DBT-AE Practice Test

DBT-AE practice test: what's covered

• Models
• Tests
• Materializations
• Jinja
• Snapshots
• Deployment

Free DBT-AE sample questions

1. An analytics engineer is wiring a staging model that reads from a downstream model rather than from raw warehouse tables. To keep the model warehouse-agnostic and let dbt build the dependency graph automatically, how should the model reference its upstream dbt model?

   • A. Use the ref() function with the upstream model's name, letting dbt resolve the schema and database at compile time
   • B. Hardcode the fully qualified database.schema.table name directly in the FROM clause
   • C. Use the source() function pointing at the upstream model name and a sources YAML entry
   • D. Reference the model through a SQL view created manually outside of dbt
   Show answer

   Correct: A. ref() is the core dbt mechanism for model-to-model dependencies: it compiles to the correct database.schema.relation for the active target and registers an edge in the DAG so dbt knows build order. Hardcoding the path breaks environment portability and the DAG. source() is only for raw external tables declared in a sources block, not for other dbt models. A manually created view lives outside dbt's lineage entirely.

2. A team loads raw event data into the warehouse with Fivetran and wants dbt to recognize those landed tables as the project's entry point, enabling lineage and freshness checks. Which dbt construct should they use to declare these external raw tables?

   • A. Define them with the source() function backed by a sources block in a YAML file
   • B. Create a seed CSV for each raw table so dbt manages them
   • C. Reference them with ref() after adding an empty placeholder model
   • D. Add them as exposures so they appear in the documentation
   Show answer

   Correct: A. Sources describe raw tables already loaded by an external tool; declaring them in a sources YAML lets models call source('name','table'), draws lineage from raw to transformed, and unlocks source freshness checks. Seeds are for small static CSVs version-controlled in the repo, not for warehouse-loaded data. ref() is only for dbt models. Exposures document downstream consumers like dashboards, not upstream raw inputs.

3. While reviewing a colleague's project, an engineer notices several models select directly from raw schemas using source() inside business-logic transformations. Following dbt's recommended layering, where should source() calls ideally be confined?

   • A. In staging models, which act as the single one-to-one interface to each raw source
   • B. In mart models, so business logic sees the freshest raw data directly
   • C. In intermediate models, where joins and aggregations happen
   • D. In any model, since the layer a source is referenced from does not matter
   Show answer

   Correct: A. dbt best practice isolates source() calls in staging models that do light renaming and casting one-to-one with each raw table; everything downstream then refs the staging model. This centralizes the raw interface so a schema change is fixed in one place. Calling source() in marts or intermediate models scatters raw dependencies and makes refactoring fragile, which is exactly the anti-pattern the staging layer prevents.

4. A new analytics engineer is learning how the dbt directed acyclic graph (DAG) is constructed and used during a run. Which statements about the DAG are accurate? (Choose TWO)

   • A. ref() and source() calls are what dbt parses to infer dependencies and build the DAG
   • B. dbt uses the DAG to determine a valid build order and to run independent models in parallel
   • C. The DAG must be defined manually in a dag.yml file before any run
   • D. A model can ref() a downstream model to create a cycle for reprocessing
   • E. Removing all ref() calls still preserves the original dependency graph
   Show answer

   Correct: A and B. dbt parses ref() and source() across the project to infer edges and assemble the DAG automatically, then topologically sorts it to pick build order and to fan out independent nodes across threads. There is no dag.yml; the graph is derived from code. Cycles are forbidden because a DAG is acyclic, and removing ref() calls erases the very edges that define the dependencies.

5. An engineer has a heavily queried reporting model whose results must be physically persisted so BI tools read precomputed rows quickly, and the team accepts a full rebuild on every dbt run. Which materialization fits this requirement?

   • A. table, which drops and recreates the relation as a physical table each run
   • B. view, which stores only the query definition and computes on read
   • C. ephemeral, which inlines the SQL into downstream models as a CTE
   • D. incremental without a unique_key, which appends rows endlessly
   Show answer

   Correct: A. The table materialization rebuilds a real physical table on every run, so BI queries hit precomputed, stored rows with the fastest read performance, which matches a heavily queried report that tolerates a full rebuild. A view stores only logic and recomputes on each read, which is cheaper to build but slower to query. Ephemeral produces no relation at all, and an incremental without a unique_key would not match the simple full-rebuild requirement here.

Last updated: 2026-10-19

DBT-AE practice test FAQ