Free Amazon Web Services DOP-C02 Practice Exam with Questions & Answers | Set: 5

AWS Config has a managed rule called alb-waf-enabled that checks whether AWS WAF is enabled on ALBs. AWS Config supports automatic remediation actions that can be triggered when noncompliance is detected.

By creating a Systems Manager Automation document that adds AWS WAF to the ALB and associating it as the remediation action for the AWS Config rule, the system can automatically detect and remediate any removal of AWS WAF from ALBs without manual intervention.

This is the most operationally efficient and reliable approach to ensure continuous compliance.

Option B lacks automatic remediation. Options C and D rely on drift detection and Lambda, which add complexity and risk downtime during stack replacement.

The requirement is classic attribute-based access control (ABAC): users should only access EC2 resources whose resource tag matches the user’s department attribute coming from IAM Identity Center (mapped into a principal/session tag like aws:PrincipalTag/department).

For EC2 resource authorization using tags, the correct pattern is to compare the EC2 resource tag condition key ec2:ResourceTag/department to the principal tag ${aws:PrincipalTag/department}. That is exactly what Option C does.

Why the other options are wrong:

A only checks that the tag key exists (aws:TagKeys) and does not enforce a match between user department and instance department.

B uses aws:ResourceTag/... rather than the EC2-specific tag key typically used for EC2 authorization decisions in EC2 actions (ec2:ResourceTag/...).

D restricts access to resources tagged as d1/d2/d3 but does not ensure the user can only access their own department.

The CfCT solution is designed for the exact purpose stated in the question. It extends the capabilities of AWS Control Tower by providing you with a way to automate resource provisioning and apply custom configurations across all AWS accounts created in the Control Tower environment. This enables the company to implement additional account customizations when new accounts are provisioned via the Control Tower Account Factory. The CloudFormation templates and SCPs can be added to a CodeCommit repository and will be automatically deployed to new accounts when they are created. This provides a highly automated solution that does not require manual intervention to deploy resources and SCPs to new accounts.

RDS Multi-AZ cluster deployments with cross-Region read replicas support near real-time replication (<1 min RPO) and fast promotion (<10 min RTO). Route 53 CNAME failover redirects application traffic automatically. This is the AWS-recommended DR pattern.

ALBs with Auto Scaling across AZs ensure high availability in each Region.

Aurora global database supports cross-Region read replicas with low latency for reads and is recommended for multi-Region high availability.

Route 53 latency-based routing sends users to the closest Region.

RDS without global database (Options B, D) has higher replication lag and less resilience.

Using CloudFront in front of ALBs (Options C and D) adds caching but is not required for latency-based routing and increases complexity.

Step 1: Reacting to CloudFormation Stack Events with EventBridgeAWS CloudFormation emits events during the lifecycle of a stack, including the UPDATE_COMPLETE event after a successful stack update. You can use Amazon EventBridge to detect this event and trigger a specific action (such as invoking a Lambda function).

Action: Create an EventBridge rule that listens for the UPDATE_COMPLETE event for the CloudFormation stack.

Why: EventBridge allows you to automatically detect CloudFormation stack lifecycle events and take action based on them.

Step 2: Invoking the Lambda FunctionAfter the EventBridge rule detects the UPDATE_COMPLETE event, it can invoke the pre-configured Lambda function to apply or update the tag on the specific CloudFormation stack instance.

Action: Configure the EventBridge rule to invoke the Lambda function when the UPDATE_COMPLETE event occurs.

Why: This automation ensures that the tag is applied immediately after a successful stack update without any manual intervention.

The requirement specifies enforcing encryption before CloudFormation creates or updates resources. This is key because preventive enforcement must occur during the provisioning workflow, not after resources already exist. AWS provides CloudFormation Hooks specifically for this purpose. A Hook allows an organization to intercept a CloudFormation stack operation and validate resource configurations before provisioning occurs. This feature is recommended by AWS for pre-deployment governance such as enforcing encryption policies, tag compliance, or security restrictions.

By enabling trusted access between CloudFormation StackSets and AWS Organizations, the Hook can be deployed centrally from the delegated administrator account across all accounts in the specified OU. Any attempt to create or update EBS volumes or SQS queues through CloudFormation is validated first by the Hook. If encryption is not configured, the operation fails immediately.

Option C (SCP) blocks API calls globally, but SCPs cannot perform conditional logic based on resource properties passed by CloudFormation prior to creation. Option B (AWS Config) detects violations after resources already exist, which does not satisfy “before stack operation.” Option D (Lambda remediation) also occurs after the resource is created.

Thus, CloudFormation Hooks distributed via StackSets provide the only solution that enforces compliance before the provisioning lifecycle

The correct solution is to add a report group in the AWS CodeBuild project buildspec file with the appropriate path and format for the reports. Then, create an Amazon S3 bucket to store the reports. You should configure an Amazon EventBridge rule that invokes an AWS Lambda function to copy the reports to the S3 bucket when a build is completed. Finally, create an S3 Lifecycle rule to expire the objects after 90 days. This approach allows for the automated transfer of reports to long-term storage and ensures they are retained for the required duration without manual intervention1.

AWS CodeBuild User Guide on test reporting1.

AWS CodeBuild User Guide on working with report groups2.

AWS Documentation on using AWS CodePipeline with AWS CodeBuild3.

The requirement is specifically to validate critical user journeys and API endpoints after each deployment and before routing traffic. The most direct AWS-native way to test “real” user flows and endpoints automatically is CloudWatch Synthetics canaries, which can run scripted checks (HTTP/API and browser-style journeys).

Option D minimizes operational overhead because it uses a straightforward managed pattern:

Canaries run against the new deployment to validate endpoints and journeys.

CloudWatch alarms trigger when the canaries fail (objective signal of broken journeys/APIs).

The solution then uses alarm-driven rollback (the intent here is automated rollback without writing custom analysis code or managing multi-service workflows).

Why the other options have more overhead or miss the “user journey/API validation” goal as cleanly:

A focuses on ECS task states (healthy/unhealthy tasks). That can detect deployment failures, but it doesn’t validate critical user journeys or API correctness. Also requires custom Lambda logic for analysis + rollback control.

B adds even more moving parts (Application Insights + alarms + EventBridge + Step Functions). Also, monitoring KPIs is not the same as explicitly validating journeys/endpoints before routing traffic.

C is the highest overhead: canaries plus X-Ray instrumentation across all microservices, trace exporting, custom Lambda analysis, etc. That’s heavy compared to canary + alarm.

So D best matches: “validate journeys/endpoints” + “automated detect + rollback” with least operational overhead by relying on managed canaries and alarms rather than custom code/workflows.

Creating an AWS CodeCommit repository for each project, using the main branch for production code, and creating a testing branch for code deployed to testing will meet the requirements. AWS CodeCommit is a managed revision control service that hosts Git repositories and works with all Git-based tools1. By using feature branches to develop new features and pull requests to merge code to testing and main branches, the developers can avoid code conflicts and lost work, and also implement code reviews and approvals. Option B is incorrect because creating another S3 bucket for each project for testing code and using an AWS Lambda function to promote code changes between testing and production buckets will not provide the benefits of revision control, such as tracking changes, branching, merging, and collaborating. Option C is incorrect because using the main branch for production and test code with different deployment pipelines for each environment will not allow the developers to test their code changes before deploying them to production. Option D is incorrect because enabling versioning and branching on each S3 bucket will not work with Git-based tools and will not provide the same level of revision control as AWS CodeCommit. References:

AWS CodeCommit

Certified DevOps Engineer - Professional (DOP-C02) Study Guide (page 182)