LEARN. PRACTICE. GROW.Inventory consumers before endpoints
A move to private access starts with consumers: a spoke application, datacenter batch, administrative tool, and recovery process. For each, record hostname, resolver, identity, operation, and availability requirements. The hub VM can have a path no other client uses. Testing that VM is useful but should not represent the service alone. Include DNS and networking owners in the change plan and define what happens if a client still depends on the public path at the start of the window.
Separate network links and zone links
Peering provides a form of VNet connectivity but does not automatically make every hub DNS configuration available to a spoke. In the Azure-provided DNS exercise, the private zone is linked only to the hub; the spoke needs an applicable link or another designed DNS path to query it. Avoid simultaneously changing resolver, routes, and grants without a verifiable hypothesis. First observe the returned name and final address; then check application traffic. Correct private resolution does not guarantee TCP, authentication, or authorization.
Design forwarding direction
For on-premises queries needing Azure private zones, the design can conditionally forward to a reachable Private Resolver inbound endpoint. In the Azure-to-internal-name direction, assess rules, outbound, and the server that is actually authoritative. Draw arrows for each namespace and look for cycles: if A sends funds.example to B and B sends it back to A, neither reaches a terminal answer. For SQL Private Link, follow the recommended service forwarding namespace. Do not use a broad empty zone to privatize only one server.
Preserve the name the application expects
For SQL Database, retain the normal server FQDN in the connection string and let DNS determine the private path. Substituting an IP or privatelink name is not a safe login shortcut. The endpoint routes to a gateway needing the appropriate name. For other services, inspect their contract rather than generalizing a SQL rule. During rehearsal, record configured hostname, observed resolution, and connection result without exposing credentials. This prevents a naming failure being confused with an incorrect password.
Cover the subresources actually used
One storage-account endpoint does not automatically represent every account API. A monthly job can read blobs and then create directories or manage ACLs through DFS. The ADLS Gen2 design should cover endpoints and zones relevant to those operations. Before broadening permissions, identify the failed call’s hostname and compare it with the successful read. Use synthetic data reproducing the complete cycle, including creation and controlled cleanup. A small test should reduce volume while retaining the functional dependencies that make it representative.
Define positive and negative acceptance checks
First confirm private-connection state and required approval. Then validate each authorized consumer: resolution, network path, identity, and useful operation. Finally, perform an authorized check that the public path is restricted as required. A positive test does not establish the negative boundary. Retain timestamped configuration evidence so RUN can repeat diagnosis. If a path is not ready, apply the approved deferral or recovery plan; do not turn a temporary exception into a permanent design without an explicit decision.
The hub resolves SQL to a private IP, but batch still uses on-premises DNS without suitable forwarding. The gate fails before public closure, avoiding a closing-time incident.
Common pitfalls
Confusing peering with automatic DNS sharing; overriding broad public zones; using an IP for SQL login; testing only blob reads; accepting a Pending endpoint.
Related topics: Hybrid network architecture · Handover and acceptance criteria
Private access is a verifiable chain per consumer: resolution, networking, approval, identity, and operation.
Reference: Private Endpoint DNS integration · AZ-305 objectives 2026-04-17