DOP-C02 Resilient Cloud Solutions Practice Question

An application on EC2 instances in an Auto Scaling group uses an ALB. The ALB health checks are failing for some instances, but the instances are healthy from the OS perspective. What is the most likely cause?

⚠ Common exam trap

DOP-C02 often tests whether candidates jump to scaling or timeout settings when the real issue is a security group rule blocking the ALB's health check traffic, so candidates must check network ACLs and security groups first.

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 security group for the instances does not allow traffic from the ALB

ALB health checks originate from the ALB's nodes and require the instance's security group to permit inbound traffic on the health check port and protocol from the ALB's security group. If the security group does not allow this traffic, the health check fails even though the OS and application are healthy. This is the most common cause of ALB health check failures when instances are otherwise reachable.

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 ALB idle timeout is too low
Why it's wrong here
The ALB idle timeout applies to idle connections between a client and the ALB, not to the health-check connections that the ALB opens to its targets. Health checks are short-lived, active probes, so they are never left idle long enough to be closed by the timeout. A misconfigured idle timeout could reset long-running user connections, but it would never cause the target to be marked unhealthy.
✓
The security group for the instances does not allow traffic from the ALB
Why this is correct
If the instance security group does not allow inbound traffic from the ALB's security group on the health-check port, the ALB's TCP or HTTP health-check probes are silently dropped. Because the instance never completes the health-check handshake, the target fails the required number of consecutive checks and the ALB marks it unhealthy. This is a classic misconfiguration that often appears right after adding the ALB, and it also blocks normal client traffic routed by the load balancer.
✗
The Auto Scaling group cooldown period is too short
Why it's wrong here
The Auto Scaling group cooldown period delays scaling actions triggered by CloudWatch alarms or manual scale events, not the processing of Elastic Load Balancing health check results. Health check failures reported by the ALB are immediately reflected in the target's state and, when an instance is marked unhealthy, ASG can replace it regardless of any cooldown period in effect. Cooldown would only postpone the next scaling activity, but it has no impact on why health checks fail.
✗
The ALB cross-zone load balancing is disabled
Why it's wrong here
Disabling cross-zone load balancing only changes how the ALB distributes client traffic among registered targets: each node sends traffic only to healthy targets in its own Availability Zone. Health checks, however, are performed against every registered target from each ALB node, independent of the cross-zone setting. Thus, a target can still be marked unhealthy when cross-zone is disabled, and the setting cannot be the cause of health check failures.

Go deeper

DOP-C02 Resilient Cloud Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question