DEV Community: Shivanna Gundanavar

Your Azure Private Endpoint Is Approved. So Why Does It Still Resolve a Public IP?

Shivanna Gundanavar — Mon, 12 Oct 2026 08:45:37 +0000

You disable public access on a storage account. You add a private endpoint. The portal shows the connection as Approved. You deploy the app.

It fails with a timeout or a 403.

Nothing in your pipeline warned you. what-if showed the right resources, the deployment succeeded, and every resource is green. The problem is that these tools check resources. They do not check whether a name inside your network actually resolves to the private address.

In my experience, most private connectivity problems in Azure are not firewall problems. They are DNS problems. This post explains why, and shares a small script that checks the whole path before you deploy.

What must be true for private access to work

For a workload in a VNet to reach a PaaS service privately, all of these must hold:

Requirement What happens if it is missing

1 The private endpoint connection is Approved Connection stays pending, nothing works
2 The matching privatelink private DNS zone exists The name resolves to the public address
3 The zone is linked to the VNet doing the lookup Same: public address, even though the zone exists
4 The zone has an A record for the resource Lookup fails or falls back to public
5 If the VNet uses custom DNS, it forwards privatelink zones to Azure DNS Lookup never reaches the private zone

Number 3 is the classic trap. The zone exists, the endpoint is approved, the A record is there, and it still does not work, because the VNet that runs the lookup cannot see the zone.

A quick manual test from a VM inside the VNet:

bash
nslookup mystore.dfs.core.windows.net

If the answer is a 10.x address, DNS is fine. If it is a public address, one of the five items above is broken, and you now have to find which one.

The idea: a what-if for network paths

Finding the broken item by clicking through the portal takes a long time, especially when the zone lives in another subscription or resource group. So I wrote a script that asks the one question directly:

Can workloads in this source VNet reach this target resource privately?

It reads the configuration with the Azure CLI and reports PASS, WARN, or FAIL for each requirement, with a suggested fix.

Example output when the zone exists but is not linked to the source VNet:

text
[PASS] Public access: disabled
[PASS] Private endpoint: 1 approved connection(s)
[PASS] Source VNet DNS: uses Azure-provided DNS
[PASS] DNS zone for pe-mystore-dfs [dfs]: privatelink.dfs.core.windows.net exists
[FAIL] VNet link for pe-mystore-dfs [dfs]: privatelink.dfs.core.windows.net is not linked to the source VNet
Fix: Link the zone to the source VNet (or to the hub VNet that provides DNS resolution for it).
[PASS] A record for pe-mystore-dfs [dfs]: mystore found

The exit code is 1 when anything fails, so a pipeline can block the change.

How it works

The script makes five groups of read-only az calls:

az resource show on the target: read publicNetworkAccess and privateEndpointConnections.
az network private-endpoint show: read the group id (blob, dfs, vault, sqlServer, and so on).
A lookup table maps the group id to the expected zone, for example dfs to privatelink.dfs.core.windows.net.
az network private-dns link vnet list: is the source VNet in the zone's links?
az network private-dns record-set a list: is there a record named after the resource?

It also reads the source VNet's DNS servers. If it uses custom DNS, the script raises a warning, because it cannot see inside your DNS servers and only you can confirm they forward privatelink zones to Azure DNS (168.63.129.16) or to an Azure DNS Private Resolver.

The core check, in a few lines:

python
links = az(["network", "private-dns", "link", "vnet", "list",
"-g", zone_rg, "-z", zone]) or []
linked = any(
((l.get("virtualNetwork") or {}).get("id") or "").lower() == source_vnet_id.lower()
for l in links
)
if not linked:
report.add("FAIL", "VNet link", f"{zone} is not linked to the source VNet",
"Link the zone to the source VNet or to the hub VNet that provides DNS.")

The whole thing is one Python file with no dependencies beyond the Azure CLI. It needs only Reader access, and it changes nothing.

Run it in a pull request

Because it is read-only and fast, it works well as a gate. A sample GitHub Actions job using federated credentials (no stored secrets):

yaml
name: private-path-check
on: pull_request

permissions:
id-token: write
contents: read

jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

  - uses: azure/login@v2
    with:
      client-id: ${{ vars.AZURE_CLIENT_ID }}
      tenant-id: ${{ vars.AZURE_TENANT_ID }}
      subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

  - name: Verify private path
    run: |
      python private_path_check.py \
        --resource-id "${{ vars.TARGET_RESOURCE_ID }}" \
        --source-vnet-id "${{ vars.SOURCE_VNET_ID }}"

Run it after the infrastructure is deployed to Dev, and a missing VNet link fails the pipeline in a minute, not after a day of debugging.

Why this matters more with AI-generated infrastructure

If an AI assistant writes your Bicep or Terraform, it will happily produce a private endpoint and forget the DNS zone link. The code is valid, what-if is happy, and the failure only appears at runtime. Checks like this one are the kind of gate that makes AI-generated changes safe to review: the model proposes, and an independent check verifies the result.

What it does not do

I want to be clear about the limits:

It does not test the network itself. NSG rules, firewall rules, routing, and open ports are not checked. For that, use Azure Network Watcher (connection troubleshoot and the virtual network verifier).
Hub-and-spoke setups need care. If DNS resolution runs through a hub VNet or a Private Resolver, pass the hub VNet as the source, or the "linked" check will report a false failure.
The zone table is small. It covers storage, Key Vault, SQL, and Databricks. Other services need an entry from the Microsoft Learn list of private endpoint DNS zone values.
The A record name is not always the resource name. That holds for storage, but some services register different names.
It reads configuration. It does not resolve DNS from inside the VNet. A real nslookup from a VM in the VNet is still the final proof.

Do We Still Need DevOps Engineers? Azure AI Is Building the Deployment Accelerator That Changes the Answer

Shivanna Gundanavar — Sat, 10 Oct 2026 05:48:07 +0000

The shift nobody is talking about honestly!

For a decade, shipping to the cloud meant a stack of specialist work: Terraform modules, YAML pipelines, PowerShell glue scripts, and one engineer who "knows how the release works."

That is changing quickly. Azure now has AI in every layer of that stack: code, infrastructure, pipelines, and operations. Combined, these pieces make a deployment accelerator: describe what you need, and a platform produces, validates, deploys, and monitors it.

My post below will covers what can be automated today, how to build such a platform on Azure, and what still needs humans.

What can be automated with Azure AI

Area	Traditionally done by	AI-assisted approach on Azure
Infrastructure code	Engineer writes Terraform/Bicep	Natural-language prompt -> Bicep/Terraform via GitHub Copilot or Azure Copilot, based on Azure Verified Modules
CI/CD pipelines	Hand-written YAML	Agent generates GitHub Actions / Azure Pipelines from repo analysis
Environment provisioning	Tickets + scripts	Azure Developer CLI (`azd`) templates + Azure Deployment Environments
Policy and compliance	Manual review	Azure Policy + AI review of IaC before merge
Security scanning	Separate tooling	Defender for Cloud + GitHub Advanced Security with AI fix suggestions
Cost control	Spreadsheet reviews	Cost Management data + AI anomaly summaries
Incident response	On-call runbooks	Azure SRE Agent / Azure Monitor + AI triage
Documentation	Rarely done	Auto-generated from the code and the deployed state

Architecture: the AI deployment accelerator

Developer request (chat / issue / PR)
|
v
AI Orchestrator (Azure AI Foundry agent)
|
+--> Azure MCP Server (read/act on Azure resources)
+--> Template library (Azure Verified Modules, azd templates)
+--> Policy engine (Azure Policy, Checkov, what-if)
|
v
Generated IaC + Pipeline -> Pull Request
|
v
Automated gates: lint, security scan, what-if, cost estimate
|
v
Human approval (for prod)
|
v
GitHub Actions deploys -> Azure
|
v
Azure Monitor + SRE Agent feed learnings back

Step-by-step: how to build it

1. Standardize first. Create a curated library of approved modules (Azure Verified Modules in Bicep or Terraform). AI is only as safe as the building blocks you let it use.

2. Give the agent tools, not freedom. Use Azure AI Foundry to build an agent and connect it to the Azure MCP Server so it can query and operate on Azure through scoped permissions.

3. Make generation produce pull requests, not deployments. The agent writes IaC and pipeline changes into a repo. Everything flows through Git, so you keep history, review, and rollback.

4. Add automated gates.

az deployment what-if or terraform plan on every PR
Policy-as-code (Azure Policy, Checkov, PSRule for Azure)
Secret and vulnerability scanning
Cost estimate in the PR comment

5. Use identity properly. Federated credentials (OIDC) from GitHub to Azure and managed identities everywhere. No stored secrets.

6. Close the loop. Send deployment and runtime telemetry back to the agent so it can suggest fixes, tune sizing, and open remediation PRs.

7. Keep humans on production approvals until you have real data showing the gates are trustworthy.

Example: a prompt-to-production flow

"Create a web app with a SQL database in a private network, dev and prod environments, Key Vault for secrets, and alerts to the ops channel."

The accelerator produces a Bicep deployment, a GitHub Actions workflow for both environments, policy checks, and a cost estimate. A reviewer approves, and it deploys. The first draft takes minutes instead of days.

Do we still need Terraform and PowerShell engineers?

Honest answer: the manual typing of Terraform, YAML, and PowerShell is going away. The engineering judgment is not.

AI is very good at producing the first 80% of IaC and pipelines. It is not accountable for:

Architecture decisions: network topology, landing zones, multi-region and DR trade-offs
Security and compliance ownership: someone must own the risk
Reviewing AI output: generated code can be subtly wrong, insecure, or expensive
Platform design: building and governing the accelerator itself
Incidents with no precedent: novel failures that don't match any pattern
Cost and capacity trade-offs that depend on business context

The role shifts from writing scripts to platform engineering, governance, and AI-assisted operations. Teams that don't need ten script-writers may well need two strong platform engineers. Fewer people doing repetitive work is a realistic outcome. "No engineers at all" is not.

Why this is Azure's moment

Microsoft owns an unusual combination: GitHub (code and CI/CD), Azure (infrastructure), Entra ID (identity), Defender (security), Azure Monitor (operations), and Azure AI Foundry (agents). Few other platforms put the full path from idea to running, monitored workload under one identity and policy model, and AI sits across all of it.

Takeaways

Start with standards and templates, then add AI on top.
Generate through pull requests, never directly to production.
Gate everything with policy, scanning, and what-if.
Reskill toward platform engineering, security, and AI orchestration.

The question isn't "will AI replace DevOps?" It's "will you be the one building the accelerator, or the one it replaces?"

What are you automating first? Tell me in the comments.

By - Shivanna Gundanavar (MLOps and Cloud)

Azure Operations Copilot in Microsoft Teams - Monitor, Investigate and Understand Azure from One Chat

Shivanna Gundanavar — Thu, 24 Sep 2026 14:43:17 +0000

Azure Operations Copilot for Microsoft Teams

Overview
Azure administrators currently use multiple Azure services and portal pages to monitor resources, investigate alerts, check application performance, review security issues, and understand cloud costs.

This proposal is for an Azure Operations Copilot for Microsoft Teams that brings these operations into one conversational experience.

The goal is not to replace the Azure portal. Instead, Teams would become a convenient starting point for investigating Azure issues.

An engineer could receive an alert in Teams and immediately ask questions about it without having to open several different Azure tools.

The Problem
When an incident happens, engineers often need to move between different Azure services to understand what is going on.

For example, an alert might come from Azure Monitor, but investigating it may require checking:
Log Analytics for logs
Application Insights for application errors and dependencies
Azure Resource Graph for resource information
Azure Service Health for platform issues
Microsoft Defender for Cloud for security findings
Azure Cost Management for cost information
The information is available, but it is spread across different services.
The proposed Copilot would bring these sources together through a single conversational interface in Teams.

Proposed Experience
Users could ask questions such as:
“What are the critical issues in production?”
“Why did this VM trigger an alert?”
“Show unhealthy resources.”
“What changed in the last 24 hours?”
“What is our Azure cost this month?”
“Which resources caused the cost increase?”
“Are there any critical security findings?”
“Is Azure Service Health reporting an issue affecting us?”
The assistant would understand the question, identify the relevant Azure services, retrieve the available information, and provide a short explanation.

Example: Investigating an Alert
An Azure Monitor alert could still be delivered to Teams as it is today.
For example:
Production API Alert
Response time increased to 4.8 seconds.
Instead of simply acknowledging the alert, the engineer could ask:
Engineer:
Why did this happen?
Azure Operations Copilot:
Application Insights shows that SQL dependency latency increased around 14:22. Database calls account for most of the increase in response time. Three timeout exceptions were also recorded during the same period.
Engineer:
Is there an infrastructure problem?
Copilot:
VM CPU, memory, and network metrics are within their normal ranges. No related infrastructure issue was identified. The available data points mainly to the database dependency.
Engineer:
Show related errors from the last 30 minutes.
Copilot:
Here are the errors related to the API and database dependency during that period...
The engineer can continue the investigation without leaving Teams.

Azure Services
The initial solution could integrate with:
Azure Monitor
Log Analytics
Application Insights
Azure Resource Graph
Azure Cost Management
Microsoft Defender for Cloud
Azure Service Health
The architecture could allow additional Azure services to be added later.

Security and Access Control
Security should be a core part of the design.
Authentication would use Microsoft Entra ID, and the assistant would respect existing Azure RBAC permissions.
For example, if an engineer does not have access to a particular subscription or resource, the Copilot should not expose information from that resource.
The same principle should apply to:
Resource information
Logs
Application data
Cost information
Security findings
Subscription information
The Copilot should work within the user's existing permissions rather than creating a separate access model.

Initial Scope
The first version should focus on read-only operations.
The main capabilities could include:
Alert investigation
Resource health checks
Log and error investigation
Application performance analysis
Recent configuration/change investigation
Azure Service Health checks
Security finding summaries
Cost and usage analysis
This keeps the initial implementation focused on visibility and investigation.

Future Scope
Once the read-only experience is mature, controlled remediation could be considered.
For example:
Restart a VM
Scale a resource
Stop a non-production resource
Acknowledge or update an incident

Trigger an approved runbook
These actions should require appropriate permissions and, where necessary, explicit user confirmation or approval.

What Makes This Different
The existing model is mainly:
Azure Alert → Teams Notification
The proposed experience is:
Azure Alert → Teams → Ask Questions → Query Azure Data → Correlate Information → Explain the Issue → Continue Investigation
The important difference is that the alert becomes the starting point of an investigation, rather than the end of the workflow.

Proposed Architecture
A simplified architecture could look like this:

Azure Services
Azure Monitor
Log Analytics
Application Insights
Resource Graph
Cost Management
Defender for Cloud
Service Health
↓
Azure Operations AI Layer
Query understanding
Data retrieval
Cross-service correlation
Incident context
Response generation
Permission enforcement
↓
Microsoft Teams
Alerts
Conversational investigation
Incident context
Follow-up questions
Investigation summaries

Expected Benefit
This could reduce the amount of context switching required during Azure operations.
Instead of asking an engineer to manually check several Azure portal pages, Teams could provide a single place to start the investigation and bring the relevant information together.

The objective is simple:
Turn Microsoft Teams from an Azure alert destination into an interactive Azure operations workspace.
The Azure portal would remain the primary place for detailed management and configuration, while Teams would provide a fast conversational interface for day-to-day monitoring, investigation, and troubleshooting.

Thank You
Shivanna Gundanavar