2.5.8. 💡 First Principle: Azure Role-Based Access Control (RBAC)

First Principle: Azure RBAC is how Azure answers the question what is this identity allowed to do? Authentication (2.5.1, 2.5.2) proves who you are; RBAC decides what you may touch. Its core purpose is to grant each identity the least privilege that still lets it do its job.

What It Is: An authorization system built into Azure Resource Manager. Every permission you grant is a role assignment, and a role assignment is always the same three things joined together:

• Security principal — who: a user, a group, a service principal, or a managed identity.
• Role definition — what: a named collection of permitted actions. Azure ships built-in roles — Owner (full access, including granting access to others), Contributor (create and manage everything, but cannot grant access), Reader (view only), and User Access Administrator (manage access only) — and you can define custom roles.
• Scope — where: management group, subscription, resource group, or an individual resource.

Key Concepts:

• Permissions inherit downward. A role assigned at a subscription applies to every resource group and resource inside it. Assign at the narrowest scope that works.
• RBAC is additive, and deny is rare. A principal's effective permissions are the union of all its role assignments; there is no ordinary "deny" rule to subtract from that. (Deny assignments exist but are created by Azure itself, not hand-authored.)
• RBAC is not Azure Policy. RBAC governs who may act; Azure Policy governs what the resulting resource may look like (see 3.3.1). A Contributor is allowed to create a VM — Policy is what stops them creating one in an unapproved region.
• A resource lock outranks RBAC. Even an Owner cannot delete a resource carrying a CanNotDelete lock until the lock is removed (see 3.3.2).

Scenario: An auditor needs to inspect every resource in the production subscription but must not be able to change or delete anything. A platform engineer needs to build and manage resources in one project's resource group, but must not be able to hand access to anyone else.

Reflection Question: Which built-in role and which scope would you assign to each person? Why is Contributor — rather than Owner — the right answer for the engineer?

💡 Tip: The exam tests the shape of a role assignment (who / what / where) and the four common built-in roles. The distinction examiners return to most is Owner vs Contributor: both can manage resources, only Owner can grant other people access.