1 · Policy as Code: Core Concepts
Azure Policy evaluates resource properties against business rules expressed as JSON definitions. The lifecycle:
- Definition — a single rule (condition + effect) written in JSON.
- Initiative (Policy Set) — a bundle of related definitions assigned together.
- Assignment — binds a definition/initiative to a scope (MG, Sub, or RG).
- Exemption — temporarily excludes a resource/scope from an assignment (with expiry).
Policies are evaluated on resource create/update (real-time) and via periodic compliance scans (~24 h cycle).
2 · Policy Effects
Effect
- Deny
- Audit
- Modify
- DeployIfNotExists
- Append
- Disabled
When It Fires
- Create/Update — blocks request
- Create/Update — logs non-compliance
- Create/Update — adds/changes properties (e.g., tags)
- Post-provisioning — deploys a related resource (e.g., diagnostic setting)
- Create/Update — appends fields (legacy, prefer Modify)
- Never — policy skipped
Use Case
- Block disallowed SKUs or regions
- Visibility-only; no enforcement yet
- Auto-apply tags, enable HTTPS
- Auto-enable monitoring agent or encryption
- Add IP rules to storage (legacy)
- Testing or gradual rollout
Evaluation order: Disabled → Append → Deny → Audit → Modify → DeployIfNotExists.
3 · Scope & Inheritance
Assignments at a higher scope apply to all children. Exemptions carve out exceptions without removing the assignment. Use notScopes for permanent exclusions.
4 · Initiatives & Regulatory Compliance
Initiatives group policies for a compliance goal. Azure provides built-in initiatives mapped to frameworks:
- CIS Microsoft Azure Foundations Benchmark
- NIST SP 800-53 Rev 5
- PCI DSS v4
- ISO 27001:2013
Assign an initiative at the Management Group level to cover every subscription uniformly.
5 · Built-in vs Custom Policies
Use built-in when Microsoft already publishes a matching rule (700+ available). Write custom when:
- Your naming convention or tagging schema is unique.
- You need to evaluate nested resource properties not covered by built-ins.
- Combining
field,count, orvalueexpressions in complex logic.
Store custom definitions in a Git repo alongside IaC (Policy-as-Code). Deploy via CI/CD using az policy definition create or Bicep Microsoft.Authorization/policyDefinitions.
6 · Compliance & Remediation
The Compliance dashboard in the portal shows:
- Compliant — resource satisfies all assigned policies.
- Non-compliant — at least one policy violated.
- Exempt — excluded via exemption resource.
- Not started — evaluation pending.
Remediation tasks fix existing non-compliant resources for Modify and DeployIfNotExists effects. They require a Managed Identity with appropriate permissions on the target scope.
7 · Policy as Guardrails vs RBAC as Access Control
| Aspect | Azure Policy | Azure RBAC |
|---|---|---|
| Purpose | What resources can look like | Who can do what |
| Default | Allow (deny by rule) | Deny (allow by assignment) |
| Scope | MG → Sub → RG → Resource | Same hierarchy |
| Enforcement | Resource properties & config | Control-plane actions |
Use both together: RBAC controls who can deploy; Policy controls what they can deploy.
8 · Real-World Scenario
Contoso's Platform Team enforces governance across 40 subscriptions:
- Tagging: Modify effect auto-applies
CostCenterandEnvironmenttags inherited from the RG. - Encryption: DeployIfNotExists enables TDE on all Azure SQL databases.
- Allowed Regions: Deny effect restricts deployments to West Europe and North Europe.
- SKU Restrictions: Deny blocks M-series VMs outside the HPC subscription (exemption granted there).
All definitions are stored in a Git repo and deployed via Azure DevOps pipelines. Compliance is reviewed weekly via the dashboard and exported to Log Analytics for executive reporting.
💡 AZ-305 Exam Tip
When a question asks "ensure all future and existing resources comply," choose DeployIfNotExists (with a remediation task for existing). If it says "prevent non-compliant resources from being created," choose Deny. Audit alone never blocks anything.