🔎 Azure Resource Graph Queries With AI: Inventory the Whole Estate Without Clicking

Someone asked a simple question: which storage accounts across all our subscriptions still allow public blob access? In the portal that’s a click-through-every-subscription afternoon. In Azure Resource Graph it’s one query that returns in two seconds. Resource Graph is the tool that turns “I’ll have to check” into “here’s the list,” and it’s badly underused because the one skill it requires — writing correct KQL against the resources tables — feels like a barrier. It isn’t, especially with AI translating plain-English questions into queries. But there’s a trap that makes Resource Graph quietly dangerous, and it’s worth knowing before you trust a single result.

The trap is this: a wrong property path in Resource Graph returns null, not an error. So a query meant to find every misconfigured resource can return zero — and look like good news — when it’s actually querying a path that doesn’t exist. AI is excellent at drafting these queries, but the discipline that makes them trustworthy is verifying the property path against a real resource before you believe a result. Get that habit and Resource Graph becomes a superpower; skip it and it’ll confidently tell you everything is fine when it isn’t.

Translate the question, then verify the path

Start by describing what you want in plain English and let AI draft the KQL — but make it tell you which property paths to confirm, because those are where it guesses.

Prompt: “Write an Azure Resource Graph KQL query that finds all storage accounts across my subscriptions where public blob access is allowed. Project the subscription, resource group, name, and the relevant property. Then tell me exactly which property path I should verify against a real storage account, since a wrong path returns null silently.”

A solid draft, and the verification it should flag:

resources
| where type =~ 'microsoft.storage/storageaccounts'
| where properties.allowBlobPublicAccess == true
| project subscriptionId, resourceGroup, name,
          publicAccess = properties.allowBlobPublicAccess

# Run it
az graph query -q "resources | where type =~ 'microsoft.storage/storageaccounts' | where properties.allowBlobPublicAccess == true | project name, resourceGroup" -o table

Before trusting that the result is complete, confirm properties.allowBlobPublicAccess is the real path. The way to do that is to project the raw properties of one known resource and look:

resources
| where type =~ 'microsoft.storage/storageaccounts'
| take 1
| project properties

If the field is nested deeper than the query assumed, your filter silently matched nothing and the “zero public accounts” result was a lie. That verification step is the whole ballgame, and it’s the same kind of verify-before-you-trust discipline that runs through the Azure governance work.

Pick the right table

Most inventory questions live in resources, but not all of them. Subscriptions and resource groups live in resourcecontainers. Defender for Cloud findings live in securityresources. Policy compliance lives in policyresources. Forcing every question into resources is a common beginner mistake that returns nothing useful.

Prompt: “I want to list every subscription along with its state and the management group it belongs to. Which Resource Graph table holds that — resources or resourcecontainers — and write the query.”

AI knows the table-to-data mapping, which saves you the documentation lookup every time you reach for a less common one.

Build the governance queries you’ll run weekly

Once you’re comfortable, Resource Graph becomes the engine behind your recurring governance checks — untagged resources, public IPs, resources missing diagnostic settings, stale resources, SKU inventory for cost. These are the queries worth saving.

Prompt: “Give me three Azure Resource Graph queries for recurring governance: (1) all resources missing a costCenter tag, (2) all public IP addresses and what they’re attached to, (3) a count of VMs grouped by SKU size for a rightsizing review. For each, flag the property path I should verify.”

// Untagged resources, grouped by type
resources
| where isnull(tags['costCenter'])
| summarize count() by type
| order by count_ desc

AI drafts the set; you verify each path against a sample and save the ones that matter. These pair naturally with the policy and cost prompts in the prompts library.

Read-only by nature, which keeps it safe

One reassuring property: Resource Graph is query-only. It inventories and reports but never changes a resource, so the queries themselves can’t break anything. That makes it the perfect input to a change — find the misconfigured resources, hand the list to a human-reviewed remediation, and act there. The only real risk is trusting a zero result that came from a wrong path, which is exactly why the verify-the-path habit matters so much.

The loop

Resource Graph turns fleet-wide governance questions into two-second answers, and AI removes the KQL barrier that kept people clicking through the portal. Describe the question, let AI draft the query and name the property paths to confirm, verify those paths against a real resource, pick the right table, and save the queries you’ll run again. The one rule that keeps it honest: a zero result might mean a clean estate or a wrong path, so verify before you trust it. AI writes the KQL and recalls the tables; you confirm the paths and own the remediation that follows. There’s more governance material in the Azure category, and the Resource Graph query-builder prompt is ready to copy from the prompts library.