Data Sharing and Federation: Databricks Data Engineer Professional Practice Questions

A provider wants to share live, read-only Delta tables from a Unity Catalog-enabled workspace to external consumers who will query using non-Databricks tools (for example, pandas or Power BI). Which authentication approaches are supported for open Delta Sharing recipients?

1. AOnly a Databricks sharing identifier; bearer tokens and OIDC are not supported for open sharing.
2. BOnly OAuth via Databricks-to-Databricks identity; open sharing always requires the recipient to run on Databricks.
3. CEither a long-lived bearer token or OpenID Connect (OIDC) token federation to obtain short-lived OAuth tokens.
4. DKerberos tickets issued by the provider workspace; open sharing uses Hive metastore authentication.

A provider shares a Delta table with history using Delta Sharing open sharing. The recipient asks whether the provider must replicate data into a separate shared storage account and whether the data will stay up-to-date. Which response is most accurate?

1. AYes—Delta Sharing requires a full copy of the data into a new storage location owned by the recipient; updates are delivered by periodic snapshot exports.
2. BNo—Delta Sharing is designed for live, zero-copy sharing; recipients access shared data read-only and provider updates appear in near real time without needing replication.
3. CYes—Delta Sharing always materializes the entire table on the provider side before recipients can query it, so updates are only visible after a manual refresh.
4. DNo—Delta Sharing data is always cached permanently in Databricks-managed storage so the recipient never incurs network transfer.

A provider wants to share a Unity Catalog volume to a recipient. Which statement is correct about volume sharing in Delta Sharing?

1. AVolumes can be shared using either open sharing (D2O) or Databricks-to-Databricks (D2D) sharing.
2. BVolumes cannot be shared using Delta Sharing; only Delta tables are supported.
3. CVolumes can only be shared using the Databricks-to-Databricks (D2D) sharing flow.
4. DVolumes can only be shared using a customer-managed open-source Delta Sharing server.

A data provider on Databricks with Unity Catalog must share a curated Delta table with two consumers: (1) a partner organization that also runs Databricks with Unity Catalog, who should be able to reference the shared data as a catalog and have new data appear without re-copying, and (2) an external analytics team that uses pandas and Apache Spark on their own infrastructure with no Databricks account. The provider wants a single sharing technology, live (no-copy) access for both, and centralized governance of grants. Which approach is correct?

1. AUse Lakehouse Federation to register the provider's Unity Catalog as a foreign catalog in the partner's workspace, and for the external team expose a JDBC endpoint; federation gives live access without any recipient objects for either consumer.
2. BUse Databricks-to-Databricks Delta Sharing for the partner, and for the external team export the table to Parquet on a nightly schedule to a shared cloud bucket, because the open Delta Sharing protocol only supports Databricks recipients and cannot serve non-Databricks clients.
3. CCreate a Delta DEEP CLONE of the table into each recipient's cloud storage account and grant them read access to the clone; deep clone keeps the copies in sync automatically, providing live access without exposing the provider's metastore.
4. DPublish the table to a Databricks Marketplace listing for the partner and generate a personal access token (PAT) for the external team to call the Databricks Jobs REST API and pull table snapshots, since Delta Sharing does not support token-based external access.
5. EUse Delta Sharing for both: add the Databricks partner as a Unity Catalog recipient with a metastore sharing identifier (Databricks-to-Databricks), and add the external team as an open-sharing recipient authenticated with a bearer token that they consume via the open Delta Sharing protocol connector — both read live data with no data copy.

Your team is deciding between query federation and catalog federation within Lakehouse Federation. Which statement best describes the execution and cost characteristics?

1. AQuery federation pushes down work to the foreign database using JDBC, executing both in Databricks and remote compute; catalog federation directly accesses object storage and runs only on Databricks compute, often making it more cost-effective/performance-optimized.
2. BCatalog federation pushes down queries over JDBC and executes using remote database compute, which is why it is best for ad hoc access.
3. CQuery federation reads foreign tables directly from object storage and runs only on Databricks compute, which is usually the most cost-effective option.
4. DBoth federation types are identical; the only difference is whether you create a connection using the UI or SQL.

A provider shares a streaming Silver orders table through Databricks-to-Databricks Delta Sharing. The recipient reports that a query they ran last week returned different (fewer) rows than the same query today, and they ask whether the provider is 'pushing' updates to them. The provider wants to explain the correct behavior and ensure the recipient can also consume the shared table incrementally as a streaming source. Which statement and configuration are correct?

1. ADelta Sharing only supports full-table batch reads and always returns the latest full snapshot; the differing counts are expected, but incremental/streaming consumption is impossible, so the recipient must diff successive full reads themselves to detect new rows.
2. BThe row-count change means the share is stale; Delta Sharing snapshots the table at share-creation time, so the provider must recreate the share after every batch to publish new rows, and streaming consumption is not supported over Delta Sharing.
3. CDelta Sharing pushes each committed transaction to the recipient's metastore as it happens, so the differing counts indicate a replication lag; the recipient should increase their sync frequency setting to receive pushes sooner. Streaming reads require the recipient to enable Change Data Feed on the provider's table themselves.
4. DThe recipient must be seeing uncommitted data; Delta Sharing exposes the writer's in-progress transactions, so counts fluctuate mid-write. To stabilize, the provider should share a materialized snapshot table instead, which also enables streaming because snapshots carry a checkpoint.
5. EDelta Sharing gives the recipient live read access to the current committed state of the shared table, so newly committed rows appear on the recipient's next query with no copy or push; to consume incrementally, the recipient can read the share as a Spark structured streaming source (Delta Sharing streaming), and the provider can enable history sharing so change/streaming reads work.

A provider shares data with an external open-protocol recipient via a bearer token embedded in a credential file. Security policy requires that the token be rotated periodically and that a leaked token can be invalidated immediately without permanently destroying the sharing relationship or its grants. Using Unity Catalog Delta Sharing, which action set meets these requirements?

1. ARevoke the SELECT grant on every shared table to invalidate the token, then re-grant after issuing a new one; grants and tokens are the same object in Delta Sharing, so revoking access is how a token is rotated.
2. BDelete the recipient and recreate it with the same name whenever rotation is needed; recreating the recipient is the only supported way to change its token, and the shares automatically re-attach because they are keyed by recipient name.
3. CEdit the credential file distributed to the recipient to contain a new random token; because the token is validated only by string length and format, changing the file value on the recipient side immediately rotates the credential server-side.
4. DRotate the recipient's token with the Unity Catalog recipient token-rotation operation, which issues a new credential and (optionally with an immediate expiration on the old one) invalidates the previous token, while the recipient object, its shares, and grants remain intact.
5. ESet the metastore-level delta.sharing.tokenLifetime to zero and toggle it back, which forces all recipient tokens to regenerate at once; per-recipient rotation is not supported, so it must be done globally.

A data engineer must let analysts query tables that live in an external PostgreSQL database directly from Databricks SQL, without copying the data into Delta, while enforcing Unity Catalog permissions on the federated tables. Which sequence of Unity Catalog objects correctly sets up Lakehouse Federation for this source?

1. ACreate a Delta Sharing recipient for the PostgreSQL server and add it to a share; Delta Sharing's open protocol federates any JDBC-compatible source, exposing its tables as a shared catalog governed by Unity Catalog.
2. BCreate an external location and a storage credential pointing at the PostgreSQL data files, then register the tables as external Delta tables over those files; Unity Catalog governs the external tables and reads them in place from the database's underlying storage.
3. CMount the PostgreSQL database to DBFS with a JDBC mount point, then create views over the mount; the mount provides live federated access and Unity Catalog permissions are inherited from the DBFS mount ACLs.
4. DUse spark.read.format('jdbc') inside a scheduled job to load each PostgreSQL table into a managed Delta table nightly, then grant analysts SELECT on the Delta copies; this is what Lakehouse Federation does under the hood, so no Connection object is needed.
5. ECreate a Unity Catalog Connection to the PostgreSQL server (holding host, port, and credentials), then create a foreign catalog that references that connection and maps the PostgreSQL database; analysts then query it as catalog.schema.table with Unity Catalog governing access, and queries are pushed down to PostgreSQL at run time.