Figures below are taken from Snowflake documentation topics linked in Official resources and the edition matrix. Snowflake changes limits and editions over time—re-verify before your exam. “✔” in edition tables means the feature is included per intro-editions.
Encryption & transport
Value / rule
What to remember
AES-256 (platform)
All customer data at rest is encrypted with Snowflake-managed keys; trust/compliance collateral often states AES-256 for at-rest layers—confirm wording in Encryption key management and End-to-end encryption.
AES-128 / 256 client-side stage keys
Client-side encryption on external stages: MASTER_KEY must be a 128-bit or 256-bit AES key (Base64-encoded) per Encryption overview.
TLS in transit
Clients ↔ Snowflake use TLS for all supported connectors/drivers (not a numeric limit, but often paired with encryption questions).
30 days
Snowflake-managed key hierarchy: account master keys and table master keys (and other keys in that hierarchy) are automatically rotated when more than 30 days old—active keys retire, new keys encrypt new data; retired keys decrypt old data until destroyed. Encryption key management (“Encryption key rotation”). Do not confuse with optional periodic data rekeying (retired key > ~1 year, Enterprise)—different lifecycle step.
Time Travel & Fail-safe
Value
Source / meaning
1 day (24 hours)
Default Time Travel retention for all accounts; Standard can set DATA_RETENTION_TIME_IN_DAYS to 0 or default 1. Time Travel.
0–90 days
Enterprise+: permanent databases/schemas/tables can set TT up to 90 days (extra storage cost). Same doc.
7 days
Fail-safe is a non-configurable recovery window that starts after Time Travel ends; Snowflake docs describe 7 days for this Fail-safe period. Not for user SELECT. Fail-safe.
Long TT queries
A long-running Time Travel query delays moving data into Fail-safe until it completes (both TT and Fail-safe docs).
Result cache & persisted results
Value
What to remember
24 hours
Persisted query results (retrieval optimization cache) expire after 24 hours from last criteria—see Using persisted query results.
31 days ceiling
Each successful reuse of the same cached result can extend retention up to a maximum of 31 days from when the query was first executed—then the result is purged.
6 hours token
For persisted results > 100 KB, the access token expires after 6 hours (new token while still in cache). Smaller results skip the token pattern.
Spark connector
Spark connector token exception: 24 hours regardless of result size (same persisted-results topic).
Semi-structured & row size
Limit
Current documentation
128 MB (uncompressed)
A single VARIANT (and OBJECT / theoretical ARRAY payload) can be up to 128 MB of uncompressed data; practical maximum is slightly lower due to overhead. Semi-structured types.
16 MB (row vs VARIANT)
Do not confuse VARIANT element size with whole-row width: Snowflake enforces a maximum compressed row size per table row (commonly cited around 16 MB in limit summaries—confirm the current CREATE TABLE / general constraints topic in the SQL reference for the exact byte cap).
Credits & warehouses
Value
Meaning
10%
Cloud services credits are charged only if daily cloud-services usage exceeds 10% of that day’s virtual warehouse credit usage; otherwise the daily cloud-services portion in that band is covered. Credits / Compute cost.
60 seconds
Warehouse billing uses a minimum 60 seconds per resume/provisioning episode (per-second metering with one-minute floor)—see warehouse / compute pricing documentation.
60 (auto-suspend)
New warehouses often default AUTO_SUSPEND to 60 seconds—always confirm in UI or SHOW PARAMETERS for your account.
Snowpipe & metadata windows
Window
Use case
~14 days
PIPE_USAGE_HISTORY via Information Schema — short rolling history (commonly 14 days in exam context). Contrast with ACCOUNT_USAGE (≈365 days).
Transcribed from Snowflake editions (feature tables). S = Standard, E = Enterprise, BC = Business Critical, VPS = Virtual Private Snowflake. Empty = not listed for that edition in the source table. For the narrative list of “notable features” (not every feature), see Overview of key features. Edition also affects credit and storage unit pricing.
Edition tiers (summary)
Edition
Positioning (docs)
Standard
Introductory offering; full standard Snowflake features; balance of features, support, and cost.
Enterprise
Everything in Standard plus enterprise-scale features (extended TT, multi-cluster WH, MVs, masking/RAP, etc.).
Business Critical
Everything in Enterprise plus highest data-protection tier (e.g. HIPAA/HITRUST positioning), Tri-Secret Secure, private connectivity patterns, account failover/failback.
VPS
Highest isolation: separate Snowflake environment; hardware not shared with non-VPS accounts; includes BC-level features.
Release management
Feature
S
E
BC
VPS
24-hour early access to weekly new releases (pre-prod validation)
✔
✔
✔
Security, governance, data protection
Feature
S
E
BC
VPS
SOC 2 Type II
✔
✔
✔
✔
Federated authentication & SSO
✔
✔
✔
✔
OAuth
✔
✔
✔
✔
Network policies (IP allow/deny for users)
✔
✔
✔
✔
Automatic encryption of all data
✔
✔
✔
✔
MFA support
✔
✔
✔
✔
Object-level access control (RBAC)
✔
✔
✔
✔
Standard Time Travel (up to 1 day)
✔
✔
✔
✔
Object tags (some advanced tagging features E+)
✔
✔
✔
✔
Fail-safe (7-day DR after TT)
✔
✔
✔
✔
Generating synthetic data
✔
✔
✔
Extended Time Travel (up to 90 days)
✔
✔
✔
Periodic rekeying of encrypted data
✔
✔
✔
Column-level security (masking policies)
✔
✔
✔
Row-level security (row access policies)
✔
✔
✔
Aggregation policies
✔
✔
✔
Projection policies
✔
✔
✔
Differential privacy
✔
✔
✔
Classification (sensitive data discovery)
✔
✔
✔
ACCESS_HISTORY (Account Usage)
✔
✔
✔
Associate event table with objects (logging/tracing)
Warehouses are account-level objects; grants use GRANT … ON WAREHOUSE w … TO ROLE | USER …. Wording follows Access control privileges (warehouse)—confirm exact behavior for your release.
Privilege
What it allows (exam shorthand)
USAGE
Run queries using the warehouse when it is already in a runnable state—not the right to start/stop/suspend/resume or reconfigure it.
OPERATE
Change the warehouse run state: start, stop, suspend, resume (and related state operations per docs).
MODIFY
Alter warehouse properties (e.g. size, scaling parameters, timeouts)—not the same privilege as OPERATE; some ALTER WAREHOUSE actions map to one or the other per SQL reference.
MONITOR
View usage and performance metrics for the warehouse without needing full admin on the object.
Loading & unloading
Topic
Cheat sheet
File sizing (bulk + Snowpipe)
Snowflake recommends staging files around 100–250 MB compressed (or larger) so the warehouse can exploit parallelism without per-file overhead dominating; aggregate tiny files, split only truly huge files (e.g. avoid single 100 GB files without care). See Preparing your data files. Not a goal to keep all files ~25 MB.
Delimited / numeric hygiene
For CSV-style loads: fields with delimiter characters must be quoted; rows should have consistent column counts. For numbers: avoid embedded characters such as commas in numeric fields (e.g. use 123456 not 123,456) unless properly handled—same doc topic.
Dates & timestamps
Do not strip temporal columns—use supported input formats and valid values (invalid dates error at load). See Date and time formats in SQL reference.
Semi-structured
Keep VARIANT/JSON etc. when that is your model; Snowflake is built for semi-structured—removing it is not a load “best practice.”
Stages
Internal (Snowflake) vs external (S3/GCS/Azure); URL + creds for external.
PUT
Client uploads files to user stage / named stage (SnowSQL).
COPY INTO
Server-side load from stage into table; requires running warehouse.
File formats
Named FILE FORMAT (CSV JSON PARQUET AVRO ORC XML); TYPE + options.
COPY INTO @stage from query/table; export to cloud files.
Metadata cols
$METADATA$FILENAME, $METADATA$FILE_ROW_NUMBER, etc. for staged files (pattern awareness).
Snowpipe
Serverless or pipe-driven loads; event notifications vs REST ingest; auto-ingest from cloud.
Pipe load history
PIPE_USAGE_HISTORY in Information Schema exposes a short rolling window (commonly 14 days) of pipe activity. ACCOUNT_USAGE.PIPE_USAGE_HISTORY / similar views retain much longer (often ~1 year)—exam questions may test which interface you use. CREATE OR REPLACE PIPE can reset pipe-local metadata—see Managing Snowpipe.
Directory table
Stage directory listing as table for discovery/pipelines.
FILE FORMAT — JSON & CSV (named FILE FORMAT options)
Defined in CREATE FILE FORMAT. Values differ by TYPE; below are common SnowPro-level knobs.
Option / area
TYPE = JSON
TYPE = CSV
STRIP_OUTER_ARRAY
When TRUE, removes the outer JSON array wrapper so each element of the array becomes its own row (classic pattern for [{...},{...}] files). When FALSE, the whole document loads as one row per file (unless other layout rules apply).
— (JSON only)
STRIP_NULL_VALUES
Omit object keys / array slots whose value is JSON null (reduces noise; affects VARIANT materialization).
—
IGNORE_UTF8_ERRORS
Replace invalid UTF-8 sequences instead of erroring (use cautiously).
Same idea for text encoding issues where supported.
ALLOW_DUPLICATE_ELEMENT_NAMES / ENABLE_OCTAL
Parser leniency / duplicate keys—know they exist; defaults are usually strict enough for exams.
—
COMPRESSION, BINARY_FORMAT
How input bytes are decoded (AUTO, GZIP, etc.).
Compression for delimited files.
FIELD_DELIMITER, RECORD_DELIMITER
—
Column vs row terminators (comma tab pipe, \n/\r\n, etc.).
FIELD_OPTIONALLY_ENCLOSED_BY, ESCAPE
—
Quotes / escape rules for fields containing delimiters.
SKIP_HEADER, TRIM_SPACE, NULL_IF
—
Header rows, whitespace trimming, sentinel strings to SQL NULL.
ERROR_ON_COLUMN_COUNT_MISMATCH
—
Whether extra/missing columns vs table abort the load.
VALIDATION_MODE + COPY
Used on COPY INTO (not only CSV): RETURN_n_ROWS / RETURN_ERRORS / RETURN_ALL_ERRORS to validate without committing (or partial commit per mode)—pair with ON_ERROR for production loads.
Semi-structured data
Topic
Cheat sheet
VARIANT
Stores JSON-like documents; max compressed size per cell (know docs limits for exam).
Flatten
LATERAL FLATTEN(input => v, path => '...') for arrays/objects.
Typing
:: VARCHAR, AS <type>, semi-structured path notation x:key[0].
Optimization
Materialized views / clustering (where applicable); avoid exploding VARIANT in wide joins without pruning.
Extract VARIANT paths to typed columns for clustering/pruning where possible.
PARSE_JSON · TO_JSON · CHECK_JSON vs FLATTEN (exam disambiguation)
Same section, different jobs: scalars that change or check one value vs a table function that multiplies rows. Docs: PARSE_JSON, TO_JSON, CHECK_JSON, FLATTEN.
API
Role in one sentence
Returns / shape
PARSE_JSON / TRY_PARSE_JSON
Turn a JSON text string into a nested VARIANT you can query with : / bracket paths. TRY_ returns NULL on bad JSON instead of erroring.
Scalar → one VARIANT per input row.
TO_JSON
Serialize a VARIANT (or compatible value) to a VARCHAR containing JSON text—export, logging, round-trip out of Snowflake.
Scalar → one JSON string per input row.
CHECK_JSON
Validate formatting: returns NULL if the expression is valid JSON (or NULL); returns an error message string (e.g. position of bad token) if invalid. Use for QC; use PARSE_JSON when you need the actual VARIANT tree.
Scalar → NULL or error-description string.
FLATTEN
Unnest arrays/objects inside an existing VARIANT into many output rows (one per element at the chosen path). Almost always LATERAL FLATTEN(input => col, path => '…') next to a driving table.
Table function → extra rows + KEY, PATH, INDEX, VALUE, …
Each row is one exploded element. Names match the FLATTEN table function.
Column
Role
SEQ
Monotonic sequence number for rows produced by this FLATTEN invocation (unique within the result).
KEY
Key name when exploding an OBJECT (may be NULL for array-only paths).
PATH
Path string to the element within the nested structure.
INDEX
Zero-based index when the parent is an ARRAY (otherwise can be NULL).
VALUE
The value at that path (often still VARIANT-typed until cast).
THIS
The “current” enclosing object/array fragment for that row (context for nested FLATTEN).
Time Travel, Fail-safe, zero-copy clone
Topic
Cheat sheet
Time Travel (tables)
For permanent, transient, and temporarytables (and other objects where TT applies), query historical row versions with AT / BEFORE (timestamp, offset, or statement id) within DATA_RETENTION_TIME_IN_DAYS. Same ideas apply to some other table-like objects per docs—always read the stem (external tables differ).
Retention
Edition-dependent max retention on tables (database/schema defaults or per-table); 0 disables TT where allowed.
Fail-safe
Non-user-accessible recovery period after Time Travel ends (not for user queries).
What gets Fail-safe?
Permanent tables (and similar persisted Snowflake storage) go through TT then Fail-safe. Materialized views persist derived data in Snowflake and are treated like tables for CDP in this sense. Transient and temporary tables do not use Fail-safe. External tables point at files outside Snowflake-managed table storage—do not expect the same Fail-safe story for that external payload. Confirm wording in Fail-safe + Materialized views.
Snowflake encrypts customer data at rest by default (including files on internal stages); not something you “opt in” with extra DDL for the baseline platform model.
Master key rotation (managed hierarchy)
Account and table master keys (Snowflake-managed hierarchy) rotate automatically when older than 30 days—classic MCQ: pick 30 days, not 90/365. See Encryption key management. Periodic rekeying of data with retired keys (> 1 year) is a separate, optional Enterprise topic.
Fail-safe
Additional Snowflake-managed recovery period after Time Travel expires on eligible permanent tables—not end-user queryable like TT; duration is platform-defined (often discussed as 7 days in training materials where Fail-safe applies—confirm for your edition).
Time Travel
Part of the CDP story, but extending retention beyond defaults (or up to edition max) is configuration (e.g., table/database parameters). Default TT exists at allowed levels; longer retention is not “zero config” everywhere.
Network / Tri-Secret Secure
Additional hardening layers exist but are separate from “automatic encryption + Fail-safe” CDP baseline.
Storage vs virtual warehouse vs cloud services / serverless
Snowflake separates where bytes live from who runs the CPUs. Exam questions often want you to pick two or three billing knobs—not everything is “just the warehouse.”
Three meters (memorize)
Meter
What it is
Typical trigger
Storage
Active table/stage bytes + Time Travel + Fail-safe where they apply (per TB-day style pricing).
Customer-sized query / load compute you turn on (XS…6XL); credits accrue while clusters run (plus minimum billable seconds on resume—see numbers sheet).
SELECT, most DML, COPY INTO while a WH is running, tasks pinned to a WH.
Cloud services (CS)
Control-plane work: auth, metadata, query parsing / planning—often compared to WH credits for the 10% daily adjustment rule.
Every session uses some CS; large overages when lots of planning/metadata vs little warehouse use that day.
Serverless / feature compute
Separate credit lines for managed features (not “your” named WH)—still not storage.
Snowpipe load service, automatic MV maintenance, automatic clustering, serverless tasks (where offered), search optimization build—verify each in current pricing/docs.
Legend for the next table: Y = materially yes, — = negligible or “not that meter,” (WH) = when a session runs SQL on a warehouse, (Svr) = serverless / background feature credits, (CS) = cloud-services style usage (may fall inside the daily 10% allowance vs warehouse).
Object / activity
Storage
Warehouse compute
Cloud services / serverless
Table (permanent / transient) — row storage
Y
(WH) for queries & DML you run
Y if clustering key → automatic reclustering work; else mostly planning (CS).
Materialized view
Y (persisted results)
(WH) when users SELECT it
(Svr) background maintenance / refresh when base data changes—classic “storage + non-WH compute” combo.
View / secure view
— (definition only)
(WH) when queried
(CS) planning; no extra stored rows for the view itself.
Sequence
Tiny metadata
—
—
Internal stage (files)
Y
(WH) for LIST/COPY / transforms you run
—
Snowpipe loading into table
Y once landed in table
Not the pipe’s server workers
(Svr) Snowpipe compute metering (separate from named WH).
Stream (CDC offset)
Small
(WH) when consumed in downstream DML you run
—
Task (user-managed)
—
Y on the WH you assign
—
Task (serverless, where available)
—
—
(Svr)
Search optimization on a table
Y (auxiliary structures)
(WH) queries can benefit
(Svr) build / maintain index.
External tables: storage of the files stays in your cloud object store (you pay the cloud vendor); Snowflake charges for metadata and query compute (WH) when you scan through Snowflake—read External tables + pricing pages. For “choose two” MCQs (e.g. MV + clustered table), map answers to storage + background serverless/CS work, not only “I ran a SELECT.”
Each day, a slice of cloud services usage is covered when it stays within 10% of warehouse compute credits used that day—no separate line item for that allowance portion.
Billable cloud services
If cloud services credits exceed 10% of the day’s warehouse compute credits, you pay for the overage (cloud services minus the 10% allowance).
Quick math
Warehouse day = 50 credits → allowance = 5 cloud-service credits “free”; 10 cloud-service credits → bill 5 overage. Warehouse day = 200 → allowance 20; 26 cloud-service → bill 6 overage.
Source
Snowflake states cloud services are charged only if daily cloud services usage exceeds 10% of daily warehouse usage—see Understanding compute cost (and parent credits overview).
Security, RBAC & DAC
Topic
Cheat sheet
RBAC vs DAC (how Snowflake mixes them)
RBAC: you grant privileges to roles (most common), then grant roles to users (or other roles); sessions use USE ROLE. Snowflake SQL also supports GRANT … TO USER … for many privileges—same privilege (e.g. MODIFY, SELECT) can be granted to either a role or a user; docs/examples may show either form. DAC-style piece: each object has an owner role; that owner (or admin) controls GRANT/REVOKE on that object. Exams often stress RBAC; know DAC wording maps to ownership + grants, not a separate product.
Roles & grant targets
Role hierarchy: GRANT ROLE child TO ROLE parent; users activate grants via GRANT ROLE r TO USER u. For object privileges use GRANT … ON <object> TO ROLE nameorTO USER name per privilege rules in the SQL reference—do not assume “roles only” in stems that show TO USER.
ACCOUNTADMIN
Powerful account-level role—use sparingly per best practice.
Generic “any database” rules mislead you—always align with Materialized views + CREATE MATERIALIZED VIEW for your release.
Theme
Typical constraint / tradeoff
Single-table lineage
Classic Snowflake MVs center on one base table with an aggregate SELECT pattern; broad multi-table join MVs are not the default pattern you should assume on Core.
Disallowed / restricted SQL
Many constructs are rejected or limited—examples often tested: window functions, ORDER BY, HAVING, certain joins/subqueries/UDFs depending on syntax—validate against current SQL reference.
External tables
Historically not a supported base for classic materialized views—treat “MV on external table” as false unless docs explicitly allow your pattern.
Maintenance cost
High churn on the base table increases background maintenance work—can hurt credits and latency.
Staleness
MV is maintained asynchronously; readers can see slightly stale results vs live base table during refresh windows.
Secure MV
Secure materialized views are not supported (pair with secure non-materialized views for sharing).
Performance & optimization
Pruning: filter on clustering / natural micro-partition columns first.
Result cache: identical query text + warehouse within 24h window (know current doc details).
Materialized views: maintained results for expensive aggregations (constraints apply).
Search optimization service (SOS): auxiliary indexes for selective point lookups. To add or remove search optimization on a table, Snowflake requires bothOWNERSHIP on the table and the ADD SEARCH OPTIMIZATION privilege on the parent schema. Grant the schema privilege with current syntax, e.g. GRANT ADD SEARCH OPTIMIZATION ON SCHEMA s TO ROLE analystor… TO USER jane—both grant targets are valid where the privilege allows. Having only MODIFY on the table (whether granted to a role or to a user), only SELECT, or relying on SECURITYADMIN alone does not replace the required OWNERSHIP + ADD SEARCH OPTIMIZATION pair—see Search Optimization Service (access control section). Behavior for DROP SEARCH OPTIMIZATION was tightened in bundle BCR-1046.
Clustering depth / average depth in SYSTEM$CLUSTERING_INFORMATION — tune keys when pruning weak.
Query acceleration (warehouse): result set reuse for repeated patterns (feature awareness).
Query tag: QUERY_TAG session parameter for workload attribution in ACCOUNT_USAGE.
Object privileges such as SELECT, INSERT, MODIFY, DELETE, etc., can be granted to a role or directly to a user when the privilege supports it—check the SQL reference for each privilege. Best practice for humans is still “privileges on roles, roles on users,” but exam wording may use either grantee.
Transactions
DML auto-commit per statement unless explicit transaction commands used.
CTAS / CLONE
CREATE TABLE AS SELECT; CREATE TABLE x CLONE y.
MERGE
Upsert pattern WHEN MATCHED / WHEN NOT MATCHED.
Streams
CDC offset on table (at-least-once semantics awareness).
RESULT_SCAN
Query prior query results via RESULT_SCAN(LAST_QUERY_ID()).
Sequences
NEXTVAL / sequences in inserts (ordering not guaranteed across parallel inserts).
UNDROP — object recovery (grace periods)
Snowflake extends undrop beyond tables; exact object types and roles evolve—read UNDROP <object> in the SQL reference. Below is the usual Core-level mental model.
Object / scope
Notes
Database
UNDROP DATABASE restores DB and contained schemas/objects within the undrop window.
Schema
UNDROP SCHEMA restores schema and contained objects.
Table
UNDROP TABLE for standard tables; Snowflake documents additional forms for Dynamic Tables and Iceberg tables—use the specific UNDROP variant from docs.
Dropped account
Organization-level restore of a dropped account inside a grace period, typically requiring ORGADMIN (not a normal ACCOUNTADMIN-only flow).
Other types
Platform adds undrop / restore coverage for more objects over time (e.g., tags, notebooks, external volumes in newer docs)—skim release notes + SQL reference before the exam.
Streams & Tasks (overview)
Stream: tracks changes (inserts/updates/deletes) for downstream incremental processing.
Task: scheduled SQL with optional dependency graph (DAG); runs with specified warehouse or serverless task (where available).
Common pattern: Task consumes stream to merge deltas into reporting table.
Stream offset: consume with DML then stream advances; stale stream if base table recreated/truncated (awareness).
Task graph: AFTER for dependencies; SCHEDULE or CRON; USER_TASK_TIMEOUT_MS; suspend on error patterns.
Serverless task: warehouse-less execution where offered (billing model differs).
Data sharing & listings
Topic
Exam-relevant notes
Outbound share
Provider account creates SHARE, adds secure objects, grants to consumer listing or account.
Inbound share
Consumer sees share; creates database FROM SHARE to mount objects read-only.
No bulk copy
Shared data stays in provider storage; consumer gets access path—not a physical “transfer” of bytes to consumer tables.
CREATE DATABASE … FROM SHARE
After creation, roles with IMPORTED PRIVILEGES (or grants) can query shared objects through that database.
Reader accounts
Provider-managed login for external consumers without their own Snowflake contract (pattern awareness).
Listings
Data Exchange / marketplace: monetized or governed discovery vs private direct share between accounts.
Standard (free) listing
Dataset/product discoverable with immediate access pattern where provider allows open consumption (no private approval loop).
Personalized / private listing
Consumer often must request access; provider approves or provisions a tailored entitlement.
Limited trial
Time-boxed access (e.g. subset of data or full product for 1–90 day-style trials—exact terms on listing).
Paid / subscription
Commercial terms: subscription or usage-based billing for premium datasets (still no bulk copy to consumer storage by default).
Re-share
Generally consumers cannot re-share provider objects unless explicitly allowed by provider policies (default deny mindset).
Secure objects
Shares often expose secure views rather than base tables to hide structure and enforce row filters.
Secure views & sharing patterns
Topic
Notes
Purpose
Prevent consumers from inferring underlying data via non-secure view optimizations (e.g., predicate pushdown leakage).
vs standard view
Standard views may expose more in plans/metadata; secure views add guardrails for shared consumption.
Performance
Secure views may not use all the same internal optimizations as standard views—expect tradeoffs.
Materialized
Pattern to remember: secure materialized views are not supported (use standard MV patterns outside secure-sharing constraints).
Profiler / plan
For secure views, Snowflake may limit sensitive details in query profile/plan views to reduce inference—treat as “less detail than standard.”
Discovery
IS_SECURE in INFORMATION_SCHEMA.VIEWS / SHOW VIEWS — you can tell if a view is secure.
DDL visibility
View text for secure views may be restricted for non-owners vs standard views—do not assume full text is always visible to all roles.
External functions & UDFs
Type
Notes
External function
Invokes remote HTTPS service (e.g., API Gateway + Lambda) — code runs outside Snowflake process boundary.
SQL UDF
In-database; RETURN expression; IMMUTABLE / VOLATILE hints matter for optimization.
JavaScript UDF
Runs in Snowflake sandbox; CALLBACK_URL not for arbitrary outbound in same way as external function.
Java / Python UDFs
Feature availability by edition/region—Core often tests “what runs where” conceptually.
External table
Files in stage; REFRESH to pick up new files; partition columns from path/metadata.
Tags, policies, governance
Topic
Notes
GRANT grantees
Many DDL grants accept TO ROLE nameorTO USER name (including privileges like MODIFY where documented). Prefer roles for operational scale; read the stem literally if it names a user grantee.
Object tagging
TAG + SET TAG on columns/tables for lineage, cost allocation, classification.
Masking policy
Attached to column; varies output by role/context without changing stored values.
Row access policy
Predicate evaluated per query to filter rows.
Classification
Integration with tagging for sensitive data discovery (awareness).
Replication, costs, limits (awareness)
Replication / failover groups: cross-region account object replication; promotion for DR (feature set by edition).
Storage billing: active storage + Time Travel + Fail-safe (where applicable); cloning dedupes until divergence.
Pipe credits: Snowpipe compute billed separately from named warehouse in serverless model.
LIMITS: identifier length, max columns, stage file sizes—skim current docs for “gotcha” numeric limits if your employer tests minutiae.
Which schema for metering / history? (exam pattern)
There is no standard Snowflake schema named WAREHOUSE_USAGE_SCHEMA—warehouse history is usually queried from SNOWFLAKE.ACCOUNT_USAGE views (e.g. query/warehouse metering views per current docs). Always read the question: retention window, account type, and privilege matter.
Schema / database
Typical use
INFORMATION_SCHEMA
Per-database metadata and short-window history functions/views (e.g. recent pipe usage ~14 days—confirm docs). Lower latency than ACCOUNT_USAGE for many patterns.
SNOWFLAKE.ACCOUNT_USAGE
Account-wide audit views: query history, copy history, pipe usage, warehouse load/metering, etc., usually with longer retention (often on the order of a year for many views) and latency (data can appear after a delay—see each view’s doc).
SNOWFLAKE.READER_ACCOUNT_USAGE
Same idea as account usage but for reader accounts (provider-created consumer accounts)—use when the stem says “reader account” or usage inside that account type.
SNOWFLAKE.ORGANIZATION_USAGE (not in your A–D list)
Org-wide views (multiple accounts); requires org-level access. Often paired with ORGADMIN style questions.
One question at a time — use Prev / Next, the dropdown, or ←→ while focus is inside this gray practice box. Click Reveal answer for the keyed choice(s) and rationale. Items marked Choose two use multi-select scoring in your head. Content is original study material, not third-party dumps. Deep link: #practice-q-7 opens question 7. Cert readiness still needs Snowflake docs, labs, and official prep.
Practice capture workflow
After each study topic or any shared question you can answer confidently, add 1–3 relevant MCQs to this page’s MCQS list in the same session. If the answer is uncertain, verify in Snowflake docs first, then add. Skip verbatim third-party exam dumps; keep items original and aligned with official docs.