Data Engineer Professional · 10% of the exam

Debugging and Deploying: free practice questions

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

1. A data engineering team is setting up a CI pipeline using GitHub Actions for a Databricks project managed with Databricks Asset Bundles. They want to run unit tests (using pytest) on every pull request BEFORE deploying to any Databricks workspace. Which GitHub Actions step configuration BEST achieves this?

  • A. A step that runs `databricks bundle validate` followed by `databricks bundle deploy --target dev` and then triggers the test job via `databricks bundle run`.
  • B. A step that installs Python dependencies from `requirements-test.txt` and runs `pytest tests/unit/` directly in the GitHub Actions runner, without connecting to any Databricks workspace.✓ Correct
  • C. A step that uses the `databricks/run-notebook` GitHub Action to execute a test notebook on an existing always-on development cluster.
  • D. A step that packages the project as a wheel using `python setup.py bdist_wheel` and uploads it to a test PyPI index for validation.
Explanation

Unit tests should be fast, isolated, and not require external infrastructure. Running pytest directly in the GitHub Actions runner (which has Python available) executes the unit tests in a pure Python/PySpark local mode environment without any Databricks workspace dependency. This is the correct separation: unit tests run in CI without workspace connectivity; integration/deployment tests may involve a workspace. Option A deploys to a dev workspace before tests pass, which inverts the correct CI order. Option C uses an always-on cluster (cost waste, no isolation) and runs tests as a notebook, which is an integration test pattern, not unit testing. Option D (building a wheel and uploading to PyPI) is a packaging step, not a test execution step.

2. When debugging why a Spark job is slow or failing on a specific stage, which tool gives detailed insight into stages, tasks, shuffles, and skew?

  • A. The Spark UI (stages/tasks/SQL tabs)✓ Correct
  • B. The Delta Sharing provider page
  • C. A cluster policy
  • D. dbutils.widgets
Explanation

The Spark UI shows stages, tasks, shuffle sizes, and skew, making it the primary tool for diagnosing performance and failures. Delta Sharing (B), cluster policies (C), and widgets (D) don't expose execution internals.

3. An organization uses Delta Live Tables (DLT) for their ingestion pipeline. After a bad deployment introduced a data quality issue, they want to roll back the pipeline's output tables to their state from 48 hours ago. Which approach is MOST appropriate?

  • A. Delete the DLT pipeline and recreate it, pointing to a backup storage location created before the deployment.
  • B. Use Delta time travel to query each output table `AS OF` a timestamp 48 hours ago and overwrite the current tables with that historical data.✓ Correct
  • C. From the DLT pipeline UI, select the pipeline run from 48 hours ago and click 'Restore Pipeline State'.
  • D. Revert the pipeline code to the previous version in Git and trigger a full refresh; DLT will automatically restore the tables to their 48-hour-ago state.
Explanation

Delta time travel allows querying a Delta table's state at a specific point in time using `VERSION AS OF` or `TIMESTAMP AS OF`. By reading the table at the desired historical timestamp and overwriting the current table, the rollback is achieved precisely. This is the correct rollback strategy for Delta-based pipelines. Option A (delete and recreate) would work only if a separate backup exists, which is not mentioned, and causes unnecessary downtime. Option C is a fabricated UI feature; DLT does not have a 'Restore Pipeline State' button. Option D is incorrect because a full refresh re-processes source data from scratch using the current pipeline code; reverting the code and running a full refresh would regenerate data using the old logic but would not restore historical data quality — it would reflect the source data as it currently exists.

4. A senior data engineer is reviewing a `bundle.yml` for a project that promotes from dev to prod. The bundle defines the following: ```yaml bundle: name: etl_pipeline variables: max_retries: default: 1 targets: dev: mode: development prod: mode: production variables: max_retries: 3 ``` A developer runs `databricks bundle deploy --target dev`. What value will `max_retries` resolve to during this deployment, and why?

  • A. 3, because `prod` is listed after `dev` in the YAML file and YAML parsers always use the last defined value for a key
  • B. 1, because the `dev` target does not override `max_retries`, so it inherits the top-level default value of 1✓ Correct
  • C. 0, because `mode: development` resets all variables to zero to prevent resource over-allocation in dev environments
  • D. The deployment will fail with a validation error because all targets must explicitly define every variable declared at the bundle level
Explanation

In Databricks Asset Bundles, variables declared at the top level with a `default` value are used unless a specific target overrides them in its `variables` block. The `dev` target has no `variables` block, so `max_retries` resolves to its default value of 1. Option A is wrong—YAML is not parsed last-wins for sibling keys at different levels; target-level variables are scoped to their target. Option C is incorrect; `mode: development` affects resource naming and permissions (e.g., prepending the user name to job names) but does not reset variable values to zero. Option D is incorrect; variables with defaults are optional to override per target.

5. A team has a Databricks job with a Python wheel task. The wheel is built from internal source code and published to an internal PyPI-compatible artifact registry. They want to ensure the correct wheel version is installed on the job cluster without affecting other jobs running on shared clusters. Which THREE configuration strategies achieve this with the LEAST operational risk? (Select THREE)

  • A. Specify the wheel as a job-level library in the Databricks job definition using the `whl` or `pypi` library type with a pinned version, so it is installed only for that job's cluster✓ Correct
  • B. Use `%pip install my-package==1.2.3 --index-url https://internal.registry/simple` in the first notebook cell so the package is installed in the notebook's isolated environment for that session✓ Correct
  • C. Add the wheel to a cluster-level init script that runs `pip install my-package` without a pinned version so the latest version is always used
  • D. Define the wheel as a task-level library in the job definition, scoping the installation to individual tasks rather than the whole cluster
  • E. Install the wheel globally on all-purpose clusters using the cluster library UI so any notebook on any cluster in the workspace can import it
  • F. Pin the wheel version in a `requirements.txt` file stored in the bundle, and reference it in the job cluster's `libraries` block via `databricks bundle deploy`, ensuring reproducible installs per deployment✓ Correct
Explanation

Options A, B, and F all achieve version-pinned, isolated installation. Option A uses the job-level library declaration which scopes the install to the job cluster and supports pinned versions. Option B uses %pip in a notebook cell, which installs into the notebook's Python environment for that session—fully isolated from other notebooks on the same cluster. Option F pins the version in a requirements.txt referenced through the DAB bundle, ensuring reproducible deployments. Option C is wrong because using an unpinned version in an init script creates non-reproducible builds—any future cluster restart could pull a different version. Option D (task-level libraries) is a valid Databricks feature, but the question asks for the LEAST operational risk among the listed options; task-level libraries are supported but less commonly the primary recommendation compared to job-level libraries and %pip for this scenario—however, on reflection, task-level libraries are in fact a valid and supported pattern. Option E installs globally on shared all-purpose clusters, which risks version conflicts with other users and jobs and is the opposite of isolation.

26 more questions in this domain

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

Start practicing free
Debugging and Deploying — Free Data Engineer Professional Practice Questions | DataCertPrep — Certification Prep