AZ-900 Identity, Governance, Privacy, and Compliance Features Explained

A practical AZ-900 walkthrough of Microsoft Entra ID, Azure RBAC, Azure Policy, governance hierarchy, locks, tags, Defender for Cloud, and the compliance tools you’ll actually run into out in the real world.

Azure can scale fast, and honestly, if you don’t get identity and governance sorted early, things can get messy before you know it. I’ve seen teams spin up subscriptions, place resources in whatever region felt easiest, hand out Owner like it was nothing, skip tagging completely, and then act surprised when cost reports, audit requests, and access problems turn into a real headache. For AZ-900, the main thing to remember is that identity, governance, privacy, and compliance aren’t just nice extras. They’re core pieces of how cloud actually works.

So, at a high level, I usually break it down like this:

• Microsoft Entra ID handles identity and authentication.
• Azure RBAC handles authorization for Azure resources.
• Azure Policy enforces organizational standards.
• Locks and tags help protect and organize resources.
• Defender for Cloud helps assess security posture.
• Trust and compliance tools help with privacy, audit, and regulatory support.

1. Microsoft Entra ID Fundamentals

Microsoft Entra ID, formerly Azure Active Directory, is Microsoft’s cloud identity and access management service. A tenant is an instance of Microsoft Entra ID associated with an organization. Many organizations use one tenant, but some use multiple tenants for isolation, mergers, sovereignty, or regulatory reasons. Azure subscriptions trust one Entra tenant at a time for identity and access management.

Common identity objects include:

• Users - human identities.
• Groups - collections used to simplify access management; depending on type and scenario, they may contain users, devices, service principals, or other groups.
• Application objects - global definitions of an app.
• Service principals - tenant-specific identities for applications.
• Managed identities - Azure-managed identities for workloads.
• External identities - guest and partner access through Entra external collaboration.

Managed identities are especially useful because they let Azure services authenticate without storing credentials in code. A system-assigned managed identity is tied to one resource and deleted with it. A user-assigned managed identity is a separate Azure resource that can be attached to multiple supported resources.

For exams, remember the difference between authentication and authorization:

• Authentication = proving who you are.
• Authorization = determining what you can do.

Entra ID is also central to single sign-on and hybrid identity. In hybrid environments, organizations connect on-premises identity with cloud identity so users can sign in once and then move into cloud services without feeling like they’re starting over every single time.

2. Keeping sign-ins protected with MFA, Security Defaults, Conditional Access, and Zero Trust

Multi-factor authentication (MFA) requires more than one factor during sign-in, such as a password plus Microsoft Authenticator, a FIDO2 key, or biometrics. Honestly, MFA’s one of the best defenses you’ve got against stolen passwords.

Microsoft also offers Security Defaults, which provide baseline identity protections for eligible environments. They’re definitely simpler than Conditional Access, and I usually think of them as a good fit for smaller environments or setups that don’t need a ton of customization.

Conditional Access adds granular, context-aware access decisions. Those policies can look at things like the user, group, location, device health, app, sign-in risk, or user risk, and then decide whether to require MFA, block access, or apply some other control. Conditional Access typically requires appropriate Entra licensing, so it is more advanced than Security Defaults.

Good operational practice includes:

• Using report-only mode before broad enforcement.
• Testing carefully with pilot groups.
• Creating exclusions for emergency access or break-glass accounts.
• Reviewing sign-in logs when users report access problems.

Zero Trust is the broader model behind modern identity security. Its core principles are simple but powerful: verify explicitly, use least privilege, and assume breach. And it doesn’t stop at identities — it applies to devices, apps, data, infrastructure, and networks too.

3. Azure Roles, Entra Roles, and Azure RBAC

This is a major exam topic. Microsoft Entra roles and Azure RBAC roles are not the same thing.

Entra roles are directory roles. Examples include Global Administrator and Security Administrator. These roles manage identity and directory features.

Azure RBAC roles are resource roles. Common examples are Reader, Contributor, Owner, and User Access Administrator. These roles control what people can do with Azure resources through Azure Resource Manager.

A user can be a Global Administrator in Entra ID and still not be Owner on a subscription. That distinction matters a lot.

Azure RBAC really comes down to three pieces:

• Security principal - user, group, service principal, or managed identity
• Role definition - what permissions are granted
• Scope - where the permissions apply

Scopes are arranged in a hierarchy, which is really important to understand:

• Management group
• Subscription
• Resource group
• Resource

Assignments inherit downward. If you assign Reader at a subscription, that access typically applies to resource groups and resources inside it. This is powerful, but assigning broad roles too high in the hierarchy can create excessive access.

Azure RBAC primarily governs management plane access through Azure Resource Manager. Some services also have separate data plane permissions. For example, a user may be able to manage a storage account through Azure RBAC but still need a role like Storage Blob Data Reader or Storage Blob Data Contributor to access blob data. And services like Key Vault can use Azure RBAC or a service-specific access model, depending on how they’ve been configured.

These are the built-in roles you really want to have in your back pocket:

• Reader - view resources only.
• Contributor - create and manage resources, but cannot grant access.
• Owner - full management access at that scope, including assigning access.
• User Access Administrator - manage role assignments.

Deny assignments are different from standard RBAC allow assignments. They show up in some platform-managed scenarios, like managed applications, where Azure has to block certain actions.

Best practice is to assign roles to groups instead of directly to individual users whenever possible. For privileged roles, use Microsoft Entra Privileged Identity Management (PIM) for just-in-time access, approval workflows, time-limited elevation, and access reviews.

4. Governance Hierarchy in Azure

Azure uses a hierarchy to organize and govern resources at scale. At the top is the root management group, then additional management groups, subscriptions, resource groups, and resources.

Root Management Group └── Corporate ├── Platform │ ├── Subscription: Shared-Services │ └── Subscription: Connectivity └── Workloads ├── Subscription: Prod-Finance │ └── Resource Group: Finance-App-Prod-RG │ └── Resources └── Subscription: Dev-Test

Management groups let you apply RBAC and Policy across multiple subscriptions. Subscriptions provide billing, quota, and administrative boundaries. Resource groups organize related resources that share a lifecycle. Resources are the actual services such as VMs, storage accounts, and databases.

Enterprises often separate subscriptions by production vs non-production, business unit, geography, or platform vs workload. This aligns well with landing zone design and reduces operational confusion.

5. Azure Policy: Guardrails for Resources

Azure Policy enforces standards on resources. RBAC answers who can act; Policy answers what rules resources must follow. Policy can evaluate resources during deployment and continuously after deployment for compliance.

Core Policy concepts:

• Definition - a single rule.
• Initiative - a group of policy definitions.
• Assignment - applying a definition or initiative at a scope.
• Exemption - documented exception to a policy assignment.
• Remediation task - used with supported effects to fix noncompliance.

Common effects include Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists, DenyAction, and Disabled. For beginners, the most important idea is that Policy can block, flag, or help remediate noncompliant configurations.

Typical policy examples:

• Only allow approved Azure regions
• Require tags such as Environment and CostCenter
• Enforce secure transfer or HTTPS settings
• Restrict allowed resource types or SKUs

Simple example:

{ "if": { "field": "location", "notIn": ["eastus", "westeurope"] }, "then": { "effect": "deny" } }

Policy is also how many teams enforce tag consistency. Tags do not automatically inherit from a resource group or subscription to all child resources. If you want consistent tagging, use Policy or automation, and remediate existing resources when needed.

6. Locks, Tags, and Standardization

Resource locks help prevent accidental changes at the management plane:

• CanNotDelete - prevents deletion.
• ReadOnly - blocks write operations and deletion.

ReadOnly locks can have broader side effects than beginners expect because some portal actions use POST operations behind the scenes. Locks mainly affect control plane operations, not every possible data plane action.

Tags are name-value metadata applied at subscription, resource group, or resource scope. Common examples include Environment, CostCenter, Owner, Application, and DataClassification. Tags are super useful for cost reporting, automation, and accountability, but they don’t enforce security on their own.

For standardized environments, Microsoft now emphasizes landing zones, Bicep/ARM, Template Specs, policy-as-code, and deployment pipelines. Azure Blueprints is historical context, but it has been deprecated and largely superseded by these newer approaches.

7. Defender for Cloud and Security Posture

Microsoft Defender for Cloud provides cloud security posture management (CSPM) and workload protection capabilities. It works with Azure, and in some cases it can also stretch into multicloud and hybrid environments. Some advanced protections require paid Defender plans.

Key ideas for AZ-900:

• Secure Score shows how closely your environment aligns with recommended practices.
• Recommendations highlight missing controls or risky configurations.
• Regulatory compliance dashboard maps controls to standards and frameworks.

Important exam distinction: Defender for Cloud helps assess posture and recommendations; it does not certify your workload as compliant. It works alongside RBAC, Policy, and logging — it doesn’t replace any of those controls.

8. Privacy, data residency, sovereignty, and compliance — and why they actually matter in the real world

Privacy is about how personal data is collected, used, shared, and protected. Security is about protecting systems and data from threats. Compliance is about meeting legal, regulatory, and contractual obligations.

Data residency refers to where data is stored or processed. Data sovereignty refers to the legal and jurisdictional control over that data. Choosing the right region definitely matters, but just picking a region doesn’t magically make you compliant or solve sovereignty concerns by itself. You’ve also got to think about service-specific behavior like replication, backup, logging, and whatever the service’s doing behind the scenes with your data.

Microsoft provides platform features, attestations, reports, contractual commitments, and documentation to help customers meet their obligations. That said, customers still have to put their own controls in place and work out what the regulations actually mean for their environment. In the real world, that usually means putting controls in place like:

• Least-privilege access, so people only get the permissions they actually need
• Encryption and key management, because data protection isn’t something you want to leave up to luck
• Logging and audit retention
• Data classification and retention policies
• Approved regions and deployment standards

Azure can support frameworks and regulations, but hosting a workload in Azure does not make it automatically compliant.

9. Purview, Priva, Trust Center, and Service Trust Portal

Microsoft Purview is broader than Azure alone and supports data governance, classification, and compliance-related capabilities across Microsoft and other supported data sources. At a high level, I think of Purview as the tool that helps organizations understand what data they actually have and how it should be handled.

Microsoft Priva focuses on privacy operations and privacy risk management, including support for subject rights and personal data processes.

Azure Trust Center provides public-facing information about Microsoft trust, security, privacy, and compliance practices.

Service Trust Portal provides detailed compliance documentation, audit reports, certifications, and evidence commonly used during reviews and audits. If an auditor asks for evidence, Service Trust Portal is usually the better answer than Trust Center.

10. Troubleshooting and Exam Memory Map

When Azure access or governance issues appear, use a simple diagnostic mindset:

• User can sign in but cannot create a VM - likely RBAC scope or missing role assignment.
• Deployment blocked in an unapproved region - likely Azure Policy.
• Resource exists but shows noncompliant - Policy may be auditing existing resources and remediation may still be needed.
• Delete operation fails unexpectedly - check for a CanNotDelete or ReadOnly lock.
• User is blocked during sign-in - review Conditional Access and sign-in logs.
• Auditor requests compliance reports - use Service Trust Portal.

Portal locations beginners should know:

• Microsoft Entra admin center - users, groups, MFA, Conditional Access, roles
• Azure portal > Access control (IAM) - Azure RBAC
• Azure portal > Policy - definitions, assignments, compliance
• Azure portal > Locks - resource locks
• Azure portal > Tags - metadata management
• Defender for Cloud - Secure Score and recommendations

A few AZ-900 exam traps to keep in mind:

• Authentication vs authorization - who you are vs what you can do
• Entra roles vs Azure RBAC roles - directory access vs resource access
• RBAC vs Policy - permissions vs standards
• Locks vs RBAC - protect the resource vs control the operator
• Tags are not security controls
• Defender for Cloud is not an IAM service
• Trust Center vs Service Trust Portal - overview vs evidence

Final memory map:

• Entra ID = identity
• MFA / Conditional Access = sign-in protection
• Azure RBAC = permissions for Azure resources
• Azure Policy = governance rules
• Locks = accidental change protection
• Tags = metadata for reporting and organization
• Defender for Cloud = posture and recommendations
• Purview / Priva = data governance and privacy operations
• Trust Center = public trust information
• Service Trust Portal = audit and compliance documents

If you keep those distinctions clear, most AZ-900 identity, governance, privacy, and compliance questions become much easier to answer.