SnowPro Advanced: Security Engineer Question 78
Single answerUse network rules to manage allowed external endpointsA security engineer is reviewing a Snowflake deployment that uses external network access for Python UDFs to call approved third-party REST APIs. The company policy requires that outbound traffic be limited to only api.vendor1.com over HTTPS and auth.vendor1.com over HTTPS. The engineer wants a solution that is maintainable and enforces the restriction centrally before associating it with an external access integration. Which approach should the engineer take?
- A
Create a network rule in EGRESS mode with TYPE = HOST_PORT and VALUE_LIST containing api.vendor1.com:443 and auth.vendor1.com:443, then reference that network rule in the external access integration's ALLOWED_NETWORK_RULES.
- B
Create a network policy that allows only api.vendor1.com and auth.vendor1.com, then attach the network policy to the users who run the UDFs.
- C
Create a network rule in INGRESS mode with TYPE = IPV4 and the public IP addresses of the vendor endpoints, then assign that rule directly to the UDF.
- D
Create a secret object for the vendor credentials and attach it to the UDF; Snowflake will automatically restrict outbound calls to the credential's associated hostnames.
Show answer and explanation
Correct answer: A
Explanation
The correct design is to use a network rule specifically for outbound destinations and then bind it to an external access integration. In Snowflake, external network access from handlers such as Python UDFs and stored procedures is controlled by external access integrations, which in turn reference allowed network rules. For hostname-based restrictions, the rule should use MODE = EGRESS and TYPE = HOST_PORT so the approved destinations can be expressed as host:port pairs like api.vendor1.com:443. This aligns with the principle of least privilege and centralizes control for reuse across multiple handlers. By contrast, network policies govern client access into Snowflake rather than outbound calls from code running in Snowflake. Secrets are complementary for credential management but do not enforce destination allowlists. This approach follows Snowflake guidance for external network access, network rules, and external access integrations.
- A. Correct.
Correct. For external network access, Snowflake uses network rules to define the allowed outbound destinations. To restrict calls to specific external endpoints over HTTPS, the appropriate pattern is to create a network rule in EGRESS mode with TYPE = HOST_PORT and list the approved host:port pairs, such as api.vendor1.com:443 and auth.vendor1.com:443. That network rule is then referenced by an external access integration through ALLOWED_NETWORK_RULES. This is the intended and maintainable control plane for governing outbound endpoints used by UDFs and stored procedures.
- B. Incorrect.
Incorrect. Network policies in Snowflake control how clients connect into Snowflake, typically by restricting source IP addresses or related inbound access conditions for users and accounts. They do not govern outbound connections from UDFs or stored procedures to external services. A candidate might choose this option because both network policies and network rules sound like access controls, but they apply to different traffic directions and use cases.
- C. Incorrect.
Incorrect. External network access for calling external services requires EGRESS-oriented rules, not INGRESS. In addition, using TYPE = IPV4 with public IP addresses is not the best fit for this requirement when the policy is expressed as approved hostnames over HTTPS. Assigning a network rule directly to a UDF is also not how Snowflake enforces this control; the rule must be associated through an external access integration that the UDF or procedure uses. This option mixes multiple incorrect ideas that reflect common misunderstandings.
- D. Incorrect.
Incorrect. Secrets store sensitive values such as API keys, OAuth tokens, usernames, and passwords for use by handlers, but they do not define or enforce which external hosts can be contacted. Outbound endpoint restrictions are handled by network rules and external access integrations. Someone might choose this option if they confuse authentication to the external service with network-level egress authorization.