ARA-C01 Question 231
Single answerBackup/recoveryA financial services company uses Snowflake Business Critical Edition in AWS us-east-1 for its production environment. During an incident review, architects are asked to design a recovery approach for accidental destructive changes, such as a table being dropped or overwritten, while also ensuring the company can recover if the entire Snowflake account becomes unavailable. The solution must minimize recovery time for business users and avoid building custom export-based backup pipelines. Which approach should the architect recommend?
- A
Rely on Time Travel and Fail-safe for both object-level recovery and account-level disaster recovery, because Snowflake automatically protects all data without additional configuration.
- B
Create regular database exports to external cloud storage and restore from those files when needed, because this is the only supported way to recover from account-level failures.
- C
Use Time Travel to recover from accidental data changes or dropped objects, and use account replication with failover groups across regions/accounts to provide disaster recovery for account unavailability.
- D
Increase the Time Travel retention period to the maximum and use database cloning in the same account as the disaster recovery strategy for a full account outage.
Show answer and explanation
Correct answer: C
Explanation
The best answer is to combine Snowflake native capabilities based on the failure scenario. For accidental user or application errors, Time Travel provides self-service recovery of data to a prior state and supports undrop/restore patterns within the configured retention period. For account-level disaster recovery, architects should use replication and failover groups so that data and supported account objects are replicated to a secondary location, typically another region and/or account, allowing controlled failover with lower recovery time objectives than manual rebuilds. Fail-safe is not a substitute for a DR plan because it is not intended for customer-operated rapid restores. Likewise, same-account cloning does not help if the account itself is unavailable. This aligns with Snowflake best practices for business continuity and disaster recovery using replication, failover groups, Time Travel, and Fail-safe for their intended purposes.
- A. Incorrect.
Incorrect. Time Travel is designed for recovering historical data states, such as querying, cloning, or restoring data before accidental updates, deletes, or drops. Fail-safe is a Snowflake-managed, last-resort recovery window intended primarily for Snowflake support use and does not provide customer-controlled, rapid operational recovery. Neither Time Travel nor Fail-safe alone is a complete strategy for account-level disaster recovery if the entire account is unavailable.
- B. Incorrect.
Incorrect. Exporting data to external storage can be used as a custom backup pattern, but it adds operational overhead and does not meet the requirement to avoid custom export-based pipelines. It is also not the only supported recovery approach. Snowflake provides native replication and failover capabilities for disaster recovery scenarios, which are generally more aligned with low-RTO enterprise recovery requirements.
- C. Correct.
Correct. Time Travel is the appropriate native feature for recovering from accidental destructive changes such as dropped or overwritten tables within the retention period. For broader disaster recovery, Snowflake supports replication and failover groups to replicate supported account objects and data to another region or account, enabling recovery when the primary account is unavailable. This combination addresses both operational recovery and large-scale disaster recovery while avoiding custom backup pipelines.
- D. Incorrect.
Incorrect. Increasing Time Travel can help with a longer window for object-level recovery, but it does not protect against an account-level outage by itself. Database clones created in the same account depend on that same account remaining available, so they do not satisfy disaster recovery requirements for total account unavailability. This option confuses point-in-time recovery and cloning with cross-account or cross-region disaster recovery.