3.3 Scenario Practice for Account Management and Data Governance

Authentication Methods

Users and service accounts authenticate to Snowflake in several ways, and the exam tests which method fits which scenario.

Multi-factor authentication

MFA adds a second factor on top of the password and is enabled per user (self-enrollment in the web UI). It is strongly recommended for any user with ACCOUNTADMIN or SECURITYADMIN. MFA caching can reduce repeated prompts for connectors. A scenario that says "reduce risk of stolen passwords for admins" points to MFA.

Key-Pair, SSO, and OAuth Scenarios

Key-pair authentication replaces a password with an RSA key for non-interactive connections (Python connector, JDBC, SnowSQL automation). You generate a 2048-bit (or larger) RSA key pair, assign the public key to the user with ALTER USER svc SET RSA_PUBLIC_KEY='...', and the client signs with the private key. For rotation, Snowflake supports two slots — RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2 — so you can roll keys with no downtime. When a stem describes a service account or ETL job that should not use a password, key-pair is the answer.

Single sign-on (SSO) uses SAML 2.0 federated authentication. Snowflake acts as the service provider and delegates authentication to an identity provider such as Okta, Microsoft Entra ID/ADFS, or PingFederate. SSO is configured through a security integration. When a stem mentions "corporate identity provider" or "users should log in with their existing company credentials," choose SSO/SAML.

OAuth is token-based and avoids storing Snowflake credentials in the client. Snowflake OAuth is built in for partner BI tools (Tableau, Looker); External OAuth lets an external authorization server (Azure AD, Ping) issue tokens that Snowflake validates. Choose OAuth when an application needs delegated, password-less access on behalf of a user.

Provisioning with SCIM

SCIM (System for Cross-domain Identity Management) integrations with Okta or Entra ID can automatically create, update, and deactivate users and roles in Snowflake when they change in the IdP. A scenario about onboarding/offboarding employees automatically points to SCIM.

Network Policies

A network policy restricts which IP addresses can connect. It is built from an allowed IP list and a blocked IP list using CIDR notation. The critical rule the exam tests: blocked ranges take precedence — if an address appears in both lists, it is denied. A network policy can be applied at the account level or to individual users; a user-level policy overrides the account-level policy for that user.

CREATE NETWORK POLICY corp_only
  ALLOWED_IP_LIST = ('192.168.1.0/24', '203.0.113.0/24')
  BLOCKED_IP_LIST = ('192.168.1.99');
ALTER ACCOUNT SET NETWORK_POLICY = corp_only;

Working a scenario

Approach each identity scenario the same way: identify who is connecting (human vs. service), from where (corporate network vs. anywhere), and what the security requirement is (no stored passwords, existing corporate login, automatic deactivation). Then map: human + admin → MFA; service/ETL → key-pair; corporate login → SSO/SAML; BI app token → OAuth; lifecycle automation → SCIM; restrict by IP → network policy. Distractors usually offer a method that works technically but ignores the specific requirement in the stem — for example, suggesting a shared password where the stem clearly wants password-less automation.

Worked Scenarios

Scenario A — locked-down admin. "Your security team requires that all ACCOUNTADMIN logins use a second factor." The requirement is a second factor on an interactive login, so the answer is enforce MFA (Duo) on the ACCOUNTADMIN users — not a network policy (which limits IPs, not factors) and not key-pair (which is for service accounts).

Scenario B — partner BI tool. "Tableau users must connect without storing Snowflake passwords, authenticating on each user's behalf." Token-based delegated access points to Snowflake OAuth. SSO would also use the IdP, but the cue "BI tool connecting on the user's behalf with tokens" is the classic OAuth signal.

Scenario C — restrict to the office network. "Only connections from the corporate office IP range should be allowed." That is a network policy with an ALLOWED_IP_LIST. If the stem adds "but one compromised machine in that range must be blocked," remember the blocked list wins.

Scenario D — automatic offboarding. "When HR deactivates an employee in Okta, their Snowflake access must disappear automatically." Lifecycle automation from the IdP is SCIM provisioning.

Combining controls

These controls stack. A production account commonly enforces SSO for humans, MFA for privileged roles, key-pair for service accounts, an account-level network policy, and SCIM for lifecycle. The exam may present a stem where two controls are both reasonable; choose the one that addresses the specific risk named (stolen password → MFA; untrusted location → network policy; orphaned accounts → SCIM). Reading the named risk, not just the actors, is the discipline that separates a correct answer from a plausible distractor.