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.

• ✗

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

  Why it's wrong here

  An Internet Gateway (IGW) is a VPC-level virtual device attached to the VPC itself, not to a subnet or a route table. Route tables contain routes with gateway targets, but you cannot "add an IGW to a route table" as a direct action. Even if you were to create a route to the IGW for 0.0.0.0/0 in a private subnet, that would expose instances directly to inbound internet traffic, violating the isolation that a private subnet is designed to provide. The correct way to give a private subnet outbound-only internet access is via a NAT Gateway or NAT instance, not by inserting the IGW into the private subnet's routing.

• ✓

  Deploy a NAT Gateway in a public subnet.

  Why this is correct

  Deploying a NAT Gateway in a public subnet is correct because the NAT Gateway is a managed service that must reside in a subnet that has a route to an Internet Gateway (IGW). This placement enables the NAT Gateway to translate private IP addresses from instances in private subnets into its own Elastic IP address and forward traffic to the IGW for outbound connections. Because the NAT Gateway is in a public subnet, it can reach the internet and, at the same time, it does not accept inbound connections from the internet, preserving the security boundary. Its managed nature means you do not need to patch or operate it, and it automatically scales to handle bursts of traffic.

• ✗

  Assign a public IP address to the EC2 instance.

  Why it's wrong here

  Assigning a public IP address to an EC2 instance in a private subnet does not grant internet access because the private subnet's route table lacks a route to an Internet Gateway (IGW). Even if the instance has a public IP, its network interface cannot use it for direct internet connectivity without an IGW route present in the subnet's route table; the instance is isolated by design. In a private subnet, all internet-bound traffic is instead routed to a NAT Gateway, which performs source NAT and uses its own public IP. Therefore, assigning a public IP is futile and does not satisfy the requirement for outbound internet access from the private instance.

• ✗

  Attach an Internet Gateway to the NAT Gateway.

  Why it's wrong here

  An Internet Gateway (IGW) is attached to a VPC, not to individual AWS resources such as a NAT Gateway. Attempting to "attach" an IGW to a NAT Gateway is architecturally invalid because the NAT Gateway is a service that already uses the VPC's IGW indirectly through the routing table of the public subnet in which it resides. The correct relationship is that the public subnet's route table contains a route (0.0.0.0/0 → IGW), which allows the NAT Gateway to reach the internet; the IGW itself is never attached to the NAT Gateway as a target or device. This misconception often arises from misunderstanding the role of an IGW as a VPC component rather than a per-resource attachment.

• ✓

  Add a route in the private subnet's route table pointing to the NAT Gateway for 0.0.0.0/0.

  Why this is correct

  Adding a route in the private subnet's route table that points 0.0.0.0/0 to the NAT Gateway is an essential configuration that enables instances in the private subnet to send outbound internet traffic. Without this route, even if a NAT Gateway exists in a public subnet, instances would have no path to the gateway and their internet-bound packets would be dropped or sent to a dead-end. This route directs all outbound IPv4 traffic to the NAT Gateway, which then performs Network Address Translation and forwards the traffic through the VPC's Internet Gateway. It is a fundamental step for private-instance internet access, and it does not open any inbound ports, so the instances remain protected from unsolicited inbound connections.

Go deeper

Related to this question