ARA-C01 Question 84
Single answerNetwork policiesA global company uses Snowflake for analytics. Security requires that interactive access from corporate offices and the company VPN be allowed, while all other public IP ranges must be blocked. At the same time, several third-party ETL vendors connect from IP addresses that can change without notice, so the company does not want those service accounts to be restricted by the same corporate IP rules. The architect must implement this with the least operational overhead and without disrupting the ETL integrations. Which approach should the architect recommend?
- A
Create one account-level network policy that allows only the corporate office and VPN IP ranges, and apply it to the Snowflake account.
- B
Create a network policy for the account that allows only corporate office and VPN IP ranges, and create separate users for the ETL vendors with no user-level network policy assigned.
- C
Create a restrictive account-level network policy for corporate office and VPN IP ranges, and create a different user-level network policy for each ETL service user that allows the required broader access.
- D
Do not use network policies. Instead, rely on role-based access control for users and use login history monitoring to detect access from unexpected IP addresses.
Show answer and explanation
Correct answer: C
Explanation
The best solution is to apply a restrictive account-level network policy for the corporate office and VPN ranges, then assign separate user-level network policies to ETL service accounts that need different source IP treatment. Snowflake network policies are designed to control login access based on client IP addresses. Critically, when both account-level and user-level network policies exist, the user-level policy overrides the account-level policy for that specific user. This makes it possible to establish a secure default posture for most users while handling exceptions for service accounts in a controlled way. Best practice is to use service accounts for integrations and assign exceptions narrowly rather than weakening the account-wide policy. This aligns with Snowflake documentation on network policies, policy assignment scope, and precedence behavior.
- A. Incorrect.
Incorrect. An account-level network policy applies broadly to account access. If it allows only corporate office and VPN IP ranges, ETL vendor connections from changing public IPs would be blocked. This satisfies the office-user requirement but fails the business requirement to avoid disrupting integrations.
- B. Incorrect.
Incorrect. Leaving ETL service users without a user-level network policy does not exempt them from an account-level network policy. If the account-level policy is restrictive, those users are still subject to it unless a user-level network policy is explicitly assigned. A common misconception is that 'no user policy' means 'no restriction,' but account-level policy still applies.
- C. Correct.
Correct. In Snowflake, a network policy can be set at the account level and also at the user level. A user-level network policy takes precedence over the account-level network policy for that user. This allows the architect to enforce a restrictive default for interactive users at the account level while assigning broader or different policies only to ETL service users, minimizing operational overhead and preserving integrations.
- D. Incorrect.
Incorrect. RBAC controls what authenticated users can do, not where they can connect from. Login history can help detect suspicious access after the fact, but it does not prevent unwanted connections. This option does not meet the preventive network access control requirement.