Valida habilidades avançadas de DevOps incluindo entrega contínua, automação e governança de segurança na AWS.
AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeCommit, Pipelines CI/CD, Amazon ECR
AWS CloudFormation, AWS CDK, AWS Systems Manager, AWS OpsWorks, Amazon EC2 Image Builder, AWS Service Catalog
Design Multi-AZ e Multi-Region, Auto Scaling, Failover do Amazon Route 53, AWS Backup, Estratégias RTO e RPO, Padrões de recuperação de desastres
Amazon CloudWatch, AWS CloudTrail, Amazon EventBridge, AWS X-Ray, Amazon OpenSearch Service, VPC Flow Logs
Regras do Amazon EventBridge, Correção automática com AWS Lambda, Automação do AWS Systems Manager, Notificações do Amazon SNS, AWS Health Dashboard, Resposta do Amazon GuardDuty
AWS IAM, SCPs e limites de permissões, AWS KMS e Secrets Manager, Regras do AWS Config, AWS Security Hub, Amazon Inspector, Governança do AWS CloudTrail
Experimente questões no estilo do exame do conjunto de amostra gratuito. Cada resposta vem com uma explicação completa.
Uma startup de mídia implanta e opera manualmente vários aplicativos monolíticos em instâncias EC2.
A cada implantação, os engenheiros de operações acessam os servidores diretamente para instalar pacotes e modificar arquivos de configuração, e as reversões manuais levam várias horas quando as implantações falham. A gerência está exigindo que os aplicativos sejam conteinerizados para garantir consistência de implantação e construir um pipeline de CI/CD automatizado desde o build até os testes e a implantação em produção quando há mudanças de código. Ao mesmo tempo, como a equipe de operações tem pessoal limitado, a carga de gerenciamento da infraestrutura de orquestração de contêineres deve ser minimizada.
Qual é a abordagem de modernização de CI/CD baseada em contêineres MAIS apropriada que atende a esses requisitos enquanto minimiza a sobrecarga operacional?
Resposta: C. ECS Fargate + CodePipeline + CodeBuild
Para selecionar a resposta correta, você primeiro precisa entender a diferença na sobrecarga operacional entre ECS Fargate, ECS EC2 e EKS. Os requisitos principais neste cenário são 'conteinerização', 'CI/CD automatizado do build à implantação em produção' e 'minimizar o fardo de gerenciamento da infraestrutura de orquestração de contêineres'. A combinação ECS Fargate + CodePipeline + CodeBuild tem o Fargate delegando completamente o provisionamento, patching e escalonamento de instâncias EC2 para a AWS, o CodePipeline orquestrando o pipeline desde o commit de código até build, test e deploy, e o CodeBuild construindo imagens Docker e enviando para o ECR em um ambiente de build sem servidor.
O ECS Fargate é um modo de execução de contêiner sem servidor onde a AWS gerencia completamente as instâncias EC2 subjacentes necessárias para executar contêineres — você apenas especifica a combinação de vCPU (0,25–16 vCPU) e memória (512MB–120GB) na definição de tarefa, e um ambiente isolado dedicado é provisionado automaticamente. O CodePipeline define estágios Source → Build → Test → Deploy e integra-se com CodeBuild, ECR e ECS em cada estágio. O CodeBuild usa comandos em buildspec.yml para construir imagens e enviar para o ECR, e a integração do CodeDeploy blue/green com serviços ECS automatiza a mudança de tráfego e a reversão.
O ECS EC2 da Opção 1 requer o gerenciamento direto de clusters de instâncias EC2, gerando sobrecarga operacional adicional para patching de AMI e gerenciamento de políticas de escalonamento de instâncias. O EKS + Jenkins + Helm da Opção 2 cria cargas de gerenciamento em três camadas — grupos de nós do cluster EKS, servidores master/agente do Jenkins e gráficos Helm — tornando-o o MAIS distante do requisito 'minimizar carga operacional'. As imagens de contêiner Lambda da Opção 4 são inadequadas para aplicações web monolíticas de longa execução devido ao limite máximo de tempo de execução de 15 minutos e ao limite de tamanho de imagem de 10GB. Quando 'conteinerização + automação de CI/CD + minimizar sobrecarga de gerenciamento' aparecem juntos em uma questão de exame, selecione Fargate + CodePipeline + CodeBuild primeiro.
Uma empresa de educação online opera uma aplicação web em um grupo Auto Scaling gerenciado pelo CloudFormation.
Sempre que uma nova AMI é lançada, o modelo de inicialização deve ser atualizado e as instâncias existentes devem ser substituídas. No entanto, se muitas instâncias forem encerradas simultaneamente durante o processo de substituição, a capacidade do serviço fica insuficiente e os tempos de resposta dos usuários aumentam drasticamente. A equipe de operações deseja substituir gradualmente as instâncias enquanto sempre mantém o número mínimo de instâncias saudáveis durante as atualizações de pilha do CloudFormation, e esse processo deve ser executado automaticamente sem intervenção manual.
Qual é a estratégia de atualização baseada no CloudFormation MAIS apropriada que atende a esse requisito?
Resposta: B. AutoScalingRollingUpdate
Os requisitos MAIS críticos neste cenário são 'durante atualizações de pilha do CloudFormation', 'substituição gradual de instâncias', 'manutenção de um número mínimo de instâncias saudáveis' e 'automatizado sem intervenção manual'. A política AutoScalingRollingUpdate do CloudFormation é definida sob o atributo UpdatePolicy, permitindo a especificação declarativa de MaxBatchSize para o número máximo de instâncias a substituir de uma vez e MinInstancesInService para o número mínimo de instâncias saudáveis a manter durante a substituição. Como um recurso nativo do CloudFormation, a substituição gradual é realizada automaticamente apenas com atualizações de pilha, sem ferramentas adicionais.
A política AutoScalingRollingUpdate tem três parâmetros principais. MaxBatchSize controla o número máximo de instâncias substituídas simultaneamente, MinInstancesInService especifica o número mínimo de instâncias que devem permanecer em serviço durante a substituição, e definir WaitOnResourceSignals como true faz com que o CloudFormation aguarde até que o cfn-signal seja recebido das novas instâncias antes de prosseguir para o próximo lote. O CloudFormation ajusta automaticamente o ritmo de substituição para evitar que a contagem de instâncias caia abaixo de MinInstancesInService enquanto substitui instâncias em lotes sequencialmente.
Quando 'CloudFormation', 'substituição gradual de instâncias' e 'manutenção de instâncias saudáveis mínimas' aparecem juntos em uma questão de exame, selecione AutoScalingRollingUpdate primeiro. AutoScalingReplacingUpdate substitui todo o grupo existente por um novo grupo, exigindo o dobro da capacidade durante a substituição, o que não é 'substituição gradual'. O CloudFormation StackSets é especializado em implantações multi-conta e multi-região e não está relacionado à substituição de instâncias em um grupo Auto Scaling em uma única pilha.
Uma empresa fintech opera uma aplicação web com várias instâncias EC2 atrás de um ALB.
A aplicação depende de um banco de dados backend e de uma API de pagamento externa. Recentemente, mesmo quando ocorrem falhas de conexão com o banco de dados, a verificação de integridade TCP padrão do ALB julga as instâncias como saudáveis, fazendo com que respostas de erro cheguem aos usuários. A equipe de operações quer implementar uma verificação de integridade que reflita não apenas a instância em si, mas também o status de conectividade dos serviços dependentes críticos dessa instância, para que o tráfego para a instância seja bloqueado automaticamente quando os serviços dependentes falharem.
Qual abordagem melhor atende a esse requisito minimizando as alterações na infraestrutura existente?
Resposta: C. Endpoint de verificação de integridade HTTP profunda do ALB
Para selecionar a resposta correta, primeiro você precisa entender a diferença entre a verificação de integridade TCP e HTTP do ALB. Uma verificação de integridade TCP verifica apenas se uma porta está aberta, portanto, se o processo da aplicação estiver ativo apesar de uma falha de conexão com o banco de dados, a instância é julgada como saudável. A verificação de integridade HTTP profunda do ALB avalia a integridade da instância com base no código de resposta HTTP de um caminho específico implementado pela aplicação. Quando o endpoint /health confirma a conectividade do banco de dados e da API de pagamento e retorna 503 em caso de falha, o ALB remove automaticamente a instância do grupo de destino. Como apenas o método de verificação de integridade no Target Group precisa ser alterado para HTTP e um endpoint /health adicionado à aplicação sem alterar a infraestrutura ALB existente, atende ao requisito de 'minimizar alterações na infraestrutura existente'.
A verificação de integridade HTTP do ALB configura caminho, intervalo de código de status HTTP saudável, intervalo, limites saudáveis/não saudáveis e tempo limite nas configurações do Target Group. Definir o limite saudável para 2-3 evita falsos positivos de instabilidade transitória de conexão, e as instâncias que atingem o limite não saudável são automaticamente removidas do Target Group. Após as verificações de integridade se recuperarem ao limite saudável, as instâncias são automaticamente readicionadas, implementando um mecanismo de auto-recuperação.
No exame, é fácil confundir com o Route 53 Failover (Opção 1). O Route 53 realiza failover em nível DNS, que não pode controlar granularmente o tráfego no nível individual de instância, e o TTL de DNS dificulta o bloqueio imediato. CloudWatch Alarm + substituição do Auto Scaling (Opção 2) substitui instâncias não saudáveis por novas, levando minutos, e as novas instâncias sofrerão o mesmo problema enquanto a falha do serviço dependente persistir. Quando você vir requisitos para 'baseado em ALB + detecção de status de serviço dependente + bloqueio imediato,' o endpoint de verificação de integridade HTTP profunda é o padrão principal.
Uma instituição financeira está operando um pipeline CI/CD usando CodePipeline e CodeBuild.
Durante o estágio de build, o projeto CodeBuild precisa baixar arquivos de bibliotecas de terceiros de um bucket S3 específico, mas a equipe de segurança exige aplicação rigorosa do princípio de privilégio mínimo para que o ambiente de build não possa acessar outros buckets S3 ou recursos AWS. Além disso, armazenar credenciais de longo prazo no ambiente de build é proibido pela política de auditoria.
Qual abordagem MELHOR atende a esses requisitos ao configurar o CodeBuild para acessar com segurança o bucket S3 específico?
Resposta: C. CodeBuild Service Role com Privilégio Mínimo
O projeto CodeBuild de uma instituição financeira precisa acessar um bucket S3 específico sob duas restrições críticas: o princípio de privilégio mínimo que bloqueia acesso a todos os recursos além do bucket específico, e uma política de auditoria que proíbe o armazenamento de credenciais de longo prazo no ambiente de build. A abordagem da Opção 3 de conceder uma política IAM de privilégio mínimo ao CodeBuild Service Role satisfaz ambas as condições simultaneamente. O CodeBuild recebe automaticamente credenciais temporárias do AWS STS usando as permissões do Service Role designado durante a execução do build, portanto credenciais de longo prazo nunca são armazenadas no ambiente de build.
O CodeBuild Service Role é um papel IAM onde o AWS STS (Security Token Service) emite dinamicamente credenciais temporárias durante a execução do build, permitindo que o CodeBuild acesse recursos AWS. Ao restringir o campo Resource na política IAM a um ARN de bucket S3 específico (arn:aws:s3:::my-libs-bucket/*) e conceder apenas a permissão s3:GetObject, o acesso a todos os outros buckets S3 e recursos AWS é bloqueado. As credenciais temporárias são válidas apenas para a sessão de build e expiram automaticamente após a conclusão do build, minimizando o risco de vazamento.
No exame, o acesso do CodeBuild aos recursos AWS é sempre resolvido com Service Role + política IAM. Quando 'privilégio mínimo' e 'sem credenciais de longo prazo' aparecem juntos, o Service Role é a única resposta correta. Access Keys em variáveis de ambiente violam o armazenamento de credenciais de longo prazo, e credenciais armazenadas no Secrets Manager ainda são credenciais de longo prazo e não satisfazem completamente a política de auditoria.
Uma grande empresa de e-commerce opera centenas de instâncias EC2.
Uma revisão regular de custos relata que um número significativo de instâncias está superprovisionado com utilização média de CPU abaixo de 5%. A equipe de operações analisa manualmente as métricas do CloudWatch para cada instância para determinar os tipos de instância apropriados, mas esse processo leva semanas devido ao grande número de instâncias. A gerência exige que as recomendações de dimensionamento de instâncias alinhadas às características da carga de trabalho sejam derivadas automaticamente para redução de custos e devem ser aplicáveis sem degradação de desempenho.
Qual abordagem melhor atende a esse requisito minimizando a sobrecarga operacional?
Resposta: B. Recomendações do AWS Compute Optimizer
O AWS Compute Optimizer atende simultaneamente a três requisitos neste cenário: automação, dimensionamento sem risco de desempenho e overhead operacional mínimo. O Compute Optimizer usa aprendizado de máquina para analisar métricas do CloudWatch (utilização de CPU, E/S de rede, E/S de disco, memória — agente CloudWatch necessário) e deriva automaticamente recomendações de tipo de instância ideal e níveis de risco de desempenho (baixo, médio, alto) para cada instância. Sem analisar manualmente centenas de instâncias durante semanas, você pode ver imediatamente o status de toda a organização e identificar precisamente as instâncias que podem ser reduzidas sem degradação de desempenho.
O Compute Optimizer analisa um mínimo de 14 dias de métricas e pode ser estendido para até 93 dias com a opção Enhanced Infrastructure Metrics para capturar padrões de carga de trabalho periódicos. Os resultados de recomendações fornecem tipo atual, tipo recomendado, economia de custo estimada e nível de risco de desempenho por instância, classificados em quatro categorias: superprovisionado, ideal, subprovisionado e dados insuficientes. O opt-in em nível de organização por meio do AWS Organizations permite gerenciamento centralizado de recomendações mesmo em ambientes multi-conta.
No exame, você deve distinguir o Trusted Advisor (Opção 3) e o Cost Explorer Rightsizing (Opção 4). O Trusted Advisor usa regras de limite simples baseadas na média de CPU de 14 dias abaixo de 10% e não recomenda tipos de instância de substituição específicos, exigindo planos Business ou superiores. O Cost Explorer Rightsizing realiza análise centrada em custos com classificação de risco de desempenho menos sofisticada. Quando você vir a combinação de palavras-chave 'EC2 em larga escala + dimensionamento automático baseado em ML + classificação de risco de desempenho + operações mínimas,' o Compute Optimizer é a resposta correta.
O exame AWS Certified DevOps Engineer - Professional (DOP-C02) tem 75 questões e limite de 180 minutos.
A nota de aprovação do exame DOP-C02 é 750 de 1000.
O conjunto de amostra de DOP-C02 (20 questões com explicações completas) é gratuito. O banco completo com mais de 280 questões está disponível com uma assinatura do CloudMasterIT.
A certificação DOP-C02 é válida por 3 anos após a aprovação. Depois disso é necessária a recertificação.