DOP-C02 Resilient Cloud Solutions Practice Question
A company runs a production application on Amazon ECS with Fargate, fronted by an Application Load Balancer (ALB). The application experiences periodic latency spikes and occasional 502 errors. The ECS service is configured with a desired count of 2 tasks, and the ALB health check is set to /health with a 30-second interval and 2 consecutive failures threshold. The team uses CloudWatch Container Insights and has noticed that CPU and memory utilization of tasks remain below 50%. However, the ALB TargetGroup's HealthyHostCount metric occasionally drops to 0 for a few minutes before recovering. The deployment strategy is rolling update with a minimum healthy percent of 50% and maximum percent of 200%. The team recently updated the task definition to increase memory and CPU, but the issue persists. What is the MOST likely cause of the problem?
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
✓
The ALB health check is too aggressive, causing tasks to be marked unhealthy during brief initialization or deployment.
The health check interval (30 seconds) and failure threshold (2) mean it takes up to 60 seconds to mark a task unhealthy. During deployments, the rolling update may temporarily have only 1 healthy task (minimum 50% of 2 = 1), and if that task becomes unhealthy, HealthyHostCount drops to 0. Option A is wrong because CPU and memory are below 50%, so resource limits are not the issue. Option C is wrong because a target group with 2 tasks and 2 AZs is fine; the problem is not AZ-specific. Option D is wrong because ECS service-linked role does not affect health checks.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The ECS service role lacks permissions to register targets with the ALB.
Why it's wrong here
The ECS service-linked role does not affect health checks; permissions to register targets are automatically granted by default.
- ✓
The ALB health check is too aggressive, causing tasks to be marked unhealthy during brief initialization or deployment.
Why this is correct
The health check interval (30 seconds) and failure threshold (2) mean it takes up to 60 seconds to mark a task unhealthy. During deployments, the rolling update may temporarily have only 1 healthy task (minimum 50% of 2 = 1), and if that task becomes unhealthy, HealthyHostCount drops to 0.
- ✗
The ALB target group is configured with only one Availability Zone, causing loss of all targets when that AZ fails.
Why it's wrong here
A target group with tasks in multiple Availability Zones is standard; the scenario does not indicate a failure of a single AZ.
- ✗
The task's CPU or memory limits are set too low, causing the container to be throttled.
Why it's wrong here
CPU and memory utilization are below 50%, so resource limits are not causing throttling or health check failures.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 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.