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

Introduction

For AZ-900, what you really need is the ability to spot which Azure service fits which kind of control problem. Honestly, the easiest way I’ve found to make sense of it is to use a layered model: identity, access control, governance, and trust and compliance. Microsoft takes care of the underlying cloud platform, but customers still have to handle the day-to-day controls like configuring identities, assigning permissions, choosing regions, classifying data, and showing auditors that the controls are actually in place. That’s the shared responsibility model, right there in plain terms.

A simple way I like to think about Azure is this:

Identity → who is requesting access
Access control → what that identity can do
Governance → what resources are allowed and how they must be configured
Trust/compliance → how the environment supports privacy, audit, and regulatory expectations

In this article, I’m focusing on Microsoft Entra ID, Azure RBAC, Azure Policy, resource locks, tags, monitoring, and Microsoft’s trust and compliance services. The goal is not deep architecture design. It is to help you identify the right service when an exam question describes a business need.

Identity in Azure

The core cloud identity service in Azure is Microsoft Entra ID, formerly Azure Active Directory. Entra ID handles identity, authentication, token issuance, and Conditional Access context. Authorization to Azure resources is then enforced through Azure Resource Manager by Azure RBAC. That distinction matters: Entra ID proves and evaluates identity; RBAC determines allowed actions on Azure resources.

A common AZ-900 confusion is tenant vs subscription. A tenant is your organization’s identity boundary in Entra ID. A subscription is primarily a billing, quota, and resource management boundary in Azure. One tenant can contain multiple subscriptions.

Authentication answers, “Who are you?” Authorization answers, “What are you allowed to do?” A user signing in with a password, FIDO2 key, or MFA prompt is authentication. That same user being allowed to read a storage account but not delete it is authorization.

Entra ID supports several important identity object types:

The app registration and service principal distinction is worth learning early. The app registration is the application definition in Entra ID. The service principal is the actual security identity used in a tenant. Put simply, the app registration is the application’s definition, while the service principal is the identity it uses when it signs in.

Managed identities are especially important because they let Azure resources authenticate to other services without storing credentials in code or configuration. 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 reused across multiple resources. A very common example is an Azure VM or an App Service using a managed identity to retrieve a secret from Azure Key Vault.

Single sign-on, or SSO, makes life easier by letting users sign in once and then move across multiple applications without having to log in again and again. Multi-factor authentication, or MFA, strengthens authentication by asking for more than one proof of identity. MFA does not grant permissions. It doesn’t grant permissions by itself; it just gives you more confidence that the person signing in really is who they say they are.

Conditional Access is the policy engine that decides when access should be allowed, blocked, or require extra controls. It can evaluate signals such as user or group, cloud app, device state, location, and sign-in risk. Risk-based features depend on appropriate Entra licensing and identity protection capabilities, so not every tenant has the same feature set.

A practical Conditional Access example is: require MFA for administrators when accessing Azure management apps, exclude emergency break-glass accounts, and test in report-only mode before enforcement. Report-only mode is useful because it shows what would have happened without immediately locking people out.

Exam alert: MFA and Conditional Access are related but different. MFA is a verification method. Conditional Access is the decision engine that may require MFA.

Passwordless authentication reduces reliance on passwords. FIDO2 security keys are strongly phishing-resistant. Some phone-based methods improve usability and security too, but they are not all equally phishing-resistant. For exam purposes, remember that passwordless is a stronger modern authentication approach, especially for privileged users.

External collaboration is handled through Microsoft Entra External ID, including B2B collaboration scenarios. A partner can be invited as a guest user, then granted limited access to a specific app, team, or resource scope. That is far better than creating unmanaged local accounts. At fundamentals level, just separate B2B collaboration for partner access from consumer-facing identity scenarios such as B2C.

Hybrid identity connects on-premises Active Directory with Entra ID. A common approach uses Microsoft Entra Connect Sync. Depending on what the organization needs, it might use password hash synchronization, pass-through authentication, or federation. AZ-900 isn’t asking you to design a hybrid identity environment from scratch, but you should definitely know it exists, because plenty of organizations still run a mix of on-premises and cloud systems.

Zero Trust is a strategy, not just one product you buy and switch on. Its core ideas are pretty straightforward: verify explicitly, use only the least privilege you need, and assume breach. In Azure, you’ll see that approach reflected in things like MFA, Conditional Access, tightly scoped RBAC assignments, managed identities instead of embedded secrets, and monitoring for risky sign-ins and admin activity.

Azure RBAC and Governance Basics

Azure governance starts with hierarchy and scope. The main structure is management groups, subscriptions, resource groups, and resources. Assignments and policies can inherit down the hierarchy depending on the service behavior and scope of assignment.

Management Groups
└─ Subscriptions
  └─ Resource Groups
     └─ Resources

Resource groups are logical containers for related resources, but they are not strict regional boundaries. Resources in the same resource group can exist in different regions. A subscription is also an access and quota boundary, not just a billing container.

Azure RBAC is the main authorization system for Azure resources. A role assignment has three parts: a security principal, a role definition, and a scope. For example, you might assign the Contributor role to a developer group at the resource group scope.

Common built-in RBAC roles include:

Least privilege is the rule here. If a dev team only needs to manage resources in one nonproduction resource group, Contributor at that resource group is safer than Owner at subscription scope. Also note that Azure RBAC roles are different from Microsoft Entra roles. Entra roles govern directory-level tasks like managing users; Azure RBAC governs Azure resource actions.

There are also deny assignments in some Azure scenarios. These are distinct from normal RBAC role assignments and can block actions even when a user has otherwise broad permissions. For AZ-900, just know that not every access outcome is explained only by “which role was assigned.”

Azure Policy, Locks, and Tags

Where RBAC answers “who can act,” Azure Policy answers “what is allowed.” Policy evaluates resources against organizational standards. A policy definition contains the rule. An assignment applies it at a scope. An initiative groups multiple policies together. Parameters let you reuse a policy with different values, such as approved regions.

Important Azure Policy effects include deny, audit, append, modify, deployIfNotExists, auditIfNotExists, and disabled. At the fundamentals level, here’s the simple way to think about them:

deny blocks noncompliant deployments
audit reports noncompliance
append adds fields to incoming requests in supported cases
modify can change or remediate some properties, often tags
deployIfNotExists can deploy a related configuration when missing

A classic example is an allowed locations policy that restricts deployment to East US and West Europe. Another common one requires tags such as Owner, Environment, or CostCenter. Policy can also be used to audit insecure settings or limit resource types and SKUs.

Tags are name/value pairs used for organization and reporting, such as Environment=Production or CostCenter=CC104. Tags are not a security control by themselves. They help with cost management, ownership, and classification. They also do not automatically inherit to every child resource in every scenario unless enforced through policy or automation.

Resource locks protect against accidental changes. A Delete lock prevents deletion. A Read-only lock blocks management-plane operations that require POST, PUT, or DELETE, which can also break portal actions that look read-like. Locks apply to management plane operations, not all data plane operations. They can also override many administrative actions even when RBAC permissions would otherwise allow them, until an authorized user removes the lock.

Modern governance note: Azure Blueprints has been deprecated. If you come across it in older material, just treat it as historical context. For current governance thinking, I’d focus on management groups, Azure Policy, ARM or Bicep, Template Specs, and deployment stacks.

Monitoring, Auditing, Privacy, and Compliance Basics

Privacy is really about handling personal data responsibly. Compliance is about meeting the legal, regulatory, and organizational requirements that apply to the business. Azure can absolutely support those goals, but it doesn’t make a customer compliant automatically.

A practical shared responsibility view looks like this:

For trust and audit evidence, the Service Trust Portal provides Microsoft compliance documentation, audit reports, privacy information, and related trust resources. It is commonly used during vendor reviews and audit preparation to review Microsoft’s published compliance and assurance materials.

Microsoft Purview focuses on data governance, classification, and retention. Think discovery of sensitive data, labeling, and governance over how data should be handled. Microsoft Priva focuses more on privacy operations and privacy risk management, including subject-rights-oriented workflows.

Microsoft Defender for Cloud is broader than a simple compliance dashboard. It gives you security posture management, secure score, recommendations, regulatory compliance views, and, depending on the plan, optional workload protection capabilities. It works alongside Azure Policy rather than replacing it. Policy enforces standards, while Defender for Cloud helps surface posture gaps and recommendations.

Auditing and monitoring matter because you cannot investigate or prove control without logs. Key services to know are:

Azure Activity Log for subscription-level control plane events such as create, update, delete, and policy actions
Azure Monitor for metrics, alerts, and operational visibility
Log Analytics for querying collected log data
Entra sign-in logs and audit logs for identity events and directory changes
Resource logs/diagnostic settings for service-level events

If a storage account was deleted, Activity Log helps show who initiated the management-plane operation. If a sign-in gets blocked, Entra sign-in logs can help you figure out whether Conditional Access or some kind of risk-based control was involved.

Data residency is about where data lives geographically. Data sovereignty adds the legal and jurisdictional side of the story. A multinational company may need workloads to stay in approved regions because of contractual or regulatory obligations. That is where region selection, Azure Policy, and compliance review all meet.

Real-World Scenarios, Troubleshooting, and Exam Prep Tips

Here is the exam mindset: identify the actual problem first.

If the question asks about sign-in strength or risky access, think MFA or Conditional Access.
If it asks who can manage a resource, think Azure RBAC.
If it asks what can be deployed, think Azure Policy.
If it asks how to prevent accidental deletion, think resource locks.
If it asks how to organize by owner or cost center, think tags.
If it asks for Microsoft audit reports, think Service Trust Portal.
If it asks about data classification or retention, think Purview.

A few quick troubleshooting patterns usually help narrow things down:

User can sign in but cannot manage a resource → likely RBAC role or scope issue.
Deployment works in one region but fails in another → likely Azure Policy.
User has Contributor but still cannot delete → likely a resource lock.
Guest user exists but access is denied → check RBAC assignment scope and Conditional Access.
Required tags are missing → check policy assignment, effect, and remediation status.

Simple hands-on practice helps retention. Create a test resource group, assign Reader to one user at subscription scope and Contributor to another at resource group scope, then compare inherited access. Next, assign an allowed locations policy and attempt a blocked deployment. Finally, apply a delete lock to a test storage account and confirm deletion fails. Those three exercises make most of this article feel concrete.

Conclusion

For AZ-900, remember the control map. Microsoft Entra ID handles identity and sign-in context. Azure RBAC handles permissions on Azure resources. Azure Policy, locks, tags, and management scopes handle governance. Service Trust Portal, Purview, Priva, Defender for Cloud, and monitoring logs support trust, privacy, compliance, and visibility.

If you keep those boundaries straight, most AZ-900 questions become much easier. The exam is not testing whether you can build everything from scratch. It is testing whether you know which Azure service exists for which problem.