Choosing between generic, singular, custom, and unit tests
dbt supports generic tests (unique, not_null, accepted_values, relationships) applied via YAML properties, singular tests written as standalone SQL files, and custom generic tests built as reusable macros—together covering models, sources, seeds, and snapshots. Unit tests, added in dbt Core 1.8+, let you validate transformation logic against static mock inputs/outputs independent of warehouse data, complementing the data-quality focus of the other test types.
Must-know
- Generic tests (unique,
not_null,accepted_values, relationships) are defined once as parametrized macros and applied to any column/model/source via YAML under a tests: ordata_tests: key. - Singular tests are one-off SQL SELECT statements stored as .sql files in the tests/ directory that return failing rows; no macro or reuse mechanism is needed.
- Custom generic tests are authored as macros named test_<name> (typically in the tests/generic or macros/ folder) accepting model and
column_nameplus optional arguments, then invoked like built-in generic tests in YAML—commonly sourced from packages like dbt-utils or dbt-expectations. - Any test can be tuned with config options such as severity: warn/error,
error_if/warn_ifthresholds,store_failures, and limit, and can target models, sources, seeds, or snapshots. - Unit tests (dbt Core 1.8+) are defined under a
unit_tests: key on a model, using given (mocked input rows/refs) and expect (expected output rows) blocks to validate SQL logic without querying the live warehouse. - dbt test runs generic and singular data tests by default; unit tests are typically invoked via dbt test --select
test_type:unit (or included in dbt build) and are meant to run fast in CI before deploying model logic.
You add a new file, tests/assert_positive_revenue.sql, containing a SELECT statement that returns any row where revenue is negative. You run dbt build without adding any entry to a schema.yml file. What must be true for dbt to run this file as a singular test?
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 5, 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.