SCS-C02 Infrastructure Security Practice Question

An organization has a VPC with public and private subnets. A NAT Gateway is deployed in a public subnet to allow instances in private subnets to access the internet. The security team notices that instances in a private subnet can reach the internet, but cannot initiate connections to an on-premises network connected via AWS Direct Connect. The on-premises network advertises a specific route. What is the most likely cause?

⚠ Common exam trap

SCS-C02 often tests the limitation that NAT Gateway only handles internet-bound traffic, tricking candidates into thinking a NAT route can reach on-premises — the correct next-hop for on-premises is always the VGW or TGW.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The private subnet route table has a route for the on-premises CIDR pointing to the NAT Gateway.

The most likely cause is that the private subnet's route table has a route for the on-premises CIDR pointing to the NAT Gateway instead of the Direct Connect virtual private gateway (VGW) or transit gateway. A NAT Gateway only translates traffic to the internet — it cannot forward traffic to on-premises networks, so the route is misdirected and the connection fails.

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 security group assigned to the instances does not allow outbound traffic to the on-premises network.
Why it's wrong here
Security groups are stateful, and their default outbound rule allows all traffic, so outbound connectivity to the on-premises network would not be blocked. Even if outbound rules had been customized, the response traffic for connections initiated by the instances would be automatically permitted because of statefulness. The actual failure occurs because the route to the on-premises CIDR is sent to a NAT Gateway, not because of security group filtering.
✗
The network ACL on the private subnet is blocking inbound traffic from the on-premises network.
Why it's wrong here
Network ACLs are stateless, so inbound rules do need to permit return traffic for connections initiated from the subnet. However, in this scenario the initial outbound packets from the instances are routed to the NAT Gateway instead of the Direct Connect connection, so they never reach the on-premises side; the connection fails before any return traffic would arrive. Thus, a NACL inbound block is not the root cause and adjusting it would not fix the problem.
✓
The private subnet route table has a route for the on-premises CIDR pointing to the NAT Gateway.
Why this is correct
Route tables in the VPC control where each destination CIDR is sent. If the private subnet route table contains a route for the on-premises CIDR pointing to the NAT Gateway, traffic destined for on-premises is sent to the NAT Gateway, which is designed only for internet-bound traffic and cannot forward it across the Direct Connect or virtual private gateway. Because the route to the NAT Gateway overrides the propagated Direct Connect route, the instances cannot reach on-premises resources. This is the correct root cause.
✗
The internet gateway is not attached to the VPC.
Why it's wrong here
An internet gateway is only used for traffic destined to the public internet and is required for public subnets to allow that traffic. Direct Connect traffic enters and exits the VPC through a virtual private gateway or transit gateway, not through an internet gateway. The absence of an internet gateway would have no effect on a private subnet's ability to reach on-premises resources over Direct Connect; the problem is the misrouting through the NAT Gateway.

Visual reference

Go deeper

SCS-C02 Infrastructure Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question