You create a new subnet in an existing AWS VPC and never associate it with a route table. Which route table governs that subnet's traffic, and why does this trip teams up?
answer
- there is a fallback, not a void
- every VPC has exactly one of these
- implicit versus explicit association
- what the default VPC's version contains
- keep it holding only local
basics
~20 sIt falls back to the VPC's main route table through an implicit association. If that table has a 0.0.0.0/0 route to an internet gateway the new subnet is silently public; if it holds only the local route, nothing in it can leave the VPC.
solid answer
~50 sEvery VPC has exactly one main route table, and any subnet without an explicit association implicitly uses it. That is the whole trap: the subnet's behaviour is decided by a table nobody chose for it, and whichever way the main table is configured, one of two failure modes follows. If someone previously added a default route to the internet gateway there — which is how a default VPC ships — the new subnet is internet-facing without any deliberate decision. If the main table carries only the `local` route, the new subnet has no egress and you get a connectivity ticket instead. The discipline is to keep the main route table minimal, with only the local route, so accidents fail closed, and to explicitly associate every subnet you create with the table you intend. A subnet has exactly one route table association at a time; a route table can serve many subnets.
code
bash · 6 lines# Which table is main, and what does it route?
aws ec2 describe-route-tables --filters Name=vpc-id,Values=vpc-0abc \
--query 'RouteTables[?Associations[?Main==`true`]].[RouteTableId,Routes]'
# Make the association explicit instead of implicit
aws ec2 associate-route-table --subnet-id subnet-0new --route-table-id rtb-0privatego deeper
Know that every VPC has one main route table and that a subnet you never associate with anything uses it automatically.
Explain implicit versus explicit associations, that a subnet has exactly one route table while a table can serve many subnets, and both failure modes the fallback produces.
Demonstrate the operating rule you enforce — main table sterile, every subnet explicitly associated — and how you would audit an existing VPC for subnets sitting on the main table.
Frame it as a guardrail question: what organisation-wide control prevents an unintended internet-facing subnet, and how you make the safe configuration the default rather than a review item.
## Main table, custom tables, and the two kinds of association When a VPC is created, AWS creates one route table with it and marks it **main**. It contains a single `local` route covering the VPC CIDR. You then normally create your own tables — a public one carrying `0.0.0.0/0` to the internet gateway, one or more private ones — and associate subnets with them. Associations come in two flavours: - **Explicit** — you associated subnet X with table Y. `describe-route-tables` shows the association object, and the console shows the subnet under that table. - **Implicit** — you associated the subnet with nothing, so it uses the main table. There is no association object to look at, which is precisely why this is easy to miss during review. A subnet participates in exactly one association at a time, so it is governed by exactly one route table. A route table, conversely, can be associated with any number of subnets — which is why one "public" table is normally shared by the public subnet in every Availability Zone. ## Why the fallback is dangerous in both directions **Fails open.** In a default VPC the main route table already has `0.0.0.0/0` pointing at the internet gateway, and default subnets have auto-assign public IPv4 turned on. A subnet created there and left unassociated is fully internet-facing. The same happens in a hand-built VPC if someone once added the internet route to the main table because it was the table in front of them. Nobody reviews a change that consists of *not* doing something, so this survives to production. **Fails closed.** In a well-built VPC the main table has only `local`. Now a new subnet has no default route at all: instances launch fine, get addresses fine, and can talk to the rest of the VPC fine, but every outbound connection to anything outside the VPC hangs. This presents as an application bug — package installs stall, an SDK call times out — and the network layer is often the last place people look. ## Making it deterministic Three habits remove the class of problem entirely: 1. **Keep the main route table sterile.** Leave it holding only the `local` route and never add a default route to it. Then the worst case of a forgotten association is an isolated subnet, which is loud and harmless, rather than an exposed one, which is quiet and not. 2. **Associate every subnet explicitly**, including ones you think will use the same table as the main one. An explicit association is a reviewable, greppable fact; an implicit one is an absence. 3. **Audit for implicit associations.** Any subnet that does not appear in the associations of a custom table is on the main table. This is a one-query check and worth running as a guardrail. ## The related knobs You can change which table is main using `aws ec2 replace-route-table-association` with the main table's association id — a change that instantly re-routes every implicitly associated subnet at once, so treat it as a high-blast-radius operation. You can also disassociate a subnet with `aws ec2 disassociate-route-table`, which does not leave it with no routing: it drops the subnet back to the main table. That surprises people who expect disassociation to isolate a subnet. One further detail worth knowing: the main route table cannot be deleted while it holds that role, and a route table with associations cannot be deleted at all — you must move its subnets first. This is a common blocker when tearing down environments by hand. ## What good sounds like in the room The strong answer names the implicit association, states both failure directions rather than only the exposure one, and closes with the operating rule: main table holds only `local`, every subnet is explicitly associated. That last sentence is what distinguishes someone who has run a VPC from someone who has read about one.
- How many route tables can one subnet be associated with at a time?Exactly one. A subnet is governed by a single route table — explicitly associated, or the main table by implication. The relationship is one-to-many in the other direction: a single route table typically serves the public subnet in every Availability Zone, which is why moving one association can change several subnets' behaviour if you edit the shared table instead.
- What happens if you disassociate a subnet from its route table?It does not become isolated — it falls back to the VPC's main route table. That is the same implicit association a brand-new subnet gets, so disassociation silently hands the subnet whatever the main table routes. If the main table has a default route to an internet gateway, disassociating a private subnet exposes it.
- Why do experienced teams leave the main route table holding only the local route?So that the failure mode of a forgotten association is isolation rather than exposure. An unassociated subnet then cannot reach anything outside the VPC, which surfaces immediately as a broken deployment; the alternative failure — a subnet silently reachable from the internet — produces no symptom at all until it is found by someone else.
saying these in an interview costs you the question
- Says an unassociated subnet has no routing at all
- Does not know the VPC has a main route table
- Thinks disassociating a subnet isolates it
- Assumes a subnet can use several route tables
- Adds the internet route to the main table for convenience