Who you are (directory services, authentication) versus what you're allowed to do (RBAC) versus whether you're even let in right now (Conditional Access) — three related but genuinely distinct ideas the exam expects you to tell apart.
Your org wants two things: (1) engineers get read/write access to VMs in the "Production" resource group, but only read access everywhere else; (2) anyone signing in from an unfamiliar location gets challenged with an extra MFA prompt, automatically, without editing anyone's individual permissions. Which Azure feature handles case 1, and which handles case 2?
Microsoft Entra ID is Azure's cloud-based identity and access management service — it's what verifies who you are (authentication), lets one identity reach multiple apps (SSO), and manages devices and app access. It's not the same thing as classic on-premises Active Directory, though Microsoft Entra Connect can sync identities between the two so users get a consistent experience either way.
Microsoft Entra Domain Services is different: a managed version of classic domain services — domain join, group policy, LDAP, Kerberos/NTLM — for legacy apps that can't use modern authentication, without you having to deploy or maintain your own domain controllers.
| Method | What it is |
|---|---|
| SSO | Sign in once, access multiple trusted apps — only as secure as that first sign-in |
| MFA | A second factor beyond password: something you know, something you have, something you are |
| Passwordless | No password at all — a trusted device plus a biometric or PIN. Rated highest on both security and convenience |
Three passwordless options: Windows Hello for Business (biometric/PIN tied to one specific Windows PC), the Microsoft Authenticator app (turns a phone into the sign-in factor via a number-match + biometric), and FIDO2 security keys (a physical, unphishable USB/NFC/Bluetooth device).
For collaborating with people outside your own tenant — partners, vendors, customers:
| Capability | Shows up in your directory? | Used for |
|---|---|---|
| B2B collaboration | Yes — as a guest user | Inviting an external partner to sign in with their own existing credentials |
| B2B direct connect | No | Mutual trust between two Entra tenants — currently used for Teams shared channels |
| External ID for customers (formerly B2C) | Separate consumer tenant | Publishing a SaaS/custom app to external consumers |
Conditional Access is a signal → decision → enforcement pipeline that runs at sign-in. It looks at signals (who, where, what device, which app), decides based on policy, and enforces the result — allow, block, or require MFA. Typical uses: require MFA only for privileged roles or unusual locations, require sign-in from managed devices, restrict which client apps can connect, block untrusted locations entirely.
Role-based access control governs the principle of least privilege: grant only the access needed, no more. It has three moving parts — a role (a bundle of permissions, built-in or custom), a scope (what it applies to), and a role assignment (linking a person/group to a role at a scope).
The scope hierarchy is exactly the one from Lesson 4: management group → subscription → resource group → resource. Grant a role at a parent scope, and it inherits down to every child scope beneath it — same inheritance behavior you saw with management group policies. RBAC is enforced by Azure Resource Manager on any action against an Azure resource — it does not reach inside an application or its data; that's on the app itself.
RBAC answers "once you're in, what are you allowed to do?" — authorization, scoped to resources, an allow-model that inherits downward.
Conditional Access answers "should you be let in right now, under these conditions?" — a sign-in-time gate based on live signals like location and device, independent of what permissions you'd have once inside.
Calibration answer: case 1 (scoped read/write on Production, read-only elsewhere) is Azure RBAC — a role assignment at the resource-group scope. Case 2 (auto-challenge on unfamiliar location) is Conditional Access — a signal-based sign-in policy, no permission changes involved.