12.2 Ownership, Inheritance & Access Control Patterns

Databricks Certified Data Analyst Associate Exam

Track your progress as you read

Finished sections get a check mark.

1 Platform Overview & Unity Catalog Foundations

1.1 Databricks Architecture & Compute Concepts 1.2 Databricks Marketplace & Data Sharing Basics 1.3 Unity Catalog Namespace & Object Hierarchy 1.4 Governed Asset Discovery & System Tables

2 Managing & Cleaning Governed Data

2.1 Dataset Discovery & Asset Tagging 2.2 Lineage Inspection & Data Traceability 2.3 SQL Data Cleaning & Transformation Techniques

3 Data Ingestion & Import Patterns

3.1 Workspace Uploads & Cloud File Ingestion 3.2 Incremental File Ingestion with Auto Loader 3.3 Ingesting Data via Delta Sharing & External Connections

4 Databricks SQL Warehouses & Core Querying

4.1 Databricks SQL Interface & SQL Assistant 4.2 SQL Warehouses Sizing & Management 4.3 Table Creation & Data Modification in Databricks SQL

5 Advanced SQL Authoring & Time Travel

5.1 Advanced Aggregations, Window Functions & Analytics 5.2 Complex Joins, CTEs & Set Operations 5.3 Views, Materialized Views & Delta Time Travel

6 Query Performance Analysis & Photon Engine

6.1 Photon Engine Architecture & Acceleration 6.2 Query History & Execution Profile Inspection 6.3 Delta Lake Audit History & Commit Logs

7 Liquid Clustering, Caching & Performance Troubleshooting

7.1 Caching Hierarchy in Databricks SQL 7.2 Data Layout Optimization: Liquid Clustering vs Partitioning & Z-Ordering 7.3 Troubleshooting Slow & Failing Queries

8 AI/BI Dashboards & Visualization Design

8.1 AI/BI Dashboards Overview & Canvas Layout 8.2 Chart Types & Visualization Selection 8.3 Notebook & SQL Editor Visualizations

9 Dashboard Interactivity, Publishing & Alerts

9.1 Dashboard Parameters & Interactive Filtering 9.2 Publishing, Sharing & Access Control 9.3 Scheduled Refresh, Email Subscriptions & Alerts

10 Developing & Maintaining AI/BI Genie Spaces

10.1 AI/BI Genie Architecture & Space Setup 10.2 Curation via Instructions, Descriptions & Sample Questions 10.3 Trusted Assets & Parameterized Functions 10.4 Monitoring, Benchmarks, Feedback & Maintenance

11 Data Modeling & Medallion Architecture

11.1 Dimensional Modeling Fundamentals 11.2 Medallion Architecture for Analytics 11.3 Constraint Enforcement & Relationships in Unity Catalog

12 Securing Data & Unity Catalog Governance

12.1 Unity Catalog Privilege Model & Grants 12.2 Ownership, Inheritance & Access Control Patterns 12.3 Fine-Grained Security: Row Filters & Column Masks

12.2 Ownership, Inheritance & Access Control Patterns

Key Takeaways Explain This Topic AI

Every securable object in Unity Catalog has exactly one owner (initially the creating principal or parent catalog/schema owner).

Privilege inheritance flows down the object hierarchy: granting SELECT on a schema automatically grants SELECT on all current and future tables and views within that schema.

Transferring object ownership requires the REASSIGN OWNERSHIP or ALTER <object> OWNER TO command, executed by the current owner or a metastore admin.

Object owners automatically possess ALL PRIVILEGES on their objects and are the only principals (alongside metastore admins) who can grant or revoke privileges on those objects.

Production access control patterns enforce separation of environments (dev/test/prod) by isolating catalogs and assigning distinct group owners per catalog.

Last updated: July 2026

In Databricks Unity Catalog , managing security efficiently at scale requires a clear understanding of object ownership , hierarchical privilege inheritance , and enterprise access control patterns . While individual privilege grants ( GRANT SELECT ON TABLE ) work for small projects, enterprise data governance relies on cascading permissions down the 3-level namespace and isolating environments across catalogs. This section details how ownership operates, how privilege inheritance flows, and how to implement production-grade governance architectures.

The Unity Catalog Ownership Model

Every securable object in Unity Catalog—whether a metastore, catalog, schema, table, view, volume, or function—has exactly one principal designated as its owner . Ownership represents the ultimate administrative authority over that specific object.

Key Rules of Object Ownership

Default Creator Ownership : By default, when a user or service principal creates an object (e.g., executing CREATE TABLE ), that creating principal automatically becomes the initial owner of the object.

Automatic Owner Capabilities : The owner of an object possesses implied ALL PRIVILEGES on that object. Owners can modify table schema ( ALTER ), delete data ( DELETE / TRUNCATE ), drop the object entirely ( DROP ), and grant or revoke privileges on that object to other principals ( GRANT / REVOKE ).

Exclusive Permission Management : Only the object owner, the owner of a parent container (e.g., schema owner), or a Metastore Admin can grant or revoke privileges on a securable object. Non-owner users cannot delegate access to others even if they hold SELECT or MODIFY .

Transferring Ownership : Ownership can be transferred to another principal using the ANSI SQL ALTER ... OWNER TO command: -- Transferring table ownership to a functional group

ALTER TABLE production_catalog.finance_schema.quarterly_revenue
OWNER TO `group_finance_engineers`;

- Transferring schema ownership
ALTER SCHEMA production_catalog.finance_schema
OWNER TO `group_finance_leads`;

Critical Best Practice : Databricks strongly recommends assigning object ownership to account-level groups or Service Principals rather than individual human user accounts. If an individual employee leaves the company and their user account is deactivated, any objects owned by that individual become orphaned, causing administrative locks and pipeline failures.

Hierarchical Privilege Inheritance

Unity Catalog implements hierarchical privilege inheritance , meaning that permissions granted at a higher level in the 3-level namespace automatically cascade down to all child objects contained within that namespace. Metastore (Top Level)

└── Catalog (e.g., main_catalog) --> Grant USE CATALOG, SELECT here
└── Schema (e.g., sales_db) --> Cascades SELECT to all tables/views
├── Table 1 (orders) --> Automatically inherits SELECT
├── Table 2 (line_items) --> Automatically inherits SELECT
└── View 1 (daily_summary) --> Automatically inherits SELECT
Inheritance Cascade Rules

Catalog-Level Grants : Granting SELECT on a catalog automatically grants SELECT on all existing schemas, tables, and views within that catalog, as well as any schemas and tables created in that catalog in the future.

Schema-Level Grants : Granting SELECT on a schema automatically grants SELECT on all current and future tables and views inside that schema.

Inherited vs. Explicit Grants : Privileges inherited from a parent container are non-blocking and cumulative. If a user has SELECT via schema inheritance, adding an explicit GRANT SELECT ON TABLE is redundant.

Non-Revocability at Child Level : An inherited privilege cannot be revoked at the child level . For example, if group_analysts has SELECT granted on schema_finance , executing REVOKE SELECT ON TABLE schema_finance.payroll FROM GROUP group_analysts; will fail or have no effect. To restrict access to payroll , access must be granted at the individual table level rather than the schema level, or managed via row/column security policies.

Production Access Control Design Patterns

Enterprise Databricks deployments organize Unity Catalog namespaces to achieve strict environmental isolation and least-privilege administrative boundaries.

Access Control Pattern Architecture & Catalog Design Privilege Allocation Strategy

Environmental Isolation (Dev / Test / Prod) Separate catalogs for environments: dev_catalog , test_catalog , prod_catalog . Engineers get CREATE and MODIFY in dev_catalog . Automated CI/CD Service Principal owns prod_catalog . Analysts receive read-only ( SELECT ) on prod_catalog .

Functional Domain Catalogs Catalogs partitioned by business unit: sales_catalog , hr_catalog , finance_catalog . Domain engineering groups (e.g., group_hr_devs ) own their respective domain catalog. Cross-domain grants are strictly audited.

Gold Data Mart Layer Curated catalog hosting enterprise reporting datasets: gold_analytics_catalog . Owned by central data governance team. Broad USE CATALOG + USE SCHEMA + SELECT granted to account-level group group_all_employees .

Comparative Matrix: Ownership vs Grants

Operation / Capability Object Owner Metastore Admin Explicit Grantee ( SELECT / MODIFY ) Inherited Grantee
Read Data ( SELECT ) Yes Yes Yes Yes
Write Data ( MODIFY ) Yes Yes If Granted ( MODIFY ) If Granted
Change Schema ( ALTER ) Yes Yes No No
Drop Object ( DROP ) Yes Yes No No
Grant/Revoke Access Yes Yes No No
Transfer Ownership Yes Yes No No
Real-World Exam Scenarios & Edge Cases
Scenario 1: Managing Schema-Level Inheritance Restrictions

Problem : The data security team grants GRANT SELECT ON SCHEMA prod.marketing TO GROUP analysts; . Later, a sensitive table prod.marketing.customer_surveys is created. The admin attempts REVOKE SELECT ON TABLE prod.marketing.customer_surveys FROM GROUP analysts; , but analysts can still query the table.

Root Cause : Inherited permissions at the schema level override table-level revokes.

Solution : Revoke SELECT from GROUP analysts at the schema level ( REVOKE SELECT ON SCHEMA prod.marketing FROM GROUP analysts; ), and grant SELECT individually on non-sensitive tables.

Scenario 2: Preventing Orphaned Production Assets

Problem : A senior data engineer builds 50 tables in prod_catalog under their personal user identity alex@company.com . When Alex leaves the company, HR disables the account, preventing remaining engineers from altering or granting access to the tables.

Solution : Reassign ownership to a production group immediately:

ALTER TABLE prod_catalog.sales.orders OWNER TO group_data_engineers ; or reassign all assets using Metastore Admin capabilities.

Summary Checklist for Exam Readiness

Object owners have implied full control, including DDL, dropping, and granting access.

Always use account-level groups for object ownership to avoid orphaned assets.

Schema and catalog level grants cascade down to all existing and future child objects.

Inherited grants cannot be revoked at the child level—you must manage grants at the appropriate container level.