SnowPro Advanced: Security Engineer Question 214
Select 3Manage the replication of security integrations (SAML2, OAuth, SCIM) to ensure seamless authentication and authorization post-failoverA global company uses Snowflake Business Critical edition with account failover groups between a primary account in AWS us-east-1 and a secondary account in AWS us-west-2. The company relies on a SAML2 security integration for SSO, an external OAuth security integration for API access, and a SCIM security integration for user and role provisioning from its identity provider. During a disaster recovery test, administrators promote the secondary account and notice that users can connect to the new account URL, but authentication and provisioning behavior is inconsistent. They want to minimize post-failover changes while ensuring SSO, OAuth-based access, and SCIM provisioning continue to work correctly. Which actions should the security engineer take?
- A
Configure the identity provider and connected applications to trust and target the secondary account’s Snowflake URLs and ACS/endpoints in advance, because replicated integrations do not eliminate the need to update or preconfigure the external IdP/application side for the failover account.
- B
Include the SAML2, OAuth, and SCIM security integrations in the failover group so the integration objects and their metadata replicate to the secondary account before failover.
- C
Rely on account object replication alone; after failover Snowflake automatically rewrites the identity provider configuration, OAuth redirect targets, and SCIM base URLs to the new account with no external changes required.
- D
After failover, recreate all users, roles, and security integrations manually in the promoted account because replicated security integrations cannot be used after promotion.
- E
Validate each replicated integration after failover, including account URL references, issuer/audience or ACS values for SAML2, client/application endpoint configuration for OAuth, and SCIM provisioning endpoint settings, then update the identity provider or client applications if they were not preconfigured for both accounts.
Show answer and explanation
Correct answers: A, B, E
Explanation
The key concept is that Snowflake can replicate supported account objects, including relevant security integrations, through replication and failover groups, but replication only covers the Snowflake-side configuration. For SAML2, external OAuth, and SCIM, end-to-end functionality also depends on external identity provider or application configuration that may reference account-specific URLs in the primary account. Therefore, a robust DR design includes: (1) replicating the security integration objects to the secondary account, (2) preconfiguring or planning external IdP/application trust for the secondary account, and (3) validating the full authentication/provisioning flow after failover. This aligns with Snowflake guidance on replication/failover for account objects and operational best practices for federated authentication and provisioning. Candidates should recognize that failover readiness for security integrations is partly a Snowflake configuration problem and partly an external identity/application integration problem.
- A. Correct.
Correct. Replicating a security integration in Snowflake does not automatically update external systems such as the SAML identity provider, OAuth client/application registrations, or SCIM provisioning connectors. In practice, seamless failover requires the external side to already recognize the secondary account URL and related endpoints, or to be updated quickly during failover. This is a common operational gap in DR planning.
- B. Correct.
Correct. Security integrations such as SAML2, external OAuth, and SCIM can be included in replication/failover design so that the Snowflake-side objects exist in the secondary account before promotion. Without replicating these account objects, the DR account may not have the required integration definitions available when it becomes primary.
- C. Incorrect.
Incorrect. Snowflake does not control or automatically rewrite configuration inside the customer’s identity provider, OAuth authorization server registrations, or SCIM provisioning applications. Even if the integration object is replicated, any external configuration that references account-specific URLs must still be planned for and validated.
- D. Incorrect.
Incorrect. This overstates the limitations. Security integrations can be replicated as account objects and made available in the target account through proper replication/failover setup. Manually recreating everything after failover is not the recommended approach and increases recovery time and configuration drift risk.
- E. Correct.
Correct. Post-failover validation is a best practice because even with replicated integration objects, authentication flows often depend on account-specific URLs and trust relationships. SAML2 commonly depends on ACS, entity ID, issuer, and audience values; OAuth flows can depend on account-specific endpoints or client registrations; SCIM connectors typically use a base URL tied to the Snowflake account. Verifying and updating these external references is essential to restore seamless authentication and authorization.