SnowPro Specialty: Gen AI Question 75
Single answerREST APIsA data engineering team is building a Snowflake-native GenAI workflow that must call an external LLM provider's REST API from within Snowflake SQL. The provider requires HTTPS requests with a bearer token, and the security team does not want API secrets stored directly in application code or exposed to analysts. The team also wants outbound access restricted to only the provider's API host. Which Snowflake approach best meets these requirements?
- A
Create a network rule for the provider host, store the bearer token in a secret, and use an external access integration so Snowflake code can call the REST API securely
- B
Store the bearer token in a normal table, use a Python UDF to read it at runtime, and call the REST API directly without any additional Snowflake configuration
- C
Create an API integration and use it to call the external LLM provider's REST API from a Python UDF, because API integrations are designed for all outbound REST traffic
- D
Embed the bearer token in the SQL statement that invokes the function and rely on role-based access control to prevent unauthorized users from seeing it
Show answer and explanation
Correct answer: A
Explanation
The best solution is to use Snowflake external network access capabilities for code running inside Snowflake that must call external REST APIs. In practice, this means defining a network rule to allow only the approved hostname, storing the credential in a Snowflake secret, and creating an external access integration that permits the handler to use that network rule and secret. This is the recommended pattern for secure outbound REST access from Snowflake Python or Java UDFs and stored procedures. It satisfies the scenario's key requirements: secure token handling, no hardcoded secrets, and tightly scoped egress control. Candidates may confuse this with API integrations, but API integrations are not the general-purpose mechanism for arbitrary outbound REST requests from handler code. Refer to Snowflake documentation on external network access, secrets, network rules, and external access integrations for the supported architecture and security best practices.
- A. Correct.
Correct. For outbound calls from Snowflake handler code to an external REST API, Snowflake uses external network access controls. A network rule restricts which external hosts can be reached, a secret stores credentials such as bearer tokens, and an external access integration ties those components together for secure use by UDFs or stored procedures. This design aligns with least-privilege and avoids hardcoding secrets in code or queries.
- B. Incorrect.
Incorrect. Storing API tokens in a regular table is not the recommended secure pattern for secrets management. It increases exposure risk and does not by itself authorize outbound network access from Snowflake code. Snowflake requires the appropriate external network access configuration for handlers that call external endpoints.
- C. Incorrect.
Incorrect. API integrations are used for specific Snowflake-managed integrations such as external functions or certain service integrations, but they are not the general mechanism for arbitrary outbound REST calls from UDFs or stored procedures. For Python/Java handler code making direct external requests, Snowflake uses external access integrations together with network rules and secrets.
- D. Incorrect.
Incorrect. Embedding bearer tokens directly in SQL exposes secrets in query text, logs, history, and possibly downstream tooling. RBAC helps with object access, but it is not a substitute for proper secret storage. This option also does not address restricting outbound access to only the approved API host.