Governance and compliance: Microsoft Purview, Azure Policy and resource locks

Why this matters

Once more than a handful of people can create things in Azure, good intentions stop being enough. Someone deploys a database in a region the company is not allowed to use. Someone forgets the cost-centre tag, so finance cannot charge the spend back. Someone tidies up a test resource group and takes the production database with it. And nobody can answer the auditor who asks where the customer records actually live. Governance tools exist so that rules hold even when people are busy, new or careless.

A manager needs to know which tool answers which worry, because the three tools in this lesson are easy to confuse and each fails silently when used for the wrong job. A salesperson will meet customers in regulated industries who ask how Azure helps them prove compliance. A junior administrator is the one most likely to hit a lock or a policy denial and wonder why their perfectly valid request failed. This lesson separates the three: Microsoft Purview looks after data, Azure Policy looks after resource settings, and resource locks look after the resources themselves.

The lesson

Microsoft Purview: knowing and protecting your data

Microsoft Purview is Microsoft's family of data governance, risk and compliance solutions. It brings data governance for Azure and other sources together with the compliance tools that grew up in Microsoft 365, under one name and one portal. Its purpose is to help an organisation govern, protect and manage its data wherever that data lives: in Azure, on-premises, in another cloud provider's storage, or in SaaS applications.

That "wherever" is the point. A company that has grown through acquisitions may have file servers in its own data centres, databases in Azure SQL Database, object storage in another cloud and documents in Microsoft 365. It usually cannot say what sensitive data it holds, or where. Purview is built for exactly this problem.

The capabilities worth knowing for the exam fall into two groups.

Data governance: finding and understanding data

• Data Map and scanning. Purview registers data sources and scans them. The scans build a map of what data exists and where it sits, across on-premises, multicloud and SaaS sources.
• Classification. During a scan, Purview applies built-in classifications that recognise patterns such as credit card numbers and national ID numbers. Data owners can then see which files and columns hold sensitive data.
• Data lineage. Purview records how data moves from its sources, through transformations, into reports. If a data team wants to know which upstream tables feed a Power BI report before it changes one of them, the lineage view shows the impact.
• Data catalog. On top of the map, Purview offers a searchable catalog with business glossary terms and named owners, so analysts can find trustworthy datasets instead of hunting through many databases and data lakes.

Risk and compliance: protecting data and proving compliance

• Information Protection and sensitivity labels. These discover, label and protect sensitive content, for example by marking a document Confidential and encrypting it.
• Data loss prevention (DLP). DLP policies detect sensitive information, such as customer account numbers, and can warn or block a user who tries to share it outside the organisation.
• Data Lifecycle Management and retention. Retention policies keep content for a set period and then delete it, for example keeping financial records in Microsoft 365 for seven years.
• eDiscovery. When a legal team must find and preserve emails, Teams chats and documents for a lawsuit, eDiscovery identifies the content, places it on hold and exports it.
• Compliance Manager. This gives a compliance score showing how far the organisation has progressed against a regulation or standard, such as GDPR, and suggests improvement actions to raise it.
• Insider Risk Management. This looks for risky activity by people inside the organisation, such as unusual downloads before someone leaves.

What Purview does not do is just as useful. It does not enforce how Azure resources are configured (that is Azure Policy). It does not monitor performance (that is Azure Monitor, lesson 16). It does not detect threats against workloads (that is Microsoft Defender for Cloud, lesson 11). Azure Key Vault protects secrets and keys, but it does not scan storage to find sensitive content. Azure Resource Graph lists Azure resources themselves, not the data inside them, and it cannot see an on-premises file server.

Azure Policy: rules for how resources are configured

Azure Policy evaluates Azure resources against rules and acts on the ones that break them. A rule is about a resource's properties: which region it is in, which virtual machine size it uses, whether it carries a required tag, whether it has a public IP address. Typical uses:

• allow deployments only in approved regions (the built-in allowed locations definition);
• allow only approved virtual machine sizes in a development subscription, which keeps costs predictable;
• require a costCenter tag, or copy a tag from the resource group to every resource inside it;
• deny public IP addresses across a subscription.

The building blocks

• A policy definition describes the condition to check and the effect to apply. Azure ships many built-in definitions, and an organisation can write custom definitions in JSON when none of them fits.
• An initiative (also called a policy set definition) groups related definitions so they can be assigned and tracked as one unit. A regulatory standard might need forty definitions; an initiative bundles them.
• An assignment applies a definition or initiative at a scope: a management group, a subscription, a resource group or a single resource. Assignments are inherited, so one assignment at a management group covers every subscription, resource group and resource beneath it. That is the way to cover several subscriptions with one assignment. A resource group belongs to a single subscription, so an assignment there cannot reach further.
• An assignment can exclude child scopes, and an exemption can skip a particular scope. If a policy denies public IP addresses across a subscription but one approved test resource group needs them, exclude that group rather than removing the policy.

Effects: what happens when a resource breaks the rule

A sensible rollout often starts with audit to learn how many resources break a rule, then switches to deny once the teams are ready.

Existing resources and compliance. Azure Policy evaluates resources that already exist, not only new ones. If a tag rule is assigned today, resources created last year without the tag are reported as non-compliant. Policy never deletes them, and they are not exempt because they are older. Remediation tasks can then apply a modify or deployIfNotExists effect to existing resources. The compliance view in Azure Policy shows the percentage of resources that meet each assignment and lists the ones that do not.

Policy is not RBAC. Azure role-based access control (lesson 11) decides who can perform an action. Azure Policy decides what a resource may look like. They are checked separately. A user with the Contributor role has permission to create virtual machines, yet the request still fails if a deny policy forbids the region. Giving that user the Owner role does not help either, because policies apply to everyone whatever their role.

Azure Policy also reaches outside Azure. Servers connected through Azure Arc (lesson 14) can be audited against the same configuration rules as Azure virtual machines.

Resource locks: stopping accidental change or deletion

A resource lock protects a resource from being deleted or changed by mistake. There are two types:

• Delete (called CanNotDelete in the API and command-line tools). Authorised users can read and modify the resource, but nobody can delete it.
• ReadOnly. Authorised users can read the resource, but nobody can modify or delete it. It is like giving everyone the Reader role for that resource for as long as the lock exists.

Locks follow a few rules that the exam likes to test.

• Locks apply to everyone, including Owners. That is their whole purpose. RBAC already limits who may delete a production database, but a person with the right role can still delete it by mistake. A Delete lock stops even authorised administrators.
• Scopes and inheritance. A lock can be applied to a subscription, a resource group or an individual resource. A lock at a parent scope is inherited by everything beneath it, including resources created after the lock was added. A Delete lock on a resource group does not stop new resources being created there; it only blocks deletion.
• A locked child blocks the parent's deletion. If one virtual machine in a resource group has a Delete lock, the whole resource group cannot be deleted. Azure does not delete the rest of the group around it.
• Removing a lock. Locks do not expire. To delete or change a locked resource, someone with permission to manage locks must remove the lock first. Among the built-in roles, only Owner and User Access Administrator can create or delete locks. A Contributor can manage resources but cannot add or remove a lock.
• Locks act on management operations, not data. A Delete lock on a storage account stops the account from being deleted, but a developer can still delete blobs inside it. Protecting the data itself needs features such as soft delete or immutability policies. In the same way, a ReadOnly lock on a running App Service app blocks configuration changes but the app keeps serving customers.

Choosing between the two types comes down to whether changes must still be allowed. If a team must keep changing a production database's settings, use Delete. If a production network security group must be frozen until a change window opens, use ReadOnly: a Delete lock would still let someone edit its rules.

Putting the three together

Each tool answers a different question:

• Where is our sensitive data, and is it protected? Microsoft Purview.
• Are our resources configured the way our rules say? Azure Policy.
• Could someone delete or change this critical resource by accident? A resource lock.

So a company that must limit deployments to approved regions, stop a key resource being deleted, and map where sensitive data lives needs Azure Policy, a resource lock and Microsoft Purview, in that order. Note what is not on the list. Azure Advisor recommends improvements but enforces nothing. Azure Monitor collects metrics and logs but neither blocks changes nor finds sensitive data. A budget in Microsoft Cost Management (lesson 12) sends alerts when spending crosses a threshold, but it does not stop anyone deploying an expensive virtual machine size; a policy does.

What the exam is really asking

• Purview vs Azure Policy. Purview is about data: discovering, classifying, labelling, retaining and tracing it, across Azure, on-premises, other clouds and SaaS. Azure Policy is about resource properties in Azure. A question that mentions sensitive data, lineage, a catalog, DLP, eDiscovery or a compliance score points to Purview.
• Azure Policy vs RBAC. RBAC is who may act; Policy is what a resource may look like. Neither replaces the other, and a role never overrides a deny policy.
• Azure Policy vs locks. Policy governs settings; locks block change or deletion regardless of settings. A lock enforcing a region is wrong, and so is reaching for Policy when the question is about stopping accidental deletion: that is a lock's job.
• Delete vs ReadOnly. Delete allows updates but not deletion. ReadOnly allows neither. Owners get no exception from either.
• Inheritance. Both policy assignments and locks flow down from a parent scope. One policy at a management group covers its subscriptions; a lock on a resource group covers its resources, new ones included.
• Existing resources. A new policy reports existing resources as non-compliant; it does not delete them or ignore them.
• Effects. Audit reports, deny blocks, modify changes tags or properties, deployIfNotExists adds what is missing.
• Locks and data. A lock protects the resource, not the blobs, rows or files inside it.