Management and Governance Data governance

Data catalog

Data catalog is a governed inventory of data assets, metadata, business context, ownership, lineage, and access signals used to help people find and understand data.

Source: Microsoft Learn - Microsoft Purview Unified Catalog Reviewed 2026-05-13

Exam trap: Treating Data catalog as a label instead of checking the exact resource, identity, dependency, and monitoring evidence.
Production check: Verify the active Azure subscription, resource group, resource ID, and environment before interpreting the result.

Practice this topic Microsoft Learn

Article details and learning context

Aliases: Data catalog
Difficulty: intermediate
CLI mappings: 4
Last verified: 2026-05-13

Related context No curated learning path mapped yet; use the category trail.

Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Data catalog is a governed inventory of data assets, metadata, business context, ownership, lineage, and access signals used to help people find and understand data. In plain English, it helps teams discover trusted data products and assets without relying on tribal knowledge or outdated spreadsheets. You see it when Microsoft Purview Unified Catalog organizes data products, data stewards curate glossary terms and ownership, or analytics teams request access to governed assets. The practical question is who owns it, which Azure resource proves it, and what breaks if it is missing.

Why it matters

Data catalog matters because it gives organizations a practical way to find, understand, and govern data before analysts, engineers, or AI applications use it. In enterprise Azure work, the weak spot is rarely the feature name; it is the gap between design intent and live state. When teams skip this topic, they can create audit findings, production outages, ambiguous ownership, hidden costs, or brittle integrations that show up during an incident. A good glossary entry turns the idea into an operating checklist: confirm scope, dependencies, monitoring, approved owners, and measurable outcomes before the change reaches production. Keep owner, scope, evidence, and rollback visible.

Official wording and source

Data catalog is a governed inventory of data assets, metadata, business context, ownership, lineage, and access signals used to help people find and understand data. Microsoft Learn places it in Microsoft Purview Unified Catalog; operators confirm scope, configuration, dependencies, and production impact.

Open Microsoft Learn

Technical context

Technically, Data catalog is backed by Azure configuration, identities, dependencies, logs, and deployment records. Operators validate it by checking the live resource, related permissions, health signals, and approved design notes. Treat it as production configuration: capture resource IDs, test failure behavior, use least-privilege access, and keep rollback notes beside the change record. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible.

Exam context

Compare with

Data classification Data lineage Azure Databricks Unity Catalog Model catalog

Where it is used

Where you see it

During portal reviews, Data catalog shows up in configuration, identity, networking, monitoring, or governance pages that prove the current production state. Review owner and rollback notes.
In CLI or IaC reviews, it appears in az purview account, deployment templates, source registration records, and exported governance evidence, helping engineers compare intended configuration with live Azure state before release.
In monitoring and governance, it appears through scan history, data estate health, catalog usage, access-request status, lineage updates, and audit logs, where teams track drift, failures, usage, and policy exceptions tied to owners.

Common situations

Plan and review production use of Data catalog across subscriptions and environments.
Troubleshoot incidents where Data catalog affects access, latency, message flow, governance, or compliance evidence.
Create audit-ready runbooks, dashboards, and change checks for Data catalog.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Commercial data marketplace Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Riverbend Bank, a financial services organization, had hundreds of analytics datasets but analysts could not tell which customer, risk, and product tables were approved for reuse.

Goals

Create a searchable catalog for high-value data products
Assign accountable data owners to every priority asset
Reduce access-request cycle time by thirty percent
Show lineage for critical customer reporting datasets

Approach using Data catalog

Riverbend implemented Microsoft Purview Unified Catalog with governance domains for risk, retail banking, and finance. Data stewards registered priority sources, curated business glossary terms, grouped approved assets into data products, and connected access policies to governed request workflows. Lineage was captured for customer reporting pipelines, and Purview account details were included in Azure governance evidence. Analysts searched the catalog instead of relying on shared spreadsheets or private messages. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch.

Potential outcomes

Priority assets gained documented owners within six weeks
Access-request cycle time dropped by thirty two percent
Customer reporting lineage became visible to auditors
Duplicate analyst datasets were reduced by twenty five percent

What to learn

A data catalog turns discovery into a governed workflow rather than an informal scavenger hunt.

Scenario 02 Research data stewardship Scenario, objectives, solution, measured impact, and takeaway.

Scenario

VanArsdel Therapeutics, a pharmaceuticals organization, needed scientists to find approved clinical, lab, and manufacturing datasets without exposing sensitive study metadata unnecessarily.

Goals

Improve discovery of approved research data products
Separate sensitive study metadata from broad user access
Track lineage from lab files to analysis outputs
Raise data health scores for priority domains

Approach using Data catalog

VanArsdel organized Purview Unified Catalog around research and manufacturing governance domains. Stewards curated data products, attached glossary terms, documented owners, and applied access policies to sensitive study assets. Data Map scans and lineage integrations showed how lab files moved into analytical tables. Security reviewed roles so catalog discovery did not become uncontrolled access, while health actions identified duplicate or poorly described assets that needed cleanup. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch.

Potential outcomes

Scientists found approved datasets forty percent faster
Sensitive study access followed documented policy decisions
Lineage coverage reached eighty percent for priority pipelines
Data health actions reduced duplicate catalog entries

What to learn

Catalog quality depends on stewardship, not just scanning more data sources.

Scenario 03 Merchandising analytics hub Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Wide World Importers, a wholesale distribution organization, wanted business users to locate trusted inventory and supplier datasets before building Power BI and AI forecasting projects.

Goals

Publish trusted merchandising data products for self-service teams
Reduce duplicate reporting datasets by at least twenty percent
Connect glossary terms to source assets and dashboards
Create a review rhythm for stale catalog entries

Approach using Data catalog

The data platform team used Purview Unified Catalog to group inventory, supplier, and sales assets into curated data products. Each product included owner names, business glossary terms, access rules, lineage, and quality notes. Catalog stewards reviewed stale assets monthly, while Azure activity evidence tracked Purview account changes. Business users could search by governance domain or data product and request access through a governed workflow. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch. The architecture decision record captured owners, rollback steps, monitoring queries, and acceptance criteria so the operating team could support the design after launch.

Potential outcomes

Duplicate reporting datasets dropped by twenty eight percent
Power BI authors found approved sources in one search flow
Stale catalog entries were reviewed monthly
Forecasting teams reused the same governed inventory product

What to learn

A useful data catalog gives business context, ownership, and access guidance in the same place.

Azure CLI

Use Azure CLI for Data catalog to collect repeatable evidence from live Azure resources without changing the JSON engine or relying on one-off portal screenshots.

Useful for

Confirm the live Azure scope, resource owner, and configuration state for Data catalog before an approval.
Capture repeatable evidence for audits, incidents, architecture reviews, and release checklists involving Data catalog.
Compare portal settings, IaC intent, and command output so drift is found before it becomes a production issue.

Before you run a command

Confirm the active tenant, subscription, resource group, resource names, and environment before trusting any command output.
Start with read-only commands; use mutating commands only when a change ticket, rollback plan, and owner approval exist.
Check whether the command touches identity, keys, networking, secrets, billing, or production traffic before running it.

What the output tells you

It shows whether Data catalog is configured at the expected Azure scope and whether live settings match the approved design.
It exposes resource IDs, identities, permissions, component names, encryption settings, logs, or status values needed for troubleshooting.
It helps reviewers connect a portal decision to concrete evidence that can be saved in an incident, audit, or release record.

Mapped commands

Data catalog operational checks

direct

az purview account list --resource-group <resource-group>

az purview accountdiscoverManagement and Governance

az purview account show --name <account-name> --resource-group <resource-group>

az purview accountdiscoverManagement and Governance

az purview account create --name <account-name> --resource-group <resource-group> --location <region>

az purview accountprovisionManagement and Governance

az monitor activity-log list --resource-group <resource-group> --max-events 100

az monitor activity-logdiscoverManagement and Governance

Architecture context

Data catalog connects architecture decisions to identity, dependency, monitoring, cost, and operations evidence for production Azure environments.

Security: Security for Data catalog starts with controlling who can discover sensitive assets, request access, curate metadata, approve policies, and connect cataloged data to downstream tools. Apply the right Azure identity, RBAC, networking, secret, policy, and diagnostic controls for the workload. Verification should use live resource state, deployment records, and logs rather than informal screenshots. The main risk is a catalog that exposes too much metadata can reveal sensitive business context, while a poorly governed catalog can send users toward unsafe data copies. Document the failure path if the Purview account, scan credential, access policy, stewardship role, or source-system permission changes, because that is where security controls often become operational incidents.
Cost: Cost for Data catalog comes from Purview capacity, scanning activity, data governance labor, integration work, metadata curation, access workflows, and remediation of poor-quality assets. A configuration that looks free can still increase background usage, security reviews, monitoring volume, or support effort. Review pricing at the whole workflow level, not just the named feature. Good teams tag owners, compare environments, watch utilization, set budgets where possible, and retire unused components before small recurring charges become normalized platform waste. Cost reviews should include the dependency services that make the pattern work in production. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible.
Reliability: Reliability for Data catalog depends on regular scans, source connectivity, metadata freshness, search health, lineage capture, stewardship review cycles, and consistent owner assignment. Test both the happy path and the failure path: stale metadata, failed scans, missing owners, duplicate assets, broken lineage, unreviewed access requests, and disconnected source systems. Production owners should know which metric or log proves the behavior is healthy, what alert fires first, and who can approve an emergency change. The design should include environment parity, rollback notes, recovery expectations, and service-specific limits so support teams are not rebuilding context during an outage. Keep owner, scope, evidence, and rollback visible.
Performance: Performance for Data catalog depends on catalog search responsiveness, scan duration, source size, metadata volume, lineage complexity, user query patterns, and access-request workflow delays. Measure it with production-shaped data and realistic failure modes, not a tiny test request. Check cold starts, retries, payload size, routing, scans, cache behavior, and logging overhead where they apply. Performance work should not weaken security or reliability; the best result is documented tuning that explains which metric improved, which tradeoff was accepted, and when the decision must be reviewed. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible.
Operations: Operations for Data catalog should be repeatable enough that another engineer can verify the same state without guessing. Keep source inventory, scan schedules, data product owners, glossary stewardship, access policy records, lineage reports, and health actions connected to the change record. Review the setting during deployments, access reviews, incident postmortems, cost reviews, and platform upgrades. Avoid one-off portal edits unless they are captured afterward in IaC or documented exception records. The operational goal is clear evidence: what exists, why it exists, how it is monitored, and when it should change. Keep owner, scope, evidence, and rollback visible. Keep owner, scope, evidence, and rollback visible.

Common mistakes

Treating Data catalog as a label instead of checking the exact resource, identity, dependency, and monitoring evidence.
Assuming development, test, and production are configured the same without comparing live output and deployment templates.
Running a mutating command during investigation before confirming blast radius, rollback steps, approval, and ownership.