COF-C03 Question 335
Single answerDirect sharesA data provider wants to give a customer near real-time access to a curated set of reporting tables in Snowflake without copying the data. The customer should be able to query the shared objects using its own virtual warehouses, but the provider must ensure the customer cannot see any non-approved tables in the source database. Which action should the provider take to meet these requirements using a direct share?
- A
Create a secure data share, grant USAGE on the database and schema that contain the approved objects, grant SELECT on only the approved tables or secure views to the share, and then add the customer account to the share
- B
Create a database role for the customer, grant it SELECT on the approved tables, and then assign the role directly to the customer account so the customer can query the provider's database in place
- C
Unload the approved tables to an internal stage and grant the customer account READ privileges on the stage so the customer can query the staged files with its own warehouse
- D
Create a share on the entire database and rely on the customer to restrict access by granting privileges only to a limited set of its internal users
Show answer and explanation
Correct answer: A
Explanation
Direct shares in Snowflake are designed for provider-to-consumer data sharing without copying or moving data. The provider creates a share, grants privileges to that share on the relevant database, schema, and specific objects, and then adds one or more consumer accounts. The consumer creates a database from the share and queries the shared data using the consumer's own virtual warehouses, not the provider's compute. To limit visibility to only approved data, the provider should grant SELECT only on specific tables or secure views that are intended for sharing. This follows Snowflake best practices for least-privilege access and controlled data exposure. Relevant Snowflake documentation includes topics on data sharing, creating shares, granting privileges to shares, and consumer-created databases from shares.
- A. Correct.
Correct. A direct share lets a provider share live data without copying it. The provider creates a share, grants the necessary privileges on the database and schema, and grants SELECT on the specific objects to be shared. Then the provider adds the consumer account to the share. The consumer accesses the shared data using its own compute, which satisfies the requirement that the customer uses its own virtual warehouses. Granting object-level privileges ensures only approved tables or secure views are exposed.
- B. Incorrect.
Incorrect. Database roles cannot be assigned directly across accounts for standard direct sharing in this way. A consumer does not query the provider's database by receiving one of the provider's roles. Instead, the provider exposes objects through a share, and the consumer creates a read-only database from that share. This option reflects a common misconception between internal RBAC and cross-account data sharing.
- C. Incorrect.
Incorrect. Unloading data to a stage creates files rather than providing direct, live access to database objects. This introduces data movement and does not meet the requirement to avoid copying data. In addition, staged files are not queried through direct shares in the same way shared tables and views are.
- D. Incorrect.
Incorrect. Sharing the entire database would expose more metadata and objects than necessary, conflicting with the requirement to ensure the customer cannot see non-approved tables. In Snowflake sharing, access should be granted only to the specific approved objects. The provider, not the consumer, is responsible for controlling which shared objects are available.