SnowPro Advanced: Security Engineer Question 225
Single answerPerform controlled tests of the failover process to validate security object promotion and functionalityA global company uses Snowflake database replication and failover groups to protect a production account in AWS us-east-1 with a secondary account in AWS us-west-2. The security team wants to run a controlled failover test to verify that replicated security objects are promoted correctly and still function after failover, without disrupting production users. They have replicated the relevant databases and account objects to the secondary account. Which action is the BEST way to validate security object promotion and functionality during the test?
- A
Promote the secondary failover group in the secondary account, then use a dedicated test user and role to verify that replicated users, roles, grants, and network policies behave as expected in the promoted account.
- B
Refresh the replication schedule for the secondary account and review SHOW GRANTS output in the source account to confirm the security objects will behave the same way after failover.
- C
Clone the production database in the primary account and run access tests there, because cloned objects preserve grants and this is equivalent to failover validation for security objects.
- D
Run ALTER ACCOUNT SET parameters in the secondary account before promotion so that account-level security objects are recreated locally, then compare the recreated objects to the primary account.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to perform an actual controlled promotion of the secondary failover group and then execute functional security tests in the promoted environment using test identities. For Snowflake disaster recovery validation, simply checking replication status or object definitions is not enough. Security engineers should confirm that replicated security objects are usable after failover, including role-based access, grants, and supported replicated account objects and policies. Snowflake documentation on replication and failover groups emphasizes promotion of secondary objects during failover and testing recovery procedures as part of operational readiness. A sound practice is to use non-production test identities and carefully scoped validation steps so that the organization proves failover capability without disrupting production workloads.
- A. Correct.
Correct. A controlled failover test should validate behavior in the promoted secondary environment, not just metadata visibility in the primary. Promoting the secondary failover group makes the replicated objects writable and active in the target account. Using a dedicated test user and role to perform realistic authentication and authorization checks verifies that security objects such as users, roles, grants, and supported account-level policies were promoted and function correctly after failover. This approach aligns with Snowflake best practices for validating disaster recovery readiness while minimizing production impact.
- B. Incorrect.
Incorrect. Reviewing replication status or SHOW GRANTS in the source account only confirms current metadata in the primary environment. It does not validate that the secondary can be promoted successfully or that the replicated security objects actually function in the target account after failover. A common misconception is that replicated metadata visibility is equivalent to operational failover readiness, but the exam expects validation in the promoted secondary.
- C. Incorrect.
Incorrect. Database cloning in the primary account is useful for testing data and some grant behavior, but it is not equivalent to testing cross-region or cross-account failover. Cloning does not validate promotion of replicated account objects or the runtime behavior of security controls in the secondary account. This distractor targets the misconception that cloning can substitute for disaster recovery testing.
- D. Incorrect.
Incorrect. Recreating account-level security objects locally in the secondary before promotion undermines the purpose of validating replication and promotion. The goal is to confirm that the replicated security configuration is promoted and works as designed, not to manually rebuild it. In addition, changing account parameters locally before promotion can produce test results that do not reflect the real failover state.