Storage and Data Protection: free practice questions

A FAILOVER GROUP with a 30-minute replication schedule achieves an RPO of less than 1 hour (30 minutes between refreshes). When a failure occurs, executing ALTER FAILOVER GROUP ... FAILOVER promotes the secondary to primary in minutes, satisfying the RTO of less than 15 minutes. The secondary account is in a different cloud region, meeting requirement 3. Option A is incorrect on multiple counts: AT/BEFORE is not a cross-region mechanism, and Fail-safe is not accessible to customers for self-service recovery. Option C is incorrect — daily clones only meet an RPO of ~24 hours, far exceeding the 1-hour requirement; also, data sharing doesn't provide a writable copy for failover. Option D is incorrect — this describes a custom data pipeline, not a Snowflake-native DR feature, and would be complex to maintain while likely not meeting the RTO.

Snowflake database replication is asynchronous. The secondary database is refreshed periodically (on a schedule or manually), meaning it may lag behind the primary. If a failover occurs before the latest refresh completes, any transactions committed to the primary after the last successful refresh will not be present in the newly promoted primary, resulting in data loss. Option A is wrong because Snowflake replication is asynchronous, not synchronous. Option C is wrong because the failover process does not perform rollbacks; it promotes the secondary as-is. Option D is partially misleading — REPLICATION GROUP does support multi-object consistency within a refresh cycle, but it does not eliminate lag-based data loss.

Delta Sharing is an open protocol developed by Databricks and supported in Snowflake that allows data to be shared with any platform that implements the Delta Sharing client protocol, including non-Snowflake consumers like BigQuery, pandas, Apache Spark, and others — without requiring a Snowflake account. Option A is incorrect — Secure Data Sharing with a reader account still requires the consumer to use Snowflake's query engine; it doesn't serve BigQuery natively. Option C is a workaround using external storage rather than a Snowflake-native sharing feature, and it doesn't use Snowflake's access controls or governance. Option D is architecturally complex and incorrect — BigQuery Omni queries data on GCP but doesn't natively connect to a Snowflake secondary database.

Option C is correct: the AT clause with TIMESTAMP accepts a timestamp expression, and DATEADD('hour', -72, CURRENT_TIMESTAMP()) computes the point 72 hours ago. Option A uses BEFORE instead of AT — BEFORE is valid but means 'just before the given point', and more importantly its syntax uses the same sub-clause keywords (TIMESTAMP, OFFSET, STATEMENT), so it would technically work, but the real issue is that AT is the appropriate and precise choice for 'exactly at' a timestamp, and the BEFORE keyword retrieves the state just before the timestamp, not at it — making it subtly wrong for an exact-snapshot audit requirement. Option B uses OFFSET, which takes an integer number of seconds relative to now (negative = in the past); -259200 seconds is indeed 72 hours, but this option is provided with the wrong unit label 'hour', making it a distractor that conflates OFFSET (seconds) with a time expression. Option D uses STATEMENT, which requires a query ID string (UUID), not a timestamp expression, making it invalid in this context.

Option B is correct: Iceberg Tables with an external catalog (such as AWS Glue) allow multiple compute engines — Snowflake, Spark, Flink — to share and access the same Iceberg metadata catalog. This provides the open table format interoperability and ACID semantics of Iceberg while allowing concurrent multi-engine read and write access managed by the shared external catalog. Option A is wrong: External Tables in Snowflake are read-only from Snowflake's perspective; Snowflake cannot write back to the underlying S3 files via an external table, and there are no ACID guarantees for concurrent multi-engine access. Option C is wrong: when Snowflake manages the Iceberg catalog, it maintains exclusive control over the Iceberg metadata — other engines like Spark cannot write to the table through a Snowflake-managed catalog. This breaks the requirement for shared concurrent read/write access from multiple engines. Option D is wrong: directory tables and manual metadata refresh are mechanisms for managing staged files, not for ACID-compliant multi-engine table access; this option does not address the concurrent write or ACID requirements.