DOP-C02 SDLC Automation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use AWS Lambda to monitor health checks and trigger a rollback via the CodeDeploy API.

  Why it's wrong here

  This approach requires building and running a custom Lambda function, scheduled or event-driven, to poll or observe health-check endpoints, then manually calling the CodeDeploy BatchGetDeployments or CreateDeployment API to initiate a rollback. It is operationally heavy: you must provision Lambda permissions, handle retries, and ensure the health check itself doesn't cause false positives. CodeDeploy already provides native rollback triggers via CloudWatch alarms, so this only adds complexity and custom code where a built-in mechanism exists.

• ✓

  Configure the deployment group to roll back when a CloudWatch alarm is triggered.

  Why this is correct

  CodeDeploy deployment groups support a built-in automatic rollback option triggered by CloudWatch alarms. When you configure one or more alarms in the deployment group, CodeDeploy monitors them during the deployment (and during traffic shifting for blue/green) and, if any alarm enters the ALARM state, it automatically rolls back the deployment to the last known good revision. This is a native, first-class feature that tightly integrates with Amazon CloudWatch and requires no custom code or external services, making it the recommended and correct way to achieve automated rollback on detected failures.

• ✗

  Set up the deployment group to use blue/green deployment with traffic shifting.

  Why it's wrong here

  Blue/green deployment with traffic shifting is a deployment strategy, not a rollback mechanism. It can help reduce risk by gradually moving traffic from the old to the new version, but it does not, on its own, detect a failed or unhealthy deployment or automatically revert traffic. To get automatic rollback with blue/green, you still must explicitly configure a CloudWatch alarm in the deployment group's rollback settings; otherwise, if the new version misbehaves, the pipeline continues without reverting.

• ✗

  Configure the pipeline to have a manual approval step after deployment.

  Why it's wrong here

  A manual approval step inserted after the deployment stage in CodePipeline pauses the pipeline until a human approves or rejects the action. It does not automate rollback; it merely creates a manual gate where a human can decide whether to proceed or manually trigger a rollback through the console or CLI. Because it requires human intervention and does not monitor application health, it neither detects failures automatically nor reverts a bad deployment; it is a compliance/control step, not a rollback mechanism.

Go deeper

Related to this question