TL;DR: Walk the path outward: route table, NAT gateway, security group egress, NACL in both directions, then DNS. For IPv4 internet egress through a public NAT gateway, verify both the private-subnet route and the NAT subnet’s internet-gateway route. IPv6 outbound-only access can use an egress-only internet gateway instead.
How to approach it
Give an ordered checklist that follows the packet outward, and say why each step is where it is. The method is systematic elimination rather than recall: each hop either forwards the packet or drops it, and naming which one you have ruled out is the whole diagnosis.
A strong answer
A private subnet is defined by not having a route to an internet gateway. The following checklist assumes IPv4 egress through a public NAT gateway. Proxy, firewall and IPv6 architectures have different next hops; confirm the address family and intended path first.
1. The subnet's route table. Confirm there is a 0.0.0.0/0 route and that it targets a NAT gateway. A default route pointing at an internet gateway would make the subnet public, and without a default route, only destinations covered by more-specific routes are reachable. Also confirm this is the route table actually associated with this subnet, because an unassociated subnet silently uses the VPC's main route table, which usually lacks the NAT route. That association is a common miss.
2. The NAT gateway itself. It must be in a public subnet, meaning a subnet whose route table points 0.0.0.0/0 at an internet gateway, and it must have an elastic IP. A NAT gateway placed in a private subnet is the classic error: everything looks configured, and the gateway itself has no path out. Check its state is Available, since a failed NAT gateway does not remove the route.
3. Security groups. They are stateful, so allowing outbound is sufficient and return traffic is automatic. The default group allows all egress, but a hardened one may not, and an egress rule limited to port 443 will break an apt or yum update on port 80.
4. NACLs, both directions. Stateless, so an outbound allow is not enough: the return traffic arrives on an ephemeral port and needs its own inbound rule, typically 1024 to 65535. Blocking the return SYN-ACK prevents the TCP handshake from completing. Inspect NACL rules on both the instance and NAT subnets.
5. DNS. If the address does not resolve, nothing else matters. Check the configured resolver and enableDnsSupport for Amazon-provided DNS. Both DNS attributes are needed for private hosted zones and interface-endpoint private DNS; enableDnsHostnames is not a universal prerequisite for ordinary public DNS lookup. AWS DNS attributes.
Test each layer rather than reasoning about all of them: an HTTPS request to a known IP can test that destination without DNS, but TLS hostname validation and virtual hosting can still fail independently. Flow Log ACCEPT/REJECT narrows the path; it does not uniquely identify whether an SG or NACL rejected traffic. Compare the rules and use Reachability Analyzer where supported.
The design note worth adding: if the traffic is to an AWS service such as S3 or ECR, consider the appropriate VPC endpoint. It keeps traffic on the AWS network, removes the per-GB NAT data processing charge, and works without any internet path. S3 gateway endpoints have no endpoint hourly or processing charge; interface endpoints such as ECR have per-AZ hourly and data-processing charges. Compare the full bill and required endpoints. PrivateLink pricing.
What interviewers probe next
"NAT gateway or NAT instance?" Gateway for almost everyone: managed, scales, no patching. An instance is cheaper at small scale and becomes your problem to keep alive.
"Is the NAT gateway highly available?" Within its availability zone only. Multi-AZ needs one per zone with per-zone route tables, otherwise a zone failure takes egress down for every subnet routing through it.
"How do you allow inbound to a private instance?" You do not, directly. A load balancer in a public subnet, or Session Manager for administrative access, which needs no inbound rule at all.
Common mistakes
Skipping the route table association, which is invisible unless you look for it specifically.
Forgetting NACLs are stateless, then being unable to explain a blocked SYN-ACK that prevents connection establishment.
Reaching for a NAT gateway when the destination is an AWS service that a correctly configured VPC endpoint could serve, after comparing its policy and cost.