In an AWS Transit Gateway, what is the difference between associating an attachment with a route table and propagating that attachment's routes into one, and how do you use both to keep dev and prod isolated while both reach shared services?

## Two knobs that sound alike A Transit Gateway holds one or more route tables, and every attachment relates to them in two independent ways. **Association — ingress.** Each attachment is associated with exactly **one** Transit Gateway route table. When a packet enters the gateway from that attachment, that table decides where it goes. "Which routes does this attachment *see*?" **Propagation — advertising.** An attachment's own prefixes — a VPC's CIDRs, or the prefixes learned by BGP over a VPN or Direct Connect gateway attachment — can be propagated into **any number** of route tables. "Who *learns about* this attachment?" The two are independent. An attachment can be associated with table X while propagating into tables X, Y and Z, and it can propagate into tables it is not associated with at all. That asymmetry is exactly what makes one-way patterns possible. ## The segmentation pattern The canonical layout for a shared hub: - **Prod route table** — prod VPC attachments associated with it. Propagations: prod attachments and the shared-services attachment. No dev. - **Dev route table** — dev VPC attachments associated with it. Propagations: dev attachments and the shared-services attachment. No prod. - **Shared-services route table** — the shared-services VPC attachment associated with it. Propagations: prod, dev and shared services, so shared services can answer both. A dev instance sending traffic to a prod address hits the dev route table, finds no matching route, and the packet is dropped inside the gateway. There is no rule to misconfigure and no policy engine to evaluate — the isolation is the *absence* of a route, which is a much stronger property than a deny rule someone can edit. When you need to prove a prefix is deliberately dropped rather than accidentally missing, add a **blackhole** route for it. That is also how you quarantine a range without detaching anything. ## Static routes and precedence Besides propagated routes, you can add static routes to a Transit Gateway route table pointing at a specific attachment. Static routes take precedence over propagated ones for the same destination, which is how you steer traffic through an inspection VPC: propagate normally, then add a static route for the destination range pointing at the firewall attachment. For stateful appliances, enable **appliance mode** on the inspection VPC's attachment. Without it, forward and return traffic can land in different Availability Zones and reach different appliance instances, and a stateful firewall drops the half of the flow it has no state for. Appliance mode keeps a flow pinned to the same AZ for both directions. This is a genuinely common production failure and it is worth naming. ## The default that quietly undoes all of it A Transit Gateway is created with automatic association and automatic propagation enabled and a default route table. Every new attachment then associates with that one table and propagates into it, and you have a flat any-to-any network wearing the costume of a segmented one. If you intend to segment, turn both defaults off at creation and make every attachment's association and propagation an explicit act. This is also the answer to "is a Transit Gateway transitive?" — yes, but only where its route tables say so. Transitivity is a capability, not a promise. ## Operating it Attachments frequently belong to other accounts, since the gateway is shared through AWS Resource Access Manager. Note the split: the attachment is created by the VPC's owner, but **association and propagation are controlled by the gateway's owner**. That is precisely the boundary you want — application teams attach their own VPCs, and the network account decides who talks to whom. For debugging, `SearchTransitGatewayRoutes` shows what a given route table actually holds, including blackholes, and Network Manager gives a topology view. The most common finding is not a broken route but a missing propagation on one of the two tables involved in a bidirectional path. ## What interviewers listen for The clean one-line distinction — association is ingress, propagation is advertising — followed by the three-table pattern and the observation that isolation comes from a missing route rather than a deny. Mentioning the automatic-association default, or appliance mode for stateful inspection, is what makes it sound like something you have operated instead of read.