SnowPro Advanced: Security Engineer Question 221
Single answerAudit pre-failover readiness:A financial services company uses account replication and failover groups to support disaster recovery for a Snowflake production account. As the Security Engineer, you must validate audit pre-failover readiness before a planned regional failover. Compliance requires that, immediately after failover, investigators can still review historical sign-in activity, query activity, and access changes that occurred before the failover. Which action should you take BEFORE the failover to best satisfy this requirement?
- A
Verify that the failover group includes the database containing materialized copies of ACCOUNT_USAGE and/or ORGANIZATION_USAGE audit data, such as regularly refreshed audit tables built from those views
- B
Rely on the SNOWFLAKE database because ACCOUNT_USAGE views are automatically replicated with every failover group and will expose the source account's full audit history after failover
- C
Grant imported privileges on the SNOWFLAKE database to additional roles in the secondary account, because imported privileges ensure historical audit records are copied during failover
- D
Create a database role on the primary account with access to INFORMATION_SCHEMA views, because INFORMATION_SCHEMA is replicated and retains long-term audit history needed after failover
Show answer and explanation
Correct answer: A
Explanation
The best answer is to persist required audit evidence into customer-managed tables that are part of the replicated/failover design before failover occurs. In Snowflake, security and operational teams often use SNOWFLAKE.ACCOUNT_USAGE and, where applicable, ORGANIZATION_USAGE to source audit telemetry such as login history, query history, grants, and access events. However, for disaster recovery planning, you should not assume these system-provided views will give you complete historical pre-failover visibility from the former primary account after promotion. The reliable pattern is to extract and retain required audit data in a regular database/schema under your control, then include that database in replication/failover scope. This aligns with Snowflake best practices around business continuity and compliance readiness: identify critical metadata needed after failover, materialize it if necessary, and verify it is covered by replication. Relevant documentation areas include Snowflake failover groups/account replication guidance and SNOWFLAKE.ACCOUNT_USAGE / ORGANIZATION_USAGE usage notes.
- A. Correct.
Correct. For audit pre-failover readiness, the key issue is that built-in telemetry surfaces such as ACCOUNT_USAGE are tied to the account/service metadata layer and should not be assumed to provide replicated historical audit data from the original primary after failover. A practical best practice is to persist required audit data into customer-managed tables in a replicated database, for example by regularly loading data from SNOWFLAKE.ACCOUNT_USAGE or ORGANIZATION_USAGE into dedicated audit tables. If that database is included in the failover group, the historical records are available in the promoted account after failover.
- B. Incorrect.
Incorrect. This is a common misconception. The SNOWFLAKE database and its shared usage views are not simply 'carried over' as replicated historical source-account audit records through failover groups. After failover, usage views reflect the new account context and are not a substitute for preserving source historical audit evidence. Relying on this alone can leave investigators without pre-failover history in the recovery environment.
- C. Incorrect.
Incorrect. Imported privileges control access to shared objects such as the SNOWFLAKE database, but they do not copy or replicate historical audit records. This option confuses authorization with data durability. Even if users can query ACCOUNT_USAGE in the promoted account, that does not guarantee the required pre-failover historical telemetry from the original primary is present there.
- D. Incorrect.
Incorrect. INFORMATION_SCHEMA is useful for current object metadata and limited operational introspection, but it is not designed to retain the long-term audit history needed for compliance investigations. Creating a database role does not solve audit preservation, and INFORMATION_SCHEMA is not the right mechanism for preserving historical sign-in, query, and access-change records across failover.