Accounts and Security Study Guide — ARA-C01

Account Security and Data Protection

This domain is one of the larger topic areas on the SnowPro Advanced: Architect (ARA-C01) exam under the current (carried-over, unverified) blueprint weighting — tied with Performance Optimization, and second to Design. It tests your ability to design, implement, and troubleshoot enterprise-grade security controls across authentication, network isolation, encryption, access governance, data recovery, and audit. Expect scenario-based questions that require you to pick the right combination of features — not just recognize that a feature exists, but know its exact behavior, defaults, tier requirements, and failure modes.

Authentication

Snowflake supports multiple authentication mechanisms. An architect must know when each applies, what it requires, and how they interact.

Key distinctions:

• Snowflake OAuth issues tokens scoped to Snowflake itself; used by Tableau, PowerBI, and similar BI tools.
• External OAuth validates tokens issued by a third-party authorization server (Azure AD, Okta, Ping) using a CREATE SECURITY INTEGRATION of type=EXTERNAL_OAUTH.
• SCIM provisions users and groups but does NOT authenticate them. SCIM-provisioned users still need an auth method.
• Key-pair auth is the recommended authentication method for automated pipelines and service accounts; passwords are discouraged for non-human identities.
• MFA enforcement is controlled via ALTER ACCOUNT SET MFA_ENROLLMENT = REQUIRED (forces users to enroll) versus OPTIONAL.

Common traps

• Confusing SCIM (provisioning) with SSO (authentication) — they are complementary, not the same.
• Thinking key-pair auth satisfies MFA requirements — it does not; it bypasses MFA.
• External OAuth requires a SECURITY INTEGRATION; failing to specify EXTERNAL_OAUTH_ISSUER or EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM causes token validation failure.
• SAML SSO does not eliminate the need for a Snowflake user object; the user must still exist in Snowflake (SCIM solves this gap).

Network Policies

Network policies control which IP addresses can reach a Snowflake account or specific users.

Network Policy rules:

• ALLOWED_IP_LIST and BLOCKED_IP_LIST are both CIDR lists.
• BLOCKED_IP_LIST takes precedence over ALLOWED_IP_LIST.
• A policy can be applied at the account level (ALTER ACCOUNT SET NETWORK_POLICY) or user level (ALTER USER SET NETWORK_POLICY).
• User-level policy overrides account-level policy for that user.
• Only one network policy can be active per user and one per account at any time.

Private Link requirements:

• Available on Business Critical tier and higher.
• Requires a Snowflake support ticket and customer-side VPC endpoint / private endpoint configuration.
• DNS must be updated so the Snowflake account URL resolves to the private endpoint.

Common traps

• Applying a network policy to a user does not stack with the account-level policy — it replaces it for that user.
• Private Link is a tier-gated feature; Standard and Enterprise accounts cannot use it.
• BLOCKED_IP_LIST being empty does not mean all IPs are allowed — ALLOWED_IP_LIST must include the desired CIDRs.
• Network policies do not apply to internal stages or Snowflake-managed services communicating internally.