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 find, understand and protect 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, resource groups or subscriptions 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.

Microsoft Purview is Microsoft's unified data governance, security and compliance service: it helps you find out what data you hold, where it lives and how sensitive it is, across Azure, on-premises systems, other clouds and SaaS sources. Its purpose is visibility and control over the data itself, wherever it is stored.

Purview's capabilities are distinct, and questions often name one of them:

For AZ-900 you do not configure Purview; you recognize its purpose. Scenarios about searching for data across sources, discovering where sensitive or personal data is stored, tracing how data flows, or preventing sensitive data from leaking point to Purview. Purview does not stop someone from deploying a resource in the wrong region, and it does not protect a resource from deletion: those are jobs for Azure Policy and resource locks.

Azure Policy is the service that evaluates Azure resources against your organization's rules and then reports, blocks or corrects anything that does not comply. You write (or pick a built-in) policy definition that describes a rule, then assign it to a scope.

Common examples of rules Azure Policy can enforce:

• Allowed locations: resources may only be created in approved regions, for example for data residency.
• Required tags: every resource must carry a tag such as a cost center.
• Allowed SKUs: only approved virtual machine sizes or service tiers may be used, which helps control cost.
• Required settings: for example storage accounts must use secure transfer (HTTPS only) or must not allow anonymous public access.

Scope and inheritance. An assignment can be made at a management group, a subscription, a resource group or an individual resource. It is inherited by everything beneath that scope: an assignment on a management group applies to all its child subscriptions, their resource groups and their resources, including resources created after the assignment. This is how one rule governs a whole organization without being assigned again and again.

Policy evaluates resource properties during create and update requests and also periodically checks existing resources, showing the results on a compliance dashboard. Whenever a question describes enforcing configuration rules on resources, the answer is Azure Policy.

A policy's effect decides what happens when a resource does not comply. Three effects are worth knowing for AZ-900:

The difference between audit and deny matters whenever a requirement says something must not happen: audit only reports, so it does not meet a "must stop" requirement.

What happens to resources that already exist. When you assign a policy, Azure evaluates the resources that are already in scope and reports any that break the rule as non-compliant. It does not delete, stop or move them, even with the deny effect: deny only blocks new create or update requests. Neither audit nor deny ever changes a resource. To bring existing resources into line automatically, a policy with the modify effect (or one that deploys a missing setting) can be applied to them through a remediation task; for example, a modify policy that adds an environment tag, run through a remediation task, can tag resources created before the policy existed, with no scripts to write.

A policy initiative (also called a policy set) is a group of related policy definitions that work toward one goal, assigned and tracked as a single unit. Instead of assigning dozens of individual policies for a standard such as a security baseline or a regulatory framework, you assign one initiative and see one overall compliance result, with the detail for each rule underneath.

Initiatives simplify management in two ways. You assign them once at a scope, and inheritance carries them to everything below, just like single policies. And an assignment follows the current content of its initiative: if a definition is added to an initiative that is already assigned, the existing assignments start evaluating it without being re-created. Microsoft provides built-in initiatives for common standards, which is a fast way to measure an environment against a published benchmark.

One of the most reliable AZ-900 distinctions is between Azure Policy and 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, blocks or corrects 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, even Owner, yet still be blocked by a deny 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, and they apply to every user and role, including Owners. A lock stops the action until someone deliberately removes the lock. Locks can be applied to a subscription, a resource group or an individual resource (not to a management group).

There are two lock types:

Inheritance. A lock on a parent scope is inherited by every resource inside it, including resources created later: a CanNotDelete lock on a resource group also protects any storage account or virtual machine created in that group after the lock was applied. If locks conflict in the chain, the most restrictive one applies.

Removing a lock. A lock is not bypassed by a powerful role; the request simply fails while the lock is in place. To go ahead, a user who is allowed to manage locks first removes the lock as a separate step, then performs the action. Managing locks needs Microsoft.Authorization/locks permissions, which the built-in Owner and User Access Administrator roles have, regardless of who created the lock. Contributor does not: a Contributor can neither create nor remove locks at any scope, so a Contributor blocked by a lock needs someone with one of those roles.

What locks cover. Locks govern management operations on a resource (creating, changing, deleting it through Azure Resource Manager), not the use of the resource. Under a ReadOnly lock you can still sign in to a virtual machine or work with data in a database. Some operations that look like reads are blocked, though: a ReadOnly lock on a storage account prevents listing its access keys, so users who do not already have a key must use Microsoft Entra credentials to reach blob or queue data (keys already held keep working), and a ReadOnly lock on a resource group prevents starting or restarting its virtual machines. Locks protect resources, not the data inside them, so they are not a replacement for backups.

Azure Blueprints is not part of the current AZ-900 skills outline, and Microsoft is retiring it — a phased retirement began on 31 July 2026 and ends on 31 January 2027, with Deployment Stacks and template specs as the replacements. You may still see it in older study material, where it is described as a way to package role assignments, policy assignments, resource groups and templates into one repeatable definition.

What the exam actually tests are the building blocks it used to bundle: Azure Policy for what is allowed, RBAC for who can act, and resource locks for protecting critical resources. If a scenario describes applying governance consistently across many environments, reason about those individual controls rather than reaching for Blueprints.

Many real requirements need all three tools, each doing the job only it can do. Suppose a hospital group has three needs: prove to auditors which systems hold patient health records, across Azure Data Lake Storage and on-premises Oracle databases; make sure no storage account can ever be created that accepts unencrypted HTTP traffic; and protect the production virtual network from deletion while the network team continues to adjust its subnets.

Locating the sensitive data is Purview's job. Registering and scanning those sources in Microsoft Purview builds the data map, and classification labels the files and columns that hold health information, giving the auditors one place to see where it lives. Azure Policy cannot see inside data, and a lock does not report anything.

Preventing the configuration is Azure Policy's job, with the deny effect. A policy that requires secure transfer (HTTPS only), assigned at the subscription or a management group above it with deny, rejects any create or update request that would leave a storage account accepting HTTP, whatever RBAC role the requester holds. Audit would only list offending accounts, which does not satisfy a "must never" requirement. Accounts that already break the rule show as non-compliant; they are not deleted.

Protecting the virtual network is a lock's job, specifically CanNotDelete. The network team can keep changing subnets, but nobody can delete the network until a user with lock permissions, such as Owner or User Access Administrator, removes the lock. A ReadOnly lock would be the wrong choice because it would also block those routine changes.

The same reasoning applies to other rules: an allowed-locations policy with deny for data residency, a modify policy with a remediation task to add a missing tag to older resources, or a ReadOnly lock to freeze a firewall's settings during a change freeze.