SnowPro Specialty: Gen AI Question 223
Single answerCortex LLM REST APIA company has a customer-facing web application hosted outside Snowflake. The app must generate short product summaries by calling a Snowflake-hosted large language model through the Cortex LLM REST API. The security team wants to avoid embedding long-lived Snowflake usernames and passwords in the application, and the architecture team wants the request flow to use the supported REST authentication pattern for programmatic access. Which approach should the development team implement?
- A
Use key pair authentication to obtain a Snowflake session token, then call the Cortex LLM REST API with that token in the Authorization header.
- B
Use external OAuth so the application obtains a Snowflake access token from the configured identity provider, then call the Cortex LLM REST API with the bearer token.
- C
Create a network rule that allows the application server IP, then call the Cortex LLM REST API without authentication because network rules provide API authorization.
- D
Store a Snowflake user password in the application secrets manager and pass the username and password directly in each Cortex LLM REST API request body.
Show answer and explanation
Correct answer: B
Explanation
The key requirement in this scenario is choosing the supported and secure authentication model for an external application calling the Cortex LLM REST API. Snowflake's recommended pattern for this API is OAuth-based authentication, where the client obtains an access token and includes it as a bearer token in the Authorization header. This is more secure than embedding long-lived credentials and is the appropriate approach for application-to-API access. Network restrictions can complement security but do not authenticate callers. Similarly, using username/password credentials directly is a poor practice and not the preferred model for this API. Candidates should distinguish between general Snowflake authentication methods and the specific authentication expectations for the Cortex LLM REST API as documented in Snowflake Cortex REST API guidance and Snowflake OAuth documentation.
- A. Incorrect.
Incorrect. Key pair authentication is a supported Snowflake authentication method for some programmatic interfaces, but the Cortex LLM REST API is designed to be called using OAuth bearer tokens rather than by first establishing a traditional Snowflake session and reusing a session token in this way. This option reflects a common misconception that all Snowflake APIs share the same authentication flow.
- B. Correct.
Correct. For external applications calling the Cortex LLM REST API, the supported pattern is to authenticate using OAuth and send the resulting bearer token in the Authorization header. This avoids hard-coded passwords and aligns with secure, programmatic REST access from applications running outside Snowflake.
- C. Incorrect.
Incorrect. Network rules and network policies can restrict where connections originate, but they do not replace identity-based authentication and authorization. Even if IP restrictions are configured, the caller still must authenticate properly to the Cortex LLM REST API.
- D. Incorrect.
Incorrect. Passing usernames and passwords from the application is not the recommended security pattern for the Cortex LLM REST API. It increases credential-management risk and does not reflect the supported best-practice authentication model for this REST endpoint.