Changing how a dbt run behaves with command flags
dbt behavior flags let you control how dbt parses, compiles, and executes projects without changing SQL logic, which is critical when debugging errors that appear only after a dbt version upgrade. Flags are set in the flags section of dbt_project.yml (or via CLI/env vars) and often govern legacy vs. new behavior for things like node coloring, quoting, or materialization logic. Understanding flags helps you distinguish 'real' modeling bugs from version-driven behavior changes.
Must-know
- Behavior flags are typically defined under a flags: key in
dbt_project.ymland can also be overridden via CLI flags or environment variables for a single run. - When dbt Labs changes default behavior in a new release, they often ship it behind a flag defaulting to the legacy value first, then flip the default in a later minor/major version—so silent breakage after an upgrade is a common exam scenario.
- Running dbt --help or checking release notes/CHANGELOG is the standard way to discover which flags exist and their current default in your installed version.
- Some flags affect parsing/compilation (e.g., strict validation of properties or configs), so an error that only appears after upgrading dbt Core is a strong clue to check for a related behavior flag rather than assuming the SQL/model is broken.
- Setting a flag incorrectly (wrong scope, wrong project file, or typoed key) will usually cause dbt to silently ignore it and fall back to the default, which is a common debugging trap.
- Flags are project-wide by default but some can be scoped per-resource or overridden at the command line for testing before committing to a project-wide change.
You edit a custom Jinja macro that changes how a column alias is generated, then run dbt run. The compiled SQL in target/compiled still shows the old alias, and the model builds with the previous (wrong) column name even though the macro file was clearly saved. Which flag should you add to your next invocation to force dbt to reparse the project from scratch instead of reusing its cached manifest?
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.