Two city VPCs need private routing between them without hairpinning traffic through the public internet. Which construct provides that private connectivity?
Select an answer to reveal the explanation.
Short Explanation
VPC peering is a private bridge between two city neighborhoods in the cloud—traffic stays off the public internet hairpin. You get private routing between the VPCs without publishing everything to the world. Open security groups and email exports are not a private network path.
Full Explanation
VPC peering establishes private IP connectivity between virtual private clouds so packets can route without traversing the public internet. Two city VPCs—such as a permitting environment and a payments or GIS environment—that must exchange data privately commonly use peering when the relationship is simple, bilateral, and does not require a large hub-and-spoke mesh. Public IP NAT of every packet between the VPCs across the open internet adds exposure, cost, and complexity contrary to the private-routing goal. Emailing configuration exports between teams is not a network data path and cannot sustain application traffic. Exposing both VPCs with wide-open security groups and no private routes increases attack surface instead of creating controlled private connectivity. Exam caveat: classic peering is typically non-transitive through a third VPC, and overlapping CIDR blocks prevent or break peering—Cloud+ expects candidates to know those limitations when designs grow beyond two networks. Operational check: ensure non-overlapping CIDR plans, create the peering and update route tables in both directions, tighten security groups and network ACLs to required ports only, test DNS and application flows, and document the peering in the city’s network diagram before cutover.