SnowPro Advanced: Security Engineer Question 100
Single answerConfigure external functionsA security engineering team must configure a Snowflake external function that sends tokenized customer identifiers to an internal REST service hosted behind AWS API Gateway. The function will be used by analysts, but the service must trust only calls that originate from Snowflake, and the team wants to avoid embedding long-lived secrets in SQL definitions. Which configuration best meets these requirements?
- A
Create an API integration that uses a Snowflake-generated IAM user, configure the API Gateway resource policy to allow that IAM principal, and create the external function referencing the API integration.
- B
Create a security integration with OAuth, store the client secret in the external function definition, and have API Gateway validate the OAuth token before invoking the REST service.
- C
Create a network policy that restricts analyst IP addresses, then create the external function without an API integration because Snowflake will inherit the network policy for outbound calls.
- D
Create the external function with a direct HTTPS URL to the REST service and use a masking policy on the input column so the remote service can trust the request source.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use an API integration with AWS API Gateway and trust Snowflake through the Snowflake-generated IAM principal. In Snowflake, external functions are designed to call remote services through a supported proxy/service layer such as AWS API Gateway. The API integration stores the secure connection details and separates trust configuration from the function definition, which aligns with security best practices by avoiding hard-coded secrets in SQL. On AWS, the API Gateway resource policy can be configured to allow invocation only from the IAM principal Snowflake provides for the integration. This is the standard pattern documented for securing external functions on AWS. Network policies do not govern Snowflake outbound calls, and masking policies do not authenticate request origin. Relevant Snowflake documentation includes the sections on creating API integrations for external functions and configuring AWS API Gateway with a Snowflake-generated IAM user.
- A. Correct.
Correct. For AWS-hosted external functions, Snowflake uses an API integration to securely associate the external function with API Gateway. A common secure pattern is to configure the API integration so Snowflake uses a Snowflake-generated IAM user, then update the API Gateway resource policy to trust that IAM principal. This lets the remote service trust requests as originating from Snowflake without embedding static secrets in SQL objects. The external function then references the API integration rather than carrying credentials itself.
- B. Incorrect.
Incorrect. OAuth security integrations are used for specific Snowflake authentication and external access patterns, but this is not the standard way to authenticate Snowflake external functions to AWS API Gateway. Also, storing a client secret in the external function definition conflicts with the requirement to avoid embedding long-lived secrets in SQL definitions. A candidate might choose this because OAuth is a common API security pattern, but it is not the recommended Snowflake configuration for this scenario.
- C. Incorrect.
Incorrect. Network policies in Snowflake control client access to Snowflake, not Snowflake's outbound connectivity from external functions. External functions require an API integration; they do not inherit outbound trust from a network policy. This distractor targets the misconception that network policies can secure all network paths involving Snowflake.
- D. Incorrect.
Incorrect. External functions are not configured as arbitrary direct outbound HTTPS calls without the required integration and proxy setup. In addition, masking policies protect returned or queried data in Snowflake; they do not prove request origin to the remote service. Someone might select this because masking policies are security features, but they do not establish trust between Snowflake and the external endpoint.