Fixing and testing a change before it merges
Once a bug in a dbt model is diagnosed, the fix must be developed in a feature branch and validated locally before merging to a protected branch (e.g., main). This involves rerunning the affected model(s), checking dependent models and tests, and confirming the fix resolves the issue without introducing regressions.
Must-know
- Use
dbt run --select model_name+to rebuild the fixed model and all downstream dependents, ensuring the fix doesn't break anything relying on it. - Use
dbt build --select model_name+to run and test the model and its downstream dependents together in dependency order, catching both data and logic regressions. - Always develop against a dev/staging target (a separate schema or database) so fixes are validated without impacting production data.
- Re-run
dbt teston the changed model and related models to confirm existing generic and singular tests pass after the fix. - Check compiled SQL (in the
target/compileddirectory) to verify the fix produces the intended logic before executing against the warehouse. - Open a pull request only after local
dbt build/dbt testruns are green; CI jobs (e.g., via a configured CI pipeline) should also pass before merging.
The following test on fct_orders starts failing after a source system change:
models:
- name: fct_orders
columns:
- name: order_id
tests:
- unique:
config:
store_failures: true
After rerunning dbt test --select fct_orders, where should you look to find the specific order_id values that are duplicated, so you can diagnose the bug before writing a fix?
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.