SnowPro Advanced: Security Engineer Question 63
Single answerRules policies: IP allow lists and deny listsA security engineer at a company using Snowflake needs to restrict direct user logins so that employees can connect only from the corporate NAT range 198.51.100.0/24. However, the company also has a small set of incident-response engineers who must be blocked immediately if they attempt to connect from a known compromised public IP, 198.51.100.77, even though that IP is inside the corporate range. The engineer wants a control that can be attached to the affected users and that enforces the more specific block without changing network infrastructure. Which configuration best meets the requirement?
- A
Create a network rule with TYPE = IPV4 and VALUE_LIST including 198.51.100.0/24 and 198.51.100.77, create a network policy that puts both rules in ALLOWED_NETWORK_RULE_LIST, and attach the policy to the users.
- B
Create one network rule for 198.51.100.0/24 and add it to ALLOWED_NETWORK_RULE_LIST, create a second network rule for 198.51.100.77 and add it to BLOCKED_NETWORK_RULE_LIST, then attach the network policy to the affected users.
- C
Create a password policy for the incident-response engineers and set it to reject authentication attempts originating from 198.51.100.77 while allowing 198.51.100.0/24.
- D
Create a session policy with a restricted idle timeout for the incident-response engineers and rely on the session policy to prevent connections from 198.51.100.77.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use Snowflake network rules and a network policy with both allow and block logic. In Snowflake, IP restrictions are implemented through network rules, typically with TYPE = IPV4 for IPv4 addresses and CIDR ranges, and then referenced in a network policy. The policy can include ALLOWED_NETWORK_RULE_LIST and BLOCKED_NETWORK_RULE_LIST. For this scenario, allowing 198.51.100.0/24 while blocking 198.51.100.77 is the correct pattern because it enforces a specific deny within an otherwise allowed corporate range. Attaching the network policy to users is appropriate when the requirement applies to specific identities rather than the whole account. This aligns with Snowflake best practices for network access control: use network policies for source-IP restrictions, password policies for credential rules, and session policies for post-authentication session behavior.
- A. Incorrect.
Incorrect. Putting both the subnet and the specific IP into the allowed list would explicitly allow both. This does not satisfy the requirement to block 198.51.100.77. A common misconception is that a more specific entry inside an allow list somehow becomes an exception, but Snowflake network policies require blocked entries to be defined in the blocked list.
- B. Correct.
Correct. Snowflake supports network rules of TYPE = IPV4 that can be referenced by a network policy. To meet the requirement, the corporate subnet should be allowed through ALLOWED_NETWORK_RULE_LIST, while the compromised IP should be explicitly denied through BLOCKED_NETWORK_RULE_LIST. This gives the desired exception handling, and the policy can be attached directly to users so it applies to those identities without changing upstream network devices.
- C. Incorrect.
Incorrect. Password policies govern password-related controls such as complexity, lockout, and rotation behavior; they do not filter connections by source IP address. Someone might choose this option because it is also a user-level security control, but it is not designed for IP-based access restrictions.
- D. Incorrect.
Incorrect. Session policies control session behavior such as idle timeout and can help reduce exposure after login, but they do not determine whether a client IP address is permitted to authenticate in the first place. This option addresses session management, not network-origin restrictions.