Turning an assumption about a model or source into a test
dbt tests validate assumptions about your data by running SQL queries that return failing rows. dbt ships with four built-in generic tests (unique, not_null, accepted_values, relationships) that can be applied to models, sources, seeds, and snapshots via YAML properties files. Tests are essential for catching data quality issues before they propagate downstream.
Must-know
- Generic (schema) tests are defined in YAML under a 'tests' key on columns or models/sources, while singular tests are standalone .sql files in the tests/ directory that must return zero rows to pass.
- The 'unique' and '
not_null' tests check a single column; 'accepted_values' checks that column values fall within a specified list; 'relationships' checks referential integrity against a column in another model or source. - Tests can be configured with severity: warn or error (default error), and
error_if/warn_ifthresholds can be set to control when a test fails vs. warns based on row count. - Running 'dbt test' executes all tests; you can scope execution using selectors like '--select
model_name' or 'source:*' to test only sources. - Tests defined on sources allow you to validate assumptions about raw data freshness and structure before it enters your transformation pipeline, catching upstream issues early.
- Custom generic tests can be created as macros (prefixed test__) in the macros/ or tests/generic/ directory and reused across multiple models with parameters, similar to built-in tests.
A source freshness block is defined as follows:
sources:
- name: jaffle_shop
loaded_at_field: _loaded_at
freshness:
warn_after: {count: 12, period: hour}
error_after: {count: 24, period: hour}
tables:
- name: raw_orders
The most recent row in raw_orders has a _loaded_at value 30 hours old. What is the result of running dbt source freshness?
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.