Add Azure Monitor Health Models AzAPI quickstart

[Bill Anderson (bandersmsft)]

Summary

Adds a Terraform sample that deploys a self-contained Azure Monitor health model through the AzAPI provider and the current Microsoft.CloudHealth/healthmodels@2026-05-01-preview API. The AzureRM provider doesn't currently expose a native Health Models resource.

The Health Models team confirmed through Megan Goode that it can support AzAPI as the current Terraform path for GA. Hansjoerg Scherer recommended Storage and Key Vault resource entities beneath an abstract parent, with the Health Model's system-assigned identity. André Bossard reviewed and corrected the final graph, required role, and resource ordering. Native AzureRM support remains future work.

Maintainer action needed

The repository's E2E workflow doesn't execute deployment tests for fork heads. A maintainer needs to move this contribution through an upstream release branch and open a release-to-master PR so the protected e2e-check can run. This follows the workflow's linked release-branch process and the precedent in PR #479 and release PR #480.

Changes

• Creates a randomly named disposable resource group, Storage account, and Key Vault with AzureRM.
• Creates a Health Model with AzAPI and a system-assigned managed identity.
• Assigns Reader to the Health Model identity at resource-group scope.
• Creates a managed-identity authentication setting.
• Creates Storage and Key Vault resource entities with Availability metric signals.
• Sets the Key Vault entity impact to Limited.
• Creates an abstract application entity.
• Connects the Health Model root to the application and the application to both resource entities.
• Exposes the resource group, Health Model, Storage account, and Key Vault names as outputs.

Validation

Tested with Terraform 1.15.8, AzAPI 2.12.0, AzureRM 4.81.0, and Random 3.9.0.

• terraform fmt -check: passed.
• terraform validate: passed with zero warnings.
• terraform plan: 13 resources to add, 0 to change, and 0 to destroy.
• terraform apply: passed with all 13 resources created.
• Azure API verification: Health Model provisioning succeeded with a system-assigned identity.
• Authentication verification: ManagedIdentity with SystemAssigned.
• Entity verification: abstract application, Storage, and Key Vault entities were created, in addition to the automatic Health Model root entity.
• Signal verification: both resource entities use the published Availability metric with Percent and Average.
• Relationship verification: the Health Model root connects to the application, which connects to both resource entities.
• Authorization verification: the Health Model identity has Reader at resource-group scope.
• Idempotence plan after apply: no changes.
• Destroy apply: all 13 resources destroyed.
• Independent resource-group deletion and empty-state checks: passed.

Related documentation work: https://github.com/MicrosoftDocs/azure-monitor-docs-pr/pull/5252

Related work item: https://dev.azure.com/msft-skilling/Content/_workitems/edit/629740

[Andre Bossard (abossard)]

I would prefer if the example has a bit of everything that AHM offers, e.g. it adds 2-3 identities, Azure resource id reference and metrics with dimension filter, AMW with PromQL and and a discovery rule example.

Also we don't have Bicep examples yet. AzAPI is a Bicep wrapper in general, so we could also think about examples Bicep usage and then a section how it applies to Terraform with AzAPI.

We can go through with this starting scaffold and then I we can expand on it.

[Bill Anderson (bandersmsft)]

Andre Bossard (@abossard) Thanks, André. We’re expanding the 101 sample to include one authentication setting, two entities with signal properties, and one relationship. I’ve asked Hansjoerg Scherer for guidance on the canonical minimal resource, signal, metric, authentication setting, and permissions. We’ll keep PromQL, dimension filtering, and discovery for a broader follow-up example.

[Andre Bossard (abossard)]

That's brilliant Bill Anderson (@bandersmsft)
Let me know if I can contribute in any way besides testing. Also I made an example for the az cli documentation, maybe it can be a bit similar to that.

https://learn.microsoft.com/en-us/azure/azure-monitor/health-models/cli?tabs=cli-bash

In these quickstarts, would it make sense to e.g. create a Key Vault and then add Key Vault metrics to the Health Model as signal? Is it common in the quickstarts to create supporting resources ?

[Bill Anderson (bandersmsft)]

Hi, this PR is ready for the maintainer release-branch and protected E2E process. The Health Models team reviewed the sample, the latest corrections are merged, local end-to-end validation passed, and CLA and prepr-check pass. Could you create the upstream release branch and release-to-master PR so e2e-check can run? If not, what's the right process I should follow? Thanks.

[Bill Anderson (bandersmsft)]

Maintainer handoff update: I contacted Vishwajeet Ranade, Jason Groce, and Akash Dubey by email to ask who can create the upstream release branch and release-to-master PR for the protected e2e-check, or confirm the current process.

[Vishwajeet Ranade (vranade-microsoft)]

I have now run the E2E check manually.

[Bill Anderson (bandersmsft)]

Vishwajeet Ranade (@vranade-microsoft) Thanks for running E2E. All checks are green. Could you merge the PR when you’re ready, or let me know if anything else is needed from me?

[Vishwajeet Ranade (vranade-microsoft)]

Vishwajeet Ranade (Vishwajeet Ranade (@vranade-microsoft)) Thanks for running E2E. All checks are green. Could you merge the PR when you’re ready, or let me know if anything else is needed from me?

This PR is now merged.

[Bill Anderson (bandersmsft)]

Vishwajeet Ranade (@vranade-microsoft) tyty!