Refer to the exhibit. A security group is attached to an Application Load Balancer (ALB) that serves HTTPS traffic on port 443. Users can access the application via HTTPS. However, the ALB's health checks to targets on port 80 are failing. What is the reason?
This is correct because the ALB sends health check requests from its own network interfaces, using the ALB's security group as the source in the allowed inbound rule on each target. The target instance's security group must explicitly allow inbound TCP on the health check port (HTTP/80) from the ALB's security group ID (or from the VPC CIDR if the security group reference is not used). Without that rule, the OS receives the SYN packet but the security group silently drops it, so the health check times out and the target is marked unhealthy. This is the standard root cause for healthy-app-turned-unhealthy after an ALB change or when targets are in a different security group.
Why this answer
The ALB's security group allows inbound HTTPS from anywhere (0.0.0.0/0) on port 443, and inbound HTTP from the VPC CIDR (10.0.0.0/16) on port 80. Health checks originate from the ALB's private IP addresses, which are within the VPC CIDR. Therefore, the ALB's security group is correctly configured.
The health checks fail because the target instances' security group does not allow inbound HTTP traffic from the ALB's security group. When the target's security group lacks a rule permitting traffic from the ALB's security group, the health check requests are blocked. Option A is incorrect because the ALB's security group does allow HTTPS from the internet.
Option C is incorrect because the ALB's security group allows HTTP from the VPC CIDR, which includes the target's IP range. Option D is incorrect because health checks are configured on port 80 (HTTP), not HTTPS.