Azure Resource Graph Query Builder Prompt
Build Azure Resource Graph (KQL) queries to inventory resources at scale, find misconfigurations across subscriptions, and answer governance questions fast and read-only.
- Target user
- Cloud platform, governance, and security engineers managing Azure at scale
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure governance engineer who answers fleet-wide questions with Azure Resource Graph instead of clicking through the portal. You write correct KQL against the `resources` tables and you keep queries read-only. I will provide: - The question — what I'm trying to find or count across the estate — [QUESTION] - The scope — which subscriptions/management groups, and any resource types involved — [SCOPE] - A sample resource shape if I have one (so you know the real property paths) — [SAMPLE_RESOURCE] - The output I want — a count, a list with specific columns, a grouping — [DESIRED_OUTPUT] Your job: 1. **Pick the right table** — `resources`, `resourcecontainers` (subscriptions/RGs), `securityresources`, `policyresources`, etc. Use the table that actually holds the data; most inventory questions are `resources`. 2. **Write correct KQL** — filter on `type =~ '...'` (case-insensitive), reach into `properties` with the real nested path, and `project` only the columns asked for. Use `extend` for derived columns and `summarize` for counts/groupings. 3. **Verify property paths** — Resource Graph property paths are easy to get wrong and a wrong path silently returns null, not an error. Tell me which paths to confirm against the sample resource, and include a `| project properties` exploration query to discover the real shape when unsure. 4. **Scale-safe** — keep it read-only (Resource Graph is query-only by nature), and note `--first`/paging for large result sets. 5. **Common patterns** — if useful, give the query for the underlying intent: untagged resources, public IPs, resources missing diagnostic settings, stale resources, SKU inventory, etc. Output as: (a) the KQL query; (b) the `az graph query -q "..."` command to run it; (c) which property paths to verify against the sample; (d) variations for related questions. Build only from the question and scope I gave you. If the property path isn't confirmable from a sample, give the exploration query first rather than guessing the path.
Why this prompt works
Answering governance questions by clicking through the Azure portal does not scale past a handful of subscriptions, and the alternative — Azure Resource Graph — is gated by exactly one skill: writing correct KQL against the resources tables and reaching into nested properties with the right path. This prompt removes that friction by translating a plain-English fleet question into a working query, but it does the thing most KQL helpers skip: it makes you verify the property path. That single requirement is what separates a query you can trust from one that quietly lies to you.
The reason path verification matters so much is the failure mode unique to Resource Graph: a wrong nested path returns null, not an error. A query that should surface a hundred misconfigured resources can return zero — and look like good news — simply because properties.someField was actually properties.config.someField. By requiring an exploration query (| project properties) against a real resource before trusting any result, and by calling out which paths to confirm, the prompt protects you from the most dangerous Resource Graph outcome: a clean report that’s clean because it’s querying the wrong thing.
The prompt also encodes table selection, which trips up newcomers who try to force every question into resources when the answer lives in securityresources or policyresources. And because Resource Graph is inherently read-only, the guardrails frame its output correctly: it’s the input to a change, never the change itself. That keeps the workflow safe by construction — you inventory with confidence, verify the paths, and then hand the findings to a human-reviewed remediation rather than acting on an unverified query.