SOA-C02 Networking and Content Delivery Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Create a single Transit Gateway route table and add routes for all VPCs and the on-premises network.

  Why it's wrong here

  A single Transit Gateway route table forces every VPC attachment and the on-premises attachment into one shared routing domain. With overlapping CIDRs, the TGW cannot uniquely resolve destinations because multiple VPC attachments advertise the same prefix, creating ambiguous next hops and unpredictable routing. Additionally, all VPCs would be able to route to each other, violating the isolation requirement. This design also propagates on-premises routes identically to all VPCs, but the fundamental flaw is that overlapping prefixes cannot coexist in one table.

• ✓

  Create multiple Transit Gateway route tables: one for each group of VPCs that need to communicate, and associate each VPC attachment with the appropriate route table. Add static routes to the on-premises network in each route table.

  Why this is correct

  Create separate Transit Gateway route tables, one per group of VPCs that must communicate, and associate each VPC attachment with its group's route table. Within each route table, add static routes pointing to the on-premises network (or propagate from the VPN/DX attachment) so every group retains reachability to the data center. Because route tables are independent, overlapping CIDRs across groups are never compared, avoiding routing conflicts; traffic between groups is denied by default since no routes exist. This gives you transitive routing within a group and full isolation between groups, which is exactly what the scenario demands.

• ✗

  Use VPC peering instead of Transit Gateway to connect VPCs, and use Direct Connect Gateway for on-premises connectivity.

  Why it's wrong here

  VPC peering does not support overlapping CIDR ranges—you cannot create a peering connection between VPCs whose CIDRs overlap, so the core requirement is impossible. Peering is also non-transitive, meaning you would need a mesh of connections, and it does not offer a hub-and-spoke model with route-table isolation. Adding a Direct Connect Gateway only manages DX-based connectivity to on-premises; it does not provide inter-VPC routing or segmentation. Thus this combined approach fails on both overlapping CIDRs and isolation.

• ✗

  Configure VPN connections between each VPC and the on-premises network, bypassing Transit Gateway.

  Why it's wrong here

  Establishing individual VPN connections from each VPC to the on-premises network creates a set of point-to-point links that do not enable inter-VPC communication; VPCs would still be isolated from one another unless you also add separate peering or routing. Overlapping CIDRs remain problematic because on-premises routers cannot distinguish identical prefixes from different VPCs, and each VPN tunnel would carry conflicting routes. This approach adds operational complexity and per-VPN cost without delivering the centrally managed, isolated hub-and-spoke architecture that Transit Gateway provides. It also leaves the requirement for isolated communication groups entirely unaddressed.

Go deeper

Related to this question