A city wants an internal management API to be reachable only from inside its VPCs using Interface VPC endpoints and private DNS, with no public service endpoint exposure. Which approach best matches that requirement?
Select an answer to reveal the explanation.
Short Explanation
Private endpoints are like an employees-only service window inside City Hall—Interface VPC endpoints plus private DNS keep the API on the inside track. Press-release public NLBs and laptop SSH tricks are the opposite of private-by-design.
Full Explanation
An internal management API that must be reachable only from inside city VPCs should use Interface VPC endpoints with private DNS so clients resolve the service to private endpoint IPs and traffic stays on AWS private networking (PrivateLink-style patterns) rather than traversing a public regional endpoint. Private DNS ensures standard SDK/hostname usage continues to work while Route Tables and security groups confine access to approved VPC CIDRs and roles. That is the textbook private-by-design pattern for management planes that must never appear on the public internet.
Publishing the API on a public Network Load Balancer open to 0.0.0.0/0 and distributing the URL in a press release fails confidentiality and the private-only requirement outright. Hosting the API only on the account root user’s laptop with SSH port forwarding fails availability, auditability, and identity governance—it is not an architecture. Disabling private DNS and forcing developers to hard-code public regional endpoints fails the private-resolution goal and reintroduces public exposure habits.
Exam caveat: interface endpoints create ENIs that need SG rules allowing client subnets on the service ports; forgetting those rules looks like "PrivateLink is broken" when it is simply filtered. Operational check: from a VPC instance, resolve the API hostname to private addresses, confirm connectivity without an IGW/NAT path to the public endpoint, and from outside the VPC verify the management API is unreachable.