Databricks-DE-Assoc Implementing CI/CD Practice Question
A CI/CD pipeline uses the Databricks CLI to deploy a job to production. The pipeline must ensure that the job configuration is identical across environments except for the cluster size, which differs between staging and production. Which approach best supports this requirement?
⚠ Common exam trap
It's easy for candidates to confuse runtime parameters (like widgets) with deployment-time configuration, which must be injected before the job is created or updated.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Define the job in a JSON file with placeholders, and use environment variables in the CI/CD pipeline to substitute cluster size values before deployment.
Templating the job JSON with environment variables allows the pipeline to substitute environment-specific values like cluster size while keeping the rest of the configuration identical. This ensures consistency and reduces drift, as the same template is used for all environments, and differences are explicitly managed through variables.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Define the job in a JSON file with placeholders, and use environment variables in the CI/CD pipeline to substitute cluster size values before deployment.
Why this is correct
Using a templated JSON file with environment-specific variables allows the pipeline to inject the correct cluster size at deployment time. This keeps the job definition consistent across environments while allowing controlled differences. It is a common pattern for infrastructure-as-code and aligns with CI/CD best practices for Databricks jobs.
- ✗
Maintain separate JSON files for staging and production, and manually update both when the job logic changes.
Why it's wrong here
Maintaining separate files increases the risk of configuration drift and human error. If the job logic changes, both files must be updated, which is error-prone and not scalable. This approach undermines the goal of a single source of truth and automated deployment.
- ✗
Store the job definition in a Databricks notebook and use widgets to parameterize the cluster size at runtime.
Why it's wrong here
Widgets are for runtime parameters in notebooks, not for defining job cluster configurations. Job clusters are specified in the job settings, not in notebook code. This approach would not allow the cluster size to be set at deployment time and would require manual input each run, which is not suitable for CI/CD.
- ✗
Use the Databricks REST API to create the job in production, then manually edit the cluster size in the Databricks UI after deployment.
Why it's wrong here
Manual edits after deployment break the automation and introduce inconsistency. The next pipeline run would overwrite the manual change unless the pipeline accounts for it, leading to unpredictable behavior. CI/CD should fully manage the job configuration without manual intervention.
About these practice questions
This Databricks-DE-Assoc question is part of Courseiva's 276-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Databricks exam blueprint
This Databricks-DE-Assoc practice question is part of Courseiva's free Databricks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the Databricks-DE-Assoc exam.