Databricks DE Assoc Domain 5: Implementing CI/CD (10%)

Overview

Section 5 covers how data engineering code moves from a developer's branch to production. The first objective is Databricks Git folders, formerly called Repos: cloning a repository into the workspace, creating and switching branches, committing and pushing changes, and taking part in pull request reviews through the Git integration.

The other three objectives cover Declarative Automation Bundles, the new name for Databricks Asset Bundles. You need to understand how one databricks.yml project uses variables and per-target overrides so the same code deploys to dev, test and prod with different catalogs, compute or schedules. You also need to deploy bundles that package Lakeflow Jobs, Lakeflow Declarative Pipelines and other workspace assets, and to use the Databricks CLI commands that validate, deploy and run bundles from a CI/CD system.

Why it matters on the exam

This section supplies about 5 of the 45 scored questions at 10%, but the ideas protect everything built in the other sections. Without version control, a notebook edited in production cannot be reviewed or rolled back. Without bundles, teams copy jobs between workspaces by hand and settings drift between environments until a production job points at a development catalog. The exam checks that you know the managed path: branch in a Git folder, review through a pull request, describe resources in a bundle, and let an automated pipeline call the CLI to deploy to each target. Watch the naming in study material, because many sources still say Repos and Databricks Asset Bundles, while the current exam guide uses Git folders and Declarative Automation Bundles.

How it's tested

Questions describe a team workflow or a deployment problem and ask for the correct Git folder action, bundle setting or CLI command. Some show a short databricks.yml fragment with targets and variables and ask what a deployment to a named target will produce.

Git folder action

A developer needs to start a feature, save work or get changes reviewed, and you choose the branch, commit, push or pull request step.
Per-environment config

Dev and prod need different catalogs or schedules, and you choose variables and target overrides over duplicated files.
CLI sequence

A CI pipeline must check and ship a bundle, and you choose the right order of validate, deploy and run commands.

Reasoning it through

A team's job must write to the dev catalog in development and to the prod catalog in production. Copying the job YAML into two bundles would work but drifts over time. Declaring a catalog variable with a default and overriding it in the prod target lets one definition serve both, deployed with databricks bundle deploy -t prod, so that is the answer.

Objectives 4

Official objectives from the Databricks outline, in outline order.

5.1 Manage your code development workflow within the Databricks workspace UI, including creating and switching between branches in Databricks Git folders (formerly Databricks Repos), committing and pushing changes, and creating pull requests using Databricks Git integrationDay-to-day Git work from inside the workspace.

What it means: A Git folder is a workspace folder linked to a remote repository on providers such as GitHub, GitLab, Azure DevOps or Bitbucket. Developers clone the repository into their own folder, work on a branch and use the Git dialog to commit, push and pull without leaving Databricks.
What to understand: Configure Git credentials, such as a personal access token or a provider app, under user settings. From the Git dialog you can create a branch, switch branches, see changed files, write a commit message, commit and push, and pull remote changes. Merge conflicts can be resolved in the UI. Pull requests are opened and reviewed on the Git provider side through its integration, and merging there is the usual gate to production. Each developer should use a personal Git folder rather than editing a shared one, and production jobs should reference a fixed branch or tag.
How it shows up: Expect questions on the correct order of branch, commit, push and pull request steps and where reviews happen.
Common confusion: Editing directly on the main branch in a shared Git folder used by production jobs.

5.2 Understand environment-specific configuration using Declarative Automation Bundle (formerly Databricks Asset Bundles) variables and overrides while promoting the same codebase across dev, test, and prod targetsVariables and target overrides that let one bundle serve every environment.

What it means: A bundle is defined by a databricks.yml file. Top-level settings describe resources once, and a targets section defines environments such as dev, test and prod. Variables hold values that differ between targets, and target blocks override settings where needed.
What to understand: Declare variables with a description and default, then reference them as ${var.name} in resource definitions. Each target can set its own variable values, workspace host, root path and run-as identity, and can override resource fields such as cluster size or schedule. Values can also come from the command line with --var or from BUNDLE_VAR_ environment variables in CI. mode: development prefixes resource names with the user's name and pauses schedules, while mode: production applies stricter checks. Lookup variables can resolve an object's ID by name, such as a cluster or warehouse.
How it shows up: Questions ask how to change a catalog, cluster or schedule per environment without duplicating code.
Common confusion: Keeping separate copies of databricks.yml for each environment.

5.3 Deploy Declarative Automation Bundles (formerly Databricks Asset Bundles) to package, configure, and promote Lakeflow Jobs, Lakeflow Declarative Pipelines, and other workspace assets across dev, test, and prod environmentsPackaging jobs, pipelines and code into a bundle and promoting it.

What it means: Bundles treat workspace assets as code. A single project can define Lakeflow Jobs, Lakeflow Declarative Pipelines, dashboards and other resources together with the notebooks, Python files and wheels they use. Deploying the bundle to a target creates or updates those assets in that workspace.
What to understand: Resources go under a resources key or in included YAML files, and artifacts describe build steps such as a Python wheel. A deployment uploads files to the target's root path and creates or updates each resource, keeping state so later deploys update rather than duplicate. Promotion means deploying the same commit to test and then prod, normally from a CI pipeline after a merge. Production targets usually run as a service principal so jobs do not depend on a person's account. bundle destroy removes resources a bundle created.
How it shows up: Scenario items ask how to move a tested job and pipeline from dev to prod consistently.
Common confusion: Exporting a job's JSON from dev and importing it by hand into prod.

5.4 Understand the Databricks CLI to validate, deploy, and manage Declarative Automation Bundles (formerly Databricks Asset Bundles) and other workspace assets in automated CI/CD workflowsCLI commands for bundles and workspace automation.

What it means: The Databricks CLI is a command-line tool for the Databricks REST APIs. Its bundle commands handle the full bundle lifecycle, and other command groups manage jobs, workspace files, secrets and more, which makes it the usual tool in a CI/CD system.
What to understand: Common bundle commands are databricks bundle init to start from a template, validate to check configuration, deploy -t <target> to push changes, run to start a job or pipeline, summary to list deployed resources and destroy to remove them. In CI, authenticate with OAuth machine-to-machine credentials for a service principal through environment variables such as DATABRICKS_HOST, DATABRICKS_CLIENT_ID and DATABRICKS_CLIENT_SECRET rather than a personal token. A typical pipeline runs validate on pull requests, then deploy to test, tests, and deploy to prod after approval.
How it shows up: Expect questions on command order and on secure authentication from automation.
Common confusion: Running deploy before validate, or using a developer's personal token in CI.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

Git folder

Workspace folder linked to a remote Git repository.

Remember
Formerly called Repos.

Tested as
Version control items.

Trap
Thinking it only supports GitHub.
databricks.yml

Root configuration file of a bundle.

Remember
Holds bundle name, includes, variables and targets.

Tested as
Bundle structure items.

Trap
Placing settings only in the UI.
Targets

Named environments such as dev and prod.

Remember
Each can override settings.

Tested as
Promotion questions.

Trap
Creating separate bundles per environment.
${var.name}

Reference to a bundle variable.

Remember
Values set per target, by --var or env vars.

Tested as
Per-environment config.

Trap
Hard-coding catalog names.
Development mode

Target mode for personal dev deployments.

Remember
Prefixes names and pauses schedules.

Tested as
Avoiding collisions.

Trap
Expecting dev schedules to run.
bundle validate

Checks bundle configuration.

Remember
Run before deploy in CI.

Tested as
CLI order questions.

Trap
Skipping it and failing at deploy time.
bundle deploy -t

Deploys the bundle to a named target.

Remember
Creates or updates resources.

Tested as
Deployment items.

Trap
Forgetting the target flag.
Service principal auth

OAuth M2M credentials for automation.

Remember
Production runs should not use a personal identity.

Tested as
CI security items.

Trap
Using a personal access token in pipelines.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Old and current names

Concept	Meaning	Key difference	Common trap
Repos to Git folders	Workspace Git integration.	Same capability, new name.	Treating them as different features.
Asset Bundles to Declarative Automation Bundles	Infrastructure-as-code for workspace assets.	Same databricks.yml approach.	Assuming older bundle docs are invalid.
Workflows to Lakeflow Jobs	Built-in orchestrator.	Same jobs features under a new brand.	Thinking jobs must be rebuilt.

Bundle CLI commands

Concept	Meaning	Key difference	Common trap
validate	Checks configuration and variables.	No changes made.	Skipping it in CI.
deploy	Uploads files and updates resources.	Changes a target workspace.	Expecting it to start a run.
run	Starts a job or pipeline from the bundle.	Executes a deployed resource.	Running before deploying changes.
destroy	Removes bundle-created resources.	Cleans up a target.	Running it against prod by mistake.

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

Manual promotion

What candidates pick
Export job JSON from dev and import into prod

Why it looks right
It is quick for a single job.

Why it's wrong
Manual copies drift and are not reviewed; deploying one bundle to each target keeps environments consistent.

Clue to watch for Repeatable or consistent promotion.
Personal token in CI

What candidates pick
Store a developer's personal access token as a CI secret

Why it looks right
It works immediately.

Why it's wrong
CI pipelines should sign in as a service principal using OAuth, so deployments never hinge on one employee's account.

Clue to watch for Automated pipeline or production.
Separate bundle per environment

What candidates pick
Three databricks.yml files for dev, test and prod

Why it looks right
It keeps environments clearly separate.

Why it's wrong
One bundle with targets and variables shares definitions and avoids divergence.

Clue to watch for Same codebase across environments.
Deploy means run

What candidates pick
databricks bundle deploy to start the job

Why it looks right
Deploy sounds like it executes the job.

Why it's wrong
Deploy only creates or updates resources; bundle run or the job's trigger starts execution.

Clue to watch for Need to execute after deployment.
Pull requests inside the workspace

What candidates pick
Approve and merge the PR in the Git folder

Why it looks right
The Git dialog handles commits and branches.

Why it's wrong
Reviews and merges happen in the Git provider; the Git folder is where you branch, commit and push.

Clue to watch for Review or approval step.

Answer framework

Follow these steps for Git folder and bundle deployment questions in Section 5.

Decide whether the question is about developer workflow in Git folders or about deploying assets with bundles and the CLI.
For developer workflow, work on a personal Git folder and feature branch, commit and push, then review through a pull request.
For configuration, put shared definitions at the top of databricks.yml and use variables and target overrides for values that differ by environment.
For deployment, run validate, then deploy to the named target, then run or let triggers start the resources.
For automation, authenticate the CLI as a service principal with OAuth credentials and promote the same commit through test before prod.

Practice question

A data engineer maintains one Declarative Automation Bundle with dev and prod targets. The job must read from the dev_sales catalog in dev and the sales catalog in prod without duplicating the job definition. What should the engineer do?

Create two copies of the job resource, one inside each target block Hard-code the prod catalog and edit the notebook before each dev run Define a catalog variable, reference it as ${var.catalog} in the job, and set its value in each target Store both catalog names in a widget and choose one manually at run time

Show the answer

Answer C. Bundle variables let one resource definition take different values per target. Declaring a catalog variable, referencing it in the job and setting dev_sales in the dev target and sales in the prod target keeps a single definition. Copying the job per target duplicates configuration that will drift. Editing notebooks or choosing values by hand breaks automated, repeatable deployment and invites mistakes in production.

Want more like this? The Databricks DE Assoc practice test has questions for every domain.

Checklist

0 of 11

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Spend six to eight hours here, split between Git folders and bundles. Connect a personal repository to a Git folder, create a feature branch, change a notebook, commit and push, then open and merge a pull request in your Git provider. Pull the merged main branch back into the workspace so the full loop is familiar.

Next, install the Databricks CLI and run databricks bundle init with the default Python template. Read the generated databricks.yml and identify the bundle, include, resources and targets sections. Add a variable for a catalog name, set it differently in dev and prod targets, run validate, and deploy to dev. Look at the deployed job's name to see the development prefix and paused schedule. Then run the job with bundle run.

If you can, wire a simple CI workflow that validates on pull requests and deploys to a test target on merge using service principal credentials. Even without CI, rehearse the command sequence and the reason for each step, since most questions in this section test that order.

FAQ

What portion of the exam is Implementing CI/CD?

Implementing CI/CD is Section 5 and carries 10% of the exam, about 5 of the 45 scored questions, across four official objectives on Git folders, bundles and the CLI.

Are Declarative Automation Bundles different from Databricks Asset Bundles?

They are the same feature under a new name. The current guide prints the new name with the old one in brackets, so older bundle tutorials still teach the right concepts.

Do I need to know a specific CI tool?

No. The guide focuses on the Databricks CLI and bundles. Any CI system, such as GitHub Actions or Azure DevOps, simply runs the same CLI commands.

Can bundles deploy Lakeflow pipelines?

Yes. Bundles can define Lakeflow Declarative Pipelines alongside jobs, notebooks and other assets, and deploy them together to each target.

What does development mode do?

It prefixes deployed resource names with your user name, pauses schedules and triggers, and allows faster iteration, so several developers can deploy without collisions.

Should production jobs use Git folders directly?

Production jobs should use code deployed by a bundle or a job's Git source pinned to a branch or tag, not a developer's personal Git folder.

Related domains

Other Data & Analytics certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Databricks DE Assoc Domain 5: Implementing CI/CD

Overview

How it's tested

Git folder action

Per-environment config

CLI sequence

Objectives 4

High-yield concepts

Git folder

databricks.yml

Targets

${var.name}

Development mode

bundle validate

bundle deploy -t

Service principal auth

Side by side

Old and current names

Bundle CLI commands

Exam traps

Manual promotion

Personal token in CI

Separate bundle per environment

Deploy means run

Pull requests inside the workspace

Answer framework

Practice question

Checklist

Study strategy

FAQ

Other Data & Analytics certifications

Test your Domain 5 knowledge

Keep going