This domain is about 31% of the exam, roughly 31 of its 100 questions.

Every point below comes from Snowflake's official documentation; each section lists its sources.

Think first How do the storage, compute and cloud services layers split the work, and which edition do you need for a feature?

Why it matters: Questions describe a workload, cost or feature need and ask which layer handles it or which edition provides it.

Storage holds table data in micro-partitions, organized into databases and schemas. Compute runs on virtual warehouses and Snowflake-managed serverless resources. Cloud services handles metadata work, and each edition adds features on top of the one before.

Snowflake stores table data in micro-partitions. It clusters them by dimensions of the data. Each database belongs to one account and holds schemas, which group objects such as tables and views. There is no hard limit on databases, schemas or objects.

Exam trap Time Travel and Fail-safe both hold a table's historical data, but not as a full copy for every change. Full copies exist only when tables are dropped or truncated.

DATABASE_STORAGE_USAGE_HISTORY reports daily storage per database. It covers 365 days, with latency up to 3 hours. AVERAGE_DATABASE_BYTES includes Time Travel bytes, while AVERAGE_FAILSAFE_BYTES shows Fail-safe. For billed storage, use STORAGE_DAILY_HISTORY instead.

Compute cost has three parts. They are user-managed virtual warehouses, serverless features such as Automatic Clustering and Snowpipe, and the cloud services layer. METERING_DAILY_HISTORY shows how many compute credits were actually billed.

A Snowpark Container Services compute pool works much like a warehouse. Its name must be unique in the account. Choosing an instance family is like choosing a warehouse size, but billing follows the instance type actually provisioned on each node. Stop all running services before dropping a pool.

Exam trap Suspending a compute pool suspends every service on it except job services. Those keep running until they reach a final state, DONE or FAILED, and only then are the nodes released.

Metadata operations use only cloud services compute. These include DDL such as cloning, SHOW commands and Information Schema queries. Listing files during COPY also uses cloud services, so poorly selective COPY commands raise that usage.

Exam trap Cloud services usage is not always billed. It is charged only when daily use exceeds 10% of daily warehouse usage.

Each edition builds on the one before it. The edition also sets the unit cost of credits and storage. Needing Enterprise features, such as materialized views, raises the price of each credit.

What each edition adds

Iceberg tables use Snowflake storage or an external volume. With Snowflake storage, Snowflake stores and manages the table files, so you configure no cloud storage access.

Snowflake storage and external volumes for Iceberg tables

• DDL, cloning, SHOW and Information Schema queries use only cloud services compute.
• Cloud services are billed only above 10% of daily warehouse usage.
• Materialized views and search optimization need Enterprise Edition or higher.
• Automatic Clustering adds no storage, while materialized views and search optimization do.

Sources: Optimizing storage for performance | Snowflake Documentation · Database, schema, & share DDL | Snowflake Documentation · Exploring compute cost | Snowflake Documentation · Optimizing cloud services for cost | Snowflake Documentation · Snowflake editions | Snowflake Documentation · Snowpark Container Services: Working with compute pools | Snowflake Documentation · Storage costs for Time Travel and Fail-safe | Snowflake Documentation · Databases, Tables & Views | Snowflake Documentation

Think first When you work in Snowsight, what decides the role your code runs with, who sees your files and what costs credits?

Why it matters: Questions describe a Snowsight task and ask which role, privilege, limit or cost applies to it.

Workspaces is now the Snowsight editor, a file-based place for SQL and Python. Every worksheet or file runs with its own role context, separate from the role in your user menu. Running code, and some changes to results, uses warehouse credits.

Workspaces is the Snowsight editor now and cannot be turned off. It replaced Legacy Worksheets, reader accounts included. On first use, Snowflake creates a personal database that stores workspaces but holds no tables or views. Notebooks add cells for Python, SQL and Markdown. Workspace SQL commands run from any client, including SnowSQL and the Snowflake CLI.

Exam trap You cannot disable Workspaces or switch back to Legacy Worksheets, not even in a reader account.

My Workspace is private; shared workspaces are for teamwork. In SQL, My Workspace is named USER$.PUBLIC.DEFAULT$. Granting WRITE on a workspace also grants READ. ALTER WORKSPACE … COMMIT has no conflict protection, so it can overwrite files others changed recently.

Private and shared workspaces compared

Exam trap REMOVE does not wait for a commit the way PUT does: in a shared workspace the file disappears for everyone right away.

Each worksheet or file keeps its own role. Changing your active role in the user menu leaves a worksheet's role as it was. In Workspaces, a file's role selector affects only that file. The selector sets the primary role, so run USE SECONDARY ROLES to add secondary roles. Object creation always follows the primary role.

Exam trap Switching your active role in the user menu does not switch an open worksheet's role, because each worksheet has its own session.

A worksheet's context is saved and shared with all its users. Context means the role and warehouse the worksheet uses. Folders no longer carry a role, and a new worksheet in a folder gets your session's role. To resume or resize a warehouse from the context selector, you need MODIFY or OWNERSHIP on it.

Exam trap Not every user can resize or resume a warehouse from the context selector; it takes MODIFY or OWNERSHIP on that warehouse.

Running code uses credits, and so do some result changes. Sorting a result column applies to all results and is billed to the warehouse that ran the query. Formatting, such as thousands separators, percentages, decimal precision and dates, costs nothing. To find billed result changes, filter Query History for snowsight_transform_cte.

Exam trap Changing decimal precision or date format in results costs no compute, but sorting a column does.

Snowsight limits show up as exact numbers. Some query details, such as duration and data scanned, stay available for only 14 days. Snowflake does not limit the size of results you download as CSV or TSV.

Snowsight limits

Exam trap Accounts in U.S. government regions, on Virtual Private Snowflake (VPS) or using Private Connectivity still see query results capped at 10,000 rows.

Snowsight needs a supported browser and an allowed network path. It supports the latest three major versions of each supported browser. Behind a proxy or firewall, read the SNOWSIGHT_DEPLOYMENT entry from SYSTEM$ALLOWLIST. For private connectivity, an ACCOUNTADMIN calls SYSTEM$GET_PRIVATELINK_CONFIG. A user who dismisses MFA enrollment is asked again every three days.

Example: Lists the endpoints to allow, including the SNOWSIGHT_DEPLOYMENT entry for Snowsight.

SELECT SYSTEM$ALLOWLIST();

Snowsight manages policies, roles and security checks. Masking policies secure columns, row access policies filter rows, and the Trust Center evaluates account security. Catalog » Explorer shows only objects your active role holds at least USAGE on. Warehouses now sit under Compute » Warehouses, and an X-Small warehouse generally serves features like Data Preview.

• Workspaces replaced Legacy Worksheets and cannot be disabled.
• A worksheet keeps its own role; the role in your user menu does not change it.
• Object creation uses only your primary role, even with secondary roles active.
• Sorting results costs compute, while formatting results does not.
• In a shared workspace, PUT needs a commit, but REMOVE publishes at once.

Sources: Workspaces | Snowflake Documentation · Snowsight quick tour | Snowflake Documentation · Work with worksheets in Snowsight | Snowflake Documentation · Querying data using worksheets | Snowflake Documentation · Workspace operations using SQL | Snowflake Documentation · Getting started with Snowsight | Snowflake Documentation · Snowsight navigation menu | Snowflake Documentation · Explore and manage database objects in Snowsight | Snowflake Documentation

Think first How do you tell which Snowflake object or hierarchy level handles a task, such as creating accounts, returning a value, or replicating files?

Why it matters: Questions describe a task or a limit and ask which object type, or which level of the hierarchy, applies to it.

An organization sits at the top and holds accounts. Each account keeps its own users, roles, databases and warehouses. Object types then differ by job: a file format helps load and unload data, while a stored procedure runs SQL statements for administrative work.

One organization account sits above the regular accounts. Each account still has its own users, roles, databases and warehouses. Usage in every account lands on a single bill. Administrators use the GLOBALORGADMIN role in the organization account; using ORGADMIN in an ORGADMIN-enabled account is being phased out.

Exam trap You cannot convert an existing ORGADMIN-enabled account into the organization account. An organization has only one organization account.

The organization administrator picks the cloud, region and edition. The region must already be enabled for the organization. The first user you name gets the ACCOUNTADMIN role. By default an organization can hold 25 On Demand accounts, or 100 with a capacity contract. Allow about 30 seconds for DNS before you connect.

A UDF returns a value; a stored procedure performs operations. Choose a stored procedure for administrative work through SQL statements. Choose a UDF when a query needs a value back. UDF handlers can be written in Java, JavaScript, Python, Scala, or SQL and Snowflake Scripting.

How UDFs and stored procedures differ

Exam trap A procedure that returns nothing still needs a RETURNS clause in its CREATE PROCEDURE statement.

External stage files are not copied by replication. Primary and secondary databases point to the same cloud storage URL for an external stage. A directory table is an option you enable on the stage itself. A named internal stage can have its files replicated, but only when that option is enabled on it.

Exam trap Do not expect files on a user stage, a table stage or an external stage to replicate. A named internal stage replicates its files only with a directory table enabled on it.

The FILE_FORMATS view lists file format objects. Its latency can reach 120 minutes. It does not recognize the MANAGE GRANTS privilege, so a SHOW command run by a holder of that privilege may show more.

Custom session attributes cannot change once set. They last for the whole session, and their names are case-sensitive, so app_context and APP_CONTEXT differ. Any user can read attributes from their own session without special privileges. SYS_CONTEXT returns a VARCHAR, or NULL when the attribute was never set.

Exam trap An owner's rights stored procedure can call SYS_CONTEXT with the SNOWFLAKE$SESSION namespace only if the owner role holds READ SESSION on the account.

Organization administrators change editions with ALTER ACCOUNT. The command accepts STANDARD, ENTERPRISE or BUSINESS_CRITICAL; VPS needs Snowflake Support. Before a downgrade, stop using features unique to the higher edition, such as masking policies. You cannot downgrade within the same day as a change.

Exam trap Reader accounts and other managed accounts cannot use ALTER ACCOUNT ... SET EDITION. Snowflake Support changes their edition.

• An organization has one organization account, where GLOBALORGADMIN handles organization-level tasks.
• One SQL statement can call many UDFs but only one stored procedure.
• User, table and external stage files are not replicated, and a stage needs a directory table enabled for its files to replicate.
• Custom session attributes are immutable and last for the whole session.

Sources: Organization accounts | Snowflake Documentation · Creating an account | Snowflake Documentation · FILE_FORMATS view | Snowflake Documentation · Choosing whether to write a stored procedure or a user-defined function | Snowflake Documentation · Stage, pipe, and load history replication | Snowflake Documentation · SYS_CONTEXT (SNOWFLAKE$SESSION_ATTRIBUTES namespace) | Snowflake Documentation · SYS_CONTEXT (SNOWFLAKE$SESSION namespace) | Snowflake Documentation · Working with account editions | Snowflake Documentation

Think first How do you configure a warehouse for a workload: a bigger size, more clusters, another type, or a different auto-suspend?

Why it matters: Questions describe a workload and ask which warehouse type, size, scaling policy or setting fits it.

Resizing helps slow, complex queries and large loads, while adding clusters helps concurrency. The warehouse type sets memory per node and, for standard warehouses, the generation. Auto-suspend trades saved credits against a warm cache.

Size up for complex queries; scale out for concurrency. Multi-cluster warehouses do little for slow queries or data loading, where resizing helps more. Resizing a running warehouse does not affect queries already running. Resizing a suspended one provisions nothing until it resumes.

Exam trap A bigger warehouse is rarely needed just to load data. Unless hundreds or thousands of files load at once, Small, Medium or Large is usually enough.

Each larger size doubles credit usage. Snowflake bills by the second, but every start costs at least 60 seconds. Consumption is still reported in hourly increments. Add WAIT_FOR_COMPLETION to ALTER WAREHOUSE to confirm that a resize is fully provisioned.

Standard, the default policy, starts clusters to avoid queuing. Auto-scale mode runs when the minimum and maximum cluster counts differ; equal counts mean Maximized mode. A single-cluster warehouse always has 1 for both counts.

Standard and Economy scaling policies

Exam trap An underused multi-cluster warehouse wastes credits through its minimum cluster count. Lower MIN_CLUSTER_COUNT to cut that waste.

Snowpark-optimized warehouses suit memory-heavy or CPU-specific code. ML training in a stored procedure is a typical case. The default gives 16x memory per node, with resource constraint MEMORY_16X. Other values include MEMORY_1X and MEMORY_64X, each also offered as an x86 variant.

Exam trap The Gen1 or Gen2 setting applies only to standard warehouses, never to Snowpark-optimized ones.

A standard warehouse can switch between Gen1 and Gen2. The switch works whether the warehouse is running or suspended. Gen2 is not offered in every region, or in sizes X5LARGE and X6LARGE. Set the GENERATION clause with SQL, because Snowsight does not offer it. A new Gen2 warehouse turns on the Query Acceleration Service, which eases the impact of outlier queries. Converting from Gen1 leaves it unchanged.

Exam trap Converting a running Gen1 warehouse lets existing queries finish on Gen1 while new ones use Gen2. You pay for both sets of compute meanwhile.

MAX_CONCURRENCY_LEVEL defaults to 8. Lowering it can speed up large, complex or multi-statement queries, but test the change first. It can also put more queries in the queue. STATEMENT_QUEUED_TIMEOUT_IN_SECONDS cancels queued queries instead of letting them wait a long time.

Auto-suspend is on by default. AUTO_SUSPEND is a number of seconds, and null means never suspend. Snowflake suggests a low value, such as 5 or 10 minutes or less. Suspending drops the data cache, so the first queries after a resume can be slower.

Separate warehouses keep workloads such as analytics and ETL apart. For example, finance and engineering can each use their own Adaptive Warehouse. Adaptive Warehouses need Enterprise Edition or higher. Interactive warehouses are a separate type to consider when dashboards, applications or other user-facing queries need very low latency.

• Size up for complex queries and big loads; add clusters for concurrency.
• Each larger size doubles credits, billed per second with a 60-second minimum.
• Economy starts a cluster only for at least 6 minutes of load; Standard favors less queuing.
• Snowpark-optimized warehouses give 16x memory per node by default.

Sources: Working with warehouses | Snowflake Documentation · Multi-cluster warehouses | Snowflake Documentation · Snowpark-optimized warehouses | Snowflake Documentation · Snowflake generation 2 standard warehouses | Snowflake Documentation · Warehouse considerations | Snowflake Documentation · SHOW WAREHOUSES | Snowflake Documentation · Adaptive Compute | Snowflake Documentation · Overview of warehouses | Snowflake Documentation

Think first How do you pick the right table or view type for a workload, and when is a clustering key worth its cost?

Why it matters: Questions describe a data, freshness or sharing need and ask which table type, view type or clustering choice fits it.

Snowflake splits every table into compressed micro-partitions on its own, in load order. Table types differ in lifetime, recovery and where files live, while view types trade speed for security. A clustering key regroups rows into new micro-partitions, at a credit and storage cost.

Every table is split into micro-partitions automatically. Snowflake partitions rows in the order they are inserted or loaded. Each micro-partition holds 50 MB to 500 MB of uncompressed data, yet storage is always compressed. Snowflake will not prune (skip) micro-partitions for a filter built on a subquery, even one returning a constant.

Exam trap A subquery that returns a constant does not help pruning: Snowflake never prunes micro-partitions on a predicate that contains a subquery.

Smaller average clustering depth means a better clustered table. Monitor clustering with SYSTEM$CLUSTERING_DEPTH or SYSTEM$CLUSTERING_INFORMATION. In a multi-column key, order columns from lowest to highest cardinality. For a very high-cardinality column, such as a timestamp, cluster on an expression like a cast to a date.

Exam trap Putting the highest-cardinality column first is backward: the general rule orders key columns from lowest to highest cardinality.

Automatic Clustering spends credits but needs no warehouse of yours. It never blocks DML. Reclustering writes new micro-partitions but keeps the old ones, so storage can grow. They stay for Fail-safe and for Time Travel, a table's retention period for past data. A suspended table is not reclustered or charged. Optima Clustering bills on uncompressed data ingested. Changing a key with ALTER TABLE does not move a table to Optima, and no migrate command exists.

Clustering Classic and Optima Clustering compared

Exam trap A resource monitor cannot cap Automatic Clustering credits; it does not control the Snowflake-provided AUTOMATIC_CLUSTERING warehouse.

A clone copies the clustering key; CTAS does not. After a clone, Automatic Clustering is suspended until you resume it. A new key leaves existing rows alone until Snowflake reclusters. Hybrid tables cannot have a clustering key at all.

What happens to a clustering key

Exam trap A cloned table is not reclustered on its own: the key comes along, but Automatic Clustering stays suspended until you resume it.

Lifetime and Fail-safe set the three native table types apart. Permanent tables keep 0 to 90 days of Time Travel on Enterprise Edition and higher. A temporary table is seen only by its session and overrides a same-named table in that schema. Tables in a transient schema or database are transient, and a transient table can never change type.

Native table types compared

Exam trap You cannot shorten or switch off Fail-safe on any table type; to avoid it, create the table as transient from the start.

External tables are read-only; Iceberg tables choose who stores files. You can query, join and build views on an external table, but not run DML on it. Its queries may be slower than native tables, and a materialized view can help. With Snowflake storage, Snowflake manages Iceberg data and metadata files and gives permanent Iceberg tables Fail-safe. An external Iceberg catalog requires external volume storage.

Exam trap An external table takes no INSERT, UPDATE or DELETE: it is read-only, though queries, joins and views on it still work.

A dynamic table keeps a query's results fresh within a target lag. Target lag caps staleness; it is not a schedule. A lag of 10 minutes means data at most 10 minutes old. The minimum is 60 seconds, and the definition cannot use stored procedures or external functions. With TARGET_LAG = DOWNSTREAM, it refreshes only when a downstream dynamic table triggers it.

Exam trap A DOWNSTREAM dynamic table with no downstream consumers never refreshes on its own, and Snowflake gives no warning.

Materialized views read one table; secure views hide their definition. A materialized view cannot join, not even to itself. Only the owning role sees a secure view's definition, and Query Profile hides its internals even from the owner. Secure views can run slower, so use them to protect data. In shares, CURRENT_ROLE and CURRENT_USER return NULL; test with SIMULATED_DATA_SHARING_CONSUMER.

Example: Turns an existing view into a secure view.

ALTER VIEW my_view SET SECURE;

• SET SECURE: UNSET SECURE turns it back into a regular view

Exam trap Sharing tables directly is not the safe choice; Snowflake strongly recommends sharing secure views or secure UDFs instead.

• Micro-partitioning is automatic and follows load order, at 50 MB to 500 MB uncompressed each.
• Transient tables skip Fail-safe and can never be converted to another table type.
• Automatic Clustering bills credits without your warehouse, and resource monitors cannot cap it.
• Target lag sets maximum staleness, and 60 seconds is the lowest it goes.
• Secure views show their definition only to the owning role, hide internals in Query Profile, and can run slower.

Sources: Micro-partitions & Data Clustering | Snowflake Documentation · Working with Temporary and Transient Tables | Snowflake Documentation · Working with Secure Views | Snowflake Documentation · Clustering Keys & Clustered Tables | Snowflake Documentation · Automatic Clustering | Snowflake Documentation · Storage for Apache Iceberg™ tables | Snowflake Documentation · Set the target lag for a dynamic table | Snowflake Documentation · Introduction to external tables | Snowflake Documentation

Think first When a workload needs generated text, fuzzy search over documents, or answers from business data, which Cortex feature fits it?

Why it matters: Questions describe an AI need and ask which Cortex function, service option, limit or cost applies to it.

In Cortex, SENTIMENT scores text from -1 to 1, and CLASSIFY_TEXT returns an object whose label names a category. COMPLETE is a legacy function; new work starts with AI_COMPLETE. Cortex Search gives fuzzy search over text, and Cortex Analyst works from a semantic model stored in a stage file or a semantic view.

COMPLETE keeps no state between calls. For a conversation, pass every earlier prompt and response, so tokens and cost grow each round. Only one system prompt is allowed, and it must come first. Calling it needs a role granted SNOWFLAKE.CORTEX_USER.

Exam trap COMPLETE does not remember the previous call. If the history is not in the prompt array, the model sees only the new prompt.

TRY_COMPLETE returns NULL where COMPLETE raises an error. Start new work with AI_COMPLETE instead. In COMPLETE, temperature defaults to 0, and max_tokens defaults to 4096 with a maximum of 8192. The guardrails option, which uses Cortex Guard, defaults to FALSE.

COMPLETE and TRY_COMPLETE side by side

SENTIMENT returns a score from -1 to 1. Near 1 is positive, near -1 negative, and near 0 neutral. The score shows polarity and certainty, not intensity. CLASSIFY_TEXT takes 2 to 100 unique categories and returns an object whose label field names the category.

Exam trap CLASSIFY_TEXT input is case sensitive, so the same text in different capitals can get different results. Category descriptions and examples also count as input tokens.

PARSE_DOCUMENT defaults to OCR mode. The output is a JSON-formatted string, so convert it with PARSE_JSON before using it as an OBJECT. The page_split option defaults to FALSE and works only for PDF, .pptx and .docx files.

The two PARSE_DOCUMENT modes

The service's warehouse builds and refreshes the search index. TARGET_LAG caps how far the content may trail the base tables. The default refresh mode is INCREMENTAL, which needs change tracking on all underlying objects. The default embedding model is snowflake-arctic-embed-m-v1.5.

Exam trap A search service keeps adding storage and compute costs. AUTO_SUSPEND is disabled by default, and its minimum is 1800 seconds.

Filters work only on the ATTRIBUTES columns named at creation. Operators are @eq, @contains, @gte, @lte and @primarykey, combined with @and, @or and @not. Without a limit, a query returns at most 10 results. SEARCH_PREVIEW truncates results over 300 kB; the REST surface allows 10 MB.

Exam trap Do not serve a low-latency end-user app with SEARCH_PREVIEW. It is meant for testing and is slower than the REST or Python APIs.

Batch search runs on its own serverless compute. That compute scales apart from interactive search traffic. For fewer than 2,000 queries, the interactive API is usually faster.

Cortex Analyst is billed by the number of messages processed. CORTEX_ANALYST_USAGE_HISTORY shows its credits in one-hour increments for the last 365 days. For a dimension with about 1 to 10 values, list sample values. Above 10 values, or for changing values, use a Cortex Search Service.

• Use AI_COMPLETE for new work; COMPLETE and TRY_COMPLETE are legacy functions.
• COMPLETE keeps no state, so conversations resend the full history and cost more each round.
• Cortex Search filters apply only to ATTRIBUTES columns, and queries return 10 results by default.
• Cortex Analyst credits depend on the number of messages processed.

Sources: COMPLETE (SNOWFLAKE.CORTEX) | Snowflake Documentation · SENTIMENT (SNOWFLAKE.CORTEX) | Snowflake Documentation · CLASSIFY_TEXT (SNOWFLAKE.CORTEX) | Snowflake Documentation · Improve literal search to enhance Cortex Analyst responses | Snowflake Documentation · CORTEX_ANALYST_REQUESTS_V view | Snowflake Documentation · CREATE CORTEX SEARCH SERVICE | Snowflake Documentation · TRY_COMPLETE (SNOWFLAKE.CORTEX) | Snowflake Documentation · PARSE_DOCUMENT (SNOWFLAKE.CORTEX) | Snowflake Documentation