Best Governance Practice for Providing Access to Production Catalogs in Lower Environments (UC)

[Charansai]

Hi everyone,

I'm a Cloud Engineer working on a multi-environment Databricks setup (Dev, QA, Prod), and I've received a request from our Data Engineering team that's a bit unconventional — they are asking for access to Production Unity Catalogs from lower environments (Dev/QA).

The rationale they’ve provided is that this access would help them:

• Debug production issues more efficiently
• Validate data discrepancies
• Reproduce production scenarios locally without affecting live data

While I understand the operational benefits, I'm concerned about governance, security, and data compliance risks, especially with exposing production data to non-production environments.

Before I proceed further, I wanted to consult the community:

What are the best practices or governance policies around this scenario?
Are there any secure ways to simulate or expose production data safely in lower environments without violating data integrity or compliance rules (e.g., masking, snapshotting, Delta Sharing)?
 Is it ever considered a good practice to grant direct access from Dev/QA to Prod catalogs, or should we avoid it altogether?
Are there any official recommendations from Databricks/Microsoft regarding cross-environment catalog access via Unity Catalog?

• All workspaces are in separate Virtual Networks and are governed through service principals and cluster policies

Would love to hear how other organizations have tackled this. Appreciate any guidance, war stories, or architectural suggestions you can share.

Thanks!

Note: Please explain in detail so that I can progress Fastly and I work in Azure Environment

[Sai_Ponugoti]

Hi @Charansai ,
That's a great question!

In general, granting Dev/QA users direct access to Production catalogs is not considered best practice. The main risks you already mentioned (governance, compliance, and accidental writes) usually outweigh the convenience of debugging in Prod. Most orgs I’ve worked with keep Prod strictly isolated and use safer patterns to give engineers the context they need.

However, you could restrict the kind of data those users handle by using Row filtering, Data masking, and attribute-based access controls. Start by onboarding those users into the prod workspace and assigning them a group. Then, you can define policies based on that group to control what data they have visibility of, and you can also create a compute policy for this new group.

You could also share production data via delta sharing. You can share a limited subset of Production data in a controlled, read-only way. That way, engineers get just enough for validation/debugging, but you don’t open the full Production catalog.

Furthermore you can use tools like audit logs, query history, or monitoring dashboards can help engineers debug without needing direct Prod access.

Please let me know if you have any questions.
Thank you