Selecting models by comparing against a prior run's state
dbt's --state flag enables comparing the current project against artifacts (primarily manifest.json) from a previous run, allowing commands to target only resources that have changed. This powers state-based selection methods like state:modified and state:new, which are foundational for slim CI and efficient deployments.
Must-know
- The --state flag points to a directory containing a prior run's artifacts (manifest.json, and optionally
run_results.json), which must be generated by a previous dbt invocation and stored/retrieved (e.g., via dbt Cloud artifacts or CI caching). - state:modified selects resources whose definitions changed relative to the stored state, including changes to SQL/Python code, configs, schema.yml properties, and referenced macros; state:new selects resources that exist in the current project but not in the prior state.
- The result:error, result:fail, and result:skipped selection methods require
run_results.jsonfrom the prior invocation (not just manifest.json) and are typically used for rerunning failed or skipped nodes. - Combining --select state:modified+ with --defer allows a slim CI workflow: only modified models and their downstream dependents are built/tested, while unmodified upstream models resolve to their production-built relations via the deferred manifest.
- State comparison is sensitive to non-functional changes like whitespace or comment edits only if dbt's parsing detects a change in the compiled/checksum representation; purely cosmetic changes that don't alter the parsed node are generally not flagged as modified.
- The
DBT_STATEenvironment variable or the --state flag must resolve to a valid path at invocation time, and mismatched dbt versions or adapter versions between the stored state and current run can cause comparison errors or false positives.
You want to run a CI job that only builds and tests the models and their dependents that were changed in an open pull request, comparing against the production manifest as a baseline. Which command accomplishes this?
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.