Amazon DVA-C02: CloudFormation e Infraestrutura como Código (SAM, CDK) — Guia de estudos

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Faz parte do AWS Developer Associate DVA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Padrões centrais do CloudFormation e melhores práticas para templates

Os templates do CloudFormation devem ser criados como descrições declarativas e idempotentes de recursos, favorecendo stacks pequenas e focadas, e stacks aninhadas para arquiteturas complexas. Use a seção Resources com IDs lógicos explícitos e prefira funções intrínsecas como !Ref, !GetAtt, !Sub, Fn::FindInMap e Fn::If para composição e reutilização. Valide os templates com aws cloudformation validate-template ou os equivalentes do SAM/CDK (sam validate, cdk synth) antes de criar change sets. Use ChangeSets (CreateChangeSet / ExecuteChangeSet) para revisão e para evitar substituições inesperadas; use DescribeChangeSet para inspecionar as ações que a stack irá executar. Mantenha o corpo do template dentro dos limites do CloudFormation movendo código inline grande para o S3 e referenciando-o (CodeUri, S3Bucket/S3Key), ou divida em stacks aninhadas com AWS::CloudFormation::Stack. Execute a detecção de drift regularmente usando DetectStackDrift e DescribeStackResourceDrifts. Use DeletionPolicy e UpdateReplacePolicy para proteger recursos que contêm dados e ative a proteção contra exclusão (termination protection) em stacks críticas. Integre o cfn-lint e o cfn-guard ao CI/CD para detectar problemas estruturais e violações de política antecipadamente. Para iteração rápida, utilize ChangeSets e estratégias de atualização no nível do recurso para minimizar o raio de impacto (blast radius); para funções Lambda, use deployments versionados para tornar as atualizações seguras e reversíveis.

Parametrização, mapeamentos, segredos e dados sensíveis

Parametrize as diferenças de ambiente com Parameters e Mappings do CloudFormation, usando AllowedValues e ConstraintDescription para falhar rapidamente. Evite embutir segredos ou credenciais em texto plano nos Parameters; em vez disso, use o SSM Parameter Store com o tipo SecureString ou o Secrets Manager e referencie-os por meio de referências dinâmicas como {{resolve:secretsmanager:mysecret:SecretString:password}} ou use tipos AWS::SSM::Parameter::Value<String>. Marque parâmetros sensíveis com NoEcho: true para mascarar os valores no console, mas saiba que NoEcho não criptografa os dados em repouso — use o Secrets Manager para auditoria e rotação. Use Mappings e Fn::FindInMap para valores determinísticos e específicos do ambiente (IDs de AMI por região) e Fn::GetAZs para o cálculo de zonas de disponibilidade. Para referências a recursos entre stacks na mesma região/conta, exporte saídas (outputs) e importe-as via Fn::ImportValue; lembre-se que as importações não podem cruzar contas ou regiões. Proteja os principals do IAM usados pelo CloudFormation definindo o escopo das roles com o princípio do menor privilégio; prefira permissões gerenciadas pelo serviço para StackSets ou provisione explicitamente uma role de administração com escopo limitado. Ao passar variáveis de ambiente para contêineres ou Lambda, prefira referenciar ARNs do Secrets Manager ou do SSM Parameter e fazer a recuperação em tempo de execução no código, ou use recursos do SAM/CDK para injetar valores seguros no ambiente com criptografia via KMS.

Deployments entre contas/regiões, padrões multi-account com CDK e SAM

Deployments entre contas (cross-account) e entre regiões (cross-region) exigem uma orquestração que vai além das exportações de uma única stack. Para deployments multi-account/multi-region, escolha CloudFormation StackSets (CreateStackSet, CreateStackInstances) com permissões gerenciadas pelo serviço (service-managed) para o Organizations ou autogerenciadas (self-managed) com uma role de execução nas contas de destino. Para artefatos de código da aplicação, use buckets S3 centralizados com replicação entre contas (cross-account replication) ou políticas de bucket, ou deixe as ferramentas publicarem os ativos por região: o CDK usa stacks de bootstrap e ativos publicados via cdk-assets e requer a execução de cdk bootstrap em cada conta/região; o CDK Pipelines (módulo pipelines) ou a CLI aws-cdk com --role-arn suportam a promoção entre contas. O SAM usa sam package / sam deploy, que faz o upload de artefatos para um bucket S3; para multi-account, use CI/CD para empacotar e enviar os artefatos para os buckets das contas de destino e executar os deploys com as credenciais apropriadas. Evite buscas de contexto do CDK (ex: VPC.fromLookup) que exigem permissão específica da conta no momento do synth; em vez disso, passe os identificadores explicitamente como parâmetros para manter o synth reproduzível. Use o AWS CodePipeline ou o GitHub Actions com roles assumidas (sts:AssumeRole) para realizar deploys nas contas de destino, garantindo que o bootstrap e as service-linked roles necessárias existam. Lembre-se que as exportações do CloudFormation são regionais; prefira StackSets ou deployments orientados por pipeline para distribuição entre contas.

Recursos personalizados, proteção de stack e aceleradores de implantação local/incremental

Use recursos personalizados (custom resources) quando o CloudFormation não possui um tipo de recurso nativo, implementando provedores baseados em Lambda que respeitem o protocolo de resposta do CloudFormation para eventos de Create/Update/Delete. Crie handlers idempotentes, responda com cfn-response ou com o framework da CLI do CloudFormation, e lide com ações de longa duração usando eventos de progresso ou armazenando o estado no DynamoDB. Fique atento aos timeouts de recursos personalizados: o CloudFormation tem um timeout máximo para operações da stack, e os recursos baseados em Lambda devem ser concluídos dentro dessa janela ou causarão o rollback da stack. Proteja recursos críticos com políticas de stack (SetStackPolicy) para bloquear a substituição ou atualização de IDs lógicos especificados durante as atualizações da stack, e habilite a proteção contra exclusão (termination protection) para ambientes que você não pode se dar ao luxo de excluir. Para desenvolvimento incremental e local, use a AWS SAM CLI (sam build, sam local invoke, sam local start-api) e o sam sync para atualizações rápidas apenas de código, e o CDK watch ou cdk deploy com ativos para atualizar somente os recursos alterados; essas ferramentas calculam hashes dos ativos (lambda asset hashing) para que apenas o código modificado seja republicado. Integre ChangeSets do CloudFormation, versionamento de Lambda (AutoPublishAlias no SAM ou lambda.Version no CDK) e desvio de tráfego (traffic-shifting) com o CodeDeploy para implantações seguras. Armadilhas comuns incluem exceder os limites de template ou de parâmetros, usar importações entre contas (cross-account) incorretamente e inicializar clientes de SDK pesados dentro dos handlers, causando latências de cold-start — prefira clientes globais, inicializados de forma tardia (lazy-initialized), com timeouts e comportamento de retry configuráveis.

Problema Prático: Cenário de Caso de Uso

Cenário: A AcmeMedia gerencia uma organização AWS com múltiplas contas, com contas separadas de Dev, Staging e Prod na região us-east-1. Um serviço serverless de processamento de imagens (Lambda + S3 + DynamoDB) deve ser implantado de forma consistente em todas as contas, com configurações sensíveis compartilhadas e armazenadas centralmente.

Desafio: Implantar a mesma stack de CloudFormation/SAM/CDK em múltiplas contas e garantir que os artefatos de código do Lambda estejam disponíveis de forma segura em cada conta de destino, mantendo os segredos fora dos templates.

Abordagem Recomendada:

1. Use AWS CloudFormation StackSets com permissões gerenciadas pelo serviço (aws cloudformation create-stack-set –stack-set-name ImageProcessor –template-body file://template.yaml) e depois aws cloudformation create-stack-instances para direcionar às contas e regiões de destino, ou configure CDK Pipelines para sintetizar e implantar por conta com roles.
2. Empacote os ativos do Lambda usando a publicação de ativos do CDK (cdk bootstrap em cada conta/região) ou o sam package para um bucket S3 em cada conta de destino; automatize a cópia de ativos via CI (CodeBuild usando aws s3 cp ou replicação do S3) e use cdk deploy ou sam deploy com as credenciais da conta de destino.
3. Armazene configurações sensíveis no AWS Secrets Manager em cada conta, referenciando-as no template através de referências dinâmicas ({{resolve:secretsmanager:arn:aws:secretsmanager:us-east-1:123456789012:secret:ImageProcSecret:SecretString:apiKey}}) ou implante um secret replicado através do recurso de replicação do Secrets Manager, evitando parâmetros NoEcho.
4. Use ChangeSets (create-change-set, execute-change-set), habilite a proteção contra exclusão (termination protection) nas stacks de produção e use políticas de stack (stack policies) para prevenir a substituição acidental de tabelas do DynamoDB ou buckets do S3 durante as atualizações.

Justificativa: StackSets e implantações orientadas por pipeline fornecem uma propagação segura e auditável entre múltiplas contas/regiões, enquanto a publicação de ativos e os secrets por conta mantêm as credenciais locais e auditáveis. ChangeSets, proteção contra exclusão e políticas de stack reduzem o risco durante implantações iterativas.

← Amazon DynamoDB e Design NoSQL · Todos os domínios · Implantação e CI →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →