Manage Azure RBAC and Scope for AZ-104
Understand built-in roles, assignment scope, inherited access, and effective permissions for the Azure RBAC questions that appear on AZ-104.
Azure RBAC is where many AZ-104 questions stop being conceptual and start becoming operational. The exam wants to know whether you can grant the right permission at the right scope without creating a security or management problem three weeks later.
Azure RBAC: Azure role-based access control for authorization on Azure resources.
Management group: Governance container above subscriptions that lets Azure apply access or policy higher in the hierarchy.
Microsoft Entra: Microsoft’s cloud identity and directory platform.
The hierarchy you need in your head
Azure scope flows downward from management group to subscription to resource group to resource. A role assignment made higher in the tree usually affects everything below it. That is why the safest default is the lowest scope that still solves the task.
What Microsoft is testing
The study guide focuses on built-in Azure roles, assigning roles at different scopes, and interpreting access assignments. In practice, that means reading a scenario and deciding whether Reader, Contributor, Owner, User Access Administrator, or another built-in role is enough. Start with built-in roles before you think about custom roles.
The distinction that prevents bad answers
Microsoft Entra roles govern directory administration. Azure RBAC governs access to Azure resources. Those two systems interact, but they are not interchangeable. The exam often hides this distinction inside routine wording such as “manage access” or “review permissions.”
Common traps
- assigning at subscription scope because the answer looks simpler
- confusing inherited access with direct assignment
- picking Owner when Contributor plus a narrower scope would work
- overlooking the “Check access” or effective access path when interpreting permissions
Lab moves worth practicing
- assign Reader, Contributor, and User Access Administrator at different scopes
- inspect inherited permissions from a parent scope
- verify access on a specific resource instead of trusting memory
Scope chooser
| Requirement | Best default scope | Why |
|---|---|---|
| One team manages one application stack | Resource group | Keeps rights narrow and operationally useful |
| A role must span everything in one billing boundary | Subscription | Broad enough when the entire subscription is in scope |
| Governance or access must span multiple subscriptions | Management group | Avoids repeating assignments subscription by subscription |
| One operator needs access to a single resource only | Resource | Smallest blast radius |
Azure CLI example: least-privilege role assignment
This is the pattern AZ-104 wants you to recognize even if the question is phrased in portal language.
1az role assignment create \
2 --assignee-object-id <principal-object-id> \
3 --assignee-principal-type User \
4 --role Reader \
5 --scope /subscriptions/<sub>/resourceGroups/app-rg
What matters in this example:
- the assignment uses a built-in role instead of a custom role
- the scope is narrowed to the resource group rather than the whole subscription
- the command targets a principal explicitly, which is what Azure will evaluate for effective access
Quiz
Continue with Policy, Tags, Locks, and Cost Control to separate authorization from governance guardrails.