‹ All SAP-C02 questions

SAP-C02 Practice Question 21: Shared VPC Subnets RAM

AWS Certified Solutions Architect – Professional (SAP-C02) · Test 3 · question 1 of 10

Organizational Complexitymedium

A retailer runs 25 AWS accounts in one organization in AWS Organizations, one per product team. Each team built its own VPC, and the RFC 1918 range that the enterprise network group allocated to AWS is almost exhausted; every VPC burns a /20 even when the team only runs a handful of instances. The teams' applications are chatty with one another and the current mesh of VPC peering connections has become unmanageable.

The platform group wants a design where a small central network account owns the CIDR, the route tables, the NAT gateways, and the Transit Gateway attachment, and product teams cannot change any of them. Product teams must still launch and manage their own EC2 instances, RDS databases, and Lambda functions in their own accounts, so that each team keeps its own bill, its own IAM boundaries, and its own CloudFormation stacks. Traffic between two teams' instances must stay inside a single VPC rather than crossing a peering or Transit Gateway hop.

Which design meets these requirements?

Select one answer
Show answer and explanation

Answer:

  • B. Build one VPC in the central network account, share the application subnets with the product accounts through AWS Resource Access Manager, and have each team launch its resources into the shared subnets from its own account

VPC sharing is built for exactly this split of responsibilities. The owner account creates the VPC and shares individual subnets with participant accounts in the same organization through AWS Resource Access Manager. Participants can then create, modify, and delete their own application resources (EC2 instances, RDS databases, Lambda functions) inside those subnets from their own accounts, so billing, IAM, and deployment stacks stay per-team. Participants cannot view or touch resources belonging to other participants or to the owner, and they cannot modify the VPC, its subnets, or its route tables, which is what keeps the network account in control. Because every team lands in one VPC, cross-team traffic uses the VPC's implicit local routing with no peering or Transit Gateway hop, and the organization consumes one CIDR block instead of 25.

Option A fixes the peering mesh but not the addressing problem; every team still holds a whole VPC CIDR, and inter-team traffic now pays a Transit Gateway attachment and per-GB processing charge for what could be intra-VPC traffic.

Option C collapses the accounts rather than the VPCs. Resources created under an assumed role live in the network account, so their cost lands on the network account's bill, they share one set of service quotas, and each team's blast radius is no longer bounded by an account.

Option D is not a design AWS supports. Transit Gateway does not NAT overlapping VPC CIDRs; a transit gateway route table cannot hold two identical, overlapping destinations for different attachments and resolve them, so overlapping VPCs cannot route to each other this way.

Reference: Share your VPC subnets with other accounts

Practice Test 3 ›

Study guides for SAP-C02