AZ-500 Secure Identity and Access: The Four Phases of an Azure Identity
The Secure Identity and Access domain is the heaviest single area on the Microsoft AZ-500 exam — Microsoft's published study guide weights it at twenty-five to thirty percent of the question pool, tying it with security operations and beating both networking and compute-storage. It also has the largest sub-surface area: Entra ID (the service formerly called Azure AD) is functionally a small operating system for identities, and AZ-500 expects you to know how every layer of it fits together. The candidates who pass this domain don't memorise features in alphabetical order. They follow an identity through four phases — provisioning, authentication, authorization, monitoring — and discover that every Microsoft tool the exam tests lands in exactly one of them. This guide walks the four phases with the exam questions in mind.
A quick naming note
Microsoft renamed Azure Active Directory to Microsoft Entra ID in mid-2023. The renaming applies across the documentation, the portal, and the SDKs, but a lot of practice questions and older study material still use the old name. On exam day you will see both. Treat "Azure AD" and "Entra ID" as synonyms; the underlying service, the Graph API, and the questions are identical regardless of which label is used. The same naming pattern applies to Azure AD Connect, which is now Microsoft Entra Connect, and to Azure AD PIM, which is now Microsoft Entra Privileged Identity Management.
Phase 1: Provisioning — how identities enter the tenant
Every Entra ID identity comes from somewhere, and the source determines which controls apply. There are six distinct provisioning paths worth knowing cold.
Cloud-only users are created directly in Entra ID via the portal, Graph API, or PowerShell. They have no on-premise counterpart and exist purely in the cloud directory. Default behaviour applies to these without configuration.
Hybrid identities come from on-premise Active Directory via Entra Connect (the renamed Azure AD Connect). The exam tests three sync methods that determine where authentication happens. Password hash sync (PHS) hashes the on-prem password and stores the hash in Entra ID so the cloud authenticates the user directly. Pass-through authentication (PTA) keeps the password on-prem and validates each sign-in via a connector against the on-prem AD. Federation (AD FS) forwards authentication entirely to the on-prem identity provider. Know the tradeoff: PHS is simplest and gives you cloud resilience if on-prem goes down; PTA keeps passwords on-prem at the cost of needing the connector available; federation gives the most control but the highest operational complexity.
B2B (business-to-business) guest users are identities from other Entra tenants that you invite into yours. They authenticate in their home tenant; you authorise them in yours. Useful for partner collaboration. Microsoft's cross-tenant access settings and B2B collaboration policies govern what guests can see.
B2C is a separate tenant type entirely — built for customer-facing applications where end-users sign up, often via social identity providers (Google, Facebook). B2C does not share a directory with your workforce Entra tenant. Exam tip: if a question describes consumer-facing identity, the answer involves a B2C tenant, not a configuration tweak in the corporate tenant.
App registrations represent applications that need to authenticate to Entra ID — typically to call Microsoft Graph or another protected API. Each app registration creates a corresponding service principal in your tenant. The app registration is the global definition; the service principal is the instance of that app inside your tenant.
Managed identities are service principals that Azure manages for you, eliminating the need to store credentials. System-assigned managed identities are tied to a single Azure resource and are deleted when that resource is. User-assigned managed identities are standalone resources that can be assigned to multiple Azure resources and outlive any one of them. When a question is about a virtual machine or function calling Key Vault without a stored secret, the answer is almost always a managed identity.
Phase 2: Authentication — proving who they are
Once the identity exists, authentication is the act of proving control over it. AZ-500 tests four layers of authentication, and the layer mostly determines the right tool for any question.
Authentication methods are the credentials a user can present. Passwords are the default; MFA adds a second factor (Authenticator app, SMS, voice call, OATH hardware token, FIDO2 security key). The modern Microsoft direction is passwordless — Windows Hello for Business, the Authenticator app phone sign-in, and FIDO2 keys all qualify as passwordless. Know which methods are passwordless because the exam tests the distinction (the Authenticator app push notification is MFA when paired with a password, passwordless when used as phone sign-in alone).
Multi-factor authentication policies control when the second factor is required. The legacy approach (per-user MFA, configured under user properties) is being phased out in favour of Conditional Access. For new tenants, MFA is enforced via the security defaults toggle (on by default) or via a Conditional Access policy. The exam strongly prefers Conditional Access answers over per-user MFA answers; if both look valid, pick Conditional Access.
Conditional Access is the decision engine that sits between an authentication attempt and access to a resource. Each policy has a signal set (which users, which apps, which platforms, which locations, which device states, which risk level) and a control set (grant access, block access, require MFA, require compliant device, require Hybrid Azure AD join, require approved client app). The exam tests scenarios like "only allow access from compliant devices," "block sign-in from outside named countries," or "force re-authentication every eight hours" — every one of these maps to a Conditional Access policy, never to a user-level setting.
Identity Protection sits parallel to Conditional Access and contributes a signal: the risk level of the user or the sign-in. A risky sign-in is one Microsoft's detection engine considers suspicious (impossible travel, anonymous IP, malware-linked IP, leaked credentials). A risky user is one accumulating risky sign-ins. Conditional Access can then reference user-risk and sign-in-risk as signals to block, force MFA, or force password change. Identity Protection requires Entra ID P2 — that licensing detail comes up on the exam.
Phase 3: Authorization — what they can do once in
Authentication proves who. Authorization decides what. AZ-500 tests two distinct authorization systems that candidates routinely conflate.
Azure roles (Azure RBAC) control access to Azure resources — virtual machines, storage accounts, key vaults, resource groups, subscriptions. Built-in roles include Owner, Contributor, Reader, and dozens of resource-specific roles (Virtual Machine Contributor, Storage Blob Data Reader, Key Vault Administrator). A role assignment has three parts: the principal (who), the role (what), and the scope (where). Scope inherits downward — assign at the subscription level and every resource group and resource inherits it.
Entra roles (directory roles) control access to the directory itself — managing users, groups, applications, and Entra-specific settings. Built-in roles include Global Administrator, User Administrator, Application Administrator, Security Administrator. These are entirely separate from Azure roles: a Global Administrator does not automatically have Azure resource access (and conversely, an Azure Owner is not an Entra admin). Exam questions that mention "manage user accounts" point at an Entra role; questions that mention "manage a virtual machine" point at an Azure role.
Privileged Identity Management (PIM) overlays both role systems with just-in-time activation. Instead of being permanently assigned to the Global Administrator role, you are made eligible, and you must explicitly activate when you need it — with optional approval and time-bound expiration. PIM also surfaces alerts ("role assigned outside of PIM," "too many global admins") and runs access reviews. Whenever an exam scenario asks how to provide elevated access without making it permanent, PIM is the answer.
Group-based access (assigning a role to a security group rather than to individual users) is the management-at-scale answer for both Entra and Azure roles. Dynamic groups let membership be driven by user attributes (department, location, role). The exam often presents a scenario about an organisation with hundreds of users and asks how to manage access efficiently — group-based assignment is the answer, dynamic groups when the population changes frequently.
Phase 4: Monitoring — what happens after sign-in
Logging in and being authorised is half the story. The other half is detecting when something goes wrong, and AZ-500 expects you to know the three monitoring surfaces that come together to provide that.
Sign-in and audit logs in Entra ID record every authentication and every directory change. Sign-in logs include the user, application, IP, location, conditional access policy outcome, and risk score. Audit logs include who changed what in the directory. These can be exported to a Log Analytics workspace, a storage account, or an event hub — the exam regularly tests the export configuration because it's the foundation of any longer-term monitoring story.
Identity Protection appears again here, now in its monitoring role. It surfaces risky users and risky sign-ins as discrete reports, lets you investigate and remediate (confirm compromised, dismiss as false positive, reset password), and runs policies that act automatically on risk. When the question describes "detect compromised accounts" or "force MFA on suspicious sign-ins," the answer is Identity Protection.
Access reviews close the loop by ensuring assigned roles, group memberships, and guest accesses stay appropriate over time. Reviews can run on a schedule, target specific groups or roles, and be completed by reviewers (the user themselves, their manager, or a designated reviewer). When the question is about recertification or about cleaning up stale guest access, the answer is access reviews.
The exam-day pattern
Almost every question in this domain is task-based: "you need to ensure X — which of the following should you do?" Recognise the phase first, the tool falls out. "Ensure only compliant devices can access Microsoft 365" — phase two, Conditional Access. "Grant a developer temporary owner access on a resource group with approval" — phase three, Azure RBAC via PIM. "Detect when accounts are being used from impossible-travel locations" — phase four, Identity Protection. "Allow guest users from a partner organisation" — phase one, B2B collaboration. "Recertify group membership annually" — phase four, access reviews. Once the phase classification is fast, the tool selection becomes mechanical, and what looks like a memorisation challenge becomes pattern matching.
What to drill this week
Reading the four-phase model is the orientation; the marks come from running it on real questions until the phase classification is reflexive. Open the Secure Identity and Access domain page on IT Exam Certs, run a focused twenty-question set, and for every question name the phase (one through four) and the tool before you look at the answer choices. The questions you stall on are the phases to drill next. Pair the drill with the rest of the AZ-500 cert page, and the heaviest domain on the exam stops being the one you fear and becomes the one you bank marks on.
Photos from Pexels: cover (vintage keys) by Meruyert Gonullu, passports by Kenneth Surillo, hierarchy by Ann H, surveillance cameras by Scott Webb.