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

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

Think first How do Time Travel, Fail-safe, cloning, sharing and replication each protect or share data, and when would you reach for each one?

Why it matters: Questions describe a recovery, sharing or disaster-recovery need and ask which feature, limit or command fits it.

Time Travel and Fail-safe protect an object's history, one after the other. Secure Data Sharing gives other accounts read-only access without copying data. Replication and failover keep copies in other accounts so you can switch over.

Every account gets 1 day of Time Travel by default. Permanent databases, schemas and tables can keep history for 0 to 90 days on Enterprise Edition and higher. You cannot turn Time Travel off for an account. An ACCOUNTADMIN can still set DATA_RETENTION_TIME_IN_DAYS to 0 at account level.

Exam trap Setting an object's retention to 0 does not always remove its history. If MIN_DATA_RETENTION_TIME_IN_DAYS is set on the account, the larger of the two values applies.

AT or BEFORE picks a point in time three ways. Use TIMESTAMP for a moment, OFFSET for a number of seconds back, or STATEMENT with a query ID. You can also clone an object as it was at that point. Such a clone leaves out external tables and internal stages.

Exam trap A historical clone of a schema will not bring back its internal stages or external tables; those object types are skipped.

Fail-safe adds 7 days that you cannot change. The window opens right after the Time Travel period ends. It exists for Snowflake to recover data lost in extreme operational failures. A recovery can take several hours or several days.

Time Travel and Fail-safe compared

Exam trap Fail-safe is not a self-service backup. You cannot recover from it yourself; only Snowflake uses it after extreme failures, and recovery is slow.

Sharing copies no data between accounts. Shared data adds nothing to the consumer's storage bill. The consumer pays only for the warehouses that query it. A consumer can accept many shares but creates just 1 database from each share. Creating a share needs ACCOUNTADMIN or the global CREATE SHARE privilege.

Exam trap Consumers cannot change shared objects. They cannot insert rows, modify tables or drop objects, because everything shared is read-only.

Share secure views or secure UDFs, not raw tables. Snowflake strongly recommends this so sensitive data stays hidden from consumer accounts. Before sharing, test what a consumer will see. Set the session parameter SIMULATED_DATA_SHARING_CONSUMER to that consumer's account, then query the secure view.

All changes run on the primary; secondaries are read-only. You can enable replication on any permanent or transient database, which makes it the primary. Secondary copies can live in other accounts of the same organization, in other regions or clouds. Each refresh brings a snapshot of data and DDL. With scheduled refreshes, a secondary lags at most 2x the refresh interval.

Stages, pipes and grants need account replication. Database replication copies data and object definitions, but some things stay behind. A database created from a share cannot be replicated at all. Replicating from Business Critical to a lower edition is blocked unless you add IGNORE EDITION CHECK.

Database replication and account replication compared

Exam trap A secondary database does not arrive with the primary's grants. Privileges on its objects, including future grants, are not copied with the data.

Run the promote command in the target account. Replication and failover groups copy a set of objects with point-in-time consistency. To fail over, a role with the FAILOVER privilege signs in to the target account. Snowflake blocks the promotion while a refresh is running. Client Redirect gives clients one connection URL that can point to another account.

Example: Promotes a secondary failover group to primary, run while signed in to the target account.

ALTER FAILOVER GROUP my_fg PRIMARY;

• PRIMARY: makes this target account serve as the source account

Exam trap Failover suspends scheduled refreshes on every secondary failover group. They stay off until RESUME runs in each target account.

• Time Travel defaults to 1 day and reaches 90 days for permanent objects; Fail-safe adds a fixed 7 days.
• Only Snowflake can recover data from Fail-safe, and it can take hours or days.
• Shared objects are read-only and cost the consumer only query compute.
• Database replication skips stages, pipes and grants; account replication covers them.
• After a failover, resume refreshes in each target account with ALTER FAILOVER GROUP … RESUME.

Sources: Understanding and viewing Fail-safe | Snowflake Documentation · About Secure Data Sharing | Snowflake Documentation · Introduction to business continuity & disaster recovery | Snowflake Documentation · Understanding & using Time Travel | Snowflake Documentation · Use secure objects to control data access | Snowflake Documentation · Introduction to database replication across multiple accounts | Snowflake Documentation · Failing over account objects | Snowflake Documentation

Think first When would a provider choose a direct share, a listing, a reader account or a clean room to share data?

Why it matters: Questions describe a sharing need and ask which account type, share method, privilege or limit applies to it.

A provider places database objects in a share, and consumer accounts in the same region query them. Reader accounts are consumers the provider creates and pays for. Listings reach other regions, and clean room partners return aggregated results without directly querying raw data.

A provider shares data with consumers through a share. The share is a named object that carries everything needed to expose a database. When the provider adds an object to the share, every consumer can use it at once.

Exam trap Adding a table to a share needs no refresh or new share: all consumers see it immediately.

Database roles let consumers give groups different subsets of a share. Without them, a consumer grants the single IMPORTED PRIVILEGES privilege, which opens every shared object. Direct grants can combine several databases, but only from one account. A shared database role takes no future grants.

Two ways to put objects into a share

Exam trap A share that spans several databases cannot use database roles, because a database role cannot receive the REFERENCE_USAGE privilege.

The provider creates, owns and pays for each reader account. Use ACCOUNTADMIN or a role with the global CREATE ACCOUNT privilege. A reader account can consume data only from the provider that created it. By default, a provider can create 75 reader accounts in total.

Example: Creates a reader account with its first administrator user.

USE ROLE ACCOUNTADMIN;
CREATE MANAGED ACCOUNT my_reader_acct
  ADMIN_NAME = my_admin,
  ADMIN_PASSWORD = 'my_password',
  TYPE = READER;

• TYPE = READER: makes the managed account a reader account

A new reader account has one admin user and no data. The admin creates a database from each share, and queries need a virtual warehouse. Its credits are billed to the provider with no monthly cap. Set a resource monitor to limit them.

Example: Turns a share from the provider into a database the reader account can query.

CREATE DATABASE my_shared_db
  FROM SHARE my_provider_acct.my_share;

Exam trap A reader account cannot load or change data: INSERT, UPDATE, DELETE, MERGE and COPY INTO <table> are not allowed there.

A direct share reaches only accounts in the same region. To reach another region or cloud platform, publish a listing that uses cross-cloud auto-fulfillment. Resharing works differently for the two methods.

Direct shares and listings compared

Exam trap A direct share cannot reach an account in another region, even on the same cloud platform. That consumer needs a listing with cross-cloud auto-fulfillment.

Collaborators return aggregated results but cannot query raw data directly. Each role has its own edition needs, and the party that runs an analysis pays for it. Trial accounts cannot use Snowflake Data Clean Rooms.

Exam trap Only data providers need Enterprise Edition. Standard Edition is enough for clean room owners and analysis runners.

• A direct share stays in one region; a listing that uses cross-cloud auto-fulfillment reaches other regions and clouds.
• The provider pays every reader account credit, so put a resource monitor on its warehouses.
• Reader accounts cannot load or change data with INSERT, UPDATE, DELETE, MERGE or COPY INTO <table>.
• Database roles split a share into subsets, but they cannot span databases or use future grants.
• Clean room partners can return aggregated results but cannot directly query the raw data, and the analysis runner pays for each analysis.

Sources: About Secure Data Sharing | Snowflake Documentation · Manage reader accounts | Snowflake Documentation · About Snowflake Data Clean Rooms | Snowflake Documentation · Share secure database objects | Snowflake Documentation · Configure a reader account | Snowflake Documentation · Using resharing as a provider | Snowflake Documentation · Overview of Snowflake Data Clean Rooms | Snowflake Documentation

Think first When would a provider share through a private listing instead of a public Snowflake Marketplace listing?

Why it matters: Questions describe a sharing goal and ask which listing type, app component or resharing rule fits it.

A listing shares an app with consumers, either free or paid. Marketplace listings reach many consumers at once, while private listings go to specific consumers. Consumers can discover and install Native Apps from either kind.

Marketplace listings reach many consumers; private ones target chosen accounts. One Marketplace listing replaces separate sharing relationships with each consumer. A private listing goes directly to a named account, in any region the Native App Framework supports. Consumers can discover and install apps from either kind.

Snowflake Marketplace and private listings compared

Exam trap A private listing is not limited to the provider's own region. It can reach accounts in any region the Native App Framework supports.

An application package needs a manifest file and a setup script. The package can also reference data content and external code files. Its logic can be a Streamlit app, stored procedures, or functions built with Snowpark API, JavaScript or SQL. On install, Snowflake creates the app object in the consumer account and runs the setup script.

The manifest must be named manifest.yml and sit at the stage root. Place it at the root of the directory on the named stage that holds the other app files. It points to the setup script, which runs on every install or upgrade. Using manifest_version: 2 turns on automated granting of privileges.

Exam trap The manifest file name is fixed. A file named manifest.yaml or app.yml does not meet the rule that it must be manifest.yml.

Consumers can limit which objects an installed app creates. They do this with feature policies. An optional marketplace.yml file declares needed resources, such as compute pools and external connections, and these show in the listing in Snowsight. An app with containers needs CREATE COMPUTE POOL unless the consumer creates the pool manually.

When a trial ends, Snowflake suspends the app unless the consumer converts it. Converting means moving the app to the full listing. Data written inside a suspended app is kept, as long as the consumer does not delete the app.

Exam trap A trial ending does not wipe the app's data. The data stays until the consumer deletes the app.

If the provider allows it, consumers can reshare incoming listings. They can reshare within one region or across regions. Resharing needs the same roles and privileges as creating a listing. The default enforcement mode is RESHARER, so governance policies are evaluated in the resharer's account.

Exam trap The provider does not pay when a resharer sends a listing to another region. Auto-fulfillment replication costs are charged to the resharer.

• Marketplace listings reach many consumers at once; private listings go to chosen accounts in any supported region.
• Every application package needs a setup script and a manifest.yml file at the stage root.
• An expired trial suspends the app but keeps its data until the consumer deletes the app.
• Cross-region reshares are paid for by the resharer, and policies default to the resharer's context.

Sources: About the Snowflake Native App Framework | Snowflake Documentation · Use and manage Snowflake Native Apps as a consumer | Snowflake Documentation · Resharing listings | Snowflake Documentation · Create the manifest file for an app | Snowflake Documentation · Specify the resources required by an app | Snowflake Documentation