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

Question 1

A team uses Databricks Asset Bundles to define a job that must exist in both a staging and a production workspace with different cluster sizes. They want a single bundle definition that deploys correctly to both targets. Which configuration should they use?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use a single bundle with `targets` for staging and production, and override cluster settings per target using target-specific variables or overrides in `databricks.yml`.. Databricks Asset Bundles are designed for multi-environment deployment. A single `databricks.yml` with `targets` for staging and production, combined with target-specific overrides for cluster configuration, lets one bundle definition produce environment-appropriate resources without duplicating the job definition.

Answer

Define two separate bundles, one per workspace, and deploy each with its own `databricks bundle deploy` command.

Answer

Hard-code the production cluster size in the bundle and use a cluster policy in staging to downsize it at runtime.

Answer

Deploy the bundle only to production and point the staging workspace at the production job through a shared workspace link.

Question 2

A CI/CD pipeline uses the Databricks CLI to deploy a job to production. The pipeline must ensure that the job configuration is identical across environments except for the cluster size, which differs between staging and production. Which approach best supports this requirement?

Accepted Answer

Define the job in a JSON file with placeholders, and use environment variables in the CI/CD pipeline to substitute cluster size values before deployment.. Templating the job JSON with environment variables allows the pipeline to substitute environment-specific values like cluster size while keeping the rest of the configuration identical. This ensures consistency and reduces drift, as the same template is used for all environments, and differences are explicitly managed through variables.

Answer

Maintain separate JSON files for staging and production, and manually update both when the job logic changes.

Answer

Store the job definition in a Databricks notebook and use widgets to parameterize the cluster size at runtime.

Answer

Use the Databricks REST API to create the job in production, then manually edit the cluster size in the Databricks UI after deployment.

Question 3

A data engineering team stores notebooks in a Git repository and wants automated deployments to a Databricks workspace. They configure a GitHub Actions workflow that runs a Databricks CLI command to deploy Databricks Asset Bundles. The workflow authenticates using a service principal OAuth token stored in GitHub Secrets. After the first successful run, subsequent runs fail with an authentication error. The token was created with a 1-hour lifetime. What should the team do to ensure the workflow can authenticate reliably on every run?

Accepted Answer

Configure the GitHub Actions workflow to obtain a short-lived OAuth token dynamically from the identity provider using a federated identity or client credentials flow before each deployment.. Short-lived OAuth tokens expire, so a CI/CD pipeline must fetch a new token at the start of each run. Using the client credentials flow or workload identity federation with the service principal allows the GitHub Actions workflow to authenticate dynamically without storing a long-lived secret. This is the secure, maintainable pattern for automated Databricks deployments.

Answer

Run the GitHub Actions workflow on a self-hosted runner inside the Databricks workspace network so that the CLI can use an instance profile for authentication.

Answer

Increase the service principal OAuth token lifetime to 24 hours in the Databricks account console and update the secret in GitHub.

Answer

Replace the service principal OAuth token with a personal access token (PAT) generated for a workspace admin user and store it in GitHub Secrets.

Question 4

A platform team is setting up a CI/CD pipeline that deploys Databricks jobs and notebooks from a Git repository. They must ensure deployments are secure and auditable. (Choose two.)

Accepted Answer

Grant the deployment identity only the permissions required to manage the specific jobs and notebooks it deploys.. Secure, auditable deployments rely on a dedicated non-human identity with narrowly scoped permissions. A service principal whose secret lives in the CI/CD secret store provides traceable, rotatable credentials, and least-privilege grants limit what a compromised pipeline could do while keeping audit records meaningful.

Answer

Disable workspace audit logs during deployments to reduce log volume and improve pipeline speed.

Answer

Use a different engineer's personal account for each environment so responsibility is clear.

Answer

Commit the workspace personal access token to the repository so all pipeline runs use the same credential.

Question 5

A team is using Databricks Asset Bundles (DABs) to manage their CI/CD pipeline. They want to run unit tests on their Python code before deploying the bundle. Where should the tests be executed in the pipeline?

Accepted Answer

In the CI/CD runner (e.g., GitHub Actions) as a separate job step before the bundle deploy command.. Unit tests should be executed in the CI/CD runner as a step before deployment. This ensures that only code that passes tests is deployed. It also leverages the runner's environment and standard testing tools, keeping the pipeline efficient and reliable. Deploying first would risk introducing bugs into production.

Answer

Using the Databricks CLI to run a test command that executes tests on a cluster.

Answer

Inside a Databricks notebook that is executed manually by a developer before merging.

Answer

As a Databricks job within the bundle that is triggered after deployment.

Question 6

A team is using Databricks Asset Bundles (DABs) to deploy a job to multiple environments (dev, staging, prod). They need to ensure that the job uses different cluster sizes and schedules per environment. Which DABs feature should they use?

Accepted Answer

Define separate bundle configuration files for each environment and use the --target flag with databricks bundle deploy.. Databricks Asset Bundles use targets to define environment-specific overrides in the databricks.yml file. When deploying, the --target flag selects the target, applying the corresponding cluster size and schedule. This keeps a single source of truth while allowing differences per environment, which is essential for promoting bundles through dev, staging, and prod.

Answer

Use the Databricks REST API to update the job configuration after deployment with environment-specific values.

Answer

Create a separate Databricks workspace for each environment and hardcode the cluster size and schedule in the job definition.

Answer

Use Jinja2 templating in the job definition to inject environment-specific values from environment variables.

Question 7

A team is using Databricks Asset Bundles to manage a job that writes to a Unity Catalog table. The bundle is deployed to a staging workspace for testing and then to a production workspace. The team wants the job to use different catalog and schema names in each environment without duplicating the entire bundle. Which approach should they use?

Accepted Answer

Define bundle variables for the catalog and schema, and set different values for each variable in the staging and production targets within the databricks.yml file.. Databricks Asset Bundles allow a single job definition to be deployed to multiple environments by using variables that are resolved differently per target. Defining catalog and schema variables and setting their values under the staging and production targets in databricks.yml keeps the bundle DRY and ensures each workspace uses the correct Unity Catalog objects.

Answer

Store the catalog and schema names in a Databricks secret scope and reference them in the job's notebook using dbutils.secrets.get.

Answer

Use a single target and pass the catalog and schema names as job parameters at runtime through the Databricks Jobs API.

Answer

Create two separate bundle configuration files, one for staging and one for production, and manually copy the job definition into each.

Question 8

A data engineering team uses Databricks Asset Bundles (DABs) to manage a job that must deploy to both a staging and a production workspace. The team wants to avoid hardcoding workspace-specific values such as the cluster ID and the storage path in databricks.yml. Which approach should they use?

Accepted Answer

Define variables in the bundle and set target-specific values in databricks.yml under targets, then deploy with databricks bundle deploy -t <target>.. Databricks Asset Bundles use a declarative databricks.yml with variables and targets. Declaring variables once and overriding them per target lets one bundle deploy consistently to staging and production without hardcoded workspace-specific values. Selecting the target at deploy time applies the correct values, keeps a single source of truth in Git, and avoids drift from manual edits or post-deployment patching.

Answer

Run databricks bundle deploy once, then use the Databricks REST API to patch the job's cluster ID and storage path after each deployment.

Answer

Store the cluster ID and storage path in a Databricks secret scope and reference them with dbutils.secrets.get inside the job's notebook code.

Answer

Create a separate Git branch for each workspace and manually edit the cluster ID and storage path in databricks.yml before each deployment.

Question 9

A data engineer is configuring a CI/CD pipeline for Databricks notebooks using GitHub Actions. They need to authenticate to Databricks to deploy notebooks. Which authentication method is recommended for production CI/CD pipelines?

Accepted Answer

Use a service principal with OAuth tokens generated via the Databricks CLI or REST API, storing the client ID and secret in GitHub Secrets.. For production CI/CD, authentication should use a service principal with OAuth. The client ID and secret are stored as secrets in the CI system, such as GitHub Secrets. The workflow can then use the Databricks CLI or REST API to authenticate. This approach decouples automation from individual users, supports permission scoping, and is more secure than personal access tokens.

Answer

Use the Databricks CLI with interactive login during the CI run.

Answer

Store a personal access token (PAT) in GitHub Secrets and use it in the workflow.

Answer

Embed the Databricks username and password directly in the workflow YAML file.

Question 10

A data engineer is setting up a CI/CD pipeline that runs unit tests on transformation logic before deploying notebooks to a production Databricks workspace. The tests must run quickly and not depend on a live Databricks cluster or external data sources. Which approach best meets these requirements?

Accepted Answer

Extract transformation logic into pure Python functions and test them locally with a framework like pytest, using sample DataFrames created in memory.. Unit tests for transformation logic should be fast, isolated, and runnable without a Databricks cluster. Extracting logic into pure Python functions and testing them with pytest and in-memory DataFrames achieves this. This practice also encourages modular code that is easier to maintain and integrate into CI/CD pipelines.

Answer

Run the tests as a Databricks job on a small interactive cluster in the development workspace, using production data for realism.

Answer

Configure the pipeline to trigger a Delta Live Tables pipeline in the development workspace and check the pipeline's event log for errors.

Answer

Use Databricks Repos to run notebooks interactively and manually verify the output before merging the pull request.

Question 11

A CI/CD pipeline must run unit tests on Python transformation code before deploying a Databricks job. The tests should execute quickly without starting a cluster and should validate the transformation logic in isolation. Which approach best meets these requirements?

Accepted Answer

Use pytest in the CI runner to test the transformation functions directly, mocking Spark or using a local SparkSession only where needed.. Unit tests for transformation logic belong in the CI runner, not on a cluster. Using pytest with pure functions and a local SparkSession where necessary keeps tests fast, isolated, and free of cloud compute. This catches logic errors before deployment, whereas bundle validation only checks configuration and integration tests against production data are slow and risky.

Answer

Deploy the job to a development workspace and run an integration test against production data to confirm the transformations produce expected results.

Answer

Configure the pipeline to run databricks bundle validate and rely on schema validation to confirm the transformation logic is correct.

Answer

Run the tests as a Databricks job task on an all-purpose cluster so the tests use the same runtime as production.

Question 12

A team wants to ensure that code changes to their Databricks notebooks are reviewed before being deployed to production. They use a Git repository and Databricks Repos. Which practice should they implement in their CI/CD process?

Accepted Answer

Require pull requests with at least one approval before merging into the main branch, and trigger production deployment only after the merge.. Enforcing pull requests with approvals through branch protection rules ensures that changes are reviewed before merging. Deploying to production only after the merge ties deployment to reviewed code. This practice is essential for maintaining code quality and auditability in a CI/CD pipeline.

Answer

Allow developers to commit directly to the main branch and deploy automatically to production on every commit.

Answer

Use Databricks Repos to create a separate repository for each developer and merge changes manually in the production workspace.

Answer

Configure the production workspace to allow only workspace admins to edit notebooks, and have developers request admin assistance for each change.

Question 13

A team stores Databricks notebooks and job definitions in a Git repository and wants every merge to the main branch to automatically deploy to production. Which combination of practices should the pipeline implement to achieve this safely?

Accepted Answer

Trigger the deployment workflow on pushes to the main branch, authenticate with a service principal whose credentials are stored in the CI system's secret manager, and run databricks bundle deploy.. Safe continuous deployment requires two things: a trigger scoped to the main branch so only reviewed, merged code reaches production, and non-interactive authentication via a service principal stored in the CI secret manager. Running databricks bundle deploy from the merged commit then applies the bundle definition reproducibly. Scheduling, branch-agnostic triggers, and personal tokens all undermine control or automation.

Answer

Trigger the deployment workflow on a nightly schedule and use a personal access token for authentication so the deployment uses the developer's existing permissions.

Answer

Trigger the deployment workflow on pushes to any branch and use the Databricks CLI with interactive browser login to authenticate to the production workspace.

Answer

Trigger the deployment workflow on pull requests and use the developer's personal access token stored in the repository as a plaintext secret.

Question 14

A data engineering team is implementing a CI/CD pipeline for Databricks notebooks and jobs using Databricks Asset Bundles. They want to ensure deployments are reproducible and that production changes are traceable. Which TWO of the following practices should they follow? (Choose two.)

Accepted Answer

Use a separate target in databricks.yml for each environment, and run databricks bundle deploy with the appropriate target in the pipeline.. Reproducible and traceable deployments require that the bundle and notebooks are versioned together and deployed from a specific commit. Using environment-specific targets in databricks.yml ensures consistent deployment across workspaces. Manual edits, embedded credentials, and local deployments all break reproducibility and traceability, so they must be avoided.

Answer

Deploy the bundle from a developer's local machine to production to avoid the complexity of a CI/CD runner.

Answer

Manually edit the deployed job in the production workspace after deployment to apply urgent fixes, and sync those changes back to Git later.

Answer

Embed production credentials directly in the databricks.yml file so the pipeline can authenticate without additional configuration.

Question 15

A team wants to automate deployment of Databricks jobs from a Git repository using a CI/CD pipeline. They need a tool that reads a declarative project definition and creates or updates jobs, pipelines, and notebooks in a target workspace. Which Databricks capability should they use?

Accepted Answer

Databricks Asset Bundles, using databricks bundle deploy to apply the project definition to the target workspace.. Databricks Asset Bundles are the declarative deployment mechanism for Databricks resources. A databricks.yml file plus source files defines jobs, pipelines, and notebooks, and databricks bundle deploy applies that definition to a target workspace. Repos handle file sync for development, SQL warehouse APIs run queries, and cluster policies govern compute; none of them deploys resource definitions from Git.

Answer

Cluster policies, by attaching a policy that references the Git repository and applies job configurations at cluster start.

Answer

Databricks Repos, by adding the repository and clicking Sync in the target workspace before each release.

Answer

The Databricks SQL warehouse API, using scheduled queries to create jobs and pipelines in the target workspace.