Azure RBAC vs Azure Policy vs Entra roles vs resource locks

A deployment fails with a 403 and the person who hit it asks to be made Owner. Sometimes that would help. Often it wouldn't, because the thing that blocked them was not a missing permission at all but a policy rule or a lock, and no amount of extra role assignments gets past either of those. Azure has four separate controls that all sound like "who is allowed to do what", and they answer different questions.

Exam questions on AZ-900, AZ-104 and AZ-305 lean on this hard. The scenario usually describes an outcome (block a region, stop a deletion, let a team manage VMs, let someone reset passwords) and offers all four tools as options. If you know which question each tool answers, most of these become quick.

The four controls in one sentence each

Azure RBAC decides what a given identity may do to Azure resources: who can create, read, change or delete them.
Azure Policy decides what the resources themselves are allowed to look like, regardless of who is asking: which regions, SKUs, tags or settings are acceptable.
Microsoft Entra roles decide who may administer the directory: users, groups, app registrations, licences, domains and password resets.
Resource locks stop a subscription, resource group or resource from being deleted or changed by anyone, including Owners, until the lock is removed.

Azure RBAC

A role assignment has three parts: a security principal (a user, group, service principal or managed identity), a role definition (a list of allowed actions), and a scope. The scope can be a management group, a subscription, a resource group or a single resource, and an assignment at any level flows down to everything beneath it.

RBAC is additive. If you hold Reader on a subscription and Contributor on one resource group inside it, your effective rights in that resource group are Contributor. There is no "most restrictive wins" rule between role assignments, and a narrower assignment never takes away something a broader one granted. The only thing inside RBAC that subtracts access is a deny assignment, and you can't create those yourself in general: Azure creates them, for example when a deployment stack is set to protect its resources. When access is checked, deny assignments are evaluated first.

A few built-in roles come up constantly:

Owner can manage everything and assign roles to others.
Contributor can manage everything but cannot grant access.
Reader can view everything and change nothing.
User Access Administrator and Role Based Access Control Administrator manage role assignments without needing broad rights over the resources themselves.

Roles split permissions into Actions (control plane, the management API) and DataActions (the data inside a resource, such as blob contents). That is why Owner on a storage account does not on its own let you read blobs with your Entra identity; you need a data role such as Storage Blob Data Reader. When built-in roles don't fit, you write a custom role and list where it can be used in AssignableScopes. A custom role can name only one management group there, and a custom role that contains DataActions can't be assigned at management group scope at all.

Azure Policy

A policy definition describes a condition and an effect. You assign it (or a group of definitions called an initiative) at a management group, subscription or resource group, and it applies to everything in that scope, including resources created later. Policy does not care who the caller is. An Owner who tries to create a VM in a forbidden region is refused exactly like a Contributor.

The effects you need to know:

Deny stops a create or update request that doesn't comply. For Resource Manager properties, the request is rejected before it reaches the resource provider, and the caller sees a 403 with the code RequestDisallowedByPolicy.
Audit lets the request through and marks the resource non-compliant, writing a warning to the activity log. Nothing is blocked.
AuditIfNotExists checks whether a related resource exists (a diagnostic setting, an extension) and flags the parent if it doesn't.
Append and Modify change the request on its way in, for example adding a tag. Modify can also fix existing resources.
DeployIfNotExists deploys the missing related resource after the main one is created.
DenyAction blocks a specific action, typically delete, on matching resources.
Disabled switches the rule off without deleting the assignment.

Deny and audit only judge requests as they arrive. Resources that already exist and break a new deny policy are not deleted or changed; they show up as non-compliant. To fix existing resources you need Modify or DeployIfNotExists plus a remediation task, and those assignments need a managed identity with enough RBAC rights to make the change.

When several policy assignments overlap, each is evaluated on its own, so the net result is the most restrictive combination. That is the opposite of RBAC's additive model and a favourite exam contrast. To carve out an exception, use an exclusion on the assignment (a scope it skips) or an exemption (a separate object on a specific scope or resource, with a reason and an optional expiry date).

Microsoft Entra roles

Entra roles such as Global Administrator, User Administrator and Billing Administrator manage the directory itself. Their scope is the tenant, an administrative unit, or a single object like one app registration. They are not assigned on subscriptions or resource groups.

The two role systems do not overlap by default. A Global Administrator has no access to Azure resources until they use the Access management for Azure resources switch, which gives them User Access Administrator at the root scope so they can grant themselves or others Azure roles. In the other direction, an Owner of every subscription still can't reset a user's password. The old classic administrator roles (Service Administrator, Co-Administrator) are retired, so any answer that relies on them is out of date.

Resource locks

A lock comes in two levels:

CanNotDelete (Delete in the portal): people can read and modify the resource but not delete it.
ReadOnly: people can read but not modify or delete, which in effect caps everyone at Reader.

Locks can be applied to a subscription, a resource group or a resource, not to a management group. They inherit downwards, and the most restrictive lock in the chain applies. A delete lock on one resource also blocks deletion of its whole resource group. Creating or removing a lock needs Microsoft.Authorization/locks/*, which Owner and User Access Administrator have; Contributor does not.

Locks protect the control plane only. A ReadOnly lock on a storage account does not stop anyone deleting blobs through the data endpoint, but it does block listing the account keys, because that is a POST to the management API. Read-only locks also break things that look harmless, such as starting a VM or scaling an App Service plan.

How to choose

If the requirement is about who can manage resources, use RBAC. Pick the narrowest built-in role at the narrowest scope that works, and assign it to a group rather than to individuals.
If the requirement is about what is allowed to exist (regions, SKUs, mandatory tags, encryption settings), use Azure Policy, and assign it high enough that new subscriptions inherit it.
If the requirement is to block a non-compliant setting, use Deny. If it is to report without disrupting anyone, use Audit. If it is to fix, use Modify or DeployIfNotExists with a remediation task.
If the requirement is about users, groups, passwords, licences or app registrations, it is an Entra role, not an Azure role.
If the requirement is "nobody, not even an Owner, should delete this by accident", use a CanNotDelete lock.
If many subscriptions need the same RBAC or policy, put them under a management group and assign once there.

Common exam traps

Assuming RBAC picks the most restrictive role. It adds them up. Reader at a high scope never cancels Contributor at a lower one.
Treating a policy 403 as a permissions problem. RequestDisallowedByPolicy means a deny effect fired. Making the user Owner changes nothing; you deploy something compliant, change the policy or add an exemption.
Expecting Deny to clean up existing resources. It only stops new creates and updates. Existing violators become non-compliant and stay as they are.
Using a lock where policy was needed, or the reverse. Locks don't care about properties, and policy is not the tool to stop one specific resource from being deleted.
Thinking Global Administrator can manage subscriptions out of the box. Entra roles and Azure roles are separate until access is elevated.
Assuming a ReadOnly lock protects data. It protects the resource configuration, not blobs, files or database rows reached through the data plane.

A worked example

A company has three subscriptions under a management group called Corp. Security asks for four things: every resource must stay in two European regions, the platform team must be able to manage all resources but not grant access, the helpdesk must reset user passwords, and the shared hub virtual network must not be deleted by mistake.

The region rule is about what may exist, not who creates it, so it is an Azure Policy with the built-in allowed locations definition and the Deny effect, assigned on Corp so all three subscriptions and any future ones inherit it. The platform team needs broad management without access control, which is Contributor, assigned to their group on Corp. The helpdesk requirement is about the directory, so it goes to the Entra Helpdesk Administrator or User Administrator role, not anything on a subscription. The hub network gets a CanNotDelete lock on the resource itself, or on its resource group if everything in there is shared. It stays editable so routes and peerings can still change, and it can't be deleted until an Owner removes the lock.

Notice that none of the four answers would work in another slot. A lock can't express "only in Europe", and Contributor can't reset a password.