Task 5.3: Deploy Declarative Automation Bundles (formerly Databricks Asset Bundles) to package, configure, and promote Lakeflow Jobs, Lakeflow Spark Declarative Pipelines, and other workspace assets across dev, test, and prod environments.

• ADevelopment mode removes the schedule mapping from deployed jobs

  Incorrect

  The schedule is deployed; development mode changes its pause status rather than removing it.

• BDevelopment mode pauses the schedules and triggers of deployed resources

  Correct

  Deploying in development mode pauses the schedules and triggers of the deployed resources, so the daily schedule exists but does not fire.

• CDevelopment mode needs --cluster-id, and the deploy command did not pass it

  Incorrect

  --cluster-id is optional in development mode; it lets you override cluster definitions but is not required.

• DDevelopment mode starts jobs through databricks bundle run instead of schedules

  Incorrect

  bundle run is one way to start a run; the schedule stays defined but paused, and unpausing it restores scheduled runs.

Development mode adds a [dev user] prefix, marks pipelines as development, allows concurrent runs, disables the deployment lock and pauses schedules and triggers.

• Arun_as with the deploying engineer's user_name

  Incorrect

  Running as a person ties production to that person's account and permissions, which is what the team wants to avoid.

• Bmode: production with no run_as mapping

  Incorrect

  Production mode adds checks to the deployment, but it does not choose the identity the job runs as.

• Crun_as with a service principal's application ID in service_principal_name

  Correct

  A service principal in run_as decouples the run identity from whoever deployed and can be given only the permissions the workflow needs.

• Dpermissions that grant CAN_MANAGE on the job to the data engineering group

  Incorrect

  Permissions control who can view or manage the job; they do not change the identity the job runs as.

Databricks recommends a service principal as the run_as identity for production targets. It separates deploying from running and supports least privilege.

• Atargets

  Incorrect

  targets holds per-environment settings and overrides; the objects the bundle deploys are defined elsewhere.

• Bvariables

  Incorrect

  variables declares custom values that the rest of the configuration can reference.

• Cartifacts

  Incorrect

  artifacts describes build outputs such as Python wheels.

• Dresources

  Correct

  resources defines the Databricks objects the bundle deploys, such as jobs and pipelines, often split into files listed under include.

databricks.yml holds the bundle name and mappings such as include, variables, artifacts, resources, workspace and targets.

• AThe deployment lock keeps the second developer's deploy from starting

  Incorrect

  The lock prevents concurrent deployments to the same destination; it does not give each user a separate destination.

• BThe default root_path includes each deployer's user folder

  Correct

  root_path defaults to ~/.bundle/${bundle.name}/${bundle.target}, so the deployer's identity is part of the bundle's identity.

• CGit branch validation keeps each developer on a separate branch

  Incorrect

  Branch validation checks the current Git branch; it does not decide where a deployment is stored.

• Drun_as gives each deployment a different service principal

  Incorrect

  run_as does not affect where a bundle is deployed; the deployment location comes from the workspace settings.

A bundle deployment is identified by its root_path, which by default combines the deploying user, the bundle name and the target.

• AIt stays in the workspace and is no longer tracked by the bundle

  Incorrect

  The deployment tracks the resources it created, so a resource removed from the configuration is not left behind.

• BThe deployment fails until the job is deleted by hand

  Incorrect

  Deploy updates the workspace to match the configuration; removing a resource is a normal change.

• CIt is deleted from the target workspace on that deploy

  Correct

  If a resource is removed from the bundle configuration, deploy removes it from the target workspace when it was previously deployed.

• DIt is renamed with a [removed] prefix and paused

  Incorrect

  Bundles do not rename or pause a resource that was removed from the configuration.

Bundle deployments keep state keyed by resource IDs: new resources are created, existing ones updated and removed ones deleted.

• AChange the bundle configuration and deploy the bundle again

  Correct

  Bundle-deployed jobs are read-only in the UI by default; editing the configuration and redeploying keeps the bundle and the job in sync.

• BAsk an admin for CAN MANAGE on the job, then edit it in the UI

  Incorrect

  The job is read-only because it is managed by a bundle, not because of permissions.

• CDisconnect the job from source and edit it in the UI

  Incorrect

  Disconnecting allows urgent UI edits, but those changes are not applied to the bundle, which stops being the source of truth.

• DUpdate the job directly with the Jobs API

  Incorrect

  Changing the job outside the bundle makes it drift from the configuration until the next deploy overwrites it.

Treat the bundle configuration as the source of truth: change the files, review them and redeploy. Disconnect from source only for emergencies.