Microsoft Purview
Microsoft PurviewA family of data governance, risk, and compliance solutions that gives organizations a single unified view of their data across on-premises, multicloud, and SaaS environments. Organized into two areas: Risk and compliance (protecting sensitive data) and Unified data governance (mapping and managing your data estate). provides a unified view of an organization's data across on-premises, multicloud, and SaaS environments through two areas:
| Area | What it does |
|---|---|
| Risk and compliance | Protects sensitive data across clouds, apps, and devices; identifies data risks; manages regulatory compliance. Integrates with Microsoft 365 (Teams, OneDrive, Exchange). |
| Unified data governance | Creates a map of your entire data estate, identifies where sensitive data lives, manages access at scale, and generates usage insights. |
Key capabilities of Microsoft Purview:
- Automated data discovery — Scans registered data sources to build an up-to-date data catalog.
- Sensitive data classification — Classifies data using built-in and custom classifiers (e.g., credit card numbers, health records).
- End-to-end data lineage — Tracks how data flows and transforms across systems.
Microsoft Purview works across Azure, SQL and Hive databases, on-premises sources, and other clouds such as Amazon S3.
Azure Policy
Azure PolicyA service that creates, assigns, and manages policies to control or audit resource configurations, ensuring they comply with organizational standards. Policies are assigned to a scope (resource, resource group, subscription, or management group) and are inherited by all child scopes. enforces configuration compliance by defining rules that are evaluated against all resources within the assigned scope and inherited by all child scopes. How Azure Policy works:
- Define a policy definition — a rule describing what is allowed or required (e.g., "VMs must use approved sizes").
- Group related policies into a policy initiative (also called a policy set).
- Assign the policy or initiative to a scope.
- Azure Policy evaluates existing and new resources and reports compliance status.
- Non-compliant resources are flagged; some policies can automatically remediate non-compliant configurations.
Policy inheritance: Policies assigned at a higher scope (e.g., subscription) are automatically inherited by all child scopes.
Azure Policy vs. Azure RBAC:
| Feature | Azure Policy | Azure RBAC |
|---|---|---|
| Controls | What resources look like (configuration) | Who can do what (actions) |
| Purpose | Enforce compliance standards | Grant or restrict permissions |
| Example | "All storage accounts must use HTTPS" | "User X can read but not delete resources" |
Azure Policy + Azure DevOps: Policy can enforce compliance checks in CI/CD pipelines — blocking deployments that would create non-compliant resources in pre- or post-deployment phases.
Resource Locks
Resource locksA control that prevents authorized users — including those with Owner-level RBAC permissions — from accidentally deleting or modifying critical Azure resources. Locks are inherited from parent to child scopes. prevent accidental deletion or modification of critical resources — they override RBAC, meaning even an Owner must remove the lock before acting. Locks are inherited from parent to child scopes. Two lock types:
| Lock type | Read | Modify | Delete |
|---|---|---|---|
| Delete | Allowed | Allowed | Blocked |
| ReadOnly | Allowed | Blocked | Blocked |
Critical behaviors:
- Locks are inherited — a lock placed on a resource group automatically applies to all resources within that group.
- Locks override RBAC. Even a subscription Owner must first remove the lock before deleting or modifying a locked resource.
- To modify or delete a locked resource: (1) remove the lock, (2) perform the action.
- Locks can be applied at the resource, resource group, or subscription level.
Service Trust Portal
The Service Trust PortalA public-facing site (servicetrust.microsoft.com) where Microsoft publishes audit reports, compliance documentation, and certifications (ISO, SOC, GDPR, etc.) for Azure and other Microsoft cloud services. Does not require an Azure subscription to browse. is publicly accessible at servicetrust.microsoft.com — no Azure subscription required — and hosts Microsoft's audit reports and compliance certifications (ISO, SOC, GDPR, and more).
Azure Policy — End-to-End Workflow
Define policy definition
→ (optional) Group into initiative (policy set)
→ Assign to scope (MG / Subscription / RG / Resource)
→ Evaluation runs (new and existing resources)
→ Compliant or Non-compliant
→ Non-compliant: flag + optional auto-remediation
Built-in initiatives cover: Storage, Networking, Compute, Security Center, Monitoring. Example: the "Enable Monitoring in Azure Security Center" initiative contains 100+ individual policy definitions.
Resource Lock Behavior Matrix
| Action | No lock | Delete lock | ReadOnly lock |
|---|---|---|---|
| Read resource | Yes | Yes | Yes |
| Modify resource | Yes | Yes | No |
| Delete resource | Yes | No | No |
| Owner can bypass | N/A | Must remove lock first | Must remove lock first |
Key insight: ReadOnly lock is stricter than Delete lock. A ReadOnly lock blocks both modification AND deletion.
Microsoft Purview vs. Azure Policy — Scope Comparison
| Dimension | Microsoft Purview | Azure Policy |
|---|---|---|
| Focus | Data assets — what data exists, where, how it flows | Azure resource configurations |
| Scope | On-prem, multicloud, Azure, SaaS | Azure resources (and Arc-connected non-Azure) |
| Output | Data catalog, lineage, classification | Compliance report, remediation tasks |
| Primary users | Data stewards, compliance officers | Cloud architects, Azure admins |
Both tools address compliance but from different angles — Purview governs data; Policy governs infrastructure.
Policy Initiative vs. Individual Policy — When to Use Each
| Approach | When to use | Example |
|---|---|---|
| Individual policy | Single, targeted requirement | "Storage accounts must use HTTPS" |
| Initiative (policy set) | Multiple related policies applied together | "CIS Azure Benchmark" — 100+ policies bundled |
| Built-in initiative | Standard compliance frameworks | ISO 27001, NIST SP 800-53, PCI DSS |
| Custom initiative | Organization-specific requirements | Internal security baseline with 20 custom policies |
Explore Governance Tools in the Azure Portal
Step 1 — Browse Azure Policy Definitions
- Sign in to portal.azure.com.
- Search for Policy and open the Azure Policy service.
- Click Definitions → filter by Category = "Tags".
- Select "Require a tag on resources" — read the policy rule JSON.
- Note the
effectproperty (e.g.,deny,audit,modify) — this controls what happens when a resource violates the policy.
Step 2 — Check Policy Compliance
- In Azure Policy, click Compliance.
- Observe the compliance percentage for any assigned policies.
- Click into a non-compliant policy (if any) to see which resources are flagged.
Step 3 — Apply a Resource Lock
- Navigate to any non-production resource group in the portal.
- Under Settings, click Locks → + Add.
- Set Lock type = Delete, enter a name (e.g., "prevent-delete"), and a note.
- Click OK — the lock is now applied.
- Try to delete the resource group — observe the error message.
- Navigate back to Locks and delete the lock before leaving.
Step 4 — Browse the Service Trust Portal
- Navigate to servicetrust.microsoft.com (no Azure sign-in required).
- Browse Audit Reports — find ISO/IEC 27001 or SOC 2 reports for Azure.
- Note that these are the official Microsoft compliance certifications that customers reference for regulatory requirements.
AZ-900 Exam Focus
Exam Trap
"Azure Policy blocks users from performing actions in Azure" — Wrong. Azure Policy controls resource configurations (what a resource must look like), not who can take actions. RBAC controls user permissions. A policy can prevent a non-compliant resource from being created, but it does not manage access rights.
Exam Trap
"An Owner can delete a resource even if a resource lock is applied" — Wrong. Resource locks override RBAC, including the Owner role. The Owner must remove the lock first, then delete the resource. This is a very common AZ-900 trap.
Exam Trap
"A resource lock prevents all users from accessing a resource" — Wrong. A Delete lock still allows reads and modifications; only deletion is blocked. A ReadOnly lock blocks modifications and deletions but still allows reads.
Exam Trap
"Microsoft Purview is only for Azure data sources" — Wrong. Purview supports on-premises, multicloud (e.g., AWS S3), Azure, and SaaS sources. It has a broader scope than Azure-only governance tools.
Exam Trap
"Azure Policy and resource locks serve the same purpose" — Wrong. Policy enforces configuration compliance (required tags, allowed SKUs). Locks prevent deletion or modification of resources. They address different governance concerns.
Must Memorize
Delete lock = read ✓ modify ✓ delete ✗
ReadOnly lock = read ✓ modify ✗ delete ✗
Locks override RBAC — Owner must remove lock first
Policy = configuration governance · Locks = accidental deletion/modification prevention
Question — click to flip
Q: What is the difference between a Delete lock and a ReadOnly lock?
Question — click to flip
Q: Can an Azure subscription Owner delete a resource that has a Delete lock applied?
Question — click to flip
Q: What is the difference between Azure Policy and Azure RBAC?
Question — click to flip
Q: Are resource locks inherited? Give an example.
Question — click to flip
Q: What is Microsoft Purview and what data sources does it support?
Question — click to flip
Q: What is the Service Trust Portal and who can access it?