Databricks-DE-Assoc Implementing CI/CD Practice Test 2 — 15 Questions

Question 1

What is the primary goal of implementing 'environment parity' in a Databricks CI/CD pipeline?

Accepted Answer

To minimize failures caused by differences between testing and production.. Environment parity ensures that the development, staging, and production environments are identical in configuration, libraries, and settings. This eliminates 'environment drift,' where code fails in production due to subtle discrepancies. Achieving parity through Infrastructure-as-Code (IaC) is the cornerstone of reliable CI/CD, as it guarantees that testing in staging provides a true representation of how the code will behave in production, significantly reducing the frequency of deployment-related failures.

Answer

To ensure every developer has full admin access to production.

Answer

To reduce the cost of compute resources in development workspaces.

Answer

To allow for manual code deployments in all environments.

Question 2

Which of the following is a recommended strategy for managing library dependencies in a CI/CD pipeline for Databricks?

Accepted Answer

Include a requirements.txt file and install libraries as part of the job definition.. Managing libraries through a centralized repository or a requirements.txt file ensures that the exact same versions are installed consistently across all environments. This avoids the 'dependency hell' where code fails because of incompatible library versions. By integrating dependency management into the CI/CD build process, teams can audit used versions, ensure security compliance, and guarantee that the production pipeline runs with the exact dependencies that were tested during the development phase.

Answer

Install libraries manually on the cluster via the Databricks UI.

Answer

Use the latest version of all libraries to ensure best performance.

Answer

Store library binary files directly in the Git repository.

Question 3

What is the primary purpose of a 'feature branch' in a Git-based workflow for Databricks?

Accepted Answer

To isolate changes so they can be tested before merging to production.. Feature branches allow developers to build and test new functionality in isolation, without affecting the main production code. This workflow is essential for CI/CD because it facilitates peer reviews, automated integration testing, and safe integration. By keeping the main branch stable and only merging validated features, teams maintain a high standard of quality and avoid breaking the production environment with incomplete or untested code changes, which is a core benefit of modern DevOps practices.

Answer

To allow multiple users to edit the same file simultaneously without sync.

Answer

To bypass the authentication requirements for the workspace.

Answer

To automatically deploy changes to the production environment.

Question 4

A data engineering manager wants to ensure that all production code in Databricks is fully audited and versioned. Which TWO of the following steps are required?

Accepted Answer

Enforce a policy where only the CI/CD Service Principal can update production assets.. Ensuring auditability and versioning requires locking down the production environment and forcing all changes through a Git-based CI/CD pipeline. By disabling manual changes in production and requiring all updates to be merged through a pull request process, teams ensure that every modification is reviewed, logged, and linked to a specific version. These controls are essential for compliance, stability, and maintaining a clear history of system changes in professional data environments.

Answer

Grant developers 'Can Manage' permissions on production workspace folders.

Answer

Store all notebook development directly in the production workspace.

Answer

Allow administrators to use personal tokens for manual emergency hotfixes.

Question 5

When utilizing Databricks Asset Bundles, how should secrets (e.g., API keys, database credentials) be handled to ensure security during CI/CD?

Accepted Answer

Use the bundle's secret reference syntax to map variables to a secret scope.. Hardcoding secrets in configuration files is a critical security vulnerability. Databricks Asset Bundles support referencing secrets through the 'secrets' scope, which securely retrieves credentials at runtime. By decoupling sensitive data from the version-controlled YAML files, teams maintain security, avoid leaking credentials in Git, and simplify secret rotation. This practice is essential for enterprise security and ensures that sensitive infrastructure data is managed in alignment with the principle of least privilege.

Answer

Hardcode the secrets in the bundle's YAML configuration files.

Answer

Store secrets as environment variables in the Git repository.

Answer

Ask all developers to manually enter secrets in the production UI.

Question 6

Your team is migrating a manual Databricks job to a CI/CD pipeline. You need to ensure the job configuration is version-controlled and deployed programmatically. Which approach aligns with Databricks best practices?

Accepted Answer

Define the job configuration in YAML files using Databricks Asset Bundles and deploy via the CLI.. Using Databricks Asset Bundles (DABs) is the recommended approach for modern CI/CD. It treats infrastructure as code, allowing you to define jobs, pipelines, and workflows in YAML files. This ensures consistency across environments like development, staging, and production. By decoupling the job definition from the workspace UI, you gain auditability, reproducibility, and the ability to integrate seamlessly with Git workflows, reducing manual configuration errors and accelerating release cycles for data engineering teams.

Answer

Manually export the job JSON via the UI and copy-paste it into the production workspace.

Answer

Use the Databricks UI to update production jobs directly to ensure changes are applied immediately.

Answer

Write a custom Python script that uses the workspace API to recreate the job from scratch every time.

Question 7

When integrating Databricks with a CI/CD tool like GitHub Actions, how should you securely manage the authentication token used for deployments?

Accepted Answer

Store the token as an encrypted secret in the CI/CD provider's secret store.. Managing secrets securely is vital for CI/CD. Storing tokens directly in code or pipeline definitions exposes them to unauthorized access. By using a secrets manager, you decouple the sensitive credentials from the pipeline logic. This ensures that the CI/CD platform can authenticate with Databricks dynamically during the execution phase, maintaining a high security posture while allowing for easy rotation of credentials without needing to refactor the entire codebase.

Answer

Hardcode the Databricks Personal Access Token directly into the YAML pipeline file.

Answer

Save the token in a public S3 bucket and download it when the pipeline starts.

Answer

Use your own password as the token for easier memorization and access.

Question 8

Which TWO of the following statements are correct regarding the use of Databricks Repos for CI/CD?

Accepted Answer

Databricks Repos allows users to integrate with Git providers like GitHub, GitLab, and Bitbucket.. Databricks Repos facilitates seamless Git integration within the Databricks workspace. It enables teams to perform development directly in the workspace while keeping code versioned in remote Git repositories. By understanding that Repos maps workspace folders to Git branches, engineers can implement effective branching strategies and merge workflows. This integration bridges the gap between collaborative notebook development and standard software engineering practices, ensuring that changes are tracked, reviewed, and tested before deployment to production environments.

Answer

Databricks Repos can only be used for Python code and does not support SQL or Markdown files.

Answer

Each Databricks Repo is a local-only folder that cannot be synchronized with a remote Git repository.

Answer

Changes made in a Repo automatically deploy to production without needing to be merged in Git.

Question 9

Refer to the exhibit. A CI/CD pipeline running a Databricks CLI command fails with the error shown. What is the most likely cause?

Accepted Answer

The path provided in the deployment script does not exist in the target Databricks workspace.. This error indicates that the automation script is attempting to reference a file or directory path that is missing in the target workspace. In CI/CD, this frequently happens when paths are hardcoded for local development environments rather than being abstracted. Using relative paths or workspace-agnostic configurations within Databricks Asset Bundles prevents these environment-specific failures, ensuring that the deployment process remains robust regardless of where the code is being executed during the pipeline run.

Answer

The Databricks CLI is not installed on the runner.

Answer

The Personal Access Token has expired.

Answer

The user does not have permissions to write to the root directory.

Question 10

A data platform team is migrating their deployment process to Databricks Asset Bundles (DABs). They already have a Python wheel task defined in a Databricks Job and a set of notebooks in a Git repository. They want the bundle deployment to be repeatable across development, staging, and production targets with different cluster sizes. Which approach should they take to parameterize the target-specific cluster configuration?

Accepted Answer

Use the bundle's databricks.yml targets block with variables and override cluster node types per target.. Databricks Asset Bundles provide a targets block in databricks.yml specifically so one bundle can deploy to multiple workspaces with environment-specific overrides. Using variables for cluster properties and overriding them per target preserves a single job definition while still allowing dev, staging, and prod to use different cluster sizes. This matches the recommended DABs workflow for environment parity and repeatable CI/CD deployments.

Answer

Store cluster configuration in a Delta table and have the job read it at runtime using spark.conf.

Answer

Define cluster settings directly in the job YAML and use separate branches for each environment.

Answer

Create a separate Databricks Job for each environment and deploy them with the same bundle.

Question 11

A data engineering team stores all production notebooks and job definitions in a Git repository. They want every merge to the `main` branch to automatically deploy the updated notebooks to the production Databricks workspace without any manual copy/paste. Which approach should they implement?

Accepted Answer

Configure a Databricks Repo in the production workspace that tracks the `main` branch, and run a CI/CD pipeline that calls the Repos API to update the repo to the latest commit after each merge.. Deploying from Git requires the production workspace to consume the repository as the source of truth. A Databricks Repo that tracks the `main` branch, updated by a CI/CD pipeline through the Repos API after each merge, achieves automated, traceable deployment of notebooks and job definitions without manual copying.

Answer

Schedule a Databricks Job that executes `git pull` inside a notebook on a fixed cron schedule.

Answer

Enable automatic Git synchronization on the production workspace so Databricks pulls changes from the repository on its own.

Answer

Use the Databricks CLI to export notebooks from the development workspace and import them into production on every merge.

Question 12

A data engineering team is setting up a CI/CD pipeline for Databricks notebooks using Databricks Repos and a Git provider. They want to ensure that changes are tested before being merged and that production deployments are controlled. Which TWO practices should they implement? (Choose two.)

Accepted Answer

Run automated tests in a CI job on a feature branch using a dedicated test workspace before merging to main.. A robust CI/CD process for Databricks Repos runs automated tests on feature branches in a dedicated test workspace, then gates merges on CI success. Production deployment should be a separate, controlled step that updates the production Repo to a tagged release, providing an immutable and rollback-friendly reference. These two practices together enforce quality gates and controlled promotion, which are core to CI/CD with Databricks Repos.

Answer

Store production credentials in the Repo's notebooks as widgets so the CI job can read them during tests.

Answer

Allow developers to commit directly to the main branch in the production workspace to reduce merge conflicts.

Answer

Configure the production Repo to track the main branch and enable automatic pull on every commit.

Question 13

A CI/CD pipeline runs unit tests against transformation logic before deploying to production. The tests must run on a Databricks cluster and produce a pass/fail result that fails the pipeline when assertions do not hold. Which implementation best fits this requirement?

Accepted Answer

Create a Databricks Job that runs a notebook containing assertions, and have the CI/CD pipeline trigger the job and check its run result.. Tests must run where the production code runs. Triggering a Databricks Job that executes assertion notebooks lets the CI/CD pipeline inspect the run result and fail on assertion errors. This validates behavior on the actual Databricks runtime rather than in a disconnected local environment.

Answer

Run pytest locally in the CI runner against a sample of production data downloaded from cloud storage.

Answer

Use the Databricks SQL Statement Execution API to run `SELECT` statements that compare row counts between source and target tables.

Answer

Configure the cluster's init script to run the test suite automatically whenever the cluster starts.

Question 14

A data engineering team stores its Databricks notebooks and Python files in a Git repository. They want to avoid manually copying files into the workspace and ensure that the production workspace always runs the exact code version that passed tests. Which approach should they use?

Accepted Answer

Use Databricks Repos to clone the Git repository into the production workspace and check out the tested commit.. Databricks Repos provides native Git integration, enabling teams to clone repositories and check out specific commits. By checking out the tested commit in the production workspace, the team ensures that the deployed code matches what passed tests, eliminating manual copying and reducing drift. This is a core practice for implementing CI/CD with Databricks.

Answer

Schedule a Databricks Job that runs a notebook which pulls the latest code from Git at runtime.

Answer

Mount the Git repository as a DBFS mount point and reference notebooks directly from the mount.

Answer

Export notebooks as .dbc files and import them into the production workspace using the Databricks CLI.

Question 15

A team is using the Databricks CLI in their CI/CD pipeline to deploy jobs and notebooks. They need the pipeline to authenticate to a production workspace without embedding a personal user's credentials. Which authentication method should they configure for the CLI?

Accepted Answer

A service principal with an OAuth token or client credentials configured in the CLI profile.. For CI/CD automation, Databricks recommends authenticating the CLI with a service principal rather than a personal user identity. Service principals are non-human accounts that can be granted scoped permissions, and the CLI supports OAuth client credentials or service principal tokens. This avoids coupling deployments to an employee's account and supports credential rotation, auditing, and least privilege in production pipelines.

Answer

A personal access token generated from a developer's Databricks account.

Answer

The workspace's built-in admin username and password stored in the CI environment variables.

Answer

An SSH key pair registered in the Databricks workspace under the deploying user's profile.