Databricks ML Professional Practice Question 6: Bundle Development Mode
Databricks Certified Machine Learning Professional · Test 1 · question 6 of 10
An ML team manages its weekly retraining job with a bundle (Declarative Automation Bundles, formerly Databricks Asset Bundles). databricks.yml defines a dev target with mode: development and a prod target with mode: production. The job has a cron schedule. After running databricks bundle deploy -t dev, the workspace shows a job named [dev jsmith] weekly_retrain that has never started on its schedule. The same job deployed to prod runs every week.
What is the most likely explanation?
Show answer and explanation
Answer:
mode: development applies defaults meant for fast, safe iteration. It prefixes resource names with [dev ${workspace.current_user.short_name}] (the [dev jsmith] in the stem), tags them dev, allows concurrent job runs, turns off the deployment lock, and pauses all schedules and triggers. The pause stops each developer's copy from running on the production cadence. If you really want the schedule to run in dev, override it with the trigger_pause_status preset or on the job's own schedule. Settings on a resource take precedence over presets, and presets take precedence over mode defaults.
Option B is wrong because the schedule is deployed. It is just in a paused state.
Option C confuses a production recommendation with a requirement. Production mode recommends a service principal through run_as. A development deployment runs as the deploying user, and that is not why the job is idle.
Option D is backwards. Development mode disables the deployment lock, and a lock controls concurrent deployments, not job runs.