Databricks-DE-Assoc Working with Lakeflow Jobs Practice Question
A data engineer is building a Lakeflow Job that must process a parameterized date range. The engineer wants to pass start_date and end_date values into a notebook task at runtime and have those values available as widget-like parameters inside the notebook. Which approach should the engineer use?
⚠ Common exam trap
The trap here is assuming that cluster environment variables or external tables are the primary way to pass runtime values, when Lakeflow Jobs exposes parameters to notebooks as widgets.
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 job parameters and reference them in the notebook using the task's base parameters, then read them with dbutils.widgets.get in the notebook.
Lakeflow Jobs parameters are surfaced to notebook tasks as widget values, so the notebook can call dbutils.widgets.get with the parameter name. Defining start_date and end_date as job or task base parameters makes them available per run and visible in the job UI, enabling dynamic date-range processing without hardcoding or external lookups.
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 job parameters and reference them in the notebook using the task's base parameters, then read them with dbutils.widgets.get in the notebook.
Why this is correct
Job parameters and task base parameters are passed to notebook tasks as widget values. The notebook can retrieve them with dbutils.widgets.get using the parameter key. This is the native way to parameterize a Lakeflow Job task and makes start_date and end_date available at runtime without hardcoding values.
- ✗
Store the dates in a Delta table and have the notebook query that table at startup.
Why it's wrong here
Reading dates from a Delta table adds an external dependency and requires the table to be updated before each run. It does not pass runtime parameters into the task and introduces coupling and potential staleness. While it can work as a workaround, it is not the intended parameter-passing mechanism for Lakeflow Jobs.
- ✗
Use the notebook's %run magic to pass arguments from a parent notebook.
Why it's wrong here
%run is used to execute another notebook and pass arguments within a notebook session, but it does not integrate with Lakeflow Jobs parameter passing. The job task would still need a way to receive start_date and end_date from the job configuration. This approach adds complexity and does not use the job's parameter system.
- ✗
Set environment variables on the job cluster and read them with os.environ in the notebook.
Why it's wrong here
Environment variables can be set at the cluster level, but they are not dynamically parameterized per job run in the same way as job parameters. They also require cluster configuration changes and are less visible in the job UI. Using os.environ bypasses the native parameter mechanism and complicates per-run flexibility.
About these practice questions
Courseiva writes every Databricks-DE-Assoc question from scratch — 276 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.