ADA-C01 Question 507
Single answerDifferentiate the use cases for primary and secondary databasesA global retailer uses Snowflake with one primary database in AWS us-east-1 to support production reporting. The company needs a disaster recovery environment in AWS us-west-2 that can be promoted quickly if the primary region becomes unavailable. During normal operations, the DR environment should be kept synchronized from the production database, but application teams in the DR region must not make independent schema or data changes there unless a failover occurs. Which Snowflake design best meets these requirements?
- A
Create a secondary database in us-west-2 from database replication, refresh it on a defined schedule, and promote it only during a failover event.
- B
Create a database clone in us-west-2 and let application teams update the clone as needed because clones stay synchronized with the source database.
- C
Use data sharing to expose the production database to us-west-2 because shared databases can be promoted to primary during regional outages.
- D
Create an independent writable database in us-west-2 and use Snowpipe to continuously copy all production changes into it so that it behaves like a secondary database.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a primary database in the production region and a replicated secondary database in the DR region. In Snowflake, primary and secondary databases are specifically designed for cross-region or cross-account replication and disaster recovery. The primary database is the source of truth and is writable. The secondary database is a replicated, read-only copy that can be refreshed and later promoted during failover. This directly addresses the requirement to keep the DR copy synchronized while preventing independent modifications before failover. By contrast, clones are point-in-time copies and are not continuously synchronized; data sharing provides read-only access but not failover promotion; and custom data movement pipelines are not substitutes for Snowflake replication and failover capabilities. This aligns with Snowflake documentation and best practices for database replication, secondary databases, and failover for business continuity.
- A. Correct.
Correct. A secondary database is the replicated copy of a primary database created through Snowflake database replication across regions or accounts. Secondary databases are read-only while acting as secondaries, which aligns with the requirement that DR teams should not make independent schema or data changes during normal operations. If the primary region is unavailable, the secondary can be promoted as part of failover/failover groups, making this the standard disaster recovery design for replicated databases.
- B. Incorrect.
Incorrect. A database clone is not the right DR mechanism here. Clones are point-in-time copies created within the same account and rely on zero-copy cloning semantics; they do not remain continuously synchronized with the source after creation. In addition, allowing teams to update the clone would diverge it from production and would not satisfy a controlled disaster recovery design.
- C. Incorrect.
Incorrect. Data sharing is intended for live, read-only access to objects without copying data, not for disaster recovery promotion. A shared database cannot be promoted to become the writable production primary for failover purposes. This option reflects a common misconception that sharing and replication are interchangeable; they are not.
- D. Incorrect.
Incorrect. Building a separate writable database and trying to feed it with copied changes introduces unnecessary operational complexity and does not create a true Snowflake secondary database. Snowpipe is for loading files, not for replicating full database state and metadata as a managed DR mechanism. This approach also risks inconsistency and misses the built-in failover semantics provided by primary/secondary databases.