2.4. Reflection Checkpoint

Key Takeaways

• Entra ID access decisions combine six mechanisms — PIM, Conditional Access, authentication strength, application identity, consent, and managed identities — each answering a different piece of "should this request go through."
• PIM's eligible-vs-active distinction means role membership alone doesn't tell you who has standing access right now.
• Key Vault security rests on two independent gates (network firewall, permission model) plus a detection layer (Defender CSPM secret scanning, Defender for Key Vault) that catches what prevention missed.
• Governance layers RBAC (who can act), Azure Policy (what configurations are allowed regardless of who acts), and Defender for Cloud compliance tooling (how the whole environment measures against a named standard) — none of the three substitutes for the other two.
• Resource locks and backup MUA specifically defend against accidental or unilateral destructive actions by otherwise-authorized users, a different threat model than RBAC's unauthorized-access focus.

Connecting Forward

Phase 3 shifts from "who can access what" to "what can reach a resource over the network and how is the data inside it protected" — storage accounts, databases, and the network services that surround them. Several Phase 2 concepts return directly: managed identities authenticating to storage and databases, and private endpoints extending the same network-isolation pattern introduced for Key Vault in 2.2.2.

Self-Check Questions

• If you had to design an access review process to catch overprivileged accounts before an auditor does, which Phase 2 tools would you combine, and in what order would you check them?
• Why does a well-governed environment need both preventive controls (Policy with Deny effects) and detective controls (compliance dashboards, secure score) rather than relying on prevention alone?