Consuming Snowflake Shares, Reader Accounts and Data Clean Rooms

1.Importing and maintaining an inbound share

On the consumer side, a share becomes usable only when you create a database from it. This is the one CREATE DATABASE that stores nothing: the imported database is a read-only window onto the provider's data and takes no storage in your account. The role that runs the command needs the global CREATE DATABASE and IMPORT SHARE privileges. Each share can back only one database.

SHOW DATABASE ROLES in DATABASE c1;
GRANT DATABASE ROLE c1.r1 TO ROLE analyst;

How you grant access depends on how the provider built the share. If objects were granted directly to the share, you grant one privilege, IMPORTED PRIVILEGES, on the imported database. That is all or nothing: every holder sees every object. Only a role that owns the imported database, or holds MANAGE GRANTS, can grant it. If the provider used database roles, you grant each shared database role to the local roles that need it, which gives different groups different subsets of the data.

After import, consumers can create streams on shared tables or secure views, but only if the provider has turned on change tracking. A stream on shared data does not extend the provider's retention period, so consume the stream within that window. Direct shares can be reshared only within the consumer's organization. To reshare, build a secure view in your own database over the imported data, because objects from an imported database cannot be attached to a share directly.

Sources12

2.Reader accounts for consumers without Snowflake

Sharing works only between Snowflake accounts. For a consumer who has no account, the provider can create a reader account, also called a managed account. The provider creates, owns and pays for it, and the reader account can consume data only from that provider. It uses the provider's edition and region. Creating one requires ACCOUNTADMIN or a role with the global CREATE ACCOUNT privilege. ACCOUNTADMIN can delegate the task by granting CREATE ACCOUNT to a role such as SYSADMIN.

CREATE MANAGED ACCOUNT <account_name>
    ADMIN_NAME = <username> , ADMIN_PASSWORD = '<password>' ,
    TYPE =  ? ;

The command returns the account name and login URL. Wait up to five minutes for provisioning, then add the account to one or more shares and configure it. The documented user and role setup is limited to the administrator named in ADMIN_NAME/ADMIN_PASSWORD plus the instruction to configure the account. These sources give no further steps for users and roles inside a reader account.

Cost control is the provider's job. Reader-account warehouses can use unlimited credits, all billed to the provider. Set up a resource monitor on each warehouse to cap them. The sources say to do this but give no resource monitor syntax.

What users can do. Reader accounts are mainly for querying shared data. Users can still create objects, for example materialized views. They cannot load or change data: INSERT, UPDATE, DELETE, MERGE, COPY INTO <table>, CREATE STAGE, CREATE PIPE and CREATE SHARE are all blocked. Masking and row access policies cannot be created, and dynamic table refreshes fail. Reader-account users get no Snowflake support, so the provider answers their questions.

Lifecycle. A provider can have 75 reader accounts by default. List them with SHOW MANAGED ACCOUNTS, or query the READER_ACCOUNT_USAGE schema in the SNOWFLAKE database. DROP MANAGED ACCOUNT deletes everything in the account and cannot be undone. A dropped account still counts against the limit for 7 days.

Sources3

3.Snowflake Data Clean Rooms: install, users and collaborators

A clean room goes beyond a share. Collaborators can bring data together while the owner controls exactly which analyses can run against it. Joining is the first gate, and it depends on account type and edition. Owners and analysis runners need Standard Edition or higher. Data providers, and anyone activating data to another collaborator, need Enterprise Edition or higher. Reader accounts cannot install clean rooms at all.

Install the native app. As ACCOUNTADMIN, install the Snowflake Data Clean Rooms application from the Snowflake Marketplace. The installing user must have a first name, last name and verified email. Then open the app (Catalog » Apps » Snowflake Data Clean Rooms), choose Open in Worksheet, and run the script that installs the clean rooms API. The UI depends on this API too. Finally, check the mount:

USE ROLE SAMOOHA_APP_ROLE; USE WAREHOUSE app_wh; CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.LIBRARY.CHECK_MOUNT_STATUS();

Bring users in. Installation covers the whole account, but nobody gets access automatically. A clean rooms administrator must grant access explicitly, by granting roles to developers so they can work with clean room environments. Clean rooms can also be shared only within the same cloud region by default. To work with collaborators elsewhere, enable Cross-Cloud Auto-fulfillment for the account.

Manage collaborators. In the current collaboration model, each region has a Secure Collaboration Orchestrator (SCO) account. The owner's region decides which SCO runs a collaboration. For each collaboration, the SCO publishes an app package and a listing. Each collaborator installs SFDCR_collaboration_name from that listing. Collaborators then contribute data offerings, and the SCO enforces the collaboration definition: who can use which data with which templates, and what can be activated to whom. The older Provider/Consumer clean rooms UI, which is being discontinued, has an administrator add each collaborator under Collaborators with a company name, email, account locator, cloud and region. Only then can users share a clean room with that collaborator.

Sources456

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A consumer can create several databases from the same share to split access between teams.Why is that wrong?

   Only one database can be created per share. Splitting access between teams requires the provider to use database roles.

   Covered in Importing and maintaining an inbound share

2. 2.A reader account can also consume shares from other providers it does business with.Why is that wrong?

   A reader account is tied to the provider that created it and can consume only that provider's data.

   Covered in Reader accounts for consumers without Snowflake

3. 3.Once the clean rooms app is installed, every user in the account can use it.Why is that wrong?

   Installation covers the account, but a clean rooms administrator must still grant access to users explicitly.

   Covered in Snowflake Data Clean Rooms: install, users and collaborators

Practise it for real

Provision a reader account for a partner without Snowflake and give it access to an existing share

1. 1.As ACCOUNTADMIN, optionally run GRANT CREATE ACCOUNT ON ACCOUNT TO ROLE SYSADMIN; to delegate reader-account management.

   Why: Only ACCOUNTADMIN, or a role with the global CREATE ACCOUNT privilege, can create and manage reader accounts.

   You should see: SYSADMIN can now run CREATE MANAGED ACCOUNT.

2. 2.Run CREATE MANAGED ACCOUNT <account_name> ADMIN_NAME = <username> , ADMIN_PASSWORD = '<password>' , TYPE = READER;

   Why: Reader accounts are MANAGED ACCOUNT objects. The admin user will configure the account.

   You should see: A status row with accountName, accountLocator and the login url.

3. 3.Wait up to five minutes, then run SHOW MANAGED ACCOUNTS;

   Why: The account needs time to provision, and this command also tracks usage against the default limit of 75.

   You should see: The new reader account appears in the list.

4. 4.Add the reader account to an existing share with ALTER SHARE <share> ADD ACCOUNTS = <reader_account>;

   Why: Reader accounts receive data through shares, just like full consumer accounts.

   You should see: The share's consumer list (SHOW GRANTS OF SHARE) includes the reader account.

5. 5.Log in as the admin user, create a database from the share, and set up a resource monitor on the warehouse.

   Why: The share is usable only after import, and the provider is billed for every credit the reader's warehouses use.

   You should see: The reader can query the imported database, and warehouse credits are capped.