Certificação AWS Solutions Architect Associate SAA-C03

Explicação: Os requisitos enfatizam a alta disponibilidade em diversas zonas de disponibilidade, recuperação automática e menor sobrecarga operacional. A maneira mais simples de conseguir isso para microsserviços em contêineres é usar um serviço de orquestração de contêineres totalmente gerenciado com computação sem servidor. O Amazon ECS com o tipo de inicialização Fargate oferece exatamente isso. Com o ECS Fargate, a AWS gerencia a infraestrutura de computação subjacente (sem instâncias do EC2 para provisionar, corrigir, escalar ou proteger no nível do sistema operacional). Você define definições de tarefas e serviços, e o ECS agenda tarefas em zonas de disponibilidade com base na sua configuração de rede (várias sub-redes em diferentes AZs). Se um contêiner falhar, o agendamento do serviço ECS o substituirá automaticamente, atendendo ao requisito de “recuperação de falhas”. O Fargate também se integra ao balanceamento de carga, ao registro em log do CloudWatch e às políticas de escalabilidade, reduzindo a carga operacional de manter a integridade da plataforma. A opção A (ECS no EC2) ainda é orquestração gerenciada, mas requer o gerenciamento da camada de capacidade do EC2: atualizações de AMI, aplicação de patches de instância, planejamento de capacidade de cluster e escalonamento de instância. A opção B (EKS com nós autogerenciados) normalmente traz ainda mais responsabilidade operacional porque você gerencia grupos de nós, atualizações e complexidade operacional do Kubernetes, além das instâncias subjacentes. A opção D é a maior sobrecarga operacional porque carece de agendamento gerenciado e autocorreção; você precisaria criar e manter seu próprio gerenciador de processos e mecanismos de failover. Portanto, C é a melhor resposta porque fornece uma plataforma de contêiner gerenciada, com capacidade multi-AZ e de autocorreção, com gerenciamento mínimo de infraestrutura – correspondendo à meta de eficiência operacional e mantendo a alta disponibilidade.

Explicação: Entre as opções listadas, a opção B é a melhor opção geral porque evita chaves de acesso de longo prazo usando uma função IAM nas instâncias EC2 e usa eventos de dados do CloudTrail para auditar o acesso S3 em nível de objeto. Os eventos de dados do CloudTrail são a maneira nativa da AWS de registrar atividades em nível de objeto, como GetObject e PutObject. A opção D melhora a restrição de rede usando um endpoint de gateway S3, mas os logs de fluxo de VPC não fornecem logs de auditoria S3 em nível de objeto, portanto, não atendem totalmente ao requisito de auditoria. As opções A e C dependem de chaves de acesso de longo prazo, o que viola o requisito de segurança. Portanto, B é a resposta mais forte entre as opções fornecidas porque atende ao requisito de ausência de chaves de longo prazo e ao requisito de auditoria de acesso a objetos. ============

Explicação: Aurora I/O-Optimized: essa configuração de armazenamento foi projetada para fornecer alto desempenho consistente para bancos de dados Aurora. Ele dimensiona automaticamente o IOPS conforme a carga de trabalho aumenta, sem a necessidade de provisionar IOPS separadamente. Economia: com o Aurora I/O-Optimized, você paga apenas pelo armazenamento e pela E/S que usar, tornando-o uma solução econômica para aplicações com demandas de E/S variadas e imprevisíveis. Implementação: durante a criação do cluster Aurora PostgreSQL Serverless v2, selecione a configuração de armazenamento otimizada para E/S. O sistema de armazenamento lidará automaticamente com o dimensionamento e a otimização do desempenho com base na carga do aplicativo. Eficiência Operacional: Esta configuração reduz a necessidade de ajuste manual e garante desempenho ideal sem sobrecarga administrativa adicional. Referência: Amazon Aurora I/O otimizado

Explicação: Amazon Textract pode extrair texto de PDFs, e Amazon Comprehen é o serviço mais adequado para analisar o texto extraído em busca de sentimentos e insights. O Comprehend oferece uma solução totalmente gerenciada e de baixa sobrecarga operacional para análise de dados de texto. Os resultados podem então ser armazenados em um Amazon S3bucket, garantindo escalabilidade e fácil acesso. Opção A: o Athena serve para consultar dados estruturados e não é adequado para análise de sentimento. Opção B: o SageMaker adiciona complexidade e não é necessário quando o Comprehend pode lidar com a análise de sentimento de forma nativa. Opção D: QuickSight é usado para visualização e análise, mas não fornece análise de sentimento. Referência da AWS: Amazon Comprehend Amazon Textract

Explicação:

Explicação: O uso de um Application Load Balancer (ALB) permite a integração com o AWS WAF para inspecionar todo o tráfego de entrada. A execução do aplicativo no Amazon ECS fornece um serviço de orquestração de contêineres escalonável e gerenciado. A utilização do Amazon Aurora Serverless para o banco de dados PostgreSQL oferece escalonamento automático com base na demanda da aplicação, o que é econômico para cargas de trabalho com padrões de tráfego variáveis, como tráfego mais alto durante a semana e tráfego mais baixo nos finais de semana. Referência: Otimizando economia de custos: a vantagem do Amazon Aurora em relação aos bancos de dados de código aberto autogerenciados

Explicação: A primeira etapa é configurar uma conta de administrador delegada para o IAM Access Analyzer no nível da organização. Somente depois de delegar a conta de administrador você poderá agregar as descobertas do Access Analyzer de todas as contas-membro em uma conta de auditoria designada. Isso deve ser configurado na conta de gerenciamento do AWS Organizations. Extrato de documentação da AWS: "Você deve designar um administrador delegado para o IAM Access Analyzer no nível da organização. A conta do administrador delegado agrega descobertas de todas as contas-membro." (Fonte: documentação do IAM Access Analyzer) A, C, D: Essas etapas não estabelecem a agregação em toda a organização necessária para o Access Analyzer. Referência: Guia de estudo oficial do AWS Certified Solutions Architect, Delegação do Access Analyzer.

Explicação: A abordagem correta e segura é usar o Amazon CloudFront com Origin Access Control (OAC) para proteger a origem S3 e anexar o AWS WAF à distribuição do CloudFront para inspecionar e filtrar o tráfego na borda antes de chegar à origem. Da documentação da AWS: "AWS WAF é integrado ao Amazon CloudFront, permitindo a inspeção de solicitações HTTP(S) no ponto de presença antes de encaminhar para sua origem. Para restringir o acesso direto ao bucket S3, use o Origin Access Control (OAC)." (Fonte: Guia do desenvolvedor do Amazon CloudFront Servindo conteúdo privado) Por que a opção D está correta: CloudFront é o único serviço que se integra ao AWS WAF para inspeção completa da camada HTTP. O Origin Access Control (OAC) garante que apenas o CloudFront possa acessar a origem S3, substituindo recursos mais antigos do Origin Access Identity (OAI). A política de bucket do S3 é configurada para confiar em solicitações somente do CloudFront usando solicitações assinadas pelo OAC. Por que as outras opções estão incorretas: Opção A: o WAF ARN não é um principal na política de bucket do S3. O IAM não oferece suporte a políticas de bucket baseadas em ARNs do WAF. Opção B: Incorreto O CloudFront não "encaminha solicitações para o WAF"; em vez disso, o WAF está associado ao CloudFront e inspeciona as solicitações na borda. Opção C: S3 não usa grupos de segurança; eles são para interfaces EC2/rede. Isso mostra um mal-entendido sobre como o S3 funciona. Referência: Guia do desenvolvedor do Amazon CloudFront "Fornecendo conteúdo privado com OAC" Guia do desenvolvedor do AWS WAF "Protegendo o CloudFront com AWS WAF" Pilar de segurança do AWS Well-Architected Framework

Explicação: A prática recomendada da AWS para um aplicativo Web altamente disponível e resiliente é: Executar instâncias do EC2 em um grupo de Auto Scaling em várias zonas de disponibilidade. Coloque um Application Load Balancer (ALB) na frente do grupo Auto Scaling. Use alarmes e políticas de escalabilidade do CloudWatch para escalabilidade horizontal com base na demanda. A opção D implementa exatamente isso: um mínimo de três instâncias espalhadas por AZs (resiliência a falhas de AZ), atrás de um ALB, com escalonamento horizontal automático. Isso fornece elasticidade e alta disponibilidade com boa eficiência de custos (aumento/aumento de escala de instâncias com base no tráfego). A opção A usa apenas três instâncias fixas e depende do escalonamento vertical, que não é tão escalonável e é menos resiliente. A opção B provisiona excessivamente nove instâncias desde o início, o que é desnecessariamente caro. A opção C mantém todas as instâncias em uma única AZ, o que não atende aos requisitos de resiliência.

Explicação: O problema é a latência de expansão: quando o tráfego aumenta, novas instâncias demoram para serem iniciadas, inicializadas e aprovadas nas verificações de integridade. Isso pode degradar temporariamente a experiência do usuário, mesmo que o Auto Scaling acabe adicionando capacidade suficiente. O objetivo é melhorar a capacidade de resposta a picos repentinos de maneira econômica. Um recurso importante do Auto Scaling para essa situação é um pool quente do EC2 Auto Scaling. Um pool quente mantém um conjunto de instâncias pré-inicializadas (paradas ou em execução, dependendo da configuração) que o Auto Scaling pode fazer rapidamente a transição para o serviço. Isso reduz o tempo necessário para lançamento e inicialização da instância, permitindo uma expansão mais rápida durante picos inesperados. A opção B é melhor porque oferece suporte às necessidades de pico do aplicativo, garantindo que o Auto Scaling possa escalar até a capacidade máxima necessária e mantenha a capacidade quente pronta. Embora um pool quente tenha algum custo (especialmente se as instâncias forem mantidas em execução), normalmente é mais econômico do que executar permanentemente a capacidade máxima o tempo todo. Ele melhora a experiência do usuário, minimizando atrasos na inicialização a frio durante picos. A opção A é contraproducente: a redução da capacidade mínima aumenta a probabilidade de atrasos na expansão. A opção C é ilógica tal como está escrita ("aumentar o máximo para satisfazer a procura normal"); o máximo deve refletir o potencial de pico, e uma piscina quente sem espaço máximo suficiente não resolverá o problema do pico. A opção D usa escalabilidade programada, mas o pico é inesperado e o aumento do tamanho das instâncias aumenta o custo e não resolve o atraso na inicialização; também pode reduzir a flexibilidade de escala horizontal. Portanto, B é a maneira mais econômica de melhorar o desempenho de expansão e proteger a experiência do usuário durante surtos inesperados.