SOA-C02 Monitoring, Logging, and Remediation Practice Question

A company has an Auto Scaling group of EC2 instances behind an Application Load Balancer. The SysOps administrator notices that the healthy host count is lower than expected. The instances are in service, and security groups allow traffic. What is a likely cause?

⚠ Common exam trap

Candidates often assume a low healthy host count is always due to network-level issues (security groups or registration), but the question explicitly states instances are 'in service' and security groups allow traffic, pointing to an application-level health check failure like a 503 response.

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 health check path is returning HTTP 503.

A health check path returning HTTP 503 (Service Unavailable) indicates that the target instances are reachable but the application is failing to respond correctly. The Application Load Balancer (ALB) marks instances as unhealthy when the health check receives any non-2xx or non-3xx response, which reduces the healthy host count even though the instances are in service and security groups are properly configured.

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 instances are not registered with the target group.
Why it's wrong here
If the EC2 instances were not registered with the target group, they would never appear as healthy or receive traffic. The scenario explicitly states the instances are InService, which means they are successfully registered and have passed the initial registration state. A lack of registration would prevent the load balancer from routing any requests, but it would not produce a health check failure—the instances simply wouldn't be in the target group's rotation.
✗
The security group for the load balancer does not allow inbound traffic.
Why it's wrong here
The load balancer's security group controls client-to-LB traffic, and if it blocked inbound requests, clients would be unable to connect to the application at all. However, health checks are sent from the load balancer to the instances using the instance security group, not the LB's security group. Since the issue is specifically that instances are failing health checks, and clients can still reach the LB (otherwise the problem would be on the client side), the LB's inbound SG rule is irrelevant to the health check failure.
✓
The health check path is returning HTTP 503.
Why this is correct
An HTTP 503 Service Unavailable response from the health check endpoint indicates the target is reachable but the application cannot serve the request. Elastic Load Balancing health checks treat any non-2xx or non-3xx status code as unhealthy, so a 503 will cause the instance to be deregistered from service. This is a common issue when the health check path points to a resource that requires authentication or returns an error when the backend is overloaded.
✗
The target group is not associated with the load balancer.
Why it's wrong here
If the target group were not associated with the load balancer, the load balancer would have no forwarding rule pointing to it, and instances in that target group would never be probed or receive traffic. The instances are described as InService, which requires an active association between the Application Load Balancer and the target group so that health checks are actually performed. Thus, this option contradicts the given state and cannot explain the failure.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question