Azure / Intermediate: managed services and governance / Lesson 9

Private endpoints, DNS, and end-to-end access

Trace a service connection from the client’s resolver to the target identity. Distinguish private endpoints, service endpoints, application outbound integration, and data authorization.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain network and DNS roles in Private Link access.
Separate inbound exposure from outbound integration.
Interpret an offline address model without claiming connectivity.

Similar private-network names describe different mechanisms

A private endpoint provides a private network interface for supported access to a service through Azure Private Link. Service endpoints follow a different design involving a service’s endpoint and virtual-network identity under its support rules. Neither phrase means every public path is automatically disabled or every application identity is authorized. App Service outbound virtual-network integration is also distinct from giving the application a private inbound endpoint. Identify direction, client location, target subresource, public-access policy, and service support before selecting a mechanism. A diagram with a private IP is insufficient to establish the entire access path.

The client must resolve the service name in its own context

A client normally uses the service’s documented hostname so TLS and application addressing remain correct. Private DNS records, zone links, forwarding, and hybrid resolvers influence whether that name leads to the intended private address. A zone existing somewhere is not proof that this client’s resolver can use it. Avoid replacing a hostname with an IP as a permanent fix when certificate and service routing expect the original name. The model below records resolver context and expected address class using a reserved example domain. It is not a DNS zone deployment or a real lookup result.

json A resolver-context planning model

{
  "model": "dns-expectation-only",
  "hostname": "storage.example.invalid",
  "client_contexts": [
    {
      "client": "inside-linked-network",
      "expected_address_class": "private"
    },
    {
      "client": "outside-private-resolution",
      "expected_address_class": "depends-on-public-dns-and-policy"
    }
  ]
}

Expected output

evaluate resolution from the actual client context before testing transport

The example domain is reserved and no DNS request occurs. Real service-specific zone names must come from current Microsoft documentation.

Address classification does not prove a connection

The offline program checks whether two documentation addresses belong to an intended synthetic subnet. It distinguishes the private candidate from an address outside that prefix without resolving a name or sending a packet. Even a correct private result can fail because of routing, network rules, endpoint approval, service firewall settings, TLS, identity, or application policy. Diagnose these in order and preserve safe context instead of granting broad roles or allowing all network sources. A single successful test from an administrator’s machine is not evidence that a different application subnet and resolver context works.

python Offline address-prefix classification

from ipaddress import ip_address, ip_network
expected = ip_network("10.20.2.0/24")
observed_model = {"inside": "10.20.2.5", "outside": "203.0.113.5"}
for client, address in observed_model.items():
    print(client, ip_address(address) in expected)

Expected output

inside True
outside False

These are synthetic expected values, not captured DNS or network observations. No socket, resolver, or Azure API is called.

Private routing does not decide who may read data

After name and transport conditions are correct, the service still evaluates the credential and requested data operation. Managed identity selection, token audience, tenant, role scope, and data-plane permissions can all matter. Public-network restrictions and private endpoint access are service configuration, not replacements for least privilege. Review which credential path the client actually uses; a shared key, signed URL, and Entra token are different authorization routes. Keep secrets out of packet or application diagnostics. Error status and correlation information should help identify the boundary without publishing credentials or private object contents.

Verify each client path and the intended denial

A future authorized verification should record the client, resolver, hostname, resolved address, route/security context, service response, and access decision. Include an allowed workload and a denied source or identity so success is not obtained by accidental public exposure. Private endpoints can introduce dependencies on DNS forwarding and regional network components that belong in recovery planning. This course performs no DNS queries, pings, connection attempts, endpoint approvals, or cloud configuration changes. It validates the planning data and offline prefix arithmetic only, leaving real connectivity and service authorization explicitly untested.

Common errors and fixes

A private DNS zone exists but the client resolves elsewhere

Why it happens: Zone existence is confused with resolver reachability and links.
How to fix it: Trace the actual client’s forwarding and zone-link path.
Prevent it next time: Record resolver context for every supported client network.

VNet integration is assumed to make App Service inbound private

Why it happens: Outbound integration and inbound exposure are conflated.
How to fix it: Design the intended direction and service-specific endpoint policy.
Prevent it next time: Review inbound and outbound paths separately.

A private IP is treated as proof of data authorization

Why it happens: Network placement substitutes for identity and operation checks.
How to fix it: Verify the credential path and narrow data permissions.
Prevent it next time: Include denied-identity evidence beside connectivity evidence.

Check your understanding

1. Why should the service hostname often remain unchanged with private access?

Show worked solution

The hostname participates in documented service addressing and TLS identity while DNS can direct it to a private address. Replacing it with an IP can break those contracts. Verify the service-specific DNS guidance and actual client resolver rather than applying a universal hosts-file workaround.

2. What does the prefix-classification program leave untested?