A county application team proposes peering every microservice VPC to every other microservice VPC. The architect must recommend a scalable alternative for multi-VPC connectivity. What should the architect recommend?

When a county application team proposes peering every microservice VPC to every other microservice VPC, the architect should recommend a Transit Gateway hub-and-spoke model (or shared services plus controlled attachments) instead of an unscalable full mesh. Each microservice VPC attaches to the Transit Gateway once; central route tables and optional inspection govern who can reach whom. That design scales as services multiply, respects peering connection practical limits, and keeps policy reviewable in one networking plane rather than in dozens of pairwise peering connections.

Approving full-mesh peering because “limits never constrain municipal designs” ignores both hard peering quotas and operational toil; meshes become unmanageable quickly. Merging every microservice into a single account and single subnet eliminates routing decisions by destroying isolation and blast-radius boundaries the microservices were split to obtain. Replacing private connectivity with public ALBs for every east-west call exposes internal service traffic and replaces private service networking with an internet-edge pattern inappropriate for service-to-service chatter.

Exam caveat: VPC peering is non-transitive—teams sometimes build meshes to fake transitivity; Transit Gateway is the exam’s scalable transitive hub when many VPCs must interconnect under control. Operational check: migrate a pilot set of microservice VPCs to Transit Gateway attachments, remove pairwise peerings, verify allowed service paths and denied cross-talk via route tables and security groups, and document attachment standards for the next services that onboard.