What's changed: Deepened AZ-104 Chapter 1 to Associate depth (tables, scenarios, FAQ, traps; localized figures)
1.2Role-Based Access Control (RBAC)
Understand Azure RBAC role assignments (security principal + role definition + scope), built-in roles, inheritance through the scope hierarchy, and least privilege.
After authentication (who) comes authorization (what they may do). Azure RBAC (role-based access control) grants fine-grained permissions on resources.
1.2.1The three parts of a role assignment
- Security principal: who you grant to (user/group/app).
- Role definition: the set of allowed actions, e.g., Reader (read), Contributor (create/modify), Owner (full + manage access).
- Scope: where it applies—management group → subscription → resource group → resource; higher assignments inherit downward.
A common AZ-104 distinction: Reader = read, Contributor = create/modify (no access management), Owner = full + manage access. Higher scopes inherit more broadly.
Azure RBAC combines three parts: "who (principal) can do what (role definition) where (scope)." Key built-in roles: Reader (read only), Contributor (create/modify but cannot manage access = grant roles), Owner (full + manage access), and User Access Administrator (manage permissions only). Scope is the hierarchy management group → subscription → resource group → resource, and higher assignments inherit downward. Role definitions use allow (Actions) and deny (NotActions), and an explicit deny assignment overrides allows (typically used by Blueprints/managed apps). When built-ins don’t fit, create a custom role while keeping least privilege. RBAC governs Azure resource permissions, distinct from Entra ID directory roles (e.g., Global Administrator, which manage the tenant/identity). Use PIM to grant strong roles like Owner just-in-time with approval, reducing standing privilege. The axes: "read only = Reader," "create/modify = Contributor," "manage permissions too = Owner/User Access Administrator."
| Role | Can do |
|---|---|
| Reader | Read only |
| Contributor | Create/modify (cannot grant roles) |
| Owner | Full + manage access |
| User Access Administrator | Manage access only |
Scenario: let developers create resources but not grant permissions to others. Assign Contributor at the resource-group scope (create/modify yes, grant roles no). Give the access-management duty to a separate User Access Administrator. Keep Owners minimal and elevate just-in-time with PIM only when needed. Apply org-wide restrictions at the management group scope to inherit downward.
Q. Read only? Reader. Q. Create/modify but no granting? Contributor. Q. Full + manage access? Owner. Q. Manage permissions only? User Access Administrator. Q. Higher-scope assignment? Inherits downward. Q. Reduce standing privilege? Just-in-time elevation via PIM.
Watch the mix-ups: (1) Contributor cannot grant roles (manage access)—that’s Owner or User Access Administrator. (2) Azure RBAC (resource permissions) ≠ Entra directory roles (tenant/identity admin)—Global Administrator ≠ Owner. (3) Scope inherits, so an over-broad higher assignment over-grants (assign at the narrowest scope). (4) A deny assignment overrides allows.
First see if a built-in role meets the need; create a custom role only when none fits. Aim for least privilege.
1.2.2Section summary
- Role assignment = principal + role definition + scope
- Use Reader/Contributor/Owner; scope inherits downward
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. What three parts make up an Azure RBAC role assignment?
Q2. Which built-in role allows read-only access without modification?
Q3. How does a role assigned at the subscription scope affect underlying resource groups?