SOA-C02 Networking and Content Delivery Practice Question

A company hosts a web application on EC2 instances behind an Application Load Balancer. Users report intermittent 503 errors. Which step should the SysOps administrator take to troubleshoot the issue?

⚠ Common exam trap

Many candidates confuse 503 errors with timeout or capacity issues and jump to increasing idle timeout or adding subnets, rather than recognizing that 503 errors from an ALB almost always point to target health check failures.

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

✓

Verify the target group health check settings.

Intermittent 503 errors from an Application Load Balancer typically indicate that the target instances are failing health checks or are unable to handle the request load. Verifying the target group health check settings (e.g., path, interval, threshold, and protocol) is the first troubleshooting step because if the health checks are misconfigured or the targets are unhealthy, the ALB will stop routing traffic to them, resulting in 503 responses.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Verify the target group health check settings.
Why this is correct
The 503 Service Unavailable response from an Application Load Balancer specifically indicates that the target group contains no registered instances that are passing health checks. Health check settings, such as the configured path, expected HTTP success codes, interval, timeout, and unhealthy threshold, directly determine whether EC2 instances are marked healthy or unhealthy. If the health check path returns a non-2xx status due to an application misconfiguration, or if the health check port is blocked by a security group, all targets can be flagged unhealthy, triggering a 503. Verifying and correcting these settings is the first and most effective remediation step.
✗
Enable cross-zone load balancing.
Why it's wrong here
Cross-zone load balancing affects how traffic is distributed across healthy targets in multiple Availability Zones, not whether those targets are considered healthy. Even with cross-zone load balancing enabled, the ALB will still return a 503 if every target in the target group fails its health check. This option addresses load distribution and capacity utilization but has no influence on the health state registration or the health check evaluation process that determines target eligibility.
✗
Increase the idle timeout on the load balancer.
Why it's wrong here
The idle timeout on an Application Load Balancer controls how long the load balancer keeps a connection open when no data is transmitted, which is relevant for long-lived HTTP connections that may need a larger timeout for activities such as file uploads or streaming. A 503 error is generated during the request routing phase when no healthy targets are available to handle the request, not because of a connection being dropped due to inactivity. Increasing the idle timeout would not change the underlying health status of the EC2 instances and therefore cannot resolve the Service Unavailable response.
✗
Add more subnets to the load balancer.
Why it's wrong here
Adding more subnets to the load balancer improves its availability by allowing it to scale across additional Availability Zones, but this does not repair the health check status of the existing registered targets. If the current targets are unhealthy, the ALB still has zero eligible targets in its target group, so any request from any subnet will result in a 503. The root cause is target-level health, not the load balancer's network footprint; thus, expanding subnets is a distraction from the actual issue.

Go deeper

SOA-C02 Networking and Content Delivery Practice Question

Why each option matters

Option-by-option breakdown

Related to this question