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 a Lambda function in CodePipeline to manually adjust weights in Route53.

  Why it's wrong here

  This approach would require you to write and maintain a custom Lambda function that manipulates Route 53 weighted DNS records, effectively hand-rolling a traffic-shifting engine. It bypasses CodeDeploy's native deployment lifecycle, so you lose automatic health checks, failure detection, and rollback capabilities. CodePipeline's Lambda invocation can trigger the function, but it is purely a custom workaround and not a managed deployment strategy — it's complex, error-prone, and outside the recommended deployment pattern.

• ✓

  Use CodeDeploy with a canary deployment configuration in the Deploy to Prod stage.

  Why this is correct

  CodeDeploy is the AWS-native service designed for controlled software rollouts, and its canary deployment configuration is fully supported as a CodePipeline deploy action. For example, a configuration like Canary10Percent5Minutes shifts 10% of traffic to the new task set or instance fleet, waits five minutes, then shifts the remaining 90%, while monitoring health via lifecycle hooks. Because CodeDeploy owns the traffic-shifting logic, it automatically detects failures, stops the deployment, and can roll back to the previous version. This directly satisfies the requirement for a built-in canary strategy in the Deploy to Prod stage with no custom scripting.

• ✗

  Use an Elastic Load Balancer to gradually shift traffic using weighted target groups.

  Why it's wrong here

  An Elastic Load Balancer can distribute traffic to multiple target groups, and you could theoretically alter the weights to inch traffic from an old fleet to a new one, but this is a purely manual, infrastructure-level control plane operation. The ELB itself has no knowledge of the application version, does not perform health checks tied to the deployment, and provides no integration with CodePipeline actions. You would have to orchestrate the weight changes with external automation, manage drift, and handle rollbacks yourself — it is not a CI/CD deployment mechanism and is totally disconnected from the pipeline's progress or validation gates.

• ✗

  Use CloudFormation with a canary update policy in the Deploy to Prod stage.

  Why it's wrong here

  CloudFormation's UpdatePolicy does provide a RollingUpdate strategy for Auto Scaling groups, but that is not the same as a canary deployment, and for Lambda there is no native canary update policy at all. To get canary-like behavior from CloudFormation, you would have to rely on a custom resource or trigger a CodeDeploy deployment from within a nested stack, which is indirect and redundant. CloudFormation is intended for infrastructure provisioning, not live traffic shifting between application versions, so using it in the Deploy to Prod stage would not give you the controlled percentage-based rollout the question asks for.

Go deeper

Related to this question