SnowPro Advanced: Security Engineer Question 165
Single answerUnderstand the differences and use cases for Time Travel and Fail-safeA security engineering team at a financial services company discovers that a privileged user accidentally dropped a critical permanent table containing audit evidence 2 days ago. The database is configured with a 3-day Time Travel retention period. The team wants the fastest self-service recovery method and also needs to explain what recovery path remains available if the issue is not discovered until 6 days after the drop. Which statement best describes the correct recovery approach and the role of Time Travel versus Fail-safe?
- A
The table can be restored by the customer using Time Travel within 3 days; after that period expires, Fail-safe may still allow Snowflake Support to recover the data for disaster recovery purposes, but it is not intended for user-managed self-service restores.
- B
The table can be restored by the customer using Fail-safe during the first 3 days, and after that Snowflake automatically moves it into Time Travel for an additional 7 days of self-service recovery.
- C
Because the table was dropped, both Time Travel and Fail-safe are unavailable; the only supported option is to reload the data from external backups maintained by the customer.
- D
The team should clone the dropped table from Fail-safe immediately because Fail-safe is optimized for fast operational recovery, while Time Travel is intended only for historical query access.
Show answer and explanation
Correct answer: A
Explanation
Time Travel and Fail-safe serve different purposes in Snowflake. Time Travel is the primary, customer-accessible feature for querying, cloning, and restoring historical data and dropped objects within the configured retention period. For permanent objects, once Time Travel retention expires, Snowflake provides a 7-day Fail-safe period. Fail-safe is not intended for routine operational restores or direct self-service access; instead, it is a Snowflake-managed last-resort recovery mechanism primarily for disaster recovery scenarios. In this scenario, discovery at 2 days means the team should use Time Travel immediately. If discovery occurs 6 days after the drop, the object would be beyond the 3-day Time Travel window but still potentially in Fail-safe, meaning recovery would no longer be self-service and may require engagement with Snowflake Support. This distinction is important for security and governance teams because Time Travel supports rapid incident response and evidentiary restoration, while Fail-safe should not be relied on as an operational backup strategy. Refer to Snowflake documentation on Time Travel and Fail-safe, including object retention behavior for permanent objects and the limitations of Fail-safe recovery.
- A. Correct.
Correct. For a permanent table, the customer can use Time Travel during the configured retention window to restore or query historical data, including undropping dropped objects when still within retention. With a 3-day Time Travel period, discovering the drop 2 days later means self-service recovery is still possible. After Time Travel expires, the data enters Fail-safe for 7 days for permanent objects, but Fail-safe is a Snowflake-managed recovery mechanism intended primarily for disaster recovery and exceptional situations, not routine self-service restores.
- B. Incorrect.
Incorrect. This reverses the roles of Time Travel and Fail-safe. Time Travel is the customer-accessible feature used first for self-service recovery and historical access. Fail-safe comes only after Time Travel ends for permanent objects and is not a self-service capability. Snowflake does not move data back into Time Travel after Fail-safe begins.
- C. Incorrect.
Incorrect. Dropped permanent tables remain recoverable during the Time Travel period, so the statement incorrectly assumes that dropping the table eliminates both native recovery paths. A common misconception is that DROP is immediately irreversible, but Snowflake specifically supports recovery of dropped objects within Time Travel retention.
- D. Incorrect.
Incorrect. Fail-safe cannot be used by customers for immediate cloning or normal operational recovery. Cloning and UNDROP-type recovery rely on metadata and Time Travel functionality. Fail-safe is not designed as a fast, user-operated restore feature and should not be treated as an alternative to Time Travel for day-to-day recovery scenarios.