A transit gateway in Account A is shared using AWS RAM so other accounts can connect VPCs in the same Region. Account B has a VPC (10.0.0.0/16) with subnets 10.0.0.0/24 (us-west-2a) and 10.0.1.0/24 (us-west-2b). Two new subnets were added: 10.0.2.0/24 (us-west-2b) and 10.0.3.0/24 (us-west-2c). All subnets use the same route table; the default route 0.0.0.0/0 points to the transit gateway. Resources in 10.0.2.0/24 can reach other VPCs, but resources in 10.0.3.0/24 cannot. What must the engineer do so resources in 10.0.3.0/24 can reach other VPCs?

The correct answer is to update the transit gateway attachment by attaching the subnet ID for the us-west-2c subnet to the VPC attachment. When a VPC is attached to a Transit Gateway, you must specify which subnets within that VPC the Transit Gateway can use to route traffic. If a subnet is not explicitly associated with the Transit Gateway attachment, resources in that subnet cannot communicate through the Transit Gateway. Since 10.0.3.0/24 is in a new Availability Zone (us-west-2c), it needs to be added to the existing Transit Gateway attachment. Adding 10.0.2.0/24 and 10.0.3.0/24 as destinations in the VPC route table is incorrect because the default route 0.0.0.0/0 already points to the transit gateway, which would cover these specific CIDRs. Adding a static route in Account A's transit gateway route tables is incorrect because the issue is with the VPC attachment itself, not the Transit Gateway's routing logic. Recreating propagation for 10.0.0.0/16 is also incorrect as propagation handles route distribution, but the fundamental problem is the missing subnet association with the attachment.