SnowPro Advanced: Security Engineer Question 49
Single answerImplement external API authentication and secretsA security engineering team is building a Snowflake external function that sends customer risk data to a third-party fraud detection REST API. The API requires a bearer token, and the team wants to avoid hardcoding credentials in SQL objects or handler code. They also want token rotation to occur without recreating the external function. Which approach best meets these requirements?
- A
Create a SECURITY INTEGRATION for API authentication, create a SECRET that stores the API credential details, grant the developer role READ on the secret and USAGE on the schema, and configure the external function to use that secret through the API integration.
- B
Store the bearer token directly in the external function definition as a constant HTTP header so the remote service receives the same token for every call until the function is replaced.
- C
Create an API INTEGRATION for the external function and configure it to reference a SECURITY INTEGRATION that handles the external API authentication, with credentials stored in a Snowflake SECRET so they can be rotated independently of the function definition.
- D
Encrypt the bearer token with a customer-managed key, store the ciphertext in a table, and have the external function decrypt the value at runtime before sending the HTTP request.
Show answer and explanation
Correct answer: C
Explanation
The best answer is to use Snowflake's supported integration-based model for external function authentication: an API integration for the external function path and a security integration for authenticating to the external API, with credentials managed as secrets so they can be rotated independently. This aligns with Snowflake security best practices: do not embed tokens in SQL definitions or code, minimize direct credential exposure, and centralize authentication configuration. In practice, the exact object relationships depend on the external function authentication method configured, but the core principle is consistent: use integrations and managed secrets rather than hardcoded headers or custom decryption logic. Candidates should distinguish external functions from external network access used by procedures/UDFs, because secrets are used differently across these features. Snowflake documentation on external functions, API integrations, security integrations, and secret management emphasizes using supported integrations for outbound authentication and avoiding plaintext credentials in application code or object definitions.
- A. Incorrect.
Incorrect. This mixes concepts in a way Snowflake does not support for external functions. Secrets are used with supported features such as external access integrations and Snowpark/handler access to secrets, but external functions use an API integration for connectivity and can reference a security integration for authentication to the remote service. Granting READ on a secret to a developer role is also not the key control pattern for this use case.
- B. Incorrect.
Incorrect. Hardcoding a bearer token in the external function definition violates the requirement to avoid embedding credentials in SQL objects and makes rotation operationally difficult because the function would need to be altered or recreated whenever the token changes. This is a common but insecure pattern.
- C. Correct.
Correct. For external functions, Snowflake uses an API integration to define the outbound integration to the proxy service, and API authentication for the remote endpoint is handled through a referenced security integration. Using Snowflake secret management for the credential material allows rotation without changing the external function definition itself, which is the design goal in this scenario.
- D. Incorrect.
Incorrect. External functions do not provide a pattern where the function definition retrieves arbitrary encrypted secrets from tables and decrypts them for outbound HTTP headers. This approach increases complexity, expands access to sensitive material, and bypasses Snowflake's supported integration-based authentication patterns.