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

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

Think first When you load or unload files, how do you choose between an internal stage, an external stage and an external table?

Why it matters: Questions describe a loading, unloading or stage access need and ask which command, option or limit applies to it.

Unloading writes table data out to flat files with COPY INTO a location. Internal stages live in Snowflake-managed storage, while external stages point to S3, Azure or GCS. External tables read files from external stages only, never from internal stages.

Term	Meaning
Unloading with COPY INTO	COPY INTO with a location as its target writes table data out to flat files.
Internal stage	Snowflake-managed storage: on AWS one S3 bucket per deployment, with a prefix for each account.
External table	A table over files in an S3, Azure or GCS stage; internal stages are not supported.
AUTO_REFRESH	An external table property that refreshes metadata through cloud storage event notifications.
Snowpipe Streaming channel	The channel through which the Snowpipe Streaming SDK sends unflushed data to the server for ingestion.

Unloaded files use gzip by default and always use UTF-8. You can unload to delimited files such as CSV or TSV, to JSON, or to Parquet; the default delimiter is a comma. Compression can be turned off or switched to another supported method. No other character set is supported.

Local unloads go through an internal location first. Files are written to a Snowflake internal location, and GET downloads them. Internal locations encrypt the files with 128-bit keys, and the downloaded copies are unencrypted. Files unloaded to cloud storage can be encrypted if you give Snowflake a security key.

Exam trap Files unloaded to an internal location are never left unencrypted there. Snowflake encrypts them automatically; only the downloaded copies are unencrypted.

Internal stages sit in Snowflake-managed cloud storage. On AWS, one S3 bucket serves each internal stage deployment, and a prefix keeps each account's data apart. On Azure, each account gets a dedicated storage account as its internal stage.

A system function, not a network policy, blocks public access. SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS blocks every public IP address; it cannot allow some and block others. SYSTEM$UNBLOCK_INTERNAL_STAGES_PUBLIC_ACCESS restores access. SYSTEM$INTERNAL_STAGES_PUBLIC_ACCESS_STATUS reports whether public IPs can reach the stage.

Exam trap The WITH_EXCEPTION variant, which allowlists specific IPs or CIDR blocks, works only on Azure, not on AWS or Google Cloud.

AWS PrivateLink to internal stages needs an account parameter. An account administrator sets ENABLE_INTERNAL_STAGES_PRIVATELINK to true. The VPC interface endpoint must be in the same AWS region as the account. On Azure, SYSTEM$AUTHORIZE_STAGE_PRIVATELINK_ACCESS authorizes a private endpoint.

External tables read files only from external stages. They read any format that COPY INTO can load except XML, and the default format type is CSV. Clustering keys, cloning and Time Travel are not supported. File format options on the stage are not inherited, so set them in the table definition.

Exam trap Do not rely on NOT NULL on an external table. Snowflake enforces no integrity constraints on external tables.

Metadata refreshes by event notification or by a manual REFRESH. The manual form is ALTER EXTERNAL TABLE … REFRESH. Automatic refresh is billed as Snowpipe charges. For a location with about 1 million files or more, set REFRESH_ON_CREATE = FALSE.

Exam trap GRANT OWNERSHIP on an external table or its parent database quietly sets AUTO_REFRESH to FALSE. AUTO_REFRESH = TRUE is also unsupported with PARTITION_TYPE = USER_SPECIFIED.

An external table query skips a file it cannot scan. Scanning continues with the next file. The Snowpipe Streaming SDK sends data to the server through a channel for ingestion. The SDK retries 5XX, 429 and 408 errors itself. A channel whose status is not SUCCESS must be closed and reopened explicitly. After a 401 or 403 error, fix the permission issue before reopening.

• Unloaded files are gzip-compressed by default and always encoded in UTF-8.
• External tables read only external stages and support neither XML, cloning nor Time Travel.
• SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS blocks all public IPs; a network policy is not used for this.
• GRANT OWNERSHIP on an external table turns its AUTO_REFRESH off.

Sources: Summary of Data Unloading Features | Snowflake Documentation · AWS VPC interface endpoints for internal stages | Snowflake Documentation · Azure private endpoints for internal stages | Snowflake Documentation · CREATE EXTERNAL TABLE | Snowflake Documentation · Introduction to external tables | Snowflake Documentation · Error handling in Snowpipe Streaming high-performance architecture | Snowflake Documentation · Refresh external tables automatically | Snowflake Documentation

Think first For a pipeline that must stay fresh on its own, when do you use dynamic tables, streams with tasks, or Snowpipe Streaming?

Why it matters: Questions describe an ingestion or pipeline need and ask which feature, setting, privilege or limit fits it.

A dynamic table materializes a SELECT query and keeps it fresh to a target lag. Streams and tasks give finer control, such as one-second schedules and multi-table writes. Snowpipe Streaming appends rows to tables through channels.

Term	Meaning
Dynamic table	A table that materializes a SELECT query and keeps it up to date to a target lag.
Target lag	A staleness goal for a dynamic table, not a refresh interval; the minimum is 60 seconds.
Stream	Tracks changes on a base table; a task can check it with SYSTEM$STREAM_HAS_DATA.
Named Channel	A Snowpipe Streaming channel that gives ordered, exactly-once ingestion.

Pick tasks for sub-minute timing or multi-table writes. Dynamic table definitions cannot use stored procedures or external functions. In a task, put SYSTEM$STREAM_HAS_DATA in the WHEN clause so the task runs only when the stream has unconsumed changes.

Dynamic tables compared with streams and tasks

Feature	Dynamic tables	Streams and tasks
Freshness floor	1 minute target lag	One-second task schedules
Outputs	Exactly one per dynamic table	One task can write many tables in one transaction
Change tracking	Built in on the base table	A stream you create on the base table

Target lag is a staleness goal, not a refresh interval. TARGET_LAG = '10 minutes' means data at most 10 minutes old. Actual lag can exceed it when refreshes run long. A downstream table's lag must be at least that of the table it reads from.

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

REFRESH_MODE = AUTO picks a mode once, at creation. It does not re-evaluate later. INTERSECT, EXCEPT and PERCENTILE_CONT need a full refresh. ADAPTIVE refreshes incrementally but reinitializes when a rebuild would be far cheaper. To switch modes, use CREATE OR ALTER or CREATE OR REPLACE, because ALTER DYNAMIC TABLE cannot.

Exam trap Snowflake never switches a dynamic table's refresh mode on its own, however much of the data changes. To change the mode, you recreate the table with CREATE OR ALTER or CREATE OR REPLACE.

Refresh results apply atomically, so readers never see partial data. If a refresh is still running, the next one waits instead of overlapping. ALTER DYNAMIC TABLE … REFRESH runs one now, and SCHEDULER = DISABLE leaves refreshes to an external orchestrator. Changing the warehouse or target lag does not reinitialize the table.

After 5 scheduled refresh failures in a row, a dynamic table suspends. Manual refresh errors do not count, and failures raise no alert by default. Suspending a table also suspends the dynamic tables downstream. Fixing the error is not enough: run ALTER DYNAMIC TABLE … RESUME.

Exam trap If an incremental dynamic table stays suspended past its base tables' Time Travel retention, change tracking data expires. The only fix is then to drop and recreate it.

Create the stream with ON DYNAMIC TABLE, not ON TABLE. ON TABLE returns an error here. APPEND_ONLY streams are not supported. Dynamic tables that use full refresh support no streams, because each refresh replaces the whole output.

Creating a dynamic table needs CREATE DYNAMIC TABLE on the schema. You also need USAGE on a warehouse and on the schema. Suspend, resume and alter need OWNERSHIP or OPERATE, while drop and undrop need OWNERSHIP.

The high-performance architecture requires a PIPE object. The SDK authenticates with key pairs and always uses UTC. InsertRows is now AppendRows, and ON_ERROR supports only CONTINUE. ARRAY and VARIANT columns need native objects, not strings.

High-performance Snowpipe Streaming limits

Limit	Value	Scope
Table throughput	20 GB/s uncompressed	Aggregate for one table
Named Channel throughput	20 MB/s uncompressed	Default for each channel
REST payload	4 MB	Hard cap per request
Active Named Channels	2,000	Default for one pipe

• Dynamic tables suit pipelines that can lag a minute or more; tasks handle sub-minute timing.
• Target lag is a staleness goal, and actual lag can exceed it.
• After 5 scheduled failures, a dynamic table suspends and must be resumed explicitly.
• High-performance Snowpipe Streaming needs a PIPE object and allows only ON_ERROR = CONTINUE.

Sources: Dynamic tables | Snowflake Documentation · Migrate from streams and tasks to dynamic tables | Snowflake Documentation · Tutorial: Get started with Named Channels using the SDK | Snowflake Documentation · Comparison between Named Channel and classic SDKs | Snowflake Documentation · Set the target lag for a dynamic table | Snowflake Documentation · Use streams on dynamic tables | Snowflake Documentation · Create a dynamic table | Snowflake Documentation · Dynamic table refresh modes | Snowflake Documentation

Think first When Snowflake must reach cloud storage, an external API or a streaming system, which integration or connector do you set up?

Why it matters: Questions describe a connection need and ask which integration type, privilege, parameter or connector limit applies.

Integrations are named account objects that hold access details, so you avoid passing explicit cloud credentials such as secret keys. Storage integrations serve external stages, while API, notification, catalog and external access integrations serve other services. Openflow connectors bring in data from systems such as Kafka, Kinesis and MySQL.

Term	Meaning
Storage integration	An object holding a generated IAM entity for S3, GCS or Azure, plus allowed or blocked locations.
STORAGE_ALLOWED_LOCATIONS	Limits which storage locations the stages using an integration can reference.
API integration	Holds details for services reached over HTTPS APIs, such as the cloud platform and credentials.
Openflow connector	A connector that moves data from a system such as Kafka, Kinesis or MySQL into Snowflake.

SHOW INTEGRATIONS can list just one integration type. Type filters include API, CATALOG, NOTIFICATION and STORAGE. Only ACCOUNTADMIN has CREATE INTEGRATION by default, but it can be granted to other roles.

What each integration type connects

Integration type	Connects Snowflake to	Holds
Storage	S3, Google Cloud Storage or Azure	An IAM entity and allowed or blocked locations
API	Services reached over HTTPS APIs	Cloud platform, service type and credentials
Notification	Message queues, email services and webhooks	An interface to third-party messaging
Catalog	Apache Iceberg tables	How the Iceberg table metadata is organized
External access	Specific external network locations	Network rules and credentials

A storage integration removes explicit cloud credentials from stages. One integration can serve many external stages, and each stage URL must fit STORAGE_ALLOWED_LOCATIONS. With the * wildcard, STORAGE_BLOCKED_LOCATIONS carves out exceptions. On AWS, all S3 storage integrations in an account share one IAM user. DESCRIBE INTEGRATION returns that user's ARN.

Exam trap Quote each blocked URL separately. Wrapping the whole STORAGE_BLOCKED_LOCATIONS value in quotes makes it invalid, and the setting is ignored.

Creating a stage with an integration needs USAGE on the integration. The role also needs CREATE STAGE on the schema. Loading or unloading through that stage needs only USAGE on the stage, not on the integration. Only an integration's owner can grant privileges on it.

CREATE OR REPLACE on a storage integration breaks its stages. Stages link to the integration by a hidden ID, not by name. Setting ENABLED = FALSE blocks new stages and cuts existing stages off from their storage location.

Exam trap Revoking cloud access does not stop Snowflake at once. Cached temporary credentials can keep working for up to 60 minutes.

On AWS, set the same external ID in two places. STORAGE_AWS_EXTERNAL_ID on the integration must match the external ID in the trust policy of the IAM role you set up for it. Location prefixes are s3 for public regions, s3gov for government regions and s3china for China. An Azure integration authenticates to one tenant, so all its storage accounts must belong to it. For government or cross-region China storage, use CREDENTIALS on CREATE STAGE instead.

SYSTEM$VALIDATE_STORAGE_INTEGRATION tests a path with real file actions. It can write, read, list or delete a file, or try all of them. The path must be in STORAGE_ALLOWED_LOCATIONS. Read fails if the file is missing, write fails if it already exists, and any failed action makes the status failure.

A system function finds integrations for a secrets provider. SYSTEM$GET_SECURITY_INTEGRATIONS_FOR_API_PROVIDER returns a JSON array of API_AUTHENTICATION integrations using WORKLOAD_IDENTITY_FEDERATION that your role can see. The provider is AWS_SECRETS_MANAGER, AZURE_KEY_VAULT or GCP_SECRET_MANAGER, in any case.

Openflow connectors ingest data from Kafka, Kinesis and MySQL. The Kafka connector writes topics into tables with Snowpipe Streaming High Performance. The MySQL connector soft-deletes rows through _SNOWFLAKE_DELETED. By default it replicates values up to 16 MB and fails a table on a larger value.

Kinesis and MySQL connector limits

Feature	Kinesis Data Streams	MySQL
Reads from	Only one stream per connector	MySQL or MariaDB
Scaling	No autoscaling	Single-node runtime: Min and Max nodes set to 1
Formats or login	JSON by default; Avro and Protobuf need extra setup	Username and password only

• Storage integrations let stages reach S3, GCS or Azure without explicit credentials.
• Creating a stage needs USAGE on the integration; using the stage needs only USAGE on the stage.
• CREATE OR REPLACE on a storage integration breaks the stages that reference it.
• Revoked cloud access can keep working for up to 60 minutes through cached credentials.

Sources: Option 1: Configure a Snowflake storage integration to access Amazon S3 | Snowflake Documentation · CREATE STORAGE INTEGRATION | Snowflake Documentation · Managing integrations in Snowsight | Snowflake Documentation · Managing Snowflake integrations with Python | Snowflake Documentation · Snowflake Openflow Connector for Kafka | Snowflake Documentation · Openflow Connector for Amazon Kinesis Data Streams | Snowflake Documentation · About Openflow Connector for MySQL | Snowflake Documentation · ALTER STORAGE INTEGRATION | Snowflake Documentation