Role-Based Access Control (RBAC)
What it is
RBAC is Azure’s authorization model: it controls what an identity may do to a resource. It answers “can this user stop this VM / read this storage account / create a resource here?”
Why it exists
To enforce the least-privilege principle at scale: give each user/service exactly the permissions they need, no more, and manage that centrally rather than per-resource.
The three pieces (memorize!)
- Security principal — who (a user, group, service principal, or managed identity).
- Role definition — what they may do (a set of permissions; e.g.
Reader,Contributor,Owner,Storage Blob Data Reader). - Scope — where it applies (management group → subscription → resource group → resource). Permissions are inherited down the scope hierarchy.
security principal + role + scope = assignment
Identity vs RBAC
- Entra ID = authentication (who you are).
- RBAC = authorization (what you can do). RBAC does not authenticate; it authorizes after identity is known.
Key exam facts
- Owner > Contributor > Reader, plus classic User Access Administrator.
- Assign roles to groups, not individual users, for easy management.
- Custom roles can be defined when built-in roles don’t fit.
- Scope precedence: deny at a parent does NOT override allow at a child unless a Deny assignment exists. (More specific/efficient assignments win; see docs on the exact rules.)
- RBAC is allow-by-default within assignment — a user with no assignment has no access (except subscription-level Owner).
Diagram
Diagrams courtesy of Microsoft Learn / Azure docs: role-based-access-control/overview
Related
entraid · role-definition · role-assignment · scope · subscription · resource-group
📘 Source: Microsoft Learn — Rbac