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 Amazon ECS service with a rolling update deployment controller

  Why it's wrong here

  ECS rolling update replaces tasks in the service incrementally with new task definitions, but the ALB continuously sends real user traffic to the service throughout, so there is no separate blue/green environment to route between. This lacks the ability to test the new version at a small traffic percentage or perform an immediate rollback without redeploying the old task definition. It also doesn't integrate with CodeDeploy's deployment lifecycle hooks or automatic rollback based on alarms.

• ✗

  Create two separate ECS services and use Route 53 weighted routing to shift traffic

  Why it's wrong here

  Using two separate ECS services with Route 53 weighted routing requires manual coordination of your pipeline to create and drain services, and it relies on DNS TTLs that clients and resolvers cache, resulting in stale traffic cutover. DNS-based weighting also cannot factor in real-time target health or listener rules, and it doesn't provide the granular, instantaneous traffic shifts that an Application Load Balancer's target group weights offer. Furthermore, this design duplicates service management and lacks CodeDeploy's automatic rollback and lifecycle hooks, making it a complex, non-integrated alternative.

• ✗

  Use AWS CloudFormation with a custom resource to swap target group weights

  Why it's wrong here

  A CloudFormation custom resource backed by a Lambda function could mutate an ALB listener's forward action, but constructing and maintaining that resource adds operational overhead and still requires your pipeline to separately implement health checks, deployment waiting, and rollback logic. CodeDeploy, on the other hand, natively provides these deployment mechanics with configurable linear or canary shifts and automatic rollback on failed health checks. Custom resources are intended for provisioning-time operations, not for orchestrating ongoing deployment flows, so this approach is ultimately brittle and hard to observe.

• ✓

  Use CodeDeploy with an ECS compute platform and an Application Load Balancer

  Why this is correct

  CodeDeploy with an ECS compute platform natively manages blue/green deployments by creating a new task set, installing it into a preconfigured green target group, and then incrementally shifting the ALB's production listener weight from the original to the new target group based on a Canary or Linear deployment configuration. The service integrates with a specified AppSpec file to run pre- and post-traffic validation hooks, and you can attach CloudWatch alarms that trigger automatic rollback if the new version misbehaves. This is the purpose-built mechanism that owns the entire traffic-shifting lifecycle, from creating the replacement task set to deregistering the old one, without resorting to custom code.

Go deeper

Related to this question