AZ-900 Identity, Governance, Privacy, and Compliance Features Explained for Microsoft Azure Fundamentals AZ-900 Candidates

1. Why this AZ-900 topic matters

For AZ-900, this domain is less about memorizing product names and more about keeping the control layers straight. Identity proves who is requesting access. Authorization defines what that identity can do. Honestly, governance is mostly about deciding what should be allowed into the environment in the first place. Privacy and compliance are what help organizations stay aligned with legal requirements, meet regulatory expectations, and earn trust from customers and auditors. Security and monitoring tools help assess, detect, and improve posture over time.

If you keep that model in mind, a lot of exam questions become easier. Azure is not just infrastructure in someone else’s datacenter. It is a platform where access, governance, auditability, and operational control all matter from day one.

2. Identity and authentication in Azure

Microsoft Entra ID, formerly Azure Active Directory, is Microsoft’s cloud identity and access management platform. A Microsoft Entra tenant is a dedicated Entra ID instance that represents an organization’s identity boundary. An Azure subscription lives inside a tenant, and it relies on identities from that tenant to decide who can get in and manage resources.

At a high level, Entra ID keeps track of the main identity building blocks you’d expect: users, groups, applications, service principals, managed identities, and admin roles. That matters because Azure access is not only for people. Applications and services also need identities.

Traditional Active Directory Domain Services and Microsoft Entra ID are different technologies. AD DS is built around domain join, Group Policy, Kerberos, LDAP, and classic Windows domain scenarios. Entra ID is cloud-first and built for internet-based identity, SaaS sign-in, modern authentication, and policy-driven access.

Authentication answers, “Who are you?” Authorization answers, “What can you do?” That distinction is critical. Depending on what the organization allows, authentication can use passwords, passkeys, certificates, Windows Hello for Business, or MFA. SSO improves the sign-in experience across applications. Conditional Access is not an authentication method; it is a policy engine that evaluates signals during sign-in and access, then enforces controls such as require MFA, require a compliant device, block access, or require password change in some risk scenarios.

Conditional Access can look at things like the user or group, the app they’re trying to reach, the device state, where they’re signing in from, and even sign-in or user risk. In the real world, a lot of organizations start simple: require MFA for admins, block legacy authentication, and make sure sensitive apps can only be reached from compliant devices. A lot of teams use report-only mode first so they can see what would happen before they actually turn the policy on. Also note that many advanced Conditional Access and identity governance features depend on the appropriate Microsoft Entra licensing tier.

External collaboration is also part of the identity story. Entra supports B2B guest collaboration for partners and external users. Older materials may also mention Azure AD B2C for customer identity scenarios. That legacy name can still appear in study content, so it is worth recognizing even though Microsoft branding around external and customer identity has evolved.

3. Workload identities, hybrid identity, and privileged access

Not every identity in Azure is human. Workload identities are used by applications and services. At a fundamentals level, an app registration defines an application in Entra ID, and a service principal is the security identity used by that application in a tenant. Managed identities are a special Azure feature that gives an Azure resource its own identity without you storing secrets in code or configuration.

A good example is an Azure App Service or VM using a managed identity to reach Azure Key Vault without storing secrets in the app itself. And honestly, that’s a lot better than hardcoding usernames, passwords, or connection strings into scripts. For AZ-900, you don’t need the deep technical plumbing, but you should know managed identities are a secure way for Azure resources to authenticate to other Azure services.

Hybrid identity is common. A lot of organizations sync their on-premises AD DS identities into Entra ID by using Microsoft Entra Connect or cloud sync options. Password hash synchronization copies a hash representation so users can sign in to the cloud, pass-through authentication checks the password against on-premises infrastructure, and federation hands the sign-in process off to an external identity provider. For AZ-900, the exam usually cares more about the concept than the deep design details: sync means identities are copied into the cloud, while federation means sign-in is handled by a trusted external identity system.

For privileged access, least privilege matters. MFA should be standard for admins, and standing permanent admin rights should be minimized. Microsoft Entra Privileged Identity Management, or PIM, supports just-in-time and time-bound activation of privileged roles. Even if AZ-900 only touches this lightly, it is a strong example of Zero Trust in practice.

4. Microsoft Entra roles vs Azure RBAC roles

This is one of the most common exam traps. Microsoft Entra roles manage the directory and identity platform. Azure RBAC roles manage Azure resources.

A Global Administrator can manage a lot of Entra settings, but that doesn’t automatically give them full access to every Azure subscription unless they also have Azure resource permissions. For the exam, if the question is about users, sign-in settings, or tenant administration, you should be thinking Entra roles. If it is about VMs, storage accounts, networks, or resource groups, think Azure RBAC.

5. Azure RBAC, scopes, and how the governance structure all fits together

Azure role-based access control, or Azure RBAC, is what decides who can do what with Azure resources. The pattern is simple: security principal plus role plus scope. The security principal might be a user, group, service principal, or managed identity. The role defines allowed actions. The scope defines where those permissions apply.

The main scopes are management group, subscription, resource group, and individual resource. Management groups are optional, but they’re incredibly useful when an organization wants the same governance rules across multiple subscriptions. A subscription is primarily a billing, quota, and management boundary. RBAC can be assigned at subscription scope, but a subscription is not the only place where access is controlled.

Role assignments inherit downward. If you assign a role at subscription scope, it applies to resource groups and resources inside that subscription unless a more specific control changes the outcome. That inheritance is why higher-scope assignments should be used carefully.

Practical example: assign Reader to an audit group at subscription scope and Contributor to an app team at a single resource group scope. Auditors can view everything in the subscription. The app team can deploy and manage only resources in its assigned resource group. That is cleaner and safer than giving broad Owner rights everywhere.

There is also an important nuance around control planes. Azure RBAC commonly governs management-plane access to Azure resources. Some services also support data-plane permissions, which control access to the actual data inside a service, like the contents of a storage account. For AZ-900, the big thing to remember is that having access to the resource itself doesn’t always mean you automatically have access to the data inside it.

6. Azure Policy, initiatives, tags, and resource locks

RBAC answers who can act. Azure Policy answers whether a resource configuration is allowed or compliant. Resource locks protect existing resources from management-plane changes or deletion. Tags are metadata labels used for organization, automation, and reporting.

Azure Policy uses definitions and assignments. A definition is the rule. An assignment applies the rule at a scope. Organizations often bundle multiple policies into an initiative, which is a set of policies applied together. A common example is a baseline initiative that requires tags, limits deployments to approved regions, and only allows approved SKUs.

Azure Policy has a few common effects, including Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists, and Disabled. For AZ-900, the ones you’ll want to focus on are:

Deny blocks noncompliant deployments.
Audit records noncompliance without blocking.
Modify can change or add properties during resource creation or update.
DeployIfNotExists can deploy related settings if missing.
AuditIfNotExists checks whether a related resource or setting exists.

A simple policy example is restricting deployments to East US and West Europe only. Another is requiring tags such as owner, environment, and costCenter. Tags by themselves do not enforce anything. If you want required tags, Azure Policy enforces that rule.

Tags are useful for cost management, ownership tracking, and automation. A practical tag strategy might include application, owner, environment, costCenter, and businessUnit. Also remember that tags do not universally and automatically inherit to every child resource. Where consistent tagging is required, Policy is usually involved.

Resource locks are different from Policy. A CanNotDelete lock prevents deletion. A ReadOnly lock blocks changes through the management plane and also prevents deletion operations that require management changes. Locks apply at subscription, resource group, or resource scope and inherit downward. They can block actions even when RBAC permissions would otherwise allow them, until the lock is removed.

Here’s one more practical distinction: if a user can sign in and has Contributor rights but still can’t deploy a VM in an unapproved region, that’s usually a Policy issue. If the resource is there but it won’t delete, I’d check for a lock first. If the user can’t modify the resource at all, check RBAC first, then look at locks if the permissions seem right.

7. Privacy, compliance, and who’s responsible for what in Azure

Put simply, privacy is about how data gets collected, handled, protected, and used. Compliance is about meeting outside requirements like laws, standards, and formal attestations. They’re definitely related, but they’re not the same thing.

It is also important not to treat all compliance examples as the same category. ISO 27001 is a certification standard that organizations can be audited against. SOC reports are attestation reports. GDPR is a privacy regulation. HIPAA is the U.S. healthcare legal and regulatory framework that comes into play for protected health information. Azure can absolutely support these requirements, but just because the platform supports them doesn’t mean the customer workload is automatically compliant.

The shared responsibility model matters here. Responsibility varies by service model. In SaaS, Microsoft manages more of the stack. In PaaS, responsibility is shared. In IaaS, customers manage much more, including guest OS configuration and many workload controls. Customers remain responsible for identity settings, access control, data classification, retention choices, application configuration, and many compliance decisions regardless of service model.

Data residency usually refers to the geographic location where customer data at rest is stored. Data sovereignty refers to the legal jurisdiction and laws that apply to that data. Data processing location is related but separate. Those distinctions really matter in regulated industries and multinational environments.

8. Trust Center and Service Trust Portal

The Microsoft Trust Center is the public-facing place where Microsoft talks about its approach to security, privacy, compliance, and responsible practices. The Service Trust Portal goes a level deeper and gives you things like audit reports, certification documents, and compliance guidance. Some Service Trust Portal artifacts require authenticated access and appropriate entitlement.

That distinction is useful in real projects. Legal and procurement teams often start with the public transparency info just to get a high-level feel for Microsoft’s practices. Security, audit, and compliance teams usually go straight to the detailed audit and certification materials when they need evidence for due diligence, migration approval, or audit prep.

9. Defender for Cloud, Purview, and Sentinel — and why they’re not the same thing

These services solve different problems, and AZ-900 likes to test the differences.

Microsoft Defender for Cloud provides cloud security posture management and cloud workload protection capabilities. It gives recommendations, visibility into configuration issues, and a Regulatory Compliance dashboard. Secure Score is a handy way to measure and prioritize security posture, but it isn’t proof of compliance, and it definitely doesn’t mean everything is secure.

Microsoft Purview focuses on data governance and compliance features like discovering data, cataloging it, classifying it, and helping organizations figure out where sensitive information lives across their data estate. Think of Purview as helping you understand and govern data.

Microsoft Sentinel is a cloud-native SIEM and SOAR platform, which basically means it helps collect, analyze, and respond to security events. It pulls in logs and alerts from Azure, Microsoft 365, on-premises systems, and even third-party sources. It’s used for analytics, detection, investigation, incident handling, and automated response through playbooks.

10. Figuring out why access or deployments are failing

A compact diagnostic flow helps a lot:

Sign-in fails - check authentication method, MFA, and Entra sign-in logs.
Sign-in succeeds but access is denied - check Azure RBAC or Entra role depending on whether the target is a resource or directory setting.
Deployment is blocked - check Azure Policy, quota limits, and resource provider registration.
Delete or update is blocked on an existing resource - check for resource locks.
Compliance concerns - check Defender for Cloud recommendations and regulatory views, then validate requirements against Microsoft’s public trust information or detailed compliance documentation.

Typical exam trap: a user signs in successfully but cannot create a VM. That is usually not an authentication problem. First check RBAC. If the role is correct, check Policy for allowed regions, required tags, or approved VM sizes. Then consider subscription quota or provider-registration issues.

11. Zero Trust and security best practices

Zero Trust in Azure maps cleanly to core services. Verify explicitly maps to MFA, strong authentication methods, and Conditional Access. Use least privilege maps to Azure RBAC, Entra roles, group-based assignment, and PIM. Assume breach maps to logging, Defender for Cloud, Sentinel, segmentation, and careful control of privileged access.

Strong baseline practices include requiring MFA for admins, using groups instead of many direct role assignments, minimizing Owner assignments, using managed identities for workloads, protecting critical resources with locks where appropriate, and reviewing guest access regularly. Break-glass emergency accounts are also a real-world best practice, though they are beyond what AZ-900 usually tests in detail.

12. AZ-900 exam quick-reference

Use this as a cram sheet:

Final memory line: identity gets you in, RBAC defines permissions, Policy defines standards, locks protect resources, Trust Center explains, Service Trust Portal provides evidence, Defender for Cloud assesses, Purview classifies, and Sentinel investigates.