Databricks Asset Bundles Cheat Sheet

Updated 2026-04-27

🧠Study flashcards on this topic119 cards · spaced repetition→

Declarative Automation Bundles (DABs, formerly Databricks Asset Bundles — officially renamed March 16, 2026) are an infrastructure-as-code framework that enables developers to programmatically define, deploy, and manage Databricks resources—including jobs, notebooks, pipelines, clusters, apps, and Unity Catalog objects—using declarative YAML or Python configuration. Introduced as Databricks' native CI/CD solution, DABs facilitate software engineering best practices such as source control, code review, automated testing, and multi-environment deployments (dev → staging → production). A key evolution in 2025–2026: DABs now support Python-based configuration (via bundle.py and @job_mutator decorators) and a direct deployment engine that removes the Terraform dependency and will become the sole supported deployment path. A key mental model: bundles treat your entire Databricks project—code, configuration, and dependencies—as a single deployable unit, ensuring consistency and reproducibility across environments.

What This Cheat Sheet Covers

This topic spans 19 focused tables and 206 indexed concepts, 119 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Concepts and TerminologyTable 2: CLI Commands for Bundle LifecycleTable 3: Bundle Configuration File StructureTable 4: Target Configuration and Environment ManagementTable 5: Variables and SubstitutionsTable 6: Resource Types - Jobs and WorkflowsTable 7: Resource Types - Data Pipelines and Unity CatalogTable 8: Resource Types - Visualization and MonitoringTable 9: Artifact and Library ManagementTable 10: Deployment Modes and StrategiesTable 11: Authentication and AuthorizationTable 12: Permissions and Access ControlTable 13: Include and Modular ConfigurationTable 14: CI/CD Integration PatternsTable 15: Advanced Features and TechniquesTable 16: Python-Based Bundle ConfigurationTable 17: Troubleshooting and DebuggingTable 18: Best PracticesTable 19: Comparison with Alternative Tools

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Concepts and Terminology

The vocabulary you'll see in every bundle project — bundles, targets, resources, variables, and the databricks.yml that ties them together. Getting these terms straight early pays off, especially the distinction between a bundle (your whole deployable project) and a target (one environment's overrides), plus newer arrivals like the Terraform-free direct deployment engine and Python-based configuration.

Concept	Example	Description
bundle	`databricks.yml` at project root	A package containing all YAML/Python configuration files, source code, notebooks, and artifacts needed to deploy a Databricks project as a single unit.
databricks.yml	`bundle:` `name: my_project` `targets:` `dev:`	The primary configuration file (required at bundle root) that defines bundle metadata, resources, targets, and deployment settings.
target	`targets:` `dev:` `production:`	An environment-specific configuration (e.g., dev, staging, production) that overrides base settings for workspace, compute, and permissions.
resources	`resources:` `jobs:` `pipelines:`	The mapping section in YAML where you define Databricks assets like jobs, pipelines, apps, model serving endpoints, schemas, and volumes.
variable	`variables:` `catalog:` `default: dev`	A custom placeholder that can be referenced via `${var.catalog}` throughout YAML, making configurations reusable across targets.
template	`databricks bundle init default-python`	A project scaffold providing pre-configured folder structure, sample code, and YAML configuration to jumpstart bundle development.
mode	`mode: production`	The deployment mode (development or production) that determines isolation behavior, immutability, and whether resources can be modified post-deploy.
run_as	`run_as:` `service_principal_name: sp123`	• The execution identity for deployed workflows • separates who deploys from who runs, recommended as service principal for production.
workspace	`workspace:` `host: https://...` `root_path: /Users/...`	The Databricks workspace connection details, including host URL and deployment path where bundle resources are created.
artifact	`artifacts:` `- type: whl` `path: ./dist/*.whl`	A build output (e.g., Python wheel, JAR file) referenced in the bundle, automatically built and uploaded during deployment.
include	`include:` `- resources/*.yml`	A glob pattern specifying additional YAML files to merge into the bundle configuration, supporting modular project structure.
direct deployment engine	`bundle:` `deployment:` `kind: direct`	• A Terraform-free deployment engine that uses direct CRUD operations via the CLI • becoming the default; Terraform engine is being deprecated.
Python configuration	`bundle.py` or `mutators.py` at root	• Python-based bundle definition and mutation • jobs and pipelines can be fully defined in Python or mutated programmatically via `@job_mutator` decorators.
sync	`databricks bundle deploy --sync`	A continuous synchronization feature that watches local file changes and automatically redeploys notebooks/files to the workspace during development.

Table 2: CLI Commands for Bundle Lifecycle

The databricks bundle commands that carry a project from creation to teardown. The core loop is init → validate → deploy → run, with destroy to clean up; the rest handle migration (generate reverse-engineers existing jobs into YAML) and deployment edge cases like a stuck lock. These are the commands you'll wire into CI pipelines.

Command	Example	Description
bundle init	`databricks bundle init default-python`	• Initializes a new bundle from a built-in or custom template • creates folder structure and configuration files.

The rest of this section is part of the full cheat sheet

Table 3: Bundle Configuration File Structure

A map of the top-level sections inside databricks.yml. Each block owns a distinct concern — bundle for metadata, workspace for where it deploys, resources for what gets created, targets for per-environment overrides, and variables/artifacts/include for reuse and modularity. Knowing which section a setting belongs in saves a lot of validation errors.

Section	Example	Description
bundle	`bundle:` `name: my_project` `git:`	The top-level metadata defining bundle name, Git source repository URL, and optional provider settings.

The rest of this section is part of the full cheat sheet

Table 4: Target Configuration and Environment Management

Targets are how one codebase deploys cleanly to dev, staging, and production — and these are the knobs each target can turn. The big lever is mode (development vs production), which flips isolation and immutability behavior wholesale. The presets family is the time-saver here: name prefixes, tags, pause status, and concurrency limits applied across every resource in the environment at once.

Setting	Example	Description
mode	`mode: development`	• Sets deployment isolation level • `development` allows concurrent personal deployments, `production` enforces workspace-wide uniqueness and immutability.

The rest of this section is part of the full cheat sheet

Table 1: Core Concepts and Terminology

Concept	Example	Description
bundle	`databricks.yml` at project root	A package containing all YAML/Python configuration files, source code, notebooks, and artifacts needed to deploy a Databricks project as a single unit.
databricks.yml	`bundle:` `name: my_project` `targets:` `dev:`	The primary configuration file (required at bundle root) that defines bundle metadata, resources, targets, and deployment settings.
target	`targets:` `dev:` `production:`	An environment-specific configuration (e.g., dev, staging, production) that overrides base settings for workspace, compute, and permissions.
resources	`resources:` `jobs:` `pipelines:`	The mapping section in YAML where you define Databricks assets like jobs, pipelines, apps, model serving endpoints, schemas, and volumes.
variable	`variables:` `catalog:` `default: dev`	A custom placeholder that can be referenced via `${var.catalog}` throughout YAML, making configurations reusable across targets.
template	`databricks bundle init default-python`	A project scaffold providing pre-configured folder structure, sample code, and YAML configuration to jumpstart bundle development.
mode	`mode: production`	The deployment mode (development or production) that determines isolation behavior, immutability, and whether resources can be modified post-deploy.
run_as	`run_as:` `service_principal_name: sp123`	• The execution identity for deployed workflows • separates who deploys from who runs, recommended as service principal for production.
workspace	`workspace:` `host: https://...` `root_path: /Users/...`	The Databricks workspace connection details, including host URL and deployment path where bundle resources are created.
artifact	`artifacts:` `- type: whl` `path: ./dist/*.whl`	A build output (e.g., Python wheel, JAR file) referenced in the bundle, automatically built and uploaded during deployment.
include	`include:` `- resources/*.yml`	A glob pattern specifying additional YAML files to merge into the bundle configuration, supporting modular project structure.
direct deployment engine	`bundle:` `deployment:` `kind: direct`	• A Terraform-free deployment engine that uses direct CRUD operations via the CLI • becoming the default; Terraform engine is being deprecated.
Python configuration	`bundle.py` or `mutators.py` at root	• Python-based bundle definition and mutation • jobs and pipelines can be fully defined in Python or mutated programmatically via `@job_mutator` decorators.
sync	`databricks bundle deploy --sync`	A continuous synchronization feature that watches local file changes and automatically redeploys notebooks/files to the workspace during development.

Table 2: CLI Commands for Bundle Lifecycle

Command	Example	Description
bundle init	`databricks bundle init default-python`	• Initializes a new bundle from a built-in or custom template • creates folder structure and configuration files.

Table 3: Bundle Configuration File Structure

Section	Example	Description
bundle	`bundle:` `name: my_project` `git:`	The top-level metadata defining bundle name, Git source repository URL, and optional provider settings.

Table 4: Target Configuration and Environment Management

Setting	Example	Description
mode	`mode: development`	• Sets deployment isolation level • `development` allows concurrent personal deployments, `production` enforces workspace-wide uniqueness and immutability.

Declarative Automation Bundles (DABs) Cheat Sheet

Table 1: Core Concepts and Terminology

Table 2: CLI Commands for Bundle Lifecycle

Table 3: Bundle Configuration File Structure

Table 4: Target Configuration and Environment Management

Declarative Automation Bundles (DABs) Cheat Sheet

Table 1: Core Concepts and Terminology

Table 2: CLI Commands for Bundle Lifecycle

Table 3: Bundle Configuration File Structure

Table 4: Target Configuration and Environment Management