SnowPro Advanced: Security Engineer Question 38
Single answerImplement Single-Sign-On (SSO):A company is rolling out SSO for Snowflake using a corporate identity provider (IdP) that supports SAML 2.0. Security requires that users authenticate through the browser-based SSO flow, and the Snowflake security engineer must reduce the risk of account lockout if the IdP metadata changes unexpectedly. Which configuration should the engineer implement to meet both requirements?
- A
Set SAML2_SNOWFLAKE_ISSUER_URL in the security integration and rely on users to continue signing in with username and password if SSO fails.
- B
Create a SAML2 security integration with ENABLED = TRUE, set SAML2_PROVIDER to the IdP, configure SAML2_SSO_URL and the IdP X.509 certificate, and set ALLOWED_USER_DOMAINS so users can fall back to local authentication.
- C
Create a SAML2 security integration with ENABLED = TRUE, configure the IdP SSO URL and X.509 certificate, and set SAML2_ENABLE_SP_INITIATED = TRUE while also maintaining a break-glass administrator account with a non-SSO sign-in path.
- D
Configure OAuth instead of SAML because Snowflake uses OAuth for browser-based federated login, and store a backup refresh token for the ACCOUNTADMIN user.
Show answer and explanation
Correct answer: C
Explanation
For Snowflake user SSO, the relevant feature is federated authentication using a SAML 2.0 security integration. In practice, the engineer must configure the SAML integration with IdP-specific settings such as the IdP SSO endpoint and signing certificate. If the requirement is browser-based SSO, SP-initiated login is commonly enabled so users start at Snowflake and are redirected to the IdP for authentication. Separately, Snowflake security best practice is to maintain at least one emergency or break-glass administrator account that is not dependent on the external IdP. This protects against lockout if the IdP is unavailable, the SAML certificate expires, or metadata changes unexpectedly. This aligns with Snowflake documentation on federated authentication and operational best practices for administrative access resiliency.
- A. Incorrect.
Incorrect. Snowflake SSO for browser-based federated authentication uses a SAML 2.0 security integration with IdP details such as the SSO URL and X.509 certificate. Merely setting an issuer URL does not satisfy the core configuration requirements. More importantly, relying on ordinary users to fall back to username/password does not meet the stated security requirement that users authenticate through browser-based SSO, and it does not provide a controlled administrative recovery approach.
- B. Incorrect.
Incorrect. A SAML2 security integration does require enabling the integration and configuring the IdP SSO URL and signing certificate. However, ALLOWED_USER_DOMAINS is not the control used to provide a general fallback from SSO to local authentication in this scenario. This option also conflicts with the requirement that users authenticate through browser-based SSO rather than routinely bypassing it with native credentials.
- C. Correct.
Correct. Snowflake browser-based SSO is implemented through a SAML 2.0 security integration. Configuring the IdP SSO URL and X.509 certificate is part of the required setup, and enabling SP-initiated login supports the browser-based flow where Snowflake redirects users to the IdP. To reduce the risk of administrative lockout if IdP metadata or certificates change unexpectedly, Snowflake best practice is to keep a break-glass administrator account that can still access the account independently of federated SSO.
- D. Incorrect.
Incorrect. OAuth is used by Snowflake for delegated authorization scenarios and some programmatic integrations, but browser-based SSO for Snowflake users is implemented with SAML 2.0 federation, not by replacing SAML with OAuth. Keeping a refresh token as a backup for ACCOUNTADMIN is also not an appropriate administrative recovery strategy for Snowflake account access.