Data Engineer Professional · Domain 8: Debugging and Deploying · 10% of the exam
Task 8.2: Analyze the errors and remediate the failed job runs with job repairs and parameter overrides.
Repair runs, rerunning failed and dependent tasks, changing parameters for a repair or a run, and what a repair keeps from the original run.
Study it
Repairing failed runs and overriding parameters
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the Databricks documentation page that proves it.
Question 1 · choose 1
In a five-task job, the task load_gold appends rows to a gold table and failed halfway because of a bad lookup, after writing about half of its output. The engineer fixed the lookup and wants to repair the run so that only load_gold and its dependents run again, without leaving duplicate rows. What must be true before the repair?
ANothing; repair resumes load_gold from the row where it stopped
BThe job must be run again with Run now instead of repaired
CThe successful tasks must be disabled before the repair
Dload_gold writes idempotently, for example with MERGE or a scoped overwrite
Show the answer and why
ANothing; repair resumes load_gold from the row where it stopped
Incorrect
Repairs rerun tasks from the start, not from a saved position.
BThe job must be run again with Run now instead of repaired
Incorrect
Run now reruns all five tasks and still appends duplicates.
CThe successful tasks must be disabled before the repair
Incorrect
Repair already skips successful tasks; disabling them does not stop duplicates.
Dload_gold writes idempotently, for example with MERGE or a scoped overwrite
Correct
A repair reruns each unsuccessful task from the beginning, and jobs do not make tasks idempotent, so the task's own write must be safe.
Repair runs only the unsuccessful tasks and their dependents. Each rerun task starts from the beginning, so a task that wrote part of its output must use idempotent operations such as overwrite or merge.
A nightly multi-task run failed at its third task because the job parameter run_date was passed as 2026-13-01. The first two tasks succeeded and must not run again. How should the engineer rerun the failed work with run_date = 2026-10-30?
AUse Run now with run_date = 2026-10-30
BRepair run, with run_date = 2026-10-30 in the Repair dialog
CHardcode the date in the third task's notebook and repair
DRepair the run without changes, then fix the parameter later
Show the answer and why
AUse Run now with run_date = 2026-10-30
Incorrect
Run now starts a new run of every task, including the two that succeeded.
BRepair run, with run_date = 2026-10-30 in the Repair dialog
Correct
Parameters entered in the Repair dialog override existing values for the tasks that are rerun.
CHardcode the date in the third task's notebook and repair
Incorrect
Hardcoding breaks later runs and is not needed, because the repair can override parameters.
DRepair the run without changes, then fix the parameter later
Incorrect
The rerun task would get the same invalid date and fail again.
A repair reruns the unsuccessful tasks and their dependents. In the Repair job run dialog you can add or edit parameters, which override the existing values for that repair.
Tasks of a failed run shared the job cluster my_job_cluster. After a repair, the engineer sees a cluster named my_job_cluster_v1. Why?
AThe repair upgraded the cluster to a newer Databricks Runtime
BThe first cluster was deleted because its tasks failed
CRepairs always run on serverless compute with a new name
DRepairing tasks that shared a job cluster creates a new one
Show the answer and why
AThe repair upgraded the cluster to a newer Databricks Runtime
Incorrect
The name shows a new cluster, not an upgrade.
BThe first cluster was deleted because its tasks failed
Incorrect
The original remains visible with its settings.
CRepairs always run on serverless compute with a new name
Incorrect
Repairs use the tasks' configured compute.
DRepairing tasks that shared a job cluster creates a new one
Correct
The new cluster keeps the original run's cluster visible for comparison.
If tasks share a job cluster, a repair run creates a new job cluster, such as my_job_cluster_v1, so the clusters of the initial and repair runs can be told apart.
A task was disabled when the run happened, but the engineer now wants it to run as part of a repair through the API. How?
AList the task in rerun_tasks in the repair request
BNothing; a repair always runs tasks that were disabled
CDelete the task and add it again before the repair
DStart a new run of the job with Run now instead
Show the answer and why
AList the task in rerun_tasks in the repair request
Correct
Repairs use run state; listing a disabled task in rerun_tasks forces it to run.
BNothing; a repair always runs tasks that were disabled
Incorrect
Repairs decide by run state, so the task must be named.
CDelete the task and add it again before the repair
Incorrect
Recreating the task is not needed.
DStart a new run of the job with Run now instead
Incorrect
That reruns everything, not a repair.
Repairs use each task's run state to decide what to repair, not whether it is disabled. To force a disabled task to run in a repair, include it in rerun_tasks.