SkarpSkarp

Chapter 13 of 20

Governance and Access Control: Role-Based Access Control (RBAC) in Azure

Zoom in on how Azure decides who can do what to which resource using role assignments, scopes, and built-in roles.

27 min readen

Big Picture: Where RBAC Fits in Azure Governance

From Identity to Authorization

Microsoft Entra ID proves who you are. RBAC answers the next question: What are you allowed to do to which Azure resources?

Canonical RBAC Definition

Role-based access control (RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources based on roles assigned to users, groups, and service principals.

Key Pieces of the Definition

  • Authorization system after sign-in
  • Built on Azure Resource Manager
  • Fine-grained actions (read, write, delete)
  • Uses roles assigned to users, groups, and service principals

Why This Matters for AZ-900

You must understand how roles and scopes combine to decide access. You do not need every role memorized, but you must grasp the mechanism and typical scenarios.

Core RBAC Concepts: Roles, Principals, and Role Assignments

Security Principals: The Who

A security principal is who gets permissions: a user, group, or service principal (app/automation identity). RBAC never acts without a principal.

Role Definitions: The What

A role definition is a bundle of allowed actions, like Owner, Contributor, or Reader. It does not apply until assigned to a principal at some scope.

Scope: The Where

Scope is the boundary where the role applies: management group, subscription, resource group, or individual resource.

Role Assignment = Who + What + Where

A role assignment combines principal + role + scope. Azure checks these assignments to decide if an operation is allowed on a resource.

RBAC Scopes: Management Group, Subscription, Resource Group, Resource

Why Scope Matters

Scope controls how far a role assignment reaches. Assign at a broad scope for wide access, or a narrow scope for tightly limited access.

The Four Main Scopes

From broad to narrow: management group → subscription → resource group → resource. RBAC permissions inherit down this hierarchy.

Management Group and Subscription

Management group scopes can span many subscriptions. A subscription scope covers all resource groups and resources in that subscription.

Resource Group and Resource

A resource group scope covers all resources inside it. A resource scope targets one specific resource, the narrowest level of control.

Visualizing RBAC Inheritance with a Scenario

Contoso's Azure Hierarchy

mg-Contoso → sub-Prod → rg-WebAppProd → vm-web-01, stwebprod, sql-web-prod. Permissions flow down this chain.

High-Level Assignments

SecurityTeam: Security Admin at mg-Contoso. CloudOps: Contributor at sub-Prod. These grant broad rights across many resources.

Workload-Level Assignment

DevTeam: Contributor at rg-WebAppProd, so they can manage all resources in that group but nothing outside it.

Resource-Level Assignment

Alice: Reader on vm-web-01 only. She can view that VM but cannot change or delete it and has no rights to other resources.

Built-in Roles vs Custom Roles

What Are Built-in Roles?

Built-in roles are predefined by Microsoft. They cover common tasks like full control (Owner), manage resources (Contributor), and view only (Reader).

Key Built-in Roles to Know

Owner: full control + grant access. Contributor: manage resources, no access control. Reader: view only. User Access Administrator: manage role assignments.

What Are Custom Roles?

Custom roles are defined by you, using JSON, when built-in roles do not fit very specific permission requirements.

Exam Tip: Built-in First

For AZ-900 scenarios, assume a built-in role is sufficient unless the question clearly states that no built-in role meets the requirement.

Least Privilege: Choosing the Smallest Role and Scope That Works

Least Privilege Defined

Least privilege means granting only the minimum permissions required to perform a job, and nothing more.

Two Dimensions: Role and Scope

Use the least powerful role that works and the narrowest scope that covers the needed resources.

Examples of Good Choices

Viewer-only needs? Reader at the right scope. Needs to manage one VM? VM-specific role at the resource scope, not Contributor at subscription.

Exam Language Cues

Phrases like "minimize permissions" or "follow least privilege" signal that you should choose the smallest scope and least powerful role that meets requirements.

Thought Exercise: Picking the Right Role and Scope

Work through these scenarios. Think first, then reveal the guidance (mentally or in notes).

  1. Scenario A: Billing Analyst
  • Need: View cost and usage data for subscription `sub-Marketing` but cannot change resources.
  • Question: Which role and scope best follow least privilege?
  • Hint: Viewing cost data is not the same as managing VMs or storage.
  1. Scenario B: App Team Developer
  • Need: Full control over resources in `rg-App1Prod` only. Must not affect other resource groups.
  • Question: Which role and scope?
  1. Scenario C: Security Auditor
  • Need: Read-only access to all resources across all production subscriptions for audit.
  • Question: Is a management group scope appropriate here? Which role?
  1. Scenario D: Automation Runbook
  • Need: A script (using a service principal) that rotates keys on a single storage account.
  • Question: Which identity type, role type, and scope best fit least privilege?

Suggested answers (compare after you think):

  • A: Use a billing or cost management–related built-in role (for AZ-900, conceptual) at the subscription scope.
  • B: Contributor at the resource group scope `rg-App1Prod`.
  • C: Reader at a management group scope that contains all production subscriptions.
  • D: A service principal with a storage-specific role at the resource scope of that storage account.

Notice how each answer tries to avoid unnecessary power or overly broad scopes.

Quiz 1: Roles, Scopes, and Least Privilege

Answer this exam-style question to check your understanding.

Your company has a subscription named Sub-Dev. The DevTeam group should be able to create, modify, and delete resources only in a resource group named rg-DevApp within Sub-Dev. They must NOT manage resources in other resource groups. Which option best follows the principle of least privilege?

  1. Assign the Owner role to DevTeam at the subscription scope Sub-Dev.
  2. Assign the Contributor role to DevTeam at the resource group scope rg-DevApp.
  3. Assign the Reader role to DevTeam at the resource group scope rg-DevApp.
  4. Assign the Contributor role to DevTeam at the subscription scope Sub-Dev.
Show Answer

Answer: B) Assign the Contributor role to DevTeam at the resource group scope rg-DevApp.

DevTeam needs to create, modify, and delete resources, so Reader is insufficient. Contributor is appropriate for managing resources, but to follow least privilege they should be scoped only to rg-DevApp, not the entire subscription. Owner is unnecessarily powerful because it allows granting access to others.

Quiz 2: Built-in vs Custom Roles

Another quick check on when to use built-in roles.

A manager needs to view all resources in a subscription but must not make any changes. What is the most appropriate approach for an AZ-900-level solution?

  1. Create a custom role with read-only permissions and assign it at the subscription scope.
  2. Assign the Reader built-in role at the subscription scope.
  3. Assign the Contributor built-in role at the subscription scope.
  4. Assign the Owner built-in role at the resource group scope for each resource group.
Show Answer

Answer: B) Assign the Reader built-in role at the subscription scope.

The Reader built-in role is designed for view-only access. Assigning it at the subscription scope lets the manager view all resources without changing them. Creating a custom role is unnecessary for this common scenario, and Contributor or Owner would violate least privilege.

How Azure Evaluates an Access Request (Conceptual Flow)

Step 1: Authentication

Microsoft Entra ID authenticates the user or app and issues a token that proves identity and tenant.

Step 2: Identify the Principal

Azure Resource Manager sees which user, groups, or service principal is making the request.

Step 3: Gather Role Assignments

Azure collects all role assignments for that principal at the resource, resource group, subscription, and management group scopes.

Step 4: Decide Allow or Deny

If any applicable role assignment grants the needed action, access is allowed; otherwise it is denied. Permissions from multiple roles add up.

Flashcards: RBAC Key Terms and Concepts

Use these cards to reinforce your memory of core RBAC concepts and exam-ready definitions.

Canonical definition of role-based access control (RBAC)
Role-based access control (RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources based on roles assigned to users, groups, and service principals.
Security principal (in Azure RBAC)
The "who" in RBAC: a user, group, service principal, or managed identity that can be assigned roles to access Azure resources.
Role definition
A collection of permissions that describe allowed actions on Azure resources, such as Owner, Contributor, or Reader.
Scope (in Azure RBAC)
The boundary where a role assignment applies: management group, subscription, resource group, or individual resource. Permissions inherit from higher to lower scopes.
Role assignment
The combination of a security principal, a role definition, and a scope that grants that principal the permissions of that role at that scope.
Least privilege principle (in RBAC)
Grant only the minimum permissions required for a user or app to perform its tasks, using the least powerful role and narrowest scope that still meets the need.
Built-in role vs custom role
Built-in roles are predefined by Microsoft for common tasks (Owner, Contributor, Reader, etc.). Custom roles are defined by customers when built-in roles do not meet specific permission requirements.
Owner vs Contributor
Owner has full access to resources and can grant access to others. Contributor can create and manage resources but cannot grant access.
Reader role
A built-in role that provides view-only access to Azure resources without the ability to modify or delete them.
User Access Administrator role
A built-in role that allows managing who has access to Azure resources (role assignments), without necessarily granting rights to manage the resources themselves.

Key Terms

Owner
A built-in role that grants full access to all resources at a given scope and allows the holder to delegate access to others.
scope
The level in the Azure hierarchy where a role assignment applies: management group, subscription, resource group, or individual resource.
Reader
A built-in role that grants view-only access to resources at a given scope, with no permission to modify or delete.
Contributor
A built-in role that allows creating and managing resources at a given scope but does not allow granting access to others.
custom role
A user-defined role created to meet specific permission requirements that are not covered by built-in roles.
subscription
An Azure entity that groups resource groups and resources under a common billing and governance boundary.
built-in role
A predefined role provided and maintained by Microsoft that groups common sets of permissions for typical tasks.
resource group
A logical container in Azure that holds related resources for an application or workload, enabling unified management of those resources.
least privilege
A security principle that recommends granting only the minimum permissions necessary for a user or application to perform its required tasks.
role assignment
The binding of a security principal to a role definition at a particular scope, which grants the permissions of that role at that scope.
role definition
A collection of permissions that define which actions are allowed on Azure resources, such as Owner, Contributor, or Reader.
management group
A container in Azure used to manage access, policy, and compliance across multiple subscriptions.
security principal
An identity that can be granted access to Azure resources, such as a user, group, service principal, or managed identity.
User Access Administrator
A built-in role that allows managing role assignments (who has what access) at a given scope, without necessarily managing the resources themselves.
role-based access control (RBAC)
An authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources based on roles assigned to users, groups, and service principals.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself