Azure RBAC vs Policy vs Resource Locks: What Each Does

Three Azure tools sound like they do the same job: they all stop somebody from doing something to a resource. On AZ-900 they appear together constantly, and the question usually describes a problem and asks which one solves it. Get the one-line difference for each and most of those questions become routine.

The short version: RBAC controls who can do what. Azure Policy controls what state resources are allowed to be in. A resource lock protects a specific resource from being changed or deleted, whoever you are. The rest of this post unpacks that, using Microsoft's documentation as of November 2026. All three live in the governance and security parts of the exam outlined in what is on the AZ-900 exam.

Azure RBAC: who can do what

Azure role-based access control is the authorization system built on Azure Resource Manager. It grants access through a role assignment, which has three parts:

1. Security principal: a user, group, service principal or managed identity.
2. Role definition: a collection of permissions, such as Owner or Reader.
3. Scope: where the access applies, at one of four levels: management group, subscription, resource group or resource.

Lower scopes inherit assignments from higher ones, so a role given on a subscription flows down to its resource groups and resources. Permissions are additive: Contributor on a subscription plus Reader on one of its resource groups results in Contributor. RBAC is free and included with every Azure subscription.

Four built-in roles are worth knowing cold:

Owner, Contributor and Reader apply to all resource types. Other built-in roles are specific to a resource type, such as Virtual Machine Contributor. You can also create custom roles when the built-in ones do not fit. The portal shows role assignments on the Access control (IAM) blade.

The sound design principle is least privilege: assign the narrowest scope that works, so a compromised principal puts fewer resources at risk.

Azure Policy: what state resources can be in

Azure Policy creates, assigns and manages rules that control or audit resources so they stay compliant with your standards. It does not care who is making the change. It looks at the resulting configuration.

• A policy definition is a rule with a condition and an effect.
• An initiative is a collection of definitions grouped toward one goal and assigned as a single unit.
• An assignment applies a definition or initiative to a scope: management group, subscription, resource group or resource. Child resources inherit assignments, and you can exclude a subscope.

Each definition has one effect. At AZ-900 level, know these:

• deny blocks a non-compliant resource from being created or updated.
• audit allows it but marks it non-compliant and logs a warning.
• append and modify add or change properties such as tags.
• deployIfNotExists deploys a related resource when it is missing.
• disabled turns the rule off.

Built-in examples include Allowed locations and Allowed virtual machine SKUs. Policy also evaluates resources that existed before the policy did, and it reports a compliance view. To bring existing non-compliant resources into line for modify or deployIfNotExists policies, you create a remediation task.

The key relationship with RBAC: even a user whose role lets them create a resource is blocked by Policy if the result would be non-compliant. Microsoft describes the two as working together for full control of a scope.

Resource locks: protect this specific resource

A resource lock prevents accidental deletion or modification of a resource, even by users with high permissions. You can apply it to a subscription, a resource group or an individual resource, but not to a management group.

There are two levels. The portal names are Delete and Read-only; the command line and API names are CanNotDelete and ReadOnly.

• CanNotDelete: authorized users can read and modify the resource but cannot delete it.
• ReadOnly: authorized users can read it but cannot update or delete it, similar to everyone having only the Reader role.

Locks apply to all users and roles, so they override RBAC. Even an Owner has to remove the lock first. Locks are inherited by child resources, including ones added later, and if locks in the chain differ, the most restrictive one wins. To create or delete locks you need the Microsoft.Authorization permissions that Owner and User Access Administrator have, and Contributor does not.

Two traps: locks cover control plane operations, not the data plane, so a lock does not stop someone changing rows inside a database through its own endpoint. And cancelling an Azure subscription is not blocked by a lock.

Side by side

Tags belong in the comparison as the odd one out: a tag is metadata only and has no protective effect.

Scenario practice

Try to answer before reading the answer.

1. A company wants deployments allowed only in two approved regions. Azure Policy (Allowed locations). RBAC controls actions, not where resources go.
2. A marketing group should manage everything in one resource group and nothing else. RBAC: Contributor assigned at the resource group scope.
3. A production database must stay usable, but nobody should delete it by accident. A CanNotDelete lock.
4. An environment must be frozen so nobody can modify or delete anything. A ReadOnly lock.
5. You need to stop one particular user from creating virtual machines. RBAC. Policy cannot say who.
6. An Owner cannot delete a resource despite full permissions. A lock exists and must be removed first.
7. Every new resource must carry a cost center tag. Azure Policy, for example with modify or append.

Entra ID roles are a different system

One boundary catches people. Azure roles manage Azure resources. Microsoft Entra roles manage Entra resources such as users, groups, domains and passwords. They are separate by default, with different scopes: Azure roles use management group, subscription, resource group and resource, while Entra roles use the tenant, an administrative unit or an object. Resetting a user's password is an Entra role job, such as User Administrator, not something Contributor on a subscription gives you. A Global Administrator has no Azure resource access by default, though it can elevate access to User Access Administrator on all subscriptions.

A fourth tool sometimes joins the lineup: Conditional Access. It decides whether a sign-in or access is allowed under conditions such as location or device. So the full sort is: Conditional Access for sign-in conditions, RBAC for allowed actions, Policy for resource configuration, locks for protection from change.

Making the differences stick

Write one sentence for each pair and say it from memory, then return to it on a schedule rather than rereading. That is the habit behind the testing effect, and the rest of the plan is in how to study for AZ-900. For another set of look-alikes that scenario questions combine with these, see LRS, ZRS, GRS and GZRS explained. When you want to test yourself, AZ-900 practice questions has governance cards in the same format.

The matching cards are in the Azure Fundamentals course, in the identity and governance units. The course is unofficial and not affiliated with or endorsed by Microsoft, and the cards are recall practice. Open the portal, add a lock to a test resource group and try to delete something in it: seeing the error does more for memory than reading about it.