Setting project-wide configuration in dbt_project.yml
The dbt_project.yml file lets you define default configurations for models, seeds, snapshots, and other resources at the project, directory, or subdirectory level, avoiding the need to repeat config() blocks in every model. Configurations set here apply hierarchically based on file path, and can be overridden by more specific configs in individual model files or in yml property files.
Must-know
- Configurations in
dbt_project.ymlare nested under resource type keys (e.g., models:, seeds:, snapshots:) followed by the project name and then folder paths matching your file structure. - The precedence order from lowest to highest is:
dbt_project.ymldefaults, then config() in the model/seed/snapshot file itself, then config defined in a schema.yml or properties file, with the most specific/local config always winning. - Common configs set here include materialized, schema, tags, enabled,
persist_docs, and grants, which can be applied broadly to a folder or narrowed to subfolders. - Setting materialized: view or table at the top project level creates a default that individual folders (e.g., staging vs. marts) can override with more specific materializations like incremental or ephemeral.
- A common gotcha is indentation errors or mismatched folder paths in the yml hierarchy, which silently cause configs not to apply as expected since dbt won't always error loudly.
- The +config-key: value syntax (with a leading plus sign) is required for resource configs in
dbt_project.ymlto distinguish them from folder path keys, especially in dbt version 0.17+.
Your dbt_project.yml contains:
models:
my_project:
staging:
+materialized: view
The model file models/staging/stg_orders.sql begins with:
{{ config(materialized='table') }}
select ...
When you run dbt run, how is stg_orders materialized?
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 4, 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.