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 CloudFormation with a 'DeploymentPreference' set to 'BlueGreen' for the ECS service.

  Why it's wrong here

  AWS CloudFormation does not have a 'DeploymentPreference' property for ECS services; the 'DeploymentPreference' attribute is used only for Auto Scaling group rolling updates in CloudFormation. ECS service updates through CloudFormation trigger a standard rolling update with the service's 'minimumHealthyPercent' and 'maximumPercent' settings, not a blue/green deployment. To achieve blue/green on ECS, you must explicitly create a CodeDeploy DeploymentGroup, an ALB with separate blue and green target groups, and an ECS service configured for the CodeDeploy controller—CloudFormation cannot orchestrate the traffic shifting by itself.

• ✓

  Use AWS CodeDeploy with a deployment group configured for blue/green deployment, and an Application Load Balancer (ALB) to shift traffic between the blue and green target groups.

  Why this is correct

  AWS CodeDeploy natively supports blue/green deployments for ECS services when integrated with an Application Load Balancer. During deployment, CodeDeploy registers the new task set with a 'green' target group while the existing 'blue' task set remains registered with the original target group; the ALB listener's traffic is then shifted from blue to green using either a canary, linear, or all-at-once traffic-shifting configuration. CodeDeploy also runs lifecycle hooks (BeforeInstall, AfterInstall, etc.) and preserves the original task set for instant rollback if the deployment fails. This is the only option that provides immutable infrastructure and controlled traffic shifting, making it the correct answer.

• ✗

  Use the ECS service's built-in rolling update with a 'minimumHealthyPercent' of 100 and 'maximumPercent' of 200.

  Why it's wrong here

  This configuration performs a standard rolling update, not a blue/green deployment. With 'maximumPercent' set to 200, ECS is allowed to start new tasks with the updated task definition while the old tasks remain running, and 'minimumHealthyPercent' of 100 ensures capacity is never below 100% during the process; however, both old and new tasks are behind the same target group, so the ALB continues to send traffic to the service as a whole, and there is no separate green target group or listener rule to shift traffic. Unlike blue/green, this approach does not enable immediate rollback to the previous version—you must initiate another deployment to revert—and there is no isolation between versions for testing before production traffic is sent to the new tasks.

• ✗

  Configure the ECS service with an 'AutoScaling' policy that replaces instances gradually.

  Why it's wrong here

  The Amazon ECS Auto Scaling policy primarily adjusts the desired number of tasks based on CloudWatch metrics such as CPU, memory, or ALB request count; it does not deploy a new task definition or change the application version. Even if a scaling event launches new task instances, they run the current task definition, so the policy cannot gradually replace the service with a new version. Auto Scaling also lacks the ability to shift traffic between multiple versions or to rollback a failed release, because it does not orchestrate deployments or manage target groups; it simply adds or removes tasks from the existing service.

Go deeper

Related to this question