Working with Lakeflow Jobs practice questions

Retries and timeouts are separate task settings; a timeout triggers a retry only when retry on timeout is enabled.

The task did have retries, yet none ran, which tells you the retry policy does not cover timeouts by default. Enabling retry on timeout treats a timed-out attempt like a failed one and starts the next attempt. A longer timeout or a job-level timeout changes when the run is stopped but not whether it retries, and the retry interval only spaces out retries that already apply.

1. Note that retries exist but did not fire after a timeout.
2. Recall that timeouts are not retried unless retry on timeout is on.
3. Enable that option on the task's retry policy.
4. Reject options that only change timing or the job-level limit.

Exam tip: A timed-out task is retried only when retry on timeout is enabled.

When both a timeout and retries are set, the timeout applies to each attempt, and the number of attempts is one more than the retry count.

Three facts combine here. First, the retry count is in addition to the original attempt, so two retries means up to three attempts. Second, Databricks applies the task timeout to each retry rather than to the task overall. Third, the retry interval is measured from the start of the failed attempt to the start of the retry, so with 20-minute attempts the one-minute interval has long elapsed when an attempt times out and adds nothing. Three attempts of up to 20 minutes is about 60 minutes. Treating the timeout as a cap on the whole task, or counting only two attempts, underestimates the worst case.

1. Count attempts: the first run plus each configured retry.
2. Recall that the timeout applies to every attempt separately.
3. Recall that the retry interval counts from the start of the failed attempt, so it adds no time when it is shorter than the attempt.
4. Multiply attempts by the timeout and compare with options that treat the timeout as a total.

Exam tip: Worst-case task time is about (retries + 1) x timeout when the retry interval is shorter than an attempt.

Run if decides when a task starts based on the results of the tasks it depends on; All done ignores those results.

Cleanup work has to happen whatever the upstream outcome. All done waits for every dependency to finish and then runs regardless of status. The default, All succeeded, and None failed both skip the task when a load fails, and At least one succeeded still skips it when every load fails.

1. Identify the requirement: run after every dependency, whatever its result.
2. Map that to All done.
3. Check each alternative for a case where it would skip the cleanup.
4. Choose the condition with no such case.

Exam tip: Cleanup or audit tasks that must always run use Run if All done.

Failure-handling tasks use the failure-based Run if conditions: At least one failed or All failed.

The quarantine must react to any single failure and stay idle otherwise. At least one failed starts the task when one or more dependencies fail, and when they all succeed the task is excluded rather than run. All failed needs every validation to fail, All done runs in every case, and None failed fires only on the happy path.

1. State the trigger: one or more failures among the dependencies.
2. State the non-trigger: all dependencies succeed.
3. Match both to At least one failed.
4. Reject conditions that need every failure or that run regardless.

Exam tip: Run a handler on any upstream failure with At least one failed; on total failure with All failed.

Run if picks when a task starts; the job run status is decided by the leaf tasks, the tasks with no downstream dependencies.

At least one succeeded runs the summary when either region loaded and skips it when both fail, which matches the requirement; All done would run it after a double failure. For the status, Databricks reports Succeeded with failures when some tasks failed but every leaf task succeeded, and Failed only when a leaf task fails. The summary is the only leaf and it succeeded.

1. Translate the rule: run if either load succeeds, not if both fail.
2. Map it to At least one succeeded.
3. Identify the leaf tasks: only the summary.
4. A failed non-leaf task with successful leaves gives Succeeded with failures.

Exam tip: Job status follows the leaf tasks: all leaves succeeded but something failed means Succeeded with failures.

The overall run status depends on the leaf tasks: Failed only when a leaf task fails, Succeeded with failures when only non-leaf tasks failed.

The audit task is the only leaf and it succeeded because All done runs it regardless of the ingest result. Databricks therefore reports Succeeded with failures, not Failed. That matters for monitoring: an alert that watches only for Failed misses this run, so failure notifications should also be set on the ingest task itself or on the Succeeded with failures state.

1. Find the leaf tasks of the job: the audit task.
2. Check the leaf's result: succeeded.
3. Recall the rule: failed tasks plus successful leaves is Succeeded with failures.
4. Note the monitoring impact on a Failed-only alert.

Exam tip: An All done cleanup leaf can turn a failed run into Succeeded with failures; alert on the task, not only the job.