An Azure Storage private endpoint acceptance procedure covering DNS, endpoint approval, public network controls, Entra data permissions, and Data Lake blob and dfs paths. It distinguishes a private route from permission to read data.
At a glance
Key findings
- A private endpoint targets a particular resource and subresource. Approval and DNS resolution do not grant the caller data access.
- Creating a private endpoint does not by itself turn off the storage account's public endpoint. Review public network settings separately.
- Test with the application's actual identity and resolver path, including blob and dfs endpoints where the Data Lake operations require both.
Name the resource and the operation under review
A private endpoint displayed as approved can coexist with a failing application or a public access path that nobody intended to retain. The endpoint status answers a narrower question than whether the storage design is complete. Begin with the storage account, required operation, caller identity, service hostname, and network location. Those details define a testable access path instead of a general claim that storage is private.
Azure private endpoints expose a private network interface for a specified resource and subresource, subject to the connection's approval state. Microsoft also distinguishes private endpoint connectivity from the resource's separate public access controls. Record the exact target and connection state; a similarly named endpoint in the right virtual network is not enough to establish that it serves the intended storage operation. [1]
Use a small synthetic object and an explicitly permitted operation for the acceptance fixture. Identify the application environment that will perform it, not just the machine used to configure the resource. Include the person responsible for the storage account and the person responsible for network resolution. Many ambiguous failures become easier to investigate once the target, identity, and ownership are written down together.
Follow the normal hostname from the application
Microsoft directs Storage clients to keep using their ordinary service connection strings and hostnames with private endpoints. DNS determines how the name reaches the private address from the relevant environment. Replacing application configuration with a privatelink hostname is not the documented general pattern. Inspect the ordinary name as the application sees it rather than treating a hand-selected private address as a complete test. [2]
Resolve the hostname from the application's actual environment and record the answer, resolver path, and relevant private DNS zone relationship. Hybrid resolvers and forwarding arrangements need deliberate configuration. Microsoft documents service-specific DNS mappings and configuration options; selecting the right zone name is only part of ensuring that a particular application uses the intended resolution path. [3]
A public DNS answer from an unrelated laptop does not establish that unauthorized users can read the account. Conversely, a private answer inside the virtual network does not establish that the caller has data permissions. Keep DNS observations separate from the subsequent connection and storage response. This avoids turning either a name-resolution screenshot or a public hostname into an unsupported exposure finding.
A private path still ends in an authorization decision
Private routing, public endpoint restrictions, and data permissions are separate controls.
Source. Microsoft private endpoint, Storage DNS, network security, and Entra authorization documentation [1][2][3][4][5].
Method. Original access-path schematic and acceptance matrix. The cases are proposed tests, not observed results. A public DNS answer alone is not treated as evidence of unauthorized data access.
Accessible table and figure data
| Boundary | Positive case | Separate negative case |
|---|---|---|
| Private DNS and endpoint | Application reaches the intended subresource | Wrong or missing private resolution is diagnosed |
| Public network setting | Behavior matches the selected public-access policy | Disallowed external location cannot use the public path |
| Data authorization | Application identity performs the permitted operation | Wrong identity is denied on the private path |
| Data Lake subresources | Required blob and dfs operations succeed | Missing subresource path is identified explicitly |
| Boundary | Positive case | Separate negative case |
|---|---|---|
| Private DNS and endpoint | Application reaches the intended subresource | Wrong or missing private resolution is diagnosed |
| Public network setting | Behavior matches the selected public-access policy | Disallowed external location cannot use the public path |
| Data authorization | Application identity performs the permitted operation | Wrong identity is denied on the private path |
| Data Lake subresources | Required blob and dfs operations succeed | Missing subresource path is identified explicitly |
Test public access as an independent setting
A storage account's network rules govern access through its public endpoint, while authorized private endpoint traffic follows the private path. Microsoft emphasizes that permitted network access still needs appropriate authorization. Review the selected public network setting and any applicable exceptions instead of assuming that creating a private endpoint removed the public route. [4]
If the intended policy disables public network access, test that policy from a controlled location outside the private path using a synthetic identity that otherwise has permission for the fixture. Keep the credential secret and the operation harmless. An unauthorized identity failing outside the network does not isolate the network restriction; it may simply demonstrate a data authorization failure that would happen anywhere.
If public access is intentionally limited rather than disabled, document the permitted networks and relevant exceptions, then choose cases that distinguish allowed from disallowed locations. Record the public path's expected behavior in the same acceptance record as the private path. This makes an intentional operational dependency visible and prevents a future reviewer from interpreting a configured exception as either an accident or a universal bypass.
Use the identity that reads the data
For Blob Storage with Microsoft Entra authorization, data access roles are distinct from ordinary management roles. Microsoft notes that management access does not automatically grant blob data permissions through Entra. The portal may also use Shared Key when the operator can list account keys. A successful portal read can therefore exercise a different authorization path from the managed identity used by an application. [5]
Run the fixture with the application's actual authentication method and intended role scope. Record the identity identifier, resource scope, operation, and sanitized outcome. Include a controlled identity that should be denied on the private network. That negative case demonstrates the data boundary separately from connectivity, and it helps detect an accidental assumption that everything inside the network is trusted to read every object.
Allow for the documented behavior of permission changes when planning the exercise rather than interpreting every immediate failure as a network defect. Keep the configuration change time and observation time distinct. If an application can fall back to a key or another identity, make that behavior visible during testing. Otherwise, a successful request can conceal the fact that the intended Entra path never worked.
Cover the subresources used by Data Lake operations
For Azure Data Lake Storage Gen2, Microsoft recommends creating private endpoints for both blob and dfs because some operations involve the other service endpoint. A test that covers only a simple blob read can miss a path used by directory operations or access-control work. Map the actual operation set before deciding that one private endpoint is sufficient. [2]
Give each required operation a row in the acceptance record: service hostname, endpoint target, expected DNS result, authentication method, and outcome. Include the operations performed by maintenance jobs as well as the interactive application. A backup reader, export task, or access-management tool may reach a different subresource from the main request path and therefore need separate review.
When a case fails, preserve the exact operation and which hostname it used. Do not fix a Data Lake failure by broadly reopening public access before determining whether a required private path is missing. The evidence should point to a specific DNS, endpoint, network, or authorization decision. That diagnosis supports a narrow repair and makes its effect easier to validate.
Test the boundary rather than the endpoint icon
A compact acceptance set includes a permitted private request, a denied private request from the wrong identity, and the expected public-path result from the chosen external fixture. Add each required Data Lake operation and a fresh application startup using the normal hostname. Keep expected and observed results adjacent. An approved connection status can support this record, but it cannot replace the requests.
Also decide what the application's outbound network policy permits beyond this storage account. A private endpoint creates a route to its target; it does not by itself define a complete egress policy for the workload. If preventing writes to other destinations is part of the requirement, test that separate control with an owned, harmless destination and record its scope without attempting arbitrary external access.
Preserve a recovery route that does not depend on an undocumented public exception. Identify who can repair DNS, adjust the approved endpoint configuration, or restore the intended data role when a test fails. Reuse the fixture after resolver changes, identity changes, or storage account restructuring. The resulting record should explain which exact path and authority were accepted, rather than making the unqualified statement that the account is private.
Method and provenance
Primary documentation reviewed on August 28, 2026. The article combines the cited platform behavior with an original review procedure and visual explanation. Suggested acceptance cases are not reported experiments.
No Azure account, private endpoint, DNS resolver, or data operation was tested. The guidance is scoped to Azure Storage; other Private Link services have their own subresources and behavior. No public access configuration or production data was changed.
AI assistance. AI assistance was used for source research, drafting, editorial checks, and figure preparation. No human technical review or production experiment is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- Microsoft Azure private endpoint overview Microsoft. Accessed .
- Microsoft private endpoints for Azure Storage Microsoft. Accessed .
- Microsoft private endpoint DNS configuration Microsoft. Accessed .
- Microsoft Azure Storage firewall rules Microsoft. Accessed .
- Microsoft Entra authorization for Blob Storage Microsoft. Accessed .