# Twelve AWS networking questions, and what the interviewer is actually listening for > Source: > Published: 2026-08-02 04:30:00+00:00 I have asked some version of "walk me through why this EC2 instance can't reach the internet" in about forty interviews. Maybe six people answered it well. Not because it's hard. Because most candidates answer the question they wish had been asked. They recite what a NAT gateway is. The question was diagnostic, and diagnosis is a different skill from definition. These are the twelve that come up most, with the reasoning behind each. Worth knowing before you read on: across 1,393 interview sessions configured on LastRound AI between January 2025 and July 2026, DevOps Engineering accounted for 464 of them. That's more than backend, frontend and full-stack combined, so the competition for these roles is real and the bar has moved. You can't shrink it. You can add secondary CIDR blocks, which is what most people mean when they say "resize." The reasoning being tested is whether you plan address space before you need it. A /16 gives you 65,536 addresses and costs nothing extra, so the correct habit is to allocate generously and subnet conservatively. I have watched a team spend two weeks migrating workloads because someone picked a /24 for a "small internal service" that grew. Weak answer: "You just add another CIDR." True but incomplete. Strong answer names the constraint that secondary CIDRs can't overlap with existing ones or with any peered VPC, which is exactly the trap that bites later. A route to an internet gateway in its route table. Nothing else. Not the name. Not the "auto-assign public IP" setting, though that matters for whether instances get an address. A subnet called "public-subnet-1a" with no IGW route is a private subnet with a misleading name, and I have debugged that exact situation twice. This question sorts people who learned AWS from a diagram from people who have configured it. The diagram shows a box labelled public. The console shows a route table. Security groups are stateful and evaluate at the instance level. NACLs are stateless and evaluate at the subnet boundary. Stateless is the word that does the work. If you allow inbound 443 on a NACL and forget the outbound ephemeral port range, the request arrives and the response never leaves. That failure looks like a timeout, not a rejection, which is why it eats hours. Security groups also deny by default with no explicit deny rule available. NACLs process rules in numbered order and stop at the first match, so a broad deny at rule 100 makes rule 200 irrelevant. If a candidate can explain why you would ever use a NACL given security groups exist, they have usually operated something real. The honest answer is: rarely, mostly for blanket IP blocks at the subnet edge. This is the diagnostic one. Answer it as a chain, out loud, in order. Route table has a 0.0.0.0/0 entry pointing at a NAT gateway. NAT gateway is in a public subnet, not the private one. That public subnet routes to an internet gateway. NAT gateway has an elastic IP. Security group allows the outbound traffic. NACL allows both the outbound request and the inbound ephemeral response. DNS resolution works, which is a separate failure that presents identically. Say the chain. Candidates who name one cause and stop are guessing. Candidates who walk the path are debugging, and the interviewer can hear the difference immediately. NAT gateway for almost everything. Managed, scales automatically, no patching. The interesting part is cost, and this is where I'll disagree with common advice. People treat NAT gateway pricing as a fixed cost of doing business. It isn't. You pay hourly plus per gigabyte processed, and the per-gigabyte charge is what surprises teams pulling container images or shipping logs out through it. A candidate who mentions VPC endpoints as the fix for S3 and ECR traffic has thought about the bill. That's a genuine signal, because it means they have seen one. Gateway endpoints cover S3 and DynamoDB, attach to a route table, and are free. Interface endpoints use PrivateLink, create an ENI in your subnet, cover most other services, and cost per hour plus per gigabyte. The follow-up that catches people: gateway endpoints don't work across VPC peering or from on-premises over Direct Connect, because they're route-table constructs local to the VPC. Interface endpoints do work across those paths. If someone confidently says "just use an endpoint" for a hybrid setup, that's the gap. Peering is point-to-point and non-transitive. Three VPCs that all need to talk means three peering connections. Ten VPCs means forty-five. That n(n-1)/2 growth is the whole argument for Transit Gateway, which gives you a hub and routes between attachments. The tradeoff is cost per attachment plus per gigabyte, so for two or three VPCs peering is usually cheaper and simpler. Non-transitive is the word that matters. If A peers with B and B peers with C, A cannot reach C. Candidates repeat "non-transitive" as a memorised phrase without being able to say what it means operationally. Ask them to draw it and you find out fast. Longest prefix match wins. A route for 10.0.1.0/24 beats a route for 10.0.0.0/16 for traffic to 10.0.1.5, regardless of the order they appear. People assume rules evaluate top to bottom because NACLs do. They don't. Route tables are prefix-matched, NACLs are ordered, security groups are unordered and permissive-only. Three different evaluation models in one networking stack is genuinely confusing, and saying so out loud is fine. It signals you understand the models rather than having memorised one. Two VPC attributes control this: enableDnsSupport and enableDnsHostnames. Support enables the Route 53 Resolver at the .2 address in your CIDR. Hostnames controls whether instances get public DNS names. Turn off support and resolution breaks entirely. Leave hostnames off and private hosted zones behave in ways that look like a routing problem. Both default differently depending on whether the VPC was created by the wizard or by Terraform, which is why this fails on the second environment and not the first. That last detail is the kind of thing you only know from having hit it. Traffic between availability zones is charged in both directions. Within an AZ it's free. The design implication is that chatty services which must live in the same failure domain sometimes belong in the same AZ, and you accept the availability tradeoff deliberately rather than by accident. Most reference architectures spread everything across three AZs and never mention the data transfer line on the bill. I don't have a clean rule for where the line sits. It depends on how chatty the service is and what your availability target actually is, and anyone offering a universal answer is selling something. The AWS VPC CNI assigns every pod a real IP from the subnet, through ENIs attached to the node. Each instance type supports a fixed number of ENIs and a fixed number of IPs per ENI, so pod density is bounded by instance type, not just by resources. A t3.medium supports 3 ENIs at 6 IPs each, minus one for the node. That's 17 pods, no matter how much idle CPU you have. The second half of the answer is subnet sizing. A /24 gives you 251 usable addresses, and a cluster that scales to 200 pods will exhaust it. Prefix delegation raises the density ceiling but consumes address space faster. This is the question where cloud and Kubernetes knowledge meet, and it separates people who have run a cluster from people who have deployed to one. No. The request fails at creation. Short answer, but the follow-up is the real question: what do you do about it? Options are re-addressing one VPC, which is disruptive, or putting a NAT layer between them, or using PrivateLink to expose the specific service rather than connecting the networks at all. PrivateLink is the answer that impresses, because it reframes the problem. You usually don't need two networks joined. You need one service reachable from the other side. Reading these is not the same as being able to say them. The chain in question four takes about ninety seconds out loud and most people discover they can't sequence it under mild pressure, even knowing every component. Say them standing up, timed, and record it. What rehearsal never fixed for me was the follow-up arriving mid-sentence — "and why doesn't that work across peering?" — about three seconds after I'd finished sounding confident. That specific gap is the one [Live Interview Copilot](https://lastroundai.com/products/ai-interview-copilot) is built for, since it reads the question as it's asked rather than after you have already frozen. The rehearsal still does the heavy lifting, though. Nothing bails you out of not knowing the material. For the source material, the [AWS VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) is the only reference worth reading properly. Which of these have you been asked? I'm curious whether the diagnostic ones show up as often elsewhere as they do in the rounds I've sat in.