Cloning objects between environments with dbt clone

The dbt clone command creates lightweight clones of upstream models into your current target schema, using database-native cloning (e.g., zero-copy clone) where supported, or view-based fallback otherwise. It is primarily used to speed up CI/CD workflows and development by avoiding full rebuilds of unchanged models, cloning them from a stateful state (like the prod manifest) instead. This is closely tied to dbt's state-based selection (--state) and deferral features.

Must-know

• dbt clone requires a --state flag pointing to a manifest.json from a previous run, typically production, to know what to clone.
• It works hand-in-hand with state:modified selection, allowing unchanged models to be cloned instead of rebuilt, saving compute and time in CI jobs.
• On platforms that support zero-copy cloning (e.g., Snowflake, Databricks), clones are fast, storage-efficient, and use native CREATE ... CLONE or CREATE TABLE ... LIKE mechanics; other adapters fall back to creating views pointing to the original relation.
• Cloned relations are created in the current target schema/database as defined by your target, not in the original schema, enabling isolated environments like CI schemas.
• dbt clone is distinct from --defer: deferral only resolves refs to unbuilt upstream nodes at compile time without creating anything, whereas clone actually materializes a cloned relation in your target.
• Common gotcha: cloning does not re-run tests or freshness checks on the cloned model, so you must still validate that the source state is trustworthy (e.g., a recent successful prod run).

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.