ARA-C01 Question 151
Select 2Configure shares, account parameters, and privilegesA data platform architect is designing a secure data-sharing solution for an enterprise Snowflake account. The company must share a curated SALES database with two external business partners. Requirements are:
- Partners must query only approved objects.
- Future tables created in specific schemas should become available to consumers without manual re-granting.
- The provider wants to avoid granting broad privileges directly on the database to consumer accounts.
- Internal analysts in the provider account should still manage object access using roles.
Which TWO actions should the architect take to meet these requirements?
- A
Create a secure share, grant USAGE on the database and schemas to the share, and grant SELECT on specific tables and views to the share.
- B
Grant future SELECT privileges on tables in the relevant schemas to the share so newly created tables are automatically included.
- C
Grant imported privileges on the shared database to the consumer accounts so they can access only approved objects.
- D
Use database roles to manage object grants, then grant the database role to the share.
- E
Grant OWNERSHIP on the curated schemas to the share so consumers can query all current and future objects in those schemas.
Show answer and explanation
Correct answers: A, D
Explanation
The best solution is to use a secure share together with database roles. Snowflake data sharing works by a provider creating a share and granting object privileges to that share. At minimum, the share needs USAGE on the database and schemas and SELECT on the specific objects to be shared. To satisfy the requirement that future tables in specific schemas become available without repeated manual grants, database roles are the most maintainable design: grant privileges, including future grants where supported, to a database role, then grant that database role to the share. This keeps internal access management role-based and avoids direct broad grants to consumer accounts.
Key points aligned to Snowflake best practices and documentation:
- Providers control access to shared data by privileges granted to a share.
- Consumers then grant IMPORTED PRIVILEGES on the created shared database to roles within their own account; this is a consumer-side step, not the provider's sharing mechanism.
- Future grants are supported for roles on schemas and objects, but not as direct future grants to shares.
- Database roles are specifically designed to simplify privilege management within a database and can be granted to shares.
This architecture minimizes operational overhead, enforces least privilege, and supports scalable external sharing.
- A. Correct.
Correct. In Snowflake Secure Data Sharing, a provider creates a share and grants USAGE on the database and relevant schemas, plus SELECT on specific tables and secure views, to the share. This is the core pattern for exposing only approved objects to consumer accounts while avoiding broad direct grants to consumers.
- B. Incorrect.
Incorrect. Snowflake does not support future grants to a share in the same way future grants can be applied to roles. Shares receive explicit object privileges, or can receive database roles that encapsulate object privileges. Assuming future SELECT can be granted directly to a share is a common misconception.
- C. Incorrect.
Incorrect. IMPORTED PRIVILEGES is granted inside a consumer account on a shared database so roles in that consumer account can use the shared objects. It is not something the provider grants to consumer accounts as a mechanism for limiting what is exposed. The provider controls exposure through the share itself.
- D. Correct.
Correct. Database roles can be used to manage privileges on objects within a database, including future grants on schemas. Granting the database role to the share lets the provider manage approved access internally through roles while allowing future objects covered by role grants to be exposed through the share.
- E. Incorrect.
Incorrect. A share cannot be granted OWNERSHIP, and OWNERSHIP would be inappropriate for read-only data sharing. Consumers of a share do not take ownership of provider objects; they receive controlled read access to explicitly shared objects.