SnowPro Advanced: Security Engineer Question 351
Single answerImplement new or update existing network policiesA Snowflake security engineer must urgently tighten inbound access after detecting repeated login attempts from unapproved networks. The company already uses a network policy named CORP_POLICY that is assigned at the account level and currently allows only the corporate NAT IP ranges. However, a small group of incident responders needs temporary access from a new vendor-managed VPN range for the next 48 hours. The engineer must make the change with minimal disruption and ensure that only the required new range is added without weakening existing restrictions. What is the best approach?
- A
Use ALTER NETWORK POLICY on CORP_POLICY to add the vendor VPN CIDR block to the allowed IP list, then keep the policy assigned at the account level.
- B
Create a second network policy for the vendor VPN range and assign both network policies at the account level so Snowflake evaluates them together.
- C
Modify CORP_POLICY to remove the blocked IP list, because allowed IP ranges and blocked IP ranges should not be used in the same policy.
- D
Grant the incident responders a role with elevated privileges so they can bypass the account-level network policy during the incident window.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to update the existing account-level network policy with ALTER NETWORK POLICY and add only the temporary vendor VPN CIDR block to the allowed IP list. This is the least disruptive and most secure way to implement the change because the account already relies on CORP_POLICY to restrict inbound access. Snowflake network policies are designed to restrict login access by client IP address and are typically managed by setting allowed_network_rule_list / blocked_network_rule_list or equivalent allowed and blocked IP definitions depending on configuration approach. Only one effective policy applies at a given scope, so the idea of stacking multiple account-level policies is incorrect. Also, network policies are enforced independently of Snowflake roles, so privileges cannot override them. Snowflake documentation and best practices emphasize using targeted allowlists, making incremental updates with ALTER NETWORK POLICY, and avoiding unnecessary broadening of access during incident response.
- A. Correct.
Correct. In Snowflake, a network policy can be updated with ALTER NETWORK POLICY to change the allowed and blocked IP lists. Because the policy is already attached at the account level, adding the temporary vendor VPN CIDR block to the allowlist is the most direct way to preserve current restrictions while permitting the required access. This approach minimizes disruption because the existing policy remains in place and only the necessary range is added.
- B. Incorrect.
Incorrect. Snowflake does not evaluate multiple account-level network policies together for a single scope in the way described. A network policy assignment is singular for the relevant scope, so creating a second account-level policy to be combined with the first is not the correct implementation model.
- C. Incorrect.
Incorrect. Snowflake network policies can contain both allowed and blocked IP lists. A common misconception is that these are mutually exclusive. In practice, both can be configured, and blocked values can be used to explicitly deny ranges even when broader allows exist. Removing the blocked list would weaken security rather than make the policy more correct.
- D. Incorrect.
Incorrect. Roles and privileges do not bypass network policy enforcement. Network policies control whether a connection is permitted based on client IP evaluation, independent of a user's role. Elevating privileges would not solve the access problem and would introduce unnecessary security risk.