2.1. Secure Access to Resources by Using Microsoft Entra ID

💡 First Principle: Every access decision Entra ID makes is really answering one question — "given everything I know about this identity right now, should this specific request go through?" — and each of the six mechanisms in this section is a different piece of evidence feeding that decision.

Get this section wrong in production and the consequences aren't hypothetical: standing admin access that should have expired, a Conditional Access gap that lets a risky sign-in through, an application with permissions nobody remembers granting. This is also the section most exam scenarios return to, because a networking or storage question can still hinge on "wait, what's actually authenticating this request?"

Mental model: think of Entra ID access as a funnel with six checkpoints — is this a standing or activated privilege (PIM), does this specific context pass policy (Conditional Access), was the credential itself strong enough (MFA/passwordless), is the calling application legitimate (app identity), did anyone actually consent to what it's asking for (OAuth consent), and if it's an Azure resource calling another Azure resource, does it even need a credential at all (managed identity)?

⚠️ Common Misconception: Conditional Access and MFA are not the same control. MFA is an authentication method; Conditional Access is the policy engine that decides when to demand it. You can have per-user MFA with no Conditional Access policies at all, and Conditional Access policies that never require MFA (they might require a compliant device instead). Exam scenarios that seem to be asking "which do I configure" are usually asking whether you understand this isn't an either/or choice.