SnowPro Specialty: Gen AI Question 38
Single answerREST APIA team is building a Retrieval-Augmented Generation (RAG) workflow in Snowflake and needs to call an external embedding service that exposes a REST API. Security requires that API credentials are not hard-coded in SQL or application code, and the platform team wants the integration to be managed natively in Snowflake so analysts can invoke it from SQL-based workflows. Which approach best meets these requirements?
- A
Create an external access integration and store the API secret in a Snowflake secret, then invoke the REST API from a Python UDF or stored procedure that uses the secret.
- B
Store the API key in a regular Snowflake table and pass it into a SQL UDF that makes outbound HTTP calls directly.
- C
Use a stage to store the API key in a text file and have analysts read it at runtime before calling the REST endpoint from SQL.
- D
Create a Snowflake task that embeds the API token in the task definition and sends HTTP requests directly from standard SQL statements.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake-native external network access with secrets management. For REST API calls from Snowflake code, the secure pattern is to define an external access integration that permits outbound connectivity to approved endpoints and to store authentication material in a Snowflake secret. A Python UDF or stored procedure can then retrieve the secret securely and invoke the API. This approach supports governance, avoids hard-coded credentials, and fits real-world GenAI workflows such as calling embedding or reranking services as part of RAG pipelines. By contrast, storing keys in tables or stages is not a best practice for secrets, and standard SQL alone does not directly provide general-purpose outbound REST invocation. Refer to Snowflake documentation on external network access, secrets, and handler-based integrations for secure access to external services.
- A. Correct.
Correct. In Snowflake, outbound calls to external services are handled through external network access features, typically by configuring an external access integration and securely storing credentials in a Snowflake secret. A handler such as a Python UDF or stored procedure can then access the secret and call the external REST API. This aligns with Snowflake security best practices because secrets are centrally managed and not exposed in SQL text or application code.
- B. Incorrect.
Incorrect. Regular Snowflake tables are not an appropriate secret-management mechanism for API credentials. In addition, SQL UDFs do not directly make arbitrary outbound HTTP calls in the way this option suggests. This distractor reflects the common misconception that any SQL object can be used both for secure secret storage and external API invocation.
- C. Incorrect.
Incorrect. A stage is designed for file storage and data loading/unloading, not secure operational secret management for runtime REST authentication. Exposing a key in a file that analysts can read increases the risk of credential leakage. It also does not provide the controlled native integration pattern Snowflake recommends for external API access.
- D. Incorrect.
Incorrect. Standard SQL statements in Snowflake do not directly issue arbitrary REST requests just because they are run inside a task. A task only schedules execution of supported SQL or procedure logic. Embedding the API token in the task definition also violates the requirement to avoid hard-coded credentials.