Azure Policy vs RBAC vs resource locks
Azure RBAC decides who may perform an action, Azure Policy decides what resource configurations are allowed regardless of who deploys them, and a resource lock stops deletion or modification for everyone until the lock is removed. The decision rule is to ask which noun the requirement is about: a person or group points to RBAC, a property of the resource such as region, SKU or tag points to Policy, and “must not be deleted” points to a lock.
The cheat sheet: requirement phrase to tool
| Requirement says | Tool | Why |
|---|---|---|
| “Helpdesk can restart VMs but not delete them” | RBAC | It is about a user’s allowed actions |
| “Resources may only be created in West Europe” | Policy (Deny) | It restricts a property of the resource, for any user |
| “Every resource must have a CostCenter tag” | Policy (Deny, or Modify to add it) | Tags are properties |
| “Nobody, not even an Owner, may delete the production resource group” | Lock (CanNotDelete) | Overrides permissions |
| “Report which VMs lack disk encryption, change nothing” | Policy (Audit) | Assessment without enforcement |
| “Deploy a diagnostic setting automatically to every new resource” | Policy (DeployIfNotExists) | Deploys related resources |
| “Developer may manage VMs in RG-Dev only” | RBAC at resource group scope | Scope and role |
| “Block a deployment even though the user is a Contributor” | Policy | Permission alone does not override Policy |
How each one works, in one paragraph
RBAC attaches a role to a principal at a scope, and the permission flows down to child scopes. It answers “is this identity allowed to run this operation?”. See Azure RBAC vs Entra roles for the role families.
Azure Policy compares the properties of resources, and some actions, against rules written in JSON. A definition holds the rule and its effect, an initiative groups definitions, and an assignment applies either to a scope, optionally with exclusions. Microsoft’s own wording is that Policy ensures state is compliant “without concern for who made the change”. Even a user with full rights is blocked if the result violates a Deny policy.
Locks are the blunt instrument. There are two levels, shown as Delete and Read-only in the portal and CanNotDelete and ReadOnly on the command line. CanNotDelete allows reads and changes. ReadOnly allows only reads and behaves roughly like giving every user the Reader role.
What each one can and cannot do
| RBAC | Azure Policy | Lock | |
|---|---|---|---|
| Question answered | Who may act | What may exist | Can this be changed or deleted |
| Applies to | Identities | Resources (and some actions) | Everyone, Owners included |
| Inherits downwards | Yes | Yes, exclusions possible | Yes, most restrictive wins |
| Fixes existing resources | n/a | Only with remediation tasks | n/a |
| Evaluated | At each request | At create or update, on new or changed assignments, and about every 24 hours | At each management request |
| Needed to create | Permission to write role assignments | Policy write permission | Microsoft.Authorization/locks rights, held by Owner and User Access Administrator |
Two limits surface in exams. Locks apply only to the control plane (Azure Resource Manager operations), not the data plane, so a lock on a storage account does not stop someone deleting blobs with a data-plane call. And Policy evaluates resources at subscription and resource-group level even if the assignment is made at a management group.
Worked example: protecting a production storage account
A team keeps customer exports in a storage account, stexports, in RG-Prod. The requirements arrive one by one.
- “Only the data team may read the blobs.” RBAC: assign the data team a data-plane role such as Storage Blob Data Reader on the account or container. Everyone else gets nothing.
- “No storage account in the subscription may allow public blob access.” Policy with a Deny effect assigned to the subscription. Start with Audit if existing resources might break, which is Microsoft’s recommended way to test an assignment, then switch to Deny. Existing accounts are only reported until you remediate them.
- “The account must survive an administrator’s mistake.” CanNotDelete lock on the account. A ReadOnly lock would be tempting but blocks listing the account keys (a POST operation), blocks creating blob containers through the control plane (the data plane can still create them) and prevents role assignments on the account. Choose it carefully.
- “Someone with Owner removes the lock and deletes it.” Neither RBAC nor Policy stops an Owner from removing a lock, since Owner can manage locks. The fix is to give people narrower roles, such as Contributor, who cannot. A lock is a safety net against mistakes, not a security boundary against an administrator.
The same governance goes much further in Azure governance design, where management groups and landing zones carry the assignments.
Which exams test this
| Exam | How it appears | Covered on this site |
|---|---|---|
| AZ-900 | Management and governance domain: describe the purpose of Azure Policy and resource locks; RBAC sits in the architecture and services domain | Management and governance |
| AZ-104 | Identities and governance domain: implement Azure Policy, configure resource locks, assign built-in roles at different scopes and interpret assignments | Identities and governance |
| AZ-305 | Identity, governance and monitoring domain: recommend a compliance solution and a way to authorize access to Azure resources; locks are not named | Identity, governance and monitoring |
| SC-500 | Identity, access and governance domain: security controls with built-in and custom Azure Policy definitions, resource locks, built-in and custom role assignments, removing overprivileged access | Identity, access and governance |
How exam questions are built around this
The scenario describes a need and offers all three tools, plus often a distractor such as Defender for Cloud or tags. The constraint words:
- “Regardless of permissions”, “even Owners”, “accidental deletion” mean a lock.
- “Prevent”, “enforce”, “block creation”, “only allowed” with a resource property mean Policy with Deny; “identify”, “report”, “visibility” mean Audit or a Defender for Cloud recommendation.
- “Automatically add”, “inherit the tag”, “configure on existing resources” mean Modify or DeployIfNotExists, and the word existing means a remediation task is needed.
- “User”, “group”, “least privilege”, “delegate” mean RBAC.
- The ReadOnly trap: a question asks why a user with Owner cannot list storage keys or start a VM in a resource group; a ReadOnly lock is the cause. The same goes for a CanNotDelete lock on the Backup service’s resource group breaking backups; see Azure Backup and Site Recovery.
- “Management group” for locks: locks cannot be added to management groups, only to subscriptions, resource groups and resources.
Practice questions
Question 1. All resources in a subscription must be deployed only to West Europe or North Europe. Contributors currently create resources in other regions. What should you use?
- A. Remove the Contributor role from all users
- B. A CanNotDelete lock on the subscription
- C. An Azure Policy assignment with the Allowed locations definition and the Deny effect
- D. A budget with an alert threshold
Show answer
Answer: C
A Policy assignment using the Allowed locations definition with a Deny effect blocks creation in other regions regardless of the user. RBAC role changes control who can act, not which region they pick. A lock prevents changes and deletions, not creation in a particular region. A budget alerts on cost but blocks nothing.
Question 2. An administrator who holds the Owner role cannot list the access keys of a storage account in the portal, although the role normally allows it. No Azure Policy is assigned. What is the most likely cause?
- A. The Owner role was reassigned at the resource group scope
- B. A ReadOnly lock is applied to the storage account or inherited from its resource group
- C. A Deny policy applies to the subscription
- D. A CanNotDelete lock is applied to the storage account
Show answer
Answer: B
A ReadOnly lock on the storage account blocks the List Keys operation because it is a POST request, and locks override role permissions, including Owner. Removing a role assignment would have removed more than key access. A Deny policy affects creation and updates of resources, not listing keys. A CanNotDelete lock still allows reads and modifications.
Go deeper
- Overview of Azure Policy, with the Policy and RBAC comparison used here.
- Lock your Azure resources, for inheritance and the list of operations a lock breaks.
- What is Azure role-based access control?, for scopes and role assignments.
- On this site: Azure RBAC vs Entra roles, Azure governance design, and the AZ-104 cheat sheet.