Before you start
Capture the current state, preserve recoverable data and record recent changes before remediation. Use production-impacting commands only within an approved maintenance or change window.
Identify expected DNS answer
Record the service FQDN and expected private endpoint IP. Identify the private DNS zone that should answer the query.
Test from affected client
Run Resolve-DnsName or nslookup from the network where the application fails. Compare the answer with the private endpoint address.
Check Private DNS zone
Verify the zone, records and VNet links. Look for duplicate or stale zones that can create inconsistent answers.
Check custom DNS
If the VNet uses custom DNS, test DNS server reachability and conditional forwarding for the Private Endpoint zone.
Validate TCP path
After DNS returns the private IP, test the required TCP port. If DNS is correct but TCP fails, move to NSGs, routes, firewalls and the service itself.
DNS
Resolve-DnsName <service-fqdn>
nslookup <service-fqdn>TCP
Test-NetConnection <private-ip> -Port 443Private Endpoint
Get-AzPrivateEndpoint -ResourceGroupName 'RG' -Name 'PE'Troubleshooting validation
- Confirm the original symptom is resolved.
- Verify dependent services and application health.
- Review logs or command output for secondary errors.
- Document the root cause and corrective action.
- Retain rollback evidence until the change is accepted.
Frequently Asked Questions
What should I check first?
Capture the current state, exact error, affected scope and recent changes before making changes. Then test the failing layer from the lowest dependency upward.
How do I validate the fix?
Repeat the original failing operation, check dependent services and confirm the issue remains resolved after any required restart or service recovery.
Can this troubleshooting be automated?
Automate read-only diagnostics first. Add remediation only after commands, permissions, logging and rollback behavior have been validated.