Certificação avançada que valida habilidades no design de arquiteturas empresariais complexas e estratégias de migração na AWS.
Acesso entre contas, AWS Organizations, AWS Control Tower, Redes híbridas, AWS Transit Gateway, AWS Resource Access Manager
Arquitetura serverless, Contêineres Amazon ECS e EKS, Amazon Aurora e DynamoDB, Amazon API Gateway, AWS Step Functions, Arquitetura orientada a eventos
AWS Well-Architected Framework, AWS Cost Explorer e Trusted Advisor, Políticas avançadas de Auto Scaling, Amazon CloudWatch e X-Ray, Estratégias de cache com ElastiCache e DAX, Otimização de custos
AWS Migration Hub, AWS Application Migration Service, AWS Database Migration Service, AWS Snow Family, AWS DataSync, Estratégias de migração 6R
Experimente questões no estilo do exame do conjunto de amostra gratuito. Cada resposta vem com uma explicação completa.
Uma empresa global de e-commerce deseja migrar totalmente seu serviço web de um data center local para a AWS.
O sistema atual é baseado em servidor único com conteúdo estático e dinâmico misturado e usa banco de dados MySQL. Após a migração, a arquitetura deve minimizar a latência para usuários globais, fornecer proteção contra DDoS, garantir alta disponibilidade Multi-AZ e suportar escalabilidade automática. O banco de dados deve manter compatibilidade com MySQL enquanto melhora o desempenho de leitura, e a equipe de operações quer minimizar a sobrecarga de gerenciamento de infraestrutura.
Qual arquitetura de migração AWS MELHOR atende a todos esses requisitos simultaneamente?
Resposta: B. CloudFront + ALB + Auto Scaling + Aurora MySQL
A combinação CloudFront + ALB + Auto Scaling + Aurora MySQL é a arquitetura de migração padrão que satisfaz todos os seis requisitos: minimizar a latência global, proteção contra DDoS, alta disponibilidade Multi-AZ, escalonamento automático, desempenho de leitura compatível com MySQL melhorado e sobrecarga operacional minimizada. O CloudFront fornece proteção contra DDoS através do AWS Shield Standard enquanto armazena em cache conteúdo estático em locais de borda em todo o mundo, o ALB + Auto Scaling lida com a distribuição Multi-AZ e o escalonamento automático do tráfego dinâmico, e o Aurora MySQL resolve tanto a compatibilidade com MySQL quanto o desempenho de leitura como um serviço totalmente gerenciado.
O Amazon CloudFront é um serviço CDN global que entrega conteúdo para usuários em todo o mundo com latência mínima através de mais de 600 locais de borda. O Amazon Aurora MySQL é totalmente compatível com MySQL enquanto fornece até 5x o desempenho do MySQL padrão, e suporta até 15 Read Replicas para distribuir a carga de leitura. A combinação de ALB e EC2 Auto Scaling Group adiciona ou remove instâncias automaticamente com base nas mudanças de tráfego, eliminando a necessidade da equipe de operações gerenciar diretamente a capacidade.
Cuidado para não confundir o Global Accelerator com o CloudFront. O Global Accelerator é adequado para otimização de roteamento de tráfego dinâmico baseado em TCP/UDP, enquanto o CloudFront inclui cache de conteúdo estático e dinâmico baseado em HTTP mais proteção contra DDoS. Quando palavras-chave como serviço web misto estático/dinâmico, usuários globais, proteção DDoS e compatibilidade MySQL aparecem juntas, a combinação CloudFront + ALB + Aurora MySQL é a resposta correta padrão.
Uma empresa SaaS operando em um ambiente de múltiplas contas gerenciado pelo AWS Organizations gerencia registros DNS para endpoints de microsserviços internos e instâncias RDS em uma zona hospedada privada do Route 53 em uma conta de serviços compartilhados. As VPCs em contas de carga de trabalho recém-criadas também devem usar esse DNS privado, mas os proprietários de contas de carga de trabalho não devem poder modificar diretamente a zona hospedada.
Em um ambiente onde as contas de carga de trabalho são adicionadas continuamente, qual design de compartilhamento de DNS privado MELHOR atende aos requisitos de segurança enquanto minimiza a sobrecarga operacional?
Resposta: B. Route 53 Resolver + RAM
Esta questão testa se você consegue selecionar corretamente uma arquitetura que centraliza os direitos de modificação de registros DNS em uma conta de serviços compartilhados, enquanto permite que VPCs de contas de carga de trabalho usem DNS privado em um ambiente de múltiplas contas. Compartilhar uma Route 53 Resolver Rule via AWS RAM permite que a conta de serviços compartilhados implante regras de encaminhamento do Resolver para VPCs de contas de carga de trabalho, mantendo a autoridade de registros DNS. Configurar o compartilhamento baseado em OU aplica-se automaticamente a contas recém-adicionadas, alcançando escalabilidade e conveniência operacional simultaneamente.
Uma Route 53 Resolver Rule é uma regra que encaminha consultas DNS para um domínio específico para um IP designado. Configurar um Inbound Resolver Endpoint na conta de serviços compartilhados permite que VPCs de contas externas encaminhem consultas de domínio privado para este endpoint. Usando AWS RAM, esta Resolver Rule pode ser compartilhada com OUs específicas ou contas individuais dentro do Organizations, e as contas de carga de trabalho só precisam associar a regra compartilhada às suas VPCs. A resolução DNS é possível sem acesso direto à própria zona hospedada, satisfazendo os requisitos de segurança.
Para questões do exame AWS sobre compartilhamento de DNS em múltiplas contas, o critério principal de decisão é se os direitos de modificação estão isolados. Se o compartilhamento direto de zona hospedada for necessário, use a associação de VPC entre contas do Route 53; se tanto o encaminhamento de consultas quanto o isolamento de permissões forem necessários, Resolver Rule + RAM é a resposta correta.
Uma grande empresa está planejando uma migração para AWS com um ambiente local misto de 500 VMs no VMware vSphere, 200 VMs no Hyper-V e 50 servidores físicos.
A equipe quer coletar automaticamente CPU, memória, dependências de rede e inventário de software para determinar prioridades de migração e tipos de instância EC2. Precisam fornecer relatórios de migração visualizados.
Qual abordagem MELHOR configura a descoberta e relatório para um ambiente heterogêneo centrado no AWS Migration Hub?
Resposta: B. Migration Hub + Agentless Connector + Agent
O AWS Application Discovery Service fornece dois métodos para coletar dados de configuração e desempenho de servidores on-premises. Para ambientes VMware vSphere, o Agentless Collector (appliance OVA) é implantado no vCenter para coletar metadados de VM sem instalar agentes. Para ambientes Hyper-V e servidores físicos, o Agente é instalado diretamente para coletar processos em execução, conexões de rede e inventário de software. A Opção 2 combina os dois métodos para cobrir todo o ambiente heterogêneo.
O AWS Migration Hub agrega e visualiza centralmente os dados coletados pelo Application Discovery Service. Com base nos dados coletados de CPU, memória, armazenamento e rede, recomenda tipos de instância EC2 apropriados, e o recurso de agrupamento de aplicações visualiza dependências entre servidores para estabelecer prioridades de migração e planos de ondas. Todos os status de migração são rastreados em uma única visualização para fornecer relatórios aos executivos.
Distinga claramente as funções das três ferramentas no exame. Escolha Application Discovery Service para coleta de inventário on-premises, Migration Hub para rastreamento e gerenciamento de migração, e MGN para migração real de servidor. O AWS Config é exclusivamente para rastrear o estado de recursos dentro da nuvem AWS e não pode ser usado para descoberta on-premises.
Um grande grupo financeiro gerencia mais de 200 contas membros usando AWS Organizations com uma SCP de negação aplicada no nível raiz que bloqueia todo uso de serviços AWS fora de regiões específicas.
Após adquirir uma subsidiária estrangeira, a conta AWS existente da subsidiária deve ser integrada à Organizations. A subsidiária tem um requisito regulatório para manter suas cargas de trabalho regionais existentes por 6 meses após a aquisição.
Para permitir à conta da subsidiária acesso temporário a regiões adicionais enquanto mantém as políticas de segurança de toda a organização existente, qual abordagem de design de SCP é MAIS apropriada?
Resposta: B. Criar uma OU dedicada para a subsidiária e aplicar uma SCP de permissão de região
Um grupo financeiro controla o acesso regional de toda a organização usando uma SCP de negação na raiz, enquanto precisa conceder à conta da subsidiária acesso temporário a regiões adicionais por 6 meses. Como as SCPs são herdadas pela hierarquia de OU, separar a subsidiária em uma OU dedicada e adicionar uma SCP de permissão de região a essa OU implementa a exceção sem modificar a política raiz. Embora a negação sempre tenha precedência sobre a permissão na avaliação de SCP, a exceção é concedida separando estruturalmente o alvo por meio do posicionamento em OU.
As SCPs são ferramentas de governança que estabelecem limites de permissão ou negação nos níveis de conta, OU e raiz. Embora a SCP raiz seja herdada por todas as contas filhas, separar a subsidiária em uma OU dedicada permite que SCPs adicionais sejam aplicadas apenas a essa OU. É importante destacar que o tratamento de exceções dentro de uma SCP raiz usando a chave de condição aws:PrincipalAccount não é oficialmente suportado na sintaxe de SCP, tornando a separação de OU a única abordagem válida. Após 6 meses, remover a SCP de exceção ou mover a conta da subsidiária para uma OU existente unifica automaticamente a política.
Quando o tratamento de exceções de SCP aparecer no exame, lembre-se de que a ÚNICA maneira de conceder exceções sem modificar a SCP raiz é criar uma OU separada. A Opção 3, que tenta contornar as SCPs com IAM Policy, é sempre incorreta, e desativar temporariamente a SCP raiz afeta todas as 200+ contas e, portanto, é incorreta.
Uma instituição financeira gerencia toda a infraestrutura AWS com CloudFormation e os templates são armazenados em um repositório GitHub.
Recentemente, um desenvolvedor modificou um template CloudFormation de pilha de produção e o implantou diretamente, causando um incidente onde uma instância RDS em execução foi substituída. A equipe de segurança exige que todas as alterações de infraestrutura passem apenas por pipelines CI/CD, e uma etapa para pré-validar o impacto das alterações antes da implantação em produção deve ser incluída.
Qual é o design de pipeline CI/CD MAIS apropriado para garantir a implantação segura de alterações do CloudFormation enquanto minimiza a sobrecarga operacional?
Resposta: C. CodePipeline + Change Sets + etapa de aprovação
Uma instituição financeira precisa validar o impacto das alterações antes da implantação em produção e impor um pipeline CI/CD. A combinação de AWS CodePipeline + CloudFormation Change Sets + etapa de aprovação manual atende MELHOR a esses requisitos. Os Change Sets exibem a Action (Add/Modify/Remove) e o Replacement (True/False) de cada recurso antes de aplicar as alterações à pilha real, possibilitando a detecção prévia de alterações destrutivas como substituição de instância RDS e bloqueando-as na etapa de aprovação manual.
O AWS CodePipeline é um serviço CI/CD totalmente gerenciado que automatiza os estágios: detecção de alterações na fonte do GitHub → criação de Change Sets → revisão e aprovação → ExecuteChangeSet. Como o pipeline controla todos os caminhos de implantação, ele impede estruturalmente a implantação direta pelos desenvolvedores. Quando o campo Replacement nos CloudFormation Change Sets mostra True, significa que o recurso existente será excluído e recriado, permitindo ao aprovador rejeitar a implantação ou escolher uma alternativa.
No exame, lembre-se da combinação de Change Sets e uma etapa de aprovação manual como o núcleo das questões de implantação segura do CloudFormation. StackSets é para implantar o mesmo template em várias contas e regiões, e não está relacionado à validação do impacto de alterações para uma única pilha. CDK Diff + implantação manual não é imposição por meio de um pipeline CI/CD, deixando o risco de os desenvolvedores ainda poderem implantar diretamente.
O exame AWS Certified Solutions Architect - Professional (SAP-C02) tem 75 questões e limite de 180 minutos.
A nota de aprovação do exame SAP-C02 é 750 de 1000.
O conjunto de amostra de SAP-C02 (20 questões com explicações completas) é gratuito. O banco completo com mais de 340 questões está disponível com uma assinatura do CloudMasterIT.
A certificação SAP-C02 é válida por 3 anos após a aprovação. Depois disso é necessária a recertificação.