ARA-C01 Question 244
Single answerData corruption impactsA retail company loads daily sales data from an external stage into a Snowflake table named FACT_SALES. On Monday at 09:00, a defective upstream transformation writes incorrect discount values into millions of rows. At 13:00, analysts report incorrect revenue dashboards. The architecture team must restore trusted data quickly while minimizing impact on downstream pipelines and preserving the ability to investigate what changed. Which action should the architect recommend?
- A
Use Time Travel to create a clone of FACT_SALES from a point before 09:00, validate the data, and swap or replace the affected table with the restored version.
- B
Use Fail-safe to immediately query and recover FACT_SALES as it existed before 09:00, because Fail-safe is intended for rapid self-service correction of user data corruption.
- C
Suspend all virtual warehouses and rerun the dashboard queries, because incorrect query results caused by warehouse cache can appear as corrupted table data.
- D
Drop FACT_SALES and reload only the current files from the external stage, because Snowflake automatically preserves prior versions of staged files for table-level recovery.
Show answer and explanation
Correct answer: A
Explanation
The best recommendation is to use Time Travel to recover the table to a known-good point before the bad load or transformation occurred. In Snowflake, Time Travel supports querying, cloning, and restoring historical table states within the configured retention period, making it the correct first-line response to logical data corruption caused by user or pipeline actions. A common architectural best practice is to create a point-in-time clone of the affected object, validate row counts and business checks, and then swap or otherwise promote the restored object to production. This minimizes downtime and preserves the corrupted state for root-cause analysis. Fail-safe is not designed for fast, self-service remediation and should not be treated as a substitute for Time Travel. Also, caches do not alter stored table contents, and external stage files are not a replacement for Snowflake table history. Relevant Snowflake documentation includes Time Travel, zero-copy cloning, and Fail-safe behavior.
- A. Correct.
Correct. Time Travel is the primary Snowflake capability for recovering from accidental data changes such as bad updates, deletes, or loads within the retention window. Creating a clone or restoring data from a point before the corruption allows the team to validate the recovered state, preserve the corrupted table for forensic analysis if needed, and minimize downstream disruption. Using a clone before swapping or replacing is a practical architecture pattern because zero-copy cloning is fast and space-efficient.
- B. Incorrect.
Incorrect. Fail-safe is not a self-service operational recovery mechanism for rapid correction of data corruption. It is a Snowflake-managed recovery option intended mainly for disaster recovery after the Time Travel period has expired, and customer access is not direct or immediate. It is also slower and less suitable for same-day remediation.
- C. Incorrect.
Incorrect. Warehouse cache does not change persisted table data. While result caching or query logic issues can sometimes cause confusion, the scenario states that defective upstream processing wrote incorrect values into millions of rows. Suspending warehouses would not repair corrupted persisted data in FACT_SALES.
- D. Incorrect.
Incorrect. Reloading only current files from the external stage is risky and often incomplete. External stages do not provide table-version recovery semantics, and the currently available files may already contain bad data or may not represent the exact pre-corruption table state. Dropping the table also increases risk and can complicate dependency management and investigation.