SnowPro Advanced: Security Engineer Question 177
Single answerManage the data lifecycle using object lifecycle management features:A financial services company stores highly sensitive customer data in Snowflake. Their security team has two lifecycle requirements for a schema that contains regulated tables: (1) developers must be able to recover dropped or updated data for a limited period to handle operational mistakes, and (2) after that period, the data must be permanently unrecoverable to satisfy retention policies. The team wants to minimize long-term storage costs while still meeting both requirements. Which configuration best meets these requirements?
- A
Set a 7-day TIME TRAVEL retention period on the regulated tables and rely on FAIL-SAFE for the following 7 days before permanent removal.
- B
Set a 90-day TIME TRAVEL retention period on the schema and disable FAIL-SAFE so the data is permanently removed immediately after Time Travel expires.
- C
Set DATA_RETENTION_TIME_IN_DAYS to 0 on the tables so deleted data cannot be accessed, and use FAIL-SAFE for developer recovery when mistakes occur.
- D
Create transient tables for the regulated data with a 7-day TIME TRAVEL retention period so developers can recover data and FAIL-SAFE can provide the final retention window.
Show answer and explanation
Correct answer: A
Explanation
This question tests practical application of Snowflake object lifecycle controls, specifically Time Travel, Fail-safe, and object type selection. For permanent tables, Snowflake supports a configurable Time Travel retention period, during which authorized users can query historical data, restore dropped objects, or recover from accidental DML/DDL changes. After the Time Travel period ends, the data enters Fail-safe for 7 days. Fail-safe is not customer-managed, not queryable by users, and not intended for normal operational recovery; it is a last-resort Snowflake recovery mechanism. This distinction is important for security engineers designing lifecycle controls that balance recoverability, compliance, and cost. Transient and temporary tables do not have Fail-safe, which can reduce storage costs but changes the lifecycle behavior significantly. Best practice is to choose the shortest Time Travel retention that still supports operational recovery needs, especially for sensitive data where retention windows should be tightly controlled. Relevant Snowflake documentation includes topics on Time Travel, Fail-safe, and table types such as permanent versus transient tables.
- A. Correct.
Correct. Time Travel is the Snowflake feature intended for user-accessible recovery of dropped or changed data for a defined retention period. After Time Travel expires, permanent tables enter Fail-safe for an additional 7 days, during which the data is not available for self-service querying or undrop operations. Fail-safe exists for disaster recovery by Snowflake and supports the requirement that data becomes unrecoverable by the customer after the limited operational recovery window. A shorter Time Travel period also helps reduce storage costs compared with longer retention.
- B. Incorrect.
Incorrect. Snowflake does not allow customers to disable Fail-safe for permanent tables. Also, a 90-day Time Travel retention period is not generally appropriate for minimizing long-term storage costs and exceeds the stated need for only a limited operational recovery period.
- C. Incorrect.
Incorrect. Setting DATA_RETENTION_TIME_IN_DAYS to 0 removes the Time Travel window, which means developers cannot self-service recover accidental changes or drops. In addition, Fail-safe is not intended for routine developer recovery; it is a Snowflake-managed disaster recovery mechanism for permanent objects.
- D. Incorrect.
Incorrect. Transient tables do not have Fail-safe, which makes them useful for reducing storage costs, but that directly conflicts with the requirement for an additional period after Time Travel during which data still exists before final removal. Also, transient tables are generally not the best fit when the organization explicitly wants both a defined user recovery window and the standard post-Time Travel permanent-table lifecycle.