Dry-running a model to check its logic and schema before a real build
The --empty flag lets you dry-run dbt build or dbt run by replacing all ref() and source() calls with a limit-0 query, so models execute against your warehouse and validate SQL syntax, dependency logic, and schema definitions without processing any actual row data. This makes it a fast, low-cost way to confirm that models compile and run correctly before wasting time or warehouse credits on full builds.
Must-know
- Running dbt run --empty or dbt build --empty replaces referenced tables/views with an empty (limit 0) subquery, so the query plan is validated but no real data is scanned.
- This is the fastest way to catch SQL syntax errors, broken refs/sources, and column-level schema mismatches before running a full, expensive build.
- Because zero rows are returned, --empty is not suitable for validating actual data quality, business logic correctness on real values, or data-dependent tests.
- Materializations that depend on data volume or actual row content (like incremental logic branching or certain snapshot behaviors) may not fully validate with --empty since underlying tables might be empty or the run may take specific empty-input code paths.
- The flag works with dbt run and dbt build, and combining it with dbt test is not meaningful since tests generally require real data to assert against.
- Using --empty is a recommended CI/CD or pre-merge practice to quickly verify model compilation and schema before running full or slice-based production-scale builds.
When you run dbt run --empty on a model, what happens to the ref() and source() calls inside that model's SQL?
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.