Sample questions
Pe Dbt Models Materializations TestsDifficulty 1
In dbt, when a model uses {{ ref('orders') }} instead of a hardcoded table name, what determines the model's position in the DAG?
- aA manual
depends_on block written by the developer - bThe order the model files appear in the project
- cdbt automatically building edges from ref() calls✓
- dA separate dependency graph file the developer maintains
Explanation:dbt parses every ref()/source() call in a model and builds the DAG from those calls — there is no manual dependency declaration step.
Pe Dbt Models Materializations TestsDifficulty 2
What is the key difference between dbt compile and dbt run for a given model?
- a
dbt compile executes the SQL against the warehouse; dbt run only renders Jinja - b
dbt compile renders SQL only; dbt run also executes it✓ - c
dbt compile and dbt run both execute SQL, but against different schemas - d
dbt compile only works on tests; dbt run only works on models
Explanation:dbt compile renders Jinja/macros into plain SQL without sending anything to the database. dbt run performs that same rendering and then actually executes the resulting SQL.
Pe Dbt Models Materializations TestsDifficulty 1
What does dbt's view materialization create in the warehouse?
- aA database view that re-runs the model's SELECT on every query✓
- bA physical table populated once and never refreshed
- cA cached result set stored in dbt's own metadata
- dA temporary file on the dbt runner's local disk
Explanation:A view materialization wraps the model's SELECT in CREATE VIEW, so no data is stored — every downstream query re-executes the SELECT.
Pe Dbt Models Materializations TestsDifficulty 2
What happens to a dbt model configured as materialized='table' on each dbt run?
- aOnly the rows changed since the last run are appended
- bdbt skips it if the table already exists
- cIt is converted into a view automatically after the first build
- dThe full result is recomputed and rebuilt✓
Explanation:A table materialization always runs the full SELECT again and rebuilds the table completely — there is no partial refresh.
Pe Dbt Models Materializations TestsDifficulty 2
What is the core idea behind dbt's incremental materialization?
- aIt replaces the table with a view after the second run
- bAfter the first run, it processes only new or changed rows✓
- cIt stores every historical version of every row automatically
- dIt runs the model's SQL twice for validation
Explanation:Incremental models are designed so that, after an initial full build, subsequent runs only transform and load the new or changed rows, avoiding a full recompute.
Pe Dbt Models Materializations TestsDifficulty 3
What is distinctive about dbt's ephemeral materialization compared to view/table/incremental?
- aIt is the only materialization that supports
unique_key - bIt writes data directly to a separate archive schema
- cIt has no database object — inlined as a CTE✓
- dIt requires a warehouse that supports MERGE statements
Explanation:An ephemeral model has no table or view in the warehouse at all; dbt inlines its compiled SQL as a CTE wherever it is referenced.