Azure Identity, Access & Security: AZ-900 Guide

In the cloud, identity is the starting point of security. There is no office building or private network to keep intruders out, so what protects your resources is knowing who is asking and what they are allowed to do. Two ideas run through this whole topic. Authentication asks "who are you?" and proves it — for example by checking a password. Authorization asks "what are you allowed to do?" once your identity is known — for example, whether you may read a file or delete a virtual machine.

Getting these right matters because a single stolen password can otherwise open the door to everything. Azure therefore provides a dedicated identity service to store accounts and verify sign-ins, plus tools to decide, on every request, whether to allow access and how much power to grant.

For the AZ-900 exam, keep the two words straight: authentication is proving identity, and authorization is granting permissions. The services in this lesson map onto them — Microsoft Entra ID and the authentication methods handle who you are, while Azure RBAC and Conditional Access handle what you can reach. The overarching models, Zero Trust and defense in depth, then describe the mindset that ties everything together. Learn the plain purpose of each and the exam's identity questions become recognition, not memorization.

Microsoft Entra ID is Azure's cloud-based identity and directory service. It stores your organization's user accounts and groups, and it verifies sign-ins so people and applications can securely reach Azure, Microsoft 365, and thousands of other cloud apps. Importantly for the exam, Microsoft Entra ID is the service formerly known as Azure Active Directory (Azure AD) — Microsoft renamed it, but the capabilities are the same, so questions may use either name.

Because it is designed for the internet, Microsoft Entra ID is where you manage identities centrally, enable single sign-on across apps, and turn on protections such as multi-factor authentication and Conditional Access. It is the backbone that the rest of this lesson builds on.

Microsoft Entra Domain Services is a separate, managed service that provides traditional domain features in the cloud — such as domain join, group policy, and legacy authentication protocols like Kerberos and NTLM — without you having to deploy and patch your own domain controllers. It suits older applications that expect a classic Windows Server domain but that you want to run in Azure. For the exam, keep the distinction simple: Microsoft Entra ID is the modern cloud directory and sign-in service (the former Azure AD), while Microsoft Entra Domain Services adds managed, traditional domain capabilities for workloads that still need them.

Authentication is how a user proves they are who they claim to be. Azure supports several methods, and the exam expects you to tell them apart.

Single sign-on (SSO) lets a user sign in once and then reach many applications without signing in again. It improves both security and convenience: with fewer passwords to remember, people reuse weak passwords less, and administrators manage one identity per person. Multi-factor authentication (MFA) requires two or more pieces of evidence from different categories — something you know (a password), something you have (a phone or token), or something you are (a fingerprint or face). Even if a password is stolen, an attacker still lacks the second factor, so MFA is one of the strongest, simplest protections available. Passwordless authentication removes the password entirely, replacing it with something more secure and convenient such as the Microsoft Authenticator app, a Windows Hello face or fingerprint scan, or a FIDO2 security key.

Microsoft Entra external identities extends this to people outside your organization, letting partners and customers sign in with their own accounts while you still control their access.

Microsoft Entra Conditional Access is a feature that grants or blocks access based on conditions. After a user's identity is verified, Conditional Access evaluates signals about the sign-in and then decides what to do — allow it, block it, or allow it only after an extra requirement is met. You can picture it as an if-then rule: if these conditions are true, then apply this control.

The signals it can consider include the user's location (which country or IP range they are signing in from), the device they are using and whether it is managed or compliant, the application being accessed, and the calculated risk of the sign-in (for example, an unfamiliar location or an impossible-travel pattern). Based on those signals, Conditional Access can require multi-factor authentication, demand a compliant device, or block the attempt outright.

Here is a concrete example. An administrator creates a Conditional Access policy that says: for anyone in the global administrator role, always require multi-factor authentication before granting access. Now, even if an admin's password is stolen, the attacker is stopped at the MFA prompt. Another common policy blocks sign-ins from countries where the company has no staff. On the exam, the phrase "grant or block access based on conditions or signals" points directly to Conditional Access.

Once a user is authenticated, authorization decides what they may actually do — and in Azure that is handled by role-based access control (Azure RBAC). RBAC lets you assign roles to users, groups, or applications to grant them a specific set of permissions, rather than giving everyone full control. This makes it easy to follow the principle of least privilege: give each person only the access their job requires, and no more.

An RBAC role assignment has three parts: the who (a user, group, or service, called the security principal), the what (a role definition such as Reader, Contributor, or Owner that lists the allowed actions), and the where (a scope such as a subscription, resource group, or a single resource). Because you can apply a role at different scopes, you can grant broad access across a subscription or narrow access to one storage account.

For example, you might give a support engineer the Reader role on a resource group so they can view resources but change nothing, while a developer gets Contributor on the same group to create and manage resources without being able to hand out access to others. On the exam, wording such as "assign least-privilege permissions by role" or "let a user view but not modify resources" points to Azure RBAC.

Two security models shape how Azure protects resources, and the exam expects you to recognize both by their guiding phrase.

Zero Trust is summed up as "never trust, always verify." Instead of assuming that anything inside the corporate network is safe, Zero Trust treats every request as if it comes from an untrusted network and verifies it explicitly — checking the user's identity, the device's health, and other signals every time, and granting only the least privilege needed. Its guiding principles are to verify explicitly, use least-privilege access, and assume breach (design as though attackers may already be inside). Conditional Access, MFA, and RBAC are the practical tools that put Zero Trust into effect.

Defense in depth uses multiple layers of security so that if one layer fails, another still protects your data — often pictured as the layers of an onion. The layers run from the outside in: physical security of the datacenter, identity and access, perimeter protection (such as guarding against denial-of-service attacks), network controls, compute, the application, and finally the data itself at the center. No single control is expected to stop every attack; the point is that an attacker must get past many of them.

Microsoft Defender for Cloud is Azure's service for monitoring and strengthening the security of your cloud environment. It has two broad jobs that the exam describes at a recognition level: improving your security posture and providing workload protection.

For security posture management, Defender for Cloud continuously assesses your resources against security best practices and gives you a secure score — a single number that summarizes how well your environment is configured. It then lists prioritized recommendations, such as "enable multi-factor authentication for these accounts" or "restrict this open network port," so you know what to fix first to raise the score and reduce risk.

For workload protection, Defender for Cloud watches your running resources — virtual machines, storage, databases, containers, and more — and raises security alerts when it detects suspicious activity or a likely threat, helping you respond quickly. It can also protect resources running in other clouds or on-premises through Azure Arc, giving one place to see security across a hybrid estate.

For the exam, keep the purpose simple: Microsoft Defender for Cloud assesses your security posture (with a secure score and recommendations) and protects your workloads (with threat detection and alerts). If a question asks which tool gives an overall view of your cloud security and tells you how to improve it, the answer is Microsoft Defender for Cloud.