Reference card. The control-flow operators are Job-level and were built in depth in [Jobs & orchestration — multi-task, dependencies, control flow](/lessons/s1-jobs-orchestration/) — this ties them off with the exam tells. One idea: a Job isn't just a straight chain; it can branch and fan out.
The operators
| Operator | What it does | Exam tell |
|---|---|---|
depends_on | task B runs only after task A succeeds; independent tasks run in parallel | enforce order / express a DAG |
| Condition task (if/else) | branches on a boolean (usually from a task value); the untaken branch is skipped, not failed | "route to X or Y based on a computed value" (e.g. quality_score > 0.95 → load, else quarantine) |
| For-each task | runs one task template over a list, instances in parallel (with a concurrency limit) | "run the same logic over N inputs/regions/report-types" |
outcome: "failed" dependency | a downstream task that runs only when upstream failed | alerts / cleanup on failure |
The two tells that get tested
- "Download/process the same thing for many inputs, in parallel, with retries" (e.g. many report types from a flaky REST API) → a for-each task with the list as input, retries per task. (et-q260.)
- "Do different work depending on a value computed by an earlier task" → a condition (if/else) task reading a task value — recall values come back as strings, so cast (
[Reference card — job parameters & secrets in notebooks](/lessons/s1-job-params-widgets/)).
That's the whole surface. Depth, cluster choices, task values, and the no-cross-task-rollback rule all live in [Jobs & orchestration — multi-task, dependencies, control flow](/lessons/s1-jobs-orchestration/).
Recall (say without scrolling up)
- "Same logic over 15 report types, in parallel" — which operator?
- "Branch to load-or-quarantine on a computed score" — which operator, and what happens to the branch not taken?
- Where does the value the condition task reads come from, and what type does it arrive as?