Identity is where Azure Management & Governance quietly begins, and AZ-900 tests it as vocabulary, not architecture. You do not need to design a sign-in system — you need to know which service does what, and to keep two words apart: authentication and authorization. Get those straight and most identity questions answer themselves. The diagram above lays out the whole flow in one line, from a user to Azure resources.
The one service to anchor everything: Microsoft Entra ID
Microsoft Entra ID is Azure’s cloud identity and directory service — it stores your users and groups and handles their sign-in. It was formerly called Azure Active Directory, and the exam may still use that name; treat the two as identical. Entra ID is the front door: everything about proving who you are runs through it.
Authentication vs authorization
This is the single most useful distinction on the identity side.
- Authentication (AuthN) — proving who you are. The sign-in. Handled by Entra ID.
- Authorization (AuthZ) — deciding what you are allowed to do. Handled by RBAC.
The shortcut: AuthN = who, AuthZ = what. Every distractor that swaps these two is wrong.
| Term | What it does | One-line tell |
|---|
| Microsoft Entra ID | Cloud identity & directory service | ”stores users and groups, handles sign-in” |
| MFA | Second verification on top of the password | ”protects against a stolen password” |
| Conditional Access | Grant / block / challenge a sign-in by conditions | ”block by location, require MFA when risky” |
| SSO | One sign-in reaches many apps | ”sign in once, no re-entering credentials” |
| RBAC | Authorization: role + principal + scope | ”give this user this permission, here only” |
Multi-factor authentication (MFA) adds a second factor — a phone code or fingerprint — so a stolen password alone cannot get in. Conditional Access sits at the sign-in and decides, from signals like location and device risk, whether to allow, block, or demand MFA. Single sign-on (SSO) lets one authenticated session carry across many apps, shrinking the number of passwords in play.
RBAC: the authorization mechanism
Once Entra ID has confirmed who you are, role-based access control (RBAC) decides what you can touch. An RBAC assignment is always three things: a role (the permissions), a principal (the user, group, or app), and a scope (management group, subscription, resource group, or single resource). Grant a person the right role at the smallest scope that works — that is least privilege in practice, and it is where identity feeds directly into governance.
How this ties into governance
Identity is the who of governance. RBAC controls who may act; Azure Policy controls what any resource is allowed to be, regardless of who created it. The two are complementary, and the exam likes to test the seam — see the Azure Policy vs RBAC comparison for that. For the wider control plane — management groups, subscriptions, Cost Management, Azure Monitor — see the Management & Governance domain page, and the AZ-900 cheat sheet for the fast recap.
How to use the questions below
Answer each before revealing the explanation, and when you miss, read past the correct option to why each distractor fails — the wrong answers here are usually the right term for the wrong job (RBAC offered where MFA belongs, Conditional Access offered where RBAC belongs). Getting the reason right is what carries into the exam.
Updated for AZ-900 (July 2026). The sample questions above are our own work
in the style of the exam — not real exam items. The exam itself is set and marked
by the certification body.