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

When I teach Azure Fundamentals, this is usually the point where people start realizing the cloud isn’t just “someone else’s datacenter” anymore. It’s where you actually begin to see how control works in practice. Identity, governance, privacy, and compliance can sound like four separate topics at first, but in Azure they’re usually all connected behind the scenes. Identity determines who is asking. Governance determines what structure and rules exist. Privacy determines how data should be handled. Compliance determines how you prove your environment meets requirements.

For AZ-900, you don’t need to become a full-blown architect or auditor. What you do need is a solid feel for what each Azure feature does, the problem it solves, and the places where beginners usually get crossed up. The four anchors are simple:

• Identity = who is requesting access
• Governance = how Azure resources are organized and controlled
• Privacy = how personal and sensitive data is handled
• Compliance = how organizations meet legal, regulatory, and internal requirements

Identity: The Control Point for Modern Cloud Access

In cloud computing, identity is the first gate. Azure does not grant access just because a user is “inside the network.” Access depends on configured controls tied to identities, devices, applications, and policies. That’s why you’ll hear people say identity has become the new security perimeter in the cloud.

Here’s a simple way I usually explain the basics:

• Authentication = proving who you are
• Authorization = determining what you can do
• Auditing/accounting = recording what happened

A user can sign in successfully and still get blocked from a resource. That is normal in Azure. Signing in and having permission are two totally different things.

Microsoft Entra ID: Cloud Identity and Access Management

Microsoft Entra ID, formerly Azure Active Directory, is Microsoft’s cloud identity and access management service used across Azure, Microsoft 365, Dynamics 365, and many integrated SaaS applications. It is not just for Azure resources.

At AZ-900 level, think of an Entra tenant as the identity boundary for an organization. Inside that tenant, you manage identities and access-related objects such as:

• Users = human identities
• Groups = collections used to simplify assignment and administration
• Guest users = external users invited for collaboration, often through B2B scenarios
• Applications/app registrations = identity definitions for apps that need to authenticate
• Service principals = the security identities created from applications and used in a tenant
• Managed identities = Azure-managed identities for Azure resources, preferred over storing secrets in code
• Devices = registered or joined devices used in identity and access decisions

The app registration versus service principal distinction trips people up. The easiest way to think about it is that the app registration is the app’s identity blueprint, while the service principal is the working copy of that identity inside a specific tenant. For AZ-900, just recognize that both exist and support application authentication.

Managed identities matter because they let Azure-hosted workloads authenticate to services like Key Vault or Storage without developers having to hardcode credentials into scripts or app settings. Azure takes care of the credential lifecycle, and honestly, that’s both safer and a whole lot easier to manage.

Hybrid identity is also common. Many organizations synchronize identities from on-premises Active Directory to Entra ID using Microsoft Entra Connect or Cloud Sync. Federation is one possible model in identity design, but it is not the same thing as hybrid identity overall. More precisely, federation means one system trusts an external identity provider or security token service to authenticate users and issue claims.

External identities usually refer to scenarios such as partner or consultant access. A guest user can be invited into Entra ID, controlled with Conditional Access, and given Azure RBAC access at a limited scope instead of being handed a full internal account.

Common Authentication Features: SSO, MFA, and Conditional Access

Three terms show up constantly in Azure Fundamentals: single sign-on, multi-factor authentication, and Conditional Access.

Conditional Access can use signals such as user or group membership, application, device state, location, sign-in risk, and user risk. Based on those signals, it can block access or require controls such as MFA, compliant device, or password change. Technically, it evaluates after primary authentication and influences token issuance or access, so it is more accurate than saying it simply “stops the password prompt.”

MFA is honestly one of the best basic controls you can put in place because it cuts the risk of password compromise way down. That said, it’s not a perfect phishing defense unless you’re using stronger methods like phishing-resistant MFA. For AZ-900, the main thing to remember is pretty simple: MFA makes authentication stronger, while Conditional Access is the policy engine that can demand it.

For example, imagine an administrator trying to sign in from an unmanaged device while they’re in a risky location. Entra ID verifies the account, Conditional Access evaluates the rules, and Azure can then require MFA, demand a compliant device, or block access altogether depending on the policy in place.

Zero Trust, Least Privilege, and Privileged Access Basics

Microsoft frames Zero Trust around three core ideas: verify explicitly, use least privilege access, and assume breach. For someone learning the fundamentals, that means Azure shouldn’t trust a request just because it came from a familiar network or because the user signed in earlier that day.

Least privilege means users, admins, and workloads should only be given the access they actually need, and nothing more. In real life, that usually looks like this:

• Giving someone the Reader role instead of Contributor when all they need is read-only access
• Scoping access to one resource group instead of an entire subscription
• Using managed identities for workloads instead of shared credentials
• Reviewing access periodically instead of letting permissions accumulate forever

If you see Privileged Identity Management (PIM) in broader Microsoft security discussions, know that it supports just-in-time and governed privileged access. It comes up more in higher-level exams, but it fits the least-privilege story so well that it’s absolutely worth recognizing by name.

How Access Is Evaluated in Azure

A good mental model is this sequence:

1. User or workload signs in through Microsoft Entra ID
2. Authentication succeeds or fails
3. Conditional Access evaluates policy signals and grant/block requirements
4. A token is issued if access conditions are satisfied
5. When the identity tries to manage an Azure resource, Azure RBAC evaluates permissions at the relevant scope
6. During deployment or configuration changes, Azure Policy may allow, deny, audit, or modify based on rules
7. Resource locks may still block management-plane changes such as delete or update

That sequence explains a lot of common confusion. A user may sign in successfully, have RBAC permission to create a VM, and still fail because Policy denies the selected region. Another user may have Contributor rights and still be unable to delete a production resource because a lock blocks the operation.

Azure Resource Hierarchy and Scope

Azure governance depends heavily on scope. The main hierarchy is:

• Management groups = organize multiple subscriptions
• Subscriptions = billing, management, quota, and isolation boundaries
• Resource groups = logical containers within a single subscription
• Resources = actual services such as VMs, storage accounts, and databases

Management groups are used when governance must scale across many subscriptions. Subscriptions are bigger boundaries for billing, service limits, and delegated administration. Resource groups are logical containers for resources that usually share a lifecycle or management context, but that doesn’t mean every part of an application has to sit in the same one. That’s a common design pattern, not some hard-and-fast rule.

One really important detail: a resource group belongs to just one subscription. Resources inside that group can still depend on things elsewhere, but the group itself doesn’t stretch across subscriptions.

Inheritance matters. Azure RBAC and Azure Policy assignments can be made at management group, subscription, resource group, or resource scope, and they flow downward. If you assign Reader at subscription scope, that read access applies to resource groups and resources inside that subscription unless something more specific changes the situation.

Azure RBAC: Who Can Do What

Azure Role-Based Access Control is Azure’s authorization system for Azure resources. The basic model is:

• Security principal = who gets access: user, group, service principal, or managed identity
• Role definition = what actions are allowed
• Scope = where that role applies

The built-in roles most often tested in AZ-900 are:

• Owner = full access, including managing access
• Contributor = can manage resources, but cannot grant access
• Reader = read-only access

Custom roles also exist, but awareness is enough for this exam.

A small but important distinction: Azure RBAC roles are not the same as Microsoft Entra roles. Azure RBAC roles control access to Azure resources and what actions you’re allowed to take with them. Entra roles, such as Global Administrator, are directory roles for managing identity services and tenant-level functions. Beginners mix these up constantly.

Example:

• A user with Global Administrator is powerful in the identity directory, but that does not automatically mean they are Contributor on every Azure subscription.
• A user with Reader on a subscription can view Azure resources there, but that does not make them an Entra administrator.

There are also advanced concepts such as deny assignments, but AZ-900 mainly expects you to understand role assignments and scope.

Management Plane vs Data Plane

This distinction improves a lot of Azure confusion.

Management plane operations are actions against Azure resource management, such as creating a storage account, changing its settings, or deleting it. Azure RBAC commonly controls these actions.

Data plane operations are actions against the data inside a service, such as reading blobs in a storage account or retrieving a secret from Key Vault. These may use service-specific permissions or data-plane roles.

Why this matters:

• A resource lock applies to management-plane operations, not directly to data-plane access.
• A user may be able to view a storage account resource in Azure Portal but still be unable to read blob data.
• Reader on a resource does not automatically mean read access to the underlying business data.

Azure Policy, Locks, and Tags: Governance Controls

If Azure RBAC answers “who can act,” Azure Policy answers “what is allowed or required.” That is the exam distinction you really want to remember.

Azure Policy includes:

• Definitions = the rules
• Assignments = where those rules apply
• Initiatives = grouped policy sets
• Compliance evaluation = checking whether resources meet the rules
• Remediation = fixing some existing noncompliance in supported scenarios

Policy can govern new deployments and assess existing resources. Common effects include:

• Deny = block noncompliant changes
• Audit = flag noncompliance without blocking
• Append = add information in some scenarios
• Modify = adjust properties in supported cases
• DeployIfNotExists = deploy supporting configuration if missing in supported scenarios

A practical example is an initiative that requires CostCenter and Environment tags and limits deployments to approved regions. A developer may have Contributor on a resource group, but if they try to deploy into an unapproved region, Policy can deny the request. RBAC allowed the attempt; Policy rejected the configuration.

Policy can help enforce naming conventions in some scenarios, but not all resource types support identical policy behavior. That is why “Policy enforces all naming everywhere” is too broad.

Resource locks are different again. They are not permission assignments or standards rules. They protect resources from certain management-plane operations:

• CanNotDelete = resource can be modified but not deleted
• ReadOnly = resource cannot be modified or deleted

Locks can override what an authorized user could otherwise do on the management plane until the lock is removed by an authorized principal. A ReadOnly lock can also block operations that seem harmless if they require a management-plane write or POST action.

Tags are name/value metadata pairs used for organization, cost reporting, automation, and ownership tracking. They’re not permissions, not encryption, and definitely not a place to store secrets or sensitive personal data. Tags also don’t automatically flow down from a resource group to every resource in the general case, so if you want consistent tagging, you usually need Policy or some kind of automation.

Governance at Scale and Design Patterns

When an organization grows, governance design matters as much as individual controls. Two common patterns are:

• Department-based subscriptions such as Finance, HR, and Sales
• Environment-based subscriptions such as Production and NonProduction

Management groups sit above those subscriptions so policy and RBAC patterns can be inherited consistently. This is one reason they are important in enterprise Azure environments.

A typical model might look like this:

• Root management group
• Production management group
• NonProduction management group
• Separate subscriptions under each for business units or major workloads

That structure supports cost separation, quota boundaries, delegated administration, and policy inheritance. It also works well with landing zone thinking, where organizations standardize networking, identity, policy, logging, and security baselines before application teams deploy workloads.

Monitoring, Logging, and Auditability

Security and compliance are weak if nothing is recorded. Azure governance depends on visibility.

• Azure Activity Log records management-plane actions on Azure resources
• Resource logs/diagnostic settings capture service-specific operational and security events
• Log Analytics provides centralized analysis for collected logs
• Sign-in logs and audit logs in Entra ID help diagnose access issues and administrative changes

If an auditor asks who changed a policy assignment, if a security team needs to investigate a suspicious sign-in, or if operations wants proof that logging is enabled, these records become essential evidence.

Security and Compliance Tools You Should Recognize

Defender for Cloud and Sentinel are especially easy to confuse. Defender for Cloud helps with posture and protection recommendations; Sentinel is for SIEM/SOAR operations and incident handling across Azure, Microsoft 365, on-premises, and third-party data sources.

Privacy in Azure

Privacy is about proper handling of personal data and sensitive information. In practice, that includes who can access it, where it is stored, how long it is retained, how it is protected, and whether its use is lawful and appropriate.

Useful distinctions:

• Data privacy = appropriate handling and protection of personal data
• Data residency = the geographic location where data is stored
• Data sovereignty = the legal and jurisdictional control that applies to data

Azure supports privacy goals through controls such as encryption in transit and at rest, identity-based access control, logging, classification, retention policies, and regional deployment choices. But Azure does not decide what data you should collect or whether your business process is lawful. That remains a customer responsibility.

A simple example: a healthcare application stores patient contact information in Azure SQL Database. Azure can provide encryption, identity controls, logging, and regional hosting options. The customer still must decide who can access the data, how long it should be retained, whether it is masked in lower environments, and whether the application meets privacy obligations.

Microsoft provides formal privacy commitments through its published privacy statements and contractual data protection terms for products and services. These materials help customers understand Microsoft’s platform commitments, but they do not replace customer-side governance.

Compliance in Azure

Compliance means meeting required standards, laws, regulations, contracts, and internal policies. Examples people commonly hear include ISO 27001, SOC reports, GDPR-related obligations, and healthcare or financial regulations.

Azure supports compliance by providing certifications, attestations, audit reports, security features, logging capabilities, and governance tools. But this is the critical point: Azure being compliant as a platform does not automatically make your workload compliant.

Consider a regulated financial application. Microsoft may provide a certified cloud platform, encryption capabilities, logging services, and compliance documentation. The customer still must configure access control, retention, monitoring, incident response, data classification, backup handling, and policy enforcement. That is shared responsibility in action.

Compliance is operationalized through a mix of platform evidence and customer evidence:

• Microsoft evidence from certifications and audit reports
• Customer evidence from logs, policies, access reviews, architecture choices, and operational procedures

Service Trust Portal and Trust Resources

The Service Trust Portal is the place to recognize for Microsoft trust and compliance documentation. It contains audit reports, certifications, compliance guides, whitepapers, and privacy resources. Access to some documents may require the right sign-in context or agreements.

In real life, vendor risk teams, auditors, legal teams, and compliance staff use it when they need Microsoft’s side of the evidence story. It supports customer assessments, but it does not replace customer-side audit preparation or control implementation.

If the question is “Where do I find Microsoft’s compliance documentation?” the answer is usually the Service Trust Portal.

Shared Responsibility for This Entire Domain

Practical Scenarios That Tie It Together

Guest consultant needs temporary read-only access to one project.
Invite as a guest user in Entra ID, require MFA with Conditional Access, and assign Reader at one resource group scope.

Developer can deploy resources but not in certain regions.
That is Azure RBAC plus Azure Policy working together. Permission exists, but policy restricts allowed configuration.

Production database cannot be deleted even by a Contributor.
A CanNotDelete lock is likely applied at the resource or inherited from a higher scope.

Application running in Azure needs a secret from Key Vault.
Use a managed identity instead of storing credentials in code or configuration files.

Auditor asks for Microsoft certification evidence and your own control evidence.
Use the Service Trust Portal for Microsoft documentation and your own logs, policy compliance reports, and procedures for customer evidence.

Troubleshooting and Diagnostic Shortcuts

Sign-in is blocked: check account state, MFA requirements, Conditional Access, location/device conditions, and Entra sign-in logs.

Deployment is denied: check Azure Policy compliance details, allowed locations, required tags, quotas, and region restrictions.

User can read but not modify: check RBAC role, scope inheritance, and whether a lock is present.

User can manage a storage account but cannot access blob data: check data-plane permissions, not just management-plane RBAC.

Resource cannot be deleted: check for CanNotDelete or ReadOnly locks at the resource, resource group, or subscription scope.

Compliance dashboard shows noncompliant: check policy assignments, initiative membership, existing resources, and whether remediation has been run where supported.

High-Priority Exam Traps

• Authentication vs authorization: prove identity vs determine permissions
• Entra ID vs Azure RBAC: identity service vs Azure resource permissions
• Azure RBAC vs Azure Policy: who can act vs what is allowed
• Policy vs locks: standards enforcement vs blocking management-plane changes
• MFA vs Conditional Access: authentication method vs policy engine
• Subscription vs resource group: broad boundary vs logical container inside a subscription
• Tags vs security: metadata only, not access control
• Defender for Cloud vs Sentinel: posture/protection vs SIEM/SOAR
• Privacy vs compliance: proper data handling vs meeting formal requirements
• Service Trust Portal vs admin tools: documentation source, not configuration plane

AZ-900 Style Practice Questions

1. A company wants to give an auditor read-only access to all resources in one subscription. Which feature fits best?
Answer: Azure RBAC with the Reader role. This is about permissions.

2. A developer has Contributor on a resource group but cannot deploy a VM in a specific region. What is the most likely reason?
Answer: Azure Policy. The user has permission, but the configuration is not allowed.

3. A company wants to require an extra verification step for administrator sign-ins. Which feature is most directly involved?
Answer: MFA. Conditional Access may enforce it, but MFA is the extra verification method.

4. A company wants to block access unless a device is compliant and the user passes MFA. Which feature is used to evaluate those conditions?
Answer: Conditional Access.

5. A company wants to organize many subscriptions under a common governance structure. What should it use?
Answer: Management groups.

6. A team wants all new resources to include CostCenter and Environment metadata. Which Azure feature should enforce that?
Answer: Azure Policy.

7. A user has permission to delete a VM but the delete operation fails because the VM is protected. What is the likely cause?
Answer: A resource lock.

8. Which service provides Microsoft audit reports and compliance documentation?
Answer: Service Trust Portal.

9. Which service is best known for cloud security posture management and workload protection?
Answer: Microsoft Defender for Cloud.

10. Which service is a cloud-native SIEM and SOAR platform?
Answer: Microsoft Sentinel.

11. A web app in Azure needs to access Key Vault without storing credentials in code. What should be used?
Answer: Managed identity.

12. Does Azure certification automatically make a customer workload compliant?
Answer: No. Compliance remains a shared responsibility.

Final Cram Summary

• Microsoft Entra ID = identity and sign-in
• Azure RBAC = who can do what on Azure resources
• Azure Policy = what configurations are allowed or required
• Resource locks = block certain management-plane changes
• Tags = metadata for organization and reporting
• Management groups = organize subscriptions at scale
• Service Trust Portal = Microsoft trust and compliance documents
• Defender for Cloud = security posture and workload protection
• Sentinel = SIEM/SOAR
• Purview = data governance and compliance capabilities

If you want the shortest possible exam rule set, it is this: sign in with Entra ID, authorize with RBAC, restrict with Policy, protect with locks, label with tags, organize with management groups, and prove trust with the Service Trust Portal plus your own evidence.

That is not just an AZ-900 answer pattern. It is how real Azure environments stay secure, organized, auditable, and defensible.