AWS Certified DevOps Engineer - Professional (DOP-C02) Practice Test

Explanation

This question is about creating a continuous, detective control for custom compliance rules across a multi-account environment. Why the AWS Config with CloudFormation StackSet approach is correct: This is the definitive solution for this use case. AWS Config is the service for assessing resource configurations. You can write custom rules (or use managed ones) to check for your specific corporate policies. Using a CloudFormation StackSet is the efficient way to deploy these rules consistently to all accounts. The AWS Config aggregator is the key to centralized reporting; it collects the compliance data from all accounts into a single dashboard, allowing the central IT team to monitor the entire organization from one place. Why other approaches are incorrect: The Service Control Policy (SCP) approach is a preventative control, not a detective one. It can stop the creation of new non-compliant roles but does not help identify or report on existing ones. The AWS Security Hub approach is a good baseline, but Security Hub's default standards might not perfectly match the company's specific, custom policies. AWS Config provides the necessary flexibility. The scheduled Lambda function approach is an inefficient, custom-built solution that relies on polling. The AWS Config approach is event-driven (for configuration changes) and provides a much richer, more manageable compliance framework.

Explanation

This is a classic use case for automated compliance and remediation using AWS management and governance tools. The best solution is to use AWS Config, which is designed for this type of compliance checking. You would use the cloudtrail-enabled managed rule to continuously check if CloudTrail is active. It's important to use a periodic trigger for this rule. Then, to create the automated response, you use Amazon EventBridge. You create a rule that is triggered specifically by an AWS Config rule compliance state change (i.e., when the cloudtrail-enabled rule becomes 'NON_COMPLIANT'). The target for this EventBridge rule would be an AWS Lambda function. The Lambda function's code would be very simple: it would receive the event details, identify the trail that is non-compliant, and use the AWS SDK to call the StartLogging API on that trail, effectively re-enabling it automatically. AWS Config rules do not have built-in, automatic remediation; you must configure it, typically with EventBridge and Lambda or SSM. AWS CDK is a framework for defining infrastructure, not a runtime monitoring tool. A Lambda function that polls every minute is less efficient and more costly than the event-driven approach using Config and EventBridge.

Explanation

This question is about designing a CI/CD process that respects the principle of separation of concerns for different artifacts (an AMI vs. infrastructure code). Why these are correct: Storing the Image Builder recipe and CloudFormation template in separate GitHub repositories is the foundation of a good decoupled process. By placing the AMI build configuration and the infrastructure code in separate repositories, you ensure that a change to one does not accidentally trigger a deployment of the other. It also allows for separate ownership and review processes. Creating a dedicated AWS CodePipeline triggered by commits to the Image Builder recipe repository correctly describes the pipeline for the AMI. This dedicated pipeline watches the AMI repository and uses CodeBuild to execute the image build process, producing a new AMI as its artifact. Establishing a second, independent AWS CodePipeline triggered by commits to the CloudFormation template repository correctly describes the pipeline for the infrastructure. This second, independent pipeline watches the CloudFormation repository. When a change is made to the template (e.g., updating the AMI ID parameter), this pipeline deploys the change. This decoupling is critical for stable operations. Why others are incorrect: Using a single GitHub repository for both the Image Builder recipe and CloudFormation template violates the decoupling requirement. A single repository would mean a change to the AMI recipe could trigger an infrastructure deployment, which is not desired. Configuring the infrastructure pipeline to receive the new AMI ID directly from the AMI pipeline's build action as a variable is incorrect because variables are scoped to a single pipeline execution. The second pipeline cannot directly access a variable from an execution of the first pipeline. The new AMI ID must be passed to the second pipeline through another mechanism, such as updating a parameter in the template file or storing it in SSM Parameter Store. Using a single, multi-stage AWS CodePipeline that first builds the AMI with CodeBuild and then deploys the CloudFormation stack violates the decoupling requirement by putting both processes into a single, monolithic pipeline.

Explanation

The key requirements are a managed service experience, support for the Go language, and native capabilities for blue/green deployments suitable for A/B testing. AWS Elastic Beanstalk is the most appropriate solution. It is a Platform as a Service (PaaS) that abstracts away the underlying infrastructure management. It has built-in support for applications written in Go. Most importantly, it has native support for blue/green deployments. You can easily clone your production (blue) environment to create an identical staging (green) environment. You can deploy your new application version to the green environment for testing. Once you are ready, you can perform a CNAME swap, which instantly redirects all production traffic to the new environment. This side-by-side architecture is perfect for A/B testing and provides a safe, zero-downtime deployment, all with minimal operational overhead. While CodeDeploy also supports blue/green, it requires you to manage the underlying infrastructure yourself, which increases the operational burden. EC2 instance refresh updates an existing environment; it doesn't create a parallel one for A/B testing. Lightsail is generally for simpler applications and lacks the sophisticated deployment features of Elastic Beanstalk.

Explanation

A strong DDoS mitigation strategy involves reducing the attack surface and using services that can detect and filter malicious traffic at scale. One key component is to use Amazon CloudFront as the entry point for your application. This places your application behind AWS's global edge network, which can absorb large-scale network-layer (Layer 3/4) attacks. For enhanced protection against more sophisticated application-layer (Layer 7) attacks, you should use AWS Shield Advanced. It provides advanced monitoring, detection, and mitigation, as well as access to the AWS DDoS Response Team (DRT). Another critical component is AWS WAF (Web Application Firewall). You can associate a WAF web ACL with your CloudFront distribution or Application Load Balancer. With WAF, you can create rules to filter traffic based on various criteria. This includes using rate-based rules to block sources that send an excessive number of requests, managed rule sets to block common attack patterns like SQL injection, and custom IP set match rules to block traffic from known malicious IP addresses. These two solutions work together to provide a comprehensive, layered defense. MFA is for authentication and does not prevent DDoS. Session Manager is for instance access. While Auto Scaling helps with availability, simply absorbing a large-scale attack is often not feasible or cost-effective without filtering the malicious traffic first.