LEARN. PRACTICE. GROW.A private endpoint does not resolve every dependency
An approved endpoint is one architecture component rather than proof of client operation. Inventory consumers, names used, resolvers, subresources, ports, and credentials. For Blob in public Azure the application retains the normal account name. DNS architecture directs resolution to the private IP; do not replace the hostname with an IP and remove TLS validation to compensate for a DNS fault. A representative operation needs transport, identity, permission, and the expected outcome. Restricting the public endpoint is an additional decision requiring identified dependencies and return criteria.
Follow the client’s resolver
In the on-premises Private Resolver model, the recommended Blob forwarding zone is blob.core.windows.net. The private zone contains the corresponding record in privatelink.blob.core.windows.net. Record the client path, responding resolver, and observed answers; a hub test can follow a different path. In a simple Azure-provided DNS design with peered VNets, link the same private zone to required client VNets. Peering does not create that association. For custom DNS architectures use the appropriate forwarding design rather than assuming a zone link automatically changes the DNS server being used.
Separate record, subresource, and authorization
Blob and File use different subresources and zones. A Blob endpoint does not itself create private File access. Verify the service used by each feature before copying configurations. In the authoritative fixture without fallback, account-a has a record and account-b does not; NXDOMAIN for b is a resolution issue in that scope rather than proof of TCP blocking. Another exercise has correct DNS and TLS, but the service returns AuthorizationPermissionMismatch for the expected identity. Investigation then covers operation, credential, scope, and data permissions. The specific code and logs help avoid treating every HTTP 403 as the same cause.
Accept migration with positive and negative evidence
For every intended client, confirm the DNS answer, destination, TLS using the normal name, identity, and a representative operation. Do not use one hub test to approve an on-premises batch still resolving publicly. If the requirement is private-only access, add a controlled external test establishing public restriction without exposing data. The checks answer different questions: private success and public denial. Define what happens if the window ends before validation; deferral, rollback, or acceptance of a temporary exception needs an owner and record. A change deadline does not turn an untested dependency into a ready one.
Traffic collection with current lifecycle
At the 2026-10-02 consultation, documentation states that new NSG flow logs can no longer be created and retirement is scheduled for 2027-09-30. For a new project evaluate VNet flow logs, resource compatibility, destination, and retention. Migration should consider collection overlap, which can duplicate records and costs. Flow records describe traffic and network decisions; they do not establish transaction commitment or data validity. Preserve identifiers and times that support application correlation. Do not delete historical records simply because collection resources will retire; retain them according to applicable retention rules.
RUN handover exercise
Prepare a demonstration for the team receiving incidents: generate an authorized flow, observe data arrival, query with appropriate permissions, and correlate with a test job. Record scope, observed delay, retention, owners, and diagnostic instructions. If collection exists but data or query access is missing, identify the gap rather than granting Owner as a universal solution. If TCP passes and the job fails validation, keep the functional issue open. A conditional handover should state temporary coverage, deadlines, and responsibilities without confusing administrative acceptance with demonstrated operational autonomy.
Summary and next exercises
The private path must be observed from the clients that will use it. Resolved name, reached destination, TLS, authorization, and outcome are separate criteria. Observability is ready only when RUN can find and interpret the required data. Examples and local models are original and synthetic: they create no resources, query no subscriptions, execute no resolvers, and send no packets. Use them to prepare hypotheses and criteria, then establish behavior in an authorized lab using test resources and data. Connect this lesson to the previous one, storage, identity, change management, and recovery.
APPLICATION NAME fundsdata.blob.core.windows.net
PUBLIC FORWARDING ZONE blob.core.windows.net
PRIVATE ZONE privatelink.blob.core.windows.net
HUB CLIENT private answer observed
ON-PREMISES CLIENT public answer observed
CUTOVER ACCEPTANCE pending representative on-premises validationThe hub receives a private IP while the on-premises batch receives a public IP. Record both resolvers and validate the batch client before disabling public access. Hub success has limited scope.
Common pitfalls
Assuming peering shares DNS; replacing the supported name with an IP; confusing Blob and File endpoints; closing with positive TCP but a failed job.
Related topics: Production diagnosis · Changes and recovery · Operational evidence
Approve cutover and handover using real-client evidence and outcomes interpreted by layer.
Reference: Private endpoint DNS integration · AZ-104; skills measured 2026-04-17