COF-C03 Question 328
Single answerConsumerA data provider has shared a secure data listing with a business partner through the Snowflake Marketplace. The partner installs the listing in its own Snowflake account and needs to let several analysts query the shared data immediately, without copying it into local tables. The partner also wants to follow least-privilege access practices. What should the partner do first to enable this access?
- A
Grant IMPORTED PRIVILEGES on the shared database created from the listing to a role, then grant that role to the analysts
- B
Clone the shared database into a local database and grant SELECT on the cloned tables to the analysts
- C
Grant SELECT on each shared table directly to the analyst roles
- D
Transfer ownership of the shared database to a custom role and then grant USAGE on the database to the analysts
Show answer and explanation
Correct answer: A
Explanation
For Snowflake consumers, data received through a share or Marketplace listing is exposed as a read-only database in the consumer account. The consumer does not manage object-level privileges in that database the same way they would for a regular database they own. Instead, the documented and recommended approach is to grant IMPORTED PRIVILEGES on the shared database to a role and then assign that role to the appropriate users. This aligns with role-based access control and least-privilege best practices. Key Snowflake documentation areas include Secure Data Sharing, consumer responsibilities for shared databases, and GRANT IMPORTED PRIVILEGES usage.
- A. Correct.
Correct. When a consumer installs a data share or listing, Snowflake creates a read-only database from the share in the consumer account. Access to objects in that shared database is typically enabled by granting IMPORTED PRIVILEGES on the database to a role. That role can then be granted to analyst users. This is the standard consumer-side pattern and supports least privilege because access is controlled through roles rather than broad user-level grants.
- B. Incorrect.
Incorrect. Cloning is not the right first step for immediate access to provider-shared data, and a shared database is read-only. While consumers can create their own derived objects in permitted ways, the key requirement is to query the shared data without copying it. Cloning into a local database would change the scenario and is unnecessary for simply consuming the shared data.
- C. Incorrect.
Incorrect. Consumers do not typically grant SELECT directly on individual objects inside a shared database created from a provider share. Instead, access is managed through IMPORTED PRIVILEGES on the shared database. Choosing this option reflects a common misconception that shared databases are administered exactly like regular databases owned by the consumer.
- D. Incorrect.
Incorrect. A consumer cannot transfer ownership of the shared database because the database originates from a share and is read-only in the consumer account. Ownership-based administration does not apply here in the same way it does for consumer-created databases. The proper mechanism is granting IMPORTED PRIVILEGES.