AZ-900 Identity, Governance, Privacy, and Compliance Features: A Practical Beginner’s Guide

Introduction: Why Identity, Governance, Privacy, and Compliance Matter in Azure

For AZ-900, Azure is not just compute, storage, and networking.

It’s not just where you run apps and store data—it’s also where identity lives, where governance gets enforced, and where compliance starts to take shape.

One thing I’ve noticed when teaching AZ-900 is that people naturally start with the infrastructure side of Azure, so they’re often caught off guard when the exam suddenly starts asking about sign-in, access control, policy, privacy, and audit readiness. Honestly, that pivot can feel a bit jarring if you weren’t expecting Azure to go in that direction.

And, actually, that’s by design.

Microsoft wants you to understand that cloud success depends on control as much as capability.

The shared responsibility model is the foundation.

Microsoft secures the underlying cloud platform, but you’re still responsible for things like identities, data classification, access decisions, a lot of the configuration choices, and whether your workload actually lines up with the compliance requirements you care about.

Now here’s the thing: that responsibility changes depending on the service model.

In SaaS, Microsoft takes on more of the stack for you. In PaaS, you still have to handle things like data, identities, and application settings. In IaaS, you’re on the hook for even more—guest OS management, quite a few network controls, and a much larger share of the security work.

Azure can support compliance, but it does not automatically make a workload compliant.

The simplest mental model is this: identity controls who is asking, governance controls what is allowed, security helps protect the environment, and compliance helps prove that controls align with required standards and regulations. For AZ-900, you don’t need to go deep on implementation details, but you absolutely do need to understand how the major services fit together.

Identity Fundamentals and Microsoft Entra ID

Start with two core terms. Authentication verifies identity. Authorization determines what that identity is allowed to do.

If a user signs in with a password and MFA, that’s authentication.

If that user can only view a subscription because they were assigned Reader, that is authorization. Logging what happened belongs to auditing and monitoring.

Microsoft Entra ID, formerly Azure Active Directory, is Microsoft’s cloud identity and access management service. Many study resources still say “Azure AD,” so map the old and new names carefully.

A tenant is basically an organization’s dedicated Microsoft Entra directory instance.

Azure subscriptions trust that tenant for identity and access, and one tenant can be associated with multiple subscriptions.

Do not treat Microsoft Entra ID as cloud-hosted Active Directory Domain Services.

AD DS is the classic on-premises directory service. It’s the one built around domains, Kerberos, LDAP, Group Policy, and the old-school domain-join model that a lot of us worked with for years.

Microsoft Entra ID, on the other hand, is designed for modern cloud identity. It’s what you use for SaaS access, Conditional Access decisions, app sign-in, and all the cloud-first identity scenarios that keep coming up now.

In the real world, organizations often use both together in hybrid environments, especially when they’re transitioning from traditional on-premises systems to cloud identity.

Microsoft Entra ID stores and manages several identity types:

That last point matters: device-based decisions often depend on device management and compliance evaluation, commonly through Microsoft Intune or another integrated mobile device management solution. Now, here’s a really important distinction: a device being registered isn’t the same thing as it being compliant. Those are related, sure, but they’re not interchangeable.

Shared Responsibility Applied to Identity and Compliance

This is a frequent exam theme: Microsoft provides a trusted platform and evidence, but customers still own how they use it.

Authentication Methods, SSO, MFA, and Conditional Access

Single Sign-On (SSO) lets users sign in once and access multiple connected applications without repeatedly entering credentials.

And yes, SSO definitely makes life easier. If you’ve ever had to log into five different services before lunch, you already know why people love it. It also helps centralize identity control. But it doesn’t mean users’ll never be asked to sign in again, because session settings, app behavior, and security controls can still prompt for reauthentication.

Token lifetime, app behavior, session controls, and Conditional Access can still require reauthentication.

Multi-Factor Authentication (MFA) requires more than one factor, such as something you know plus something you have or are. It is one of the most effective defenses against password theft.

Passwordless authentication reduces reliance on passwords and can use methods such as Windows Hello for Business, FIDO2 security keys, or Microsoft Authenticator-based sign-in. At a fundamentals level, know that passwordless approaches are generally stronger and often more phishing-resistant than password-only sign-in.

Conditional Access is a Microsoft Entra capability that evaluates signals such as user or group, application, device state, location, and, with the right licensing and features, sign-in risk or user risk. It then applies controls such as requiring MFA, blocking access, or limiting access to compliant devices.

A simple Conditional Access pattern looks like this:

Assignments: All administrators
Cloud apps: Azure management
Conditions: Any location
Grant control: Require MFA

That is a good example of Zero Trust in practice: verify explicitly and apply least privilege.

Hybrid Identity and External Identities

Hybrid identity means an organization is using on-premises Active Directory alongside Microsoft Entra ID.

At a high level, synchronization copies or links identity information into the cloud, usually with Microsoft Entra Connect Sync or cloud sync.

Federation is a different concept: authentication can rely on an external identity provider. For AZ-900, you only need conceptual awareness.

External collaboration is also common.

Microsoft Entra External ID is what helps when people outside your organization still need access, but you don’t want to build a separate identity system just for them.

In a B2B collaboration scenario, for example, you might invite a partner or contractor as a guest. They can get to the apps or resources you’ve intentionally allowed, and nothing beyond that unless you decide otherwise.

In customer identity scenarios, you’ll still see older study material mention Azure AD B2C, but Microsoft’s current branding emphasizes Microsoft Entra External ID.

For exam purposes, focus on the scenario first. The naming can vary a bit across study materials, but the underlying concept stays the same.

Azure RBAC, Microsoft Entra ID Roles, and Privileged Access

Azure has multiple role systems, and this is a classic exam trap.

Azure Role-Based Access Control (Azure RBAC) controls access to Azure resources such as subscriptions, resource groups, virtual machines, and storage accounts.

A role assignment has three parts: who gets access, what role they get, and where that access applies. Once you can spot those three pieces, the whole model gets a lot easier to follow. Honestly, this is one of those areas where the simple version is the version you’ll use most often, both in the exam and in the real world.

For example, assigning the Reader role to a group at subscription scope gives that group view access across the subscription.

RBAC scopes follow the Azure hierarchy: management group, subscription, resource group, resource.

If you assign permissions at a parent scope, those permissions flow down to the child scopes automatically.

Effective permissions are additive, which means lower-scope assignments don’t simply override broader inherited permissions.

The effective result is generally the union of allowed permissions, with deny assignments as an exception mechanism. That is the precise way to think about RBAC inheritance.

Microsoft Entra ID roles, also called directory roles, control administration of the identity system itself.

Common examples include Global Administrator and User Administrator, which you’ll see a lot in identity-related discussions.

These do not automatically grant Azure resource permissions.

Use this memory cue:

For privileged access, know the concept of Privileged Identity Management (PIM).

It supports things like just-in-time elevation, time-limited activation, approval workflows, and access reviews.

The exam usually stays high level, but the key idea is that standing administrator access is riskier than temporary elevation when needed.

Governance Hierarchy and Design

The Azure hierarchy is:

Management groups → Subscriptions → Resource groups → Resources

Management groups help organize multiple subscriptions and are useful for broad policy or RBAC assignments.

Subscriptions matter because they’re used for billing, quota, and administrative separation. They’re also often where organizations draw the line for ownership or chargeback.

Resource groups are just logical containers for resources that usually share the same lifecycle, like an app, its database, and the networking pieces that support it.

Resources always exist inside a resource group, and that resource group exists within a single subscription.

A practical design might look like this: a company uses one management group for Production and one for Non-Production, separate subscriptions for business units, and resource groups for each application environment. Policy and RBAC can be assigned high in the hierarchy and inherited downward.

Azure Policy, Tags, and Resource Locks

Azure Policy evaluates resource properties and compliance state.

It’s about what configurations are allowed or required, not who is allowed to act.

At a high level, policy effects include deny, audit, append, modify, and deployIfNotExists. Policies can also be grouped into initiatives for broader compliance goals.

Common policy examples include requiring tags, restricting allowed regions, limiting SKUs, or auditing encryption settings. A policy can be assigned at management group, subscription, or resource group scope and inherited downward.

Tags are name-value pairs such as Environment=Prod or CostCenter=Finance.

They’re useful for organization, reporting, automation, and cost analysis.

One important practical nuance: tags do not automatically inherit from a resource group to all child resources. If you want consistent tagging, use Azure Policy or automation to enforce and remediate it.

Resource locks help prevent accidental deletion or modification.

Delete locks stop deletion, while Read-only locks stop both changes and deletion.

But locks apply to control-plane operations, not all data-plane activity.

For example, a lock on a storage account helps protect management operations on that account, but it doesn’t replace service-specific data protection, backup, soft delete, or access controls. In other words, it’s a guardrail, not a full security strategy.

Also, users with sufficient permissions may remove a lock first, so locks are guardrails, not absolute security boundaries.

A Read-only lock can also block some operations that seem harmless because certain Azure actions use control-plane POST operations behind the scenes. That surprises many beginners.

Advisor, Cost Management, and Cost Governance

Azure Advisor provides recommendations across cost, security, reliability, operational excellence, and performance. Think of it as best-practice guidance based on your environment.

Microsoft Cost Management helps analyze spending, create budgets, review forecasts, and report by scope, resource, or tag. A common governance workflow is: assign cost center tags, create a monthly budget for a subscription, configure budget alerts, and use cost analysis to identify which team or workload caused the increase.

Historical note: Azure Blueprints is deprecated. Modern governance strategy centers on Azure Policy, ARM or Bicep templates, Template Specs, deployment pipelines, and related policy-driven approaches.

Privacy, Compliance, and Trust Tools

Privacy concerns how personal data is collected, used, stored, and protected.

Compliance is about aligning with laws, regulations, standards, and internal policies. It’s the part that asks, ‘Are we meeting the rules we said we had to follow?’

Microsoft supports a wide range of compliance evidence, including regulations like GDPR, standards and certifications like ISO 27001, attestations and reports like SOC, and government programs like FedRAMP.

These are not all the same type of requirement, and exam questions may test that distinction indirectly.

Data residency and sovereignty also matter, but they depend on service, region, configuration, and customer design choices. Storing data in a region is important, but it is not the only legal or operational consideration.

A practical audit workflow often uses both Service Trust Portal and Compliance Manager together: the first provides Microsoft’s supporting documentation, while the second helps your organization track its own required actions.

Defender for Cloud, Secure Score, and Azure Monitor

Microsoft Defender for Cloud provides cloud security posture management and cloud workload protection.

At a high level, it helps identify weak configurations, exposed resources, missing hardening steps, and other security gaps that can affect your environment.sed management ports, missing hardening steps, and other security issues across cloud resources.

It also includes regulatory compliance views and supports multi-cloud scenarios.

Secure Score is best understood as a measure of security improvement opportunities.

Be aware that Microsoft uses score concepts in different product contexts.

For AZ-900, keep it simple: secure score helps prioritize recommended security improvements.

Azure Monitor collects and analyzes metrics, logs, and alerts from Azure resources, applications, virtual machines, guest operating systems, containers, and more. It supports observability and investigation. Important monitoring sources to recognize include Activity Log for subscription and resource administrative events, resource logs through diagnostic settings, and alerting based on metrics or logs.

Defender for Cloud tells you where your posture should improve. Azure Monitor helps you see what is happening operationally.

Troubleshooting Common Identity and Governance Problems

For identity investigations, remember that Microsoft Entra sign-in logs and audit logs are key sources. For Azure administrative actions, Activity Log is essential. Diagnostic settings can export logs to Log Analytics, storage, or security information and event management tools for longer-term analysis.

AZ-900 High-Probability Distinctions

Final Review

For AZ-900, the big picture matters more than memorizing every setting. Microsoft Entra ID handles cloud identity. Conditional Access shapes sign-in decisions. Azure RBAC controls access to Azure resources, while Microsoft Entra ID roles control the directory. Azure Policy enforces configuration standards. Resource locks reduce accidental damage. Management groups, subscriptions, and resource groups provide governance structure. Service Trust Portal, Compliance Manager, Purview, and Priva support trust, compliance, data governance, and privacy operations. Defender for Cloud and Azure Monitor provide security posture and operational visibility.

If you keep the service distinctions clear, most exam questions become much easier. Ask yourself: is this an identity problem, a permission problem, a configuration rule, accidental damage prevention, trust evidence, data governance, privacy operations, security posture, or monitoring? That single elimination strategy solves a large percentage of AZ-900 questions in this topic area.