DOP-C02 Incident and Event Response Practice Question
Exhibit
Refer to the exhibit. ``` 2024-03-15T10:00:00Z ERROR 500 GET /api/orders 2024-03-15T10:00:01Z ERROR 500 GET /api/orders 2024-03-15T10:00:02Z ERROR 500 GET /api/orders ... (repeated many times) 2024-03-15T10:05:00Z INFO 200 GET /api/health 2024-03-15T10:05:01Z ERROR 500 GET /api/orders ```
An application log excerpt shows repeated HTTP 500 errors for the /api/orders endpoint, with occasional successful health checks. The application runs on EC2 instances behind an ALB. What is the MOST likely cause of this pattern?
⚠ Common exam trap
A common mix-up: candidates confuse HTTP 500 errors with instance-level failures (like OOM or health check failures), but the key differentiator is that successful health checks prove the instances are operational, shifting the root cause to a failing backend dependency rather than the compute layer.
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 backend service that the /api/orders endpoint depends on is unavailable or failing.
The pattern of repeated HTTP 500 errors for /api/orders with occasional successful health checks strongly indicates that the backend service dependency (e.g., a database, cache, or another microservice) is intermittently failing or unavailable. HTTP 500 errors are server-side errors, meaning the application code is running but cannot complete the request due to a downstream failure. Successful health checks confirm the EC2 instances themselves are healthy and in-service, ruling out instance-level or ALB misconfiguration issues.
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 backend service that the /api/orders endpoint depends on is unavailable or failing.
Why this is correct
The HTTP 500 on /api/orders is generated by the application after the ALB successfully forwards the request, meaning the instance is reachable and the web server process is handling traffic. However, the /api/orders endpoint depends on a downstream service (e.g., database, internal microservice, cache) whose failure causes the application to throw an unhandled exception and return a 500. Health checks succeed because the configured health check path (typically /health or /) exercises simple connectivity and doesn't call the failing dependency, so the instance remains in service. This is a classic partial-failure scenario where the dependency, not the instance, is unhealthy.
- ✗
The EC2 instances are running out of memory and the application is crashing.
Why it's wrong here
If EC2 instances were running out of memory and the application were crashing, the application process would either terminate or become unresponsive, causing health check requests to time out or return connection-refused errors, not HTTP 200. Since the health checks explicitly return 200, the application is alive and able to process inbound requests on the health path. Additionally, a crash-level OOM would prevent the ALB from getting any HTTP response for /api/orders, not a well-formed 500 error generated by the application's exception handler. The 500s indicate the application is executing code and failing on a specific operation, which is characteristic of a dependency failure rather than resource exhaustion.
- ✗
The ALB is misconfigured and routing requests to the wrong target group.
Why it's wrong here
An ALB misconfiguration that routes requests to the wrong target group would cause all traffic for that listener (including health checks and /api/orders) to hit the incorrect backing instances. However, the health checks are tied to the target group's registered instances, and if the ALB sent health checks to the wrong target group, those health checks would reflect the actual health of that unintended group; they still return 200, meaning the configured target group is healthy and correctly targeted. Furthermore, if the ALB were sending /api/orders to a wrong target group that doesn't host the service, the response would be a 404/503 from the ALB itself or a connection error, not an HTTP 500 generated by the application. The application-level 500 proves the request reached the correct application code, ruling out listener-level misrouting.
- ✗
The EC2 instances are not passing health checks and are being deregistered from the target group.
Why it's wrong here
Instances failing health checks are automatically deregistered from the target group, and the ALB stops sending them new requests, so they cannot produce HTTP 500 responses to live traffic. Since the log shows repeated HTTP 500 errors from /api/orders, traffic is still being forwarded to the backend instances, which means they are passing health checks and are in-service. The stated health check result of 200 directly contradicts this option, as the ALB would mark the instances unhealthy and remove them from rotation long before they could emit a 500. The 500s are coming from the application code after routing, not from an unhealthy/deregistered instance being unreachable.
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.