COF-C03 Question 41
Single answerSharesA data provider company uses Secure Data Sharing to give an external customer access to curated sales data. The provider created a share that includes a database and several secure views. After the customer creates a database from the share, they report that one of the newly added views is not visible in the shared database. The provider verifies that the view exists and that the underlying tables are already part of the same shared database. What should the provider do to make the new view available to the consumer?
- A
Grant SELECT on the new view to the share and ensure USAGE on its schema and database is granted to the share
- B
Ask the consumer to refresh the shared database using ALTER DATABASE ... REFRESH
- C
Clone the shared database into a new database and add the clone to the existing share
- D
Convert the view to a materialized view because standard views cannot be shared
Show answer and explanation
Correct answer: A
Explanation
With Snowflake Secure Data Sharing, the provider controls consumer visibility by granting privileges on database objects to a share. When a new object is added later, it does not become available automatically unless the required privileges are granted to the share. For views, Snowflake sharing best practices require using secure views when sharing derived data. The provider must ensure the share has access to the database and schema containers and grant the appropriate object privilege on the new secure view. The consumer does not manage refresh behavior for shared databases in order to see newly granted objects. This aligns with Snowflake documentation for CREATE SHARE, GRANT
- A. Correct.
Correct. In Secure Data Sharing, objects are exposed to consumers through privileges granted to the share. For a consumer to see and query a newly added view, the provider must grant the appropriate privileges on that view to the share, and the containing schema and database must also be available through the share. In practice, shared objects require the necessary USAGE privileges on parent containers plus object-level access such as SELECT on secure views.
- B. Incorrect.
Incorrect. Consumers do not make newly shared objects appear by refreshing a database in this manner. Shared databases reflect the current contents of the share once the provider grants the needed privileges. The issue is on the provider side: the new object has not been properly granted to the share.
- C. Incorrect.
Incorrect. Cloning is unrelated to making an additional view visible through an existing share. A clone would create another copy of the database metadata/storage structure for the provider, but it would not solve the missing privilege on the share. This distractor reflects a common misconception that cloning is used to republish shared data.
- D. Incorrect.
Incorrect. Standard non-secure views are not shareable, but the scenario already states that the provider is using secure views. There is no requirement to convert a secure view into a materialized view for sharing. Materialized views have different use cases and are not the fix for this access issue.