ADA-C01 Question 100
Select 2Analyze how Snowflake OAuth is impacted by federated authentication, network policies, and private connectivityA company uses Snowflake with SSO through an external identity provider for interactive users. It also built an internal web application that connects to Snowflake by using Snowflake OAuth on behalf of signed-in employees. Recently, the security team attached a restrictive network policy to the Snowflake account and moved the application to a VPC that accesses Snowflake through private connectivity. After the change, employees can still sign in to the corporate IdP, but the application intermittently fails when requesting or using OAuth tokens to access Snowflake. The Snowflake administrator must determine which statements accurately describe how federated authentication, network policies, and private connectivity affect this design. Which TWO statements are correct?
- A
If the network policy blocks the source IPs used by the application, Snowflake can reject OAuth-related requests even when the user successfully authenticated with the external IdP.
- B
Once a user is federated through SSO, Snowflake OAuth bypasses Snowflake network policies because authentication is delegated to the external IdP.
- C
When private connectivity is used, the OAuth client and application endpoints must use the appropriate Snowflake private URL/hostnames; otherwise token or session establishment can fail even if credentials and integration settings are correct.
- D
Federated authentication cannot be used together with Snowflake OAuth, so the application must switch to key pair authentication for all users.
- E
Attaching a network policy to the security integration object is required for Snowflake OAuth to work with federated users over private connectivity.
Show answer and explanation
Correct answers: A, C
Explanation
The key point is that Snowflake OAuth operates within Snowflake's own access controls and connectivity requirements. Federated authentication through an external identity provider can validate the user identity, but it does not exempt the client or application from Snowflake-enforced network policies. If the application's egress IPs or private endpoint routing are not allowed, Snowflake can deny the connection even though the IdP login succeeded. In addition, when private connectivity is introduced, clients must use the correct Snowflake private endpoint/hostname for the account; continuing to use public URLs is a common cause of failures. Snowflake documentation on federated authentication, Snowflake OAuth, network policies, and private connectivity consistently treats these as complementary controls: identity can be federated, authorization can use OAuth, but the final connection to Snowflake must still come through an allowed network path and correct account endpoint.
- A. Correct.
Correct. Snowflake network policies are enforced by Snowflake on incoming connections. Even if the employee successfully signs in with the external identity provider, the subsequent request to Snowflake for OAuth token usage or session establishment still reaches Snowflake and is subject to Snowflake's network controls. A common misconception is that successful IdP authentication guarantees Snowflake access, but Snowflake still evaluates its own policies before allowing the connection.
- B. Incorrect.
Incorrect. Federated authentication does not override or bypass Snowflake network policies. The IdP authenticates the user, but Snowflake still authorizes and accepts or rejects the connection based on its own controls, including network policies. Candidates sometimes confuse delegated authentication with delegated network enforcement, but these are separate layers.
- C. Correct.
Correct. In deployments using AWS PrivateLink, Azure Private Link, or Google Cloud private connectivity patterns supported by Snowflake, clients must connect to the account's private connectivity endpoint/hostname as documented for that environment. If the application or OAuth flow is still pointed at public account URLs, connectivity or token/session-related steps may fail despite valid federation and OAuth configuration. This is especially relevant after moving applications to private-only network paths.
- D. Incorrect.
Incorrect. Snowflake OAuth can be used in environments where users are federated through an external IdP. Federation and OAuth address different parts of the identity and authorization flow and are not mutually exclusive. This distractor reflects a misunderstanding that OAuth and SAML/SSO cannot coexist in Snowflake-based application architectures.
- E. Incorrect.
Incorrect. Network policies are attached at the account, user, or other supported scope as documented by Snowflake, not as a required property of a security integration for Snowflake OAuth. The issue described is about whether the connection source is allowed and whether the correct connectivity endpoint is used, not about binding a network policy to the OAuth integration object.