AZ-900 Guide: Identity, Governance, Privacy, and Compliance Features in Azure

When I teach AZ-900, I use a simple model: identity is who you are, access control is what you can do, governance is what is allowed in the environment, and trust/compliance is how organizations support security, legal, and audit requirements. That framework matters because Azure services often sound related while solving different problems. On the exam, many wrong answers are not nonsense; they are real services applied to the wrong layer.

For AZ-900, focus on service purpose, boundaries, and business value. You are usually not being tested on deep configuration. The exam really comes down to this: can you spot the right service for the job it’s meant to do?

Identity, access, governance, and shared responsibility

Cloud changes the control model. In Azure, users can deploy resources quickly, teams can work across subscriptions, and misconfiguration can create security, cost, or compliance risk. That is why identity and governance are core cloud concepts, not optional extras.

Shared responsibility is really the bedrock here — everything else sits on top of it. Microsoft handles the security of the cloud platform itself, but customers still have to manage how identities are set up, how data’s handled, and how resources get deployed. The exact split varies by service model. With IaaS, you’re still on the hook for things like configuring the guest operating system and keeping virtual machines patched. In PaaS and SaaS, Microsoft takes care of more of the platform, but the customer still owns access decisions, data classification, and a lot of the compliance side.

Microsoft Entra ID: Identity First

Microsoft Entra ID, formerly Azure Active Directory, is Microsoft’s cloud identity and access service. A tenant is a dedicated Microsoft Entra ID instance associated with an organization. That tenant is basically the home base for your identities — users, groups, applications, and service principals live there, and from that one directory, you can connect to one or more Azure subscriptions.

For Azure resources, the easiest exam-safe statement is this: Microsoft Entra ID authenticates identities, and Azure RBAC authorizes management access to Azure resources. That wording is more precise than saying Entra ID has nothing to do with authorization. Entra ID also participates in authorization for many applications through tokens, claims, groups, and app roles. So if AZ-900 asks who can create, delete, or manage Azure resources, you’ll usually be looking at Azure RBAC.

Entra ID supports a lot of the identity plumbing behind the scenes — users and groups, single sign-on, multi-factor authentication, external identities, and those hybrid identity setups you see in real organizations. In hybrid environments, organizations often synchronize on-premises identities to the cloud using Microsoft Entra Connect Sync, or they may use federation models. For exam purposes, just know Azure identity is often hybrid, not purely cloud-native.

It also helps to separate identity object types:

• Application registration: the app definition in Entra ID.
• Service principal: the security identity for that application in a tenant.
• Managed identity: an automatically managed identity for an Azure resource, often used so code does not need stored credentials.

That last one is especially practical. If an Azure VM, App Service, or Function needs to talk to another Azure service, I’d usually rather use a managed identity than stash a username, password, or secret in code — it’s just a cleaner and safer approach.

Authentication, Conditional Access, and the basics of Zero Trust

Authentication answers, “Who are you?” Authorization answers, “What are you allowed to do?” A user might successfully sign in and still be unable to create a VM. That is normal. It means identity worked, but permission did not.

Conditional Access is part of identity protection. It evaluates signals such as user or group, application, device state, named location, sign-in risk, and other session conditions. A policy might say admins have to use MFA, sign-ins from risky locations should be blocked, or only compliant devices can get in. Conditional Access lines up really well with Zero Trust ideas like verify explicitly and use least privilege, but it doesn’t take the place of Azure RBAC.

A simple way I like to picture the flow is this:

User signs in with Entra ID → Entra ID validates identity and may enforce MFA/Conditional Access → Azure RBAC evaluates allowed management actions at scope → Azure Policy evaluates whether the deployment/configuration is allowed → Resource lock may still block modification or deletion

Azure RBAC: Permissions and Scope

Azure RBAC, or Role-Based Access Control, is Azure’s main authorization system for management-plane access through Azure Resource Manager. It determines what an identity can do at a given scope. Common scopes are management group, subscription, resource group, and resource. Role assignments at broader scopes are inherited by child scopes.

Important built-in roles for AZ-900 include:

• Reader: can view resources.
• Contributor: can create and manage resources, but cannot assign roles.
• Owner: full management access to resources, including role assignment.
• User Access Administrator: can manage user access to Azure resources.

Even Owner is not “unstoppable.” Actions can still be affected by locks, Azure Policy, Privileged Identity Management activation, service-specific controls, or other constraints.

Least privilege means giving only the access required. A finance auditor may need Reader at resource group scope. A developer may need Contributor only in a dev resource group, not across the whole subscription. Group-based assignment is usually better than assigning roles one user at a time.

One useful nuance: Azure RBAC often governs the management plane, but some services also have data-plane access controls. For example, storage and Key Vault scenarios may involve additional data access roles, ACLs, or service-specific models. For AZ-900, just remember that not every access question is purely management-plane RBAC.

Tenant, management groups, subscriptions, and resource groups — those are the main building blocks for organizing Azure.

The way you organize Azure really matters, because it has a direct impact on access, governance, billing, and how smoothly the environment can scale.

Tenant → Management Group → Subscription → Resource Group → Resource. That’s the hierarchy I keep in mind when I’m explaining how Azure is structured.

A subscription is more than billing. It is also an access and limit boundary. A resource group is basically a logical container, but that doesn’t mean every related resource has to sit in the same one. In real environments, teams often split networking, shared services, or production databases into different groups because of lifecycle, access, or policy needs.

Management groups are especially useful in enterprises. If a company has separate subscriptions for production, development, and different business units, management groups let it apply governance and access rules at scale.

Azure Policy, Tags, and Resource Locks

Azure Policy is about standards. RBAC answers who can act; Policy answers whether the requested configuration is allowed. A policy can evaluate existing resources and new deployments. Common effects include deny, audit, append, modify, and deployIfNotExists. Policies are defined, assigned to scope, evaluated for compliance, and sometimes remediated. A collection of related policies is called an initiative, also known as a policy set.

Common examples include restricting allowed regions, requiring specific tags, or limiting SKU choices. Even if a user has Contributor rights, the deployment can still fail if it breaks policy. Honestly, that’s one of the most common AZ-900 gotchas.

Tags are name/value metadata applied to subscriptions, resource groups, or resources. They help with cost reporting, ownership, automation, and chargeback. A practical taxonomy might include Environment, Owner, Department, and CostCenter. Tags do not secure resources, do not automatically inherit in every scenario, and should not contain secrets or sensitive personal data.

Resource locks protect resources at the management plane. There are two main types:

• CanNotDelete: prevents deletion.
• ReadOnly: prevents modification and can block some operations that are not obviously “writes.”

Locks can affect even authorized users, including Owners, until the lock is removed by someone with the right permissions. They are useful for production protection, but they are not a substitute for RBAC or Policy.

Defender for Cloud, Purview, and Trust Resources

Microsoft Defender for Cloud is primarily a security service. At a high level, it provides cloud security posture management and workload protection capabilities. For AZ-900, remember these ideas: secure score, recommendations, regulatory compliance view, and protection for workloads. It helps you assess security posture and improve it; it does not automatically make you compliant.

It is also worth separating Defender for Cloud from similar-sounding services. Azure Policy enforces standards. Defender for Cloud surfaces security recommendations and posture insights. Microsoft Sentinel is a broader SIEM/SOAR platform for security operations. On the exam, if you see secure score or security recommendations, think Defender for Cloud.

Microsoft Purview is broader than a single Azure-only service. It’s really a Microsoft family of tools and capabilities that focus on data governance, risk, and compliance. At the fundamentals level, the main thing to know is that Purview helps organizations find, classify, catalog, and govern their data. Think of it as data mapping, cataloging, classification, lineage, and governance that pays attention to sensitivity. That is different from Defender for Cloud, which is about security posture, and different from Azure Policy, which is about allowed resource configurations.

Service Trust Portal is Microsoft’s trust documentation hub. Organizations use it to review audit reports, compliance documentation, privacy information, and other evidence for due diligence or audit preparation. Some content requires sign-in and appropriate eligibility or agreements. For AZ-900, just recognize it as a source of trust and compliance documentation.

Privacy and compliance are definitely areas where the wording matters a lot. Microsoft provides certifications, attestations, contractual commitments, and supporting documentation that can help customers work toward standards and regulations like ISO, SOC, GDPR-related requirements, and healthcare scenarios. But here’s the important part: using Azure doesn’t automatically make a customer compliant. They still own configuration, retention, classification, access reviews, and operational controls.

Data residency refers to where customer data is stored, and in some service commitments may also relate to where certain processing occurs. Data sovereignty is about which countries, jurisdictions, and legal systems can influence how that data’s handled. And yeah, those ideas matter a lot, especially in regulated industries and multinational environments.

Common AZ-900 scenarios and troubleshooting logic

These are the patterns I really want learners to spot quickly:

• User cannot sign in: think Entra ID, MFA, Conditional Access, or identity source issues.
• User can sign in but cannot create a resource: think RBAC role assignment, scope, inherited access, or PIM activation.
• User has Contributor but deployment is denied: think Azure Policy, region/SKU restrictions, required tags, or quota/provider issues.
• Authorized user cannot delete or update a resource: think resource lock as a common cause, but also consider RBAC, dependencies, or provider constraints.
• Auditor wants compliance evidence: think Service Trust Portal, Defender for Cloud regulatory views, and Purview for data governance context.

Here’s a compact troubleshooting checklist I like to use:

1. Confirm sign-in success in Entra ID 2. Check role assignments in Access control (IAM) 3. Verify assignment scope and inheritance 4. Review deployment error details and Activity Log 5. Check Azure Policy compliance/deny results 6. Check for CanNotDelete or ReadOnly locks 7. Consider quotas, provider registration, and service-specific controls

Practical examples help. If finance auditors need view-only access to one resource group, assign Reader at that resource group scope. If a company wants to stop VM deployment outside approved regions, use Azure Policy. If a production storage account must not be deleted accidentally, apply a CanNotDelete lock. If an app running on an Azure VM needs to access Key Vault without stored secrets, use a managed identity.

What AZ-900 Expects You to Know

AZ-900 expects you to know service purpose, business value, and key distinctions. It does not usually expect deep implementation detail, custom JSON authoring, or advanced architecture troubleshooting.

High-frequency exam traps are predictable:

• Entra ID is not the same as Azure RBAC.
• Contributor does not override Azure Policy.
• A tag does not secure a resource.
• A lock is not the same as a permission assignment.
• Defender for Cloud is not the same thing as Purview.
• Microsoft compliance certifications do not make the customer automatically compliant.

Quick practice questions

1. A user can sign in to the Azure portal but still can’t create a VM in a resource group. Most likely answer: Azure RBAC.

2. A deployment is blocked because the VM is being created in an unapproved region. Most likely answer: Azure Policy.

3. A production database cannot be deleted even by an authorized admin. Most likely answer: Resource lock.

4. An organization wants MFA for admin accounts and risky sign-ins. Most likely answer: Microsoft Entra ID Conditional Access.

5. A compliance officer needs Microsoft audit documentation. Most likely answer: Service Trust Portal.

6. A company wants to discover and classify sensitive data across sources. Most likely answer: Microsoft Purview.

7. A team wants recommendations and secure score improvements. Most likely answer: Microsoft Defender for Cloud.

8. An Azure app should access another Azure service without storing secrets in code. Most likely answer: Managed identity.

Final Review

If you remember the layered model, most AZ-900 questions become easier. Microsoft Entra ID handles identity and sign-in. Azure RBAC controls management access to Azure resources. Azure Policy defines what configurations are allowed. Tags organize resources. Resource locks protect against delete or modification at the management plane. Defender for Cloud helps assess and improve security posture. Purview helps discover, classify, and govern data. Service Trust Portal provides trust and compliance documentation. And throughout all of it, compliance remains a shared responsibility.

That is the real exam skill: identify the layer, then choose the service that belongs to that layer.