SnowPro Advanced: Security Engineer Question 60
Single answerUse network rules for granular access controlA security engineer needs to tighten inbound access to a Snowflake account used by both employees and a third-party ETL vendor. Employees should connect only from the company NAT IP ranges, while the vendor should connect only from its published CIDR blocks. The engineer also wants a solution that is easier to maintain than embedding all allowed IPs directly in a network policy. Which approach best meets these requirements using Snowflake network rules?
- A
Create separate network rules for the employee and vendor IP ranges, then reference those rules in a network policy allow list and attach the policy at the account level.
- B
Create a single network rule for the vendor IP ranges and grant it to the vendor role; use no network policy because network rules enforce access by themselves.
- C
Create network rules for the employee and vendor IP ranges, then attach the rules directly to users so each user inherits only the matching IP restrictions.
- D
Create a network policy with blocked IP ranges for all public addresses except the company and vendor IPs; network rules are not intended for controlling client ingress access.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to define reusable network rules for each trusted source range and then use those rules in a network policy. This aligns with Snowflake best practices for maintainability and granular access control: network rules let administrators manage IP/CIDR groups centrally, while network policies provide the enforcement layer for restricting inbound client connections to Snowflake. In practice, this is preferable to embedding many IPs directly in policy definitions because vendor and corporate ranges often change over time. Snowflake documentation describes network policies as the mechanism for restricting client access by IP and network rules as reusable objects that can be referenced to simplify administration and support granular security designs.
- A. Correct.
Correct. Snowflake network rules can define groups of IP addresses or CIDR ranges that are reused in policies, which is more maintainable than hardcoding long IP lists directly in a network policy. A network policy can then reference these rules in its allowed network list to control inbound client connectivity. Applying the policy at the account level is appropriate when the requirement covers all users of the account, including both employees and the vendor.
- B. Incorrect.
Incorrect. Network rules do not independently enforce client access just by being created, and they are not granted to roles for this purpose. For inbound client IP restriction, enforcement is done through a network policy that uses the network rules. This option reflects the common misconception that network rules are standalone enforcement objects.
- C. Incorrect.
Incorrect. Network rules are not attached directly to users to impose ingress IP restrictions. User- or account-level enforcement for client IP access is done through network policies. While network policies can be assigned at different scopes depending on the use case, directly binding network rules to users is not how Snowflake implements this control.
- D. Incorrect.
Incorrect. Network rules are specifically useful for granular access control and can be referenced by network policies for inbound restrictions. Also, trying to block essentially the entire public internet is operationally fragile and harder to maintain than defining explicit allowed ranges. This option incorrectly suggests that network rules are not relevant to client ingress control.