A storage connection works from an Azure virtual machine but fails from an office laptop. Both applications use the same hostname, and the private endpoint says Approved. That is not enough to conclude that the laptop uses the same route. Start with the DNS answer seen by each client, then investigate the path that answer selects.
A private endpoint supplies a private network interface for access to a supported service. It does not make every client discover that interface automatically. The diagnostic sequence below uses Azure Storage as its example; other services have different private DNS zones and subresources.
Separate three kinds of failure
| Observation | Useful evidence | Next investigation |
|---|---|---|
| Hostname resolves to an unexpected public IP | Query result and DNS server used by the failing client | Private zone visibility and DNS forwarding |
| Hostname resolves to the expected private IP, but connection times out | Endpoint IP, connection status, and the client's network path | Routing and applicable network controls |
| Service responds with an access error | Exact response, requested operation, and identity | Service authorization and access settings; do not assume DNS is broken |
Treat these as investigation starting points rather than a complete error-code decoder. A successful DNS lookup does not prove network connectivity, and a private IP does not grant permission to read data. Keep the observed response alongside the hypothesis so that a later test can disprove your first explanation.
Query the normal service hostname
For Blob Storage, query the account's normal service name from the environment where the application fails. Replace the placeholder below with your own account name. The command is a diagnostic example, not output captured from a CertGrid-operated lab.
nslookup YOUR_ACCOUNT.blob.core.windows.netRecord the answering DNS server, aliases, and final IP address. Compare the result with the private endpoint's network interface, not merely with your expectation that any private address must be correct. Repeat from a working client and keep the results side by side.
Azure Storage clients should continue using the normal service connection string. Do not switch the application to a privatelink subdomain URL or a hard-coded IP as the standard fix. DNS is intended to resolve the normal hostname to the appropriate endpoint for that client's environment.
Check the private DNS zone and its consumers
Confirm the service's recommended private DNS zone, the endpoint's record, and the VNet links that make the zone available to the intended clients. A zone existing somewhere in the subscription does not demonstrate that the failing client's resolver can use it. Check the configured DNS path before creating a second zone with the same name.
For a client using custom DNS, the query first follows that resolver's configuration. For on-premises clients, inspect the forwarding design and connectivity to the Azure-side resolver. Microsoft documents patterns using Azure DNS Private Resolver or a DNS forwarder. Follow the service-specific zone guidance rather than forwarding arbitrary suffixes or assuming VNet peering alone establishes DNS resolution.
Verify the endpoint matches the requested service
An Azure Storage account exposes several services. A private endpoint for Blob Storage is not automatically a private endpoint for Azure Files. Match the application's hostname and operation to the configured target subresource, and check the connection's approval status. Some workloads require access to more than one storage service.
Also separate private connectivity from the public-access policy. Creating a Storage private endpoint does not automatically disable its public endpoint. Public network restrictions need their own deliberate configuration. Do not enable public access simply to make an unresolved private-path failure disappear.
Work through a two-client example
Suppose a study VM resolves the account hostname to the expected endpoint IP, while a laptop using corporate DNS receives a public address. Your first useful difference is the resolver path, not the users' data permissions. Record which DNS server answered each request, then inspect whether the corporate resolver forwards the relevant queries to a resolver that can see the private zone.
After correcting an evidenced DNS problem, repeat the lookup and the original application operation. If resolution now matches but the operation still fails, retain the DNS result and move to the next layer. This avoids undoing a valid DNS correction while chasing an unrelated authorization issue.
- Write the expected hostname, subresource, and private endpoint IP.
- Capture the failing client's actual DNS answer and resolver.
- Compare with a working client, if one exists.
- Check zone records, VNet links, and custom forwarding along the observed path.
- Retest the same operation and record what changed, including any new error.
Continue with the AZ-104 study guide for networking coverage. The Azure RBAC, Policy, and resource locks comparison helps keep permission and governance decisions separate from connectivity. For storage availability choices, use the Azure redundancy comparison.