Enforcing data integrity with YAML-defined constraints
dbt allows you to define data constraints (not null, primary key, foreign key, check, custom) directly in a model's YAML properties, which dbt then compiles into DDL statements enforced by the underlying data platform. This ensures data integrity guarantees are pushed down to the warehouse itself, not just validated in dbt tests, but support and enforcement behavior vary significantly by adapter.
Must-know
- Constraints are defined under the 'constraints' key at the model level (table-level constraints like
primary_key,foreign_key, check) or under a column's 'constraints' key (column-level constraints likenot_null,primary_key,foreign_key). - Constraints require the model to have a defined 'contract' (enforced: true) in its config, since dbt needs guaranteed column names, data types, and order to generate valid DDL.
- Platform enforcement differs: warehouses like Snowflake and Redshift may accept but not actively enforce
foreign_keyor check constraints (informational only), while Postgres and Databricks (via Delta) more strictly enforcenot_nulland check constraints. - For platforms that don't support ALTER-based constraint application post-load, dbt generates constraints inline as part of the CREATE TABLE statement, meaning the model build will fail at compile/run time if data violates a
not_nullor check constraint. - Primary key and foreign key constraints often require the 'type:
primary_key'/'type:foreign_key' syntax with a 'to' and 'field' reference for foreign keys, pointing to a ref() or source() relation. - Combining constraints with contracts turns schema and integrity violations into build-time errors rather than downstream surprises, but this also means any upstream schema drift will break the run until the YAML is updated to match.
A model declares a primary_key constraint on order_id with contract.enforced: true. On a Postgres target, dbt build fails immediately when duplicate order_id values exist. On a BigQuery target with the same YAML and the same duplicate data, the build succeeds without error. Why does the behavior differ between the two platforms?
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.