A Lakeflow Job runs five notebook tasks that all need the same processing date for a given run. The team wants that value set in one place per run, without editing five task configurations whenever it changes, and wants each notebook to read it as an ordinary parameter. Which statement about job parameters is correct?
{{job.parameters.processing_date}}- AJob parameters are fixed at the moment the job definition is saved, so supplying a different processing date means editing the job definition itself rather than starting another run with a new value.
- BJob parameters are scoped to the first task in the graph, so the remaining four tasks receive the processing date only if that task writes it out again for them to read.
- CJob parameters apply only to pipeline tasks, so the five notebook tasks have to take the processing date from a widget default written into each notebook instead.
- DJob parameters are defined once on the job, are available to every task in the run, and reach a task through a parameter value written with the {{job.parameters.processing_date}} reference syntax. Correct
Why A is wrong: Tempting because the parameter keys are indeed part of the job definition, but the values carry defaults that can be replaced when a run is triggered, which is the whole point of parameterising a run.
Why B is wrong: This confuses job parameters with task values, which are written by one task and read by another; job parameters are attached to the run and need no relay task.
Why C is wrong: Plausible because notebooks do expose widgets, but job parameters are not restricted by task type, and a widget default hard codes the value in five places, which is the problem being solved.
Why D is correct: Correct: the parameter is declared at job level, a value may be supplied when the run starts, and each task picks it up by referencing it in its own parameters.