A company has created three VPCs: a production VPC, a nonproduction VPC, and a shared services VPC. The production VPC and the nonproduction VPC must…

This configuration creates a centralized routing model with traffic isolation. A dedicated route table for the production and nonproduction VPCs ensures they only learn the route to the shared services VPC, preventing them from communicating with each other. A separate route table for the shared services VPC allows it to learn routes to both the production and nonproduction VPCs, enabling it to communicate with both. This hub-and-spoke design with route table segmentation is the standard method for achieving the required network isolation using a transit gateway.

B. Propagating routes from each VPC into a single route table for production and nonproduction would allow them to communicate, violating the isolation requirement.
C. Associating all VPC attachments to a single route table would allow all VPCs to communicate with each other, which is explicitly forbidden by the requirements.
D. Disabling route propagation without adding static routes would prevent any communication between the VPCs, failing to meet the connectivity requirements.

1. AWS Documentation, "AWS Transit Gateway route tables". In the section "Examples", the "Isolated VPCs" example describes this exact scenario: "You can create a route table for the isolated VPCs and a route table for the centralized VPC. The route table for the isolated VPCs has a route to the centralized VPC. The route table for the centralized VPC has routes to the isolated VPCs."

2. AWS Documentation, "How transit gateways work". The section on "Route tables" explains: "By default, VPCs and VPNs are associated with the default transit gateway route table... To support different routing policies, you can create additional route tables and associate them with a set of attachments."