COF-C03 Question 336
Single answerDirect sharesA data provider uses a Snowflake direct share to give an external customer read-only access to a curated SALES database. After the share is created, the provider adds USAGE on the database and schema, and SELECT on several tables to the share. When the customer creates a database from the share, they can query the tables successfully. Later, the provider adds a new secure view to the shared schema, but the customer cannot see or query it from the shared database. What should the provider do to make the new secure view available through the existing direct share?
- A
Grant SELECT on the new secure view to the existing share
- B
Recreate the consumer database from the share so metadata is refreshed
- C
Grant OWNERSHIP on the secure view to the share
- D
Clone the schema into a new database and share the clone instead
Show answer and explanation
Correct answer: A
Explanation
Direct shares in Snowflake expose specific database objects to consumers in a read-only manner. After creating a share, the provider must grant USAGE on the database and schema and grant object-level privileges, such as SELECT on tables or secure views, to the share. Adding a new object later does not automatically make it visible to consumers; the new object must also be granted to the existing share. This is a common operational scenario in provider-consumer sharing models. Snowflake documentation on secure data sharing and shares explains that providers manage access by granting privileges on supported objects to the share, and consumers access those objects through a database created from that share.
- A. Correct.
Correct. In a direct share, new objects are not automatically available just because the database and schema are already shared. The provider must explicitly grant the appropriate privilege on the new object to the share. For a secure view, that means granting SELECT on the view to the share, assuming the required USAGE privileges on the database and schema are already in place.
- B. Incorrect.
Incorrect. Consumers do not need to recreate the database from the share just because a provider adds another eligible object. Shared object metadata becomes available when the provider grants the required privileges to the share. Recreating the database would not solve the issue if the view has not been granted to the share.
- C. Incorrect.
Incorrect. A share does not receive OWNERSHIP on objects. Direct shares provide read-only access to supported database objects through privileges such as USAGE and SELECT. OWNERSHIP is not granted to a share and would be inconsistent with the purpose of secure data sharing.
- D. Incorrect.
Incorrect. Cloning the schema is unnecessary and does not address the root cause. The issue is not with the schema itself, but with object-level privileges on the new secure view. The existing share can expose the view once SELECT on that view is granted to the share.