AWS CloudOps Engineer - Associate (SOA-C03) — Questões de prática e simulado

Raciocine de trás para frente a partir do que o cenário já descarta. O acesso geral à internet prova que o roteamento funciona. As network access control lists estão abertas, então a sub-rede não está filtrando nada. A política do bucket do S3 permite acesso a partir da VPC, e essa é a pista, porque uma política escrita assim só é satisfeita quando a requisição realmente chega pelo caminho do endpoint privado. O tráfego que sai por um NAT gateway alcança o endpoint público do S3 e não carrega contexto de endpoint, então a política o nega mesmo com os pacotes chegando.

Isso faz do VPC endpoint para o S3 o ponto a verificar. Existe um gateway endpoint para o S3 nesta VPC, e a associação de tabela de rotas dele inclui a sub-rede privada? Criar o endpoint é só metade do trabalho; depois você o adiciona como destino na tabela de rotas para o tráfego direcionado ao S3, e uma sub-rede cuja tabela de rotas nunca foi associada continua usando o caminho da internet.

As outras três não combinam com os sintomas. A largura de banda do NAT gateway causaria lentidão, não uma negação seca. O versionamento do bucket é uma configuração de proteção de dados, sem relação com o acesso. A permissão da função da instância é uma armadilha que soa plausível, mas o enunciado te diz que a política do bucket é o controle em jogo.

Dica de prova: quando a conectividade funciona de forma geral e um único serviço falha, procure na política do recurso uma condição que restrinja o caminho, não apenas o principal.

Sobreviver à perda de uma Availability Zone exige duas coisas: uma cópia dos dados em outro lugar e algo que promova essa cópia automaticamente. Habilitar o cluster mode com réplicas espalhadas por várias Availability Zones fornece a cópia, e o auto-failover Multi-AZ fornece a promoção: ele detecta que o primário está inacessível e elege uma réplica em uma zona que continua de pé, sem nenhum operador no processo. É por isso que essa configuração melhora a tolerância a falhas exatamente na falha que o cenário descreve.

Repare no cuidado da redação sobre perda de dados. A replicação para as réplicas é assíncrona, então gravações que o primário confirmou um instante antes de cair podem nunca ter chegado a uma réplica. O que se sustenta é perda mínima de dados, não zero, e uma resposta que promete perda zero com replicação assíncrona costuma ser a errada.

Os distratores erram na disponibilidade. Snapshots diários são um backup, útil para restaurar depois de uma corrupção, mas medido em horas de perda e com restauração manual. Nós independentes em zonas diferentes não compartilham dados, então perder um significa perder todas as sessões que viviam ali. A persistência append-only em um único nó sobrevive ao reinício do processo naquele nó, mas o nó continua em uma única zona e não há para onde fazer failover.

Dica de prova: separe durabilidade de disponibilidade. Snapshots e persistência dão durabilidade; réplicas mais promoção automática dão disponibilidade.

Aplicar uma tag a uma instância é uma chamada de API, e é nessa chamada que toda a automação se apoia. A marcação passa pela ação CreateTags do Amazon EC2, o AWS CloudTrail registra essa chamada como evento de gerenciamento, o CloudTrail entrega os eventos que registra ao Amazon EventBridge, e uma regra do EventBridge cujo padrão de evento corresponde àquela chamada de API e àquela chave de tag invoca o AWS Lambda como alvo. A função Lambda então cria o bucket do S3 pelo SDK. Nada faz polling, nada roda por temporizador, e a reação acontece porque a chamada de API aconteceu — que é exatamente o que orientado a eventos significa.

As outras três combinações quebram já no primeiro passo. As métricas do Amazon CloudWatch são séries temporais numéricas e nenhuma métrica carrega uma chave de tag e seu valor, então nada nessa cadeia consegue detectar a mudança, e colocar o Amazon SNS na frente do AWS Lambda apenas encaminha uma notificação que nunca foi gerada. Uma regra agendada do Amazon EventBridge que consulta tags por polling é o oposto de orientado a eventos: ela acorda por temporizador, acrescenta latência de até o intervalo de polling e roda o tempo todo mesmo quando nada mudou, de modo que o AWS Step Functions atrás dela herda esse atraso. A opção do AWS Config é a que chega mais perto de ser plausível, porque o AWS Config de fato avalia mudanças de configuração de recursos, mas passar pelo AWS Systems Manager e pelo AWS CloudFormation para criar um único bucket é maquinário muito mais pesado do que o cenário precisa, e isso descarta a correspondência de padrão do EventBridge, que é o que faz a filtragem de verdade.

Dica de prova: para um requisito com a forma quando isso acontecer, faça aquilo, a resposta padrão da AWS é o CloudTrail registra a chamada de API, o EventBridge faz a correspondência do padrão de evento e o Lambda executa a ação. Reconhecer esse trio responde de cara à maioria das questões sobre automação orientada a eventos.

Leia as duas restrições juntas: criptografia em trânsito e certificados gerenciados pela AWS. O AWS Certificate Manager, ou ACM, provisiona certificados públicos, valida e renova esses certificados automaticamente, e o ACM se integra ao Elastic Load Balancing, então você pode implantar o certificado direto no load balancer. Você anexa o certificado provisionado ao listener HTTPS do ALB e a plataforma cuida do resto do ciclo de vida, sem material de chave para copiar nas instâncias e sem data de renovação para lembrar.

Cada distrator quebra uma das restrições. Certificados autoassinados gerados em cada instância com OpenSSL não são gerenciados pela AWS de jeito nenhum, e os clientes os rejeitam a menos que você distribua a confiança na mão. O AWS KMS cria e controla chaves criptográficas; ele não é uma autoridade certificadora e não gera certificados TLS. Enviar certificados de servidor do IAM ainda funciona para configurações antigas, mas esses certificados foram obtidos em outro lugar e a renovação fica por sua conta, que é justamente o trabalho de gerenciamento que a questão manda você evitar.

Dica de prova: certificados gerenciados pela AWS mais um load balancer é um par fixo. Se a questão então acrescentar criptografia entre o load balancer e as instâncias que estão atrás dele, trate a conexão de back-end como uma decisão separada do certificado do listener.