Azure Governance: Purview, Policy, and Locks
Governance keeps your Azure environment compliant and controlled. Microsoft Purview, Azure Policy, and resource locks work together to enforce rules automatically.
Keeping Azure under control
Governance is like the rules of a shared kitchen at work.
Microsoft Purview = the food safety inspector. They check what food is stored, where it came from, and whether it’s labelled correctly. In Azure, Purview discovers and classifies your data across all your services.
Azure Policy = the kitchen rules posted on the wall. “All food must be labelled.” “No personal items in the fridge.” These rules are enforced automatically — if you try to store unlabelled food, the policy rejects it.
Resource locks = padlocks on the expensive equipment. Even if you have permission to use the kitchen, you can’t throw away the espresso machine. Locks prevent accidental deletion of critical resources.
Microsoft Purview
Purview is Azure’s data governance platform. In the context of AZ-900, it provides:
| Capability | What It Does |
|---|---|
| Data Map | Discovers and classifies data across Azure, on-prem, and SaaS |
| Data Catalog | Searchable index of your organisation’s data assets |
| Compliance | Tracks compliance against regulatory standards |
| Risk management | Identifies sensitive data and potential risks |
Harbour Health uses Purview to discover where patient data exists across their Azure environment — SQL databases, blob storage, and file shares. It automatically classifies data containing health records and flags any that lacks proper sensitivity labels.
Exam scope: AZ-900 only tests the PURPOSE of Purview in Azure — that it provides data governance, discovery, and classification. Deeper Purview features (like Data Loss Prevention) are covered in other exams.
Azure Policy
Azure Policy enforces rules on your Azure resources automatically:
| Policy Action | What Happens |
|---|---|
| Deny | Blocks resource creation if it doesn’t meet the policy |
| Audit | Allows creation but flags it as non-compliant |
| Append | Adds settings to resources (e.g., automatically add a tag) |
| DeployIfNotExists | Deploys a required resource if it’s missing |
Common policy examples
| Policy | Effect | Example |
|---|---|---|
| Allowed locations | Deny | Only allow resources in Australia East and Australia Southeast |
| Require tags | Deny | All resources must have an “Owner” tag |
| Allowed VM sizes | Deny | Only allow B and D-series VMs (no expensive N-series) |
| Require encryption | Audit | Flag storage accounts without encryption enabled |
Policy initiatives
A policy initiative is a collection of related policies grouped together. Instead of assigning 10 individual policies, you assign one initiative.
Example: Harbour Health’s “Healthcare Compliance” initiative includes:
- Require encryption on all storage
- Require HTTPS on all web apps
- Restrict resource creation to approved regions
- Require sensitivity labels on databases
Azure Policy vs RBAC
They’re different:
- RBAC controls WHO can do things (users and permissions)
- Azure Policy controls WHAT can be done (resource configurations)
A user with Contributor access can create any VM. But if an Azure Policy restricts VMs to D-series only, even a Contributor can’t create an N-series VM. Policy overrides individual permissions for resource configuration.
Resource locks
Resource locks prevent accidental changes to critical resources:
| Feature | CanNotDelete Lock | ReadOnly Lock |
|---|---|---|
| Can read? | Yes | Yes |
| Can modify? | Yes | No |
| Can delete? | No | No |
| Use case | Protect production resources from deletion | Protect critical configs from any changes |
Key facts about locks:
- Locks apply to ALL users, regardless of RBAC role — even Owners
- Locks are inherited — a lock on a resource group applies to all resources inside
- To delete a locked resource, you must first remove the lock (deliberate two-step process)
- Locks protect against accidents, not malicious actors (an admin can remove the lock)
Summit Construction puts a CanNotDelete lock on their production database. Even if an admin accidentally tries to delete it, the lock prevents it. They’d have to intentionally remove the lock first.
🎬 Video walkthrough
🎬 Video coming soon
Azure Governance — AZ-900
Azure Governance — AZ-900
~9 minFlashcards
Knowledge Check
Harbour Health wants to ensure that no Azure resources can be created outside of Australia. Which Azure feature should they use?
Summit Construction's production SQL database must not be accidentally deleted, but admins still need to modify its settings. Which resource lock type should they apply?
Next up: The Azure Portal — your visual command centre for managing everything in Azure.