DVA-C02 Deployment 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.

• ✗

  Create a new ECS task definition with a different CPU/memory allocation.

  Why it's wrong here

  Creating a new ECS task definition, even with different CPU/memory allocations, defines the blueprint for how containers run, but it does not inherently control traffic shifting between different application versions. A task definition specifies container images, resource limits, and network modes, serving as a template for tasks. It is not a mechanism for managing the deployment strategy or routing client traffic from an old version to a new one.

• ✓

  Use CodeDeploy to perform a canary deployment that shifts 10% of traffic initially.

  Why this is correct

  Using CodeDeploy to perform a canary deployment is the correct approach for gradually shifting traffic to a new application version in ECS. CodeDeploy integrates with ECS and an Application Load Balancer (ALB) to manage two target groups (one for the old task set, one for the new). It progressively updates the ALB listener rules to route a specified percentage of traffic, like 10% initially, to the new version, allowing for controlled rollout and easy rollback.

• ✗

  Configure the target group to route traffic to a specific task set.

  Why it's wrong here

  Configuring a target group to route traffic to a specific task set is insufficient for percentage-based traffic shifting between application versions. An Application Load Balancer (ALB) target group distributes incoming traffic evenly among all healthy registered targets (ECS tasks) within that group. To shift traffic between distinct versions, you typically need *two* separate target groups (one for the old version, one for the new) and a deployment controller like CodeDeploy to adjust the traffic distribution between them.

• ✗

  Use ECS service auto scaling to gradually increase the number of tasks.

  Why it's wrong here

  Using ECS service auto scaling to gradually increase the number of tasks manages the capacity of an existing service based on demand, not the controlled rollout of a new application version. Auto scaling adjusts the task count to maintain performance or cost efficiency for a single, deployed version of an application. It does not facilitate shifting traffic from an old version to a new, distinct version of the application.

Go deeper

Related to this question