Database XYZ has the data_retention_time_in_days parameter set to 7 days and table XYZ.public.ABC has the data_retention_time_in_days set to 10 days. A Developer accidentally dropped the database…

Question

Options

• Aundrop database xyz;
• Bcreate table abc_restore as select * from xyz.public.abc at (offset => -606024*8);
• Ccreate table abc_restore clone xyz.public.abc at (offset => -3600248);
• DCreate a Snowflake Support case to restore the database and table from Fail-safe.

• A
  11% (6)
• B
  21% (11)
• C
  4% (2)
• D
  64% (34)

Explanation

Option D is correct because the database was dropped 8 days ago, which exceeds its 7-day Time Travel retention period. Once Time Travel expires, Snowflake automatically moves the data into Fail-safe - an additional 7-day disaster recovery layer - but Fail-safe data is accessible only by Snowflake Support, not by users directly. Since day 8 falls squarely in the Fail-safe window, a support case is the only viable path.

Why the distractors fail:

• A (UNDROP DATABASE) would work within the database's 7-day Time Travel window, but that window has already closed after 8 days - the command will return an error.
• B attempts a Time Travel query on the dropped database using an 8-day offset, but since the database's retention is 7 days (not the table's 10 days), the database no longer exists in Time Travel; the table's higher retention is irrelevant once its parent database's retention expires.
• C is the same conceptual problem as B - cloning with a Time Travel offset still requires the parent database to exist within its own retention window, which it doesn't.

Memory tip: Think of it as a two-stage safety net - Time Travel (self-service, your configured retention days) feeds into Fail-safe (Snowflake-managed, always 7 days, Support-only). The key trap here is that child objects cannot outlive their parent's retention in Time Travel; the table's 10-day setting is a red herring once the 7-day database retention expires.

No community discussion yet for this question.