No exame DOP-C02, o dominio de automacao do ciclo de vida do desenvolvimento de software (22%) tem o maior peso de todos os seis dominios. Em seu nucleo estao CodePipeline, CodeBuild e CodeDeploy trabalhando em conjunto. O exame nao testa apenas se voce conhece esses servicos — testa se voce consegue identificar a combinacao correta para requisitos especificos e reconhecer as armadilhas comuns.
Arquitetura aprofundada do CodePipeline
O CodePipeline e um orquestrador, nao um construtor ou implantador. Ele conecta os estagios de origem, build, teste e implantacao em um fluxo de trabalho automatizado unico, invocando o servico certo em cada etapa e aguardando os resultados antes de prosseguir.
Estrutura de estagios do pipeline
Um pipeline de producao tipico tem esta aparencia:
Source: Detecta mudancas de codigo no CodeCommit, GitHub (via CodeStar Connections) ou S3 e aciona o pipeline Build: CodeBuild compila, executa testes unitarios, constroi imagens Docker e produz artefatos Test: CodeBuild executa testes de integracao, varreduras de seguranca e portas de qualidade Staging Deploy: CodeDeploy ou CloudFormation implanta no ambiente de preparacao Approval: Acao de aprovacao manual quando os requisitos de conformidade exigem aprovacao humana Production Deploy: CodeDeploy implanta em producao com a estrategia de implantacao selecionada
Acoes paralelas vs sequenciais
Multiplas acoes dentro de um unico estagio sao executadas em paralelo. Por exemplo, testes unitarios e analise estatica de codigo podem ser executados simultaneamente para reduzir o tempo total de execucao do pipeline. Acoes em estagios separados sao executadas sequencialmente.
Pipelines entre contas
Um padrao comum em grandes empresas — e um topico frequente no exame — e executar o CodePipeline em uma conta central de ferramentas e implantar em contas de preparacao e producao separadas. Isso requer criar funcoes IAM de contas cruzadas em cada conta de destino com permissoes de implantacao, conceder a funcao de servico CodePipeline permissao para assumir essas funcoes via STS, e configurar politicas de bucket S3 e politicas de chave KMS para permitir acesso das contas de origem e destino.
Analise aprofundada do buildspec.yml do CodeBuild
O arquivo buildspec.yml define o processo de build completo. Um detalhe de comportamento critico: se a fase de build falhar, os comandos subsequentes nessa fase param de executar — mas post_build ainda executa independentemente. Essa e a fonte de um bug comum do mundo real que o exame testa diretamente.
Estrutura do buildspec.yml
Variavel de ambiente CODEBUILD_BUILD_SUCCEEDING
Este e um topico importante que aparece diretamente no exame. Mesmo que a fase de build falhe devido a um erro nos testes unitarios, a fase post_build sempre e executada. Sem uma verificacao explicita, uma imagem Docker defeituosa poderia ser enviada ao ECR e se tornar uma candidata a implantacao.
A variavel CODEBUILD_BUILD_SUCCEEDING e definida como 1 se todas as fases anteriores tiveram sucesso, e 0 se alguma fase falhou. Use essa variavel em post_build para condicionar o envio da imagem: se o valor for 0, ignore o docker push e termine com codigo de saida 1 para marcar o build como falho. Esse padrao evita que imagens defeituosas cheguem a producao.
Integracao de segredos e configuracao
CodeBuild suporta tres metodos para injetar segredos:
env.variables: Texto simples (evite para valores sensiveis — visivel no CloudTrail e logs) env.parameter-store: Referencias caminhos do SSM Parameter Store (apropriado para configuracao nao sensivel) env.secrets-manager: Referencias IDs de segredos do Secrets Manager (apropriado para credenciais)
A funcao de servico do CodeBuild deve ter permissoes IAM para acessar os caminhos referenciados do Parameter Store e os segredos do Secrets Manager.
Arquitetura de integracao de testes automatizados
Estrategia de posicionamento por tipo de teste
Testes unitarios pertencem a fase de build — executam em milissegundos a segundos e devem bloquear o build de produzir artefatos se falharem. Testes de integracao requerem dependencias externas (bancos de dados, APIs, servicos downstream) e podem executar de minutos a horas.
Uma questao direta de cenarios reais do DOP-C02: "Testes de integracao requerem ate 2 horas. Como o pipeline deve lidar com isso?" A resposta correta e adicionar um projeto dedicado do CodeBuild como uma acao de estagio de teste. O CodePipeline aguarda automaticamente a conclusao do CodeBuild e usa o codigo de saida para determinar sucesso ou falha. Lambda (maximo de 15 minutos de execucao) e explicitamente errado neste cenario e aparece como opcao armadilha.
CodeGuru Reviewer para portas de qualidade de codigo
O Amazon CodeGuru Reviewer integra-se ao CodeCommit e GitHub para revisar automaticamente pull requests em busca de problemas de qualidade de codigo, vulnerabilidades de seguranca e padroes de uso indevido da API AWS. Suporta Java e Python. Quando uma questao do exame pergunta sobre "revisao automatizada de codigo para pull requests" ou "deteccao de credenciais codificadas antes do merge," o CodeGuru Reviewer e o servico alvo.
Verificacoes de saude e validacao de implantacao
Hook ValidateService do CodeDeploy
O hook de ciclo de vida ValidateService no appspec.yml e executado apos a conclusao da implantacao. Um script de validacao pode realizar smoke tests — verificando se a aplicacao responde a endpoints de verificacao de saude, verificando funcionalidade critica ou confirmando conectividade com o banco de dados. Se o script de validacao sair com um codigo nao-zero, o CodeDeploy aciona rollback automatico.
Verificacao de saude do ALB e CodeDeploy
Em implantacoes baseadas em EC2, o ALB realiza verificacoes de saude de cada instancia antes de enviar trafego de producao para ela. O CodeDeploy integra-se com essas verificacoes de saude do ALB como criterio de sucesso da implantacao. Se uma instancia recentemente implantada nao passar nas verificacoes de saude do ALB dentro do tempo de espera configurado, o CodeDeploy marca a implantacao como falha e aciona rollback automatico. Essa integracao garante que apenas instancias saudaveis e totalmente inicializadas recebam trafego real de usuarios.
Padrao de listener de teste Blue/Green do ECS
Para implantacoes Blue/Green do ECS, o CodeDeploy configura o ALB com dois listeners: o listener de producao (porta 80/443) roteando para o conjunto de tarefas Blue, e um listener de teste (tipicamente porta 8080) roteando para o conjunto de tarefas Green. O hook BeforeAllowTraffic executa uma funcao Lambda que envia solicitacoes de teste ao ambiente Green pelo listener de teste. Isso valida a nova versao em isolamento antes que qualquer trafego de producao a toque. Somente apos o sucesso do hook o CodeDeploy desloca o trafego de producao de Blue para Green. Falha em qualquer ponto aciona rollback automatico para Blue.
Pontos-chave do exame
"bloquear push para ECR quando testes unitarios falham no CodeBuild" -- verificar variavel CODEBUILD_BUILD_SUCCEEDING na fase post_build e omitir condicionalmente o comando docker push
"testes de integracao que requerem 2 horas no pipeline" -- projeto dedicado do CodeBuild em uma acao de estagio de teste (limite de 15 minutos do Lambda o torna incorreto)
"validar ambiente Green antes da transicao de trafego com rollback automatico" -- hook BeforeAllowTraffic do CodeDeploy executando uma funcao Lambda para validacao
"implantacao de pipeline entre contas" -- funcao IAM entre contas na conta de destino + permissao AssumeRole na funcao de servico CodePipeline + configuracao de politica S3 e KMS
"referenciar credenciais de banco de dados com seguranca no CodeBuild" -- secao env.secrets-manager no buildspec.yml (nao env.variables que expoe segredos nos logs)
"revisao automatizada de codigo de pull request para Java ou Python" -- Amazon CodeGuru Reviewer integrado ao CodeCommit ou GitHub
"implantacao sequencial em preparacao e producao com portao humano opcional" -- unico CodePipeline com estagio de implantacao de preparacao + acao opcional de aprovacao manual + estagio de implantacao de producao
"execucao de testes paralelos no pipeline" -- multiplas acoes dentro do mesmo estagio do pipeline (cada acao referenciando um projeto CodeBuild diferente)