A SysOps administrator is troubleshooting an application that runs on EC2 instances behind an ALB. Users report intermittent 503 errors. The administrator checks the ALB access logs and finds entries with 'elb_status_code' 503 and 'target_status_code' '-'. What is the most likely cause?
When every instance in a target group fails consecutive health checks, the ALB marks them unhealthy and has no target to forward client traffic to. Instead of proxying a 5xx error from an overloaded backend, the load balancer itself responds with 503 Service Unavailable because the service is deemed unreachable. The health check interval and threshold settings determine how quickly an unhealthy target is removed from rotation, but the client sees 503 until at least one target passes.
Why this answer
The ALB access log entry with `elb_status_code` 503 and `target_status_code` '-' indicates that the load balancer itself generated the 503 error because it could not establish a connection to any healthy target. The dash for the target status code means the request never reached a target instance, which occurs when all targets in the target group are marked unhealthy by the health checks. This is the most common cause of intermittent 503 errors with an ALB.
Exam trap
The trap here is that candidates often confuse a 503 error with target-side issues (like high CPU or application errors), but the dash in the target_status_code is the key indicator that the ALB itself is rejecting the request due to no healthy targets, not that the request reached a target and failed.
How to eliminate wrong answers
Option B is wrong because an expired SSL certificate on the ALB would cause TLS handshake failures (e.g., 502 or 525 errors), not a 503 with a dash for the target status code. Option C is wrong because high CPU utilization on target instances would still allow the ALB to forward requests to them (resulting in a target_status_code like 200 or 500), but the dash indicates no connection was attempted. Option D is wrong because the ALB's security group controls inbound traffic to the load balancer; if it were blocking traffic, clients would receive a 504 or connection timeout, not a 503, and the access log would show a different elb_status_code.