SnowPro Advanced: Security Engineer Question 101
Single answerConfigure external functionsA security engineer is implementing a Snowflake external function that sends customer identifiers to a tokenization service hosted behind a cloud API gateway. The company requires that Snowflake authenticate to the remote service without embedding static secrets in function definitions, and the security team wants outbound access tightly scoped to only the approved endpoint. Which configuration best meets these requirements?
- A
Create an API integration that references the allowed API gateway prefix and a cloud provider token configuration, then create the external function using that API integration.
- B
Create a network policy that allows Snowflake egress only to the tokenization endpoint, then attach the policy to the external function.
- C
Store the tokenization service credentials in a Snowflake secret and reference the secret directly in the external function definition.
- D
Use a secure UDF instead of an external function so Snowflake can call the remote HTTPS endpoint without additional integration objects.
Show answer and explanation
Correct answer: A
Explanation
For external functions, Snowflake requires an API integration that defines how Snowflake communicates with an external proxy service such as Amazon API Gateway, Azure API Management, or Google Cloud API Gateway/Cloud Run-based proxy patterns, depending on the cloud architecture. From a security perspective, the API integration is the correct place to restrict allowed outbound endpoint prefixes and configure authentication between Snowflake and the cloud provider service. This is preferable to embedding static credentials in SQL definitions and supports least-privilege outbound access. Network policies are for controlling inbound client access to Snowflake accounts, not outbound calls made by Snowflake. Likewise, secure UDFs do not replace the external function architecture. Best practice is to use API integrations with tightly scoped allowed URL prefixes and cloud-native authentication supported by Snowflake external functions.
- A. Correct.
Correct. External functions are configured through an API integration, which is the Snowflake object used to define and secure communication with a proxy service such as a cloud API gateway. The API integration can restrict outbound calls to specific allowed URL prefixes and can be configured to use cloud-native authentication mechanisms rather than hardcoding credentials in the function definition. This aligns with least privilege and avoids embedding static secrets in SQL objects.
- B. Incorrect.
Incorrect. Network policies in Snowflake control client access to Snowflake based on IP rules; they do not govern Snowflake's outbound connectivity for external functions. A common misconception is to treat network policies as general-purpose egress controls, but outbound access for external functions is controlled through the API integration's allowed prefixes and the cloud-side proxy configuration.
- C. Incorrect.
Incorrect. Secrets are used with other Snowflake features such as external network access for procedures and functions in supported runtimes, not as the standard mechanism for authenticating external functions. External functions rely on an API integration and a supported proxy service. Referencing a secret directly in the external function definition is not how external function authentication is configured.
- D. Incorrect.
Incorrect. Secure UDFs protect the function definition and can help with data governance, but they do not provide a way to invoke arbitrary remote HTTPS services. Calling remote services from Snowflake in this pattern requires an external function backed by an API integration and proxy service, not a standard or secure UDF alone.