SOA-C02 Monitoring, Logging, and Remediation Practice Question

An application running on Amazon EC2 instances behind an Application Load Balancer (ALB) is experiencing intermittent 5xx errors. CloudWatch metrics show that the ALB's 'HTTPCode_ELB_5XX_Count' is elevated. What is the MOST likely cause?

⚠ Common exam trap

Watch out — candidates often confuse 'HTTPCode_ELB_5XX_Count' (errors generated by the load balancer) with 'HTTPCode_Target_5XX_Count' (errors generated by the target), leading them to incorrectly assume the target is returning 5xx errors when the actual issue is a load balancer timeout.

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 load balancer is timing out waiting for a response from the target.

When the ALB's 'HTTPCode_ELB_5XX_Count' is elevated, it indicates that the load balancer itself is generating the 5xx error, not the target. The most common cause is that the load balancer is timing out while waiting for a response from the target instances, which occurs when the target takes longer than the configured idle timeout (default 60 seconds) to respond. This results in the ALB returning a 504 Gateway Timeout error, which is counted in the ELB 5xx metric.

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 target instances are returning HTTP 503 errors.
Why it's wrong here
The target instances returning HTTP 503 errors would be recorded in the HTTPCode_Target_5XX_Count metric, not the load balancer's own ELB 5xx count. A 503 from the target means the application itself is overloaded or unavailable, but the load balancer successfully received and forwarded that response; it is an application-level error, not a load balancer-generated timeout error.
✗
The target instances have high latency but are still responding.
Why it's wrong here
High latency alone does not produce a load balancer 5xx error unless the target fails to send its response before the idle timeout expires. If the target is still responding (even slowly) and completes within the configured timeout, the request succeeds and no error is logged. Exceeding the idle timeout is the direct cause, which is described by the correct answer.
✓
The load balancer is timing out waiting for a response from the target.
Why this is correct
When a target fails to send a complete HTTP response before the load balancer's idle timeout (default 60 seconds for Application Load Balancers), the load balancer terminates the connection and returns a 504 Gateway Timeout to the client. This 504 is generated entirely by the load balancer, so it appears in the ELB 5XX error metrics, not in the target instance's metrics. A common cause is a long-running application task that exceeds the idle timeout without sending interim data.
✗
Client requests are malformed and being rejected by the load balancer.
Why it's wrong here
Malformed client requests that are rejected by the load balancer produce HTTP 400 Bad Request responses, which are client-side (4xx) errors, not server-side 5xx errors. The load balancer validates HTTP headers and request-line syntax at the protocol level; if a request is malformed, it is rejected before any connection to the target is established, so the target never sees it and no ELB 5xx is emitted. This does not match the symptom of a 5xx error in ELB metrics.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question