Certificação AWS Solutions Architect Associate SAA-C03

Explicação: O IAM Access Analyzer analisa permissões concedidas por meio de políticas para determinar quais recursos são compartilhados com uma entidade externa e ajuda a identificar permissões excessivas ou violações de privilégios mínimos em todas as contas em uma organização da AWS. Ele foi projetado especificamente para revisar e refinar permissões do IAM com esforço administrativo mínimo. Extrato de documentação da AWS: "O IAM Access Analyzer ajuda a identificar os recursos em sua organização e contas, como buckets do Amazon S3 ou funções IAM, que são compartilhados com uma entidade externa. Você também pode usar verificações de política do Access Analyzer para refinar permissões e implementar privilégios mínimos." (Fonte: documentação do IAM Access Analyzer) R: O Network Access Analyzer é para análise de acesso à rede VPC, não para permissões do IAM. B: Os alarmes do CloudWatch não são adequados para análise detalhada de permissões. D: O Amazon Inspector serve para avaliação de vulnerabilidades de segurança, não para revisão de políticas de IAM. Referência: Guia de estudo oficial do AWS Certified Solutions Architect, Análise de segurança do IAM.

Explicação: A empresa deseja migrar de um ambiente Docker local para serviços AWS totalmente gerenciados com armazenamento persistente. A melhor opção é: Amazon ECS com tipo de inicialização AWS Fargate: esta é uma solução de orquestração de contêiner sem servidor onde a AWS gerencia a infraestrutura subjacente, eliminando a necessidade de gerenciar nós EC2 ou Kubernetes. Amazon EFS (Elastic File System): Este é um sistema de arquivos totalmente gerenciado, escalável e compartilhado para uso com tarefas do ECS. Ele oferece suporte ao armazenamento persistente para contêineres, substituindo os volumes locais usados ​​no local. Esta combinação (ECS + Fargate + EFS) é totalmente gerenciada e não requer manutenção manual do servidor. A opção A usa EKS com nós autogerenciados, que não são totalmente gerenciados. A opção C (DynamoDB) é para armazenamento estruturado de chave-valor, não para armazenamento persistente de arquivos. A opção D usa ECS com tipo de inicialização EC2, que não é sem servidor e requer gerenciamento de instâncias. Referência: uso do Amazon ECS com AWS Fargate Montagem de volumes EFS em tarefas do ECS

Explicação: Workload Discovery on AWS é uma ferramenta que descobre automaticamente recursos da AWS em várias contas e regiões e cria diagramas de arquitetura visual que mostram relacionamentos de recursos. Ele foi projetado especificamente para ajudar as equipes a compreender e documentar as cargas de trabalho existentes com o mínimo de esforço manual. Este serviço fornece visibilidade de múltiplas contas, mapeamento de relacionamento e diagramas exportáveis, o que satisfaz diretamente a necessidade de “construir e mapear os detalhes de relacionamento das diversas cargas de trabalho” com o mínimo de sobrecarga operacional. O Systems Manager Inventory (Opção A) concentra-se na coleta de dados de configuração e inventário (principalmente para instâncias e alguns recursos) e não gera diagramas de arquitetura ou visualizações completas de relacionamento. Step Functions (Opção B) e X-Ray (Opção D) exigiriam coleta personalizada e diagramação manual e não são desenvolvidos especificamente para descoberta e mapeamento de ambiente.

Explicação: As instâncias em uma sub-rede privada não podem acessar diretamente a Internet porque não possuem endereços IP públicos e a tabela de rotas da sub-rede privada normalmente não envia tráfego 0.0.0.0/0 para um gateway da Internet. No entanto, essas instâncias ainda precisam de acesso somente de saída à Internet para baixar patches e atualizações, permanecendo inacessíveis pela Internet. O design padrão da AWS para conseguir isso é um gateway NAT implantado em uma sub-rede pública. A opção C é necessária porque um gateway NAT deve residir em uma sub-rede pública que tenha uma rota para o gateway da Internet. Isso permite que o gateway NAT encaminhe o tráfego de saída de instâncias privadas para a Internet e retorne respostas, sem permitir conexões de entrada iniciadas na Internet para essas instâncias. A opção A é necessária porque um gateway NAT usa um endereço IP elástico para representar sua identidade pública na Internet. Sem um Elastic IP, o gateway NAT não pode se comunicar com endpoints da Internet. O Elastic IP está associado ao gateway NAT, não ao gateway da Internet. A opção B é necessária porque a sub-rede privada precisa de uma rota para 0.0.0.0/0 (rota padrão) direcionada ao gateway NAT. Isso garante que o tráfego de saída da Internet das instâncias privadas seja enviado ao gateway NAT em vez de ser descartado. A opção D está incorreta porque um gateway NAT em uma sub-rede privada não teria uma rota funcional para o gateway da Internet e não forneceria saída da Internet. A opção E está incorreta porque a rota padrão da sub-rede pública deve apontar para o gateway da Internet, e não para o gateway NAT. A opção F está incorreta porque você não associa Elastic IPs a um gateway de Internet. Portanto, A, B e C implementam corretamente o acesso à Internet de saída da sub-rede privada, mantendo as instâncias inacessíveis pela Internet.

Explicação: O modelo de acesso centralizado com menor sobrecarga é conectar o Active Directory local existente usando o AD Connector e, em seguida, gerenciar o acesso à conta da AWS por meio de conjuntos de permissões do IAM Identity Center. A documentação da AWS explica que o IAM Identity Center fornece um local para atribuir permissões a várias contas da AWS, e o AD Connector foi projetado especificamente para permitir que os serviços da AWS usem um diretório existente sem armazenar informações de diretório na AWS. Essa abordagem preserva a fonte de autenticação atual da empresa e adiciona autorização centralizada em toda a organização. A criação de usuários do IAM ou a criação de scripts de atribuições de funções entre contas acrescentaria um trabalho administrativo significativo e enfraqueceria o modelo de identidade. ============

Explicação: AWS Direct Connect: fornece uma conexão de rede dedicada do seu data center local para a AWS, garantindo baixa latência e desempenho de rede consistente. Associação Direct Connect Gateway: Direct Connect Gateway: atua como um hub de trânsito de rede global para conectar VPCs em diferentes regiões da AWS. Associação com Transit Gateway: permite a comunicação entre data centers locais e várias VPCs conectadas ao transit gateway. Interface Virtual de Trânsito (VIF): Criar VIF de Trânsito: Para conectar o Direct Connect a um gateway de trânsito. Etapas de configuração: Estabeleça uma conexão Direct Connect. Crie um VIF de trânsito para o gateway Direct Connect. Associe o gateway Direct Connect ao gateway de trânsito conectado às VPCs. Eficiência de Custos: Esta combinação evita os custos recorrentes e a potencial variabilidade de desempenho das conexões VPN, fornecendo uma solução de rede híbrida robusta e de baixa latência. Referência: AWS Direct Connect Transit Gateway e Direct Connect Gateway

Explicação: para executar instâncias do RDS somente durante o horário comercial com o mínimo de sobrecarga operacional, você pode usar o Amazon EventBridge para agendar eventos que invocam funções do AWS Lambda. As funções do Lambda podem ser configuradas para iniciar e interromper as instâncias do RDS com base na programação especificada (horário comercial). As regras do EventBridge permitem definir eventos recorrentes facilmente, e as funções Lambda fornecem uma maneira sem servidor de gerenciar operações de início e parada de instâncias RDS, reduzindo a sobrecarga administrativa. Opção A: embora os alarmes do CloudWatch possam ser usados, eles são mais adequados para monitoramento, e usar o Lambda com EventBridge é mais simples. Opção B (Trusted Advisor): O Trusted Advisor não é ideal para agendar tarefas. Opção C (Gerenciador de Sistemas): O Gerenciador de Sistemas também pode funcionar, mas o EventBridge e o Lambda oferecem uma solução mais simplificada e com menor sobrecarga. Referência da AWS: Agendador do Amazon EventBridge AWS Lambda

Explicação:

Explicação: Para conceder acesso entre contas a um bucket do Amazon S3, você pode usar uma política de bucket que especifique o ID da conta da AWS à qual você deseja conceder acesso. Este método permite que a Conta B acesse o bucket S3 na Conta A sem a necessidade de serviços ou configurações adicionais. Referência: Exemplo 2: Proprietário do bucket concedendo permissões de bucket entre contas

Explicação: O Amazon Aurora Serverless v2 oferece capacidade de banco de dados econômica, sob demanda e com escalonamento automático. Você paga apenas pelo uso real, tornando-o ideal para ambientes de desenvolvimento e teste que não são usados ​​continuamente. Suporta PostgreSQL e é adequado para cargas de trabalho variáveis ​​e de curta duração, minimizando custos quando os bancos de dados estão ociosos. Extrato de documentação da AWS: "O Amazon Aurora Serverless v2 ajusta automaticamente a capacidade do banco de dados com base nas necessidades do aplicativo, ideal para ambientes de desenvolvimento e teste com uso intermitente." (Fonte: documentação do Aurora Serverless v2) B: As instâncias RDS são executadas e acumulam cobranças mesmo quando ociosas. C, D: Clusters/bancos de dados globais Aurora são um exagero e incorrem em custos mais altos para desenvolvimento/teste. Referência: Guia de estudo oficial do AWS Certified Solutions Architect, Aurora Serverless for Cost Optimization.