Hand me a subscription ID. I will tell you in ten minutes what is wrong with your landing zone. Hand me an hour and I will hand you back a Schema 2.2 findings report with MITRE mapping, severity, effort, and remediation snippets for thirty assessment dimensions.

This session is sixty minutes of live Azure forensics against real tenants, audience-driven. No deploys. No applies. No state files. Just azure-analyzer running read-only against the live Azure metadata layer and the surrounding governance APIs.

azure-analyzer is a PowerShell runner that wraps thirty Azure, GitHub, and ADO scanners into one orchestrator. Each scanner emits a v1 envelope. Normalisers convert to a FindingRow Schema 2.2 row with Pillar, Frameworks, MITRE, Impact, Effort, RemediationSnippets, EvidenceUris, BaselineTags, ScoreDelta, EntityRefs, ToolVersion, and DeepLinkUrl. The orchestrator writes results.json plus entities.json (v3 entity model with edges). The report comes out as HTML and Markdown.

For the live session I use it in two modes:

Interactive query mode (first 45 minutes, audience-driven). Audience volunteers a subscription they have RBAC for. I open azure-analyzer and run individual queries from the embedded 135-query ALZ Resource Graph library, mapped to the official ALZ Checklist by item ID. Then I take requests. "Show me storage accounts with public network access enabled." "Show me NSG rules that allow inbound any-to-any over RDP." "Show me identities with Owner at the management group root that are not break-glass." Each query is one paste, one execution, one finding. Sub-second per query. The room sees what the tenant actually looks like, control by control, and where the drift is.
Report mode (final 15 minutes, capstone). I show the unified Schema 2.2 report from a pre-run scan, walking through the entity graph, MITRE technique coverage, effort-versus-impact prioritisation, and the deep-link evidence URIs that take a security engineer straight to the offending resource in the portal. This is the artifact you hand to leadership. It is what the audience-driven queries become at scale: not a screen of KQL output, but a typed, indexed, framework-mapped findings catalogue. The report renders from cached results.json, so nothing live can fail at this stage.
Read-only across the whole session. The interactive ARG queries are sub-second and idempotent. The report is a static artifact. There is nothing to break. Worst case for the audience volunteer is that we find something they did not know about. Best case is the same thing.

The session is structured but not scripted. I have baseline starter queries (BD-04, BD-05, NS-09, the policy and diagnostic settings checklist items), then take requests. By minute fifty the room has seen the runner used as a tenant audit tool, an incident response tool, a compliance proof tool, and a portfolio governance tool spanning Azure plus the GitHub and ADO supply chain. The toolkit and the query library are public. The session ends with the audience knowing how to write their own scanners against the same Schema 2.2 contract.

The fallback if no audience subscription is offered is a sandbox tenant with seeded findings. The Schema 2.2 report path is identical, just against the sandbox.