This chapter covers Role-Based Access Control (RBAC), Azure's system for managing who can do what to specific resources. AZ-900 tests this under objective 2.5, connecting identity (covered in earlier chapters) to actual resource-level permissions.
Jump to a section
A simple way to picture Role-Based Access Control (RBAC)
In most companies, what you're allowed to do isn't decided individually for every employee from scratch — it's tied to your role. A finance manager role comes with access to financial systems; an IT administrator role comes with access to system configurations. Assigning someone to a role automatically grants the permissions that come with it, rather than configuring each person's access one permission at a time. Role-Based Access Control (RBAC) in Azure works the same way — permissions are bundled into roles, and assigning a user (or group) to a role grants them exactly the permissions that role includes, at a specific scope.
What RBAC is
Role-Based Access Control (RBAC) is Azure's system for granting access to resources by assigning roles to users, groups, or applications, rather than assigning individual permissions one at a time. A role defines a set of permissions (what actions are allowed), and assigning that role to an identity grants those permissions.
The three core elements
RBAC assignments consist of three parts: a security principal (the user, group, or application being granted access), a role definition (the set of permissions being granted), and a scope (where those permissions apply — a specific resource, a resource group, a subscription, or a management group).
Built-in and custom roles
Azure provides many built-in roles for common scenarios (such as "Reader," which allows viewing resources but not changing them, or "Contributor," which allows creating and managing resources but not granting access to others). Organizations can also create custom roles when the built-in options don't precisely fit their needs.
Why scope matters
The same role can be assigned at different scopes, and permissions generally flow down from broader scopes to narrower ones — a role assigned at the subscription level applies to all resource groups and resources within it, unless overridden more specifically at a narrower scope.
RBAC vs. authentication
RBAC handles authorization — what an already-authenticated identity is allowed to do — distinct from authentication (verifying who that identity is in the first place), covered in an earlier chapter.
Identify the security principal
Determine which user, group, or application needs access — RBAC assignments are made to a specific identity or group of identities.
Choose an appropriate role
Select a built-in role that matches the needed permissions, or create a custom role if no built-in role fits precisely.
Choose the appropriate scope
Decide where the role should apply — a specific resource, a resource group, a subscription, or a management group — since this determines how broadly the permissions take effect.
Assign the role
The role is assigned to the security principal at the chosen scope, granting the corresponding permissions from that point forward.
An organization assigns the built-in "Reader" role to auditors who need to review resource configurations without being able to change anything, while assigning the "Contributor" role to the engineering team that actively builds and manages resources — each group getting exactly the level of access appropriate to their job.
A separate organization assigns a role at the resource group level for a specific project team, so their permissions apply to all the resources within that project's resource group, without needing to configure access to each individual resource one at a time.
Objective 2.5 expects candidates to understand the three core elements of RBAC (security principal, role definition, scope), and common built-in roles like Reader, Contributor, and Owner.
A common wrong answer is confusing RBAC with authentication — RBAC is about authorization (what an already-verified identity can do), not about verifying identity in the first place. Another common trap is not understanding that permissions generally flow down from broader scopes to narrower ones, so a role assigned at a subscription level affects everything beneath it unless more specifically overridden.
Stable terms: RBAC, role, scope, security principal. Knowing the general purpose of common built-in roles (Reader = view only, Contributor = manage resources, Owner = manage resources and access) is frequently tested.
Memory trick: RBAC = who (security principal) gets what permissions (role) and where (scope). Permissions generally flow down from broader scopes to narrower ones.
Role-Based Access Control (RBAC) grants access by assigning roles (bundles of permissions) to security principals, rather than individual permissions one at a time.
RBAC assignments consist of a security principal, a role definition, and a scope.
Azure provides built-in roles like Reader, Contributor, and Owner, and supports custom roles when needed.
Permissions generally flow down from broader scopes (like a subscription) to narrower ones (like a single resource).
These come up on the exam all the time. Here's how to tell them apart.
Reader Role
Can view resources
Cannot make changes
Suited to auditors or those needing visibility only
Contributor Role
Can view and manage resources
Cannot grant access to others
Suited to those actively building and managing resources
Mistake
RBAC and authentication are the same thing.
Correct
RBAC handles authorization — what an already-authenticated identity is allowed to do. Authentication, covered in an earlier chapter, is about verifying who that identity is in the first place.
Mistake
A role assigned at a narrow scope affects the whole subscription.
Correct
It's the opposite — permissions generally flow down from broader scopes to narrower ones. A role assigned at a subscription level affects everything beneath it, while a role assigned at a single resource only affects that resource.
Mistake
Only individual users can be assigned roles.
Correct
Roles can be assigned to users, groups, or applications (service principals) — assigning a role to a group is a common way to manage permissions for multiple people at once.
It's Azure's system for managing access to resources by assigning roles — predefined bundles of permissions — to users, groups, or applications, rather than configuring individual permissions one at a time.
A security principal (the user, group, or application being granted access), a role definition (the set of permissions being granted), and a scope (where those permissions apply — a resource, resource group, subscription, or management group).
Reader allows viewing resources but not making changes. Contributor allows creating and managing resources but doesn't include the ability to grant access to others — that additional capability belongs to the Owner role instead.
You've just covered Role-Based Access Control (RBAC) — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?