You need to expose an internal service to a partner organisation. VPC peering or a private endpoint service? Justify.
Show the full answer Hide the answer
What the interviewer is testing
Whether you know the asymmetry between these mechanisms, which is what makes one suitable for partner exposure and the other not.
Why peering is wrong here
Peering joins two networks. It creates bidirectional reachability at the network layer, subject only to routing and security group configuration — which means the partner's network can potentially reach far more of yours than the one service you intended, and yours can reach theirs.
It also requires non-overlapping address ranges, which you do not control and which frequently conflict, and it does not scale: peering is point to point, so twenty partners is twenty peerings with twenty address-range negotiations.
Why a private endpoint service is right
It projects a single service into the consumer's network as an address, and traffic flows one way only. The provider gains no visibility of or access to the consumer's network, and the consumer reaches exactly one service.
That asymmetry is precisely what partner exposure requires. It also avoids the address range problem entirely, since no routing is joined, and it scales to many consumers without additional network design.
Why not a public API with mTLS
It is a legitimate option and is what most partner integrations actually use. Compared to a private endpoint it exposes the service to the internet — so it must withstand scanning, denial of service and credential attacks — and it depends entirely on the authentication being correct.
For a high-value internal service where the partner is on the same cloud provider, private connectivity removes that exposure. For a partner on a different provider or on premises, a public API with mTLS plus network restrictions, or a dedicated link, is the practical answer.
What a strong answer adds
The controls that go with either choice: authorisation at the service against the partner's identity (the network path is not an authorisation), rate limiting per partner, a documented contract with versioning, and audit logging of everything the partner accesses.
And the DNS detail that causes most private endpoint troubleshooting: split-horizon resolution must be configured correctly or connectivity fails in ways that look like a network problem.
Common weak answers
Peering because it is familiar. Choosing based on which is cheaper without addressing the reachability asymmetry.