Verifying private network paths before you deploy: a what-if for Azure private endpoints
A common Azure scenario: public access is disabled on a PaaS resource, a private endpoint is created, and the connection shows as Approved. The application still times out. Resource-level checks such as what-if report nothing wrong, because every resource is configured. What they do not verify is whether the name the application uses resolves to the private address from the application's VNet. In my experience, most private connectivity failures come from DNS configuration, not from firewall rules. What must be true For a workload in a VNet to reach a PaaS service privately: The private endpoint connection is Approved. The matching privatelink private DNS zone exists. The zone is linked to the VNet that performs the lookup. The zone contains an A record for the resource. If the VNet uses custom DNS servers, they forward privatelink zones to Azure DNS (168.63.129.16) or to an Azure DNS Private Resolver. The third point is the one that is easy to miss: the zone and the record exist, but the VNet performing the lookup cannot see the zone, so the name resolves to the public address. An approach: check the whole path in one command I wrote a small, read-only script that takes a target resource and a source VNet, then reports PASS, WARN, or FAIL for each requirement above, with a suggested fix. It uses the Azure CLI and needs only Reader access. Checks performed: publicNetworkAccess on the target resource Private endpoint connections and their approval state Expected privatelink zone for the endpoint's group id Whether the zone is linked to the source VNet Whether the zone has an A record for the resource Whether the source VNet uses custom DNS servers (reported as a warning for manual review) It exits with code 1 on any failure, so it can run as a pipeline gate after a Dev deployment. Limitations It does not test the network path itself (NSGs, firewalls, routing, ports). Azure Network Watcher covers that. It reads configuration and does not resolve DNS from inside the VNet. A real lookup from a VM in the VNet remains the final proof. In hub-and-spoke designs, the hub VNet may need to be passed as the source. The built-in zone table covers a few services (storage, Key Vault, SQL, Databricks) and needs extending for others. Why I think this matters for AI-assisted infrastructure Script and sample pipeline: Ping me or message me When infrastructure code is generated by an AI assistant, a private endpoint without its DNS zone link is a plausible output: the code is valid and the deployment succeeds. Independent, read-only checks like this one are the kind of gate that lets teams review generated changes with confidence. Questions for the community Which private endpoint failure costs your team the most troubleshooting time? How do you manage DNS in hub-and-spoke networks: Private Resolver, DNS forwarders, or another pattern? Would a check like this be more useful as an Azure Policy, a Network Watcher feature, or a pipeline step? Which services should be added to the DNS zone table first? Shivanna Gundanavar
AI-102: Microsoft Agent Framework
Hello, I am currently going through the official AI-102 Learning Path and I noticed that the modules and labs now feature the Microsoft Agent Framework (using the agent_framework library). However, I need clarification regarding the actual exam content: Does the current live exam already test on Microsoft Agent Framework as seen in the new Learning Path? Or does the exam still focus on Semantic Kernel and AutoGen, as previously listed in older study guides? I want to make sure I am focusing my study on the correct framework that will appear in the exam questions. Thank you!
