A city architect says Microsoft Purview will stop staff from creating untagged resource groups the way Azure Policy does. What distinction should the team correct?
Select an answer to reveal the explanation.
Short Explanation
Different toolboxes. Purview is about understanding and governing data; Policy is about whether Azure resources meet your rules. Mixing them up is like asking the records librarian to enforce parking permits.
Full Explanation
Microsoft Purview and Azure Policy solve different municipal problems. Purview focuses on understanding and governing data—cataloging assets, classification themes, and compliance visibility for citizen datasets. Azure Policy evaluates Azure resource properties and configurations against rules you assign (naming, required tags, allowed locations, public IP restrictions, and similar standards). Stopping staff from creating untagged resource groups is a Policy (or tagging-enforcement) concern, not a Purview catalog feature.
Treating Purview and Policy as identical tools that both enforce resource naming collapses two product purposes into one and leads to the wrong control being purchased. The reverse mix-up—saying Policy catalogs PII lineage while Purview only locks resource groups—also fails: lineage and data catalog themes belong with Purview, while locks are a separate Resource Manager safeguard. Likewise, denying public IP creation is classic Policy territory; Purview does not replace Policy as the resource-configuration gate.
Exam caveat: both products can appear in a broader “governance” story, but AZ-900 questions often hinge on whether the scenario is about data understanding versus resource configuration compliance. Operational check: for an untagged resource-group scenario, open Azure Policy assignments at the subscription and look for a require-tag or deny effect; separately open Purview (or review its documented purpose) and confirm it is inventorying datasets, not blocking ARM deployments of empty resource groups.