Skip to content

Shaping a model's dependency graph so it stays readable

A clean dbt DAG is built by chaining models with the ref() function so dbt can infer dependencies, determine run order, and parallelize execution safely. Well-designed lineage flows from sources through staging, intermediate, and mart layers in one direction, avoiding circular or crossed dependencies. Building logical flow is as much about naming, folder structure, and layering conventions as it is about the ref() and source() functions themselves.

Must-know

  • Always use ref() (and source() for raw tables) instead of hardcoded table names so dbt can build an accurate dependency graph and DAG visualization.
  • Follow a layered architecture (staging → intermediate → marts) so each model has a single, clear purpose and downstream models never skip layers unnecessarily.
  • Staging models should reference only source() calls, never other staging or downstream models, to keep the base of the DAG clean and consistent.
  • Avoid circular references; dbt will throw a compilation error if models depend on each other directly or indirectly in a loop.
  • Use intermediate models to encapsulate complex joins or transformations, keeping mart models simpler and easier to trace visually in the DAG.
  • A DAG that fans out too widely from one model or has excessive layers can indicate poor modularity; aim for logical, digestible dependency chains rather than monolithic models.
Check this objectiveFree · always available

Which statement about organizing a dbt project into staging, intermediate, and marts layers is correct?

Your objective map0 tried · 0 right · 31 untouched

What you have tried across dbt Analytics Engineering's objectives, not a readiness score.

Coverage checked against the published exam guide on Aug 4, 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.