ADA-C01 Question 450
Single answerConfigure data sharing programmaticallyA data platform team wants to automate secure data sharing from a provider account to multiple consumer accounts each time a new regional dataset is published. The automation must use SQL so it can run from a deployment pipeline, and consumers should immediately see future tables added to the shared schema without the provider updating the share each time. Which sequence of actions should the administrator implement?
- A
Create a share, grant USAGE on the database and schema to the share, grant SELECT on all existing tables in the schema to the share, grant SELECT on future tables in the schema to the share, and then ALTER SHARE ... ADD ACCOUNTS = <consumer_accounts>.
- B
Create a share, grant IMPORTED PRIVILEGES on the provider database to the share, grant SELECT on the schema to the share, and then ALTER SHARE ... SET ACCOUNTS = <consumer_accounts>.
- C
Create a database role with SELECT on the schema, assign the database role to the consumer accounts, and then create listings so future tables are inherited automatically.
- D
Create a share, grant REFERENCE_USAGE on the database to the share, grant SELECT on future tables in the database to the share, and then create a reader account for each consumer account.
Show answer and explanation
Correct answer: A
Explanation
For direct secure data sharing configured programmatically, the provider typically uses SQL in this order: CREATE SHARE, grant required privileges on database/schema and shared objects to the share, then add consumer accounts with ALTER SHARE. Consumers can only access objects included in the share, and for standard table sharing the provider must grant USAGE on the database and schema plus SELECT on the tables or secure views. To support automation when new tables are added over time, GRANT SELECT ON FUTURE TABLES IN SCHEMA ... TO SHARE allows future tables in that schema to be included without modifying the share for each release. This aligns with Snowflake best practices for direct sharing automation. Be careful not to confuse provider-side sharing with consumer-side IMPORTED PRIVILEGES, listing-based sharing, or reader accounts, which serve different use cases.
- A. Correct.
Correct. Programmatic secure data sharing with SQL uses CREATE SHARE, then object grants to the share, and finally adding consumer accounts with ALTER SHARE ... ADD ACCOUNTS. To make shared objects accessible, the provider grants USAGE on the database and schema and SELECT on tables or secure views. To avoid manually updating the share for newly added tables, the provider can grant SELECT ON FUTURE TABLES IN SCHEMA to the share. This is the standard pattern for automating direct shares to consumer accounts.
- B. Incorrect.
Incorrect. IMPORTED PRIVILEGES is granted to a database created from a share on the consumer side; it is not something granted from a provider database to a share. Also, SELECT is not granted on a schema; schemas require USAGE, while tables/views require SELECT. In addition, ALTER SHARE commonly uses ADD ACCOUNTS to add consumers rather than replacing the entire set with SET ACCOUNTS in this scenario.
- C. Incorrect.
Incorrect. Consumer accounts are not assigned database roles from the provider in direct data sharing. Database roles can be granted to shares in some role-based sharing designs, but the option is wrong because SELECT is not granted on a schema, and creating listings is a different sharing mechanism from direct account-to-account shares. The scenario specifically requires a SQL-driven direct sharing sequence where consumers automatically see future tables in a shared schema.
- D. Incorrect.
Incorrect. REFERENCE_USAGE is used in specific cases such as sharing secure views that reference objects in other databases; it is not the primary grant needed for sharing base tables in the same database. Also, future table grants are scoped at the schema level, not the database level in this form. Finally, reader accounts are for consumers that do not already have their own Snowflake account, while the scenario states sharing to multiple consumer accounts.