SnowPro Advanced: Security Engineer Question 76
Single answerCreate, implement and manage external access integrations:A security engineer needs to let a Python UDF in Snowflake call a third-party fraud scoring REST API. Company policy requires that outbound access be tightly restricted to only the approved API host and that the API key not be hard-coded in the function definition. The engineer wants the UDF to be able to use the stored credential securely at runtime. Which configuration should the engineer implement?
- A
Create a NETWORK RULE that allows the specific external host, create a SECRET to store the API credential, and create an EXTERNAL ACCESS INTEGRATION that references both the allowed network rule and the allowed secret. Then associate that integration and secret usage with the Python UDF.
- B
Create a SECURITY INTEGRATION for the API provider, attach the API key directly to the integration, and grant USAGE on the integration to the UDF owner role so the Python UDF can call the endpoint.
- C
Store the API key in a session variable, create a NETWORK POLICY to allow the target host, and reference both from the Python UDF so outbound requests are restricted and authenticated.
- D
Create an API INTEGRATION for the REST endpoint and attach the API key as a masked tag on the function so the Python UDF can retrieve it securely during execution.
Show answer and explanation
Correct answer: A
Explanation
For handler code in Snowflake, such as Python UDFs or stored procedures, outbound calls to external services are managed through external network access. The secure implementation uses three core components: a NETWORK RULE to define allowed egress destinations, a SECRET to store credentials such as an API key or OAuth token material, and an EXTERNAL ACCESS INTEGRATION to bind the allowed network locations and secrets. The function or procedure is then created to use that integration and authorized secret access. This aligns with Snowflake best practices for least privilege and secret management: restrict outbound hosts explicitly and never hard-code credentials in source code. Candidates should distinguish this from NETWORK POLICY, which governs inbound client connectivity to Snowflake, and from API INTEGRATION, which is associated with external functions rather than general external access from Snowpark or handler code.
- A. Correct.
Correct. External network access from Snowflake UDFs and stored procedures is controlled through an EXTERNAL ACCESS INTEGRATION. To restrict egress, you define a NETWORK RULE for the approved host. To avoid hard-coding credentials, you store them in a SECRET and allow that secret in the EXTERNAL ACCESS INTEGRATION. The Python UDF can then be created with the external access integration and authorized secret usage, which is the intended Snowflake pattern for secure outbound calls.
- B. Incorrect.
Incorrect. SECURITY INTEGRATION objects are used for specific identity, authentication, and external service integration patterns such as SSO, SCIM, or some service auth scenarios, but they are not the mechanism for enabling outbound network access from a Python UDF to an arbitrary REST API with a stored API key. The API key is not attached this way for external access integrations.
- C. Incorrect.
Incorrect. NETWORK POLICY controls which client IP addresses can connect to Snowflake, not which external destinations Snowflake code can call. Session variables are also not an appropriate secure secret-management mechanism for long-lived API credentials in this scenario. This option mixes inbound access controls with outbound access requirements.
- D. Incorrect.
Incorrect. API INTEGRATION is used for specific Snowflake features such as external functions, not for enabling Python UDF external network access. A masked tag is for data governance and masking-related metadata behavior, not a secure runtime credential store for UDFs. This option confuses external functions with external access integrations.