Data-Engineer-Associate - Working with Lakeflow Jobs (16% of the exam) - Section 4.1

Implement control flows (retries and conditional tasks such as branching and looping) using Lakeflow Jobs for pipeline orchestration.

Configure task retries and timeouts, If/else condition tasks for branching, For each tasks for looping over inputs, and Run if dependency conditions. Predict which downstream tasks run after an upstream failure or success.

task retriesIf/else condition taskFor each taskRun if conditionstask values

Practice question for this objective

Free sampleWorking with Lakeflow Jobsmedium

A Lakeflow Job has four tasks. Task C lists task A and task B as its dependencies, and no Run if condition has been changed from its default anywhere in the job. Task A succeeds, and task B fails on its only attempt because no retries are configured. What happens to task C and to the job run?

ATask C starts as soon as task A finishes, because a dependency edge fixes the ordering of tasks and does not gate a task on the outcome of the tasks above it.
BTask C is skipped because the default Run if condition requires every dependency to succeed, and the job run itself is reported as failed rather than as successful. Correct
CTask C starts once both task A and task B have reached a terminal state, and it receives the failure of task B as an input value that its own code can branch on.
DTask C fails immediately with the same error that task B raised, so the completed run records two failed tasks alongside the one task that finished successfully.

A task's default Run if condition requires all its dependencies to succeed, so a failed upstream task leaves it skipped. Each dependency edge in the Lakeflow Jobs task graph carries a Run if condition, which defaults to All succeeded. The scheduler evaluates that condition once every dependency reaches a terminal state, and because task B failed the condition cannot be met, so task C is never started and is recorded with a skipped outcome. Conditions such as All done or At least one succeeded exist precisely to change this behaviour when a downstream task should still run, and the job run reports failure because it contains a failed task.

Why A is wrong: Tempting because a dependency does control ordering, which is the part most candidates remember, but the edge also carries a condition, and the default condition requires success rather than mere completion.

Why B is correct: Correct: the default Run if condition on a task is All succeeded, so a failed dependency leaves task C unexecuted, and a run containing a failed task is recorded as a failed run.

Why C is wrong: This describes the All done condition combined with an If/else style branch, neither of which is in force here, so task C is not offered any outcome value to branch on under the default configuration.

Why D is wrong: Plausible because the run as a whole does fail, but a task that never executes is recorded as skipped rather than failed, and an error from one task is not propagated as the result of another.

See more Data-Engineer-Associate practice questions, answers explained.

Exam traps in Working with Lakeflow Jobs

Answers that look right on this material and are not. Each one is a distractor from a different question in the Data-Engineer-Associate bank for this domain.

Return the list from segment with dbutils.notebook.exit and have enrich call dbutils.notebook.run against the segment notebook to receive the returned value before it processes the identifiers.
Why it is wrong: Tempting because dbutils.notebook.exit does hand a value from one notebook to a caller, but the exit value is a small string subject to its own size limit, and calling dbutils.notebook.run would execute the segment logic a second time inside enrich rather than reuse the completed task.
Have the rebuild notebook read the count from a job parameter widget at the top of its first cell and call a notebook exit immediately when the value is zero, leaving the job graph itself unchanged.
Why it is wrong: This does skip the work, but the task still starts and pays for compute, and the branch logic ends up buried in notebook code rather than visible in the job graph, which the requirement rules out.
load_full is skipped, publish is marked failed because a dependency did not succeed, and the run is reported as failed even though load_incremental finished.
Why it is wrong: It is tempting because the default Run if condition does block publish, but a dependency that was skipped produces a skipped task rather than a failed one, and a skipped task does not fail the run.

Examworthy is not affiliated with or endorsed by Databricks. Original, blueprint-aligned practice material only.