Data Engineer Professional · 20% of the exam

Databricks Tooling: free practice questions

5 sample questions from our 50-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Databricks exam.

1. An organization wants to share a Delta table containing aggregated sales data with a partner company that uses a non-Databricks platform (e.g., Apache Spark on their own infrastructure). The data must remain in the provider's storage and the partner should only have read access. Which Databricks feature is MOST appropriate for this use case?

  • A. Unity Catalog external location shared via IAM cross-account role
  • B. Delta Sharing, using an open protocol that allows the recipient to access data without a Databricks account✓ Correct
  • C. Unity Catalog with cross-workspace catalog binding to the partner's workspace
  • D. Databricks Repos with the Delta table exported as Parquet files and pushed to a shared Git repository
Explanation

Delta Sharing is an open protocol specifically designed to share live Delta tables with external parties, including those not using Databricks. The data stays in the provider's storage, and recipients receive read-only access via a sharing URL and credential token. Option A is incorrect because sharing an IAM role with an external party is a security anti-pattern and does not provide the governed, read-only sharing model needed. Option C is incorrect because cross-workspace catalog binding is for sharing within the same Databricks organization/metastore, not with external non-Databricks parties. Option D is an anti-pattern that involves copying data, breaks the 'live' requirement, and introduces security and governance risks.

2. A data engineering team uses Databricks Repos integrated with a Git provider. A team member accidentally committed a notebook containing a hard-coded API key directly to the `main` branch and pushed it to the remote repository. The team wants to remove the secret from the repository history. Which TWO actions should the team take as immediate remediation steps within Databricks and their Git workflow? (Select TWO)

  • A. Rotate/revoke the exposed API key in the target system immediately, since the secret is already compromised regardless of Git history cleanup.✓ Correct
  • B. Use the Databricks Repos UI to revert the commit, which will purge the secret from the full Git history on the remote.
  • C. Perform a `git filter-repo` or equivalent history-rewriting operation on the remote repository to remove the secret from all historical commits, then force-push the rewritten history.✓ Correct
  • D. Delete the Databricks Repo object from the workspace and re-clone the repository; this removes the secret from the remote Git provider's history.
  • E. Store the API key in a Databricks secret scope and update the notebook to reference it via `dbutils.secrets.get()` to prevent future exposure.
  • F. Open a support ticket with Databricks to have the secret scrubbed from the Unity Catalog audit logs where it may have been captured.
Explanation

**Option A** is correct — rotating/revoking the compromised credential is the single most critical immediate action; the secret must be treated as compromised the moment it was pushed. **Option C** is correct — to truly remove a secret from Git history, a history-rewriting tool like `git filter-repo` (or BFG Repo Cleaner) must be used on the remote, followed by a force-push; this is the standard Git remediation. Option B is incorrect — the Databricks Repos UI only manages the working state of the repo (branch switching, pull, commit, push); it cannot rewrite remote Git history. Option D is incorrect — deleting and re-cloning the Repo object in Databricks only affects the local workspace copy; the remote Git provider's history is completely unaffected. Option E is a good *future prevention* best practice but is not an immediate remediation for the already-exposed secret. Option F is incorrect — Databricks Unity Catalog audit logs record API actions, not notebook cell content or committed file contents; the secret would not be captured there.

3. A Databricks administrator defines the following cluster policy JSON snippet: ```json { "node_type_id": { "type": "fixed", "value": "i3.xlarge" }, "autoscale.min_workers": { "type": "range", "minValue": 1, "maxValue": 4 }, "spark_conf.spark.databricks.delta.preview.enabled": { "type": "fixed", "value": "true", "hidden": true } } ``` A data scientist uses this policy to create a cluster. Which of the following outcomes correctly describes the cluster's behavior?

  • A. The data scientist can choose any node type but is limited to between 1 and 4 workers.
  • B. The cluster will always use `i3.xlarge` nodes, can scale between 1 and 4 workers, and the Delta preview Spark config is set but not visible to the user in the cluster creation UI.✓ Correct
  • C. The cluster will always use `i3.xlarge` nodes, but the data scientist can set autoscaling min workers to 0 since only the max is restricted.
  • D. The `hidden: true` flag causes the Spark config to be excluded from the cluster entirely; it is only used for policy documentation purposes.
Explanation

In a cluster policy, `type: fixed` locks a value so users cannot change it. `type: range` restricts a numeric value within min/max bounds. `hidden: true` means the fixed value is applied to the cluster but is not shown in the cluster creation UI, preventing users from seeing or overriding it. Therefore: the node type is locked to `i3.xlarge`, workers must be between 1 and 4, and the Delta config is silently applied. Option A is wrong — node type is `fixed`, not user-configurable. Option C is wrong — `minValue: 1` means the minimum is restricted to at least 1; 0 is outside the allowed range. Option D is wrong — `hidden: true` does not exclude the config; it applies it invisibly.

4. A company has a Unity Catalog metastore and wants to give the group `data_scientists` the ability to create new tables in any schema within the catalog `research`, but NOT allow them to drop or alter existing tables. Which combination of privileges achieves this with the LEAST permissive grant?

  • A. GRANT ALL PRIVILEGES ON CATALOG research TO `data_scientists`
  • B. GRANT USE CATALOG ON CATALOG research TO `data_scientists`; GRANT CREATE TABLE ON CATALOG research TO `data_scientists`
  • C. GRANT USE CATALOG, USE SCHEMA ON CATALOG research TO `data_scientists`; GRANT CREATE TABLE ON ALL SCHEMAS IN CATALOG research TO `data_scientists`
  • D. GRANT USE CATALOG ON CATALOG research TO `data_scientists`; GRANT CREATE TABLE, USE SCHEMA ON ALL SCHEMAS IN CATALOG research TO `data_scientists`✓ Correct
Explanation

To create tables, a user needs USE CATALOG on the catalog, USE SCHEMA on each schema they operate in, and CREATE TABLE privilege. Option D correctly grants USE CATALOG at the catalog level and then grants both USE SCHEMA and CREATE TABLE on all schemas within the catalog, scoping permissions appropriately. Option A grants ALL PRIVILEGES which is overly permissive and would allow dropping/altering tables. Option B omits USE SCHEMA, which is required to navigate into any schema. Option C attempts to grant USE SCHEMA at the catalog level, which is an invalid syntax; USE SCHEMA must be granted at the schema level or via ALL SCHEMAS IN CATALOG.

5. A lead data engineer is designing a Unity Catalog security model. They need to allow a new service principal `etl_sp` to create and manage tables within the schema `gold_catalog.reporting`, but `etl_sp` should NOT be able to create new schemas or modify the catalog itself. Additionally, they need to verify which privileges `etl_sp` currently holds. Which combination of actions correctly satisfies ALL requirements? (Select THREE)

  • A. GRANT CREATE TABLE, MODIFY ON SCHEMA gold_catalog.reporting TO etl_sp;✓ Correct
  • B. GRANT USE CATALOG ON CATALOG gold_catalog TO etl_sp;✓ Correct
  • C. GRANT USE SCHEMA ON SCHEMA gold_catalog.reporting TO etl_sp;✓ Correct
  • D. GRANT CREATE SCHEMA ON CATALOG gold_catalog TO etl_sp;
  • E. GRANT ALL PRIVILEGES ON CATALOG gold_catalog TO etl_sp;
  • F. Run SHOW GRANTS ON SCHEMA gold_catalog.reporting; and SHOW GRANTS ON CATALOG gold_catalog; to audit etl_sp's privileges
Explanation

To allow `etl_sp` to create and manage tables in `gold_catalog.reporting` without broader catalog-level control, you need three grants: (A) GRANT CREATE TABLE and MODIFY on the specific schema — this allows creating and modifying tables within `reporting`. (B) GRANT USE CATALOG on `gold_catalog` — required for the principal to navigate into the catalog at all; without this, no operations inside the catalog are possible. (C) GRANT USE SCHEMA on `gold_catalog.reporting` — required to access objects within the schema. Together, A+B+C provide exactly the right level of access. Option D (CREATE SCHEMA) would allow `etl_sp` to create new schemas in the catalog, which violates the requirement. Option E (ALL PRIVILEGES on the catalog) is far too permissive and violates least privilege. Option F describes auditing with SHOW GRANTS, which is a useful practice but does not fulfill any of the stated *requirements* for access setup; it also only shows current grants and would not verify historical privileges.

45 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free
Databricks Tooling — Free Data Engineer Professional Practice Questions | DataCertPrep — Certification Prep