What you will be able to do
- Explain how bundle commands choose their authentication and locate the bundle root
- Use databricks bundle validate to catch configuration errors and read the bundle identity summary
- Deploy a bundle to a named target with -t/--target and predict what happens when no target is given
- Describe how bundle deploy tracks resources by ID and what makes a deployment forget a resource
- Choose the right deploy flag (--force, --force-lock, --select, --fail-on-active-runs, --auto-approve, --cluster-id) for a situation
Key concept
Bundle deployment identity and state — A deployed bundle is identified by its root_path, which by default combines the deployer, the bundle name and the target name. Within that identity, the CLI records the resources it created by their IDs, not their names. Validate prints this identity, deploy creates, updates or removes resources against it, and bind and unbind edit it.
1.The bundle command group and where it gets its credentials
Declarative Automation Bundles (formerly Databricks Asset Bundles) describe jobs, Lakeflow pipelines and other Databricks resources as YAML files that sit alongside your source code. A bundle is not a separate service. Bundles are a feature of the Databricks CLI, and the CLI's bundle command group is how you validate, deploy and run them. To use it you need CLI version v0.218.0 or above, and the remote workspace must have workspace files enabled.
A bundle always goes through the same lifecycle. databricks bundle init creates a project from a template. You then define settings and resources in databricks.yml and its resource files. Finally you validate, deploy and run.
Checkpoint 1 of 7· Put it in order
Put the bundle lifecycle steps in order.
- 1.Deploy the bundle
- 2.Validate the bundle
- 3.Create the project with databricks bundle init
- 4.Define bundle settings and resources in databricks.yml and resource files
- 5.Run the workflows
Creating the bundle comes first and defining its configuration comes second. The documentation then says to validate and deploy, and only after that to run.
“Finally, validate and deploy your bundle, then run your workflows.”Source: docs.databricks.com
The folder you run a command from decides which credentials it uses. Inside the bundle folder, bundle commands authenticate with the settings in databricks.yml. If you need different credentials from inside that folder, pass a configuration profile with --profile (or -p) and leave out --target. A command that doesn't need the bundle's authentication can simply be run from outside the bundle folder.
The reverse case also comes up: running bundle commands from somewhere other than the bundle root, as a CI runner often does. For that, set the DATABRICKS_BUNDLE_ROOT environment variable. If it isn't set, the CLI looks for the bundle root in the current working directory.
Checkpoint 2 of 7· Check yourself
You are inside a bundle folder and need one bundle command to authenticate differently from the settings in databricks.yml. What does the documentation say to do?
Use a configuration profile flag and leave out --target. DATABRICKS_BUNDLE_ROOT only tells the CLI where the bundle root is. It has nothing to do with credentials.
“specify a configuration profile using the --profile (or -p) flag and do not specify a --target.”Source: docs.databricks.com
2.Catching configuration errors with bundle validate
databricks bundle validate checks that the bundle configuration files are syntactically correct. It also warns when a resource property in the configuration isn't part of that object's schema, so a misspelled job field shows up as a warning instead of passing unnoticed. By default the command also prints a summary of the bundle identity: its name, the target, and the workspace host, user and path it will deploy to.
Name: MyBundle
Target: dev
Workspace:
Host: https://my-host.cloud.databricks.com
User: someone@example.com
Path: /Users/someone@example.com/.bundle/MyBundle/dev
Validation OK!If you only want the summary of identity and resources, use bundle summary instead. Since deploy validates on its own, why run validate as a separate step? Databricks' recommended CI flow runs databricks bundle validate before deploy so that misconfigurations, such as missing libraries, are caught early, in a step that changes nothing.
Checkpoint 3 of 7· Exam question
A data engineer runs `databricks bundle validate` against their project before opening a pull request. What does this command actually verify?
Correct answer: A — It resolves and checks the bundle configuration files for syntax and structural correctness, and prints a summary of the bundle identity and resources without deploying anything
- A. This is correct: `databricks bundle validate` parses and resolves databricks.yml and any included files, checks for configuration errors, and outputs a summary of the bundle's resources without contacting the workspace to deploy anything.
- B. Uploading source files to the workspace artifact path is part of `databricks bundle deploy`, not validation; validate only checks configuration correctness locally and does not sync files.
- C. Comparing deployed resources against local configuration to detect drift is closer to what `databricks bundle plan` shows before a deploy, not what validate is designed to report.
- D. Running jobs or pipelines against a cluster is the job of `databricks bundle run`, not validate; validate never executes any workload.
3.Deploying to a target, and what makes a deployment unique
databricks bundle deploy deploys the bundle to the remote workspace. One bundle can be deployed to several workspaces, for example development, staging and production. Each of these is declared as a target, and you choose one with -t (or --target) followed by the target's name. If you give no options, the CLI uses the default target declared in the bundle configuration.
Checkpoint 4 of 7· Fill the gap
Complete the command that deploys the bundle to the target declared with the name dev.
databricks bundle deploy ? dev-t (or --target) chooses a target declared in the bundle configuration. -p chooses a CLI profile, -c overrides the cluster ID, and --select limits the deploy to particular resources.
Source: docs.databricks.comA target is more than a label, because its name is part of the bundle's identity. That identity comes from the root_path property, which defaults to ~/.bundle/${bundle.name}/${bundle.target}. By default, then, a bundle's identity is made up of the deployer, the bundle name and the target name. The Path line in the validate output above is this value. If two bundles share all three, their deployments interfere with each other.
The default root_path sits under the deployer's own ~/.bundle folder, so the deployer's identity is part of the bundle identity. Each engineer gets a separate path. Two deployments interfere only when the deployer, the bundle name and the target are all the same.
Checkpoint 5 of 7· Exam question
A team's `databricks.yml` defines a `dev` target with `default: true` and a `prod` target with no default flag. An engineer runs `databricks bundle deploy` with no additional flags from their laptop. Which target receives the deployment?
Correct answer: A — The `dev` target, because a target marked `default: true` is used automatically whenever `-t`/`--target` is omitted from the command
- A. This is correct: exactly one target can be marked `default: true` in databricks.yml, and the CLI uses that target automatically when `-t`/`--target` is not supplied on the command line.
- B. There is no fallback to whichever target happens to be listed last; target resolution is driven only by the explicit `default: true` marker, not by ordering in the file.
- C. A single `bundle deploy` invocation always deploys to exactly one target per run; it never fans out to every configured target in one command.
- D. The `-t`/`--target` flag is optional precisely because a default target can be configured; the CLI only errors on a missing target when no default has been set.
Sources2
4.How deploy tracks resources: by ID, not by name
A deployment records the resources it creates in the target workspace by their IDs, as state stored in the workspace file system. Names play no part in matching a bundle deployment to a resource. Renaming a job in the YAML therefore updates the job the deployment already tracks. Every deploy compares the configuration with that state and applies three rules.
| Situation | Result of bundle deploy |
|---|---|
| Resource is in the bundle configuration but not in the target workspace | It is created |
| Resource is in the bundle configuration and already exists in the target workspace | It is updated in the workspace |
| Resource was previously deployed but has been removed from the bundle configuration | It is removed from the target workspace |
The third rule matters most. Deleting a job from the YAML and deploying deletes that job in the workspace. The documentation says a resource's association with a bundle can only be forgotten if you change the bundle name, the target, or the workspace, and that bundle validate outputs a summary containing these values.
The deployer is a separate point. It is part of a bundle's default identity, because the default root_path sits under the deployer's own ~/.bundle folder. But it is not in the documentation's list of three changes. Keep the two statements apart: the identity (deployer, name, target) decides which deployments interfere with each other, and the list (name, target, workspace) is what the documentation gives for forgetting the association with a resource.
Checkpoint 6 of 7· Check yourself
Which change makes a deployment lose its association with the resources it created earlier?
Only a change to the bundle name, the target or the workspace makes the association be forgotten. A rename or an edit is applied as an update to the resource the state already tracks.
“A resource's association with a bundle can only be forgotten if you change the bundle name, the bundle target, or the workspace.”Source: docs.databricks.com
Sources2
5.Deploy flags that change the rules
Several bundle deploy flags matter in automated pipelines. Two of them are easy to mix up. --force overrides validations that would otherwise block a deployment. --force-lock overrides the deployment lock that keeps concurrent deployments apart.
| Flag | What it does | Caveat |
|---|---|---|
| --auto-approve | Skips interactive approvals that might be required for deployment | Needed when no one is present to answer a prompt |
| --fail-on-active-runs | Fails if there are running jobs or pipelines in the deployment | Stops a deploy from changing resources that are in the middle of a run |
| --force | Overrides validations that block a deployment, including Git branch validation against the target's git.branch | For dashboards, also overwrites a dashboard that was modified in the workspace after the last deployment |
| --force-lock | Forces acquisition of the deployment lock | Only if a previous deployment crashed or was interrupted and left a stale lock file |
| --select | Deploys only the named resources, e.g. jobs.my_job, and their upstream dependencies | Databricks recommends it only for development workspaces and not for production: downstream resources are not updated |
| -c, --cluster-id | Overrides the cluster in the deployment with the given cluster ID | Example: databricks bundle deploy --cluster-id 0123-456789-abcdef |
Checkpoint 7 of 7· Match them up
Match each situation to the deploy flag that fits it.
Tap a term, then the definition that fits it.
--force overrides validations such as the Git branch check. --force-lock exists only to recover from a stale lock. The other two control approvals and active runs.
“It should only be used if the previous deployment crashed or was interrupted and left a stale lock file.”Source: docs.databricks.com
Sources2
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.bundle deploy skips configuration checking unless bundle validate has been run first.Why is that wrong?
Deploy runs validation itself, and a validation failure fails the deployment. CI flows still run validate explicitly to catch misconfigurations early.
Covered in Catching configuration errors with bundle validate
2.Bundle deploy finds existing workspace resources by name, so renaming a job creates a new one.Why is that wrong?
Deploy tracks the resources it created by ID, in state stored in the workspace. A rename becomes an update. Only a change of bundle name, target or workspace breaks the association.
3.The deployer is one of the things whose change makes a deployment forget its resources, so the list is name, target and deployer.Why is that wrong?
The deployer is part of a bundle's default identity, but the documented list of changes that make the association be forgotten is the bundle name, the target and the workspace.
4.--force and --force-lock are interchangeable ways to push a blocked deployment through.Why is that wrong?
--force overrides validations such as the Git branch check and dashboard overwrite protection. --force-lock only takes over the deployment lock, and should only be used after a crashed or interrupted deployment.
Covered in Deploy flags that change the rules
5.--select is a safe way to speed up production deployments by pushing only the job that changed.Why is that wrong?
Databricks recommends --select only for development workspaces. Downstream resources and dependencies are not updated.
Covered in Deploy flags that change the rules
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.”
↩︎ The bundle command group and where it gets its credentials“You must install the Databricks CLI, version v0.218.0 or above.”
↩︎ The bundle command group and where it gets its credentials“Your remote Databricks workspaces must have workspace files enabled.”
↩︎ The bundle command group and where it gets its credentials“Finally, validate and deploy your bundle, then run your workflows.”
↩︎ Checkpoint - 2.
“Bundle commands use the settings in databricks.yml for authentication when run from inside the bundle folder.”
↩︎ The bundle command group and where it gets its credentials“Validate bundle configuration files are syntactically correct.”
↩︎ Catching configuration errors with bundle validate“outputs warnings if resource properties are defined in the bundle configuration files that are not found in the corresponding object's schema”
↩︎ Catching configuration errors with bundle validate“If you only want to output a summary of the bundle's identity and resources, use bundle summary.”
↩︎ Catching configuration errors with bundle validate“If no command options are specified, the default target as declared within the bundle configuration files is used.”
↩︎ Deploying to a target, and what makes a deployment unique“If these are identical across different bundles, deployment of these bundles will interfere with one another.”
↩︎ Deploying to a target, and what makes a deployment unique“tracks the resources it creates in the target workspace by their IDs as a state that is stored in the workspace file system”
↩︎ How deploy tracks resources: by ID, not by name“If a resource is removed from the bundle configuration, it is removed from the target workspace if it was previously deployed.”
↩︎ How deploy tracks resources: by ID, not by name“Therefore by default, a bundle's identity is comprised of the identity of the deployer, the bundle's name, and the bundle's target name.”
↩︎ How deploy tracks resources: by ID, not by name“Fail if there are running jobs or pipelines in the deployment.”
↩︎ Deploy flags that change the rules“Only the specified resource(s) and required upstream dependencies are deployed; downstream resources and dependencies are not updated.”
↩︎ Deploy flags that change the rules“Fundamentally, the root_path property is what determines a bundle's unique identity, which defaults to ~/.bundle/${bundle.name}/${bundle.target}.”
↩︎ Key concept“Resource names are not used to correlate between a bundle deployment and a resource instance”
↩︎ Exam trap 2“A resource's association with a bundle can only be forgotten if you change the bundle name, the bundle target, or the workspace.”
↩︎ Exam trap 3“--force overrides Git branch validation, so a deployment proceeds even when your current Git branch doesn't match the git.branch configured for the target.”
↩︎ Exam trap 4“Databricks recommends only using this option for deploying resources to development workspaces. It is not intended for use in production.”
↩︎ Exam trap 5“specify a configuration profile using the --profile (or -p) flag and do not specify a --target.”
↩︎ Checkpoint“A resource's association with a bundle can only be forgotten if you change the bundle name, the bundle target, or the workspace.”
↩︎ Checkpoint“It should only be used if the previous deployment crashed or was interrupted and left a stale lock file.”
↩︎ Checkpoint - 3.
“You can run databricks bundle commands outside of the bundle root by setting the DATABRICKS_BUNDLE_ROOT environment variable.”
↩︎ The bundle command group and where it gets its credentials - 4.
“This step ensures that misconfigurations, for example, missing libraries, are caught early.”
↩︎ Catching configuration errors with bundle validate
Also cited
“Bundle validation is automatically performed as part of this deployment.”
↩︎ Exam trap 1“Bundle validation is automatically performed as part of this deployment.”
↩︎ Prediction