Keeping models modular and avoiding repeated logic
Modularity in dbt means breaking transformation logic into small, reusable, single-purpose models rather than writing one large monolithic SQL file. DRY (Don't Repeat Yourself) principles are achieved by centralizing shared logic in staging models, macros, and packages so that changes only need to be made in one place.
Must-know
- Staging models should do minimal transformation (renaming, casting, light cleanup) and one staging model per source table, so downstream models can reference clean, standardized building blocks instead of re-cleaning raw data repeatedly.
- Use the ref() function to build on other models rather than duplicating SQL logic across multiple models; this also ensures proper dependency resolution and lineage in the DAG.
- Repeated SQL snippets (e.g., business logic like calculating a discount or a common CASE WHEN) should be extracted into Jinja macros so the logic is defined once and reused across many models.
- Intermediate models are used to encapsulate complex or reusable transformation logic between staging and mart layers, preventing the same joins or aggregations from being rewritten in multiple downstream marts.
- Variables (vars) and
dbt_utils/date-spine style packages help avoid hardcoding values or reinventing common utility logic, supporting DRY across an entire project. - Over-modularizing (excessive layering of trivial models) can hurt performance and readability, so modularity should be balanced with the actual reuse and clarity benefits it provides.
You notice the following CASE expression duplicated across five mart models:
case
when status in ('shipped','delivered') then 'fulfilled'
when status in ('cancelled','returned') then 'unfulfilled'
else 'pending'
end as order_statusWhich approach best follows dbt's DRY principle to eliminate this duplication?
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 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.