Finding and handling where a DAG run actually failed
When a dbt run fails partway through the DAG, dbt provides several tools to diagnose the failure and efficiently resume execution without rerunning successful models. Understanding error types, state-based reruns, and the run_results.json artifact is essential for managing failure points in production pipelines.
Must-know
- dbt distinguishes between compilation errors (caught before execution, e.g. Jinja/SQL syntax issues) and database errors (raised by the warehouse during model execution, e.g. type mismatches or permission issues), both shown in the CLI output with the failing model name.
- When a model fails, dbt marks all downstream dependent models as 'skipped' rather than attempting to run them, since their inputs would be invalid or missing.
- The
dbt run --select result:error+ --state path/to/artifacts(orresult:error) pattern uses the previousrun_results.jsonto rerun only models that errored (and optionally their downstream dependents), avoiding a full pipeline rerun. - Similarly,
--select result:skippedcan be used to rerun models that were skipped due to an upstream failure, after the root cause is fixed. - Tests failing (as opposed to models failing) produce a 'fail' or 'warn' status but do not block downstream models from running unless configured with
error_if/severity settings or the models are explicitly selected based on test results. - Common root causes of DAG failure points include schema/column changes upstream, missing or stale source data, hard-coded references instead of
ref()/source()breaking lineage, and warehouse-level issues like permissions, timeouts, or credit/resource limits.
A model's schema.yml contains:
models:
- name: stg_customers
columns:
- name: customer_id
tests:
- not_null:
config:
severity: error
The test currently fails on three rows because of a known, temporary upstream data issue that the source team is fixing next week. You want dbt build to keep running the rest of the DAG (and still clearly report the failure) without stopping on this test. Which change accomplishes this with the least disruption?
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.