Re-running only what failed with dbt retry
The dbt retry command re-executes only the nodes that failed or were skipped in the most recent dbt invocation, using the run_results.json file to determine what to rerun. This saves time in development and CI by avoiding a full re-run of successful models, tests, or seeds. It works with any dbt command that produces run_results.json, such as run, build, test, or seed.
Must-know
- dbt retry reads the
run_results.jsonartifact from the prior invocation to identify nodes with a status of error, fail, or skipped. - It reruns the failed/skipped nodes using the exact same command and flags (e.g., full-refresh, target, vars) as the original invocation that produced
run_results.json. - If no
run_results.jsonis found, or if the prior run had zero failures, dbt retry will raise an error since there is nothing to retry. - dbt retry does not accept its own selection criteria (like --select or --exclude); it strictly reuses the failed/skipped node set from the previous run.
- You must run dbt retry from the same project directory (and target/profile context) as the original failed invocation for the artifacts to be valid.
- Successful nodes from the prior run are left untouched and are not rerun, which distinguishes retry from simply rerunning the full original command.
After a failed dbt build run, a developer deletes the target directory to tidy up local artifacts, then immediately runs dbt retry. The command fails with an error stating that no previous run results could be found. Why does this happen?
What you have tried across dbt Analytics Engineering's objectives, not a readiness score.
Developing and optimizing dbt models
- Tracing and confirming a model's upstream raw sources
- How dbt's core materialization types differ
- Keeping models modular and avoiding repeated logic
- What each core dbt command actually does
- Shaping a model's dependency graph so it stays readable
- Setting project-wide configuration in dbt_project.yml
- Pulling in and using a dbt package
- Writing a model in Python instead of SQL
- Granting model access through the grants config
- Configuring a snapshot to track slowly changing data
- Picking the right incremental strategy for a dataset
- Dry-running a model to check its logic and schema before a real build
- Sampling a model run before a full build
- What microbatch and other advanced materializations are for
Managing dbt models governance
Debugging data modeling errors
Troubleshooting and optimizing dbt pipelines
Implementing dbt tests
Implementing and maintaining external dependencies
Coverage checked against the published exam guide on Aug 5, 2026.
These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.