Articles
AWS Transit Gateway Interview Questions: Route Tables and Asymmetric Paths
Practice AWS Transit Gateway interview questions with ingress route tables, propagation, blackholes, asymmetric return paths, and inspection decisions.
VPC A can send packets toward VPC B through a transit gateway, but the connection never completes. A route to B is visible in one transit-gateway table. Is that enough evidence to clear the routing layer?
No. For AWS Transit Gateway interview questions, verify the table selected by each ingress attachment and the route selected for each destination, in both directions. A route elsewhere on the gateway does not govern the packet you are tracing. A forward path does not establish a return path, and route propagation is not the same as route-table association.
This article is for infrastructure, cloud, and SRE candidates. AWS documentation supplies platform mechanics; the address ledger, route lookup, and asymmetric-path exercises are original synthetic practice, not evidence from an AWS deployment. Start with Design VPC, IP plan, management, storage, SSO and make each attachment's routing ownership explicit.
Which route table sees an arriving packet?
Official: AWS's Transit Gateway routing overview describes a Regional layer 3 router that selects a next-hop attachment by destination address. Each attachment can be associated with one transit-gateway route table and can propagate routes to one or more tables.
Association answers “which table handles packets entering through this attachment?” Propagation answers “which tables receive routes advertised by this attachment?” Keep those questions separate, even when default settings put both activities in the same table.
Imagine three attachments named att-A, att-B, and att-inspect. These names are original exercise identifiers. att-A is associated with rt-spokes, while att-B is associated with rt-services. The existence of a B route in rt-services does not establish what a packet entering through A will do.
Write an ingress ledger before writing routes. For each attachment, record its actual association and which routes it propagates into which tables. Avoid relying on a table's name, since a table called production may not be associated with the production attachment you are testing.
Official: AWS's route-table guide describes separate association, propagation, static-route, and blackhole operations. Creating a route and associating an attachment are different configuration steps.
In an interview, explain both settings aloud. If you say only “propagate B,” the interviewer can reasonably ask whether packets from A consult the receiving table at all. If you say only “associate A,” the table may still lack a usable destination route.
Solve a bidirectional route-ledger exercise
Use this original IPv4 topology. A is 10.10.0.0/16, B is 10.20.0.0/16, and the inspection VPC is 10.30.0.0/16. The source is 10.10.1.10, and the destination is 10.20.2.20. Treat the VPC subnet routes and network controls as correct for the first pass.
The transit-gateway tables are deliberately different:
| Ingress table | Destination route | Next hop in the exercise |
|---|---|---|
rt-spokes, associated with A | 10.20.0.0/16 | att-B |
rt-services, associated with B | 10.30.0.0/16 | att-inspect |
rt-services, associated with B | No matching A route | No next hop for the response |
For the request, ingress is att-A, so use rt-spokes; the B prefix matches and selects att-B. For the response, ingress is att-B, so use rt-services; the destination is now A's source address. The unrelated inspection prefix does not match it.
The observed consequence in this model is forward routing with no modeled return route. A packet arriving at B is not proof of a completed TCP exchange. If the interviewer shows only a successful request-side flow record, ask for the response-side evidence.
Now add 10.10.0.0/16 → att-A to rt-services. The model has a direct path in both directions. Before proposing that as a production repair, ask whether policy requires inspection between A and B. A connectivity fix that bypasses required inspection may violate the design.
Your answer should preserve the intent: identify the missing route, identify its owning table, explain the intended path, and propose a narrowly scoped change. Do not “fix” every table by propagating every VPC everywhere.
What happens when a more specific blackhole exists?
Official: The routing overview specifies most-specific destination matching and additional priorities for equal destinations, including static-route priority over an overlapping propagated route. It also describes blackhole routes that discard matching traffic.
Extend the original rt-spokes table with 10.20.2.0/24 → blackhole. Keep the broader 10.20.0.0/16 → att-B route. The destination 10.20.2.20 matches both prefixes, and the /24 wins. A second destination, 10.20.3.20, still matches the /16 route.
This is why “the route to B exists” is not a sufficient diagnosis. Show the exact destination and every relevant match. A limited blackhole may intentionally isolate a subnet, or it may be a stale incident control. Its purpose determines whether deletion is an appropriate fix.
For an equal-prefix exercise, place a static blackhole and a propagated B route on the same destination prefix. Discuss the documented route-type priority rather than assuming propagation overrides manual configuration. Record the active route and route origin in your evidence.
Do not overextend the toy longest-prefix function. Real Transit Gateway selection includes route-type and BGP-related priorities. The local exercise checks distinct-prefix lookup and one explicitly modeled static-versus-propagated case; it is not a complete implementation of AWS's routing control plane.
Where do VPC subnet routes still matter?
The transit gateway is only one forwarding boundary. The source workload subnet must send the intended external destination toward the gateway, and the receiving VPC must deliver traffic from the attachment toward the workload. Return routes need their own inspection.
Official: AWS's VPC-attachment documentation explains attachment subnet and target subnet routing requirements. It also limits reachability from Availability Zones without the relevant attachment and warns about overlapping VPC CIDRs.
For the original A-to-B connection, expand the ledger into four routing observations: A workload table, A ingress TGW table, B attachment-side VPC path, and B workload return table. Then evaluate the reverse TGW ingress lookup. Record the association for each table you inspect.
If only one Availability Zone fails, compare attachment placement and the failing workload's zone before changing a broad route. A correct gateway-wide prefix does not prove that a workload in every zone has a usable entry path.
Likewise, an attachment in an available state is a control-plane observation, not proof that a service process accepts traffic. Preserve DNS, routing, subnet filters, security groups, listener state, and application response as distinct checks.
The simplest interview explanation names the last boundary supported by evidence. “The SYN was observed at B's workload interface, but no response is evidenced” is more actionable than “TGW is healthy.” It also leaves room for a listener or filtering failure rather than forcing every symptom into routing.
How can a stateful appliance see an asymmetric flow?
Consider an original inspection topology. A's ingress table sends B destinations to att-inspect. After inspection, packets reenter the gateway through the inspection attachment and use its associated table to reach B. Responses must also follow the intended inspection path.
The key is that a transit gateway does not inherently remember “send the response back through every hop the request used.” Each forwarding decision must be consistent with the configured routes and the appliance's state requirements.
An original failure changes B's return route to direct A instead of inspection. The request reaches the firewall, but the reverse leg bypasses it. Another failure sends the legs through different appliance instances that do not share connection state. Both can break the intended stateful processing, but their route and flow evidence differ.
Official: AWS describes appliance-mode support on VPC attachments to keep the selected Availability Zone stable for the lifetime of a flow. Current VPC-attachment guidance also distinguishes AZ-aware behavior with propagation from fallback flow-hash selection when AZ information is unavailable.
Do not describe appliance mode as a universal symmetry switch. It does not invent missing routes, fix an appliance's own forwarding, supply application authorization, or prove that two independently designed gateways enforce the same flow path.
For a useful interview answer, draw the inspection VPC's internal path too. Identify the appliance, attachment subnet, any load-balancing layer, and the next route back to the transit gateway. A box labeled “firewall” conceals the ownership and failure modes you are supposed to explain.
Ask how the configuration handles a new flow versus an established one during a change. Routing changes can alter which stateful component sees a packet. Do not promise seamless continuity without the actual appliance and rollout behavior being tested.
What changes when a second transit gateway is involved?
Official: AWS's peering-attachment guide describes peered transit gateways and static-route configuration toward the peering attachment. A peer relationship is not automatic end-to-end route distribution for every attached VPC.
Extend the original exercise by placing B behind TGW2. A-to-B now requires the appropriate lookup on TGW1, the peering next hop, and a lookup on TGW2 to B. The reverse path requires its own matching configuration on both gateways.
Write the path as a sequence of table decisions rather than one arrow crossing Regions. If a route exists only on TGW1, ask what TGW2 does when the packet arrives. If both forward routes exist, still verify the routes toward A on the return leg.
Do not assume that privately routed connectivity automatically makes a private DNS zone visible across every attached network. Name resolution is a separate requirement with a resolver and zone-sharing design. A wrong hostname answer can send the application away from the route path you intended to test.
What evidence supports a safe route repair?
Capture source and destination addresses, ports, direction, ingress attachment, associated table, winning route, route origin, attachment state, and observation time. For inspection, add the expected stateful hop and the actual flow evidence on each leg.
Official: Transit Gateway Flow Logs provide traffic metadata for investigation. They are not application payload captures or proof that a remote process completed a request. Interpret them within their capture scope and delivery behavior.
An original repair plan has three checks: the previously failing permitted destination works, an intentionally isolated destination remains isolated, and the return leg still follows required inspection. A broad “ping passes” test can miss both application failure and a security-policy regression.
Before changing a route, save the current configuration and identify rollback conditions. If the failure affects only one specific prefix, state why a narrower repair is preferable to changing a default route used by unrelated workloads.
For local preparation, test the route ledger against expected next hops and blackholes, including both directions. This proves your arithmetic and assumptions are internally consistent. It does not verify an AWS attachment, packet path, failover time, or firewall state.
Sources and Further Reading
Official references checked October 1, 2026. Original route models do not claim deployment, packet-capture, or appliance-failover validation.