AWS VPC Interview Questions

True. Every Region starts with a default VPC (a /16, typically 172.31.0.0/16) with one public subnet per AZ, an Internet Gateway already attached, and a main route table sending 0.0.0.0/0 to it. Each default subnet has MapPublicIpOnLaunch enabled, so an instance launched with no networking configuration gets a public IP automatically — which is convenient for a quick test but is exactly why production workloads should be deliberately placed into a custom VPC with private subnets instead of relying on the default's wide-open convenience.

A NAT Gateway is deployed in a public subnet and lets instances in a private subnet initiate outbound IPv4 connections to the internet (for example, to fetch patches) while blocking inbound connections that were not initiated from inside the VPC. The private subnet's route table needs a 0.0.0.0/0 route pointing to the NAT Gateway. An Internet Gateway alone attaches the VPC to the internet but does not translate private addresses, so private instances would lack a route for outbound traffic and could be reached directly if given public IPs. VPC Peering and Transit Gateway connect VPCs or networks to each other, not to the public internet.

The statement is false. A VPC is a regional resource that exists within exactly one AWS region and never crosses region boundaries. Subnets inside a VPC can span multiple Availability Zones in that same region. To connect workloads across regions, you create a separate VPC in each region and link them with VPC Peering, Transit Gateway, a VPN, or Direct Connect.

VPC peering in AWS is a point-to-point, non-transitive connection. Traffic cannot pass through an intermediate VPC to reach a third one, so every communicating pair needs a dedicated peering link. A full-mesh arrangement therefore requires N*(N-1)/2 peerings, which scales quadratically and becomes operationally unwieldy for large numbers of VPCs, making peering a poor choice for broad, many-to-many connectivity.

A VPC is a regional resource: when you create it you choose a Region, and it spans every Availability Zone in that Region. Subnets, not the VPC, are bound to individual Availability Zones, with each subnet living in exactly one AZ. A VPC does not extend across Regions, so the Region is the level at which it is scoped.

A VPC is the foundational networking layer almost every other AWS resource sits in. The pieces that matter in interviews: it's Region-scoped with subnets pinned to one AZ each, public vs private subnets are defined by their route to an Internet Gateway vs a NAT Gateway, and security groups (stateful) vs NACLs (stateless) are the two filtering layers. Being fuzzy on subnets-are-AZ-scoped or on the IGW-vs-NAT distinction is a common tell of someone who hasn't actually built a network.

Both real constraints show up constantly in capacity planning: every subnet loses 5 addresses to AWS reservations regardless of size, so a /28 (16 addresses) nets only 11 usable — small enough to bite teams who size subnets too tightly. And subnet CIDRs must nest inside the VPC's CIDR with zero overlap between sibling subnets, since a VPC's route table can't disambiguate an address that two subnets both claim. Neither the claim that a subnet's CIDR block can be widened or narrowed after creation nor the claim that DNS resolution for instances is a per-subnet setting inherited from the subnet's Availability Zone is real: a subnet's CIDR block is fixed at creation with no resize path at all (not even a conditional one), and DNS resolution (enableDnsSupport/enableDnsHostnames) is configured at the VPC level, not derived per-subnet from its AZ.

The scaling math is the interview point: peering is O(n²) connections as VPC count grows, and each one needs manual route-table wiring on both sides — a real operational burden past a handful of VPCs. Transit Gateway turns that into O(n) attachments with centralized route tables (including the ability to segment attachments into different routing domains). Knowing this trade-off, rather than defaulting to 'just peer everything,' is what separates someone who has actually run a multi-VPC estate from someone reciting definitions.

In the Amazon VPC model, every subnet is associated with exactly one Availability Zone at creation time and cannot span more than one. This is a platform-level constraint, so instances launched into a subnet always run in that subnet's AZ. The other statements are false: a subnet cannot span multiple AZs; creating a VPC does not auto-create subnets, so each subnet must be explicitly created in a chosen AZ; and an AZ can hold many subnets within the same VPC (for example, one public and one private).

A route table is the VPC resource that maps destination CIDR blocks to targets such as an Internet Gateway, NAT Gateway, or VPC peering connection. The default route 0.0.0.0/0 pointed at an Internet Gateway is what makes a subnet public. Network ACLs filter traffic but do not route it, security groups are stateful instance-level firewalls, and the Internet Gateway is a target rather than the resource that holds the routes.

When you create a custom VPC in AWS, exactly three resources are automatically created and associated at creation time: a default security group (with an allow-all rule for instances in the same group), a default network ACL (allowing all inbound and outbound traffic), and a main route table (containing only the local route for the VPC CIDR). AWS does not auto-provision subnets, an internet gateway, or a NAT gateway for a custom VPC; those (one subnet per AZ and an attached internet gateway) are only provisioned for the AWS-managed default VPC that comes with each region. Because all three of these resources are always created together, the question asks for the full set rather than singling one out.

AWS lets you pick the VPC's primary IPv4 CIDR anywhere from /16 down to /28, but once set, that primary block's size can't be changed — you can only add non-overlapping secondary CIDR blocks alongside it, and any block you add has to avoid every CIDR you might peer with later. A /24 (256 addresses total) sounds like plenty until you subtract AWS's 5 reserved addresses per subnet and multiply by AZ count and subnet tiers (public/private/data); teams that undersize routinely paint themselves into a corner. The standard advice is to start generous (often /16) even for a small footprint, because growing into unused space is free and shrinking isn't possible. The other options are all false statements about how VPC CIDR sizing actually works.

VPC peering is explicitly non-transitive by design: it connects exactly the two VPCs in the peering relationship, and VPC B will not forward traffic between A and C even with route tables configured to try it — AWS's peering implementation simply doesn't route across a 'hop.' To let A and C talk, you either add a direct A↔C peering connection (and at n VPCs, that's an O(n²) mesh) or replace the mesh with a Transit Gateway, which acts as a Regional hub-and-spoke router that every VPC attaches to once. Identical CIDR blocks would actually block peering, not enable it — overlapping CIDRs are rejected. The claim that an account can only maintain one active peering connection at a time is false.

NAT Gateway and NAT instance solve the same problem — outbound-only internet access for private subnets — with opposite operational trade-offs. NAT Gateway is a managed service: no patching, no instance sizing, automatic scaling to 100 Gbps, and an SLA, but it's a single-purpose black box. A NAT instance is 'just an EC2 box' with IP forwarding and disabled source/dest checks, so it can be repurposed (bastion, monitoring agent) but you own its patching, sizing, and HA. The claims that a NAT Gateway can route directly between two private subnets and that a security group attaches directly to it are both false: a NAT Gateway must live in a public subnet with an Elastic IP to reach the internet at all, and it has no concept of a security group — traffic to/from it is filtered by the subnet's network ACL, not an attached SG (that's a NAT instance's model, since it's a real EC2 instance).

True. A gateway endpoint adds an entry to the subnet's route table that matches S3's (or DynamoDB's) managed prefix list and routes it directly to the service over AWS's internal network — no Internet Gateway, no NAT Gateway, and no public IP involved at any point. That's both a security win (the traffic is never exposed to the public internet) and a cost win (S3 gateway endpoints carry no hourly or per-GB charge, unlike routing the same traffic out through a NAT Gateway, which bills per GB processed).

The route table shown has only the automatic local route for the VPC's own CIDR — there is no default route sending everything else (0.0.0.0/0) to the NAT Gateway, so any request to an address outside the VPC has nowhere to go and is dropped. The fix is adding 0.0.0.0/0 → nat-xxxx. Private subnets should never get their own Internet Gateway — that's what would make them public; a NAT Gateway isn't a device you attach a separate route table to, the route lives on the subnet's table; and the entire point of routing through NAT is that private instances stay private, so they explicitly don't need public IPs — the NAT Gateway's own Elastic IP is what's public.

The interview signal here is whether the candidate has the two axes straight rather than treating both as 'the same thing at a different layer.' Security groups: instance-level, stateful, allow-only. NACLs: subnet-level, stateless, allow-and-deny, order-matters. A candidate who can also explain why — stateful means connection tracking handles return traffic automatically, stateless means it doesn't and both directions need explicit rules — is showing they've actually debugged connectivity with these, not just memorized a comparison table.

Outbound NAT is two separate routing hops plus one address rewrite, and mixing up the order is the usual source of confusion. First the private subnet's own route table decides the packet isn't local traffic and sends it to the NAT Gateway (this is what makes it work from a private subnet with no public IP of its own). The NAT Gateway then source-NATs the packet to its own private IP before it ever reaches the Internet Gateway. Only then does the public subnet's route table forward that already-NAT'd traffic to the Internet Gateway, which translates the NAT Gateway's private IP to its Elastic IP — a private IP isn't routable on the public internet, so this final hop is what actually gets the packet onto it. The NAT Gateway rewrites to its private IP; the Internet Gateway maps that private IP to the Elastic IP — conflating the two is why people misdiagnose which hop is failing when outbound connectivity breaks.

Security Groups are stateful: when an inbound request is allowed, the matching response traffic is automatically permitted without an outbound rule for it. Network ACLs are stateless, so each direction needs its own explicit allow rule, including the return traffic. The other statements invert the real behavior: NACLs are the ones that evaluate numbered rules in order and stop at the first match, and Security Groups are the ones that support only allow rules, whereas NACLs support both allow and deny.

A NAT Gateway is an AZ-scoped resource, not a Regional one — it lives in one specific public subnet in one AZ. If that AZ goes down, or even just has degraded networking, every private subnet pointed at it loses outbound internet access simultaneously, and it also means every other AZ's outbound traffic is crossing AZ boundaries (and paying for it) to reach the single NAT Gateway. The standard highly-available pattern is one NAT Gateway per AZ, each in that AZ's public subnet, with each AZ's private-subnet route tables pointing at the NAT Gateway local to them — so an AZ failure only takes down that AZ's own outbound path, and traffic never has to hop AZs. An Internet Gateway is a separate, Regional resource that serves public subnets directly; it isn't a NAT substitute or a NAT failover mechanism.

Network ACLs are stateless and rule-ordered: AWS evaluates rules starting from the lowest number, and the first rule that matches the traffic decides the outcome — evaluation stops there. It does not scan for the most specific match, and it does not let a later Allow override an earlier Deny the way people sometimes assume from security-group behavior (which has no concept of rule order or explicit deny at all). Here, rule #100's 0.0.0.0/0 deny matches the admin CIDR too, since it's a superset, so it wins outright and rule #200 never gets evaluated. The fix is renumbering so the narrower Allow has a lower number than the broad Deny — rule ordering in NACLs is exactly the kind of detail that silently breaks 'correct-looking' configs.

AWS has two distinct VPC endpoint mechanisms and they aren't interchangeable. A gateway endpoint is just a target you add to a route table — traffic matches a managed prefix list and gets routed to the service, at no hourly or per-GB cost — but it's only available for S3 and DynamoDB. Everything else that supports private connectivity (Secrets Manager, KMS, SNS, SQS, EC2, most others) does it through an interface endpoint: an Elastic Network Interface with a private IP dropped into your subnet, fronted by AWS PrivateLink, billed per-hour-per-AZ plus per-GB processed. So reaching both S3 and Secrets Manager privately genuinely requires provisioning one of each type — there's no single endpoint that covers everything.

This tests whether someone understands gateway endpoints as an architectural and cost decision, not just a checkbox. The concrete wins to listen for: no NAT Gateway per-GB data-processing charge for that traffic, no path through the public internet at all (stronger security posture, not just 'private-looking'), and the mechanism — a route-table entry matching S3's prefix list — rather than vague 'it makes it private' hand-waving. A strong answer also notices this decouples S3 reachability from the NAT Gateway's own availability.

This is the single most common peering gotcha: an active peering connection is necessary but not sufficient — it just makes the path available, it does not populate anyone's route table. Each side has to separately add a route sending the other VPC's CIDR to the peering connection ID. VPC A clearly has its route to B (traffic flows A→B), but VPC B's table above only has its own local CIDR and a default route to an Internet Gateway — no route to 10.0.0.0/16 at all, so return or A-bound traffic has nowhere to go and connectivity is one-directional. Peering acceptance happens once, not per-direction. Peering traffic is direct VPC-to-VPC and never touches a NAT Gateway. Security groups can reference the peer's CIDR block just fine for peered traffic — no special peering-connection-ID syntax is required.

The Transit Gateway makes forwarding decisions solely from its TGW route table. The packet arrives from VPC A's attachment and the TGW looks up 10.1.0.0/16; since propagation is disabled and no static route exists, there is no matching route, so the packet is dropped. The sender observes a connection timeout because no SYN-ACK returns. The VPC subnet route tables are correctly configured but only deliver the packet to the TGW, and VPC B's security groups and NACLs are never reached. Both the VPC route tables and the TGW route table must contain appropriate routes for connectivity.