1.3.2. Authorization: Deciding What You Can Do
💡 First Principle: Once identity is proven, access should be granted by role, not by individual — you define what a job function may do once, then attach principals to it. That's role-based access control (RBAC), and it exists because per-person permission lists rot: people change jobs, permissions accumulate, and nobody remembers why Alice can delete mailboxes.
Two RBAC systems share the stage in Microsoft's cloud, and telling them apart is a reliable exam discriminator. Microsoft Entra roles govern the directory — creating users, resetting passwords, managing apps and policies (User Administrator, Application Administrator, Global Administrator). Azure RBAC roles govern resources — VMs, storage, key vaults (Owner, Contributor, Reader) — scoped to management groups, subscriptions, or resource groups. They are separate hierarchies: a Global Administrator has no Azure resource access by default (there's a deliberate, audited "elevate access" escape hatch for emergencies).
Every authorization grant has three parts: a principal (who), a role definition (a bundle of permissions — the what), and a scope (where it applies). Least privilege means minimizing all three — the narrowest role, at the narrowest scope, for the fewest principals, ideally for a limited time. That last refinement — time — is what Privileged Identity Management adds in Phase 5: standing permissions become eligible ones you activate only when needed.
Applications are authorized the same way but with their own vocabulary: scopes and app roles define what an app may do against an API, granted through consent. Same triad — principal, permissions, boundary — different wardrobe. Recognize the pattern and Phase 4's consent model will feel familiar rather than new.
⚠️ Exam Trap: When a scenario says a user "cannot manage user accounts in the Azure subscription's virtual machines" versus "cannot create users in the directory," it's steering you between Azure RBAC and Entra roles. Match the verb's target — resources vs. directory — before picking a role.
Reflection Question: Your helpdesk needs to reset passwords for non-admin users only. Walk the triad: which principal set, which role, and — thinking ahead — what scoping construct could limit them to a single department?
