Azure Governance and Compliance: Purview, Policy, and Resource Locks

Governance is the set of controls that keep a cloud environment consistent with your organization's rules, and compliance is being able to show you actually meet those rules and any external regulations. As a company deploys more resources across more teams and subscriptions, it becomes impossible to police everything by hand. Governance tools let you define standards once and have Azure apply and check them for you.

The AZ-900 exam focuses on three tools in this area, each with a distinct job. Microsoft Purview governs your data, helping you understand and classify information across the estate. Azure Policy governs your resources, enforcing rules about how they are configured and where they are deployed. Resource locks protect individual resources from accidental deletion or change.

It also helps to keep governance separate from access control. Role-based access control, or RBAC, decides who can perform actions, while Azure Policy decides what configurations are allowed regardless of who is acting. The two work together: a user might have full permission to create a virtual machine through RBAC, yet a policy can still block that VM if it breaks a rule such as an approved-region restriction. The following sections describe each tool's purpose and the comparisons the exam likes to test.

Microsoft Purview is a unified data governance and compliance solution that helps you manage and understand data across your whole estate, not just in Azure but often across on-premises systems and other clouds too. Its purpose is to give you visibility and control over data wherever it lives.

Purview's core capabilities revolve around knowing your data. Data cataloging builds a searchable map of your data sources so people can find and understand what exists. Data classification scans content and labels it, for example flagging where sensitive information such as personal or financial data resides. Data discovery lets you explore lineage and see how data flows and is used across systems. Together these help you protect sensitive information and meet regulatory obligations.

For AZ-900, you do not need to configure Purview; you need to recognize its purpose. If a question mentions data governance, cataloging, classifying, or discovering sensitive data across an organization's estate, the answer is Microsoft Purview. Be careful not to confuse it with Azure Policy: Purview governs the data itself (what information you hold and where it is), whereas Azure Policy governs how resources are configured and deployed. When the scenario is about understanding, cataloging, or classifying data, choose Purview.

Azure Policy is the service that enforces your organization's rules and standards on Azure resources. You define policies that describe what is and is not allowed, and Azure evaluates resources against them automatically. This keeps deployments consistent and compliant without relying on people to remember every rule.

A policy has an effect that decides what happens when a resource does not comply. Two effects to know are audit, which flags a non-compliant resource and reports it without blocking anything, and deny, which stops the non-compliant resource from being created or updated in the first place. Auditing is useful for visibility across an existing estate; denying actively prevents mistakes and drift.

The classic exam examples are simple and worth memorizing. A policy might only allow certain regions, so any attempt to deploy outside an approved region is denied. Another might require a tag, such as a cost center, on every resource, so untagged resources are flagged or blocked. Policies can be grouped into initiatives and assigned at scopes like a management group, subscription, or resource group so they apply broadly. Whenever a question describes enforcing rules on resources or denying non-compliant resources, the answer is Azure Policy.

One of the most reliable AZ-900 questions asks you to separate Azure Policy from role-based access control, because both sound like security controls. The distinction is clean: RBAC controls who can do things, and Azure Policy controls what is allowed.

RBAC grants people and applications permission to perform actions, such as letting a user read a storage account or letting an administrator create virtual machines. It is about identity and authorization. Azure Policy, by contrast, does not care who is acting; it evaluates the properties of the resource itself and allows or blocks the configuration. The two are complementary and often both apply to the same action.

A practical way to remember it: a user might have every permission RBAC can grant, yet still be blocked by a policy. RBAC says you are allowed to build; Policy says what you build must follow the rules.

Resource locks protect important Azure resources from being accidentally deleted or modified. Even a user with permission to change a resource can make a costly mistake, and a lock adds a guardrail that stops that action until someone deliberately removes the lock. Locks can be applied to a resource, a resource group, or a subscription, and they apply to everyone regardless of their RBAC role.

There are two lock types. CanNotDelete means authorized users can still read and modify the resource, but no one can delete it. ReadOnly is stricter: users can read the resource but cannot modify or delete it, effectively freezing its configuration. Choose CanNotDelete when you want normal changes but no deletions, and ReadOnly when the resource should not change at all.

Remember that locks are about protecting resources, not about permissions. RBAC decides who has access; a lock overrides that access to prevent accidental deletion or modification. On the exam, if a scenario says prevent accidental deletion of a critical resource, the answer is a resource lock, and specifically CanNotDelete when deletion is the concern.

You may see Azure Blueprints mentioned alongside these governance tools, so it helps to recognize the concept even though it is not a core focus of this topic. A blueprint packages together a set of governance artifacts, such as role assignments (RBAC), policy assignments (Azure Policy), resource groups, and resource templates, into a single repeatable definition.

The purpose is to help teams stand up new environments that are compliant from the start. Instead of manually configuring roles, applying policies, and creating baseline resources every time, an organization can define a blueprint once and deploy it repeatedly, so every subscription begins in a known, governed state. This is especially useful for large organizations that must meet regulatory or internal standards consistently across many environments.

The key idea to carry into the exam is that Blueprints orchestrate other governance building blocks rather than replacing them. A blueprint might bundle a region-restriction policy, a required-tag policy, specific role assignments, and a standard resource group so that everything is applied together. If a scenario describes packaging governance settings into a repeatable, deployable definition for consistent environments, that points toward Azure Blueprints, while the individual rules inside it are still Azure Policy and RBAC doing their usual jobs.

Suppose your company must keep all resources inside a single approved Azure region for data-residency reasons, and it wants to protect a critical production database from accidental loss. Governance gives you two tools that work together.

First, you create an Azure Policy that only allows the approved region and assign it at the subscription scope with the deny effect. Now, if any engineer tries to deploy a virtual machine or any other resource outside that region, Azure blocks the deployment automatically, even if RBAC has granted that engineer full rights to create resources. The policy governs what is allowed; RBAC still governs who can attempt the action, and here the two combine so a permitted user is still stopped by the rule.

Second, you place a resource lock of type CanNotDelete on the production database. Administrators can still update and manage it day to day, but no one can delete it by mistake; the lock must be removed first. If you needed to freeze the configuration entirely during an audit, you would switch to a ReadOnly lock instead.

This single scenario exercises the whole topic: Azure Policy enforcing an approved-region rule by denying non-compliant deployments, the Policy-versus-RBAC distinction, and resource locks preventing accidental deletion.