SnowPro Advanced: Security Engineer Question 224
Select 2Perform controlled tests of the failover process to validate security object promotion and functionalityA global company uses Snowflake Business Critical Edition with organization-level replication and failover groups. The security team replicates account-level objects from a primary account in AWS us-east-1 to a secondary account in AWS us-west-2. The failover group includes users, roles, network policies, password policies, and grants. Before an annual disaster recovery audit, the team must perform a controlled failover test to confirm that security objects are promoted correctly and still function after promotion, while minimizing business risk. Which steps should the team take during the test? (Choose two.)
- A
Refresh the failover group on the secondary account, promote the secondary failover group, then validate that replicated roles, users, and policy objects exist and that a test user can authenticate and access only the expected objects.
- B
Convert the secondary account into a read/write account by cloning replicated security objects individually, then test access using the cloned objects to avoid changing failover group state.
- C
Perform the test in a planned window using non-production test users or a limited-scope validation approach, and after testing, fail back according to the documented runbook to restore the original topology.
- D
Validate failover readiness by querying ACCOUNT_USAGE views in the primary account only; if the objects appear there and replication status is current, functional testing after promotion is unnecessary.
- E
Suspend replication before the test so that promoted security objects are isolated from the primary, then resume replication after the test without requiring any failback procedure.
Show answer and explanation
Correct answers: A, C
Explanation
The best answers are 1 and 3. In Snowflake, failover groups are the supported mechanism for replicating and failing over supported account objects, including many security-related objects such as users, roles, and certain policies. A proper controlled test should verify both promotion and operational functionality. Practically, that means synchronizing the secondary with a refresh, promoting it, and then validating real security outcomes such as user authentication, role-based access, and policy behavior. Just checking metadata or replication status is insufficient for a security audit because those checks do not prove that the promoted objects actually work as intended.
From an operational perspective, Snowflake disaster recovery testing should be done in a planned window with a documented runbook and a clear failback procedure. Using test identities or a limited-scope validation approach reduces risk while still demonstrating control effectiveness. Relevant Snowflake documentation includes guidance on replication and failover groups, promotion of secondary failover groups, and the supported object types for account object replication. Best practice is to test not only whether objects are present after promotion, but also whether least-privilege access and authentication controls behave correctly in the promoted environment.
- A. Correct.
Correct. In Snowflake, a controlled failover test for replicated security objects requires more than checking metadata existence. The secondary failover group should first be refreshed so it has the latest replicated state, then promoted. After promotion, the team should validate both object promotion and functionality: confirm the expected users, roles, network policies, password policies, and grants are present, and verify actual behavior with a constrained test sign-in and authorization checks. This aligns with best practice for disaster recovery testing: validate that replicated objects are usable after promotion, not just replicated.
- B. Incorrect.
Incorrect. Security objects included in a failover group are managed through replication and failover group promotion, not by individually cloning replicated account objects to simulate failover. Cloning is not the mechanism used to convert a secondary failover target into the active copy for replicated account-level security objects. This option reflects a common misconception that clone-based testing is equivalent to failover testing, but it does not validate promotion behavior or failover group semantics.
- C. Correct.
Correct. Controlled failover tests should be executed during a planned maintenance or validation window with minimized blast radius, such as using test users or limited-scope checks. After the test, the team should follow the documented failback/runbook process to return service topology to normal. This is operationally sound and consistent with disaster recovery best practices: validate promotion and functionality while preserving business continuity and maintaining clear rollback steps.
- D. Incorrect.
Incorrect. ACCOUNT_USAGE and replication status can help confirm that objects were replicated, but they do not prove that promoted objects function correctly in the secondary account after failover. For security-focused failover validation, the team must test authentication and authorization behavior after promotion. Relying on metadata checks alone misses issues such as effective login restrictions, policy enforcement, or unexpected grant behavior.
- E. Incorrect.
Incorrect. Suspending replication is not the recommended prerequisite for a controlled failover test of a failover group. The goal is typically to ensure the secondary is up to date, which requires refresh/synchronization before promotion. In addition, once promotion occurs, returning to the original topology is not as simple as resuming replication without a failback plan. This option underestimates the importance of documented failover/failback procedures and current replication state.