AWS Transit Gateway VPC Route Configuration

A company is planning to migrate to AWS and use multiple VPCs in multiple AWS Regions. A network engineer must connect the eu-west-1 and eu-central-1 Regions to the company headquarters and branch office, respectively. The network engineer created a production VPC, named Prod A, with a CIDR block of 10.0.0.0/16. Prod A runs in an account in eu-west-1. The network engineer then created another production VPC, named Prod B, with a CIDR block of 10.1.0.0/16. Prod В runs in a different account in eu-central-1. The network engineer performed the following steps to try to achieve the required connectivity: 1. Created one transit gateway in each Region 2. Shared and accepted the transit gateways with the production accounts in both Regions 3. Configured the peering attachment between both transit gateways 4. Attached both VPCs to the respective Region transit gateway 5. Created both transit gateway route tables and associated the attachments with the route tables 6. Configured a static route in both transit gateway route tables to send traffic to the remote VPC in the other Region 7. Activated route propagation on the VPC route tables in each Region After the configuration, the network engineer tried to connect from Prod A to Prod B. However, the connection was unsuccessful. What should the network engineer do to achieve the required connectivity?

Modify the IP address of the peering attachment to a wider range.
Delete the static routes that were in the transit gateway route table to send traffic to the remote VPC and enable route propagation instead.
Create a new route destined to 10.0.0.0/8 in both production VPC route tables with the Region transit gateway as the target. Source Reference Answer
Modify the transit gateway route tables from the production accounts to propagate routes dynamically between the production VPCs.

Community Votes

100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The exam tests the distinction between Transit Gateway route tables (which support propagation) and VPC route tables (which do not automatically learn remote transit gateway routes). The common trap is assuming route propagation works bidirectionally or that static routes on the TGW are sufficient for end-to-end connectivity without corresponding VPC entries.

This question tests the understanding of routing table dependencies in AWS Transit Gateway (TGW) architectures, specifically how VPC route tables must be manually configured to reach remote networks. Community consensus confirms that while TGW handles inter-region peering via static routes, VPCs require explicit return routes pointing back to their local TGW.

Option B is a common distractor; candidates often confuse TGW route table behavior with VPC behavior. While TGW route tables can propagate routes from attached gateways, they do not propagate routes into VPC route tables. Therefore, enabling propagation on the TGW does not update the VPC's local routing table.

Community Discussion (3 comments)

secdaddy 👍 2 Selected: C

A ❌ Eliminate TGW peering attachments don’t have IP addresses. B ❌ Eliminate TGW peering requires static routes; propagation is not supported. C ⚠️ Technically Valid (but bad design) Broad CIDR route (10.0.0.0/8) works but is ugly. D ❌ Eliminate Cannot propagate routes dynamically between VPCs.

woorkim 👍 1 Selected: C

C is correct because: Adding a route for 10.0.0.0/8 in both VPC route tables pointing to the transit gateway will: Enable traffic to flow between the VPCs Cover both VPC CIDR ranges (10.0.0.0/16 and 10.1.0.0/16) Complete the routing path in both directions

c1193d4 👍 2 Selected: C

C: because TGW routes are NOT propagated to VPC route tables (manual update as to take place)

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

The core issue is that traffic flow requires valid routes in both directions. While the Transit Gateway (TGW) route tables were correctly configured with static routes to peer regions, the VPC route tables within Prod A and Prod B lacked entries for the remote CIDRs. Option C resolves this by adding a broad route (10.0.0.0/8) in the VPC route tables pointing to the local Transit Gateway, ensuring all traffic destined for any AWS network is forwarded to the TGW for routing.

Why the Other Options Are Wrong

Option A is invalid because TGW peering attachments are logical constructs and do not have configurable IP addresses like Direct Connect or Site-to-Site VPNs. Option B is incorrect because route propagation in TGWs sends learned routes from attachments into the TGW route table, but it does not push routes into the VPC route tables; VPCs require manual route updates. Option D is technically impossible as VPC route tables cannot dynamically propagate routes based on TGW state changes in this manner.

Community Comment Notes

Comment [1] highlights that TGW peering relies on static routes and explicitly dismisses options involving IP modification or dynamic propagation to VPCs. Comment [2] reinforces that TGW routes are never automatically propagated to VPC route tables, necessitating manual configuration. Comment [3] validates that the broad CIDR 10.0.0.0/8 covers both specific VPC ranges (10.0.0.0/16 and 10.1.0.0/16), making it a functional, albeit less granular, solution compared to adding two specific routes.

Related Analysis

Practice All ANS-C01 Questions

Access 137 questions with complete answers and detailed explanations.

View Full ANS-C01 Practice Test →

← Back to ANS-C01 Study Guide