Azure Identity, Access & Security: AZ-900 Guide

In the cloud, identity is the starting point of security: with no office walls to keep intruders out, what protects resources is knowing who is asking and what they are allowed to do. Two words run through this whole topic.

• Authentication answers "who are you?" and proves it, for example with a password plus a phone prompt. SSO, MFA and passwordless sign-in are authentication methods, and Microsoft Entra ID is the service that performs them.
• Authorization answers "what are you allowed to do?" once your identity is known, for example whether you may read a storage account or delete a virtual machine. In Azure, that decision is made by Azure RBAC.

Two neighbouring ideas are often confused with these. Conditional Access sits between them: it runs at sign-in, after the user's first factor has been checked, and decides whether the sign-in may go ahead (allow it, block it, or require something extra first, such as MFA or a compliant device). It does not decide which resources a user may change. Auditing is different again: logs such as the Azure Activity log record what someone did after the fact, but recording an action never permits or prevents it.

Microsoft Entra ID is Azure's cloud-based identity and directory service, the service formerly known as Azure Active Directory (Azure AD). It stores your organization's users and groups and verifies sign-ins so people and applications can reach Azure, Microsoft 365 and thousands of SaaS apps. A cloud-only organization with no on-premises servers simply creates its accounts in Microsoft Entra ID; it is also where you turn on SSO, MFA and Conditional Access. (Organizations that already run Windows Server Active Directory on-premises use Microsoft Entra Connect to synchronize those existing accounts into Microsoft Entra ID; Connect is a sync tool, not a directory of its own.)

Microsoft Entra Domain Services is a managed domain service. It provides traditional Windows Server domain features (domain join, Group Policy, and the older Kerberos and NTLM authentication protocols, plus LDAP) for applications that expect a classic domain but are moving to Azure. Microsoft Entra ID on its own does not offer these: it uses modern web sign-in protocols, so it cannot join a server to a traditional Windows Server domain or apply Group Policy to it. Domain Services fills that gap using the users and groups already in Microsoft Entra ID.

The alternative is to build your own Active Directory Domain Services (AD DS) domain controllers on Azure VMs. That gives the same domain features, but you deploy, patch, back up and monitor those VMs yourself. Domain Services is the managed option: Microsoft runs the domain controllers for you.

Authentication is how a user proves they are who they claim to be. Azure supports three methods that the exam expects you to tell apart.

Single sign-on (SSO) lets a user sign in once and then reach many applications without signing in again. Each person has one identity used by every connected app, which helps security as well as convenience: people juggle fewer passwords, and when someone leaves, disabling that one account removes their access to every app connected to it.

Multifactor authentication (MFA) requires evidence from two or more different categories: something you know (a password or PIN), something you have (a phone, hardware token or security key), or something you are (a fingerprint or face). A password plus a code from a hardware token combines know + have. Two items from the same category (two passwords) is not MFA. Where you sign in from is not an MFA factor: location is a signal that Conditional Access can use to decide whether to ask for MFA (see the next section). Because a stolen password alone no longer works, MFA is one of the simplest strong protections available.

Passwordless authentication removes the password entirely. Microsoft Entra ID supports Windows Hello for Business, FIDO2 security keys and the Microsoft Authenticator app. Each still combines two factor categories, a device you have unlocked by a PIN you know or a biometric you are, so it is strong authentication with no password for an attacker to phish or steal. That is what sets it apart from MFA added on top of a password, where the password is still there to be stolen, and from SSO, which reduces how often you sign in but not how.

Self-service password reset, by contrast, is a way to recover a forgotten password, not a sign-in method.

External identities let people outside your organization sign in to your apps with accounts they already have, while you still control what they can reach. The Microsoft Entra capability for this is Microsoft Entra External ID, and it covers two main scenarios.

• Business partners (B2B collaboration). You invite a partner's employee, who appears in your directory as a guest user and signs in with their own organization's work account and password. You never create or manage a password for them, and you can apply your own Conditional Access and access rules to them.
• Customers and consumers. Your customer-facing apps let the public sign up and sign in with a social account such as Google or Facebook, or with a local account (email and password) created for your app.

Do not confuse External ID with Microsoft Entra Connect, which synchronizes your own on-premises employees into Microsoft Entra ID, or with Domain Services, which provides domain features for VMs. External ID is specifically about people who are not your employees.

Microsoft Entra Conditional Access is a policy engine that decides, at sign-in, whether to allow access, block it, or allow it only after an extra requirement is met, such as completing MFA or using a compliant (managed) device. It runs after the user's first factor (such as a password) is checked, evaluates signals about the sign-in, and applies an if-then rule: if these conditions are true, then apply this control.

The signals are properties of the sign-in attempt itself:

• User or group: who is signing in, including members of a Microsoft Entra directory role such as Global Administrator.
• Location: where the user is signing in from, as an IP address range or country. It is not the Azure region where the target resources are deployed.
• Device: the device in use and whether it is managed or compliant.
• Application: which cloud app the user is trying to reach.
• Risk: the calculated risk of the sign-in, such as an unfamiliar location or atypical travel (sign-ins from places too far apart to reach in the time between them).

What a user is allowed to do on a resource is not a Conditional Access condition: a user's Azure RBAC role assignments (permissions on subscriptions, resource groups and resources) are evaluated later, when they act on that resource. Do not confuse these with Microsoft Entra directory roles such as Global Administrator, which describe who the user is in the directory and can be targeted by a Conditional Access policy. The two work together but answer different questions. Conditional Access decides whether and how the user gets in; RBAC decides what they can do on which resources once in. A requirement such as "finance staff must sign in from a compliant device, and may only read the billing storage account" therefore needs both: a Conditional Access policy for the device requirement and an RBAC role assignment at the storage account for the read-only permission. Neither tool can do the other's job.

A concrete example: a policy that requires MFA for anyone in the Global Administrator role means a stolen admin password alone is stopped at the MFA prompt. Another common policy blocks sign-ins from countries where the company has no staff.

Azure role-based access control (Azure RBAC) is the authorization system for Azure resources: it decides which actions a signed-in user, group or application may perform, and where. You grant access by creating a role assignment, which has three parts: the security principal (who), the role definition (what actions), and the scope (where). This makes it easy to follow least privilege: give each person only the access their job needs.

Scope and inheritance. Scopes form a hierarchy: management group, subscription, resource group, resource. A role assigned at one level is inherited by everything below it: a role at the subscription applies to every resource group in it, including resource groups created later, and to every resource inside them. The scope therefore sets the reach of an assignment: the broader the scope, the more resources it covers, and an assignment cannot be "carved out" further down by a lower-level role.

Common built-in roles:

Azure also has many resource-specific built-in roles, such as Virtual Machine Contributor, which can manage virtual machines but not grant access to others. Least privilege means combining two choices: the role with the smallest set of actions that still covers the job, and the narrowest scope that still covers the resources involved.

RBAC versus Azure Policy. The two are easy to mix up. RBAC controls who may act on resources. Azure Policy controls what resources may look like, for example only allowed regions or VM sizes, and applies to everyone, including Owners. Giving a developer rights to manage one resource group is RBAC; stopping anyone from deploying outside approved regions is Azure Policy. (Azure Policy itself is covered with governance tools in the management and governance domain.)

Two security models shape how Azure protects resources, and the exam expects you to recognize each by what it does.

Zero Trust is summed up as "never trust, always verify." No request is trusted because of where it comes from, even inside the corporate office. Microsoft states three principles:

• Verify explicitly: authenticate and authorize every request using all available signals (identity, location, device health, risk). MFA and Conditional Access put this into practice.
• Use least-privilege access: give only the access needed, and only for as long as needed, for example just-in-time access that expires. Azure RBAC at a narrow scope puts this into practice.
• Assume breach: design as though an attacker is already inside, and limit the damage (the "blast radius"). In practice this means segmenting networks and access so a compromised server cannot reach everything, encrypting traffic end to end, and using monitoring to spot threats quickly.

Defense in depth uses multiple independent layers of security, so that if one layer fails another still protects the data at the center (often pictured as an onion). The layers, from the outside in:

The two models fit together but are not the same:

Network segmentation shows up in both, as the network layer of defense in depth and as a way to assume breach in Zero Trust.

Microsoft Defender for Cloud is Azure's service for measuring and improving your cloud security. It has two jobs: security posture management and workload protection.

For posture management, it continuously assesses your resources against security best practices, lists prioritized recommendations (such as "enable MFA for these accounts" or "restrict this open port"), and summarizes the result as a secure score. The secure score measures how closely your resources follow those security recommendations: fix recommendations and the score rises.

For workload protection, it watches running resources such as virtual machines, storage, databases and containers, and raises security alerts when it detects suspicious activity. Through Azure Arc and multicloud connectors it can also cover on-premises servers and resources in other clouds, giving one view across a hybrid estate.

Several other security numbers sit near the secure score; keep them apart:

Defender for Cloud does not assign roles (that is RBAC), block sign-ins (that is Conditional Access) or enforce allowed SKUs and regions at deployment (that is Azure Policy).