Databricks-DE-Assoc Implementing CI/CD Practice Question
A team is using Databricks Asset Bundles (DABs) to deploy a job to multiple environments (dev, staging, prod). They need to ensure that the job uses different cluster sizes and schedules per environment. Which DABs feature should they use?
⚠ Common exam trap
The trap here is thinking that external templating or post-deployment API calls are needed, when DABs natively support environment-specific configuration through targets.
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 separate bundle configuration files for each environment and use the --target flag with databricks bundle deploy.
Databricks Asset Bundles use targets to define environment-specific overrides in the databricks.yml file. When deploying, the --target flag selects the target, applying the corresponding cluster size and schedule. This keeps a single source of truth while allowing differences per environment, which is essential for promoting bundles through dev, staging, and prod.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the Databricks REST API to update the job configuration after deployment with environment-specific values.
Why it's wrong here
Using the REST API to patch job configurations after deployment is an imperative approach that bypasses the declarative nature of DABs. It introduces drift between the bundle definition and the actual job state, making rollbacks and audits difficult. DABs should manage the full lifecycle declaratively.
- ✗
Create a separate Databricks workspace for each environment and hardcode the cluster size and schedule in the job definition.
Why it's wrong here
Hardcoding values defeats the purpose of environment-specific configuration and requires maintaining multiple copies of the job definition. While separate workspaces are common, the bundle should still parameterize differences. Hardcoding makes promotion error-prone and violates DRY principles.
- ✓
Define separate bundle configuration files for each environment and use the --target flag with databricks bundle deploy.
Why this is correct
Databricks Asset Bundles support targets, which are defined in the databricks.yml file. Each target can override resource properties such as cluster size and schedule. Using the --target flag selects the appropriate configuration for deployment. This is the intended way to manage environment-specific settings in DABs.
- ✗
Use Jinja2 templating in the job definition to inject environment-specific values from environment variables.
Why it's wrong here
While Jinja2 templating can be used in some CI/CD tools, Databricks Asset Bundles do not natively support Jinja2 templating for job definitions. The bundle schema uses YAML with variable substitution, but not Jinja2. Using environment variables directly is possible but less structured than targets.
About these practice questions
One of 276 original Databricks-DE-Assoc practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.