A county needs separate VPCs for assessor, courts, and public works that must reach a central shared-services VPC for Active Directory and logging without creating a full mesh of VPC peerings. Which connectivity design best meets this requirement?
Select an answer to reveal the explanation.
Short Explanation
Think of Transit Gateway like a county road hub instead of paving a driveway from every building to every other building. Each VPC attaches once, shared services sit in the middle, and route tables decide who can talk to whom. Full-mesh peering gets ugly fast as departments multiply.
Full Explanation
For multi-VPC municipal connectivity, AWS Transit Gateway is the scalable hub that lets assessor, courts, and public works each attach once while shared services for Active Directory and logging sit on a controlled spoke or hub attachment. Transit Gateway route tables then advertise only the paths the county intends: spokes reach shared services, and spoke-to-spoke traffic stays denied unless an explicit policy requires it. That hub-and-spoke model avoids the operational and limit pressure of building a full mesh of VPC peering links as departments multiply, and it keeps blast-radius and routing policy centralized in one place the network team can audit.
Full-mesh peering among every department VPC and shared services fails the stated requirement because it recreates the N-squared attachment problem the county wants to escape; peering also does not provide the same centralized route-table segmentation model Transit Gateway offers for many spokes. Collapsing all department workloads into one shared VPC with security groups alone weakens account and network blast-radius isolation that separate VPCs were meant to provide, and it does not create a clean shared-services connectivity pattern when organizational boundaries matter. Fronting Active Directory and logging through public Application Load Balancers over the internet exposes directory and telemetry planes to the public edge, which contradicts typical private shared-services designs for county identity and audit pipelines.
Exam caveat: VPC peering is neither transitive nor a substitute for Transit Gateway when many VPCs must share centralized services under controlled routing; on SAP-C02, prefer Transit Gateway (or PrivateLink for service-style exposure) over mesh peering once spoke count and policy complexity grow. Operational check: after attaching the department and shared-services VPCs, verify each spoke’s Transit Gateway route table contains only the intended shared-services prefixes, confirm spoke-to-spoke routes are absent where isolation is required, and test AD and logging reachability from a host in each department VPC while proving a sandbox spoke cannot route to courts.