Azure Private Endpoint: build a validation matrix before production

An Azure Private Endpoint is often validated too quickly. The service answers from a test VM, the portal shows a private network interface, and the team considers the rollout ready. In real environments, that check is not enough. The private path depends on DNS, source networks, private zones, VNet links, service firewalls, hosting plans and sometimes deployment agents that still use a public path.

The scenario here is common: an internal application uses several Azure PaaS services such as Storage, Key Vault and an Azure Function. Workloads run in an Azure spoke, administrators may come from on premises, and standard service names must keep working. The goal is not to prove one successful request. The goal is to build a matrix that says which source should resolve which name, which network path is expected, and which failure is normal.

Start with flows, not objects

Before creating or closing anything, describe the application flows. A Private Endpoint does not make the whole application private. It makes access to a specific service subresource private. A Function may have a private HTTP endpoint while still depending on Storage, Key Vault or deployment endpoints that need their own design.

Internal application
Reads secrets from Key Vault
Writes files to Storage
Exposes an HTTP API through Azure Functions

Expected paths
Azure workload -> Key Vault through Private Endpoint
Azure workload -> Storage blob through Private Endpoint
Internal client -> Function through a name resolved privately
On premises -> privatelink zones through hybrid DNS

Unexpected paths
Direct access by private IP
Hosts file used to fix a test
Public access left enabled without a documented reason

This step avoids confusing technical success with an operable design. If the application calls vault.azure.net, the test must use that name. If the team uses an internal name such as api.internal.example.com, the design must say whether it points to an application, APIM, Application Gateway or an alias that ends at a Private Endpoint.

Build a source-name-result matrix

The validation matrix must cover real sources. A VM placed in the right subnet does not necessarily represent a pod, a Function with VNet integration, an on-premises workstation or a CI agent. Each source can use a different resolver, route and policy set.

Source                         Tested name                       Expected result
vm-spoke-app                    myvault.vault.azure.net            Key Vault Private Endpoint IP
vm-spoke-app                    mystorage.blob.core.windows.net     Storage Private Endpoint IP
deploy-agent                    func-app.azurewebsites.net          Private IP or documented failure
onprem-workstation              myvault.vault.azure.net             Private IP through hybrid forwarding
internet-client                 myvault.vault.azure.net             Network refusal or public access disabled
unauthorized-spoke-vm           mystorage.blob.core.windows.net     Resolution possible, service access denied

Private resolution is not enough to authorize access. It only proves that the tested name points to a private interface from that source. The service still needs its own controls: managed identity, firewall, ACL, SAS, RBAC, application secret or client certificate depending on the case.

Separate DNS, transport and authorization

A common mistake is to analyze 403, timeout and TLS errors as the same network incident. The matrix should separate three layers. DNS answers whether the name resolves to the expected address. Transport answers whether the source can open a connection to that address and port. Authorization answers whether the service accepts the identity, secret or request.

nslookup myvault.vault.azure.net
nslookup myvault.privatelink.vaultcore.azure.net

curl -vk https://myvault.vault.azure.net/

az keyvault secret show --vault-name myvault --name app-secret --query id -o tsv

A 403 can be a good sign if the private path works but the identity is not allowed. A timeout can point to routing, NSG, firewall or service availability. A certificate error often appears when a test bypasses the normal hostname and uses a private IP address. These differences belong in the runbook.

Close public access after proving the private path

Closing public access is a security step, but doing it too early makes troubleshooting harder. The safer sequence is to create the Private Endpoint, validate private resolution from expected sources, validate application access, then disable public access once deployment and operations dependencies are understood.

For Azure Functions, consider SCM if deployments still use that endpoint. For Storage, validate the subresources that are actually used: blob, file, queue or table. For Key Vault, check the agents that retrieve secrets during deployment. A design that protects runtime but breaks delivery is not ready yet.

Keep operational evidence

Validation should not live only in terminal history. It should produce evidence that the team can review: date, source, tested name, resolved address, HTTP status or CLI result, identity used and decision.

Private Endpoint validation
Date: 2026-05-15
Source: vm-spoke-app-01
Resolver: Azure DNS through hub
Name: myvault.vault.azure.net
Resolution: 10.42.20.7
Transport result: HTTPS reachable
Application result: secret read with app-prod managed identity
Decision: private path validated, public access can be closed

Conclusion

A production-ready Private Endpoint is not just a private network interface created in Azure. It is a set of names, routes, DNS zones, service rules and application controls that must stay readable. The validation matrix avoids false positives: one successful request from the right VM does not prove every useful path is under control.

A healthy baseline is concrete: a flow list, a matrix by source, separate DNS and application tests, progressive public access closure and saved evidence. With that discipline, Private Endpoint becomes an operable architecture mechanism rather than a checkbox in a private design.