ADA-C01 Question 476
Single answerImport and maintain inbound data sharesA Snowflake administrator is onboarding a new inbound data share from a partner. The provider has already added the consumer account to the share and sent the share name. Your organization wants a read-only database created from the share, and only the FINANCE_ANALYST role should be able to query the shared data. A week later, the provider adds new tables to the share, and analysts ask how those objects will appear in the consumer account. Which action should the administrator take, and what should they expect after the provider updates the share?
- A
Create a database from the share using CREATE DATABASE <db_name> FROM SHARE <provider_account>.<share_name>; then grant imported privileges on that database to FINANCE_ANALYST. When the provider adds objects to the share, they become available in the imported database automatically.
- B
Create a regular database and use GRANT SELECT ON ALL TABLES to FINANCE_ANALYST; then use ALTER SHARE REFRESH when the provider adds new tables so the consumer database stays synchronized.
- C
Use CREATE DATABASE AS CLONE on the provider's shared database; then grant USAGE on future schemas in the cloned database to FINANCE_ANALYST so new provider tables are visible.
- D
Create the database from the share and grant OWNERSHIP on the imported database to FINANCE_ANALYST. When the provider adds objects, the consumer must recreate the database from the share to see them.
Show answer and explanation
Correct answer: A
Explanation
Inbound data shares are consumed by creating a database from a share using CREATE DATABASE
- A. Correct.
Correct. For an inbound share, the consumer creates a read-only database with CREATE DATABASE ... FROM SHARE using the provider account identifier and share name. Access to objects in a shared database is controlled in the consumer account by granting IMPORTED PRIVILEGES on the database to a role, rather than granting object-level privileges like SELECT on the shared tables. When the provider adds or removes objects from the share, those changes are reflected automatically in the consumer's imported database; no manual refresh or recreation is required.
- B. Incorrect.
Incorrect. A consumer cannot turn an inbound share into a regular writable database for direct synchronization purposes, and GRANT SELECT ON ALL TABLES is not the correct model for access to shared databases. For imported/shared databases, the consumer grants IMPORTED PRIVILEGES on the database. In addition, there is no ALTER SHARE REFRESH command for consumers to synchronize new shared objects.
- C. Incorrect.
Incorrect. Consumers do not use CREATE DATABASE AS CLONE to consume a provider's share. Cloning applies to objects within accounts according to Snowflake cloning rules, not to importing shared data from another account via a data share. Also, future grants in the consumer account are not how newly shared provider objects become visible; visibility is governed by what the provider includes in the share and by the consumer's imported privileges.
- D. Incorrect.
Incorrect. Granting OWNERSHIP on an imported database is not the correct way to provide query access to a consumer role. Shared databases are read-only, and the correct privilege model is GRANT IMPORTED PRIVILEGES ON DATABASE. Also, the consumer does not need to recreate the database when the provider updates the share; changes appear automatically.