Articles · Snowflake

Snowflake Data Sharing Interview Questions: Provider Grants, Consumer Roles, and Reader Accounts

Practice Snowflake data sharing interview questions with provider grants, imported privileges, consumer database roles, reader-account costs, and regions.

Snowflake data sharing interview questions often start with “the share exists, but the analyst cannot query it.” That sentence leaves several possibilities open. The provider may have omitted an object, the consumer may not have imported the share, the analyst may lack the relevant role, or the query may have no usable warehouse.

A strong answer traces the entire entitlement chain. This guide follows an original same-region orders share, distinguishes direct object grants from shared database roles, and then considers reader accounts and cross-region delivery. Official Snowflake behavior is linked at first use. The SQL is source-reviewed preparation material; the local checks model permissions and arithmetic, not an executed Snowflake account. Start with Implement a Snowflake Query Client to practice connecting session context with query outcomes.

What Does Secure Data Sharing Share?

Official behavior: Snowflake's Secure Data Sharing overview explains that same-region sharing uses services-layer metadata rather than copying data into each consumer account. Shared objects are read-only to consumers. A standard consumer uses its compute to query the imported data; the shared data does not become consumer storage charged as its own copy.

This differs from exporting a daily file. If a provider changes an underlying shared table, the consumer is querying shared data rather than yesterday's independently loaded extract. It also differs from transferring ownership: the consumer cannot update the provider's shared orders table.

Interview reasoning: begin by establishing whether the prompt concerns a direct share, a listing, a reader account, or a replicated cross-region arrangement. “No copy” is an appropriate explanation of the basic same-region mechanism, but it is incomplete as a description of every delivery architecture.

Our exercise uses provider database PARTNER_DATA, schema PUBLIC, and table ORDERS. The intended consumer is clientorg.analytics. The consumer chooses its own imported database name, VENDOR_ORDERS. Naming those objects avoids treating the provider database and consumer database as the same identifier.

Build the Provider Side Before Debugging the Consumer

Official behavior: provider setup guidance distinguishes granting object privileges directly to a share from granting database roles to a share. In the direct-grant path, the provider supplies database and schema usage plus select access to the intended object, then authorizes the receiving account.

For our hypothetical setup, use a provider role with the required sharing privileges:

-- Provider account; database, schema and table already exist.
CREATE SHARE orders_s;
GRANT USAGE ON DATABASE PARTNER_DATA TO SHARE orders_s;
GRANT USAGE ON SCHEMA PARTNER_DATA.PUBLIC TO SHARE orders_s;
GRANT SELECT ON TABLE PARTNER_DATA.PUBLIC.ORDERS TO SHARE orders_s;
ALTER SHARE orders_s ADD ACCOUNTS = clientorg.analytics;
SHOW GRANTS TO SHARE orders_s;
SHOW GRANTS OF SHARE orders_s;

The first SHOW inspects what the share can expose; the second helps inspect the receiving-account relationship. Read the returned records instead of assuming a successful CREATE SHARE supplied both objects and consumers.

Official boundary: the grant-to-share reference states that future grants cannot automatically add future objects to a share. A new RETURNS table is not included merely because it was created in a schema already used by the share. Sharing imported objects onward is also restricted; do not propose reshare grants as if the consumer owned the provider's data.

Preparation advice: validate the object contract before making a share available. Suppose ORDERS contains internal risk notes that the consumer must not receive. Selecting the whole table is the wrong exposure decision even if the syntax works. A deliberately designed secure view can publish approved fields, but its definition and any account-dependent filtering still need review. “Secure” in the object name is not evidence that the chosen columns meet the business requirement.

Importing the Share Does Not Grant Every Analyst Access

Official behavior: the CREATE DATABASE reference supports creating a database from a share. Use the actual provider account and share identifier visible to the consumer, not the consumer account added in the provider command.

-- Consumer account; importer has the required privileges.
SHOW SHARES;
CREATE DATABASE VENDOR_ORDERS FROM SHARE provider_account.orders_s;
GRANT IMPORTED PRIVILEGES ON DATABASE VENDOR_ORDERS TO ROLE analyst;
GRANT USAGE ON WAREHOUSE ANALYST_WH TO ROLE analyst;

Replace provider_account.orders_s with the inbound identifier from the account's actual share information. The roles and warehouse in this exercise must already exist. Production execution also requires the appropriate administrative privileges; these statements are not a suggestion to give all analysts an administrator role.

Official behavior: consumer guidance distinguishes the role allowed to import a share from roles allowed to query its imported objects. Creating the database requires the relevant global privileges, including CREATE DATABASE and IMPORT SHARE. For objects directly granted to a share, a local role receives IMPORTED PRIVILEGES on the imported database.

If an administrator can run the query and an analyst cannot, investigate the analyst's effective role and grants first. Recreating the provider share is a large change that may not address the missing local permission. Conversely, granting a consumer role cannot expose an object the provider never included.

For this direct-grant exercise, imported privileges cover the directly shared object set; they are not per-table filtering knobs. If finance and operations should see different objects, explain how the provider exposure model must support that split.

When Do Shared Database Roles Change the Answer?

Official behavior: the provider setup documentation describes database roles as a way to segment shared objects. On the consumer side, account roles receive the relevant database roles from the imported database. GRANT DATABASE ROLE is distinct from assigning a normal account role to a user.

Original alternative: imagine the provider exposes an orders summary through PARTNER_DATA.finance_r and operational status through PARTNER_DATA.ops_r. After importing this different share, the consumer can assign those database roles deliberately:

-- Alternative: provider shared database roles, not just direct grants.
SHOW DATABASE ROLES IN DATABASE VENDOR_ORDERS;
GRANT DATABASE ROLE VENDOR_ORDERS.finance_r TO ROLE finance_analyst;
GRANT DATABASE ROLE VENDOR_ORDERS.ops_r TO ROLE operations_analyst;

The local database prefix is VENDOR_ORDERS, even though the provider created the roles inside PARTNER_DATA. Confirm the names actually exposed in the imported database. A typo in that prefix is an identity problem, not a reason to increase privileges broadly.

Consumer account role	Finance summary	Operational status	Intended explanation
finance_analyst	Yes	No	Receives finance_r only
operations_analyst	No	Yes	Receives ops_r only
combined_review	Yes	Yes	Receives both database roles
unrelated_user	No	No	Receives neither

This matrix is our desired test fixture, not an automatically enforced organization policy. Role inheritance or additional grants can change effective access. Test both expected access and expected denial with the intended execution identity, and inspect additional privilege paths if a negative test unexpectedly succeeds.

Also keep the two grant mechanisms explicit. A share can contain database-role grants and direct object grants. Imported privileges and shared database roles then cover different parts of the exposed set; one shorthand does not describe every object.

Diagnose a Failure With a Condition Ledger

Original troubleshooting exercise: assume no additional grant paths and a correctly named query. Test one missing condition at a time.

Missing condition	Observation to investigate	Repair boundary
Provider object grant	ORDERS was omitted from the shared set	Provider grants
Receiving account	Intended account is absent from share recipients	Provider account authorization
Imported database	Share is available but VENDOR_ORDERS was not created	Consumer import setup
Analyst entitlement	Importer can query; intended analyst cannot	Consumer role grants
Usable compute	Object access is correct, but the query cannot use its warehouse	Warehouse access and operation

Do not treat this as an exact error-message classifier. Snowflake can deliberately make authorization failures resemble missing objects, and one deployment can have several missing conditions. Record the active account, role, database, schema, warehouse, query text, and error before selecting a repair.

Our local model makes query readiness the conjunction of these five conditions. It passes when all are true and fails when any one is removed. That establishes the reasoning of this simplified exercise, not Snowflake's internal authorization algorithm or runtime error strings.

A follow-up can introduce an object rename. The role may retain the intended entitlement while the consumer's SQL still references the old name. Add an identity check rather than forcing every failure into the permission ledger. A good debugging answer can revise its initial hypothesis when the evidence changes.

Who Pays for a Reader Account?

Official behavior: reader-account guidance describes accounts created, owned, and managed by the provider for consumers who are not already Snowflake customers. A reader account consumes data from the provider that created it. The provider is responsible for the reader account's credit charges.

It is therefore wrong to explain a reader account as simply a free consumer warehouse. The consumer may not have a direct Snowflake billing relationship, but compute consumption still has an owner. Reader accounts also have restrictions on loading and modifying data; they are not interchangeable with a standard consumer's general-purpose account.

Official setup: the reader configuration guide includes creating warehouses, importing shares, assigning database and warehouse access, and optional resource monitors. It recommends appropriate warehouse sizing and auto-suspend to manage consumption.

Original arithmetic: suppose a hypothetical reader warehouse consumes 2 credits per active hour and runs for 3 hours. Its modeled consumption is 6 credits, charged to the provider's responsibility. Two such readers consume 12 credits under the same assumptions. This is not a price quote or a prediction of an actual warehouse bill; it simply demonstrates why the operating model needs cost controls.

Ask who can start or resize the warehouse, what usage limits trigger notification or suspension, and who supports the reader's users. A missing imported privilege and an exhausted compute allowance require different conversations even if both prevent useful querying.

What Changes Across Regions and After Revocation?

Official behavior: Snowflake's cross-region sharing guide describes replicating databases and shares to a provider account in the receiving region. Listings can use Cross-Cloud Auto-fulfillment for delivery to other regions. Choose the actual distribution mechanism before discussing freshness and cost.

Original freshness trace: the source commits order O9 at 10:02. A hypothetical scheduled refresh completes at 10:05, and the receiving-region consumer queries at 10:03. Its absence from the receiving copy can be a delivery-lag observation rather than missing permission. The same query after the successful refresh should be compared with source and refresh timestamps.

Those times are illustrative, not a Snowflake latency guarantee. Record the last successful refresh and the relevant object version before concluding that data disappeared. A successful source query does not prove that a remote consumer is reading the same refreshed state.

Design reasoning: revoking future access and undoing prior disclosure are different requirements. Removing access to the share cannot retroactively erase results the consumer already exported or stored elsewhere. Define the authorized object set, revocation verification, and downstream retention obligations separately. The share is an access mechanism, not proof of deletion throughout another organization's systems.

Practice Explaining the Entitlement Chain

Question	What to rehearse
Implement a Snowflake Query Client	Track account and session context before interpreting a failure
Design an RBAC Relational Schema	Distinguish principals, roles, grants, and inherited access
Design an access control system (RBAC + resource-based)	Explain an effective permission path and an expected denial
Design a compliant multi-tenant analytics platform	Preserve consumer boundaries and clarify data exposure
Design a Data Service for Downstream Consumers	Define delivery freshness, ownership, and revocation evidence

Use the access-control exercise to draw the provider-to-consumer path. Then remove one grant and explain what evidence would locate that failure without granting everything to everyone.