SnowPro Associate: Platform Question 334
Single answer4.0 Data Protection and Data SharingA retail company accidentally ran a DELETE statement that removed several days of order records from a permanent table in Snowflake. The data engineering team discovers the issue 12 hours later and must restore the table to its state immediately before the DELETE. They want the fastest recovery method with minimal operational effort and without relying on external backups. What should they do?
- A
Use Time Travel to create or replace the table from a point just before the DELETE occurred
- B
Use Fail-safe to directly query the table as it existed before the DELETE and insert the missing rows back
- C
Clone the table from a point before the DELETE using zero-copy cloning, then manually merge the rows back
- D
Restore the table by reloading the data files from the internal stage used during the original load
Show answer and explanation
Correct answer: A
Explanation
This question tests practical understanding of Snowflake data protection features. For accidental data changes to permanent tables, Time Travel is the primary self-service recovery feature as long as the data is still within the retention period. It allows querying historical data or restoring objects to an earlier state. Fail-safe is a separate feature that begins after Time Travel ends and is intended for Snowflake-managed disaster recovery scenarios, not routine user-driven recovery. In real-world operations, the best practice is to use Time Travel first for quick recovery from accidental DML or DDL changes, and only consider Fail-safe when Time Travel is no longer available. This aligns with Snowflake documentation on Time Travel and Fail-safe behavior for permanent objects.
- A. Correct.
Correct. Time Travel is designed for recovering data that was changed or deleted within the retention period. Because the issue was found 12 hours later, the team can use AT or BEFORE to access the table as it existed before the DELETE and restore it, for example with CREATE OR REPLACE TABLE ... AS SELECT ... AT(TIMESTAMP => ...). This is typically the fastest native recovery approach and does not require external backups.
- B. Incorrect.
Incorrect. Fail-safe is not intended for direct self-service querying or routine recovery by users. It is a Snowflake-managed recovery mechanism used only after the Time Travel retention period has expired, and recovery requires Snowflake support. It is also not designed for immediate operational restoration in normal workflows.
- C. Incorrect.
Incorrect. Zero-copy cloning can be used with Time Travel semantics in some recovery patterns, and it could help recover data. However, the scenario asks for the fastest recovery with minimal operational effort to restore the table to its prior state. Cloning and then manually merging rows back adds unnecessary steps compared to directly restoring the table from Time Travel.
- D. Incorrect.
Incorrect. Reloading data from a stage is not the best answer because it depends on the original files still being available, and it may not reproduce the exact table state immediately before the DELETE. It also adds more operational effort than using Snowflake's built-in Time Travel capability.