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

Deploy Declarative Automation Bundles (formerly Databricks Asset Bundles) to package, configure and promote Lakeflow Jobs, pipelines and other workspace assets.

Structure a bundle's configuration file with resources for jobs and Lakeflow Spark Declarative Pipelines, deploy it, and promote the same definition across environments. Recognise why a bundle beats manual copying or notebook revision history for repeatable deployment.

Declarative Automation BundlesDatabricks Asset Bundlesdatabricks.ymlbundle resourcesenvironment promotion

Practice question for this objective

Free sampleImplementing CI/CDmedium

A Declarative Automation Bundle has declared two Lakeflow Jobs, ingest_orders and rebuild_marts, and a continuous integration pipeline deploys it to the prod target on every merge. A pull request removes the rebuild_marts declaration from databricks.yml because the workload has been retired, and the pipeline deploys the merged configuration to prod. What happens to rebuild_marts in the prod workspace?

databricks bundle deploy -t prod

AIt stays in the workspace with its schedule active, because a deployment adds and updates the declared resources and leaves anything not mentioned in the configuration alone.
BIt stays in the workspace with its schedule paused, because the deployment marks resources dropped from the configuration as inactive so that their run history is preserved.
CIt is removed from the workspace, but the deployment fails afterwards, because a bundle cannot deploy a target whose declared resource set differs from the state recorded for it.
DIt is removed from the workspace, because the deployment reconciles the target with what the configuration declares and the state it holds for previously deployed resources. Correct

Bundle deployment is declarative: it reconciles a target workspace with the configuration, so deleting a resource declaration removes that resource on the next deploy. Each deployment to a target records which resources the bundle created there. On a later deployment the CLI compares the declared resources with that record, creating and updating what is declared and deleting what is no longer declared, which is why removing a job key retires the job rather than orphaning it.

Why A is wrong: Tempting because many deployment tools are additive in exactly this way, but bundle deployment is declarative and tracks what it previously created, so an undeclared resource does not simply persist.

Why B is wrong: Tempting because pausing a schedule is genuine bundle behaviour in development mode, but that applies to jobs the bundle deploys, and it is not what happens to a resource removed from the configuration.

Why C is wrong: The removal is right but the failure is invented, because a difference between the configuration and the recorded state is the normal case that a deployment exists to resolve.

Why D is correct: Correct: the bundle records the resources it deployed to that target, so a resource that disappears from the configuration is removed on the next deployment rather than being left behind as an orphan.

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 continuous integration pipeline is deploying a stale commit, so the engineer should have the pipeline fetch the latest main branch before it runs the deploy command and then trigger it again.
Why it is wrong: Tempting because a stale checkout does produce surprising deployments, but the restored value is the one currently committed, so the pipeline is deploying the intended commit and the cause lies elsewhere.
It creates a fresh copy of every job under a new name on each deployment, so that earlier versions stay in the workspace and can be selected for a rollback.
Why it is wrong: Tempting because rollback is a genuine continuous delivery concern, but bundles roll back by deploying an earlier commit, and duplicate jobs would immediately double every schedule.
Deploying starts each job it creates once, so the missing run means the job was already present in prod and was updated rather than created by this merge.
Why it is wrong: Tempting because a first deployment does feel different from an update, but deployment never triggers a run in either case, so the presence of the job beforehand does not explain the missing run.

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