AWS DOP-C02 Practice Exam — Simulado AWS Certified DevOps Engineer Professional

Explicação: A seguir estão as etapas que a empresa pode executar para alterar o nível de log dinamicamente quando a implantação ocorre: Crie um script que use a variável de ambiente CodeDeploy DEPLOYMENT_GROUP_NAME para identificar de qual grupo de implantação a instância faz parte. Use estas informações para definir as configurações de nível de log. Faça referência a esse script como parte do gancho do ciclo de vida BeforeInstall no arquivo appspec.yml. A variável de ambiente DEPLOYMENT_GROUP_NAME é definida automaticamente pelo CodeDeploy quando a implantação é acionada. Isso significa que o script não precisa chamar o serviço de metadados ou a API do EC2 para identificar o grupo de implantação. Esta solução é a menos complexa e requer menos sobrecarga de gerenciamento. Também não requer versões de script diferentes para cada grupo de implantação. A seguir estão os motivos pelos quais as outras opções não estão corretas: A opção A está incorreta porque exigiria a marcação das instâncias do Amazon EC2, o que seria um processo manual e demorado. A opção C está incorreta porque exigiria a criação de uma variável de ambiente personalizada para cada ambiente. Este seria um processo complexo e sujeito a erros. A opção D está incorreta porque usaria a variável de ambiente DEPLOYMENT_GROUP_ID. No entanto, essa variável não é definida automaticamente pelo CodeDeploy, portanto, o script precisaria chamar o serviço de metadados ou a API do EC2 para obter o ID do grupo de implantação. Isso adicionaria complexidade e sobrecarga à solução.

Explanation: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html

Explanation: https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html

Explanation: To restrict access to CloudFront to a specific IP address range: Create an AWS WAF IP address set with the corporate office IPs. Modify the existing WebACL's default action to Block (deny all except explicitly allowed). Add a high-priority rule that allows traffic from the IP address set (the corporate IPs). This way, only requests from the corporate IPs are allowed; all others are blocked. Regex pattern sets are not necessary for IP-based restrictions and add complexity. Setting default action to Allow with exceptions is less secure and more complex to manage. References: AWS WAF IP Set Examples Restricting Access by IP Address

Explanation: The requirement is to immediately detect and terminate EC2 instances involved in cryptocurrency mining with the least development effort. Amazon GuardDuty is the AWS-native service specifically designed to detect malicious activities such as crypto-mining by continuously analyzing CloudTrail events, VPC Flow Logs, and DNS logs. GuardDuty includes managed threat intelligence and predefined findings like CryptoCurrency:EC2/BitcoinTool.B!DNS and CryptoCurrency:EC2/BitcoinTool.B!IP, which directly identify mining behavior without custom detection logic. Option C leverages this built-in capability. Once GuardDuty is enabled, findings are automatically generated when mining activity is detected. These findings are sent to Amazon EventBridge in near real time. An EventBridge rule can filter for cryptocurrency-related findings and trigger an AWS Lambda function. The Lambda function can then identify the affected EC2 instance and terminate it or adjust the Auto Scaling group to replace it. This approach requires minimal custom code and no log parsing, scheduled jobs, or analytics pipelines. Options A and B rely on custom log analysis, periodic execution, and maintaining lists of mining domains or IPs, which significantly increases complexity and response time. Option D uses AWS Security Hub, which aggregates findings from GuardDuty and other services but is not intended for immediate, low-latency remediation. Therefore, Option C provides the fastest detection, immediate response, and lowest development overhead using AWS-managed threat detection services.