Study Databricks DE-PRO Lakeflow Jobs: key concepts, common traps, and exam decision cues.
The exam is not asking whether you can write one ETL notebook. It is asking whether you can turn pipeline logic into a production workflow with clear orchestration boundaries.
| Requirement | Better first lane |
|---|---|
| managed batch or streaming ETL with declarative quality controls | Lakeflow Declarative Pipelines |
| scheduling, dependencies, notifications, and reruns | Lakeflow Jobs |
| branch or iterate across tasks | control flow in Jobs and pipeline design |
| side-effect-heavy task that should not blindly retry | explicit retry and failure policy review |
| Layer | What belongs there |
|---|---|
| Lakeflow Declarative Pipelines | transformation logic, expectations, declarative ETL behavior |
| Lakeflow Jobs | scheduling, dependencies, retries, notifications, execution flow |
| deployment config | target-aware environment settings and promotion behavior |
Many wrong answers happen because the stem is about orchestration but the candidate answers with transformation tooling, or the reverse.
| If the stem says… | Strong reading |
|---|---|
| “build reliable production pipeline” | choose the workflow that is easiest to observe and rerun |
| “control flow operators” | know when orchestration logic belongs outside raw transformation code |
| “environment configs and dependencies” | promotion should be target-aware, not hard-coded |
| “retries” | retry policy must fit the side effects and blast radius of the task |
Professional orchestration is not “retry until green.” It means:
That is why Jobs and declarative pipelines appear together in this blueprint even though they are not the same feature.
| Trap | Better rule |
|---|---|
| mixing pipeline logic and orchestration into one notebook | keep the layers separate |
| assuming all failed tasks should auto-retry | some tasks need controlled failure behavior |
| treating Lakeflow Jobs and Lakeflow Declarative Pipelines as the same thing | one defines pipeline logic, the other controls execution flow |
| Scenario clue | Stronger answer shape |
|---|---|
| “managed ETL with built-in visibility and expectations” | Declarative Pipelines |
| “task dependencies, notifications, scheduling, reruns” | Jobs |
| “same code must promote with different environment configs” | target-aware deployment config |
| “rerun is risky because side effects are not idempotent” | controlled retry policy review |
This objective usually tests whether you can separate orchestration from pipeline logic. If the question is about managed ETL logic, think Lakeflow Declarative Pipelines. If it is about task ordering, retries, notifications, or run control, think Jobs. The weakest answer usually treats them as the same service layer or assumes retries are always safe without considering side effects.