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.

• ✓

  Configure the security group for the application tier to allow inbound traffic from the web tier's security group.

  Why this is correct

  Configuring the application tier's security group to allow inbound traffic from the web tier's security group is the correct approach. This uses security group referencing, which lets you specify the web tier's security group ID as the source instead of a CIDR block. Because security groups are stateful, return traffic from the application tier is automatically permitted, and the rule dynamically tracks instance IPs, so autoscaling or instance replacements require no rule updates.

• ✓

  Ensure the web tier instances have a route to an Internet Gateway for user traffic.

  Why this is correct

  The web tier must have a route to an Internet Gateway (IGW) in its subnet's route table to receive user traffic from the internet. Even if the web instances have public IP addresses, without a 0.0.0.0/0 route pointing to the IGW, inbound packets from the internet will not be forwarded to them. Additionally, the IGW must be attached to the VPC and the route table must be associated with the public subnet where the web tier resides.

• ✗

  Use a network ACL on the private subnet to deny all inbound traffic except from the public subnet CIDR.

  Why it's wrong here

  Using a network ACL (NACL) on the private subnet to deny all inbound traffic except from the public subnet CIDR is flawed because NACLs are stateless. While the inbound rule would allow traffic from the web tier, the corresponding outbound rule would still need to explicitly allow return traffic to the web tier, otherwise responses are dropped. More importantly, NACLs operate at the subnet level and don't provide instance-level filtering; a security group referencing the web tier's SG offers simpler, stateful, and more granular control.

• ✗

  Add a route to the Internet Gateway in the private subnet's route table.

  Why it's wrong here

  Adding a route to the Internet Gateway in the private subnet's route table is incorrect because it would make the private subnet effectively public, exposing the application tier to unsolicited internet traffic. Private subnets are intentionally isolated from direct internet routing; outbound internet access should be achieved via a NAT gateway or NAT instance located in a public subnet. Direct IGW routing would also require public IPs on the application instances, which defeats the purpose of a private tier and increases the attack surface.

• ✗

  Assign public IP addresses to the application tier instances for outbound access.

  Why it's wrong here

  Assigning public IP addresses to the application tier instances is unnecessary and poses a security risk. For outbound internet access—such as downloading patches or calling external APIs—the application tier should use a NAT gateway in a public subnet rather than having its own public IPs. Public IPs would expose the application instances directly to the internet, undermining the multi-tier isolation model and allowing potential inbound attacks on the application tier's services.

Go deeper

Related to this question