SnowPro Advanced: Security Engineer Question 80
Single answerLeverage API authentication integrationsA security engineer is integrating a custom internal application with Snowflake by using the SQL API. The application runs in a controlled server environment and must authenticate without storing Snowflake user passwords in code or configuration. The company also wants centralized credential management and the ability to rotate credentials with minimal application changes. Which authentication approach best meets these requirements?
- A
Configure the application to use key pair authentication with a Snowflake user, and have the application generate a JWT for SQL API authentication
- B
Store a Snowflake username and password in the application configuration file and use basic authentication for each SQL API request
- C
Use SAML-based SSO directly from the server application to authenticate every SQL API request without user interaction
- D
Create a programmatic access token in Snowsight and embed it in the application for long-term API access
Show answer and explanation
Correct answer: A
Explanation
For non-interactive, service-to-service API access to Snowflake, key pair authentication is a strong fit and is commonly used with the Snowflake SQL API. In this model, the Snowflake user is configured with an RSA public key, and the application uses the corresponding private key to sign a JWT presented to Snowflake. This approach removes the need to store user passwords, aligns well with enterprise secret-management practices, and supports key rotation by updating registered public keys and the managed private key material. SAML/federated login is intended for human users, while storing passwords in application files is discouraged from a security engineering perspective. Snowflake documentation on key pair authentication and SQL API authentication patterns supports this best-practice approach.
- A. Correct.
Correct. For Snowflake API integrations such as the SQL API, key pair authentication is a recommended approach for service-to-service access. The client holds the private key securely, generates a JWT, and Snowflake validates it against the public key associated with the Snowflake user. This avoids embedding passwords, supports centralized key management through standard secret-management systems, and enables key rotation with limited application impact.
- B. Incorrect.
Incorrect. While username/password authentication may work in some client scenarios, storing Snowflake passwords in application configuration is a weaker security practice and does not align with the requirement to avoid stored passwords in code or configuration. It also complicates secure rotation and increases the risk of credential exposure.
- C. Incorrect.
Incorrect. SAML SSO is primarily designed for interactive user authentication through an identity provider, not for unattended server-to-server API authentication on every SQL API call. Using SAML in this way does not fit the non-interactive application scenario and would introduce operational complexity.
- D. Incorrect.
Incorrect. Snowflake does not provide a general long-term 'programmatic access token' generated in Snowsight for this purpose. This option reflects a common misconception based on patterns from other platforms. For API authentication integrations, Snowflake supports mechanisms such as key pair authentication and OAuth, depending on the use case.