A company has three VPCs in the same AWS region: VPC A (production), VPC B (development), and VPC C (shared services). The VPCs have overlapping CIDR blocks (e.g., VPC A: 10.0.0.0/16, VPC B: 10.0.0.0/16, VPC C: 10.1.0.0/16). The SysOps administrator needs to enable private IP communication between VPC A and VPC C, and between VPC B and VPC C, but not between VPC A and VPC B. The solution must also support a growing number of VPCs in the future. Which AWS service should be used?

Use AWS Transit Gateway with attachment route tables that isolate traffic between VPCs, ensuring that VPC A and VPC B routes are separate.

Transit Gateway can segregate traffic using separate route tables, but overlapping CIDR blocks (VPC A and VPC B both have 10.0.0.0/16) cause routing ambiguity. While the route tables can prevent direct communication, traffic destined to VPC C (unique CIDR) works, but the overlapping issue complicates routing and may lead to unpredictable behavior. Transit Gateway is not recommended for overlapping CIDRs.

Create two VPC peering connections: one between VPC A and VPC C, and one between VPC B and VPC C.

VPC peering does not support overlapping CIDR blocks. If VPC A and VPC B both have CIDR 10.0.0.0/16, they cannot peer with VPC C if VPC C's CIDR also overlaps? VPC C is 10.1.0.0/16, no overlap. The peering between VPC A and VPC C would work, but VPC A's route table would need a route to VPC C (10.1.0.0/16) via the peering connection. However, if VPC A has a subnet 10.0.0.0/24, and VPC B has a subnet 10.0.1.0/24, traffic from VPC A to 10.0.1.0/24 would be sent to the peering connection if a route exists, but that's only for VPC C? This is messy. VPC peering requires non-overlapping CIDRs to function correctly because if VPC A has 10.0.0.0/16 and tries to reach 10.0.1.0/24 (which is in VPC B, but they are not peered), it will route locally. But with VPC C, peering is fine. However, VPC peering does not scale well for many VPCs as it requires full mesh or hub-and-spoke. This option is valid but less scalable and may have issues if future VPCs have overlapping CIDRs.

Set up two AWS Site-to-Site VPN connections from VPC C to VPC A and VPC B using virtual private gateways.

Site-to-Site VPN is designed for connecting on-premises networks to AWS, not for VPC-to-VPC connectivity. While it could technically work, it is not optimal for within-region VPC connectivity due to higher latency, cost, and complexity. Also, overlapping CIDRs still cause routing issues.

What does this SOA-C02 question test?

CIDR notation defines the prefix length.

What is the correct answer to this question?

The correct answer is: Use AWS PrivateLink by creating a Network Load Balancer in VPC C and configuring VPC endpoints in VPC A and VPC B to access the services. — VPC peering does not support overlapping CIDR blocks. AWS Transit Gateway supports multiple VPC attachments and can route traffic based on route tables, but it still cannot resolve overlapping IP addresses; you cannot have two VPCs with identical CIDR blocks communicating directly because the Transit Gateway would not know which VPC to forward traffic to for a given IP. However, the question says VPC A and VPC B both have 10.0.0.0/16, and they do not need to communicate directly. VPC C has 10.1.0.0/16, so VPC C is unique. VPC A and VPC B can each connect to VPC C as long as they use different route tables. But the overlapping CIDR issue still exists: if VPC A sends traffic to an IP in 10.0.0.0/16, Transit Gateway would route based on the most specific route; but since both VPC A and VPC B use the same CIDR, the Transit Gateway cannot distinguish. However, for traffic from VPC A to VPC C (which is 10.1.0.0/16) there is no conflict. Similarly from VPC B to VPC C. The problem arises if VPC A wants to reach an IP in 10.0.0.0/16 that might be in VPC B, but that is not required. Transit Gateway can handle this by using different route tables for VPC A and VPC B: each route table will have a route for 10.1.0.0/16 pointing to the VPC C attachment, and a route for the local VPC's CIDR pointing to the local attachment (or blackhole). But VPC A's route table might have a route for 10.0.0.0/16 pointing to local, but if VPC A tries to reach an IP in 10.0.0.x, it will be routed locally within VPC A. So Transit Gateway can work. However, AWS recommends that for overlapping CIDRs, you use solutions like NAT or PrivateLink, but Transit Gateway has limitations. The better answer for today's AWS architecture is to use AWS PrivateLink to allow VPC A and VPC B to access services in VPC C via Network Load Balancer endpoints. This avoids routing issues due to overlapping CIDRs and is scalable. Transit Gateway with Network Manager could work, but overlapping CIDRs are not recommended and require careful route table design and may cause asymmetric routing. The question says 'supports growing number of VPCs' - Transit Gateway is designed for that. But given the overlapping CIDR issue, PrivateLink or VPN might be more appropriate. However, PrivateLink requires services in VPC C to be exposed via NLB and endpoints in VPC A and B. This is a valid solution and avoids CIDR overlap. AWS PrivateLink supports inter-VPC communication without peering or transit gateway, and it works with overlapping CIDRs because it uses private IP addresses in the endpoint's subnet. So this is likely the correct answer. Option: Use AWS PrivateLink with Network Load Balancers in VPC C and VPC endpoints in VPC A and VPC B. That meets all requirements.

What should I do if I get this SOA-C02 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.