SnowPro Advanced: Security Engineer Question 86
Single answerLeverage Snowflake secrets for secure authentication with external endpoints:A security engineer is helping a data engineering team call a third-party REST API from Snowflake using a Python UDF. The API requires a bearer token, and the company policy prohibits hard-coding credentials in code, stages, or table data. The engineer also wants to ensure outbound traffic is limited to approved hosts only. Which approach should the engineer implement to meet these requirements?
- A
Create a SECRET that stores the API credential, create an EXTERNAL ACCESS INTEGRATION that allows only the approved external network rule and the secret, and reference both from the Python UDF.
- B
Store the bearer token in a VARCHAR column in a secured table, grant SELECT on the table only to the UDF owner role, and have the Python UDF read the token at runtime.
- C
Embed the bearer token in the Python UDF source code, but restrict USAGE on the function so only a small set of roles can invoke it.
- D
Create a SECURITY INTEGRATION for the REST API endpoint and attach it directly to the Python UDF so the function can authenticate and egress without additional configuration.
Show answer and explanation
Correct answer: A
Explanation
The best practice for calling external endpoints from Snowflake handler code is to separate network control from credential storage. Use a SECRET to store the bearer token or other supported credential type, and use an EXTERNAL ACCESS INTEGRATION to explicitly allow egress only to approved destinations via network rules. The UDF or stored procedure references the integration and allowed secret, enabling secure runtime access without placing credentials in code, stages, or relational data. This aligns with Snowflake guidance for external network access, secrets management, and least-privilege outbound access. Key concepts from Snowflake documentation include CREATE SECRET, CREATE EXTERNAL ACCESS INTEGRATION, network rules for egress control, and handler access to secrets for external connectivity.
- A. Correct.
Correct. Snowflake secrets are designed to securely store authentication material for use by supported handlers such as external access from Python or Java UDFs/procedures. To control outbound connectivity, the function should use an EXTERNAL ACCESS INTEGRATION tied to specific network rules that define the approved destinations. The integration can also allow specific secrets, so the UDF can retrieve credentials securely at runtime without exposing them in code or data objects.
- B. Incorrect.
Incorrect. Although a secured table may reduce exposure, storing API tokens in regular table data is not the recommended secure authentication pattern for external endpoint access from Snowflake code. It increases the risk of accidental querying, copying, or auditing complexity, and it does not integrate with the external access secret framework intended for this use case.
- C. Incorrect.
Incorrect. Restricting who can execute a UDF does not make hard-coded credentials acceptable. Hard-coded tokens are difficult to rotate, may be exposed through source inspection or deployment processes, and violate the stated policy. Snowflake secrets exist specifically to avoid embedding credentials in handler code.
- D. Incorrect.
Incorrect. SECURITY INTEGRATION objects in Snowflake are used for specific authentication and security scenarios such as SSO, SCIM, OAuth, external functions API authentication, and related integrations, but they are not the mechanism that enables Python UDF outbound network access with credential retrieval. For this scenario, the correct objects are a SECRET plus an EXTERNAL ACCESS INTEGRATION with appropriate network rules.