SOL-C01 · Question #50
A data engineer is tasked with ensuring that only authorized personnel can access sensitive data within a Snowflake database named 'SALES DB'. They need to implement a row-level security policy that f
The correct answer is D. Create a row access policy on the 'CUSTOMER DATA' table that filters rows based on the current. Option D is correct because Snowflake's Row Access Policy is a native, purpose-built feature for row-level security - it evaluates a policy function at query time to filter rows based on session context (like CURRENT_ROLE()), applies transparently to the table, and requires no ap
Question
A data engineer is tasked with ensuring that only authorized personnel can access sensitive data within a Snowflake database named 'SALES DB'. They need to implement a row-level security policy that filters rows based on the current user's role. A table named 'CUSTOMER DATA exists with a column named 'REGION'. Which of the following steps is the MOST effective and secure way to achieve this, considering minimal administrative overhead and leveraging Snowflake's built-in features?
Options
- ACreate a view that joins
CUSTOMER DATA' withINFORMATION SCHEMA.APPLICABLE - BCreate a stored procedure that dynamically generates SQL queries based on the current user's
- CCreate a masking policy on the 'REGION' column that replaces values with NULL based on the
- DCreate a row access policy on the 'CUSTOMER DATA' table that filters rows based on the current
- EImplement a custom application logic layer that retrieves all data from 'CUSTOMER_DATA' and
How the community answered
(22 responses)- A14% (3)
- B27% (6)
- C9% (2)
- D45% (10)
- E5% (1)
Explanation
Option D is correct because Snowflake's Row Access Policy is a native, purpose-built feature for row-level security - it evaluates a policy function at query time to filter rows based on session context (like CURRENT_ROLE()), applies transparently to the table, and requires no application-side changes, making it both secure and low-overhead.
Why the distractors fail:
- A (View + INFORMATION_SCHEMA): Views can work but require managing separate objects per role and offer no centralized policy enforcement;
APPLICABLE_ROLESjoins add complexity and don't scale cleanly. - B (Stored procedure with dynamic SQL): Procedures don't enforce access at the data layer - they must be called explicitly, so direct table queries bypass the filter entirely, making this insecure.
- C (Masking policy on REGION): Masking policies govern column-level data obfuscation (e.g., hiding values), not row-level filtering - the rows still appear, just with masked values.
- E (Application logic layer): Fetching all data and filtering in the app violates least-privilege at the database layer, exposes all rows to the middle tier, and creates a serious security gap.
Memory tip: Think "Row Access Policy = Row Filter" - the name maps directly to the feature. If the question mentions filtering which rows a user sees, reach for Row Access Policy; if it mentions hiding values within a column, that's a Masking Policy.
Topics
Community Discussion
No community discussion yet for this question.