SnowPro Advanced: Security Engineer Question 99
Single answerEgress proxy configurationsA security engineer is enabling outbound access from Snowflake to an internal REST service hosted behind the company's corporate egress proxy. The team wants all traffic from a Snowflake external function to leave through the approved proxy, and they also want to avoid broad network exposure. Which configuration should the engineer implement to meet these requirements?
- A
Create a network rule for the corporate proxy host and port in MODE = EGRESS, create a secret for proxy authentication if needed, and reference both in an external access integration used by the function's handler.
- B
Add the internal REST service URL directly to an ingress network policy, and attach the policy to the user that owns the external function so outbound calls are forced through the proxy.
- C
Create a network rule for the target REST service endpoint in MODE = INGRESS and bind it to a security integration so Snowflake automatically routes external function traffic through the corporate proxy.
- D
Store the proxy URL in a session variable and let the external function resolve routing dynamically at runtime without defining any network rule or integration.
Show answer and explanation
Correct answer: A
Explanation
For Snowflake outbound access, the key control plane objects are egress network rules, secrets, and an external access integration. The integration defines which network locations and secrets code can use, enabling administrators to tightly restrict outbound connectivity. In a proxy-based design, the approved proxy endpoint should be the allowed egress destination, and proxy credentials should be stored in a secret when authentication is required. This is preferable to allowing direct access to many external hosts because it centralizes inspection and enforcement and reduces exposure. A common mistake is confusing ingress network policies, which restrict client access into Snowflake, with egress controls used for outbound calls from Snowflake-managed code or integrations. Snowflake documentation on external network access and network rules emphasizes using MODE = EGRESS for outbound destinations and associating those rules with an external access integration.
- A. Correct.
Correct. For Snowflake outbound access patterns that require controlled external connectivity, the engineer should explicitly allow egress destinations with a network rule defined for egress, then use an external access integration to govern which network rules and secrets are permitted. If the proxy requires authentication, a secret can be used so credentials are not hard-coded. This approach aligns with least-privilege design because only the approved proxy endpoint is allowed rather than opening broad outbound access.
- B. Incorrect.
Incorrect. Network policies and ingress controls govern how clients connect into Snowflake, not how Snowflake-managed code or integrations make outbound connections. Attaching an ingress network policy to a user does not cause external function traffic to traverse a corporate proxy.
- C. Incorrect.
Incorrect. An ingress network rule is for incoming connections to Snowflake, not for outbound destinations. A security integration is also not the mechanism that routes external function or handler traffic through a proxy. This option mixes several Snowflake concepts in a way that sounds plausible but does not match how egress control is configured.
- D. Incorrect.
Incorrect. Snowflake does not rely on ad hoc session variables to authorize outbound destinations. Outbound connectivity must be explicitly governed through supported objects such as network rules and an external access integration. Omitting those controls would not satisfy security or platform requirements.