ARA-C01 Question 152
Single answerConfigure shares, account parameters, and privilegesA global data provider uses Secure Data Sharing to distribute curated analytics tables from a provider account to several consumer accounts. The security team requires that consumers must be able to query only approved objects through the share, while provider administrators must minimize the risk of exposing additional objects later through role inheritance or future grants. Which action should the architect take to meet these requirements?
- A
Create a database role with SELECT on the approved tables, grant the database role to the share, and avoid granting USAGE/SELECT directly to account roles for the share.
- B
Grant IMPORTED PRIVILEGES on the shared database to a consumer role so that only approved objects are visible to consumers.
- C
Grant SELECT on the entire schema to the share and rely on the consumer account's role hierarchy to restrict access to approved tables.
- D
Create the share, grant USAGE on the database and schema plus SELECT on only the approved tables/views directly to the share, and avoid future grants on the shared schema.
Show answer and explanation
Correct answer: D
Explanation
To securely expose a limited set of objects through Secure Data Sharing, the provider account must configure the share directly with the minimum required privileges: USAGE on the database, USAGE on the schema, and SELECT on the specific tables or secure views intended for consumers. The key architectural concern in this scenario is preventing accidental expansion of access over time. Future grants on schemas can automatically add privileges for newly created objects, which is undesirable when the security team wants only explicitly approved content exposed.
A common confusion is between provider-side and consumer-side privileges. On the consumer side, IMPORTED PRIVILEGES allows a role to use an imported shared database, but it does not define which objects are in the share. That is entirely controlled by the provider. Another misconception is that consumer role hierarchy can narrow the objects exposed by the provider; it cannot. Once objects are shared, consumer roles can be granted access to the shared database, but the share contents are still determined by provider grants.
This aligns with Snowflake documentation and best practices for Secure Data Sharing: define shares explicitly, grant object privileges directly to the share, and use least privilege to avoid unintended data exposure.
- A. Incorrect.
Incorrect. Database roles can be used within a database for privilege management, but they are not granted to shares to expose objects through Secure Data Sharing in the way described here. For shares, the provider grants privileges such as USAGE on the database and schema and SELECT on specific tables or secure views directly to the share. Choosing this option reflects a common misconception that all privilege containers in Snowflake can be attached to shares interchangeably.
- B. Incorrect.
Incorrect. IMPORTED PRIVILEGES is used in the consumer account to allow a role to access objects in an already-created shared database. It does not control which objects are exposed by the provider in the share. The provider must define object-level access in the share itself. This option confuses provider-side share configuration with consumer-side access delegation.
- C. Incorrect.
Incorrect. Granting SELECT on the entire schema is broader than required and increases the chance of overexposure. Consumer account role hierarchy cannot reduce the set of objects made available through the share; it only controls which consumer roles can use the imported shared database. If the provider exposes too much in the share, the consumer cannot use role hierarchy to make those objects disappear from the shared database definition.
- D. Correct.
Correct. In Secure Data Sharing, the provider should grant USAGE on the database and schema and SELECT only on approved tables or secure views directly to the share. Avoiding future grants on the shared schema helps prevent newly created objects from being unintentionally exposed later. This follows least-privilege design and aligns with provider-side control over what a share contains.