Study COF-C03 Time Travel, Fail-safe, Cloning, and Retention Logic: key concepts, common traps, and exam decision cues.
Protection and recovery questions become easy once you separate recover older state, last-resort vendor recovery, and duplicate an object for your own environment. They are related, but Snowflake does not use one feature for all three jobs.
Time Travel: Snowflake feature that lets you query or restore historical object state within the configured retention window.
| Feature | Strongest first meaning |
|---|---|
| Time Travel | self-service historical access within retention |
| Fail-safe | Snowflake-managed last-resort recovery window after Time Travel |
| clone | zero-copy point-in-time duplicate for your environment |
| retention setting | boundary controlling how much historical state remains available to Time Travel |
| If the stem says… | Better reading |
|---|---|
| “the object was changed recently and needs to be restored” | Time Travel |
| “we need a test copy right now” | clone |
| “the normal self-service window has passed” | Fail-safe may be the remaining recovery concept |
These questions are mostly about not mixing adjacent features. Clone, Time Travel, and Fail-safe are related to older state, but they do not exist for the same job.
| Scenario | Better first move |
|---|---|
| object changed recently and must be restored | use Time Travel logic |
| team wants a fast duplicate for testing | use clone logic |
| ordinary self-service recovery window has passed | think Fail-safe |
| retention setting is in the stem | connect it to Time Travel reach |
| Trap | Better rule |
|---|---|
| clone equals backup or historical recovery | clone is duplicate-first, not recovery-first |
| Fail-safe is just another name for Time Travel | Fail-safe is separate and vendor-managed |
| secure sharing solves recovery | sharing exposes data; it does not restore earlier object state |