DOP-C02 Sample Questions

DOP-C02 sample questions, correct option bolded, with a full explanation for each.

A company is replacing manual production releases of its Lambda application with an automated pipeline. AWS CodeDeploy publishes the new Lambda version behind Amazon API Gateway. The release policy requires that no more than 10% of production traffic reach the new version for a 5-minute wait period, automated alarms must be able to trigger rollback during that period, and the release must finish within 10 minutes. Which deployment configuration should the pipeline use?

• AllAtOnce deployment configuration with automatic rollback on test alarm
• Canary10Percent15Minutes deployment configuration with automatic rollback on test alarm
• Linear10PercentEvery1Minute deployment configuration with automatic rollback on test alarm
• Canary10Percent5Minutes deployment configuration with automatic rollback on test alarm

This is correct because the canary-10%-5-minute option holds the new version at 10% of production traffic for the required 5-minute wait period, lets the automated alarm roll back during that window, and then finishes the release within the 10-minute deadline. The linear-10%-every-minute option also starts at 10%, but it begins increasing traffic every minute, so it cannot provide a 5-minute low-traffic observation period. The all-at-once option exposes 100% of traffic immediately, so it defeats the blast-radius constraint even if rollback later occurs. The canary-15-minute option satisfies the 10% blast radius but exceeds the required completion window. Use the deployment configuration's traffic-shift increment and wait time to match the stated blast radius and release window, and use CloudWatch alarms to automate rollback without a human in the loop.

A bad release caused an outage. CloudWatch Logs show a recurring stack trace, and the error-rate metric crosses its alarm threshold whenever this bad revision is deployed. On-call engineers notice the trace by eye and manually roll back the deployment. The team wants to automate this response in the deployment pipeline. Which solution enforces the control with the LEAST operational overhead?

• Attach the existing CloudWatch alarm to the pipeline's CodeDeploy deployment group and enable automatic rollback when the alarm state is ALARM.
• Create an EventBridge rule for the alarm's state change that runs a Systems Manager Automation runbook to stop and roll back the deployment.
• Use the existing CloudWatch alarm as the action that sends the metric state to an SNS topic and pages the on-call engineer.
• Add a manual approval action to CodePipeline that requires the on-call engineer to confirm the rollback whenever the alarm fires.

Attaching the existing alarm to the deployment group and turning on automatic rollback is correct because CodeDeploy is already the deployment pipeline and natively monitors the alarm; when the metric shows the bad release, it rolls back without a human or custom automation. The EventBridge and Systems Manager Automation option also enforces the control, but it requires writing and maintaining a custom runbook and IAM plumbing, so it has more operational overhead. The manual approval option reintroduces the human step, and the SNS option only notifies; neither enforces the control. Prefer native deployment-lifecycle enforcement over custom event automation when the qualifier is operational overhead.

An organization uses AWS CodePipeline to deploy a log-shipping agent. The deploy stage starts a CodeDeploy deployment in each of 40 accounts, each with a deployment group for that account's EC2 fleet. Each account has a CloudWatch alarm that tracks the rate of log events accepted by the agent. The team wants the least operational overhead solution that automatically rolls back an account's fleet if the alarm enters ALARM during that account's deployment. Which CodeDeploy configuration should be used?

• In each account, add the existing CloudWatch alarm to its CodeDeploy deployment group and enable automatic rollback when the alarm is triggered.
• In each account, create an Amazon EventBridge rule that redeploys the previous agent revision whenever the account alarm enters ALARM.
• Consolidate all 40 accounts into a single CodeDeploy deployment group and enable automatic rollback on a central CloudWatch alarm.
• Keep per-account deployment groups, enable rollback on deployment failure, and add a lifecycle hook that fails if the alarm is ALARM after startup.

This is correct because CodeDeploy can monitor a CloudWatch alarm attached to a deployment group and automatically roll back when that alarm is triggered, so the existing per-account health signal becomes a native rollback trigger with no custom code. The lifecycle-hook option is the strongest distractor because it could also fail a deployment and roll it back, but it requires writing and maintaining a custom hook to evaluate the alarm, which is more operational overhead. The EventBridge rule option is another custom mechanism that replaces a managed feature with a redeploy rule. The single deployment group option fails because CodeDeploy deployment groups are scoped to one account and region and cannot target EC2 fleets in 40 accounts. The general rule is to use the deployment service's native alarm-based rollback rather than building a custom detection-and-redeploy path.

After a bad production deploy, a database password appeared in a CloudFormation template and in CodePipeline logs. The company uses one pipeline to deploy the same template to many accounts. The CISO mandates that a secret value never appear in a template or pipeline artifact, and that compliance be checked automatically for every deployment. Which solution satisfies this with the LEAST operational overhead?

• Run CloudFormation Guard in a CodeBuild stage with rules that reject hard-coded secret-like strings and require Secrets Manager dynamic references; fail the pipeline and send an SNS notification on violation.
• Enable Amazon Macie automated sensitive-data discovery on the S3 bucket that stores CodePipeline artifacts, and deliver all findings to AWS Security Hub for compliance reporting.
• Create a custom AWS Config rule with Lambda in each target account that checks stack templates for secret values and triggers SSM Automation to delete non-compliant stacks.
• Store all application credentials in AWS Secrets Manager, grant only the pipeline service role read access by ARN, and enable automatic rotation so any leaked value stops working quickly.

The CloudFormation Guard option is correct because it is a proactive policy gate: it inspects the template before deployment, rejects literal secret-like values, and requires Secrets Manager dynamic references, so the actual secret value is kept out of the template and later pipeline stages. The custom AWS Config rule is the strongest distractor because it looks like automated compliance, but it evaluates stacks only after deployment; by then the secret has already appeared in the template and pipeline artifact, which violates the 'never appear' requirement. The Secrets Manager-only option is good practice but has no compliance check or reporting, and the Macie option is after-the-fact detection. The general rule is that an absolute 'never appear' constraint requires a proactive build-time policy gate, not post-hoc detection or remediation.

A company uses CloudFormation StackSets to provision an account baseline that applies mandatory tags to every resource. The baseline stack must call an external CMDB and pass an API token stored in AWS Secrets Manager. Corporate policy requires that the secret value never appear in the IaC template, in pipeline code, or in pipeline logs. Which approach meets this requirement with the least operational overhead?

• Use a CodeBuild stage to read the secret from Secrets Manager and pass the returned value to StackSets as a CloudFormation parameter.
• Create a Lambda-backed custom resource that retrieves the secret from Secrets Manager and exposes it to the stack with a custom resource attribute.
• Put the token in an encrypted CodeBuild environment variable and substitute its value into the StackSet template as a parameter during deployment.
• Add a CloudFormation dynamic reference to the secret in the StackSet template and grant the StackSets execution role permission to read it.

This is correct because a CloudFormation dynamic reference places only the secret's identifier in the template; CloudFormation resolves the value from AWS Secrets Manager at deployment time, so neither the template nor the pipeline code and logs ever contain secret material. The CodeBuild retrieval-and-parameter option is the strongest distractor because it is a common pattern, but the retrieved token is carried through the pipeline as a parameter, violating the policy. The Lambda custom resource approach can also avoid putting the value in the pipeline and template, but it adds a Lambda function and custom resource to operate, so it is not the least operational overhead. The rule that generalises is: for secrets in infrastructure as code, prefer native dynamic references to Secrets Manager over custom secret-fetching steps.

An operations team whose incident response is entirely manual wants to replace it with an automated image lifecycle for patching Windows instances across dev, test, and prod accounts. Patches must be validated in test, then promoted to prod as exactly the same artifact; a rebuild in any later stage makes the test result meaningless. Which solution meets this requirement with the least operational overhead?

• Build the AMI once in a central account with EC2 Image Builder; after the test stage passes, distribute the tested AMI to all accounts and update launch templates.
• Run the same AWS CodePipeline in test and prod; each pipeline invokes EC2 Image Builder from the same source recipe, then points its account's launch template at the resulting AMI.
• Use a Systems Manager Automation runbook to patch a test instance, create an AMI from it, copy that AMI to prod, and update the prod Auto Scaling group's launch template.
• Create a separate EC2 Image Builder pipeline in dev, test, and prod accounts using identical recipes and pipeline definitions, and tag each output AMI with its recipe version.

This is correct because the central EC2 Image Builder option builds once, runs its test stage, and then distributes that same tested AMI to every environment, so production never runs a separately built image. The strongest distractor is the Systems Manager Automation runbook: it also promotes an unchanged AMI and would satisfy the artifact requirement, but it requires the team to operate and maintain the patched instance, runbook, AMI copy, and template update, so it is not the least operational overhead. The separate-pipeline options fail because identical recipes are not identical artifacts; each build is a separate run and can pull different package or component versions. The general rule is to promote one immutable image from a single build through all environments, never rebuild during promotion, and use the managed build/distribution service where possible.

An online retailer runs Java microservices as containers on Amazon ECS with the EC2 launch type. Incident response is manual, so engineers want end-to-end traces in AWS X-Ray. Deployments use CodePipeline and CloudFormation, and security requires secrets never appear in pipeline definitions or CloudFormation templates. Which tracing setup is the MOST secure?

• Create an IAM user, store its access key in a Systems Manager Parameter Store SecureString, and use the task definition secrets field.
• Add a task IAM role to the ECS task definition and run the X-Ray daemon as a sidecar so it uses that role.
• Create an IAM user, store its access key in AWS Secrets Manager, and use the ECS task definition secrets field for the daemon.
• Attach the AWS X-Ray managed policy to the container instance role and run the X-Ray daemon on each container instance.

This is correct because the ECS task IAM role is not a secret, so no credential value exists in the CodePipeline definition or CloudFormation template. The X-Ray daemon gets temporary credentials from the ECS task role through the default credential chain. The Secrets Manager and SecureString options keep the literal key out of the pipeline and template, but they still depend on long-lived IAM-user access keys, which must be stored, retrieved, and rotated. The container-instance-role option also avoids secrets but is broader than the task-role option because every task on that instance shares the instance role. The general rule is to prefer IAM roles over stored credentials for AWS-integrated workloads, using Secrets Manager or Parameter Store only when there is no IAM-role alternative.

A company's CodePipeline pipeline deploys a service to an Auto Scaling group using CodeDeploy with a linear deployment strategy that shifts 10% of traffic every five minutes. The on-call team watches a CloudWatch dashboard during the shift and manually cancels the deployment if the p99 latency exceeds 250 ms. Management wants the release to be reversed automatically on that same latency signal with the least operational overhead. What should the team configure?

• Send the p99 latency alarm to an SNS topic that notifies the on-call engineer to roll back the deployment manually.
• Add the p99 latency CloudWatch alarm to the CodeDeploy deployment group and enable automatic rollback when the alarm is triggered.
• Configure the CodeDeploy deployment group to roll back automatically whenever any deployment lifecycle event fails on an instance during the deployment.
• Create an EventBridge rule on the alarm that invokes a Lambda function to stop the deployment and redeploy the previous application revision.

This is correct because CodeDeploy can treat a CloudWatch alarm as a rollback trigger on the deployment group; when the p99 latency alarm enters ALARM during the linear traffic shift, CodeDeploy fails the deployment and automatically deploys the last known good revision. That uses the same defined health signal and avoids any human step. The strongest distractor is the EventBridge/Lambda answer: it also automates on the alarm, but it means building and operating custom code, so it is not the least operational overhead. The SNS answer still requires a person to act, and the lifecycle-event failure answer rolls back only on installation/health-check failures, not on the p99 latency signal. General rule: when a CI/CD service offers a native automated rollback trigger on the same health signal, choose it over custom automation for the least operational overhead.

After a bad production deployment, a company is setting up its next CodeDeploy blue/green rollout for the checkout service. They can detect faults immediately with AWS X-Ray, and a CloudWatch alarm on the checkout fault rate exists. No operator will be available during the rollout. What should they do to ensure the rollout is reverted with the LEAST operational overhead?

• Use the SNS action on the alarm to have the on-call engineer roll back the deployment manually.
• Set up a Step Functions rollback runbook to start automatically when the CloudWatch alarm enters ALARM.
• Use the alarm to trigger a Lambda function that starts a CodeDeploy deployment with the previous revision.
• Add the existing CloudWatch alarm to the CodeDeploy deployment group and enable automatic rollback for that group.

The option that adds the existing CloudWatch alarm to the CodeDeploy deployment group and enables automatic rollback is correct because CodeDeploy will monitor that alarm during deployment and automatically stop and roll back the deployment without a human. The SNS-to-on-call-engineer option is the strongest distractor because it is a common alarm response, but it fails the explicit constraint that no operator is available. The Lambda and Step Functions options are automatic, but they create extra custom components to build and maintain, so they are not the LEAST operational overhead. The general rule is to prefer the deployment service's native alarm-triggered rollback before building a custom runbook.

See exam format, exam objectives, practice test.

Exam facts on this page come from Amazon Web Services’s own pages (official exam page). Prices, versions and policies change — confirm there before you book.