Azure Policy
Azure Policy audits and enforces rules about resource configuration at scale — which regions are allowed, which SKUs are forbidden, which tags are required, whether encryption is on. It evaluates resources continuously and can report violations, block non-compliant deployments, or remediate them automatically. It is governance expressed as code rather than as a wiki page nobody reads.
Policy answers a different question from RBAC. RBAC governs who can do something; Policy governs what may exist regardless of who creates it. A user with Contributor rights still cannot deploy a VM in a disallowed region if a policy denies it. Confusing the two — trying to enforce configuration with permissions, or access with policy — leads to gaps in both.
Definitions and Effects
A policy definition pairs a condition with an effect. The common effects are Audit (flag non-compliance without blocking), Deny (block the non-compliant deployment outright), and DeployIfNotExists or Modify (remediate by deploying or changing configuration). Choosing the effect is choosing how strict to be — audit to measure, deny to enforce, deploy/modify to fix automatically.
Initiatives
An initiative groups many policy definitions into one assignable set — for example, all the controls behind a compliance standard. Assigning the initiative applies every policy in it together and reports compliance as a whole. Initiatives are how large governance programs stay manageable instead of being hundreds of individually assigned policies.
Assignment Scope
Policies and initiatives are assigned at a scope — management group, subscription, or resource group — and apply to everything within it, inheriting down the hierarchy. Assigning at a management group enforces a rule across many subscriptions at once. Scope is how the same governance applies uniformly across an estate without per-resource configuration.
Remediation
For DeployIfNotExists and Modify policies, a remediation task brings existing non-compliant resources into line — enabling a diagnostic setting everywhere it is missing, for instance — rather than only governing new ones. The task acts through a managed identity that you grant the roles it needs to make the change. Without remediation, such policies affect future deployments only and leave the existing fleet untouched, which surprises teams expecting an immediate fix.
Azure Policy — Governs what may exist and how it is configured — allowed regions, required tags, encryption on. Enforced regardless of who acts.
Azure RBAC — Governs who may perform actions on resources. Grants or denies permission to people and identities, not configuration rules.
- Confusing Policy with RBAC — trying to enforce configuration with permissions, or restrict access with policy, leaving gaps in both.
- Leaving policies in Audit mode and assuming they enforce, when only Deny actually blocks non-compliant deployments.
- Expecting DeployIfNotExists or Modify to fix existing resources without running a remediation task — they govern new deployments by default.
- Assigning dozens of individual policies instead of grouping them into an initiative, making the program unmanageable.
- Assigning policy at too narrow a scope, so subscriptions outside it escape governance.
- Writing overly broad Deny policies that block legitimate work and get disabled wholesale in frustration.
- Use Policy for configuration governance and RBAC for access — they answer different questions and work together.
- Start in Audit to measure compliance, then move critical controls to Deny once the impact is understood.
- Run remediation tasks to bring existing resources into compliance, not just future deployments.
- Group related policies into initiatives, especially for compliance standards.
- Assign at management-group scope to enforce uniformly across subscriptions.
- Scope and target Deny policies precisely so they block the wrong thing without blocking legitimate work.
Knowledge Check
What is the difference between Azure Policy and Azure RBAC?
- Policy governs what may exist and how it is configured; RBAC governs who may perform actions
- Policy grants users their permissions, while RBAC is what enforces resource configuration rules
- They are two interchangeable names for one and the same governance system
- Policy applies only to user accounts, while RBAC applies only to resources
A DeployIfNotExists policy is assigned, but existing non-compliant resources are unchanged. Why?
- It governs new deployments by default; a remediation task fixes existing resources
- DeployIfNotExists is an audit-only effect that merely flags the non-compliant resources
- The policy must be assigned at resource-group scope rather than higher up to apply
- Existing resources are permanently exempt from every assigned policy
What does assigning a policy at management-group scope achieve?
- It enforces the rule across all subscriptions under that management group at once
- It applies the policy to only one specific resource group nested beneath that one group
- It automatically converts the policy effect from Deny to Audit mode
- It grants users the permission to create new resources within that scope
You got correct