Connecting two VPCs privately

WHAT THIS TESTS The interviewer wants to see that you know more than one way to connect VPCs and can reason about scale, security blast radius, and CIDR constraints rather than reaching for a single default.

A GOOD ANSWER COVERS The first method is VPC peering, a direct private link between the two VPCs. It is cheap, low latency, and simple, but it is non-transitive, so a third VPC cannot reach prod through dev. As the number of VPCs grows, peering becomes an unmanageable full mesh, and it fails if the two CIDR ranges overlap. The second method is a Transit Gateway, a central hub that all VPCs attach to, giving hub-and-spoke routing that scales to hundreds of VPCs with centralized control, at higher cost and a small added latency hop. A third, tighter option is PrivateLink or a private service endpoint, which exposes only the monitoring service rather than the whole VPC, works across overlapping CIDRs, and gives the smallest blast radius. The right choice depends on how many VPCs you expect and how much of the network you want to expose.

COMMON WRONG ANSWERS Proposing only peering and ignoring its non-transitivity and mesh explosion. Forgetting that overlapping CIDR ranges block peering and Transit Gateway routing. Suggesting a public path or internet gateway, which defeats the requirement for private access.

LIKELY FOLLOW-UPS How do you handle overlapping CIDRs? How does routing differ between peering and a Transit Gateway? When is PrivateLink the only clean option?

ONE CONCRETE EXAMPLE With just dev and prod, peering is the simplest fit. But if you only want dev to reach the monitoring service and nothing else in prod, PrivateLink exposes that one endpoint, keeps the rest of prod invisible, and tolerates overlapping address space.