SOA-C02 Networking and Content Delivery Practice Question

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's security group does not allow HTTPS traffic from the internet.

  Why it's wrong here

  The exhibit clearly shows an inbound HTTPS (port 443) rule from 0.0.0.0/0 on the ALB's security group, so this statement is factually false. More importantly, this rule is for client-to-ALB traffic, which is unrelated to the ALB's ability to reach targets for health checks; those probes originate from the ALB and are filtered by the targets' security group. Even if this rule were absent, the only impact would be users failing to reach the load balancer over HTTPS, not the reported unhealthy targets.

• ✓

  The security group for the target instances does not allow HTTP traffic from the ALB's security group.

  Why this is correct

  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.

• ✗

  The ALB's security group does not allow HTTP traffic from the target's IP range.

  Why it's wrong here

  This statement inverts the traffic flow required for load balancer health checks. The ALB's security group governs inbound connections to the load balancer from clients, not outbound connections that the ALB initiates to targets; for health checks, the target instance's security group must permit HTTP from the ALB's security group or its VPC CIDR. Moreover, the exhibit already shows the ALB allowing HTTP from 10.0.0.0/16, but even that rule is irrelevant because the health check source is the ALB's private IP addresses, not the target's IP range. Thus, a missing inbound rule on the target side is the cause, not a missing rule on the ALB side.

• ✗

  The health check is configured to use HTTPS, but the target only supports HTTP.

  Why it's wrong here

  The health check configuration shown in the exhibit explicitly uses HTTP on port 80, matching the target group's protocol and port, so there is no HTTPS-to-HTTP mismatch. Even if HTTPS were used, the failure would typically be due to the target not presenting a trusted certificate or not listening on 443, neither of which is applicable here. The actual issue is that the target instances' security group is filtering the ALB's health check probes, causing them to fail at the network layer before any TLS handshake or HTTP request could occur.

Go deeper

Related to this question