Snowflake Gen AI Governance — SnowPro Gen AI C02 study notes

Domain 3.0 = 29% of the exam (second-largest). Objectives transcribed verbatim from the official C02 study guide; this file was created 2026-06-18 to close the gap where the project had no dedicated Governance study file (the C01 map treated Domain 3 as SPCS + Model Registry, which C02 demoted into Domain 1.0 Overview). Expand each section with hands-on reps before exam day; flagged spots need a sandbox to confirm exact syntax.

The four official objective groups: 3.1 model access controls · 3.2 RBAC & privileges · 3.3 cost management/monitoring · 3.4 AI observability.

3.1 Set up model access controls

Limits on which models can be used

• Restrict access to specific models via the account-level allowlist parameter CORTEX_MODELS_ALLOWLIST (set with ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = '...'). Values: 'All', 'None', or a comma-separated model list (e.g. 'mistral-large2,llama3.1-70b'). Confirm exact value syntax in a sandbox.
• Application roles + RBAC also gate model access (see 3.2).

Data safety and security considerations

• Cross-region inference — when a requested model isn't available in the account's region, Snowflake can route the request to another region IF CORTEX_ENABLED_CROSS_REGION is set (e.g. 'ANY_REGION', 'AWS_US'). Governance implication: data leaves the home region — know which value permits what. (Common trap question.)
• Guardrails — Cortex Guard filters unsafe LLM responses; enabled as an option on COMPLETE / AI_COMPLETE.
• Sensitive data management — AI_REDACT removes/masks PII before it reaches a model.
• Methods to reduce hallucinations and bias — grounding via RAG (Cortex Search), structured outputs, evaluation (see 3.4).
• REST API authentication methods — key-pair (JWT) auth and OAuth for calling Cortex REST APIs.

3.2 Grant and revoke RBAC and privileges

Roles (database roles in the SNOWFLAKE database — grant, don't recreate):

• SNOWFLAKE.CORTEX_USER — baseline role to call Cortex LLM functions (COMPLETE, EMBED, etc.). Granted by default to PUBLIC in many accounts; revoking it from PUBLIC is the standard lock-down move, then grant to specific roles.
• SNOWFLAKE.CORTEX_ANALYST_USER — Cortex Analyst.
• SNOWFLAKE.CORTEX_AGENT_USER — Cortex Agents.
• SNOWFLAKE.CORTEX_EMBED_USER — embedding functions.

Individual privileges — specific requirements differ per service (Analyst, Search, Agents, Snowflake Intelligence). Know that Cortex Search needs privileges on the search service object; Analyst needs access to the semantic view/model.

Pattern to memorize:

-- lock down, then grant deliberately
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER FROM ROLE PUBLIC;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE my_genai_role;

Application roles: privileges can also be granted on/revoked from APPLICATION ROLEs (Native Apps).

3.3 Manage, monitor, and optimize Cortex costs

Know which component drives cost (do not memorize prices):

• Cortex AI functions / Agents — billed by tokens. Minimize tokens; cap with token limits.
• Cortex Search — multiple cost types: virtual warehouse (indexing compute), EMBED_TEXT (embedding), serving, and indexing (storage of the index).
• Cortex Analyst — request-based.
• SPCS — billed via compute pools (track separately).

Usage-tracking views (ACCOUNT_USAGE / ORGANIZATION_USAGE) — recognize each by name:

• CORTEX_FUNCTIONS_USAGE_HISTORY / CORTEX_FUNCTIONS_QUERY_HISTORY — LLM function usage.
• CORTEX_ANALYST_USAGE_HISTORY
• CORTEX_AISQL_USAGE_HISTORY
• CORTEX_SEARCH_DAILY_USAGE_HISTORY
• CORTEX_REST_API_USAGE_HISTORY
• CORTEX_PROVISIONED_THROUGHPUT_USAGE_HISTORY
• METERING_DAILY_HISTORY / METERING_HISTORY — account-wide credit metering.
• Usage quotas to cap consumption; object tagging to attribute AI-service costs to teams.

3.4 Use Snowflake AI observability tools

• AI Observability features — evaluation metrics, comparisons (run vs run), tracing, logging, event tables.
• Implementation — the TruLens SDK is the supported path; observability surfaces in Snowsight. Evaluate Gen AI apps (RAG triad: context relevance, groundedness, answer relevance).
• Event tables capture traces/logs from Gen AI app runs for evaluation and debugging.

Highest-leverage governance facts (most-tested, per objective emphasis)

1. CORTEX_MODELS_ALLOWLIST (account param) is THE model-restriction lever — values + syntax.
2. The four SNOWFLAKE.CORTEX_*_USER database roles and what each unlocks.
3. Cross-region inference: the parameter, the values, and the data-residency implication.
4. Which billing component dominates for each service (tokens vs warehouse vs serving/indexing).
5. The *_USAGE_HISTORY view names — discrimination questions pair the wrong view with a service.
6. AI_REDACT for PII; Cortex Guard for unsafe-output filtering; TruLens for evaluation.

Hands-on to do before exam (in sandbox)

• REVOKE/GRANT SNOWFLAKE.CORTEX_USER and confirm a non-granted role gets denied.
• Set CORTEX_MODELS_ALLOWLIST to a single model; confirm a non-listed model errors.
• Query CORTEX_FUNCTIONS_USAGE_HISTORY and METERING_DAILY_HISTORY.
• Run AI_REDACT on sample PII text.
• (Optional) Stand up a minimal TruLens evaluation against a tiny RAG app.

Official study resources (from the C02 guide, Domain 3.0)

Overview of Access Control · Governance Overview · Control Model Access · Cortex LLM Allowlist · CORTEX_FUNCTIONS_USAGE_HISTORY · LLM Functions — Control Model Access / Required Privileges / Limiting Access to Specific Roles / Cortex Guard · Cortex Search — Costs / Cost Categories · Cortex Analyst — Required Privileges / Cost / Admin Observability · AI Observability — Key Concepts / Evaluation Metrics / Evaluate Gen AI Apps with TruLens (blog) · AI_REDACT / Redact PII · Snowflake Database Roles · GRANT/REVOKE on APPLICATION ROLE · RAG Triad Metrics (blog).