What you will be able to do
- Explain what a Declarative Automation Bundle (formerly Databricks Asset Bundle) contains and why it is treated as infrastructure as code
- Read a databricks.yml file: identify the required bundle name, the resources mapping, targets, the default target, and include
- State the prerequisites for deploying bundles from the Databricks CLI and pick the right authentication for interactive work versus automation
- Put the bundle lifecycle in order: init, configure, validate, deploy, run
Key concept
Bundle deployed to a target — A bundle is a project's source files plus YAML metadata that describes its Databricks resources (jobs, pipelines and so on). The whole thing is deployed as one unit to a named target, such as dev or prod, and each target can override the shared settings.
1.Bundles as infrastructure as code
Declarative Automation Bundles is the new name for Databricks Asset Bundles. Exam questions and older documentation may use either name. A bundle lets you describe Databricks resources such as jobs and pipelines as source files that sit next to your code. That means they get the same treatment as code: source control, code review, testing and CI/CD. Databricks calls this an infrastructure-as-code (IaC) approach. Bundles fit best when a project has several contributors, depends on automation, and needs CI/CD.
A bundle has four parts: the cloud infrastructure and workspace configuration it needs, the source files that hold the business logic (notebooks, Python files), definitions of Databricks resources (Lakeflow Jobs, Lakeflow pipelines, dashboards, Model Serving endpoints, MLflow experiments and registered models), and unit and integration tests. All of it is deployed together.
Bundles are a feature of the Databricks CLI. You write the bundle locally, then use the CLI to validate it, deploy it to remote workspaces, and run its workflows. You can run bundle projects from an IDE, a terminal, or inside Databricks. If you only want to work with bundles in the workspace, you don't need the CLI installed. Because bundles are versioned files, they also give you a history of both code and infrastructure changes, which helps in regulated industries.
Checkpoint 1 of 5· Check yourself
A team wants job definitions reviewed in pull requests and promoted to production through CI/CD. How does the documentation classify Declarative Automation Bundles?
Bundles define resources in YAML that lives with the source code, which is what makes them infrastructure as code and a natural fit for CI/CD.
“Declarative Automation Bundles are an infrastructure-as-code (IaC) approach to managing your Databricks projects.”Source: docs.databricks.com
Sources1
2.databricks.yml: name, resources and targets
Every bundle has exactly one main configuration file, databricks.yml, at the root of the project folder. The one required top-level mapping is bundle with a name. The other main mappings are resources, where jobs, pipelines, schemas, volumes and other objects are declared, and targets, the named deployment destinations. Each resource's keys follow the create-request fields of the matching REST API object. For example, a job resource maps to the Job object.
bundle:
name: hello-bundle
resources:
jobs:
hello-job:
name: hello-job
tasks:
- task_key: hello-task
existing_cluster_id: 1234-567890-abcde123
notebook_task:
notebook_path: ./hello.py
targets:
dev:
default: trueThis is how one bundle serves several environments. Top-level settings are shared, and each target overrides only what is different. A target can set its own workspace, resources, variables, permissions, run_as, mode, presets and git. Only one target may be default: true, and that target is used when a command doesn't name one. Databricks recommends setting workspace.host per target instead of relying on the default, because it makes the configuration more portable. The CLI then looks for a matching profile in .databrickscfg, and if more than one profile matches you have to pass --profile.
Bigger projects can split configuration across files. databricks.yml lists the other files under include. You might put job definitions in one file and targets in another. databricks bundle generate can produce YAML for a resource that already exists in the workspace, and databricks bundle validate warns about unknown resource properties.
Checkpoint 2 of 5· Check yourself
A repository holds a bundle whose configuration is split across databricks.yml, jobs.yml and targets.yml. Which statement is correct?
A bundle must have exactly one databricks.yml at its root. Other configuration files are brought in with the include mapping.
“A bundle must contain one (and only one) configuration file named databricks.yml at the root of the bundle project folder.”Source: docs.databricks.com
3.Prerequisites and authentication
To build, deploy and run bundles from the CLI, you need three things. First, workspace files must be enabled in the remote workspace (they are on by default from Databricks Runtime 11.3 LTS). Second, you need Databricks CLI v0.218.0 or above; databricks --version shows what is installed. Third, the CLI must be configured to access the workspace.
Which authentication to use depends on who or what runs the deploy. For a person working interactively, Databricks recommends OAuth user-to-machine (U2M) login with databricks auth login --host <workspace-url>, which saves a configuration profile. Fully automated workflows, such as a CI pipeline deploying a bundle, should use OAuth machine-to-machine (M2M) authentication with a service principal instead. When you run bundle commands from inside the bundle folder, they authenticate with the settings in databricks.yml. To use a different profile there, pass --profile and don't pass --target.
Checkpoint 3 of 5· Check yourself
A GitHub Actions workflow will run databricks bundle deploy on every merge to main, with no person involved. Which authentication does Databricks recommend?
U2M is for trying things interactively. For fully automated workflows, Databricks recommends OAuth M2M.
“For fully automated workflows, Databricks recommends that you use OAuth machine-to-machine (M2M) authentication instead.”Source: docs.databricks.com
Checkpoint 4 of 5· Exam question
A bundle defines: ``` variables: warehouse_id: description: SQL warehouse used by the nightly job default: abc123 ``` and a job task references `${var.warehouse_id}`. A CI pipeline needs to deploy to a staging target using a different warehouse ID on every run, without editing `databricks.yml` or committing a target-specific override file. Which approach satisfies this requirement?
Correct answer: A — Export an environment variable named `BUNDLE_VAR_warehouse_id` set to the desired ID before invoking `databricks bundle deploy`, since CLI variable resolution checks that environment prefix ahead of the declared default.
- A. The `BUNDLE_VAR_<name>` environment variable convention is read by the CLI ahead of a variable's declared default, so exporting it per CI run supplies a fresh warehouse ID each time without touching any committed file.
- B. A `lookup` block resolves an object's ID by looking it up by name in the workspace; it solves a different problem than supplying a caller-chosen literal value per run and would not let CI inject an arbitrary ID.
- C. The `--profile` flag selects a named Databricks CLI authentication profile; it does not accept key-value pairs for overriding bundle variables, so this would not affect `warehouse_id` at all.
- D. A committed overrides file is lower precedence than an environment variable in the CLI's resolution order, and it would also require a file edit and commit on every run, which the requirement explicitly rules out.
4.The bundle lifecycle: init, configure, validate, deploy, run
The quickest way to start is databricks bundle init. It offers the Databricks default templates and asks questions to fill in project variables. Teams can also write custom templates that include default permissions, service principals and CI/CD configuration. Once the bundle exists, you define its settings and resources in databricks.yml and the resource files. Then you validate it, deploy it, and run its workflows. For the hello-bundle example, these commands target prod explicitly. Because dev is the default, the dev versions don't need -t.
databricks bundle validate
databricks bundle deploy -t prod
databricks bundle run -t prod hello_jobCheckpoint 5 of 5· Put it in order
Put the stages of a bundle's lifecycle in order
- 1.Deploy the bundle
- 2.Run databricks bundle init to create the project from a template
- 3.Run the deployed workflows
- 4.Validate the bundle
- 5.Define bundle settings and resources in databricks.yml and resource files
Creating the bundle comes first. Next you develop its configuration. Finally you validate, deploy, and run.
“Finally, validate and deploy your bundle, then run your workflows.”Source: docs.databricks.com
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The U2M
databricks auth loginprofile a developer uses locally is also the right credential for CI/CD bundle deployments.Why is that wrong?U2M is meant for interactive use. For fully automated workflows, Databricks recommends OAuth M2M with a service principal.
Covered in Prerequisites and authentication
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.databricks.com/aws/en/dev-tools/bundlesOfficial docs
“Declarative Automation Bundles are a feature of the Databricks CLI.”
↩︎ Bundles as infrastructure as code“The Databricks CLI can then be used to validate, deploy, and run bundles using these bundle YAML files.”
↩︎ Bundles as infrastructure as code“You must install the Databricks CLI, version v0.218.0 or above.”
↩︎ Prerequisites and authentication“Create your first bundle project using the Databricks CLI bundle init command.”
↩︎ The bundle lifecycle: init, configure, validate, deploy, run“Creating your bundle is the first step in the lifecycle of a bundle.”
↩︎ The bundle lifecycle: init, configure, validate, deploy, run“Your bundle project's collection of source files and metadata is deployed as a single bundle to your target environment.”
↩︎ Key concept“Declarative Automation Bundles are an infrastructure-as-code (IaC) approach to managing your Databricks projects.”
↩︎ Checkpoint“Finally, validate and deploy your bundle, then run your workflows.”
↩︎ Checkpoint - 2.
“The simplest databricks.yml defines the bundle name, which is a required top-level mapping, and a target deployment.”
↩︎ databricks.yml: name, resources and targets“Databricks recommends that you use the host mapping instead of the default mapping wherever possible, as this makes your bundle configuration files more portable.”
↩︎ databricks.yml: name, resources and targets“it falls back to use the notebook_task mapping within the top-level resources mapping”
↩︎ Prediction“A bundle must contain one (and only one) configuration file named databricks.yml at the root of the bundle project folder.”
↩︎ Checkpoint - 3.
“The databricks bundle validate command returns warnings if unknown resource properties are found in bundle configuration files.”
↩︎ databricks.yml: name, resources and targets - 4.
“Bundle commands use the settings in databricks.yml for authentication when run from inside the bundle folder.”
↩︎ Prerequisites and authentication
Also cited
“U2M authentication is appropriate for trying out these steps in real time.”
↩︎ Exam trap 1“For fully automated workflows, Databricks recommends that you use OAuth machine-to-machine (M2M) authentication instead.”
↩︎ Checkpoint