Role assignment (RBAC)
What it is
A role assignment is the record that joins three Azure RBAC elements:
Security principal (who) + role definition (what they can do) + scope (where) = an assignment.
A role definition by itself grants nobody anything. The assignment is the answer to “who has which permissions, at which Azure scope?”
Why it exists
Access is a relationship, not a property. Assignments make “who can do what, where” explicit, auditable, and scoped, which is how least-privilege gets implemented and governed.
Key ideas
- Principal: a user, group, service principal, or managed identity that receives the role.
- Scope: management group → subscription → resource group → resource. An assignment inherits to child scopes, so a subscription-level role can be very broad.
- Least privilege: prefer a well-managed group and the highest scope that is still narrow enough for the job. “Highest” does not mean “subscription” by default.
- Who can create it: the person or automation needs permission for
Microsoft.Authorization/roleAssignments/writeat the target scope. Common built-in ways to receive that permission include Owner or User Access Administrator; Contributor does not receive it by default.
Northwind example
Maya assigns the Reader role to Northwind-Auditors at one production resource group. Every member can see resources in that group and its children, but not modify them or see unrelated subscriptions. Assigning the same group at the subscription scope would widen access to all resource groups below it, so she avoids it unless that is the intended responsibility.
How it fits (diagram)
Exam notes
- Know the scope hierarchy and inheritance.
- A role assignment is not a login account, and it does not replace a Conditional Access policy.
Related
rbac · role-definition · scope · groups · service-principal
📘 Source: Microsoft Learn — Assign Azure roles using the Azure portal