Entra ID — RBAC, managed identities, PIM and Conditional Access

Azure’s identity and access management system is built on Microsoft Entra ID (formerly Azure Active Directory), which provides both cloud identity for users and service principals and federated identity for Azure workloads through managed identities. In Azure, identity and access management is not a separate security layer bolted on after infrastructure design; it is the primary access control mechanism for every Azure resource, replacing network-level controls as the first line of defence in a Zero Trust architecture.

Azure Role-Based Access Control (RBAC) governs all operations against Azure resources by evaluating whether the requesting identity has a role assignment that permits the action on the targeted resource scope. Every Azure resource operation — read a secret from Key Vault, deploy a Virtual Machine, query a Log Analytics Workspace — is an RBAC-protected action. Understanding the role assignment model, the built-in roles, and the custom role definition structure is the prerequisite for any Azure security design.

Privileged Identity Management (PIM) and Conditional Access extend the baseline RBAC model with just-in-time access elevation and context-aware authentication policy. PIM enables engineers to hold eligible role assignments that are inactive by default and require explicit activation for a bounded time window with justification, reducing the standing privileged access footprint that represents the highest-risk attack surface. Conditional Access policies enforce authentication requirements — MFA, compliant device, specific location — before granting access to applications and resources.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.