DEA-C02 Storage and Data Protection Practice Question
A data engineer needs to restore a specific version of a permanent table named FINANCE_LEDGER as it existed 40 hours ago, but the table is currently 2 TB and has DATA_RETENTION_TIME_IN_DAYS set to 1. The engineer wants to recover the historical data without affecting the current table. Which approach correctly recovers the data?
⚠ Common exam trap
The trap here is believing that raising DATA_RETENTION_TIME_IN_DAYS retroactively extends access to versions that already aged out of the previous window.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The data cannot be recovered because the 40-hour-old version is beyond the 1-day Time Travel window and Fail-safe is not directly queryable.
Time Travel access is bounded by the table's current retention setting, and changing that setting only applies going forward. A 40-hour-old version exceeds the 1-day window, and Fail-safe cannot be queried by users. Therefore the historical version is not retrievable through normal means, which is why the engineer's goal cannot be met in this configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The data cannot be recovered because the 40-hour-old version is beyond the 1-day Time Travel window and Fail-safe is not directly queryable.
Why this is correct
With DATA_RETENTION_TIME_IN_DAYS set to 1, only the most recent 24 hours are queryable through Time Travel. A 40-hour-old version is outside that window, and Fail-safe cannot be queried by users at all. Because retention cannot be extended retroactively, the historical version is effectively unrecoverable without Snowflake Support intervention in a genuine disaster case.
- ✗
Use Fail-safe to restore the table to the 40-hour-old state, then query it.
Why it's wrong here
Fail-safe is a non-queryable, Snowflake-managed recovery mechanism used only after the Time Travel window has elapsed, and it requires Snowflake Support to perform the recovery. It is intended for disaster scenarios, not routine point-in-time queries of a specific version. Using it here would be inappropriate and would not give the engineer direct access to the 40-hour-old data.
- ✗
Query the table using AT (OFFSET => -144000) and insert the results into a new table.
Why it's wrong here
With only 1 day of retention, the accessible window is 24 hours, so a 40-hour-old offset falls outside Time Travel and the query fails with an error about the data being past the retention period. The offset itself is expressed in seconds, and 144000 seconds is indeed 40 hours, but the retention setting makes that point unreachable.
- ✗
Increase DATA_RETENTION_TIME_IN_DAYS to 90, then query 40 hours ago using Time Travel.
Why it's wrong here
Raising retention only affects how long future changes are retained; it does not retroactively extend the window for data already aged out. The 40-hour-old version was already outside the prior 1-day window and cannot be resurrected by a later setting change. This is a common misconception about how retention changes apply over time.
About these practice questions
One of 229 original DEA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Snowflake exam blueprint
This DEA-C02 practice question is part of Courseiva's free Snowflake certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DEA-C02 exam.