Configuring a snapshot to track slowly changing data

As of dbt v1.9+, snapshots can be defined in YAML files under a snapshots: key, similar to how sources and models are configured, rather than only using the legacy Jinja/SQL snapshot block syntax. YAML snapshots use select to define the query (often referencing a source or model) and require a config block for strategy, unique_key, and check/timestamp columns. This objective tests your ability to correctly structure and configure a YAML-based snapshot definition.

Must-know

• YAML snapshots are defined in .yml files under a snapshots: top-level key, with each snapshot having a name and a relation or select pointing to the source table.
• Required config fields are strategy (timestamp or check), unique_key, and either updated_at (for timestamp strategy) or check_cols (for check strategy).
• The target_schema config is deprecated in favor of letting snapshots follow the same custom schema logic as models; use schema config or generate_schema_name macro instead when applicable.
• You can still use the legacy .sql snapshot block syntax with {% snapshot %}...{% endsnapshot %}, but YAML snapshots are the current recommended approach and both cannot define the same snapshot simultaneously.
• Snapshots configured in YAML support the same config options as SQL-defined snapshots, including invalidate_hard_deletes, strategy, and unique_key, and can also be configured via dbt_project.yml under the snapshots: key for project-wide defaults.
• A common gotcha: the select (or relation) in a YAML snapshot must resolve to a single table/query representing the mutable source data being tracked—snapshots still cannot be built on ephemeral models.

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.