Data-Engineer-Associate - Implementing CI/CD (10% of the exam) - Section 5.2

Understand environment-specific configuration using bundle variables and overrides while promoting the same codebase across dev, test and prod targets.

Define bundle variables and per-target overrides so one codebase deploys to dev, test and prod with different workspaces, catalogs and compute. Explain how target mode (development versus production) changes resource naming and scheduling.

Declarative Automation Bundlesbundle variablestargetsoverridesdevelopment mode

Practice question for this objective

Free sampleImplementing CI/CDhard

A team promotes one job definition across dev, test and prod with Declarative Automation Bundles. Each environment needs a different Unity Catalog catalogue name and a different worker count on the job cluster, while the notebook code and the job structure stay identical. The team wants a single job declaration in the bundle and no hand editing between deployments. Which approach fits the requirement?

variables:
  catalog_name:
    description: Unity Catalog catalogue the job writes to
    default: dev_catalog
  worker_count:
    default: 2

ADeclare the catalogue and the worker count as bundle variables, reference them in the single job declaration, set each target's values in that target's variables mapping, and deploy with the target selected by the -t flag. Correct
BKeep one databricks.yml per environment in separate directories of the repository, each holding its own copy of the job declaration, and deploy whichever file matches the environment being promoted.
CDeploy the bundle once with its defaults and then adjust the catalogue and the worker count on the deployed job in the workspace user interface for each environment after the deployment finishes.
DCreate a git branch per environment, commit the environment values into the job declaration on each branch, and deploy the branch that matches the environment being promoted.

Promote one bundle definition across environments by parameterising it with bundle variables and setting each value in the target's variables mapping. A bundle variable declared once and referenced inside a resource lets a single job declaration carry environment specific values. Each target supplies its own value in that target's variables mapping, so selecting the target at deploy time resolves the reference. The structure of the job stays in one place, which is what makes promotion across dev, test and prod repeatable.

Why A is correct: Correct: one job declaration references the variables, and each target supplies its own values, so the same codebase is promoted and only the environment specific values change.

Why B is wrong: Tempting because it does give each environment its own values, but it duplicates the job declaration three times, so a structural change has to be applied in three places and the copies drift.

Why C is wrong: Tempting because the change is quick, but a later deploy reconciles the deployed job with the bundle configuration and overwrites those manual edits, so the environments drift silently between deployments.

Why D is wrong: Plausible because branches do isolate values, but promoting code then means merging between long-lived branches that differ by configuration, which is the drift the bundle target mechanism exists to remove.

See more Data-Engineer-Associate practice questions, answers explained.

Exam traps in Implementing CI/CD

Answers that look right on this material and are not. Each one is a distractor from a different question in the Data-Engineer-Associate bank for this domain.

The schedule block is read for production targets alone, so a development deployment drops the schedule from the job definition and the job can be started by hand.
Why it is wrong: Tempting because the deployed job does not fire on its own, but the schedule is present in the deployed job and merely paused, so it has not been dropped from the definition.
The prod target is deployed, because a target that declares mode: production outranks any other target whenever the deploy command names none.
Why it is wrong: It is tempting because production mode does add stricter behaviour, such as refusing the development name prefix and keeping schedules unpaused, so it reads as the privileged target. It is wrong because mode changes how a target is deployed, not whether it is selected; target selection is decided by the default key or the target flag alone.
The job definition has been written into the prod workspace so that reviewers can inspect it there, with its schedule left paused until a later deployment enables it.
Why it is wrong: Tempting because reviewing the resolved definition is exactly the engineer's goal, but writing resources into a workspace is the job of databricks bundle deploy, and validate creates nothing remotely.

Examworthy is not affiliated with or endorsed by Databricks. Original, blueprint-aligned practice material only.