SnowPro Advanced: Security Engineer Question 62
Single answerRules policies: IP allow lists and deny listsA financial services company uses Snowflake to support internal analysts and a third-party support vendor. Security requirements state that all Snowflake access must be restricted to the corporate NAT range 198.51.100.0/24, except that the vendor may connect only from 203.0.113.10. During an incident review, the security team discovers repeated connection attempts from a known malicious IP address, 198.51.100.77, which is inside the corporate range and must be blocked immediately without disrupting legitimate corporate users or the vendor. Which rule policy design best meets these requirements?
- A
Create a network rule for the corporate range and vendor IP, create a second network rule for 198.51.100.77, then define a rule policy with the corporate and vendor rule in ALLOWED_NETWORK_RULE_LIST and the malicious IP rule in BLOCKED_NETWORK_RULE_LIST.
- B
Create a single network rule containing 198.51.100.0/24, 203.0.113.10, and 198.51.100.77, then attach it to ALLOWED_NETWORK_RULE_LIST because the malicious IP is already part of the broader corporate CIDR.
- C
Create a rule policy that includes only BLOCKED_NETWORK_RULE_LIST for 198.51.100.77 and do not define any allowed list, because Snowflake will implicitly allow only the remaining IPs in 198.51.100.0/24 and the vendor IP.
- D
Create two rule policies: one attached to the account for the corporate range and one attached to each user for the vendor and blocked IP. Snowflake will merge the policies so the blocked IP is denied while all other listed IPs are allowed.
Show answer and explanation
Correct answer: A
Explanation
The best solution is to define separate network rules for approved and denied source IPs, then reference them in a single rule policy that uses both ALLOWED_NETWORK_RULE_LIST and BLOCKED_NETWORK_RULE_LIST. This supports a practical security pattern: allow a broad trusted range, allow a specific partner IP, and carve out an exception for a known-bad address within that trusted range. Snowflake rule policies are designed for this exact use case, and blocked entries take precedence over allowed entries when there is overlap. Best practice is to keep rules modular and explicit so that emergency blocks can be applied without rewriting broader allow rules. This aligns with Snowflake documentation for network rules and rule policies governing IP allow lists and deny lists.
- A. Correct.
Correct. This design uses separate network rules for the allowed sources and the explicitly blocked source, then applies them through a rule policy using both ALLOWED_NETWORK_RULE_LIST and BLOCKED_NETWORK_RULE_LIST. This meets the requirement to permit the corporate CIDR and vendor IP while immediately denying the single malicious IP inside the broader allowed range. In Snowflake rule policies, blocked entries take precedence over allowed entries when both apply, which is exactly the behavior needed here.
- B. Incorrect.
Incorrect. Putting the malicious IP into the same allowed network rule does not block it; it explicitly permits it. The fact that the IP is also part of the broader corporate CIDR does not create an exception. A common misconception is that a more specific host address inside an allowed CIDR can somehow be treated differently without a separate blocked rule, but Snowflake requires explicit use of the blocked list for that outcome.
- C. Incorrect.
Incorrect. Defining only a blocked list would block 198.51.100.77, but it would not restrict access to just the corporate range and vendor IP. Without an allowed list, other IP addresses are not implicitly limited to the stated corporate and vendor sources. This fails the requirement that all access be restricted to specific approved source addresses.
- D. Incorrect.
Incorrect. Snowflake does not support combining multiple rule policies in the way described here. You cannot rely on Snowflake to merge separate account-level and user-level rule policies to create a composite effective policy. This option reflects a common misunderstanding based on how other policy systems behave. The recommended pattern is to define the needed allowed and blocked network rules and reference them within a single rule policy applied at the appropriate scope.