dbt Fundamentals Practice Questions (2026): 10 dbt Certification Questions with Answers

{{ ref('stg_orders') }} tells dbt one model depends on another, so dbt builds them in the right order (the DAG) and substitutes the correct schema/database for your dev, CI, or prod target. Hardcoding (A) breaks the dependency graph and pins one environment. source() (B) is only for raw tables declared in a sources: block, not for dbt models. import() (D) is not a dbt function.

source() takes the source name and the table name and resolves to the real relation, while wiring the raw table into lineage and enabling dbt source freshness. ref() (B) is only for dbt-managed models and seeds, not raw sources. seed() (C) is not a function — seeds are referenced with ref(). Hardcoding (D) works but loses lineage and freshness tracking.

An incremental model builds the full table once, then on later runs inserts/merges only rows that pass the filter in an {% if is_incremental() %} block (e.g. where event_timestamp > (select max(event_timestamp) from {{ this }})). A view (A) stores no data and re-computes on every query. A full table (B) is what you are trying to avoid. ephemeral (D) does not persist anything — it is inlined as a CTE.

Ephemeral models are not built as objects; dbt interpolates their SQL as a common table expression (CTE) into any downstream model that ref()s them. That keeps the warehouse tidy for small, reusable logic. A table (A) and view (B) both create a persistent database object, and incremental (C) also persists a table. Note: because ephemeral models are not materialised, you cannot query or test them directly.

Generic tests like unique and not_null compile to a SQL query that selects the rows that violate the rule. Zero returned rows means the test passes; one or more means it fails. dbt does not add database constraints (A) or mutate your data (C) — tests are read-only assertions. And they check values, not mere existence (D).

The relationships test is dbt’s built-in foreign-key check: it flags any customer_id in fct_orders that has no match in dim_customers. accepted_values (A) checks a column against a fixed hardcoded list, not another table. unique (B) catches duplicates, and not_null (D) catches nulls — neither verifies the value exists in a parent table.

A macro is a reusable Jinja function — {% macro cents_to_dollars(col) %} {{ col }} / 100 {% endmacro %} — that you call from any model, keeping the logic DRY and in one place. Seeds (A) load static CSV data. Snapshots (C) track slowly changing records over time. Sources (D) declare raw input tables. None of them templates reusable SQL logic.

dbt build runs seeds, models, snapshots, and their tests as one interleaved DAG, and it will not build a model’s children if that model’s tests fail. dbt run (A) executes models only (no tests or seeds). dbt test (B) runs tests only. dbt compile (C) just renders the SQL without touching the warehouse.

A snapshot implements slowly changing dimension (SCD) Type 2: on each run dbt compares the source to the stored snapshot and, when a tracked column changes, closes the old row and inserts a new one with dbt_valid_from/dbt_valid_to timestamps — giving you full history. An incremental model (A) appends new rows but does not version changes to existing keys. A seed (B) is static CSV. A view (D) always shows only the current mutated value, with no history.

Slim CI compares the PR against a production manifest.json: state:modified selects changed nodes, the trailing + adds their downstream dependencies, and --defer lets unchanged parents resolve to the existing prod tables instead of rebuilding them. --full-refresh (A) rebuilds everything — the opposite of slim. tag:nightly (C) is a static selector unrelated to what changed. +fct_orders (D) selects one model’s upstream lineage, not what the PR modified.