ADA-C01 Question 116
Single answerSecure and Integrate the Snowflake SQL APIA company is building an internal web application that submits ad hoc SQL statements to Snowflake by using the Snowflake SQL API. The security team requires that: (1) no username/password credentials are stored in the application, (2) access tokens must be short-lived, and (3) compromised tokens should have limited blast radius. The application must authenticate directly to Snowflake without a human user present. Which approach best meets these requirements?
- A
Configure the application to use OAuth 2.0 client credentials flow against a Snowflake security integration, and have the app request short-lived access tokens for a service principal
- B
Store a Snowflake user password in a cloud secrets manager and have the application call the SQL API with basic authentication over HTTPS
- C
Use key pair authentication directly with the SQL API by sending the private key in each API request so Snowflake can validate the caller without issuing tokens
- D
Use an external browser SSO flow to obtain a session token once, cache it in the application, and reuse it for all future SQL API requests until it expires
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use OAuth 2.0 client credentials flow with a Snowflake security integration. This is the recommended pattern for non-interactive applications that need to call the Snowflake SQL API securely. It avoids storing Snowflake usernames and passwords, supports short-lived access tokens, and limits exposure compared with long-lived static credentials. In Snowflake, SQL API requests are typically authorized with bearer tokens, and OAuth is a strong fit for enterprise integration and security requirements. External browser SSO is intended for interactive users, not backend services. Likewise, transmitting private keys in API requests is not how Snowflake SQL API authentication works and would be insecure. Relevant Snowflake documentation areas include the SQL API authentication requirements, OAuth with security integrations, and service-to-service authentication best practices.
- A. Correct.
Correct. For server-to-server access to the Snowflake SQL API, OAuth with the client credentials flow is the best fit when no interactive user is involved. A Snowflake security integration can be configured for OAuth, allowing the application to obtain short-lived bearer tokens instead of storing user passwords. This aligns with least privilege and reduces the impact of credential compromise because tokens are time-bound and scoped to the client or service identity.
- B. Incorrect.
Incorrect. Although a secrets manager is better than hardcoding credentials, this still relies on a long-lived username/password credential, which violates the requirement to avoid storing username/password credentials in the application architecture. It also creates a larger blast radius than short-lived OAuth access tokens. The SQL API is typically used with token-based authentication rather than basic authentication using a stored Snowflake password for this kind of service-to-service design.
- C. Incorrect.
Incorrect. Key pair authentication is supported for some Snowflake clients and programmatic access patterns, but the SQL API expects token-based authorization in practice rather than sending a private key with each request. Sending a private key in requests would also be a serious security anti-pattern. If key pair authentication is used in a broader architecture, it would not be implemented by transmitting the private key to Snowflake on every SQL API call.
- D. Incorrect.
Incorrect. External browser SSO is designed for interactive user authentication, not headless service-to-service integrations. Caching a session token from a one-time browser login is operationally fragile and does not meet the requirement for direct non-human authentication. It also creates governance and lifecycle issues because the token is tied to a user session rather than a service principal pattern.