An Apache Spark-based analytics platform optimized for Azure.
Hi @Nasir SM
Thank you for reaching out to the Microsoft Q&A forum.
Azure Databricks RBAC can be confusing because permissions are managed across multiple layers, and each layer serves a different purpose.
1. Azure RBAC
Azure RBAC controls access to the Azure Databricks workspace resource itself. For example, roles such as Reader, Contributor, and Owner determine who can view or manage the Azure resource. However, having Contributor or Owner access in Azure does not automatically grant access to notebooks, clusters, or data within Databricks.
2. Databricks Workspace Permissions
Within the Databricks workspace, permissions are managed separately for workspace objects such as notebooks, folders, jobs, compute clusters, SQL warehouses, and repositories. Users must be granted the appropriate permissions to access or manage these resources.
3. Unity Catalog Permissions
If Unity Catalog is enabled, it governs access to data assets such as catalogs, schemas, tables, views, and volumes. A user may require privileges such as USE CATALOG, USE SCHEMA, and SELECT before they can query data.
Simple Example
A user may have Contributor access to the Azure Databricks workspace in Azure Portal but still be unable to view a notebook or query a table because the required Databricks workspace permissions or Unity Catalog privileges have not been granted.
A simple way to think about it is:
Azure RBAC → Controls access to the Azure resource Databricks Workspace Permissions → Controls access to workspace assets Unity Catalog Permissions → Controls access to data
When troubleshooting access issues, it is important to verify permissions at all three layers separately. In most cases, understanding which layer is enforcing the restriction helps resolve the confusion around RBAC in Azure Databricks.