Skip to content

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?

  1. Aabc
  2. Bdef
  3. Cghi
  4. 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.

Question 2 · choose 1

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?

  1. Aspark_version 15.4.x-scala2.12, node_type_id i3.xlarge and num_workers 2
  2. Bnum_workers 8 alone, with no spark_version or node_type_id
  3. Cspark_version 15.4.x-scala2.12, node_type_id i3.xlarge and num_workers 8
  4. 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.

Question 3 · choose 1

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?

  1. AA lookup by name: lookup: warehouse: 'Shared Analytics'
  2. BThe warehouse ID hard-coded under each target's variables mapping
  3. CThe ${workspace.host} substitution in each task's settings
  4. 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.

Question 4 · choose 1

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?

  1. Asales_${bundle.environment}
  2. Bsales_${workspace.current_user.short_name}
  3. Csales_${var.schema}, without declaring var.schema
  4. 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.

Question 5 · choose 1

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?

  1. ARedeploy the bundle with the new --var value before each run
  2. BDefine a job parameter and pass it with bundle run --params
  3. CSet BUNDLE_VAR_run_date before calling bundle run
  4. 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.

Practise domain 5 →Practise all domains →