SnowPro Advanced: Security Engineer Question 151
Single answerConfigure Data ListingsA security engineer at a data provider is preparing a Snowflake data listing that will be shared only with three approved consumer accounts. The provider must ensure that consumers can query only the rows allowed by the provider's governance policies, and the provider wants to avoid exposing the underlying physical tables directly. Which approach should the engineer use when configuring the listing?
- A
Create a share that contains secure views protected by the required row access and masking policies, then create a private listing based on that share and target the approved consumer accounts.
- B
Create a public listing directly from the base tables, because row access and masking policies are enforced automatically for all listings regardless of object type.
- C
Create a private listing from an application package, because private listings cannot be created from shares when only specific accounts should have access.
- D
Create a share with standard views over the protected tables, then publish it as a private listing because secure views are only required for public listings.
Show answer and explanation
Correct answer: A
Explanation
The correct solution is to create a private listing from a share that exposes secure views, not base tables. This satisfies all stated requirements: limiting access to approved accounts, preserving governance controls such as row access and masking policies, and avoiding direct exposure of physical tables. In Snowflake, listings are a discovery and distribution mechanism layered on top of secure sharing constructs. A private listing is used when the provider wants to target specific consumer accounts rather than publish broadly. Best practice is to publish only governed, consumer-ready objects such as secure views. Snowflake documentation on Secure Data Sharing, Secure Views, Row Access Policies, Masking Policies, and Listings supports this approach.
- A. Correct.
Correct. In Snowflake, data listings are commonly created from shares, and a private listing is the right choice when access must be limited to specific consumer accounts. To avoid exposing underlying tables and to enforce governed access, the provider should share secure views rather than base tables. Row access policies and masking policies can be applied to the objects exposed through the share so that consumers only see authorized data. This aligns with best practice for data sharing and listings: expose only the minimum governed interface necessary.
- B. Incorrect.
Incorrect. Although governance policies can apply in shared scenarios, publishing base tables directly is not the best approach when the requirement is to avoid exposing underlying physical tables. The misconception is that listings remove the need for careful object design. In practice, providers typically use secure views to abstract and restrict access. Relying on direct base-table exposure creates unnecessary risk and reduces control over what consumers can see.
- C. Incorrect.
Incorrect. Listings can be created from shares, and private listings are specifically used to make data products available only to selected consumers. An application package is used for Native Apps, not as a requirement for account-restricted data listings. This option confuses Native App distribution with standard data sharing through listings.
- D. Incorrect.
Incorrect. Standard views are not the recommended object type for secure data sharing when the provider wants to prevent consumers from gaining insight into underlying query logic or structures. Secure views are designed for sharing scenarios and provide stronger protections. The misconception here is that secure views matter only for public listings, but the same security design principle applies to private listings as well.