Locking a model's shape down with a contract
dbt model contracts let you enforce the shape of a model's output—its column names, data types, and (optionally) constraints—before the model is allowed to build. Contracts act as a guardrail so downstream consumers can trust that a model's interface won't silently change, and dbt will fail the build if the actual result doesn't match the declared contract.
Must-know
- You enable a contract by setting 'contract: {enforced: true}' in the model's config (in the .yml file or config block), which requires you to explicitly declare 'columns' with 'name' and '
data_type' for every column the model returns. - When a contract is enforced, dbt builds the model using an explicit create-table/view statement with the declared column names and types (rather than 'select *'), so a mismatch between the query's actual output and the contract causes the run to fail before the object is created or swapped.
- Constraints (e.g., '
not_null', 'primary_key', 'foreign_key', 'check') can be added on top of the contract but support varies by adapter/warehouse—some are enforced at build time, others are informational only, and unsupported constraints will raise errors or be ignored depending on the platform. - Contracts are most commonly applied to models intended as stable interfaces—typically models materialized as table or incremental, and especially those exposed to other teams, tools, or marked as part of a public/versioned model contract via 'access' and '
latest_version' governance features. - If you change a contracted model's columns, types, or constraints, you must bump the model's version (using dbt's model versioning) or update the contract deliberately; unannounced breaking changes will simply fail CI/builds rather than pass silently.
- A common gotcha is forgetting to specify '
data_type' precisely enough (e.g., varchar length, numeric precision/scale) to match warehouse-specific type requirements, which causes contract enforcement failures even when the logical type is correct.
You enforce a contract on stg_orders with these columns declared:
columns:
- name: order_id
data_type: int
- name: amount
data_type: numeric(18,2)Running dbt build produces this error:
Compilation Error
This model has an enforced contract that failed.
Please ensure the name, data_type, and number of columns in your model match the contract.
...
amount | numeric(38,2) | numeric(18,2) | data type mismatchWhy did this happen?
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.