Data Engineer Associate · Domain 5: Implementing CI/CD · 10% of the exam
Task 5.2: Understand environment-specific configuration using Automation Bundle (formerly Databricks Asset Bundles) variables and overrides while promoting the same codebase across dev, test, and prod targets.
Custom variables and their defaults, lookups, substitutions, target overrides, and the ways a value is set for one deployment.
Study it
Bundle variables, substitutions and target overrides
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the Databricks documentation page that proves it.
Question 1 · choose 1
A bundle's databricks.yml contains:
variables:
warehouse_id:
default: abc
targets:
prod:
variables:
warehouse_id: def
A CI job runs:
BUNDLE_VAR_warehouse_id=ghi databricks bundle deploy -t prod --var="warehouse_id=xyz"
No variable-overrides.json file exists. Which value does ${var.warehouse_id} resolve to?
Aabc
Bdef
Cghi
Dxyz
Show the answer and why
Aabc
Incorrect
The top-level default is the last place the CLI looks; any other source of a value wins over it.
Bdef
Incorrect
The target's variables mapping is checked after --var, BUNDLE_VAR_ environment variables and variable-overrides.json.
Cghi
Incorrect
A BUNDLE_VAR_ environment variable ranks below a --var option given on the command line.
Dxyz
Correct
The CLI checks --var options first, so the value passed on the command line is used.
The CLI resolves a variable in order: --var, then BUNDLE_VAR_ environment variables, then variable-overrides.json, then the target's variables mapping, then the default.
A bundle contains:
resources:
jobs:
etl:
job_clusters:
- job_cluster_key: main
new_cluster:
spark_version: 15.4.x-scala2.12
node_type_id: i3.xlarge
num_workers: 2
targets:
prod:
resources:
jobs:
etl:
job_clusters:
- job_cluster_key: main
new_cluster:
num_workers: 8
Which cluster settings does the etl job get when deployed with -t prod?
Aspark_version 15.4.x-scala2.12, node_type_id i3.xlarge and num_workers 2
Bnum_workers 8 alone, with no spark_version or node_type_id
Cspark_version 15.4.x-scala2.12, node_type_id i3.xlarge and num_workers 8
DThe deployment fails because job_cluster_key main is defined twice
Show the answer and why
Aspark_version 15.4.x-scala2.12, node_type_id i3.xlarge and num_workers 2
Incorrect
The target's value for num_workers overrides the top-level value for the same job_cluster_key.
Bnum_workers 8 alone, with no spark_version or node_type_id
Incorrect
Target settings are joined with the top-level settings; unspecified fields keep their top-level values.
Cspark_version 15.4.x-scala2.12, node_type_id i3.xlarge and num_workers 8
Correct
Settings for the same job_cluster_key are merged, and for conflicts the targets mapping takes precedence.
DThe deployment fails because job_cluster_key main is defined twice
Incorrect
Defining the same key under a target is the intended way to override or join settings.
Target overrides join with top-level resource settings by key, such as job_cluster_key for job clusters or task_key for tasks, with target values winning conflicts.
A bundle's job tasks need the ID of a SQL warehouse named 'Shared Analytics', which has a different ID in each workspace. The team wants the ID resolved from the name at deployment instead of maintained by hand. How should the variable be defined?
AA lookup by name: lookup: warehouse: 'Shared Analytics'
BThe warehouse ID hard-coded under each target's variables mapping
CThe ${workspace.host} substitution in each task's settings
Dtype: complex with the warehouse name set as the variable's default
Show the answer and why
AA lookup by name: lookup: warehouse: 'Shared Analytics'
Correct
A lookup resolves a named object's ID, so the correct ID is used in each workspace.
BThe warehouse ID hard-coded under each target's variables mapping
Incorrect
This works but must be updated by hand whenever a warehouse is recreated, which the team wants to avoid.
CThe ${workspace.host} substitution in each task's settings
Incorrect
This substitution returns the workspace URL, not a warehouse ID.
Dtype: complex with the warehouse name set as the variable's default
Incorrect
A complex variable holds only the value it is given; it does not resolve a name to an ID.
Variable lookups resolve IDs for objects such as clusters, warehouses, jobs, pipelines and service principals by name. A missing or duplicate name causes an error.
A bundle deploys one Lakeflow pipeline to dev, test and prod. Its target schema must be sales_dev, sales_test or sales_prod depending on the target, from a single pipeline definition. Which value should the pipeline's schema field use?
Asales_${bundle.environment}
Bsales_${workspace.current_user.short_name}
Csales_${var.schema}, without declaring var.schema
Dsales_${bundle.target}
Show the answer and why
Asales_${bundle.environment}
Incorrect
The documentation says to use ${bundle.target} instead of ${bundle.environment}.
Bsales_${workspace.current_user.short_name}
Incorrect
This varies by the deploying user, not by the target.
Csales_${var.schema}, without declaring var.schema
Incorrect
A variable must be declared, and given a value, before it can be referenced.
Dsales_${bundle.target}
Correct
${bundle.target} resolves to the target name at deployment, giving one definition that adapts to each target.
Substitutions such as ${bundle.target}, ${bundle.name} and ${workspace.current_user.userName} insert deployment context into resource settings.
A bundle job reads ${var.run_date}. After deploying, an engineer runs databricks bundle run my_job --var="run_date=2026-10-01", but the run uses the value from the last deployment. How should a different date be passed for each run?
ARedeploy the bundle with the new --var value before each run
BDefine a job parameter and pass it with bundle run --params
CSet BUNDLE_VAR_run_date before calling bundle run
DPut the date in .databricks/bundle/<target>/variable-overrides.json
Show the answer and why
ARedeploy the bundle with the new --var value before each run
Incorrect
This works but turns every run into a deployment, which is not how per-run values are meant to be passed.
BDefine a job parameter and pass it with bundle run --params
Correct
Bundle variables are resolved at deployment; job parameters carry run-time values into a run.
CSet BUNDLE_VAR_run_date before calling bundle run
Incorrect
Environment variables also set a deployment-time variable value, with the same limitation as --var.
DPut the date in .databricks/bundle/<target>/variable-overrides.json
Incorrect
This file is another source of deployment-time variable values.
Bundle variables shape what is deployed; job parameters shape each run. Use bundle run --params for values that change between runs.