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.

• ✗

  Delete the existing service and recreate it with the new task definition

  Why it's wrong here

  Deleting an existing Amazon ECS service immediately terminates all running tasks associated with it, making the application unavailable to users. Recreating the service, even with the new task definition, requires time for the new tasks to be provisioned, started, and become healthy before they can serve traffic. This process inherently introduces a significant period of downtime, making it unsuitable for minimizing service interruption during deployments.

• ✓

  Configure the ECS service to use a blue/green deployment with CodeDeploy

  Why this is correct

  Configuring the ECS service for blue/green deployment with AWS CodeDeploy is a robust strategy for minimizing downtime. CodeDeploy provisions an entirely new set of tasks (the "green" environment) running the updated application version alongside the existing "blue" environment. Once the new tasks pass health checks, CodeDeploy atomically shifts traffic from the old environment to the new one, ensuring users experience no interruption and providing an easy rollback mechanism if issues arise.

• ✗

  Update the target group health check settings to a more lenient threshold

  Why it's wrong here

  Modifying the target group health check settings to be more lenient, such as increasing the unhealthy threshold or decreasing the healthy threshold, primarily affects how quickly unhealthy tasks are removed or how long new tasks take to be considered healthy. While it might slightly speed up a task's initial readiness or prevent premature termination, it does not fundamentally alter the deployment process itself or prevent downtime if tasks are stopped before new ones are ready to handle traffic. This action doesn't address the core mechanism of minimizing service interruption during an update.

• ✗

  Stop all running tasks and then start new tasks with the updated image

  Why it's wrong here

  Stopping all running tasks before initiating new ones with an updated image guarantees a period of complete service unavailability. During the interval when all old tasks are terminated and before the new tasks are fully provisioned, started, and registered as healthy with the load balancer, no application instances are available to serve user requests. This "stop-all-then-start-new" approach is a high-downtime deployment strategy, directly contradicting the goal of minimizing interruption.

• ✓

  Update the ECS service with a new task definition and set minimum healthy percent to 100 and maximum percent to 200

  Why this is correct

  Updating the ECS service with a new task definition and configuring `minimum healthy percent` to 100 and `maximum percent` to 200 enables a zero-downtime rolling update. With `minimum healthy percent` at 100, the service ensures that at least all current tasks remain healthy and serving traffic while new tasks are launched. `Maximum percent` at 200 allows the service to launch up to double the desired number of tasks, ensuring new tasks are fully operational and healthy before any old tasks are gracefully terminated, maintaining full capacity throughout the deployment.

Go deeper

Related to this question