Azure Policy vs Azure RBAC vs resource locks: who, what and what can't be deleted

Azure has three governance controls that sit side by side and get confused all the time:

• Azure RBAC decides who can perform an action.
• Azure Policy decides what a resource is allowed to look like, whoever creates it.
• Resource locks stop deletion or change for everyone, Owners included.

Even if someone has permission to act, Policy still blocks a non-compliant result, and a lock overrides any user permissions.

RBAC: who can do it

A role assignment is a security principal, a role definition and a scope. Scopes are the management group, subscription, resource group or resource, and assignments are inherited by everything below. RBAC is additive: your effective permissions are the sum of your role assignments. If you’re unsure which role system you need in the first place, see Azure RBAC vs Microsoft Entra roles.

The exception is a deny assignment. Azure Resource Manager checks deny assignments first, and if one applies, access is blocked even when a role grants it. You can’t create your own: Azure creates them, for example when a deployment stack uses deny settings. (Customer-managed deny assignments are still in private preview.)

Azure Policy: what is allowed

A policy definition is a rule plus an effect. Group several definitions into an initiative (the CLI and PowerShell call it a policySet); Microsoft recommends assigning initiatives even if you start with one policy. Assign either to any of the four scopes; child scopes inherit it.

The supported effects are addToNetworkGroup, append, audit, auditIfNotExists, deny, denyAction, deployIfNotExists, disabled, manual, modify and mutate. The ones to know cold:

• deny blocks a non-compliant create or update.
• audit and auditIfNotExists let it through and flag it as non-compliant.
• append and modify change the request (for example, adding a tag) before it goes through.
• deployIfNotExists deploys a related resource when it’s missing.
• denyAction blocks an action; the only supported action is DELETE.
• disabled switches the rule off without removing the assignment.

Policy also re-checks existing resources in a compliance cycle every 24 hours. Policy can look at the identity behind a request too (for example, blocking users without MFA), but its core job is the resource’s properties.

Exclusions vs exemptions

• An exclusion (notScopes) lives on the assignment. Excluded resources aren’t evaluated or counted. Use it to permanently leave out a broad scope such as a test environment.
• An exemption is a separate object on the resource or scope. The resources show as Exempted in compliance reports, so they’re still tracked, and an exemption can expire. Use it for time-bound or specific waivers.

Policy is an explicit deny system: a more permissive assignment lower down doesn’t override a deny higher up. You exclude or exempt the lower scope instead.

Remediation and managed identity

Existing non-compliant resources aren’t fixed automatically. For deployIfNotExists and modify you run a remediation task, and Azure Policy makes the change using the assignment’s managed identity (system-assigned or user-assigned, one per assignment). In the portal the identity gets its roles automatically; through an SDK, you grant them yourself, or the remediation fails. Granting those roles needs User Access Administrator (or Owner); Contributor can trigger remediation but can’t create definitions or assignments.

Resource locks: what can’t be deleted

There are two levels:

• CanNotDelete (Delete in the portal): read and modify, but not delete.
• ReadOnly (Read-only): read only, similar to restricting everyone to Reader.

Locks go on a subscription, resource group or resource. You can’t lock a management group. Locks are inherited, and the most restrictive one wins. A Delete lock on one resource stops its whole resource group from being deleted.

Locks apply to the control plane (management.azure.com), not the data plane. A ReadOnly lock on a SQL logical server still lets you change the data in its databases, and no lock on a storage account protects the blobs, files, queues or tables inside it.

Only someone with Microsoft.Authorization/locks/* (Owner and User Access Administrator have it) can create or remove a lock.

Three traps

1. The Owner can’t delete a locked resource. They have to remove the lock first, then delete. A Contributor can do neither.
2. ReadOnly breaks things that look harmless. Locks block POST requests, so a ReadOnly lock stops you listing storage account keys, starting or restarting VMs in a locked resource group, and scaling an App Service plan.
3. Audit doesn’t fix anything. Audit only reports. To bring existing resources into line, use deployIfNotExists or modify and run a remediation task, with a managed identity that holds the right role.

Pick it in five seconds

Go deeper

Azure Policy, resource locks, management groups and RBAC are all in the governance objectives of the AZ-104 study guide, with the design view in the AZ-305 study guide and the fundamentals in the AZ-900 study guide. Facts checked against Microsoft Learn on 8 October 2026.