Azure Databricks workspaces should use Unity Catalog for data governance

Without Unity Catalog, table and file permissions in Databricks are managed separately inside each workspace. That makes it hard to see who can reach which data, and the same dataset can end up with different rules in different places. Unity Catalog gives one place to define access, with auditing of who used what. Microsoft describes how it works in the Azure Databricks documentation: What is Unity Catalog?.

The practical risk is drift: a team creates a new workspace for a project, copies a few tables, and grants broad access to get moving. Months later nobody can say which workspace holds which copy of the data or who was allowed to read it. A shared metastore lets you answer that with one query instead of a tour of every workspace.

In the Azure portal open the Azure Databricks workspace and launch it. In the workspace, open Catalog and look at the catalog explorer: a workspace with a metastore shows Unity Catalog catalogs. An account admin can also open the Databricks account console, go to Workspaces and see which metastore each workspace uses.

A read-only command with the Databricks CLI, configured for the workspace:

databricks metastores current

An error saying that no metastore is assigned means the workspace is not using Unity Catalog.

A Databricks account admin creates a metastore in the account console (Catalog, then Create metastore), picks the region of the workspaces, and assigns the workspace to it. The same can be scripted with the account-level CLI:

databricks account metastores create --json '{"metastore_info": {"name": "<metastore-name>", "region": "<azure-region>"}}'
databricks account metastore-assignments create <workspace-id> <metastore-id>

Check the CLI help for the exact syntax of your CLI version. ConfigCobra only reads your environment and never changes it; the steps below are for you or your administrator to run.

Data owners and workspace admins start managing permissions with catalogs, schemas and grants rather than workspace-local settings. Existing tables that live only in the old workspace-local store are not governed until they are upgraded or recreated in a catalog, so plan that migration with the teams that own the data.

• Data engineers and analysts: need grants on the catalogs they use; queries can fail with permission errors until grants exist.
• Admins: gain a single audit trail for data access.
• Jobs and notebooks: references to legacy table names may need updating.

Run the change in a test workspace first.

Treat the rollout as a project rather than a switch. Start with one non-critical workspace, move a few datasets, and let the owning team confirm that their queries and jobs still behave as expected. Then repeat for the remaining workspaces in the same Azure region, since a metastore is attached to workspaces in its own region. The remediation impact view in ConfigCobra can show the affected resources and identities before you apply a fix.