ALB Health Check Timeout Causing 503 Errors
A company runs a critical application on Amazon EC2 instances behind an Application Load Balancer (ALB). The application experiences intermittent errors where some requests return HTTP 503 (Service Unavailable) errors. The developers have verified that the application code is healthy and the EC2 instances pass health checks. The ALB health check is configured to hit a specific endpoint (/health) with a healthy threshold of 2 and an unhealthy threshold of 2. The health check interval is 30 seconds, and the timeout is 5 seconds. The application's /health endpoint sometimes takes up to 6 seconds to respond due to a dependency on a third-party service. The developers want to minimize the 503 errors without changing the application code. Which action should the developer take?
Quick Answer
The correct action is to increase the health check timeout to 10 seconds. This resolves the ALB health check timeout causing 503 errors because the current 5-second timeout is too short for the /health endpoint, which occasionally takes up to 6 seconds to respond due to a third-party dependency. When the timeout expires, the ALB marks the instance as unhealthy, and after the unhealthy threshold of 2 is reached, it stops routing traffic, resulting in 503 errors. On the AWS Certified Developer Associate DVA-C02 exam, this scenario tests your understanding of how health check parameters—timeout, interval, and thresholds—interact with application latency. A common trap is to adjust the interval or unhealthy threshold, but those changes would either increase load or make instances appear unhealthy faster, worsening the problem. Remember the memory tip: “Timeout first, not threshold”—always match the timeout to the slowest expected response before tweaking other settings.
⚠ Common exam trap
The trap is that candidates might think decreasing the unhealthy threshold or interval would help, but those actions would make the situation worse; the key is to match the timeout to the application's response time.
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
✓
Increase the health check timeout to 10 seconds to accommodate the slow /health endpoint.
Increasing the health check timeout to 10 seconds allows the /health endpoint to respond within the timeout period, preventing the ALB from marking the instance as unhealthy due to a slow response. Since the endpoint sometimes takes up to 6 seconds, a 5-second timeout is too short, causing health checks to fail intermittently. By increasing the timeout, the health checks will succeed, and the ALB will not remove the instance from service, thus reducing 503 errors.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Increase the health check timeout to 10 seconds to accommodate the slow /health endpoint.
Why this is correct
The /health endpoint can take six seconds, exceeding the five-second timeout, so the ALB marks instances unhealthy and returns 503s. Raising the timeout to ten seconds lets the health check succeed, keeping instances in service without code changes.
- ✗
Decrease the unhealthy threshold to 1 so that instances are marked unhealthy after one failed health check.
Why it's wrong here
Lowering the unhealthy threshold to 1 marks an instance unhealthy after a single timed-out health check, removing it from rotation and worsening 503s. It is tempting because aggressive thresholds speed up failure detection, but the 5-second timeout cannot accommodate the 6-second /health response regardless of threshold.
- ✗
Increase the deregistration delay to 300 seconds to allow connections to drain.
Why it's wrong here
Deregistration delay only drains in-flight connections when an instance is removed from the target group; it does nothing while the instance stays registered. It is tempting because it reduces 503s during scale-in or deployments, but here the timeout of 5 seconds against a 6-second /health response is the actual cause.
- ✗
Decrease the health check interval to 10 seconds to detect health changes faster.
Why it's wrong here
Shortening the interval increases how often the 5-second timeout fires against a /health endpoint that needs 6 seconds, marking targets unhealthy sooner and producing more 503s. It is tempting because faster detection helps when instances fail abruptly, but the mismatch between timeout and response time is the real fault.
Go deeper
Related to this question
About these practice questions
One of 1,135 original DVA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on DVA-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An application running on Amazon EC2 instances behind an Application Load Balancer (ALB) is experiencing intermittent 503 errors. The EC2 instances are in an Auto Scaling group. What is the MOST likely cause?
easy- A.The SSL certificate on the ALB has expired.
- ✓ B.The target group health checks are failing.
- C.The ALB DNS name is not resolving.
- D.The security group for the ALB is blocking traffic.
Why B: The intermittent 503 errors indicate that the ALB temporarily has no healthy targets to forward requests to. When target group health checks fail, the ALB marks instances as unhealthy and stops routing traffic to them, causing a 503 response if all instances are unhealthy. This aligns with the Auto Scaling group potentially launching new instances that haven't passed health checks yet, or existing instances failing health checks due to application overload or misconfiguration.
Variation 2. A web application running on Amazon EC2 instances behind an Application Load Balancer (ALB) is experiencing intermittent 503 errors. Which TWO steps should be taken to diagnose the issue?
easy- A.Check the Route 53 health checks for the domain.
- ✓ B.Check the CPU utilization of the EC2 instances.
- ✓ C.Check the target group health check settings and instance health status.
- D.Check the security group rules for the ALB.
- E.Check the EBS volume type of the EC2 instances.
Why B: High CPU utilization on EC2 instances can cause them to become unresponsive or fail to respond to health checks within the ALB's configured timeout, leading to 503 errors. The ALB routes traffic only to healthy targets; if instances are overwhelmed, they may fail health checks or drop requests, resulting in a 503 response to clients.
Variation 3. A company runs a Node.js application on Amazon EC2 instances behind an Application Load Balancer (ALB). Users report intermittent 503 errors. The ALB target group health checks are failing. The developer checks the EC2 instance logs and sees no application errors. What is the MOST likely cause?
hard- A.The health check path is set to '/' but the application serves on a different path.
- B.The EC2 instances are running out of memory.
- C.The health check path returns a 5xx status code due to a missing dependency.
- ✓ D.The security group for the EC2 instances does not allow inbound traffic from the ALB.
Why D: When an ALB target group's health checks fail, the ALB will return HTTP 503 (Service Unavailable) errors to clients because there are no healthy targets to route traffic to. If the developer checks the EC2 instance logs and sees no application errors (or no connection attempts at all), it indicates that the health check requests are not even reaching the application. This is typically caused by a security group misconfiguration where the EC2 instances' security group does not allow inbound traffic from the ALB's security group. Option C is incorrect because if the application returned a 5xx status code, the request would have reached the Node.js application, and the error or access attempt would be recorded in the logs.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DVA-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 DVA-C02 exam.