AZ-900 Guide: Identity, Governance, Privacy, and Compliance Features in Microsoft Azure

When I teach AZ-900, I keep seeing the same thing: people naturally drift toward virtual machines, storage, and web apps first. And honestly, that makes perfect sense. They’re the parts of Azure you can see and touch right away. But in the real world, the stuff that actually keeps Azure usable, secure, and ready for an audit is usually identity, governance, privacy, and compliance.

That’s exactly why this topic matters so much in Microsoft Azure Fundamentals. The exam isn’t asking you to design a full enterprise landing zone, but it absolutely does expect you to know what each control is for, where it fits, and how the terms differ. If you can clearly separate authentication from authorization, Azure RBAC from Azure Policy, privacy from security, and governance from compliance, you’re already in really good shape.

1. Why these concepts matter in Azure

In cloud computing, security is a lot bigger than just firewalls and network settings. It really starts with identity, then moves into access control, and gets strengthened by governance rules, monitoring, and how data’s handled.

• Identity = who or what is requesting access.
• Authentication = proving that identity.
• Authorization = deciding what that identity can do.
• Governance = organizing and controlling the environment.
• Privacy = handling personal or sensitive data appropriately.
• Compliance = meeting and proving required standards or obligations.

One common beginner mistake is thinking that if Azure is secure, then every workload you put into Azure is automatically private and compliant. That is not how cloud works. Microsoft secures the platform itself, but customers still have to configure identities, permissions, regions, retention, encryption, and workload settings. You’ll see that shared responsibility model come up again and again in AZ-900.

2. Identity fundamentals and Microsoft Entra ID

In Azure, identity goes way beyond just a person typing in a password. In the cloud, identity isn’t just about people. An app, a service, or even a device can have its own identity too. In Microsoft cloud, the central identity and access management service is Microsoft Entra ID, formerly called Azure Active Directory. You’ll still run into the older Azure AD name in older docs, portal screens, and even exam questions, so it’s absolutely worth knowing both names.

Microsoft Entra ID is Microsoft’s cloud-based identity and access management service. It’s not the same thing as on-premises Active Directory Domain Services, although it can integrate with on-premises directories and even third-party identity providers.

The core distinction to remember is simple:

Authentication answers “Who are you?” Authorization answers “What are you allowed to do?”

A Microsoft Entra ID tenant is a dedicated instance of Entra ID for an organization. It contains directory objects like users, groups, applications, service principals, and devices. An organization can have one tenant or several, depending on how it’s designed and what the business needs.

Useful identity object examples for AZ-900:

• Users: employees, administrators, contractors.
• Groups: collections of users or devices used to simplify access management.
• Applications: app registrations representing software that integrates with identity.
• Service principals: the security identities used by applications in a tenant.
• Managed identities: Azure-managed identities for resources, preferred over storing credentials in code.
• Devices: registered or joined endpoints used in access decisions.
• Guest users: external users invited into a tenant for collaboration, often called B2B access.

Managed identities are especially worth recognizing. If an Azure app needs to talk to another Azure service, like a secret store, I’d much rather use a managed identity than hard-code a username, password, or secret into the app. Honestly, it’s a cleaner and safer approach, and it saves you from a lot of unnecessary credential headaches later. For fundamentals, just remember: managed identities reduce credential management risk.

Another important exam distinction is this:

• Microsoft Entra ID = identity service
• Azure subscription = billing and resource management boundary
• Resource group = logical container for related resources

A single tenant can be connected to multiple subscriptions, and that’s very common in real environments. Authentication happens in the tenant, because that’s where identity lives. Authorization for Azure resources usually comes from Azure RBAC, and that kicks in at the management group, subscription, resource group, or individual resource scope.

3. How people sign in: authentication methods, SSO, and Conditional Access

Passwords are still everywhere, but by themselves, they just aren’t strong enough anymore. A password only proves that someone knows a credential; it doesn’t prove that you can fully trust the sign-in. That is why Azure environments often use stronger sign-in controls.

Common authentication methods and related features include:

• Password: familiar but weak on its own.
• Multi-factor authentication (MFA): requires an additional factor such as Microsoft Authenticator approval, one-time passcode, FIDO2 security key, or biometric/passwordless method.
• Passwordless authentication: methods such as Windows Hello for Business, FIDO2 security keys, or Microsoft Authenticator sign-in.
• Single Sign-On (SSO): sign in once and access multiple applications.
• Self-service password reset (SSPR): allows users to reset passwords with less help desk involvement.

SSO isn’t the same thing as federation. Federation is one trust model that can enable cross-system sign-in, but SSO can also exist within a single centralized identity system. At a high level, SSO is what the user experiences, while federation is one way the underlying trust between systems can be set up.

Conditional Access adds context to sign-in decisions. It checks things like who the user is, what group they’re in, which app they’re trying to access, what device they’re using, where they’re signing in from, and whether anything about the sign-in looks risky. Then it decides whether to allow access, block the sign-in, or require MFA before letting the user in. Now, some of the risk-based features do depend on licensing and Microsoft Entra ID Protection, but for AZ-900, you really just need the main idea: Conditional Access makes access decisions smarter by using context instead of treating every sign-in like it’s identical.

A safe rollout concept worth knowing is report-only mode. Organizations often test Conditional Access policies before fully enforcing them, because a badly designed policy can lock out administrators. Real environments also use exclusions and emergency access, sometimes called break-glass accounts, to avoid total lockout.

Zero Trust fits naturally here. The shorthand is “never trust, always verify,” but the fuller idea is to verify explicitly, use least-privileged access, and assume breach.

4. Azure scope, hierarchy, and inheritance

Azure governance depends heavily on scope. The hierarchy is:

• Management groups
• Subscriptions
• Resource groups
• Resources

Management groups become really handy in larger organizations that have lots of subscriptions to keep under control. They let teams apply governance controls consistently across departments, environments, or even different regions, which is a big reason larger organizations rely on them.

The key idea is inheritance. When you assign something at a higher scope, it usually trickles down to the lower scopes too, unless something is specifically blocking it.

Examples:

• So if you assign the Reader role at the subscription scope, that access usually applies to the resource groups and resources underneath that subscription too.
• If you apply an Azure Policy at the management group level to block deployments outside approved regions, every subscription under that management group inherits that rule as well.

A pretty typical enterprise setup often ends up looking something like this:

• Top management group: company-wide standards
• Child management groups: Production, NonProduction
• Subscriptions under each: Finance, HR, Engineering
• Resource groups inside subscriptions: app-specific or environment-specific containers

This is the kind of structure that makes large Azure estates manageable.

5. Azure RBAC, Entra roles, Policy, and locks

This is one of the most useful AZ-900 topics, because people mix up tools that actually solve very different problems all the time, and that confusion can really trip you up on the exam.

Azure Role-Based Access Control (Azure RBAC) controls who can do what to Azure resources. Role assignments are made at a scope and inherited downward.

Common built-in roles include:

• Reader: view resources only
• Contributor: create and manage resources, but does not assign roles unless separately granted
• Owner: full access to resources and can manage access
• User Access Administrator: manage user access to Azure resources

Do not confuse Azure RBAC with Microsoft Entra roles. Azure RBAC applies to Azure resources and resource scopes. Entra roles apply to directory-level administration.

Azure Policy controls what is allowed or required. It evaluates resource properties for compliance and can support governance and security guardrails. Common effects include Deny, Audit, Append, Modify, and DeployIfNotExists. For AZ-900, you do not need to author policy JSON, but you should know the purpose.

Policy initiatives are grouped collections of policies. They are useful when an organization wants to apply a broader standard, such as a set of required tags, region restrictions, and security settings together.

Resource locks protect resources from accidental change. The Azure lock names are:

• CanNotDelete: prevents deletion
• ReadOnly: prevents changes and deletion

Locks can block actions even when RBAC permissions exist. They also inherit from higher scopes, which is useful but can surprise administrators and automation scripts.

One more practical note: tags help with organization and cost reporting, but tags do not automatically inherit from resource groups to all resources in every case. Many beginners assume they do. Policy can help enforce or add tagging standards more consistently.

6. Practical implementation examples

RBAC example: assign the Reader role to an auditor group at the resource group scope. Result: auditors can inspect resources but cannot modify them. Common mistake: assigning access at subscription scope when only one application resource group was intended.

Policy example: assign a policy at subscription scope that denies deployments outside approved regions. If a user with Contributor access tries to deploy in a blocked region, the deployment fails because policy is about allowed behavior, not user permission.

Lock example: apply a CanNotDelete lock to a production storage account. Even an authorized admin may be blocked from deleting it until the lock is removed.

These three examples are enough to anchor the exam logic:

• Can sign in but cannot manage resource = likely RBAC issue
• Has access but deployment is blocked = likely Policy issue
• Has access but cannot delete = likely lock issue

7. Microsoft Defender for Cloud, Sentinel, and security posture

Microsoft Defender for Cloud provides cloud security posture management and workload protection capabilities. For AZ-900, focus on these ideas:

• It gives recommendations to improve security posture.
• It contributes to secure score, which is a high-level measure of security improvement opportunities.
• Recommendations can relate to identity, networking, compute, storage, and other areas.
• It can also provide workload protection capabilities, not just posture visibility.

A simple example: Defender for Cloud may recommend enabling MFA, closing exposed management ports, or hardening storage settings. A security team can prioritize those findings and improve secure score over time.

Do not confuse Defender for Cloud with Microsoft Sentinel. Sentinel is Microsoft’s SIEM/SOAR platform for collecting, correlating, and analyzing security events and supporting incident response workflows. Defender for Cloud is about posture and protection; Sentinel is about security operations and analytics.

8. Privacy, data protection, and shared responsibility are all connected, but they’re not the same thing.

Security and privacy overlap quite a bit, but they’re definitely not the same thing.

• Security protects systems and data from unauthorized access or damage.
• Privacy governs how personal or sensitive data is collected, used, shared, retained, and protected.

Data protection in Azure commonly includes:

• Access control
• Encryption at rest
• Encryption while data is moving
• Backup and recovery planning
• Data classification and labeling
• Retention and deletion controls
• Logging and auditing access to data

The shared responsibility model is essential. Microsoft is responsible for the security of the cloud, while customers are responsible for security in the cloud. The exact split changes by service model.

So yes, Azure can absolutely support strong security and compliance, but customers still have to make the right choices around regions, permissions, data classification, and workload protection. Azure gives you the tools, but you still have to configure and use them correctly.ll have to use them well.

Data residency simply means where the data is stored geographically, which is a lot more important than people sometimes realize. Data sovereignty goes one step further than that. It’s about which legal authority and governance requirements apply to that data. And in regulated industries, those distinctions really do matter.

9. Compliance, the Service Trust Portal, and Microsoft Purview each play a different role here.

Compliance means meeting standards, regulations, or internal requirements, and being able to show that you did. Azure supports a lot of compliance programs, but compliance still isn’t automatic.liance can still vary by service and by region. Customers still need to verify whether the exact Azure services and regions they plan to use are actually in scope for the standard they care about.

Common compliance names to recognize:

• GDPR: privacy and personal data obligations in the European context
• ISO 27001: information security management standard
• SOC 1, SOC 2, SOC 3: assurance reports about controls
• HIPAA: U.S. healthcare data protection requirements related to protected health information

The Microsoft Service Trust Portal is the primary place customers use to access audit reports, compliance documentation, attestations, and trust-related information. During an audit or vendor review, an organization might retrieve Microsoft compliance artifacts there to support its evidence collection.

Microsoft Purview is Microsoft’s broader family of data governance, risk, and compliance capabilities. At a high level, Purview includes concepts such as:

• Information protection and sensitivity labeling
• Data lifecycle and retention
• Data loss prevention (DLP)
• eDiscovery and compliance investigation support
• Data governance and classification

Exam-safe summary:

• Need compliance reports? Service Trust Portal
• Need data governance or retention concepts? Purview
• Need posture recommendations? Defender for Cloud

10. Troubleshooting and common AZ-900 decision points

This is where many exam questions live: not in deep configuration, but in choosing the right service.

• Sign-in fails → think Entra ID, authentication method, MFA, Conditional Access
• Sign-in succeeds but resource action fails → think Azure RBAC
• User is Contributor but deployment is denied → think Azure Policy
• Resource cannot be deleted even by an admin → think resource lock
• Security team wants recommendations or secure score improvement → think Defender for Cloud
• Auditor requests compliance documentation → think Service Trust Portal
• Business wants labels, retention, or DLP → think Purview

Useful log and evidence sources to recognize at a high level:

• Sign-in logs for authentication activity
• Azure Activity Log for management operations on resources
• Policy compliance results for governance state

In real environments, organizations also reduce privileged risk with practices such as least privilege, periodic access reviews, privileged identity management for just-in-time elevation, and emergency access accounts. AZ-900 does not require deep design here, but knowing the purpose helps.

11. Exam traps, rapid review, and study guidance

Fast memory sheet:

• Entra ID = identity
• MFA/SSO/Conditional Access = authentication and sign-in controls
• Azure RBAC = who can do what
• Azure Policy = what is allowed or required
• Locks = prevent accidental deletion or change
• Defender for Cloud = posture and protection
• Service Trust Portal = compliance documents
• Purview = data governance and compliance capabilities

What AZ-900 usually does not require: deep policy JSON authoring, advanced Conditional Access design, detailed Sentinel analytics rules, or complex Purview configuration. Focus on purpose, scope, and differences between services.

If you read an exam question and pause long enough to ask, “Is this about sign-in, permission, allowed behavior, accidental protection, security posture, audit evidence, or data governance?” you will usually narrow the answer quickly.

That is the real skill behind this topic. Learn what problem each Azure feature solves, and the terminology starts to make sense. Once those boundaries click, Azure becomes much easier to reason about in both the exam and the real world.