AWS DOP-C02 Practice Exam — Simulado AWS Certified DevOps Engineer Professional — questões e gabarito

Explicação: "Observe que o filtro de métrica é diferente de uma consulta de insights de log, onde a experiência é interativa e fornece resultados de pesquisa imediatos para o usuário investigar. Nenhuma ação automática pode ser invocada a partir de uma consulta de insights. Os filtros de métrica, por outro lado, gerarão dados métricos na forma de uma série temporal. Isso permite criar alarmes que se integram aos seus processos de ITSM, executar funções do AWS Lambda ou até mesmo criar modelos de detecção de anomalias." https://aws.amazon.com/blogs/mt/quantify-custom-application-metrics-with-amazon-cloudwatch-logs-and-metric-filters/

Explicação: Esta solução atenderá aos requisitos porque usará pilhas aninhadas e conjuntos de pilhas do CloudFormation para implantar os modelos de maneira mais eficiente e consistente em várias regiões. As pilhas aninhadas permitem que a empresa separe componentes comuns e reutilize modelos, enquanto os conjuntos de pilhas permitem que a empresa crie pilhas em várias contas e regiões com um único modelo. A empresa também pode usar o Amazon SNS para enviar notificações à equipe de engenharia de dados sempre que for feita uma alteração nos modelos ou nas pilhas. Amazon SNS é um serviço que permite publicar mensagens para assinantes, como endereços de e-mail, números de telefone ou outros serviços da AWS. Ao usar o Amazon SNS, a empresa pode garantir que a equipe de engenharia de dados esteja ciente de todas as alterações nos modelos e possa tomar as medidas adequadas, se necessário. O que é Amazon SNS? - Serviço de notificação simples da Amazon

Explicação: O engenheiro deve fazer as seguintes alterações para obter uma política de permissão mínima: A: Adicione uma condição para garantir que o principal que faz a solicitação seja uma função do AWS Lambda. Isso garante que apenas funções do Lambda possam executar esta política. B: Limite os recursos especificando o ARN das instâncias do EC2 em vez de permitir todos os recursos. Isso garante que a política afete apenas as instâncias do EC2. D: Adicione uma condição para garantir que esta política se aplique apenas a instâncias EC2 marcadas com "Ambiente: Não Produção". Isto garante que os ambientes de produção não sejam afetados por esta política. : AWS Identity and Access Management (IAM) - AWS Documentation Certified DevOps Engineer - Professional (DOP-C02) Guia de estudo (página 179)

Explicação: O Amazon Redshift oferece suporte ao registro de auditoria que pode ser configurado para registrar atividades do usuário, incluindo consultas e alterações do usuário. Os logs podem ser entregues em um bucket S3 (opção B), que é o local padrão para logs de auditoria do Redshift. Embora o Redshift possa enviar alguns logs para o CloudWatch, o log de auditoria nativo normalmente é roteado para o S3. A criação de um painel do CloudWatch com um widget de log (opção D) permite a visualização das atividades do usuário a partir de logs ingeridos no CloudWatch Logs ou por meio de processamento personalizado. A opção A é inválida porque o CloudTrail não captura logs de consulta do Redshift diretamente. A opção C assume incorretamente que os logs de auditoria do Redshift podem ser entregues diretamente ao CloudWatch. A opção E adiciona complexidade ao exigir Lambda e Athena desnecessariamente quando a visualização direta no CloudWatch é mais simples. Referências: Amazon Redshift Audit Logging Visualização de logs com painéis do Amazon CloudWatch

Explicação: O principal problema descrito é a inconsistência de implantação e a falta de confiabilidade causadas pelo uso do AWS Systems Manager Run Command para implantação de aplicativos. O Run Command executa comandos ad hoc e não fornece orquestração de implantação, rastreamento de versão, ganchos de ciclo de vida ou controle de tráfego baseado em integridade, o que geralmente leva a desvios entre instâncias do EC2. A solução nativa da AWS mais confiável é adotar o AWS CodePipeline combinado com o AWS CodeDeploy. A opção B introduz um pipeline de CI/CD estruturado com um estágio de construção claro seguido por um estágio de teste, garantindo que apenas os artefatos testados progridam para implantação. Os estágios sequenciais de construção e teste são preferidos para confiabilidade e comportamento determinístico, especialmente quando os resultados dos testes devem restringir as implantações. A opção C é essencial porque o AWS CodeDeploy é o serviço projetado especificamente para implantar revisões de aplicativos de forma consistente em frotas EC2. Ao criar um aplicativo CodeDeploy e um grupo de implantação e integrá-lo ao ALB, as implantações ganham suporte para eventos de ciclo de vida, verificações de integridade, sincronização de instâncias e reversão automática. Isso garante que todas as instâncias do EC2 recebam a mesma versão do aplicativo e que o tráfego seja gerenciado com segurança durante as implantações. A opção A introduz paralelismo desnecessário que não aborda a questão central. A opção D adiciona complexidade excessiva com orquestração Lambda. A opção E substitui incorretamente CodeArtifact por S3 sem abordar a confiabilidade da implantação. Portanto, combinar CodePipeline (B) com CodeDeploy e integração ALB (C) fornece implantações consistentes, repetíveis e confiáveis ​​alinhadas com as práticas recomendadas da AWS.

Explicação: A seguir estão as etapas que o engenheiro de DevOps deve seguir para reduzir a latência da função Lambda em todos os momentos do dia: Configure a simultaneidade provisionada na função Lambda. Configure o AWS Application Auto Scaling na função Lambda com valores de simultaneidade provisionados definidos como mínimo de 1 e máximo de 100. A configuração de simultaneidade provisionada garante que sempre haja um número mínimo de instâncias de função do Lambda disponíveis para lidar com solicitações. A configuração do Application Auto Scaling aumentará ou diminuirá automaticamente o número de instâncias da função Lambda com base na demanda do aplicativo. Esta solução garantirá que a função Lambda seja capaz de lidar com o aumento de carga durante o meio do dia, ao mesmo tempo que mantém baixa a latência de inicialização a frio. A seguir estão os motivos pelos quais as outras opções não estão corretas: A opção A está incorreta porque não reduzirá a latência de inicialização a frio da função Lambda. A opção B está incorreta porque não aumentará ou diminuirá o número de instâncias da função Lambda com base na demanda. A opção D está incorreta porque configurará apenas a simultaneidade reservada na API API Gateway, o que não afetará a função Lambda.

Explicação: https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting-deployments.html#troubleshooting-skipped-lifecycle-events

Explicação: https://aws.amazon.com/about-aws/whats-new/2016/09/aws-codedeploy-introduces-deployment-monitoring-with-amazon-cloudwatch-alarms-and-automatic-deployment-rollback/

Explicação: Para agregar eventos de diversas contas em uma única conta, o barramento de eventos padrão na conta receptora (DevOps) deve ter uma política baseada em recursos que permita que as contas de origem coloquem eventos nele. Em seguida, uma regra do EventBridge em cada conta de origem roteia eventos do Amazon Connect para o barramento de eventos padrão na conta DevOps (entrega de eventos entre contas). As opções A e B descrevem políticas ou regras que aplicam permissões ou roteamento incorretamente. A opção D menciona permissões de reprodução, que não estão relacionadas ao roteamento de eventos. Referências: Políticas baseadas em recursos de entrega de eventos entre contas EventBridge para barramentos de eventos

Explicação: Os principais objetivos da empresa são produzir compilações diárias, publicar artefatos em um site hospedado no Amazon S3 e fazer isso com o mínimo de sobrecarga operacional. Como o repositório de origem é público e as compilações são produzidas em uma programação diária fixa, não há necessidade de orquestração complexa em vários estágios ou invocações manuais de pipeline. A opção B fornece a solução mais simplificada e recomendada pela AWS. Ao usar o AWS CodeBuild diretamente com o repositório público como fonte, a empresa elimina completamente a necessidade de gerenciar um AWS CodePipeline. O CodeBuild pode compilar nativamente o projeto e publicar artefatos de construção diretamente em um bucket do Amazon S3 por meio de sua configuração de artefatos. Isso minimiza as dependências de serviço e a complexidade operacional. Usar uma regra agendada do Amazon EventBridge para acionar o projeto CodeBuild diariamente garante que as compilações ocorram automaticamente sem intervenção manual. Habilitar a criptografia de artefatos é a prática recomendada da AWS, mesmo para artefatos públicos, porque a criptografia em repouso não impede o acesso público de leitura quando as políticas de bucket permitem. A opção A depende de webhooks e gatilhos baseados em push, que não atendem ao requisito de “construir todos os dias” e introduzem acoplamento desnecessário à atividade do repositório. As opções C e D mantêm o CodePipeline, o que adiciona sobrecarga extra de configuração e manutenção sem fornecer valor adicional para esse fluxo de trabalho simples de criação e publicação. Portanto, a Opção B atende a todos os requisitos com o mínimo esforço operacional, ao mesmo tempo que segue os princípios de design de CI/CD recomendados pela AWS.