ADA-C01 Question 456
Single answerManage data providers and consumersA company publishes a Secure Data Share from its provider account to several external customers. One customer reports that after creating a database from the share, they can query the shared tables but cannot create derived tables or views in that shared database. The provider wants to confirm whether this behavior is expected and advise the consumer on the correct approach while maintaining least privilege. What should the administrator recommend?
- A
Grant OWNERSHIP on the shared database to the consumer role so the consumer can create tables and views directly in the shared database.
- B
Have the consumer create a separate database or schema they own, then create views or tables there that reference objects in the shared database.
- C
Convert the Secure Data Share to a database role share so the consumer can write objects into the shared database without additional privileges.
- D
Grant IMPORTED PRIVILEGES on the shared database to the consumer role; this allows creating permanent objects inside the shared database.
- E
Recreate the share as a listing because only listings allow consumers to create derived objects from shared data.
Show answer and explanation
Correct answer: B
Explanation
This behavior is expected. In Snowflake data sharing, a consumer database created from a share is read-only. Consumers can query shared objects but cannot create schemas, tables, or views inside the imported shared database. The recommended approach is for the consumer to create a separate writable database or schema in their own account and build any derived objects there. If needed, the consumer can be granted IMPORTED PRIVILEGES on the shared database to access the share, but that privilege does not allow writes. This aligns with Snowflake documentation and best practices for Secure Data Sharing: providers control access to shared objects, while consumers create downstream objects only in their own writable containers.
- A. Incorrect.
Incorrect. A consumer cannot be granted OWNERSHIP of a database created from a share in a way that turns the shared database into a writable database. Databases created from shares are read-only from the consumer perspective. This option reflects a common misconception that higher privileges can override the fundamental read-only nature of shared databases.
- B. Correct.
Correct. In Snowflake, a database created from a share is read-only. Consumers can query shared objects, but they cannot create tables, views, or other objects inside that shared database. The correct pattern is to create a separate database or schema owned within the consumer account and then create derived objects there, such as secure views, standard views, or tables created with CTAS, referencing the shared data as allowed by Snowflake.
- C. Incorrect.
Incorrect. Database roles can be used to share objects and simplify privilege management, but they do not change the core behavior of consumer databases created from shares. Shared databases remain read-only for consumers. This option incorrectly suggests that the sharing mechanism affects write capability in the imported database.
- D. Incorrect.
Incorrect. IMPORTED PRIVILEGES allows a role in the consumer account to use privileges associated with the shared database, but it does not make the database writable. It enables access to the shared objects; it does not permit creating permanent objects inside the shared database.
- E. Incorrect.
Incorrect. Listings are a distribution mechanism used in data exchange/marketplace-style scenarios, but they do not change the fact that consumer-accessed shared data is read-only in the imported database. Consumers still need to create derived objects in their own writable database or schema.