SnowPro Specialty: Gen AI Question 59
Single answerREST APIsA retail company built a customer-support workflow in Snowflake that classifies incoming support tickets with a third-party LLM exposed through a REST API. The workflow is implemented as an external function so analysts can call it directly from SQL. During testing, the security team finds that API keys are embedded in application code and rotated manually, and operations reports intermittent failures when the provider returns rate-limit or transient 5xx errors. The team wants a more secure and resilient design while keeping the SQL interface for users unchanged. Which approach BEST addresses these requirements?
- A
Store the API key in a Snowflake secret, configure the external access or API integration to use that secret, and implement retry/backoff logic in the HTTPS service that fronts the external function before calling the third-party REST endpoint.
- B
Hardcode the API key inside the external function definition so credentials stay close to the SQL interface, and rely on analysts to rerun failed SQL statements when the REST API returns rate-limit errors.
- C
Replace the external function with a JavaScript UDF that calls the third-party REST API directly from Snowflake, because UDFs provide built-in HTTP retry handling and remove the need for integrations.
- D
Keep the current design, but add a masking policy to the SQL text that references the external function so the embedded API key is hidden from most users and transient REST failures are suppressed.
- E
Move the API key to a table in Snowflake protected by RBAC, and have the external function query the table at runtime to append the key to each outbound REST request.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to separate concerns: use Snowflake-managed secret handling for authentication material and handle REST API resiliency in the service layer that fronts the external function. In Snowflake, external functions are designed to let SQL invoke remote services through an API integration, typically backed by an HTTPS endpoint such as API Gateway, a proxy service, or another managed API layer. For secure credential handling, Snowflake provides secret objects and integration-based patterns rather than embedding credentials in code or tables. For reliability, external REST providers commonly return HTTP 429 for rate limits and 5xx for transient failures; best practice is to implement retry with exponential backoff, idempotency where appropriate, and observability in the intermediate service rather than pushing that burden to analysts. This design keeps the SQL interface unchanged while improving security posture and operational stability. Relevant Snowflake documentation areas include External Functions, API Integrations, and Secret management for external network access and authentication.
- A. Correct.
Correct. This aligns with Snowflake best practices for securing outbound credentials and integrating with external REST services. Secrets should be managed through Snowflake secret objects rather than embedded in code. For external calls, the recommended pattern is to use Snowflake integrations and secure credential handling, while resilience for rate limiting and transient upstream failures is typically implemented in the proxied HTTPS service or API layer that the external function invokes. This preserves the SQL interface while improving both security and reliability.
- B. Incorrect.
Incorrect. Hardcoding API keys is a security anti-pattern because rotation becomes manual and credentials may be exposed through code management, deployment tooling, or metadata access. Relying on end users to rerun failed SQL statements is also not a robust strategy for handling HTTP 429 or transient 5xx responses from a REST API.
- C. Incorrect.
Incorrect. Snowflake JavaScript UDFs are not the standard mechanism for making arbitrary outbound REST API calls. Network access for external services is handled through supported integration patterns such as external functions or other governed connectivity features, not by assuming UDFs can directly call third-party endpoints with built-in retry behavior.
- D. Incorrect.
Incorrect. Masking policy on SQL text does not solve the core issue of credential management. Even if text were obscured from some users, the key would still be embedded in logic and manually rotated. Masking also does not add proper retry or backoff behavior for upstream REST failures.
- E. Incorrect.
Incorrect. Storing an API key in a table is weaker than using dedicated secret management. Although RBAC can limit access, tables are not the intended mechanism for secret storage, rotation, and controlled use in outbound authentication. It also introduces unnecessary complexity and potential exposure paths compared with Snowflake secrets and integrations.