SnowPro Advanced: Security Engineer Question 220
Single answerAudit pre-failover readiness:A global company is preparing to fail over a Snowflake account group to a secondary region during a disaster recovery exercise. The Security Engineer has been asked to audit pre-failover readiness specifically for security and compliance operations. The company relies on object access history, login activity, query activity, and policy change evidence for post-incident investigations. Which action should the engineer take BEFORE failover to best ensure these audit capabilities remain available after the failover?
- A
Verify that the SNOWFLAKE database and all account usage views will automatically replicate and include historical telemetry in the secondary account after failover.
- B
Create or validate a process that continuously exports required audit data from ACCOUNT_USAGE/organization-level views to replicated customer-managed tables in a failover group before failover occurs.
- C
Grant imported privileges on the SNOWFLAKE database to security roles in the secondary account, because this is sufficient to make historical audit records available after failover.
- D
Enable Tri-Secret Secure so that audit history stored in Snowflake system views is included in cross-region replication during failover.
Show answer and explanation
Correct answer: B
Explanation
For audit pre-failover readiness, the key principle is to separate what Snowflake manages as system telemetry from what your organization must preserve for continuity of investigations and compliance. Snowflake replication and failover groups protect supported customer-managed objects, but teams should not rely on Snowflake-provided system history alone being available in the exact way needed after failover. Therefore, before failover, the Security Engineer should validate an export/persistence pipeline that copies required audit data from sources such as ACCOUNT_USAGE and related organizational telemetry into customer-managed tables included in replication. This supports continuity for security investigations, policy evidence, and compliance reporting. Snowflake documentation on replication/failover, ACCOUNT_USAGE, and access history best practices supports evaluating object support boundaries and persisting critical audit evidence when continuity is required across regions.
- A. Incorrect.
Incorrect. A common misconception is that all system-provided telemetry, especially the SNOWFLAKE database and ACCOUNT_USAGE history, is protected by normal database replication or failover group behavior. In practice, teams should not assume historical audit telemetry in Snowflake-provided system views will be available in the secondary after failover in the same way as customer-managed replicated objects. Pre-failover readiness requires validating what must be preserved separately.
- B. Correct.
Correct. The practical and recommended approach is to identify the audit records required for investigations and compliance, then persist them into customer-managed tables that can be replicated in the failover group. This allows key evidence such as login history, access/query history, and governance-related metadata to remain available after failover. This is the most reliable pre-failover audit-readiness control because it converts critical system telemetry into replicated business-owned data.
- C. Incorrect.
Incorrect. Imported privileges can help a role access objects in the shared SNOWFLAKE database where supported, but privileges alone do not guarantee that the needed historical audit data is replicated to or retained in the failed-over environment. This option confuses access control with data availability.
- D. Incorrect.
Incorrect. Tri-Secret Secure is related to key management and encryption control, not to replication of Snowflake system audit history. It does not cause ACCOUNT_USAGE or other Snowflake-managed telemetry to become part of failover replication. This distractor targets a misunderstanding between encryption features and disaster recovery/audit readiness.