SAP-C02 - Design Solutions for Organizational Complexity (26% of the exam) - Section 1.1

Architect connectivity across many VPCs and accounts using AWS Transit Gateway, VPC peering and AWS PrivateLink, balancing transitive routing, segmentation and scale.

Describe how AWS Transit Gateway, VPC peering, and AWS PrivateLink each handle transitive routing and traffic segmentation at scale. Choose between them by weighing hub-and-spoke topology, endpoint scope, and cross-account reachability requirements.

AWS Transit GatewayVPC peeringAWS PrivateLinkTransitive routing

Practice question for this objective

Free sampleDesign Solutions for Organizational Complexityhard

A company runs roughly 50 application VPCs across several accounts, all attached to a central Transit Gateway. Many of these VPCs call the same AWS service APIs privately, and each VPC currently provisions its own set of interface VPC endpoints for those services. A cost review shows the per-endpoint hourly charge multiplied across 50 VPCs is now significant, and the platform team wants to keep traffic private to the service while drastically cutting the number of interface endpoints and the ongoing management of them. Which design MOST cost-effectively delivers private service access at this scale?

AReplace the interface endpoints with gateway VPC endpoints in every application VPC, since gateway endpoints carry no hourly charge and can front the same set of AWS service APIs the VPCs call.
BHost one shared set of interface VPC endpoints in a central VPC attached to the Transit Gateway, route the application VPCs to it through the Transit Gateway, and resolve the endpoint names centrally for all spokes. Correct
CEstablish VPC peering from each application VPC to one endpoint-hosting VPC so the shared interface endpoints are reachable, accepting a full mesh of peering connections to every spoke.
DKeep an interface endpoint in each VPC but switch them to private DNS disabled, which removes the hourly charge while still routing the application traffic privately to the AWS services.

Share one central set of interface VPC endpoints across many spokes over the Transit Gateway to cut per-VPC PrivateLink endpoint cost at scale. Interface VPC endpoints bill per endpoint per hour, so hosting a single shared set in a central VPC and reaching them from spokes through the Transit Gateway, with central DNS resolution, keeps service traffic on AWS PrivateLink while eliminating dozens of duplicated endpoints and their recurring charges.

Why A is wrong: Gateway VPC endpoints are free but support only Amazon S3 and DynamoDB, so they cannot replace interface endpoints for the broader set of service APIs these VPCs consume.

Why B is correct: Centralising the interface endpoints in one shared VPC and reaching them over the Transit Gateway collapses 50 duplicated endpoint sets into a single managed set while keeping service traffic private and inherited by new spokes.

Why C is wrong: A full peering mesh to 50 spokes reintroduces exactly the point-to-point sprawl the Transit Gateway exists to avoid, adding many connections and route entries rather than reducing management overhead.

Why D is wrong: Disabling private DNS only changes name resolution behaviour and does not remove the per-endpoint hourly charge, so the 50 duplicated endpoints and their cost remain in place.

See more SAP-C02 practice questions, answers explained.

Exam traps in Design Solutions for Organizational Complexity

Answers that look right on this material and are not. Each one is a distractor from a different question in the SAP-C02 bank for this domain.

Create a full mesh of VPC peering connections between every pair of VPCs and add the shared services VPC as another peer, relying on the peering links for any VPC to reach any other VPC directly.
Why it is wrong: A peering mesh seems to give any-to-any reachability, but peering is non-transitive and the number of links grows roughly with the square of the VPC count, which becomes unmanageable well before 200 VPCs.
Create inter-Region VPC peering connections between each pair of VPCs that must communicate and add the matching routes, leaving each regional Transit Gateway to handle only its own in-Region traffic.
Why it is wrong: Inter-Region VPC peering keeps traffic on the backbone but it scales as a per-VPC-pair mesh, defeating the hub model and multiplying the peerings and route entries the team must manage.
Create a private virtual interface and a Direct Connect gateway for every VPC, then peer the VPCs to one another so each account manages its own dedicated route back to the on-premises data centre.
Why it is wrong: Per-VPC private virtual interfaces work for a few VPCs, but with more than forty VPCs this multiplies configuration and hits virtual interface limits, which is the opposite of minimal per-VPC effort as accounts grow.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.