What you will be able to do
- Run the bundle lifecycle with validate, deploy and run, choosing the environment with -t/--target
- Explain how a deployment tracks resources and what causes them to be created, updated or removed
- Contrast development and production deployment modes and decide when to use presets
- Choose the right deploy flag (--force, --select, --fail-on-active-runs) for a promotion scenario
1.validate, deploy, run, and choosing a target
Bundles are deployed with the Databricks CLI. You need CLI version v0.218.0 or above, and the remote workspaces must have workspace files enabled. Workspace files are on by default from Databricks Runtime 11.3 LTS. A new project usually starts from a template with databricks bundle init. You then define settings and resources in databricks.yml, and finally validate, deploy and run.
Checkpoint 1 of 7· Put it in order
Put the bundle lifecycle steps in order
- 1.Create the project with databricks bundle init
- 2.Push the bundle to a workspace with databricks bundle deploy
- 3.Start a deployed job or pipeline with databricks bundle run
- 4.Define settings and resources in databricks.yml and resource files
- 5.Check the configuration with databricks bundle validate
Creating the bundle comes first, then development of its configuration, then validation and deployment, and running workflows comes last.
“Finally, validate and deploy your bundle, then run your workflows.”Source: docs.databricks.com
validate checks the YAML and warns about unknown resource properties. It also prints a summary of the bundle's name, target and workspace. Every command takes -t or --target to pick the environment. If you leave it out, the CLI uses the target marked default: true. Promoting from dev to prod means running the same commands against the same files with a different target.
# You must specify "-t prod", because the "dev" target
# is already set to "default: true":
databricks bundle validate
databricks bundle deploy -t prod
databricks bundle run -t prod hello_jobCheckpoint 2 of 7· Fill the gap
dev is the default target. Which flag deploys this bundle to prod?
# You must specify "-t prod", because the "dev" target
# is already set to "default: true":
databricks bundle validate
databricks bundle deploy ? prod
databricks bundle run -t prod hello_job-t (--target) selects a target declared in the bundle configuration. -p selects a CLI profile, --select limits which resources are deployed, and -c overrides the cluster ID.
Source: docs.databricks.com2.What a deployment tracks
One bundle can be deployed to several workspaces, such as development, staging and production. Each deployment has an identity set by root_path, which defaults to ~/.bundle/${bundle.name}/${bundle.target}. By default, that identity combines the deploying user, the bundle name and the target name. Two deployments with the same three values will interfere with each other.
The deployment stores the IDs of the resources it created as state in the workspace file system. On each deploy, a resource that is in the configuration but not in the workspace is created. One that exists in both is updated. One that was previously deployed but is no longer in the configuration is removed. Names are not used for matching, so a job in the workspace that happens to have the same name is not taken over by the bundle.
Checkpoint 3 of 7· Check yourself
Which change makes a bundle forget its association with a job it deployed earlier?
The association is based on IDs within the deployment's identity. Only changing the bundle name, the target or the workspace breaks it.
“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
Checkpoint 4 of 7· Exam question
Which top-level mapping in a `databricks.yml` bundle configuration file is required and defines the bundle's name along with settings such as the Databricks CLI version constraint?
Correct answer: B — bundle
- resources. The resources mapping holds the definitions of jobs, pipelines, dashboards, and similar workspace assets, but it does not name the bundle itself or set the CLI version constraint.
- bundle. The bundle mapping is the required top-level block that names the bundle and can specify settings such as the required Databricks CLI version, making it the correct answer.
- workspace. The workspace mapping specifies connection details such as host, profile, and root path for where the bundle deploys, not the bundle's own name or CLI version constraint.
- targets. The targets mapping defines the deployment environments (such as dev and prod) and their overrides, but it is not where the bundle's name or CLI version requirement is declared.
Sources2
3.Development and production modes
A target can set mode: development or mode: production. Each mode applies a set of default behaviours in one step. Modes are optional, and a bundle deploys without one. There is no test mode. A test or staging environment is just another target, usually with its own host, variables and possibly presets.
targets:
dev:
mode: development| Behaviour | mode: development | mode: production |
|---|---|---|
| Resource names | Prefixed with [dev ${workspace.current_user.short_name}]; jobs and pipelines get a dev tag | Not described |
| Lakeflow pipelines | Marked development: true | Validated to be development: false |
| Schedules and triggers | Paused; unpause a job with pause_status: UNPAUSED | Not described |
| Cluster override | --cluster-id or cluster_id overrides all cluster definitions | Overriding existing cluster definitions is not allowed |
| Concurrency and locking | Concurrent runs enabled; deployment lock disabled (re-enable with bundle.deployment.lock.enabled) | Not described |
| Git and identity | Not described | Current branch must match git.branch if set; run_as with a service principal recommended |
If production deployments do not run as a service principal, production mode also checks that artifact_path, file_path, root_path and state_path are not overridden to a specific user, and that run_as and permissions are specified. To stop non-admin users from changing deployed assets, and to keep in-progress deployments from affecting running jobs, Databricks suggests deploying to an immutable, read-only folder.
Checkpoint 5 of 7· Check yourself
A developer deploys with -t dev, where dev uses mode: development. The job's daily schedule never fires. What is the most likely cause?
Development mode pauses schedules and triggers. Set pause_status to UNPAUSED on the job to let it run.
“Pauses all schedules and triggers on deployed resources such as jobs or quality monitors.”Source: docs.databricks.com
Sources4
4.Presets and deploy flags for controlled promotion
Presets let you set individual target behaviours yourself, such as a name prefix, the pipeline development flag, trigger pause status, job concurrency and tags. They are useful when a mode's defaults don't suit an environment, for example a shared test target.
targets:
dev:
presets:
name_prefix: 'testing_' # prefix all resource names with testing_
pipelines_development: true # set development to true for pipelines
trigger_pause_status: PAUSED # set pause_status to PAUSED for all triggers and schedules
jobs_max_concurrent_runs: 10 # set max_concurrent runs to 10 for all jobs
tags:
department: financeA few deploy flags matter when promoting. --force overrides blocking validations, including the production Git branch check. For dashboards, it also overwrites changes made in the workspace since the last deploy. --fail-on-active-runs stops the deploy if any of the bundle's jobs or pipelines are running. --auto-approve skips interactive approvals, which suits non-interactive CI runs. --force-lock takes the deployment lock and should only be used when a crashed deployment has left a stale lock behind. --select deploys only the named resources and their upstream dependencies. Databricks advises using it only for development workspaces.
Checkpoint 6 of 7· Match them up
Match each databricks bundle deploy flag to its effect
Tap a term, then the definition that fits it.
Each flag relaxes or tightens a different deploy safeguard. Only --select is limited to development use.
“--force overrides Git branch validation”Source: docs.databricks.com
Checkpoint 7 of 7· Exam question
A `databricks.yml` file defines a `dev` target with `mode: development` and a `prod` target with `mode: production`. A developer runs `databricks bundle deploy` with no `-t` flag from a workspace where `dev` is marked `default: true`. What happens?
Correct answer: B — The bundle deploys against the `dev` target's configuration, since a target flagged `default: true` is used automatically when none is specified.
- A. The CLI does not require an explicit `-t` flag on every invocation; when a target is marked as the default, omitting the flag does not produce an error.
- B. Exactly one target can be marked `default: true` in a bundle, and the CLI falls back to that target automatically whenever `-t`/`--target` is omitted, so the deploy targets `dev`.
- C. A single `bundle deploy` invocation acts on one target at a time; it does not fan out to every target defined in the configuration file in one command.
- D. Target selection is driven by the `default: true` flag in configuration or an explicit `-t` argument, not by a locally cached record of the last deployment.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A test environment needs mode: test, and a target cannot deploy without a mode.Why is that wrong?
Modes are optional, and the documentation describes only development and production. A test or staging environment is simply another target.
Covered in Development and production modes
2.A bundle finds existing workspace jobs by name and takes them over on deploy.Why is that wrong?
Deployments track resources by the IDs stored in their state. Names are never used for matching.
Covered in What a deployment tracks
3.--select is a safe way to promote one changed job to production.Why is that wrong?
--select does not update downstream resources and can cause dependency errors. Databricks restricts it to development workspaces.
Covered in Presets and deploy flags for controlled promotion
Practise it for real
Create a bundle, deploy it to a development target, and run its job from the CLI
1.Run databricks bundle init and choose a default template
Why: Templates are the quickest way to get a working databricks.yml with resources and targets
You should see: A project folder containing databricks.yml at its root
2.Open databricks.yml and confirm the dev target has mode: development and default: true
Why: Development mode prefixes names, pauses schedules and marks pipelines as development
You should see: A targets mapping with a dev entry, plus any other targets the template created
3.Run databricks bundle validate
Why: Catches configuration errors and unknown properties, and summarises the name, target and workspace
You should see: A summary with no errors
4.Run databricks bundle deploy -t dev
Why: Creates the bundle's resources in the workspace and records their IDs in deployment state
You should see: Jobs or pipelines appear in the workspace with the [dev <your short name>] prefix and paused schedules
5.Run databricks bundle run -t dev <job key from your resources mapping>
Why: Starts the deployed workflow from the command line
You should see: A run starts for the deployed job
Stuck? Get a nudge
If the deploy prefix doesn't appear, check that you deployed the target that has mode: development.
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
“You must install the Databricks CLI, version v0.218.0 or above.”
↩︎ validate, deploy, run, and choosing a target“Finally, validate and deploy your bundle, then run your workflows.”
↩︎ Checkpoint - 2.
“If no command options are specified, the default target as declared within the bundle configuration files is used.”
↩︎ validate, deploy, run, and choosing a target“specify a configuration profile using the --profile (or -p) flag and do not specify a --target”
↩︎ validate, deploy, run, and choosing a target“A bundle can be deployed to multiple workspaces, such as development, staging, and production workspaces.”
↩︎ What a deployment tracks“a bundle's identity is comprised of the identity of the deployer, the bundle's name, and the bundle's target name”
↩︎ What a deployment tracks“Fail if there are running jobs or pipelines in the deployment.”
↩︎ Presets and deploy flags for controlled promotion“Resource names are not used to correlate between a bundle deployment and a resource instance”
↩︎ Exam trap 2“It is not intended for use in production.”
↩︎ Exam trap 3“If a resource is removed from the bundle configuration, it is removed from the target workspace if it was previously deployed.”
↩︎ Prediction“A resource's association with a bundle can only be forgotten if you change the bundle name, the bundle target, or the workspace.”
↩︎ Checkpoint“--force overrides Git branch validation”
↩︎ Checkpoint - 3.
“The databricks bundle validate command returns warnings if unknown resource properties are found in bundle configuration files.”
↩︎ validate, deploy, run, and choosing a target - 4.
“Prepends all resources that are not deployed as files or notebooks with the prefix [dev ${workspace.current_user.short_name}]”
↩︎ Development and production modes“Validates that the current Git branch is equal to the Git branch that is specified in the target.”
↩︎ Development and production modes“setting the mode mapping to production does not allow overriding any existing cluster definitions”
↩︎ Development and production modes“Databricks recommends that you use service principals for production deployments.”
↩︎ Development and production modes“presets override the default mode behavior, and settings of individual resources override the presets”
↩︎ Presets and deploy flags for controlled promotion“Deployment modes are optional. You can deploy bundles without setting a mode or configuring presets.”
↩︎ Exam trap 1“Pauses all schedules and triggers on deployed resources such as jobs or quality monitors.”
↩︎ Checkpoint“If a schedule is set to UNPAUSED, but the trigger_pause_status preset is set to PAUSED, the schedule will be unpaused.”
↩︎ Prediction