Versioning a model and retiring the version it replaces
dbt supports model versioning to manage breaking changes to public models without disrupting downstream consumers. By defining multiple versions of a model in YAML and marking older ones as deprecated, teams can migrate consumers on their own timeline while signaling when old versions will be removed.
Must-know
- Model versions are configured under the 'versions' key in the model's YAML properties, each with a unique 'v' identifier and optional '
defined_in' to point to a different file name. - The '
latest_version' property controls which version is resolved when downstream code refs the model without specifying a version, allowing you to promote a new version without breaking unversioned refs. - Consumers pin to a specific version using the two-argument ref syntax, e.g. ref('
model_name', v=1), ensuring their pipelines are unaffected by changes to the latest version. - Deprecating a version is done by setting a '
deprecation_date' on that version in the YAML; dbt will emit warnings (and can be configured to error) when that date has passed and the version is still referenced. - Only models configured with access: public (or otherwise exposed via groups/contracts) are typical candidates for versioning, since versioning is meant to manage a stable, shared interface across teams.
- Versioned models are commonly paired with model contracts to enforce a stable schema per version, so breaking schema changes trigger a new version rather than silently altering an existing one.
You add deprecation_date: 2026-09-01 to the v: 1 entry of stg_orders in its YAML versions config. What is the actual effect of this setting once that date passes?
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.