12.1 Azure Policy for Security Governance: Definitions, Initiatives, Effects & Remediation

Policy vs RBAC vs Locks

Three governance mechanisms, three different jobs:

A user with Owner rights still cannot create a resource that a Deny policy forbids — that is why Policy, not RBAC, is the answer to "prevent anyone, including administrators, from creating X".

---

The Object Model

• Policy definition — one rule: an if condition over resource properties and a then effect.
• Initiative (policy set) — a bundle of definitions treated as one compliance unit. The Microsoft Cloud Security Benchmark (MCSB) is the default initiative assigned by Microsoft Defender for Cloud, and regulatory standards such as PCI DSS, ISO 27001, and NIST SP 800-53 ship as initiatives too.
• Assignment — the definition or initiative applied at a management group, subscription, resource group, or resource scope, with parameters and optional notScopes exclusions.
• Compliance state — Compliant, Non-compliant, Exempt, Conflicting, or Not started.

Scope inheritance flows downward, so a Deny assigned at a management group applies to every subscription beneath it. That is where security baselines belong.

---

Effects and Evaluation Order

Evaluation order matters: Disabled is checked first, then Append and Modify, then Deny, then Audit. The IfNotExists effects (AuditIfNotExists, DeployIfNotExists) are evaluated after the resource provider has returned a success code, because they need the resource to exist before they can look for its companion. The practical consequence: a Modify effect can alter a payload that a Deny then rejects, and a DeployIfNotExists never fires on a request that Deny already blocked.

Managed identity for deployment effects

DeployIfNotExists and Modify assignments create resources or change properties on your behalf, so the assignment needs an identity:

• Choose system-assigned or user-assigned on the assignment.
• Grant that identity the roles listed in the policy definition's roleDefinitionIds — for example, Log Analytics Contributor for a diagnostic-settings policy.
• Grant them at a scope covering the resources being remediated. Missing role assignments are the single most common cause of "the policy shows non-compliant and remediation fails".

---

Remediation: Fixing What Already Exists

Assigning a policy only evaluates and enforces on new or updated resources. Everything already deployed is simply marked non-compliant. To fix them:

1. Create a remediation task from the assignment (portal, az policy remediation create, or Start-AzPolicyRemediation).
2. The task enumerates non-compliant resources and invokes the deployment or modification using the assignment's managed identity.
3. Track progress per resource; failures usually trace back to missing role assignments or resource locks.

Evaluation itself runs on a roughly 24-hour cycle plus on resource change, and can be triggered on demand with an on-demand compliance scan when you do not want to wait.

---

Exemptions vs Exclusions

Both remove enforcement, but only one leaves an audit trail:

Use exemptions for accepted risk so the acceptance expires and gets re-reviewed. Use exclusions only for scopes that structurally do not belong, such as a sandbox management group.

---

Where Policy Reaches Beyond ARM

• Azure Policy for Kubernetes installs a Gatekeeper v3 admission controller add-on so definitions evaluate Kubernetes objects at admission time — the mechanism behind Pod Security Standards enforcement on AKS.
• Machine configuration (guest configuration) audits and configures settings inside Windows and Linux virtual machines, which is how OS security baselines become measurable compliance data.
• Defender for Cloud consumes all of this: your Secure Score recommendations are backed by policy definitions, and adding a custom initiative is how a custom standard appears on the regulatory compliance dashboard.