Tracing a bug back through dbt's compiled SQL
When a dbt model fails, the error often comes from the compiled SQL, not the Jinja source, since Jinja/macros/ref() calls resolve before the SQL reaches the warehouse. Checking the compiled code in the target/compiled directory (or the 'Compiled code' tab in dbt Cloud) shows exactly what the warehouse executed, making it the fastest way to isolate syntax or logic errors. Running the compiled SQL directly in your warehouse's query editor lets you iterate quickly without waiting for dbt to re-run the full Jinja compilation each time.
Must-know
- Compiled SQL lives in target/compiled/<
project_name>/models/... and mirrors the exact file/folder path of the source model. - target/run/ contains the actual SQL that was executed against the warehouse (post-compilation, including any adapter-specific wrapping), which can differ slightly from target/compiled for incremental or materialization logic.
- Use
dbt compile(ordbt run --select model_name) to regenerate compiled files before inspecting them, since stale target/ artifacts can mislead debugging. - Copy-pasting compiled SQL into your warehouse's native SQL editor lets you test fixes, check row counts, and inspect intermediate CTEs faster than repeatedly invoking dbt.
- Errors referencing ref() or source() failures usually indicate a graph/compilation-time problem, while errors on the raw SQL syntax usually indicate a compiled-code problem, so identifying which stage failed narrows debugging quickly.
- The target/ directory is gitignored and regenerated per invocation, so always re-run
dbt compileafter changing a model or its Jinja logic before trusting the compiled output.
A dbt run on models/marts/fct_orders.sql fails with:
Database Error in model fct_orders
column reference "customer_id" is ambiguous
The model joins stg_orders to stg_customers in Jinja using {{ ref(...) }} calls, and no column is explicitly aliased. What should you inspect first to pinpoint the source of the ambiguity?
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.