SAP-C02 Practice Question: Design Solutions for Organizational Complexity

A company has a multi-account AWS environment with a central network account and multiple workload accounts. They want to use AWS Transit Gateway to connect VPCs across accounts. The network team has created a Transit Gateway in the network account and shared it using AWS Resource Access Manager (RAM) with the workload accounts. The workload accounts have created VPC attachments to the Transit Gateway. However, traffic is not flowing between the VPCs. The route tables in the workload VPCs have routes pointing to the Transit Gateway. What is the most likely cause?

⚠ Common exam trap

SAP-C02 often tests the shared responsibility of Transit Gateway routing, and candidates may assume that attaching a VPC automatically adds routes to the Transit Gateway route table, when in fact propagation or static routes are required.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The Transit Gateway route tables do not have routes for the attached VPCs.

For traffic to flow between VPCs attached to a Transit Gateway, the Transit Gateway route tables must have routes for the attached VPC CIDRs. When a VPC is attached, a route to the VPC is not automatically added to the Transit Gateway route table unless route propagation is enabled or a static route is created. The most likely cause is that the Transit Gateway route tables lack routes for the attached VPCs, preventing traffic from being forwarded between them.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The Transit Gateway is in a different AWS account, so route propagation is not automatic.
Why it's wrong here
Route propagation into a Transit Gateway route table is never automatic regardless of account ownership; attachments must be associated and routes propagated or added statically. It tempts those assuming cross-account sharing changes behaviour, but the same manual configuration is required whether the Transit Gateway is local or shared via RAM.
✓
The Transit Gateway route tables do not have routes for the attached VPCs.
Why this is correct
Attachment alone does not enable routing. The Transit Gateway's route table must contain routes associating each VPC attachment, otherwise packets arriving from one VPC have no path to the other attachments, even though the workload VPC route tables correctly target the gateway.
✗
The security groups in the workload VPCs are blocking traffic.
Why it's wrong here
Security groups filter traffic at the elastic network interface, but the stem describes no connectivity at all between VPCs, which points to Transit Gateway route table associations and propagations rather than stateful filtering. It tempts troubleshooters who default to security groups, yet those would be the cause only after routing is confirmed working.
✗
VPC flow logs are not enabled.
Why it's wrong here
Flow logs only record metadata about IP traffic; they neither permit nor block packets, so enabling them cannot restore connectivity. They are tempting because they diagnose reachability problems, and would be the right choice when you need to confirm whether traffic reaches an attachment before troubleshooting Transit Gateway route table associations and propagations.

Visual reference

Go deeper

SAP-C02 Practice Question: Design Solutions for Organizational Complexity

Why each option matters

Option-by-option breakdown

Related to this question