2.3.4. Azure RBAC: Built-in Roles, Custom Roles, and Overprivileged Access
💡 First Principle: Every RBAC role assignment is a standing bet that the assigned scope of access matches what the identity actually needs — and every bet that's wider than necessary is unused attack surface waiting for that identity's credentials to be compromised.
Azure ships built-in roles (Owner, Contributor, Reader, User Access Administrator, and hundreds of resource-specific roles) covering most common needs; when none fit precisely, you can define custom roles with a specific, narrower set of permitted actions. The same layered thinking applies to Microsoft Entra roles (Global Administrator, User Administrator, and similar), which govern directory-level actions and are a separate role system from Azure resource RBAC — a user can be a Global Administrator with no Azure resource permissions at all, and vice versa.
| Role | Can Manage Resources? | Can Assign Roles to Others? |
|---|---|---|
| Owner | Yes | Yes |
| Contributor | Yes | No |
| User Access Administrator | No (resource management) | Yes |
| Reader | View only | No |
Evaluating and remediating overprivileged access assignments — accounts holding more permission than their activity justifies — is an explicit, ongoing exam skill, not a one-time setup task. Microsoft Entra tooling like Access Reviews and PIM's usage insights are commonly used to surface these.
⚠️ Exam Trap: Contributor is a broad role, but it explicitly cannot assign roles to other users — that permission is scoped to Owner and User Access Administrator specifically. A scenario where "a Contributor granted another user access" describes something that shouldn't be possible under correctly-configured RBAC, and the exam expects you to recognize the anomaly.
Reflection Question: A team lead has Contributor access to a resource group and asks why they can't grant a new team member access to it. What role would you recommend adding, and why not just upgrade them to Owner?
