SnowPro Advanced: Security Engineer Question 314
Single answerData sharing configurationsA security engineer at a provider account must share a SALES table with several external consumers using Secure Data Sharing. The shared data must exclude rows for the APAC region, and the provider must prevent consumers from seeing underlying object definitions or using non-secure objects that could expose restricted data through query optimization side effects. The provider also wants the share to remain simple for consumers to query. Which approach best meets these requirements?
- A
Create a secure view that filters out APAC rows, grant SELECT on the secure view to a share, and grant REFERENCE_USAGE on the database and schema objects needed by the secure view.
- B
Create a standard view that filters out APAC rows, grant SELECT on the view to a share, and rely on the consumer account's role hierarchy to prevent access to restricted rows.
- C
Share the base SALES table directly and use a row access policy in the consumer account to filter APAC rows after the share is imported.
- D
Create a dynamic table that excludes APAC rows, share the dynamic table, and assume its refresh definition is hidden from consumers even if the object is not secure.
Show answer and explanation
Correct answer: A
Explanation
The best practice for Secure Data Sharing when consumers should see only a filtered subset of provider data is to share a secure view rather than the base table. Secure views help protect the view definition and are intended for scenarios where the provider must prevent information leakage that could occur with non-secure objects. In addition, when a shared view references objects across databases, the share needs REFERENCE_USAGE on the referenced database so queries can resolve dependencies. This question tests practical understanding of how to combine row filtering, secure objects, and required privileges in a real provider-consumer sharing design. Relevant Snowflake guidance includes documentation for Secure Data Sharing, secure views, and privileges such as USAGE/REFERENCE_USAGE required for shared objects and dependent objects.
- A. Correct.
Correct. In Secure Data Sharing, if the provider needs to expose only a subset of rows while also protecting object logic and avoiding leakage from non-secure objects, a secure view is the appropriate mechanism. Secure views are designed to hide underlying details from consumers and are the recommended way to share filtered data. When a shared secure view references objects in other schemas or databases, the provider must grant the share the required REFERENCE_USAGE privileges on the referenced databases (and ensure required object privileges are in place) so the consumer can query the view successfully.
- B. Incorrect.
Incorrect. A standard view can filter rows, but it is not appropriate for this requirement because the scenario explicitly calls for protection against exposing object definitions and use of non-secure objects. In Snowflake, secure views are required when the provider needs stronger confidentiality protections around view definitions and optimizer behavior. Consumer role hierarchy does not enforce provider-side row filtering for shared data.
- C. Incorrect.
Incorrect. The provider cannot depend on a row access policy in the consumer account to protect provider data in a share. Data sharing is controlled by the provider account, and the provider should enforce row restrictions before or within the shared object. Sharing the base table directly would expose all rows in that table to the consumer unless the provider applies controls on the provider side, such as sharing a secure view.
- D. Incorrect.
Incorrect. Dynamic tables are not the correct answer for this security requirement. Even if a dynamic table contains only the filtered result set, the scenario specifically requires protection from exposing underlying object definitions and use of non-secure objects. A secure view is the documented pattern for secure data sharing of filtered subsets. Using a dynamic table here adds operational complexity and does not replace the need for secure object semantics in a shared configuration.