Articles
AWS PrivateLink Interview Questions: Endpoints, DNS, and VPC Boundaries
Practice AWS PrivateLink interview questions with endpoint ownership, private DNS, network controls, service authorization, and VPC boundary exercises.
A consumer creates a VPC endpoint for a partner's API. The endpoint appears available, but the application still resolves the API hostname to a public address. A second client connects privately and receives HTTP 403. Are these the same PrivateLink problem?
For AWS PrivateLink interview questions, trace the named destination, the consumer's endpoint path, and the service's authorization decision separately. A private connection is not a general routed bridge between VPCs, and endpoint acceptance is not permission to perform every application action.
This article is for cloud, backend, and infrastructure engineers preparing service-connectivity discussions. AWS documentation supports the mechanics; the resolver matrix and fault-isolation exercise are original synthetic practice, not measurements from an AWS deployment. Start with Explain VPCs and private/public network connectivity, then narrow the drawing from whole-network access to one service connection.
What boundary does AWS PrivateLink create?
Official: AWS's PrivateLink concepts describe private connections through VPC endpoints to services, resources, or service networks. Traffic on those connections stays on the AWS network rather than traversing the public internet.
The important interview distinction is the object being connected. For the traditional interface-endpoint exercise in this article, the consumer gets endpoint network interfaces with private addresses in selected subnets. The application accesses a particular service through those interfaces; it does not gain arbitrary IP reachability to every host in the provider's VPC.
Official: AWS's service-access documentation explains using private DNS so an AWS service's usual hostname can resolve to interface-endpoint addresses. That allows compatible clients to retain the service hostname while taking the private path.
An original design choice follows: use service connectivity when consumers need a specific API, not unrestricted connectivity between all subnets. If the requirements instead call for broad routed communication among networks, compare peering or Transit Gateway on that actual requirement.
Do not turn “private” into “trusted.” A client can reach the endpoint and still lack a valid application identity, tenant permission, or allowed service action. Conversely, an authorized client can time out before any service authorization happens.
Your first diagram should name the consumer application, resolver, endpoint, provider service, and authentication boundary. Each arrow needs a protocol and an owner. Leaving these details out makes every subsequent troubleshooting answer sound like “check the VPC.”
Is every PrivateLink connection an NLB endpoint service?
Official: The traditional endpoint-service creation guide describes a service provider exposing an endpoint service through a Network Load Balancer, or a Gateway Load Balancer for the corresponding appliance pattern. Provider permissions and optional acceptance control which endpoint connections are established.
For the original partner-API scenario, we deliberately choose the Network Load Balancer pattern. The provider owns the listener, target groups, service availability, and acceptance configuration. The consumer owns its interface endpoint and client-side connectivity configuration.
However, that pattern is not a definition of every current PrivateLink capability. Official: AWS's resource-access documentation describes resource endpoints for shared resources through resource configurations and a resource gateway. These can access resources without the traditional load-balancer endpoint-service arrangement.
An interview answer should therefore specify the endpoint type before reciting requirements. Gateway endpoints for Amazon S3 and DynamoDB are another distinct mechanism and do not use PrivateLink. An interface endpoint, resource endpoint, and gateway endpoint should not be treated as interchangeable names.
For preparation, make a small vocabulary card: endpoint type, target object, provider-side construct, consumer-side construct, and DNS behavior. Then apply it to the given scenario. You do not need to list every service integration to demonstrate that the traditional NLB story has a defined scope.
If the prompt mentions cross-Region access, identify the actual supported service configuration and Region choices. Do not repeat an outdated blanket statement that PrivateLink is always same-Region, or promise availability across every service and Region without checking the relevant support.
Explain private DNS with a resolver matrix
Suppose the original partner API is api.partner.example. The consumer endpoint has illustrative private addresses 10.20.1.40 and 10.20.2.40; these are invented values, not live targets. A public client uses a different public service address.
Official: AWS's endpoint-service DNS guide describes provider domain-ownership verification and private hosted-zone behavior for the consumer's private DNS name. This is a DNS naming mechanism, not a transfer of ownership of the consumer's entire resolver configuration.
Use this original matrix:
| Client and resolver context | Expected answer in this exercise | What it does not establish |
|---|---|---|
| Consumer VPC using the configured private DNS path | Consumer endpoint's private addresses | Endpoint SG or provider health is correct |
| Public client using public DNS | Public service address | The VPC client sees the same answer |
| On-premises client with no private DNS forwarding configured | Public answer or failure under its own DNS policy | Creating an endpoint fixed hybrid DNS |
| Consumer client using a custom resolver that bypasses the private zone | Depends on that resolver's configuration | The application uses the intended endpoint |
The table's conditional wording matters. “Private DNS is enabled” is not a complete observation about what the failing process resolved. Record the resolver used by that process, the exact queried name, address family, returned addresses, and observation time.
Official: AWS's interface-endpoint configuration guide requires VPC DNS resolution and DNS hostnames for private DNS and describes endpoint security-group configuration. A checkbox in the endpoint settings is only one part of a working client path.
Now ask whether an application caches a previously resolved public address or uses a proxy with a different resolver. A shell lookup on the same instance is useful but may not reproduce the application's own resolution and connection behavior. Explain what observation would distinguish those paths.
Can you test connectivity by replacing the hostname with an IP?
An IP-targeted probe can answer a narrow transport question, but replacing the hostname changes more than DNS. HTTPS certificate validation, server-name indication, and application routing may depend on the original hostname.
In the original exercise, a direct connection to 10.20.1.40:443 succeeds while a normal hostname request fails. That supports a difference between the two tested paths. It does not justify disabling certificate verification or conclude that the provider's HTTP routing is healthy.
A careful probe preserves the intended hostname while controlling address resolution through a supported test mechanism. Record which part of the request changed. Use an approved test operation so a diagnostic retry cannot duplicate a transaction.
If the API returns HTTP 403, the request reached a component that produced an HTTP response. Determine which component produced it and which identity, action, and tenant it evaluated. Do not add network allowances merely because the status includes the word “forbidden.”
The interview answer should also distinguish a TLS handshake failure, a connection refusal, a timeout, and an application response. These observations locate different boundaries and have different owners. A single “endpoint is broken” label discards the most useful evidence.
Which owner should investigate each failure?
Use an original fault-isolation exercise with a known-good comparison client. Both call the same hostname and operation, but one runs from a newly added subnet. Keep credentials and request data equivalent where safe so you do not accidentally compare two authorization contexts.
First record the actual resolved destination. If it is public for the failing client and private for the comparison, start with DNS scope, resolver configuration, and application caching. Provider target health cannot explain why the client chose a different address.
Second inspect the consumer's path to the endpoint interface. Confirm the intended endpoint, its subnet placement, relevant client and endpoint security groups, and subnet controls. A group attached to a similarly named endpoint is not evidence about the interface the client actually contacted.
Third verify connection state and provider configuration. In the selected NLB pattern, check acceptance where required, enabled service Availability Zones, listeners, target health, and the chosen request protocol. Creating an endpoint does not create a healthy backend process.
Fourth evaluate service authorization. Official: AWS's endpoint-policy guide says endpoint policies do not override or replace identity or resource policies. Not every AWS service supports them; endpoints for non-AWS endpoint services use different access-control expectations.
For the partner API, do not invent an IAM endpoint policy as the sole application authorization mechanism. The API may authenticate and authorize requests itself. Name the real control and its owner instead of applying an AWS-service pattern to a custom service by analogy.
The practical output is an evidence record: client, resolver result, endpoint ID, connection state, transport result, response producer, and authorization context. It is much more reviewable than a list of ten services that “might be involved.”
Does overlapping VPC address space make this a routed solution?
Service-level connectivity can be useful when full network routing would be awkward, but that does not transform PrivateLink into a general CIDR-overlap resolution system. For the interface-endpoint model, the consumer connects to addresses in its own VPC and the provider exposes the chosen service.
An original follow-up asks whether the provider can initiate arbitrary connections back to the consumer's hosts. Do not draw a reverse whole-VPC bridge just because responses travel back on an established service connection. Response traffic and independently initiated reachability are different requirements.
Likewise, connecting several consumer VPCs to a provider does not establish transitive connectivity among the consumers. If the design needs a worker in consumer A to reach a database in consumer B, explain that as a separate requirement and select a supported architecture for it.
For identity-sensitive services, distinguish the source address seen by the provider from a verified customer identity. In the NLB endpoint-service pattern, AWS documents source-address and Proxy Protocol considerations. Do not use a guessed consumer IP as a substitute for authentication or tenant authorization.
What should an availability answer include?
Name the endpoint and service's selected Availability Zones, client behavior across returned addresses, and the provider's healthy capacity. Multiple interfaces alone are not proof that every zonal path serves the same application contract.
In an original failure drill, one endpoint address is reachable and one path has an unhealthy provider target. Explain what the client does when it receives both addresses: connection timeout, bounded retry, address reselection, and safe operation replay. Do not promise a specific failover time without a measured test.
The local preparation model evaluates named states and expected next checks. It does not create network interfaces, validate AWS DNS propagation, or measure NLB failure behavior. A real deployment test would need the actual endpoint type, Region, resolver topology, and provider configuration recorded alongside results.
Sources and Further Reading
Official documentation checked October 1, 2026. The illustrated interface-endpoint scenario is deliberately narrower than the full current PrivateLink product family.