SnowPro Core Prep

Lab 07 · Domain 2 · You are Priya

Prove who you are — and from where

Read every Teach first section before you copy SQL. Roles (Lab 06) answer what you can do. This lab answers how you log in and which networks are allowed. Trial accounts may not configure every option — see-cards still count for the exam.

Business problem Sam found a shared password in a Slack thread. Morgan wants MFA for humans, key-pair for the nightly loader, and a plan if someone tries to log in from a random café IP.
Solution you will learn MFA, federated SSO, key-pair, OAuth — when each fits. Network policies as IP allow/block lists (safe allow-all teaching object only). Trust Center as posture awareness — not a substitute for RBAC.
Before
Password-only chaos
  • Humans share passwords
  • CI stores plaintext passwords
  • Any IP can attempt login
After
Layered front door
  • Humans: SSO + MFA
  • Services: key-pair / OAuth
  • Network policy = IP fence

Episode 07 · Start here

Sam finds a password. Dev draws the front door.

SamCompliance
Someone pasted the service account password into Slack. If that leaks, RBAC won’t save us — the thief wears Riley’s badge.
DevCoach
Authentication is the front door. MFA/SSO for people. Key-pair for robots. Network policy decides which streets can even ring the doorbell.

Auth = who · Network policy = from where · RBAC = what they can touch after entry.

See it — auth methods (exam pictures)

Human
MFA = password + phone

Second factor (app/Duo) so a stolen password alone fails. Enable in Snowsight user profile.

Password works →
prompt for app code
Company login
Federated SSO

Log in at Okta / Azure AD; Snowflake trusts the IdP via a SAML security integration. MFA often lives at the IdP.

One company login →
Snowflake session
Robot
Key-pair for services

Public key on the user; private key in the vault/CI. No shared password in Slack.

ALTER USER svc SET RSA_PUBLIC_KEY=…
App token
OAuth

Partner apps / custom clients get tokens via an OAuth security integration. BI tools often use this.

App asks IdP →
token → Snowflake

See it — network policy & Trust Center

IP fence
Network policy

Allowed / blocked CIDR lists. Attach to account or a single user. Wrong allow-list = lockout.

Office 203.0.113.10/32
allowed · café blocked
Health check
Trust Center

Snowsight scanner for security posture (MFA gaps, risky settings). Awareness for Core — not a magic fix.

Findings list →
fix MFA / policies

Which door for which visitor?

1 · Human SSO + MFA Priya, Kai, Morgan
2 · Batch job Key-pair nightly loader user
3 · Partner app OAuth BI / custom client
4 · Fence Network policy IP allow where needed

Before Step 1

Riley: “I’ll lock the account to my laptop IP”

RileyPeer engineer
I’ll set ALLOWED_IP_LIST to my home IP and attach it to the whole account. Super secure!
MorganManager
Until your ISP rotates the IP and nobody can open Snowsight. On trial: create policies to learn syntax — don’t attach a tight one to the account.

1 SHOW network policies (safe)

What this does: Lists any policies already on the account. Read-only — cannot lock you out.

SQL · show policies
USE ROLE ACCOUNTADMIN;

SHOW NETWORK POLICIES;
✓ Result set (maybe empty on a fresh trial)

2 Create a safe allow-all teaching policy

What this does: Practices CREATE NETWORK POLICY / DESCRIBE syntax with 0.0.0.0/0 (all IPv4). Do not treat this as production hardening. Leave account attach commented.

SQL · create + describe
CREATE NETWORK POLICY IF NOT EXISTS NP_ALPINE_LAB_ALLOW_ALL
  ALLOWED_IP_LIST = ('0.0.0.0/0')
  COMMENT = 'Lab 07 teaching — allows all IPv4';

DESCRIBE NETWORK POLICY NP_ALPINE_LAB_ALLOW_ALL;
SHOW NETWORK POLICIES LIKE 'NP_ALPINE%';
Do not run on trial unless you know your IPs Office-only example lives commented in sql/07_auth_network.sql. Prefer attaching a tight policy to one service user first — not the whole account.
✓ Policy object exists · DESCRIBE shows 0.0.0.0/0

Before Step 3

Kai: “Is MFA the same as SSO?”

KaiAnalyst
My company says “use SSO.” Is that MFA? Or something else?
DevCoach
Different layers. SSO = where you prove identity (company IdP). MFA = second factor. Often you get both: SSO login that also demands the phone code.

3 Auth setup map (read — may not configure on trial)

What this does: Gives you the exam story for each method. Full commented DDL lives in sql/07_auth_network.sql.

Notes · SSO / key-pair / OAuth
-- MFA: enable authenticator in Snowsight user profile
-- SSO: CREATE SECURITY INTEGRATION … TYPE = SAML2 (IdP admin helps)
-- Key-pair: generate RSA keys → ALTER USER … SET RSA_PUBLIC_KEY='…'
-- OAuth: CREATE SECURITY INTEGRATION … TYPE = OAUTH for apps
-- Trust Center: Snowsight → Security → review findings
✓ You can name each method and who it is for

4 Session context check

What this does: Confirms who you are in this session — useful when debugging “wrong user / wrong region” auth tickets.

SQL · session
SELECT CURRENT_USER(), CURRENT_ROLE(),
       CURRENT_ACCOUNT(), CURRENT_REGION();
✓ Your user + account locator + region print

Exam presses further — say these out loud

Basics named the doors. Cover each answer before you open it.

Q1. MFA vs SSO — same thing?

Say: No. SSO federates identity to an IdP (one company login). MFA adds a second factor. They combine often but answer different exam questions.

Q2. Why key-pair for service accounts instead of passwords?

Say: Automation shouldn’t share human passwords. Public key on the Snowflake user; private key in a vault. Rotatable, no Slack paste, fits SnowSQL/connectors.

Q3. What does a network policy actually enforce?

Say: Client IP must match ALLOWED_IP_LIST and not BLOCKED_IP_LIST. Attach at account or user. Misconfigured allow-list locks legitimate users out — test on one user first.

Q4. What is Trust Center for?

Say: Account security posture findings (e.g. users without MFA, risky configs). Awareness/monitoring — it does not replace designing RBAC, SSO, or network policies.

Q5. OAuth vs key-pair — when OAuth?

Say: OAuth when a partner app or custom client needs delegated tokens via a security integration. Key-pair when your own service connects directly as a Snowflake user (ETL, scripts).

Priya’s wrap-up (say this out loud)
“RBAC decides what you can touch after you get in. Auth decides how you prove identity: SSO and MFA for people, key-pair or OAuth for services. Network policies fence which IPs may connect — I practiced CREATE/DESCRIBE with an allow-all lab policy and left tight account attaches commented so I don’t lock the trial. Trust Center surfaces posture gaps. Outcome: I can pick the right front door on Domain 2 questions.”
Next Lab 08 — masking, row access, tags on SECURE.CUSTOMERS_PII.
← Lab 06 Lab 08 — governance →