ARA-C01 Question 83
Single answerNetwork policiesA financial services company uses Snowflake for both internal analytics and third-party data sharing. Security has required that all human users connect only from the corporate NAT IP ranges, while a service account used by an external ETL tool must continue connecting from the vendor's public IP range. The account currently has no network policies defined. The architect must implement this with the least operational risk and without affecting the ETL service account. Which approach should the architect take?
- A
Create one account-level network policy that allows both the corporate NAT IP ranges and the vendor's public IP range, then rely on role-based access control to prevent human users from connecting from the vendor IPs.
- B
Create an account-level network policy that allows only the corporate NAT IP ranges, and create a user-level network policy for the ETL service account that allows the vendor's public IP range.
- C
Create a user-level network policy for every human user allowing the corporate NAT IP ranges, and leave the account without a network policy so the ETL service account continues to work.
- D
Create an account-level network policy that blocks the vendor's public IP range and allows the corporate NAT IP ranges, then grant the ETL service account a custom role that bypasses network policy enforcement.
Show answer and explanation
Correct answer: B
Explanation
The key design principle is to establish a secure default at the account level and use user-level network policies only for explicit exceptions. In Snowflake, a network policy can be set on the account or on individual users, and the user-level policy overrides the account-level policy for that specific user. That makes option 2 the best answer: apply an account-level policy that allows only the corporate NAT ranges for all users, then assign a dedicated user-level policy to the ETL service account to allow the vendor's public IP range. This aligns with Snowflake security best practices by minimizing exposure and reducing operational complexity. It also avoids the misconception that RBAC or roles can control source IP access; they cannot. Network policies are specifically for restricting login attempts based on client IP addresses.
- A. Incorrect.
Incorrect. A network policy controls source IP access, not user behavior through RBAC. If the vendor public IP range is allowed at the account level, any user whose credentials are used from that IP range could authenticate unless a more restrictive policy applies. RBAC governs object privileges after login, not network ingress restrictions. This option therefore does not meet the requirement that human users connect only from corporate NAT ranges.
- B. Correct.
Correct. In Snowflake, network policies can be assigned at the account and user levels. A user-level network policy takes precedence over the account-level network policy for that user. Setting the account-level policy to allow only the corporate NAT IP ranges restricts all users by default, while assigning a separate user-level policy to the ETL service account allows that service account to connect from the vendor's public IP range without broadening access for everyone else. This is the standard least-risk design for exceptions.
- C. Incorrect.
Incorrect. This can work functionally, but it is not the least operational risk. Managing user-level policies for every human user creates unnecessary administrative overhead and increases the chance of missed users, inconsistent assignments, or future drift. Best practice is to use an account-level network policy for the common baseline and user-level policies only for justified exceptions such as a specific service account.
- D. Incorrect.
Incorrect. Snowflake network policy enforcement is not bypassed through roles. Roles do not override network restrictions. Also, using a blocked list for the vendor IP directly conflicts with the requirement that the ETL service account must continue connecting from that vendor range.