Academmia

Azure Role-Based Access Control (RBAC): who can do what, where

az-900•mixed•

Azure architecture and services

Azure Role-Based Access Control (RBAC): who can do what, where

Short Summary

Azure role-based access control (Azure RBAC) is Azure’s main way to manage authorization (permissions) for resources. It works by creating role assignments that combine who (a security principal), what (a role definition), and where (a scope). In this lesson, you’ll practice choosing the smallest scope and the most specific role to follow least privilege. You’ll also see where RBAC ends and where sign-in controls (like Conditional Access) and governance controls (like Azure Policy and resource locks) take over.

Learning Objectives

By the end of this lesson, you will be able to:

  • Explain the difference between authentication (AuthN) and authorization (AuthZ) in Azure access control.
  • Describe the three parts of a role assignment: security principal, role definition, and scope.
  • Choose an appropriate scope (management group, subscription, resource group, or resource) for common access needs.
  • Differentiate Azure RBAC from Conditional Access, Azure Policy, and resource locks.
  • Apply least privilege when selecting built-in roles such as Reader, Contributor, Owner, and User Access Administrator.

Core Concepts

What Azure RBAC is (and where it sits)

Azure RBAC is an authorization system used to control access to Azure resources. It’s built on Azure Resource Manager (ARM), meaning RBAC is evaluated when you try to perform management actions through ARM (for example: create, update, delete, or read Azure resources).

A helpful mental model:

  • AuthN (Authentication) answers: “Who are you?” (sign-in and identity)
  • AuthZ (Authorization) answers: “What are you allowed to do?” (permissions)

Microsoft Entra ID is where identities live (users, groups, service principals, managed identities). Azure RBAC is how you grant those identities permissions to Azure resources.

The RBAC “recipe”: who + what + where

Access in RBAC is granted by creating a role assignment, which is made of three parts:

  1. Security principal (who): the identity getting access (user, group, service principal, or managed identity).
  2. Role definition (what): a set of allowed actions (permissions). Azure provides built-in roles and you can create custom roles when needed.
  3. Scope (where): the boundary the permissions apply to.

If you remember only one sentence, make it this:

RBAC is “who can do what at which scope.”

Scope and inheritance

Scopes are hierarchical. A role assigned at a higher scope flows down to lower scopes:

  • Management group
  • Subscription
  • Resource group
  • Resource

Example: if I assign someone Reader at a subscription, they can read resources in every resource group in that subscription (unless something else blocks the action, like a lock or a deny/condition).

Rule of thumb: use the smallest scope that meets the need.

Built-in roles you’ll see everywhere

Azure has many built-in roles, but these show up constantly:

  • Reader: can view resources, cannot make changes.
  • Contributor: can create and manage resources, but cannot grant access to others (no role assignments).
  • Owner: full access, including the ability to manage access (assign roles).
  • User Access Administrator: can manage access (role assignments), typically without needing full resource management permissions.

This is why least privilege often means: start with Reader, then move to Contributor, and only use Owner/User Access Administrator when managing access is part of the job.

RBAC vs Conditional Access vs Policy vs Locks

These controls solve different problems:

  • Conditional Access: “Under what conditions can you sign in?” (device, MFA, location, risk, etc.). It happens at sign-in / token level, before you even try to change a resource.
  • Azure RBAC: “After you are signed in, what actions can you do on this resource?”
  • Azure Policy: “What is allowed to exist or be configured?” (governance/compliance). Policy can deny creation of certain resources/configs even if you have RBAC permissions.
  • Resource locks: “Even if you have permission, can you delete or change this?” A lock can block deletes/updates until removed.

Practical Understanding

Situation 1: A developer needs to restart VMs in one app’s resource group

You want the developer to manage only what they need in that one area.

  • Recommended approach: assign a VM-focused role (or an appropriate built-in role) at the resource group scope that contains those virtual machines (VMs), not at the subscription.
  • Common misunderstanding: “I’ll just give Owner so they can’t get blocked.” Owner is almost never needed for day-to-day work and makes it easy to accidentally grant others access or cause broad-impact changes.

Situation 2: A security team wants everyone to use MFA, even if they already have RBAC permissions

RBAC doesn’t enforce sign-in requirements.

  • Recommended approach: use Conditional Access to require multi-factor authentication (MFA), and keep RBAC focused on permissions.
  • Common misunderstanding: “RBAC can require MFA.” RBAC controls actions on resources; Conditional Access controls sign-in conditions.

Situation 3: A team can create resources, but they keep getting blocked when deploying certain SKUs

This often isn’t a permissions problem.

  • Recommended approach: check Azure Policy assignments (for example, allowed locations, allowed resource types, allowed SKUs/tier configurations).
  • Common misunderstanding: “If deployment fails, I need more RBAC permissions.” Policy can deny certain configurations even if you are Contributor.

Situation 4: A user has Contributor but still can’t delete a resource

This is a classic “permissions vs protection” moment.

  • Recommended approach: check for resource locks (CanNotDelete / ReadOnly) on the resource or parent scope.
  • Common misunderstanding: “Contributor should always be able to delete things.” Locks can block deletes/changes until removed by someone with the right permissions.

Common Pitfalls

  • Mistake: Assigning roles at the subscription when only one resource group is needed. Correction: Use the smallest scope that meets the requirement (resource group or resource when possible).

  • Mistake: Using Owner as a default “to avoid blockers.” Correction: Start with Reader/Contributor and only use Owner or User Access Administrator when access management is required.

  • Mistake: Treating Conditional Access as “permissions.” Correction: Use Conditional Access for sign-in conditions; use RBAC for allowed actions on resources.

  • Mistake: Assuming every deployment failure is an RBAC issue. Correction: Check Azure Policy assignments and resource locks when actions are denied.

  • Mistake: Assigning permissions directly to individuals everywhere. Correction: Prefer groups (and assign roles to groups) so access is easier to audit and manage.

  • Mistake: Forgetting to remove role assignments when someone no longer needs access. Correction: Review and remove role assignments regularly, especially when people change roles or leave the team.

Check Your Understanding

  1. In your own words, explain AuthN vs AuthZ and where RBAC fits.
  2. Give an example of a role assignment using “who + what + where.”
  3. Describe a case where Conditional Access is the right tool, not RBAC.
  4. Describe a case where Azure Policy blocks an action even if RBAC allows it.
  5. What would you check first if a Contributor can’t delete a resource?

Further Reading