SnowPro Advanced: Security Engineer Question 57
Single answer1.3 Implement network security controls.A security engineer is hardening a Snowflake deployment used by both internal employees and an external ETL vendor. The company must ensure that Snowflake logins are allowed only from approved corporate egress IPs and the vendor's fixed NAT IPs. However, security administrators must still be able to connect from a separate emergency break-glass network if the main corporate network is unavailable. The engineer wants the most secure design with the least ongoing administrative overhead. Which approach should be implemented?
- A
Create a network rule containing the approved corporate, vendor, and break-glass IP addresses, then create a network policy that allows only that rule and assign the policy at the account level.
- B
Create separate network policies for corporate users, vendor users, and administrators, then assign all three policies at the account level so Snowflake can evaluate them together.
- C
Rely on session policies for administrators and users, because session policies can restrict source IP addresses while also controlling authentication behavior.
- D
Enable private connectivity for the Snowflake account, then remove all network policies because private connectivity alone enforces that only approved public IP addresses can connect.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to implement a network policy that explicitly allows only approved source IP ranges and apply it at the account level. Snowflake network policies are the native mechanism for restricting access based on client IP address. Using a network rule to hold the approved IP list improves maintainability compared with embedding many values directly in policy definitions. This design is especially appropriate when the requirement is to allow a known set of corporate, vendor, and emergency administration egress addresses.
Key points candidates should know:
- Network policies control which client IP addresses may connect to Snowflake.
- A network rule can be used as a reusable object representing allowed IP ranges, helping reduce administrative overhead.
- Network policies are not combined arbitrarily across the same scope; candidates should understand assignment and precedence behavior rather than assuming multiple policies are unioned together.
- Session policies are unrelated to source IP filtering.
- Private connectivity is valuable for reducing internet exposure, but it is not a universal substitute for network policies in mixed-access scenarios.
This reflects Snowflake guidance for implementing network security controls using network policies and related objects to enforce trusted ingress paths while maintaining operational resilience for administrative access.
- A. Correct.
Correct. In Snowflake, network policies are the primary control used to restrict access by client IP address. A practical and low-overhead design is to define the approved source IPs in a network rule and reference that rule from a network policy, then apply the policy at the account level to enforce a consistent perimeter. Including the break-glass network in the allowed set preserves emergency administrative access without requiring policy changes during an outage. This aligns with Snowflake best practice for centralized ingress restriction.
- B. Incorrect.
Incorrect. Snowflake does not evaluate multiple account-level network policies together for a single connection attempt in the way described. A single effective network policy is applied based on assignment scope and precedence, not a merged set of multiple account-level policies. This option reflects a common misconception that network policies can be layered additively across the same scope.
- C. Incorrect.
Incorrect. Session policies do not restrict source IP addresses. They are used for controls such as session idle timeout and session lifetime, not network ingress filtering. Choosing this option confuses session management controls with network security controls.
- D. Incorrect.
Incorrect. Private connectivity can reduce exposure to the public internet, but it does not replace all network access control requirements, and it does not enforce approved public IP lists by itself. Also, the scenario explicitly includes external vendor access via fixed NAT IPs and a break-glass network, which are appropriately controlled using network policies. Removing network policies would weaken defense in depth.