Azure Resource Graph is great for getting a quick cross-subscription view of resources, but things get less straightforward when a query becomes part of a team's recurring governance process. Where do you store queries that need to be maintained over time: shared queries, a Git repository, PowerShell or CLI scripts, or Azure Workbooks? How do you schedule recurring runs, preserve execution history, handle accepted exceptions, and make sure the right people act on findings? I'm especially interested in approaches that prevent useful queries from becoming undocumented scripts understood by only one person.
3 Answers
The best location depends on what the result is meant to do. Workbooks are useful for interactive dashboards and governance views, while Git-backed scripts are better when the query is deployed, tested, or used to generate recurring exports. A PowerShell or CLI wrapper can handle formatting and notifications, but keep the query text and supporting code in a shared repository rather than inside one person’s script folder. That gives the team review history and makes ownership clearer.
For deployment and automation-focused queries, keep them alongside the pipeline or automation code in source control. For exploratory work, a shared query or workbook is usually enough. Once a query produces findings that require action, add a lightweight results process: record each run, assign findings to an owner, and maintain an exception list with an approver and expiration date. Otherwise every run becomes just a fresh snapshot and it’s hard to tell whether a finding is new, accepted, or ignored.
That distinction is useful: dashboards for visibility, source control for repeatable automation, and a separate tracking process for remediation and exceptions. The query itself shouldn’t have to carry the entire governance workflow.
For a straightforward Azure-native setup, save the query as a shared resource and use a Logic App to run it on a schedule. The Logic App provides run history, while the query resource’s activity history can show changes. Keep the queries in a resource group with a clearly assigned owner. Everyone can use them, but that owner should be responsible for reviewing updates and investigating unexpected changes. Not every operational query needs to be managed through infrastructure as code.
That seems like a practical baseline. After the Logic App runs, I’d also send findings to an ownership queue and persist the output somewhere if you need trend history or evidence that an issue was reviewed.
For recurring governance checks, I’d treat the query more like a small product than a saved snippet: version it, document the expected result, and record who owns remediation. The storage choice matters less than making those responsibilities visible.