DOP-C02 Incident and Event Response Practice Question
A company runs a containerized application on Amazon ECS with Fargate launch type. The application is behind an Application Load Balancer (ALB). The operations team notices that the ALB's 5xx error rate increases periodically. The ECS service is configured with a target tracking scaling policy based on CPU utilization. The CloudWatch logs from the application show no errors. The health check on the ALB is configured to hit the /health endpoint. What is the MOST likely cause of the 5xx errors?
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 health check endpoint is returning a 503 status due to a dependency failure.
The ALB periodically reports 5xx errors because the health check endpoint /health is returning a 503 status code, likely due to a transient dependency failure. When the health check fails, the ALB considers the target unhealthy and returns a 503 (or 502) to clients. The application code itself logs no errors because the failure occurs in a downstream dependency that the health check probes, not in the main application logic. Option A is incorrect because ECS with Fargate does not expose underlying host patching; the ALB would not detect such patching as 5xx errors. Option C is incorrect because a target tracking CPU scaling policy, even if slow, would not cause 5xx errors—it would affect performance but not directly trigger health check failures. Option D is incorrect because the application logs show no errors, ruling out unlogged exceptions as the source.
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 tasks are running on an underlying host that is being patched.
Why it's wrong here
This is incorrect because the application is running on AWS Fargate, which fully abstracts the underlying compute instances. Host patching is an AWS-managed activity that occurs without any impact to task placement or health, and there is no user-accessible host for the ECS tasks to be 'running on' during a patch. Even with the EC2 launch type, a patched host would be drained via instance state changes before termination, causing the ALB to deregister targets gracefully rather than synthesize a 503 solely from the patching event.
- ✓
The health check endpoint is returning a 503 status due to a dependency failure.
Why this is correct
This is the correct explanation because the ALB health check probes the configured endpoint and expects a successful status code, and a 503 returned by that endpoint indicates the application's dependency (for example, a database or downstream API) is unavailable. When the health check receives 503 for all tasks, the ALB marks the targets unhealthy and stops routing traffic, ultimately returning HTTP 503 to clients. The symptom therefore matches the health check failure, not an application exception or scaling issue.
- ✗
The target tracking scaling policy is not responding quickly enough to traffic spikes.
Why it's wrong here
This is incorrect because a target tracking scaling policy operates on CloudWatch metric thresholds and adjusts the desired task count asynchronously, with inherent cooldown and evaluation periods. A slow scale-out might cause increased latency or resource saturation, but it does not directly make the ALB return 503; the ALB returns 503 only when there are no healthy targets in the target group. In practice, if tasks become overloaded they may fail health checks, but the root cause is still those tasks failing the health check, not the scaling policy itself.
- ✗
The application is throwing exceptions that are not logged.
Why it's wrong here
This is incorrect because unlogged exceptions in the application would typically manifest as HTTP 500 Internal Server Error responses, not 503 Service Unavailable. Furthermore, the statement that logs show no errors rules out this cause, and health checks would still succeed as long as the exception is contained within a request handler rather than causing the process to crash or the health endpoint to fail. A 503 implies a deliberate status code from the health check or ALB, not an unhandled exception in the application code.
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.