Most people arrive at the AZ-900 comfortable with the idea of virtual machines and storage accounts, then freeze on a question like: “A company wants to require a second verification step only when users sign in from an unfamiliar location. Which capability provides this?” That is not a compute or storage question — it is an identity, access, and security question, and it is one of the areas the exam tests most consistently. The good news is that this domain rewards understanding a handful of concepts and how they relate, not memorising screens.
This guide walks the whole identity-and-access story the way the AZ-900 frames it: what authentication and authorization actually mean, what Microsoft Entra ID is and how it differs from the on-premises Active Directory you may already know, how Azure verifies who you are (MFA, passwordless, SSO), how it decides when to challenge you (Conditional Access), how it controls what you can do (Azure RBAC), and the two big security models the exam name-drops — Zero Trust and defence in depth. Everything here is fundamentals-level: what each concept is and when it applies, not how to administer it. (The hands-on administration of Entra ID is AZ-104 territory, and we’ll point you there at the end.)
Authentication vs Authorization: The Distinction the Exam Loves
Before any service, get these two words straight, because a surprising number of AZ-900 questions hinge on them.
- Authentication (AuthN) answers “Who are you?” It is the act of proving your identity — entering a password, approving a phone prompt, scanning a fingerprint.
- Authorization (AuthZ) answers “What are you allowed to do?” It happens after authentication and decides which resources and actions your verified identity may access.
| Term | Question it answers | Azure example |
|---|---|---|
| Authentication | Who are you? | Signing in to the Azure portal with MFA |
| Authorization | What can you do? | Azure RBAC letting you read but not delete a resource group |
A clean way to remember it: you authenticate once to prove identity, then you are authorized many times as you try to touch different resources. If a scenario is about proving identity, it’s authentication (Entra ID, MFA). If it’s about permissions on a resource, it’s authorization (RBAC).
Microsoft Entra ID: Azure’s Cloud Identity Service
Microsoft Entra ID (formerly Azure Active Directory, or Azure AD) is Microsoft’s cloud-based identity and access management service. It is the directory that holds your organisation’s identities and controls how they sign in to Microsoft 365, the Azure portal, and thousands of SaaS applications. If your study notes still say “Azure AD,” they’re using the retired name — the exam uses Microsoft Entra ID.
Entra ID manages several kinds of identity:
- Users — people in your organisation (and guest users invited from outside via B2B).
- Groups — collections of users you assign access to together, so you manage permissions once instead of per person.
- Service principals and app registrations — identities for applications, not humans.
- Managed identities — identities Azure automatically manages for a resource (like a VM or Function) so it can call other Azure services without a password stored in code.
- Devices — registered or joined devices that Conditional Access can reason about.
Entra ID Is Not the Same as On-Premises Active Directory
This is the single most tested distinction in the topic. Traditional Active Directory Domain Services (AD DS) — the thing running on a domain controller in a server room — is not the same as Entra ID.
| On-premises Active Directory (AD DS) | Microsoft Entra ID | |
|---|---|---|
| Where it runs | Your servers (domain controllers) | Microsoft’s cloud, delivered as a service |
| Protocols | Kerberos, LDAP, NTLM | HTTP/HTTPS-based: SAML, OAuth 2.0, OpenID Connect |
| Structure | Organisational Units, forests, domains, group policy | Flat directory of users, groups, tenants |
| Designed for | On-prem file servers, domain-joined PCs, GPO | Cloud and web/SaaS apps, mobile, SSO |
| Managed by you? | Yes — you patch and run the DCs | No — Microsoft runs the platform |
The exam cue: if the scenario is about web and cloud applications, SSO, and identities delivered as a service, that’s Entra ID. If it’s about Kerberos, group policy, and domain-joined on-prem servers, that’s on-premises AD.
Two related terms worth recognising:
- Microsoft Entra Domain Services (Entra DS) provides managed domain services in the cloud — things like domain join, group policy, and Kerberos/LDAP — for legacy apps that need traditional AD features but that you’d rather not run domain controllers for.
- Hybrid identity connects your on-prem AD to Entra ID (using Microsoft Entra Connect) so users have one identity across both worlds. The recognition point for AZ-900 is simply that hybrid identity lets on-prem and cloud coexist with a single sign-in.
Authentication Methods: Passwords, MFA, and Passwordless
Once you have identities in Entra ID, the next question is how users prove who they are.
Multi-Factor Authentication (MFA)
Multi-factor authentication requires two or more independent categories of evidence before granting access. The three classic categories are:
| Factor | ”Something you…” | Examples |
|---|---|---|
| Knowledge | know | Password, PIN |
| Possession | have | Phone with Authenticator app, hardware token, FIDO2 key |
| Inherence | are | Fingerprint, face scan |
The point of MFA is resilience: even if an attacker steals a password (knowledge), they still lack the phone (possession) or the fingerprint (inherence). MFA is one of the highest-value security controls Microsoft recommends, and the exam treats it as the default answer whenever a scenario says “add a second layer of verification” or “protect against stolen passwords.”
Passwordless Authentication
Passwordless sign-in removes the password entirely, replacing “something you know” with a stronger combination of possession and inherence. Azure supports passwordless methods such as:
- Windows Hello for Business — face or fingerprint on your device.
- Microsoft Authenticator app — approve a notification with biometrics.
- FIDO2 security keys — a physical key you tap.
Passwordless is more secure and often more convenient because there’s no password to phish, guess, or reuse. If a scenario stresses “eliminate passwords” or “reduce phishing risk,” passwordless is the answer.
Self-Service Password Reset (SSPR)
Self-service password reset lets users reset their own passwords (after verifying identity with a second method) without calling the help desk. The exam cue is “reduce help-desk tickets” or “let users unlock themselves.”
Single Sign-On (SSO)
Single sign-on lets a user authenticate once and then access many applications without signing in again to each one. Instead of separate credentials for email, HR, the expense tool, and a dozen SaaS apps, the user signs in to Entra ID and rides that session across everything federated to it.
SSO improves both security and usability: fewer passwords means fewer weak or reused passwords, fewer reset requests, and a smaller attack surface — and when someone leaves, disabling one identity revokes access everywhere. The exam cue is any scenario about “one sign-in for multiple applications.”
Conditional Access: Deciding When to Challenge
MFA answers how to verify; Conditional Access answers when. It is a policy engine in Entra ID that evaluates signals about each sign-in and then makes a decision to allow, block, or require extra controls.
Think of it as if-then rules:
- Signals (the “if”) — who the user is, the group they’re in, the device state, the app being accessed, the location or IP, and the calculated sign-in risk.
- Decision and controls (the “then”) — grant access, block access, require MFA, require a compliant/managed device, or force a password change.
Concrete examples the exam likes:
- “Require MFA only when users sign in from outside the corporate network.”
- “Block access to the finance app from countries where we don’t operate.”
- “Require a managed, compliant device to open email.”
The key idea for AZ-900: Conditional Access applies the right level of friction based on context, so trusted, low-risk sign-ins stay smooth while risky ones get challenged or blocked. If the question involves conditions on a sign-in (location, device, risk) driving a requirement (like MFA), the answer is Conditional Access.
Azure Role-Based Access Control (RBAC): Deciding What You Can Do
Authentication proves identity; Azure RBAC handles authorization — what a verified identity is allowed to do on Azure resources. RBAC follows the principle of least privilege: give each identity only the permissions it needs, no more.
An RBAC role assignment has three parts:
| Part | Meaning | Example |
|---|---|---|
| Security principal | Who gets access | A user, group, service principal, or managed identity |
| Role definition | What they can do | A collection of permissions (a role) |
| Scope | Where it applies | The level the role is granted at |
Scope is the concept the exam probes most, because RBAC permissions inherit downward through the Azure hierarchy:
Management group (many subscriptions)
└── Subscription
└── Resource group
└── Resource (a single VM, storage account, etc.)Assign a role at a higher scope and it flows down to everything beneath it. Grant Reader at the subscription and the user can read every resource group and resource in it; grant Contributor on a single resource group and they can manage only that group’s resources. Least privilege usually means assigning roles at the narrowest scope that still gets the job done.
A few built-in roles to recognise:
| Role | What it grants |
|---|---|
| Owner | Full access, including managing others’ access |
| Contributor | Create and manage resources, but cannot grant access to others |
| Reader | View resources only — no changes |
| User Access Administrator | Manage user access to resources (assign roles) |
The classic AZ-900 trap is the difference between Owner and Contributor: both can manage resources, but only Owner (and User Access Administrator) can hand out access to others. If a scenario wants someone to build resources without being able to grant permissions, that’s Contributor.
Azure RBAC Roles vs Microsoft Entra ID Roles
Another commonly confused pair. They govern different things:
| Azure RBAC roles | Entra ID (directory) roles | |
|---|---|---|
| Control access to | Azure resources (VMs, storage, networks) | Entra ID and identity features (users, groups, Conditional Access) |
| Examples | Owner, Contributor, Reader | Global Administrator, User Administrator |
| Scope | Management group → resource | The Entra tenant |
Rule of thumb: managing a resource (a VM, a storage account) → Azure RBAC. Managing identities and the directory itself (creating users, assigning Global Admin) → Entra roles. Note that RBAC governs access; enforcing organisational rules on resources (like “no public IPs”) is the job of Azure Policy, and preventing accidental changes is the job of resource locks — both part of Azure’s broader governance story rather than RBAC itself.
Zero Trust and Defence in Depth: The Security Models
The exam expects you to recognise two conceptual security models by name.
Zero Trust
Zero Trust replaces the old “trust everything inside the network wall” mindset with “never trust, always verify.” Its three guiding principles:
- Verify explicitly — always authenticate and authorise based on all available signals (identity, device, location, risk). This is exactly what MFA and Conditional Access implement.
- Use least-privilege access — grant just-enough, just-in-time access (RBAC and least privilege).
- Assume breach — design as though an attacker is already inside: segment access, encrypt, and monitor continuously.
Zero Trust ties the whole domain together: MFA + Conditional Access = verify explicitly, RBAC = least privilege, and monitoring/segmentation = assume breach.
Defence in Depth
Defence in depth layers multiple, independent security controls so that if one fails, others still protect the asset. Microsoft describes it as concentric rings around data:
| Layer | Example control |
|---|---|
| Physical | Datacentre access controls (Microsoft’s responsibility) |
| Identity & access | Entra ID, MFA, Conditional Access |
| Perimeter | DDoS protection, firewalls |
| Network | Network segmentation, network security groups |
| Compute | Endpoint protection, patching |
| Application | Secure development, secrets management |
| Data | Encryption at rest and in transit |
The exam cue for defence in depth is any mention of “multiple layers” or “if one control is bypassed, another still protects the data.” Note that identity is now the primary security perimeter in the cloud — which is exactly why this whole domain matters so much.
Putting It Together: Scenario-to-Concept Decision Table
Under exam pressure, match the strongest signal in the question to the right concept:
| The scenario says… | The answer is… |
|---|---|
| ”Prove who a user is” | Authentication (Entra ID) |
| “Control what a user can do to a resource” | Authorization (Azure RBAC) |
| “Add a second verification step” | Multi-factor authentication (MFA) |
| “Eliminate passwords / reduce phishing” | Passwordless |
| ”Sign in once, access many apps” | Single sign-on (SSO) |
| “Require MFA only from unfamiliar locations/devices” | Conditional Access |
| ”Give read-only access to a subscription” | RBAC — Reader role at subscription scope |
| ”Manage resources but not grant others access” | RBAC — Contributor |
| ”Cloud identity service for web/SaaS apps” | Microsoft Entra ID |
| ”Kerberos, group policy, domain-joined servers” | On-premises Active Directory |
| ”Never trust, always verify” | Zero Trust |
| ”Multiple layers, each a backstop” | Defence in depth |
Common AZ-900 Identity Mistakes
| Mistake | The correction |
|---|---|
| Calling it “Azure AD” | The exam uses Microsoft Entra ID |
| Thinking Entra ID = on-prem AD | Different protocols and purpose — cloud identity vs domain services |
| Confusing authentication with authorization | AuthN proves identity; AuthZ grants permissions |
| Assuming Contributor can grant access | Only Owner and User Access Administrator can |
| Mixing up Azure RBAC roles and Entra roles | RBAC = resources; Entra roles = the directory |
| Treating MFA and Conditional Access as the same | MFA is how to verify; Conditional Access decides when |
Where This Fits in Your AZ-900 Prep
Identity, access, and security is one of the highest-leverage areas on the AZ-900 precisely because it spans the whole exam — the concepts here reappear inside architecture, governance, and compliance questions. Understanding why MFA, Conditional Access, and RBAC exist (and how Zero Trust ties them together) turns a dozen memorised terms into one coherent mental model.
That model becomes reflexive through timed, scenario-based practice. Sailor.sh’s AZ-900: Azure Fundamentals Mock Exam Bundle gives you full-length mock exams that mirror the real exam’s format and passing bar, with a detailed explanation on every question — so an identity question you miss becomes a lesson you keep. Use the free concepts here to build the model; use timed exams to make the scenario-to-concept mapping automatic.
To round out the “Azure architecture and services” side of the exam, pair this with the sibling guides on Azure Compute for AZ-900 and Azure Storage for AZ-900. Start with the AZ-900 exam guide for 2026 for logistics and the full blueprint, follow the 30-day AZ-900 study plan to schedule your prep, and if you’re still deciding, read is the AZ-900 worth it in 2026. When you’re ready to administer Entra ID hands-on — creating users, configuring Conditional Access policies, and assigning roles for real — the AZ-104 exam guide is the natural next step.
Frequently Asked Questions
Is Microsoft Entra ID the same as Azure Active Directory?
Yes — Microsoft Entra ID is the current name for the service formerly called Azure Active Directory (Azure AD). It’s the same cloud identity and access management service; only the name changed. The AZ-900 exam uses the Entra ID name, so update any older notes.
What is the difference between authentication and authorization?
Authentication proves who you are (signing in, MFA). Authorization determines what you’re allowed to do once your identity is verified (Azure RBAC permissions on a resource). Authentication always comes first.
What is the difference between MFA and Conditional Access?
MFA is a method — requiring a second factor beyond the password. Conditional Access is a policy engine that decides when to require MFA (or block access) based on signals like location, device, and risk. Conditional Access commonly enforces MFA under specific conditions.
What is the difference between Azure RBAC roles and Entra ID roles?
Azure RBAC roles (Owner, Contributor, Reader) control access to Azure resources like VMs and storage accounts. Entra ID roles (Global Administrator, User Administrator) control access to Entra ID itself — managing users, groups, and identity settings. Use RBAC for resources and Entra roles for the directory.
What is Zero Trust in simple terms?
Zero Trust means “never trust, always verify.” Instead of trusting anything inside the network, every access request is authenticated and authorised using all available signals, granted with least privilege, and monitored as if a breach has already happened. In Azure, MFA, Conditional Access, and RBAC are the practical building blocks of a Zero Trust approach.
Which built-in role lets someone manage resources but not grant access to others?
Contributor. It can create and manage resources but cannot assign roles to other users. Only Owner and User Access Administrator can grant access to others — a distinction the AZ-900 tests directly.