SnowPro Advanced: Security Engineer Question 315
Single answerData sharing configurationsA security engineer at a provider account must share a curated dataset with several external customers. The dataset is stored in schema PROD_SECURE and includes a secure view that masks sensitive columns based on a policy. The provider wants to ensure customers can query only the intended shared objects, cannot see underlying base tables, and can begin consuming the data without copying it. Which action should the engineer take to meet these requirements?
- A
Create a share, grant USAGE on the database and schema to the share, grant SELECT on the secure view to the share, and have each customer create a database from the share
- B
Create a share, grant IMPORTED PRIVILEGES on the database to the share, grant SELECT on the base tables to the share, and have each customer clone the shared schema
- C
Create a data exchange listing for the schema and instruct customers to query the provider database directly without creating any object in their accounts
- D
Create a share, grant SELECT on the schema to the share, and have each customer create a warehouse owned by the provider to run queries against the shared data
Show answer and explanation
Correct answer: A
Explanation
The correct configuration for Secure Data Sharing is to create a share in the provider account, grant USAGE on the containing database and schema, and grant object privileges such as SELECT on the specific secure view that should be exposed. The consumer then creates a database from that share and queries it using compute in the consumer account, so the data is not copied. This approach aligns with Snowflake best practices for least privilege and controlled exposure: expose secure views rather than base tables when the provider wants to restrict direct access to underlying objects and preserve masking or other protected logic. Key concepts from Snowflake documentation include provider-created shares, consumer-created databases from shares, consumer-side warehouses for query execution, and the requirement to grant USAGE at the database/schema level plus SELECT on the shared objects.
- A. Correct.
Correct. Secure Data Sharing is designed for exactly this use case: the provider creates a share, grants USAGE on the database and schema, and grants object-level privileges such as SELECT on the secure view. Consumers then create a database from the share in their own accounts and query the shared data without copying it. Sharing the secure view rather than base tables helps prevent consumers from directly accessing underlying objects while preserving policy-driven logic exposed by the secure view.
- B. Incorrect.
Incorrect. IMPORTED PRIVILEGES is granted to roles on a consumer-created database from a share; it is not something granted on a provider database to a share in this way. Also, consumers do not clone shared schemas to consume shared data. Granting access to base tables would also violate the requirement to prevent visibility into underlying tables when a secure view is intended as the controlled interface.
- C. Incorrect.
Incorrect. Listings and data exchanges are mechanisms for discovery and distribution, but consumers still access data through databases created from the shared data product, not by querying the provider's database directly. In standard secure sharing, consumers must create a database from the share in their own account context.
- D. Incorrect.
Incorrect. SELECT is not granted on a schema; schemas require USAGE, while SELECT is granted on specific objects such as views or tables. In addition, consumers use their own virtual warehouses to query shared data; providers do not share warehouse ownership or execution resources with consumers for standard data sharing.