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.

• ✗

  Keep the existing rule that allows inbound HTTP from 0.0.0.0/0, but add a network ACL to block traffic from the internet.

  Why it's wrong here

  Keeping the existing security group rule that accepts HTTP from 0.0.0.0/0 while trying to add a network ACL that blocks internet traffic is ineffective because network ACLs are stateless and require explicit allow rules for both inbound and the ephemeral port range used for return traffic. More importantly, a NACL that blocks 'internet traffic' cannot distinguish between traffic from an ALB node and traffic from any other source, so it either blocks all inbound traffic (including the load balancer's) or leaves a hole that already allows direct access to the instance. This approach also fails to restrict access to only the ALB, so the instance remains directly reachable from the internet whenever the NACL permits, and it unnecessarily adds subnet-wide filtering complexity.

• ✓

  Modify the EC2 security group to allow inbound HTTP from the ALB's security group.

  Why this is correct

  Referencing the ALB's security group as the source in the EC2 instance security group creates a highly precise trust boundary: only traffic originating from network interfaces associated with that ALB security group is permitted, so direct internet access to the instance is impossible. Because the rule references the security group ID rather than any IP address, it automatically follows the ALB's elastic network interfaces as the load balancer scales or moves between Availability Zones, requiring no manual updates. This leverages the stateful nature of security groups — return traffic is automatically allowed — and it is the documented, recommended pattern for application load balancer to target communication.

• ✗

  Modify the EC2 security group to allow inbound HTTP from the ALB's private IP addresses.

  Why it's wrong here

  Using the ALB's private IP addresses is not scalable because an Application Load Balancer is a regional, distributed service that dynamically provisions multiple ENIs across Availability Zones, and those private IP addresses can change whenever the ALB scales out, scales in, or an Availability Zone is added or removed. You would be forced to continuously discover and update a potentially long list of CIDR entries as the ALB topology changes, and any stale entry would cause intermittent connection failures when traffic arrives from a node whose IP is no longer listed. The security group reference — which resolves to the ALB's current ENIs — is the only dynamic way to grant access without manual IP management.

• ✗

  Modify the EC2 security group to allow inbound HTTP from the ALB's public IP addresses.

  Why it's wrong here

  Application Load Balancers, unlike classic 'web' load balancers or NAT instances, are not assigned stable public IP addresses; internet-facing ALBs are reached through a public DNS name that resolves to the IP addresses of the currently attached ENIs, and those public IP addresses can be rotated by AWS. Restricting the instance security group to those ephemeral public IPs is both unreliable — the IPs may change without notice — and semantically wrong, because ALB-to-instance traffic flows over private IPs inside the VPC even for an internet-facing ALB. Moreover, you cannot enumerate a static set of public IP addresses for a modern ALB, so this rule would break whenever the DNS resolution changes.

Go deeper

Related to this question