A Transit Gateway has three VPC attachments: A, B, and C. Attachment A is associated with TGW route table RT1. Route propagation from attachment B is enabled into both RT1 and a separate TGW route table RT2, while attachment C is associated with RT2. Based on how Transit Gateway route tables work, which statement is correct?
- Attachment A can also be associated with RT2 at the same time, since a single attachment can be associated with multiple TGW route tables simultaneously
- Attachment A can send traffic based only on the routes in RT1, the one route table it's associated with, while attachment B's routes can be propagated into multiple TGW route tables (here, both RT1 and RT2) so they can be learned by other attachments
- Route propagation and association are two names for the same action; enabling propagation from attachment B into RT1 is what associates attachment B with RT1
- Attachment C cannot receive attachment B's routes unless attachment C is itself also enabled for propagation into RT2
Why B? And why not the others?
Correct answer: B. Attachment A can send traffic based only on the routes in RT1, the one route table it's associated with, while attachment B's routes can be propagated into multiple TGW route tables (here, both RT1 and RT2) so they can be learned by other attachments
Association and propagation are two distinct, separately-configured relationships in Transit Gateway routing: each attachment can be associated with only one TGW route table at a time, and that association determines which route table's routes govern traffic sent from that attachment, so attachment A is limited to RT1's routes. Propagation is different and many-to-many: an attachment's routes can be propagated into multiple TGW route tables so that other attachments associated with those tables can learn and use them, which is exactly why attachment B's routes can appear in both RT1 and RT2 even though B itself is associated with only one route table. The 'A can be associated with RT2 too' option is wrong because association is strictly one route table per attachment; a second simultaneous association isn't possible. The 'propagation and association are the same action' option is wrong because they are configured and behave independently — an attachment can propagate into a route table it isn't associated with, and vice versa. The 'C needs its own propagation to receive B's routes' option is wrong because receiving propagated routes depends on which route table an attachment is associated with (C is associated with RT2, which already received B's propagated routes), not on whether the receiving attachment itself propagates anything.
Source: AWS Transit Gateway Guide: Transit gateway route tables — 'Transit gateway route tables allows you to associate a table with a transit gateway attachment... An attachment can be propagated to multiple route tables'; each attachment is associated with exactly one route table.