Two VPCs are attached to the same AWS Transit Gateway, and each attachment is associated with the Transit Gateway default route table. Instances in the two VPCs still cannot reach each other across the Transit Gateway, although each VPC has internet access. The Transit Gateway route table shows the attachments associated but no routes to the opposite VPC CIDRs. Which change restores VPC-to-VPC connectivity through the Transit Gateway?
- ADetach and reattach each VPC to the Transit Gateway so the attachments re-register and the gateway rebuilds the missing routes to the opposite VPC CIDRs automatically.
- BAdd a route in each VPC subnet route table that sends the internet CIDR to the Transit Gateway so cross-VPC packets are forwarded over the existing internet path.
- CEnable route propagation for the attachments on the Transit Gateway route table, and add a route in each VPC subnet route table for the other VPC CIDR pointing at the Transit Gateway. Correct
- DReplace the Transit Gateway with VPC peering between the two VPCs, then add a peering route in each subnet route table because peering forwards cross-VPC traffic without route tables on the gateway.
Why A is wrong: Reattaching does not change whether route propagation is enabled, so the Transit Gateway route table would still lack the opposite VPC routes and the cross-VPC traffic would continue to fail.
Why B is wrong: Routing the internet CIDR to the Transit Gateway misdirects general traffic and still provides no Transit Gateway route between the specific VPC CIDRs, so VPC-to-VPC reachability is not restored.
Why C is correct: Propagation populates the Transit Gateway route table with each VPC CIDR, and the subnet route entries send cross-VPC traffic to the gateway, together giving the gateway and the VPCs the routes needed to connect.
Why D is wrong: Discarding the Transit Gateway for peering is unnecessary rework when the attachments already exist; the real gap is the missing propagated and subnet routes, which peering does not address.