Azure Policy & Resource Locks
Policies enforce rules across your Azure environment automatically. Resource locks prevent accidental deletion. Together, they're your governance safety net — the Azure equivalent of Group Policy on steroids.
What is Azure Policy?
Azure Policy is like a set of rules for your entire Azure environment.
If you’ve used Group Policy on-prem, this is the cloud equivalent — but instead of controlling desktop settings, it controls Azure resources. You can say things like “no one can create VMs larger than Standard_D4s_v3” or “every resource must have a CostCenter tag” or “storage accounts must use encryption.”
Policies can audit (flag non-compliant resources), deny (block creation of non-compliant resources), or remediate (fix existing resources automatically).
Policy definitions, assignments, and initiatives
The workflow:
- Choose or create a policy definition — what rule to enforce
- Assign it to a scope — where the rule applies
- Set parameters — configure the rule (e.g., which regions are allowed)
- Monitor compliance — check which resources comply
Policy initiative = a bundle of related policy definitions. Instead of assigning 15 individual policies for security compliance, assign one initiative that contains all 15.
| Term | What It Is | Example |
|---|---|---|
| Policy definition | A single rule | ”Allowed locations: UK South, UK West” |
| Policy assignment | Applying a rule to a scope | Assign “Allowed locations” to Production subscription |
| Policy initiative | A bundle of definitions | ”CIS Benchmark” (contains 50+ definitions) |
| Policy parameters | Configurable inputs | The list of allowed locations |
| Compliance state | Does a resource pass? | Compliant, Non-compliant, Exempt |
Policy effects explained
The effect determines what happens when a resource violates the policy:
| Effect | When Evaluated | What Happens |
|---|---|---|
| Deny | At resource creation/update | Blocks the operation — the resource can't be created or modified |
| Audit | On existing and new resources | Flags as non-compliant but allows the operation |
| AuditIfNotExists | When a related resource is missing | Flags non-compliance (e.g., VM without diagnostic extension) |
| DeployIfNotExists | When a related resource is missing | Automatically deploys the missing resource |
| Modify | At resource creation/update | Adds, changes, or removes tags or properties |
| Append | At resource creation/update | Adds properties (e.g., adding a tag value) |
| Disabled | Never | The policy is turned off (useful for testing) |
Exam tip: Deny vs Audit
Deny blocks creation of non-compliant resources. Audit allows creation but marks them as non-compliant. A common exam scenario: “The company wants to track which storage accounts don’t use encryption, but don’t want to block existing deployments.” Answer: Audit (not Deny).
DeployIfNotExists is the auto-remediation effect — it can automatically deploy a resource (like a diagnostic extension) when it’s missing. The exam loves this one.
Real-world: Meridian Financial's policy strategy
Meridian Financial assigns policies at the management group level:
- Deny: “Allowed locations” — only UK South and UK West (data sovereignty)
- Deny: “Allowed VM sizes” — prevents anyone from deploying expensive GPU VMs
- Audit: “Require tags” — flags resources missing the CostCenter tag
- DeployIfNotExists: “Deploy diagnostic settings” — auto-enables logging on all VMs
- Initiative: “Azure Security Benchmark” — 200+ definitions for security compliance
Their compliance dashboard shows 94% compliance across 12 subscriptions. The 6% non-compliant are legacy resources being remediated.
Resource locks
Resource locks prevent accidental modification or deletion of critical resources. They’re simpler than policies — just two types.
| Feature | ReadOnly Lock | Delete Lock |
|---|---|---|
| Can read the resource? | Yes | Yes |
| Can modify the resource? | No | Yes |
| Can delete the resource? | No | No |
| Use case | Production resources that must never change | Resources that can be updated but not deleted |
Key facts about locks:
- Locks are inherited — a lock on a resource group applies to all resources inside
- Locks apply regardless of RBAC — even Owners can’t delete a locked resource (they must remove the lock first)
- Only Owners and User Access Administrators can create or delete locks
- Locks work at: subscription, resource group, or individual resource level
Exam tip: Lock inheritance
If you place a Delete lock on a resource group, you cannot delete ANY resource in that group — even individual resources. The lock must be removed from the resource group first. This catches many exam candidates off guard.
Also: a ReadOnly lock on a storage account prevents listing access keys (which effectively blocks key-based data access). However, data-plane operations using Entra ID RBAC or existing SAS tokens may still work. The management-plane vs data-plane distinction matters here.
Knowledge check
Alex applied a 'Deny' policy that restricts VM creation to UK South and UK West regions. A developer tries to create a VM in East US. What happens?
Meridian Financial placed a Delete lock on their production resource group. A team member (with Owner role) tries to delete a VM inside that resource group. What happens?
CloudFirst Labs wants to ensure all new storage accounts have encryption enabled, but they don't want to block existing accounts that might not have it yet. They want a compliance report showing which accounts need updating. Which policy effect should they use?
🎬 Video coming soon