Azure Policy
This section documents the Azure Policy guardrails the accelerator assigns to each environment.
Policy is a guardrail layer, not the main purpose of the accelerator. It uses built-in policy definitions only, at resource group scope. It does not create custom definitions, initiatives or management-group assignments.
Policy mode
Set policy_mode in inputs.yaml:
| Mode | Effect | Default for |
|---|---|---|
audit | Reports non-compliance; nothing is blocked | All scenarios except 11 |
deny | Blocks non-compliant changes | Opt-in |
none | Assigns nothing | Scenario 11, existing platform (the platform team owns policy) |
Change the value, then run Deploy-MLOpsAccelerator -Upgrade and let the infra pipeline apply it.
Pages
- Policy assignments: every policy the accelerator assigns, with scope, effect and a definition link.
- Policy FAQ and tips: common problems and how to adjust the guardrails.
Why only built-in policies?
ALZ ships custom definitions and initiatives because it governs a whole platform and relies on deployIfNotExists and modify effects. Here the scope is one workload, so built-ins cover it. Custom definitions would add something to version and maintain.
Why are there no managed identities for policy?
ALZ creates managed identities for deployIfNotExists remediation. The accelerator only uses audit and deny effects, so it needs no remediation identity and no extra role assignments for the identities.
Prerequisites
Assigning policy needs the Resource Policy Contributor role. Contributor cannot write policy assignments. The bootstrap grants it to the deploy identity at subscription scope. See Azure prerequisites.