DOP-C02 Resilient Cloud Solutions Practice Question
A company runs a containerized microservices architecture on Amazon ECS with Fargate. The services communicate via an internal Application Load Balancer. Recently, a new deployment of Service A caused its health checks to fail. The DevOps engineer notices that the old tasks remain running and the service is unavailable. What configuration change would prevent this issue in future deployments?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Set the deployment minimum healthy percent to 50 and maximum percent to 100 with a health check grace period
Setting the deployment minimum healthy percent to 50 and maximum percent to 100 ensures that during a rolling update, at least 50% of the tasks remain healthy, and the deployment will not continue if the new tasks fail health checks, preserving service availability. Option B is incorrect because the circuit breaker can roll back on failure, but 'disable rollback' negates that; it's a misconfigured setting. Option C is not a configuration change for this issue; CodeDeploy is a separate service used for blue/green deployments, not a direct fix for health check failures during rolling updates. Option D is incorrect because setting minimum healthy percent to 0 and maximum percent to 200 allows all old tasks to be stopped before new ones start, causing downtime if health checks fail, as there are no healthy tasks to serve traffic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Set the deployment minimum healthy percent to 50 and maximum percent to 100 with a health check grace period
Why this is correct
With min healthy percent 50 and max percent 100, the ECS rolling deployment will keep half of the existing tasks running while starting replacements at 100% capacity; the deployment only substitutes tasks that pass the health check, so a misconfigured health check in the new task definition will fail the new tasks without ever reducing service capacity below 50%. The health check grace period further shields new tasks from being killed during their initial startup window before the container is ready, preventing a false failure from a slow start. This combination preserves an always-available old task pool until the new tasks are fully verified.
- ✗
Set the deployment circuit breaker to rollback on deployment failure and disable rollback
Why it's wrong here
Enabling the ECS deployment circuit breaker and setting it to rollback will indeed revert to the last successful task set when the new deployment is unhealthy, but it only reacts after the failure has already occurred; it does not prevent the health checks from failing or the service from briefly serving unhealthy tasks. Additionally, the prompt asks for a configuration that prevents the issue, and disabling rollback would actually force an unrecoverable failed deployment rather than restoring service. Because the circuit breaker is a recovery mechanism, not a preventive safeguard against misconfigured health checks, it leaves the root cause untouched.
- ✗
Change the deployment controller from ECS to CodeDeploy for blue/green deployments
Why it's wrong here
Switching the ECS deployment controller to CodeDeploy blue/green replaces the rolling update with a parallel blue/green flow where the entire new task set is created before any traffic is shifted. While this isolates the old environment during the health check window, the new green task set will still run the same misconfigured health check and likely fail the deployment, and CodeDeploy will not automatically correct an application-level health check flaw. Moreover, this approach changes the deployment topology rather than tuning how task survival and health check assessment behave, so it does not address the underlying cause of the health check failure.
- ✗
Set the deployment minimum healthy percent to 0 and maximum percent to 200
Why it's wrong here
Setting min healthy percent to 0 and max percent to 200 tells ECS it may stop all old tasks before the new tasks are fully healthy, so a health check failure in the new task definition will tear down the entire service with nothing left to serve traffic. Even with max percent 200, the controller can place replacement tasks at 200% momentarily, but it is also free to scale the old task count to zero before the new tasks become stable if the deployment algorithm deems it necessary. This configuration maximizes availability risk and invalidates the safety of an automatic rollback, as no healthy tasks remain to form a fallback task set.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 251 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.