SnowPro Advanced: Security Engineer Question 61
Single answerUse network rules for granular access controlA financial services company uses Snowflake Business Critical Edition and wants to restrict access to a production account so that only users connecting from the corporate NAT gateway range 198.51.100.0/24 and a private connectivity endpoint VPCE-ID vpce-0abc123def4567890 can sign in. The security team also wants a solution that can be reused across multiple policies and kept separate from the policy definition itself. Which approach best meets these requirements?
- A
Create a network rule that contains the allowed IPv4 CIDR range and the allowed AWS PrivateLink VPCE ID, then reference that network rule from a network policy allow list.
- B
Create a network policy and place both the CIDR range and the VPCE ID directly into ALLOWED_IP_LIST, because network policies can store either IP addresses or private endpoint identifiers in the same property.
- C
Create two network rules, one for the allowed CIDR range and one for the allowed VPCE ID, and assign the network rules directly to the ACCOUNT parameter NETWORK_RULE.
- D
Create a network rule with TYPE = HOST_PORT for the corporate gateway and VPCE endpoint, then attach it to the login policy for all users.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a network rule as a reusable object that defines approved network locations, then reference that object from a network policy. This is the recommended pattern for granular access control because it separates network location definitions from enforcement logic. In practice, security teams can manage network rules centrally and reuse them across policies as requirements evolve. Snowflake documentation on network policies and network rules describes how network rules provide reusable definitions for allowed or blocked network identifiers, including support for private connectivity scenarios such as cloud provider private endpoints. A common misconception is that all source restrictions should be embedded directly in ALLOWED_IP_LIST, but that approach is less modular and does not satisfy the requirement to keep definitions separate and reusable. Another common error is confusing network policies with login policies or assuming network rules are enforced directly at the account level without a network policy.
- A. Correct.
Correct. Network rules are designed to define reusable sets of network identifiers, including IP network ranges and private connectivity identifiers, depending on the rule type and mode. A network policy can then reference network rules for allowed and blocked network locations. This matches the requirement for granular control, reuse across policies, and separation of location definitions from the policy itself.
- B. Incorrect.
Incorrect. This reflects an older or simplified understanding of network policies. While network policies support IP-based allow and block behavior, the requirement explicitly asks for a reusable definition separated from the policy. Also, private connectivity identifiers are not managed by simply mixing them into ALLOWED_IP_LIST in the same way as CIDR entries. Network rules are the intended mechanism for this more granular, reusable design.
- C. Incorrect.
Incorrect. Network rules are not assigned directly through an ACCOUNT parameter called NETWORK_RULE for login enforcement. Access enforcement for client sign-in is handled by network policies, which can reference network rules. Creating separate network rules can be valid in some designs, but the enforcement mechanism described here is wrong.
- D. Incorrect.
Incorrect. HOST_PORT network rules are used for other Snowflake networking use cases, not for controlling user sign-in source locations in a network policy. Login policies govern authentication-related settings such as password and MFA behavior, but they do not attach network rules to restrict source networks. This option confuses login policies with network policies.