SnowPro Advanced: Security Engineer Question 215
Select 2Manage the replication of security integrations (SAML2, OAuth, SCIM) to ensure seamless authentication and authorization post-failoverA global company uses Snowflake Business Continuity with account failover groups between a primary account in AWS us-east-1 and a secondary account in AWS us-west-2. The company uses a SAML2 security integration for SSO with its corporate IdP, an external OAuth security integration for a custom application, and a SCIM security integration for automated user and role provisioning. During a planned failover test, administrators notice that database objects are available in the secondary account, but users cannot authenticate through SSO and provisioning workflows do not resume automatically. They want to redesign the setup so authentication and authorization continue with minimal manual intervention after future failovers. Which TWO actions should they take?
- A
Include security integrations in the failover group so supported integrations are replicated to the secondary account, and validate post-failover endpoint and metadata requirements with the external identity systems.
- B
Rely on user and role object replication alone, because once identities exist in the target account, SAML2, OAuth, and SCIM integrations automatically inherit the same trust configuration.
- C
Update the IdP, OAuth client/application, and SCIM provisioning configuration to recognize the secondary account or failover URLs, because external providers must trust the post-failover Snowflake account endpoints.
- D
Create network policies in the secondary account only after failover, because precreating or replicating security-related account objects can interfere with SAML2 and SCIM replication.
- E
Use database replication instead of account object replication for security integrations, because SAML2, OAuth, and SCIM definitions are stored with application schemas rather than at the account level.
Show answer and explanation
Correct answers: A, C
Explanation
The key idea is that seamless post-failover authentication and authorization require two layers of preparation: Snowflake-side replication of supported account objects and external identity-provider/application readiness. In Snowflake Business Continuity, database replication alone does not cover account-level security integrations. Security integrations such as SAML2, external OAuth, and SCIM must be managed as account-level objects in the failover architecture. Even when replicated, administrators must still update or validate the external IdP, OAuth application/provider, and SCIM provisioning system so they trust and use the secondary account endpoints after failover. This aligns with Snowflake documentation and best practices for replication and failover groups, account object replication, and configuring SSO, OAuth, and SCIM integrations. The exam-relevant takeaway is that successful failover depends not just on object replication inside Snowflake, but also on coordinated external identity configuration.
- A. Correct.
Correct. Security integrations are account-level objects, and for business continuity they must be included through the appropriate account-level replication and failover design rather than assuming database replication is sufficient. However, replication of the Snowflake object alone is not the full solution: SAML2, OAuth, and SCIM depend on trust relationships and endpoint configuration in external identity systems. Administrators should therefore both replicate the supported account objects and verify the external provider settings required for the secondary account after failover.
- B. Incorrect.
Incorrect. This reflects a common misconception that replicated users and roles are enough for seamless continuity. Authentication integrations do not simply inherit trust because the external IdP, OAuth provider/client, and SCIM provisioning system reference specific Snowflake account URLs, ACS/issuer values, redirect URIs, tokens, or SCIM base endpoints. Without configuring those external dependencies, authentication and provisioning can still fail even if users and roles exist.
- C. Correct.
Correct. A failover-ready design must account for both Snowflake-side replication and external identity-system configuration. For SAML2, the IdP may need the correct ACS URL, entity ID, or metadata for the target account. For OAuth, the application or authorization server may need approved redirect URIs or account-specific endpoints. For SCIM, the identity platform must send provisioning calls to the correct Snowflake SCIM endpoint and trust the corresponding integration. This is a practical best practice for minimizing downtime after failover.
- D. Incorrect.
Incorrect. Network policies are a separate security control and are not the reason SAML2 or SCIM failed in this scenario. Delaying creation of related account security objects until after failover increases operational risk and manual work. The better practice is to plan and replicate or preconfigure required account-level objects where supported, then validate how they interact during failover testing.
- E. Incorrect.
Incorrect. Security integrations are not database objects and are not replicated via database replication. They are account-level objects. This option confuses database replication with account object replication, which is exactly the type of misunderstanding that leads to incomplete failover planning for authentication and provisioning.