What if your data models could police themselves and keep your team safe from costly mistakes?
Why Model contracts and access controls in dbt? - Purpose & Use Cases
Imagine you have a team where everyone builds parts of a data model, but no one clearly states what each part should look like or who can change it. You try to check the data manually every time before using it, and you have to ask around to know who can update what.
This manual checking wastes time and causes mistakes. Without clear rules, data can break silently, or wrong people might change important parts. It's like building a house without a blueprint or locks on the doors--things get messy and unsafe quickly.
Model contracts and access controls set clear agreements on what data models should contain and who can change them. This means everyone knows the rules upfront, and the system automatically checks if the data fits the contract. It also locks down who can edit, keeping the data safe and reliable.
SELECT * FROM sales_data;
-- Manually check columns and values every timemodel_contract:
columns:
- name: sales_amount
type: number
access_control:
roles:
- analyst
- data_engineerIt enables teams to trust their data models and collaborate safely without constant manual checks or accidental changes.
A retail company uses model contracts to ensure sales data always has the right columns and formats, while access controls let only senior analysts update sensitive financial models.
Manual data checks are slow and risky.
Model contracts define clear data expectations.
Access controls protect who can change data models.
Practice
model contract in dbt?Solution
Step 1: Understand what a model contract does
A model contract sets rules that data must follow to be considered valid in dbt models.Step 2: Compare options to the definition
Only To define rules that ensure data quality in models describes defining rules for data quality, which matches the purpose of model contracts.Final Answer:
To define rules that ensure data quality in models -> Option BQuick Check:
Model contract = data quality rules [OK]
- Confusing access control with model contracts
- Thinking contracts schedule runs
- Mixing contracts with visualization tools
schema.yml file?Solution
Step 1: Identify the syntax for model contracts in schema.yml
Model contracts are defined under thecontractkey with column tests insideschema.yml.Step 2: Match options to this syntax
models: - name: my_model contract: columns: - name: id tests: - not_null correctly showscontractwith columns and tests. Others show unrelated keys likeaccess_control,schedule, ordashboard.Final Answer:
models: - name: my_model contract: columns: - name: id tests: - not_null -> Option CQuick Check:
Contract syntax = models: - name: my_model contract: columns: - name: id tests: - not_null [OK]
- Confusing access control syntax with contract syntax
- Using schedule or dashboard keys incorrectly
- Missing indentation in YAML
schema.yml:
models:
- name: sales
contract:
columns:
- name: order_id
tests:
- not_null
- unique
- name: amount
tests:
- not_null
What happens if the order_id column contains duplicate values when the model runs?Solution
Step 1: Understand contract tests behavior
Contract tests likeuniqueenforce data rules strictly. If violated, the model run fails.Step 2: Apply to duplicate
Sinceorder_idvaluesorder_idmust be unique, duplicates cause the test to fail, stopping the model run.Final Answer:
The model run fails because the contract test for uniqueness fails -> Option DQuick Check:
Contract test fail = model run fails [OK]
- Thinking model logs warning but continues
- Assuming duplicates are ignored
- Believing model run is skipped automatically
dbt_project.yml:
access_control:
- role: analyst
models:
- sales
- customers
- role: viewer
models:
- sales
But analysts report they cannot see the customers model. What is the likely error?Solution
Step 1: Check where access controls are defined in dbt
dbt does not support anaccess_controlblock indbt_project.yml. Access controls are managed outside or via external tools.Step 2: Analyze other options
Role spelling or model existence might cause issues, but the main problem is unsupported syntax in the config file.Final Answer:
Theaccess_controlblock is not supported indbt_project.yml-> Option AQuick Check:
Access control block unsupported = Theaccess_controlblock is not supported indbt_project.yml[OK]
- Trying to set access control inside dbt_project.yml
- Assuming role names cause access issues
- Not verifying model existence
finance model, and that the model must always have a non-null transaction_id. How can you combine model contracts and access controls to achieve this?Solution
Step 1: Use model contracts for data quality
Define a contract test inschema.ymlto ensuretransaction_idis not null, enforcing data quality.Step 2: Manage access control outside dbt
dbt does not handle user permissions directly; access control is managed by your data platform or warehouse permissions for the 'data_engineer' role.Final Answer:
Define a model contract inschema.ymlfortransaction_idnot null, and manage access control via your data platform's permissions for 'data_engineer' role -> Option AQuick Check:
Contracts for data rules + external access control = Define a model contract inschema.ymlfortransaction_idnot null, and manage access control via your data platform's permissions for 'data_engineer' role [OK]
- Trying to set access control inside dbt schema.yml
- Using macros to check user roles inside SQL
- Assuming dbt manages user permissions directly
Ready to prove it?
Pass the test and this pattern moves unknown
