Certificação AWS Solutions Architect Associate SAA-C03

Explicação: De acordo com o AWS Well-Architected Framework Security Pillar e o Guia do usuário do AWS Identity and Access Management (IAM), a conta de usuário root em uma conta da AWS é extremamente poderosa e deve ser protegida com medidas de segurança rigorosas. Da documentação da AWS: "Recomendamos que você não use o usuário root para tarefas diárias, mesmo administrativas. Em vez disso, crie usuários IAM e conceda a eles apenas as permissões necessárias. Para ajudar a proteger sua conta AWS, habilite a autenticação multifator (MFA) para o usuário root." (Fonte: Guia do usuário do AWS Identity and Access Management Protegendo o usuário root) A ação correta e recomendada é criar usuários IAM com permissões específicas para operações diárias e habilitar a MFA no usuário root para fornecer uma camada adicional de segurança. O usuário root não pode ser desabilitado, portanto a Opção A é tecnicamente incorreta. A AWS também desaconselha explicitamente o uso de chaves de acesso root (Opção C) ou o compartilhamento de credenciais root (Opção D), ambos os quais violam o princípio do privilégio mínimo. Práticas recomendadas resumidas na documentação oficial da AWS: Não use o usuário root para tarefas de rotina Habilite MFA para usuário root imediatamente Crie usuários IAM individuais e atribua privilégios mínimos Evite criar ou usar chaves de acesso de usuário root Essas recomendações são fundamentais para proteger qualquer nova conta da AWS e são consistentemente enfatizadas no Guia de estudo oficial do AWS Certified Solutions Architect e no whitepaper de práticas recomendadas de segurança da AWS. Referência: Guia do usuário do AWS IAM "Protegendo o usuário root" Pilar de segurança do AWS Well-Architected Framework Guia de estudo oficial do AWS Certified Solutions Architect (última edição)

Explicação: A orientação da AWS para aplicativos globais, altamente disponíveis e de baixa latência usando um banco de dados relacional recomenda: Amazon CloudFront com Amazon S3 para conteúdo estático para armazenar dados em cache em pontos de presença globalmente e minimizar a latência para ativos estáticos. Uma camada de aplicação regional implantada perto dos usuários usando serviços de contêiner gerenciados, como Amazon ECS no AWS Fargate, que elimina a necessidade de gerenciar servidores e escalar automaticamente, reduzindo a sobrecarga operacional. Uma camada de banco de dados relacional que usa o banco de dados global Amazon Aurora, criado especificamente para aplicativos distribuídos globalmente. O banco de dados global Aurora fornece um cluster primário em uma região com réplicas de leitura de baixa latência em regiões secundárias e replicação rápida entre regiões, permitindo leituras de baixa latência e alta disponibilidade para usuários globais. A opção A utiliza apenas uma única região, o que não atende ao requisito de “usuários globais com baixa latência”. A opção C usa replicação baseada em RDS e DMS, que requer mais gerenciamento e não fornece recursos de banco de dados globais integrados do Aurora. A opção D substitui o banco de dados relacional pelo DynamoDB, o que viola o requisito de que o aplicativo interaja com um banco de dados relacional.

Explicação: erros esporádicos de HTTP 500 em um aplicativo que depende do DynamoDB geralmente indicam falhas downstream intermitentes (por exemplo, limitação transitória, problemas temporários de rede, tempos limite de solicitação ou exceções que podem ser repetidas no lado do serviço). O prompt indica que a tabela do DynamoDB está no modo sob demanda e outros aplicativos a utilizam sem problemas, o que sugere que o problema não é uma deficiência sustentada de capacidade ou uma interrupção sistêmica do DynamoDB. Em vez disso, o aplicativo Web provavelmente precisará lidar com falhas ocasionais que podem ser repetidas com mais eficiência. A opção C é a prática recomendada para melhorar a confiabilidade ao chamar serviços da AWS: implementar espera exponencial com novas tentativas. Os SDKs da AWS geralmente incluem comportamento de repetição, mas muitos sistemas ainda exigem ajuste (por exemplo, aumentar o máximo de tentativas, adicionar jitter, garantir operações idempotentes quando necessário e tentar novamente somente em erros repetíveis). A espera exponencial reduz a chance de sobrecarregar um serviço durante breves períodos de contenção e ajuda o aplicativo a se recuperar rapidamente de erros transitórios sem falhas visíveis ao usuário. Essa abordagem também é minimamente perturbadora porque é uma melhoria de configuração e lógica, e não uma migração arquitetônica. A opção A não é uma configuração padrão do DynamoDB; O DynamoDB tem limites de tamanho de item e a taxa de transferência é gerenciada por meio de capacidade sob demanda ou provisionada, e não por “suporte a solicitações de gravação maiores”. A opção B (Streams) fornece um feed de captura de dados alterados, mas não evita ou mitiga falhas de solicitação; é para processamento de eventos, replicação ou auditoria. A opção D (leituras fortemente consistentes) aborda leituras obsoletas, não erros HTTP 500, e pode aumentar o custo de leitura/consumo de RCU sem resolver a causa raiz. Portanto, adicionar espera e novas tentativas exponenciais é a maneira mais apropriada e operacionalmente sólida de reduzir falhas esporádicas sem interromper a arquitetura ou o desempenho do aplicativo.

Explicação: Uma política de controle de serviço é o controle correto para toda a organização porque os SCPs definem o máximo de permissões disponíveis nas contas-membro. A documentação da AWS também observa que em SCPs você pode usar a condição global keyaws:PrincipalArnin theConditionelement para identificar entidades de segurança específicas, incluindo funções. Isso torna a opção D o padrão correto: negar a modificação das funções do Lambda para todos, exceto para a função designada da equipe de segurança. Um SCP que negue todas as alterações sem exceção também bloquearia a equipe de segurança. O elemento Principal não é a maneira correta de expressar esta exceção em um SCP para este caso de uso. Portanto, a resposta correta é um SCP com uma exceção na cláusula Condition para a função da equipe de segurança.

Explicação: Criptografia EBS: Criptografia EBS padrão: pode ser habilitada para novos volumes EBS. Uso do AWS KMS: especifique chaves do AWS KMS para lidar com criptografia e descriptografia de dados de forma transparente. Criptografia do Amazon RDS: Criptografia RDS: criptografa o armazenamento subjacente para instâncias RDS usando o AWS KMS. Configuração: habilite a criptografia ao criar a instância do RDS ou modifique uma instância existente para habilitar a criptografia. Menor quantidade de alterações: tanto o EBS quanto o RDS oferecem suporte à criptografia contínua com AWS KMS, exigindo alterações mínimas na infraestrutura existente. Permite a conformidade com os requisitos regulamentares sem modificar a aplicação. Eficiência operacional: o uso do AWS KMS para EBS e RDS garante uma abordagem consistente e gerenciada para criptografia, simplificando o gerenciamento de chaves e aprimorando a segurança. Referência: Criptografia do Amazon EBS Criptografia do Amazon RDS AWS Key Management Service

Explicação: O Amazon FSx for Lustre é um sistema de arquivos totalmente gerenciado e de alto desempenho, ideal para aplicações que exigem acesso de baixa latência ao armazenamento compartilhado, especialmente em casos de uso como jogos, onde alta taxa de transferência e baixa latência são essenciais. Ele se integra facilmente às instâncias EC2, fornecendo armazenamento compartilhado rápido e escalonável e oferece suporte a protocolos personalizados para necessidades específicas de aplicativos. Opção A (FSx File Gateway): O FSx File Gateway foi projetado para armazenamento em nuvem híbrida e não é adequado para cargas de trabalho de jogos de alto desempenho. Opção B (instância EC2 Windows): Configurar um compartilhamento de arquivos em uma instância Windows introduziria sobrecarga administrativa adicional e não forneceria o desempenho necessário. Opção C (EFS com Lustre): Embora o Lustre esteja integrado ao FSx, o EFS não oferece suporte nativo ao Lustre. Referência da AWS: Amazon FSx para Lustre

Explicação:

Explicação: O Amazon Managed Streaming for Apache Kafka (Amazon MSK) é um serviço totalmente gerenciado que facilita a criação e a execução de aplicativos que usam o Apache Kafka para processar dados de streaming. Ao usar o Amazon ECS com o tipo de inicialização AWS Fargate, você pode executar contêineres sem gerenciar servidores ou clusters. Essa combinação reduz a sobrecarga operacional e fornece escalabilidade. Referência: potencialize seu aplicativo Kafka Streams com Amazon MSK e AWS FargateAmazon Web Services, Inc.

Explicação: O AWS Step Functions fornece um serviço de fluxo de trabalho totalmente gerenciado e com pouco código, com uma interface visual para orquestrar trabalhos do AWS Glue em sequência. O Step Functions integra-se nativamente ao AWS Glue e pode ser acionado pelo Amazon EventBridge com base em eventos ou programações. Extrato de documentação da AWS: "O AWS Step Functions facilita a coordenação de vários serviços da AWS em fluxos de trabalho sem servidor para que você possa criar e atualizar aplicativos rapidamente. O Step Functions fornece fluxos de trabalho visuais e integra-se ao AWS Glue para orquestração ETL." (Fonte: documentação do AWS Step Functions) R: Scripts manuais e painéis não fornecem um fluxo de trabalho visual integrado ou de baixo código. C: QuickSight é para BI, não para visualização de fluxo de trabalho. D: O ECS adiciona complexidade desnecessária. Referência: Guia de estudo oficial do AWS Certified Solutions Architect, Automação com Step Functions.

Explicação: A prática recomendada para fornecer acesso seguro de curto prazo aos recursos da AWS, como o Amazon S3, sem usar credenciais de longo prazo, é usar o AWS Security Token Service (STS). De acordo com as práticas recomendadas de IAM da AWS e o pilar de segurança do AWS Well-Architected Framework, credenciais temporárias devem sempre ser usadas em vez de credenciais de longo prazo, quando possível. Da documentação do AWS IAM: "Use credenciais temporárias (funções IAM e AWS STS) em vez de chaves de acesso de longo prazo. As credenciais de segurança temporárias são de curto prazo, expiram automaticamente e são recuperadas usando o AWS STS." (Fonte: IAM Best Practices IAM User Guide) A opção D descreve o uso de uma relação de confiança e um mecanismo de assunção de função por meio do AWS STS. Isso permite que o aplicativo local solicite credenciais temporárias com escopo reduzido para fazer upload de arquivos para o S3 com segurança. Esta abordagem é: Segura Usa credenciais de curta duração com menos privilégios Escalável Não há necessidade de túneis EC2 ou VPN Baixa sobrecarga operacional Nenhuma infraestrutura para manter Recomendado pela AWS Alinhado com as melhores práticas de segurança Em contraste: A opção A usa credenciais de longo prazo, o que é um risco de segurança. A opção B requer infraestrutura adicional (EC2, VPN), aumentando a complexidade e o custo. A opção C depende do acesso baseado em IP, que é inseguro e não uma forma de autenticação baseada em identidade. Referência: Práticas recomendadas do AWS IAM "Usar credenciais temporárias" AWS Security Token Service "Credenciais de segurança temporárias" Pilar de segurança do AWS Well-Architected Framework