5.4 Delta Sharing

Databricks Certified Data Engineer Associate Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the Databricks Certified Data Engineer Associate Exam Study Plan and Strategies

2 Domain 1: Databricks Intelligence Platform (10%)

1.1 The Lakehouse Architecture 1.2 Databricks Workspace and Components 1.3 Delta Lake Fundamentals 1.4 Databricks Repos, Secrets, and Development Tools 1.5 Databricks SQL and the Photon Engine 1.6 Databricks Runtime and Compute Configuration

3 Domain 2: Development and Ingestion (30%)

2.1 Auto Loader (cloudFiles) 2.2 Reading Data with Spark SQL and PySpark 2.3 Writing Data to Delta Tables 2.4 Spark SQL Query Fundamentals 2.5 Complex Data Types and Higher-Order Functions 2.6 User-Defined Functions (UDFs) 2.7 Structured Streaming Fundamentals 2.8 Databricks Notebooks and Code Execution 2.9 Data Extraction from External Sources 2.10 Table Management and Properties

4 Domain 3: Data Processing & Transformations (31%)

3.1 The Medallion Architecture (Bronze, Silver, Gold) 3.2 Delta Lake Optimization: OPTIMIZE, VACUUM, and Liquid Clustering 3.3 Advanced SQL Transformations 3.4 Incremental Data Processing Patterns 3.5 Lakeflow Declarative Pipelines (Delta Live Tables) 3.6 Implementing a Multi-Hop Pipeline 3.7 Slowly Changing Dimensions (SCD) Patterns 3.8 Data Deduplication Strategies

5 Domain 4: Productionizing Data Pipelines (18%)

4.1 Databricks Workflows and Lakeflow Jobs 4.2 Databricks Asset Bundles (Declarative Automation Bundles) 4.3 Pipeline Monitoring, Alerting, and Error Handling 4.4 Testing and Deployment Best Practices 4.5 Pipeline Performance and Cost Optimization 4.6 Designing Idempotent and Recoverable Pipelines

6 Domain 5: Data Governance & Quality (11%)

5.1 Unity Catalog: Architecture and Three-Level Namespace 5.2 Access Control and Permissions 5.3 Data Lineage and Audit Logging 5.4 Delta Sharing 5.5 Lakehouse Federation 5.6 Data Quality Best Practices 5.7 Row-Level and Column-Level Security 5.8 Compliance and PII Data Management

Key Takeaways Explain This Topic AI

Delta Sharing is an open protocol for secure, cross-platform data sharing without copying or replicating the underlying data.

Databricks-to-Databricks sharing targets recipients on Unity Catalog and uniquely supports sharing notebooks, volumes, and models.

Open sharing targets non-Databricks recipients using bearer-token credentials (or OIDC federation), readable by any Delta Sharing client.

A share is a named collection of data assets the provider exposes; a recipient is the named entity that consumes a share.

The provider always retains governance — recipients read live data through the protocol and never get a physical copy.

Last updated: June 2026

Quick Answer: Delta Sharing is an open protocol for sharing live data across platforms and organizations without copying it . A provider packages assets into a share and grants it to a recipient . Two modes exist: Databricks-to-Databricks (UC recipients; uniquely supports notebooks, volumes, and models) and open sharing (any client, via bearer-token credentials).

What Delta Sharing Is

Delta Sharing solves cross-organization data exchange. Traditionally you would FTP files, replicate to a recipient's system, or stand up a custom API — all of which copy data, drift out of date, and create governance gaps. Delta Sharing instead exposes live, read-only access to data in place : the recipient queries the provider's data through the protocol and always sees the current version, with no replication . Because it is an open protocol (with open-source clients for pandas, Spark, Power BI, and more), the recipient does not need to be a Databricks customer — a key differentiator the exam emphasizes.

Shares and Recipients

Two objects define a sharing relationship, and both are Unity Catalog securables:

Object Definition

Share A named, read-only collection of data assets (tables, views, volumes, notebooks, models) that a provider exposes

Recipient The named entity (an organization or principal) that a share is granted to

The workflow: an admin creates a share , adds assets to it, creates a recipient , and grants the share to that recipient. Privileges like CREATE SHARE , USE SHARE , and CREATE RECIPIENT govern who can do this. The provider keeps full control — they can add or remove assets and revoke the share at any time, and all recipient access is captured in audit logs.

Two Sharing Modes

Databricks-to-Databricks (D2D) sharing is used when the recipient also has a Unity Catalog-enabled Databricks workspace (on any cloud — AWS, Azure, or GCP). It is the most secure mode because identity is managed through UC on both sides, with no tokens to distribute. D2D is also the way to share across different metastores in your own account . Critically, D2D is the only mode that can share notebooks, volumes, and models — open sharing supports tables and views only.

Open sharing is used when the recipient is not a Databricks user or lacks a UC-enabled workspace. The provider issues bearer-token credentials (or uses OIDC federation ) that any Delta Sharing client can use to read the data.

Databricks-to-Databricks Open sharing
Recipient UC-enabled Databricks Any Delta Sharing client
Auth Managed UC identity Bearer token / OIDC
Notebooks, volumes, models Yes No
Tables, views Yes Yes

Remember: the deciding factor between modes is whether the recipient is on Unity Catalog .

The Sharing Workflow and Providers

Delta Sharing introduces a small set of objects beyond shares and recipients. On the consuming side, a provider object represents the organization you are receiving data from; the recipient mounts the provider's shares as a catalog and queries them in the normal three-level namespace. Privileges such as CREATE PROVIDER , USE PROVIDER , CREATE RECIPIENT , and USE RECIPIENT govern these flows.

A typical provider workflow:

CREATE SHARE sales_share;
ALTER SHARE sales_share ADD TABLE prod.sales.orders;
CREATE RECIPIENT partner_co; (Databricks generates a credential or links a UC sharing identifier)
GRANT SELECT ON SHARE sales_share TO RECIPIENT partner_co;

The recipient then sees a read-only catalog and queries the live data. Because access is read-only and in place, the provider never loses control of the source.

Governance and Security of Shares

Everything a recipient does is captured in audit logs , so the provider can see exactly which shared tables were read and when. The provider can revoke a share or rotate credentials at any time, immediately cutting off access. For open sharing, the bearer token is the credential, so it must be transmitted securely and rotated periodically; this is why Databricks-to-Databricks sharing — which uses managed UC identity instead of tokens — is considered the more secure mode when both parties are on Unity Catalog.

Delta Sharing also supports sharing across metastores within one account , which is how large enterprises move data between regional metastores without copying it.

Why Delta Sharing Matters for the Exam

The core idea to retain is that Delta Sharing breaks the historical trade-off between sharing data and keeping control of it. Old approaches forced a copy — once a partner had your file, you could not govern it, and it was stale the moment it left. Delta Sharing's open protocol gives recipients live, read-only access in place , so the provider keeps governance, the data is always current, and access is fully audited and revocable.

The single decision that drives implementation is whether the recipient is on Unity Catalog : if yes, Databricks-to-Databricks sharing uses managed identity and unlocks notebooks, volumes, and models; if no, open sharing issues a bearer token (or OIDC) that any open-source client can consume for tables and views. Do not confuse Delta Sharing with Lakehouse Federation — Sharing is outbound distribution of your data, while Federation is inbound querying of others' systems. Both avoid copying data, but they solve opposite directions of the interoperability problem.