SnowPro Advanced: Security Engineer Question 350
Single answerImplement new or update existing network policiesA Snowflake security engineer must update access controls after a company acquires a second office. Users currently authenticate with username/password and connect from the original office through a corporate NAT IP range that is already allowed by an account-level network policy. The new office has a different static egress IP range and needs access immediately. At the same time, the security team wants to ensure service users running automated jobs are not unintentionally blocked during the change. Which approach should the engineer take to meet the requirement with the least operational risk?
- A
Alter the existing account-level network policy to include both office IP ranges, review whether any user-level network policies exist that could override account behavior for critical service users, and validate connectivity before removing any temporary allowances.
- B
Create a new network policy for the new office and attach it to the virtual warehouses used by employees so traffic from the new office is evaluated separately from the account-level policy.
- C
Add the new office IP range to the allowed list in the account parameter without modifying the existing network policy, because account parameters are evaluated before network policies.
- D
Assign a permissive network policy directly to every service user because user-level policies are combined with the account-level policy, ensuring access if either policy allows the connection.
Show answer and explanation
Correct answer: A
Explanation
This question tests practical implementation of updated Snowflake network policies in a real operational scenario. The key concepts are: (1) network policies are used to restrict access by client IP address, (2) they can be applied at the account level and user level, and (3) when a user has a network policy assigned directly, that user-level policy takes precedence over the account-level policy. Therefore, when expanding access for a new office, the safest approach is typically to update the existing account-level network policy to include the new static egress range and verify whether critical service users have user-specific policies that might behave differently. This aligns with Snowflake best practices for controlled rollout and avoiding disruption to automation. Relevant Snowflake documentation includes guidance for CREATE NETWORK POLICY, ALTER NETWORK POLICY, setting network policies at the account or user level, and understanding policy precedence.
- A. Correct.
Correct. In Snowflake, network policies can be set at the account level and also at the user level. A practical low-risk approach is to update the existing account-level policy to allow the additional corporate egress range, while also checking whether any user-level policies are in place for service accounts or other critical users because user-level policy assignment takes precedence over the account-level policy. Validating connectivity before removing any temporary access is a sound operational practice during network policy changes.
- B. Incorrect.
Incorrect. Network policies are not attached to virtual warehouses. They are associated with the account, and can also be assigned to individual users. This option reflects a common misconception that network controls are evaluated at the compute layer rather than the authentication/access layer.
- C. Incorrect.
Incorrect. Snowflake does not use a separate account parameter in place of network policies for IP allowlisting in this manner. Network access restrictions are implemented through network policies, not by adding IP ranges to a generic account parameter evaluated ahead of those policies.
- D. Incorrect.
Incorrect. User-level network policies do not merge with the account-level policy using a permissive union. Instead, a user-level network policy takes precedence for that user. Applying a permissive policy to every service user could create broader access than intended and is not the safest least-risk approach.