SnowPro Advanced: Security Engineer Question 275
Single answerSecurity-related implicationsA financial services company uses Snowflake to share curated account data with an external audit firm through a secure data share. The shared database contains a view that joins a fact table with a mapping table that includes internal customer identifiers and analyst comments. During a security review, the team discovers that the audit firm can query the shared view successfully, but future updates to the mapping table may expose sensitive columns that were not intended for external use. The security engineer must reduce the risk of accidental data exposure while preserving the audit firm's access to only approved fields. Which action should the security engineer take?
- A
Replace the shared view with a secure view that explicitly selects only the approved columns needed by the audit firm
- B
Keep the existing standard view, because consumers of a data share can only see columns that were visible when the share was first created
- C
Grant imported privileges on the shared database to a custom role in the audit firm's account so that column visibility can be restricted there
- D
Convert the mapping table to a temporary table so that sensitive columns are not persisted and therefore cannot be exposed through the share
Show answer and explanation
Correct answer: A
Explanation
The best answer is to replace the shared view with a secure view that explicitly selects only approved columns. In Snowflake, secure views are recommended when exposing data to other parties because they help protect underlying implementation details and support controlled data sharing patterns. From a security perspective, the provider must enforce least privilege at the object definition layer rather than relying on the consumer to restrict access after the share is created. This is especially important when underlying tables may gain new sensitive columns over time. Best practice is to publish curated, secure objects for data sharing and avoid exposing broad base-table structures or non-secure abstractions when sensitive data is involved. Relevant Snowflake guidance includes documentation on secure views, secure data sharing, and the principle of exposing only intended data through provider-controlled objects.
- A. Correct.
Correct. A secure view is appropriate for data sharing scenarios because it is designed to protect underlying logic and limit exposure of base objects. Explicitly projecting only approved columns follows least-privilege design and reduces the chance that later schema changes to base tables will unintentionally expose sensitive fields. In provider-managed data sharing, the safest pattern is to expose only a curated secure view or secure objects intended for consumer access.
- B. Incorrect.
Incorrect. This reflects a common misconception. A standard view is not the recommended object for securely sharing sensitive data, and assuming column exposure is fixed at share creation is unsafe. Changes to underlying objects or view definitions can affect what consumers can access. Snowflake best practice for sensitive shared data is to use secure views and explicitly control the projected columns.
- C. Incorrect.
Incorrect. Imported privileges let a consumer role use privileges from a shared database, but they do not allow the consumer to redefine which columns are visible inside the provider's shared objects. The provider account controls the objects and their definitions in a data share. Column-level restriction must be implemented by the provider, typically through secure views or similar curated objects.
- D. Incorrect.
Incorrect. Temporary tables are session-scoped and are not an appropriate mechanism for provider-managed shared data. They are not designed to solve data sharing exposure risks. Even if persistence were changed, that would not address the core issue: the shared interface should explicitly expose only approved fields through a secure object.