SOL-C01 · Question #77
You are tasked with securing sensitive data in a table called `CUSTOMER DATA'. You want to grant the 'SELECT privilege on this table to a role called 'ANALYST ROLE, but prevent them from seeing the 'C
The correct answer is A. Create a view on 'CUSTOMER_DATA' that excludes the column and grant 'SELECT' on the view B. Use dynamic data masking on the column and grant the 'UNMASK' privilege to only specific roles E. Create a secure view on 'CUSTOMER DATA that excludes the 'CREDIT CARD NUMBER column. Options A, B, and E are all valid Snowflake approaches to column-level access control: creating a regular view (A) or a secure view (E) that simply omits the CREDIT_CARD_NUMBER column prevents ANALYST_ROLE from ever seeing it, while dynamic data masking (B) keeps the column visib
Question
You are tasked with securing sensitive data in a table called `CUSTOMER DATA'. You want to grant the 'SELECT privilege on this table to a role called 'ANALYST ROLE, but prevent them from seeing the 'CREDIT CARD NUMBER column, which contains personally identifiable information (PII). Which of the following approaches are valid in Snowflake to achieve this?
Options
- ACreate a view on 'CUSTOMER_DATA' that excludes the column and grant 'SELECT' on the view
- BUse dynamic data masking on the column and grant the 'UNMASK' privilege to only specific roles
- CGrant `SELECT on 'CUSTOMER_DATA' to 'ANALYST_ROLE and then 'REVOKE SELECT
- DApply a row access policy to filter out rows containing sensitive information when accessed by
- ECreate a secure view on 'CUSTOMER DATA that excludes the 'CREDIT CARD NUMBER column
How the community answered
(46 responses)- A67% (31)
- C9% (4)
- D24% (11)
Explanation
Options A, B, and E are all valid Snowflake approaches to column-level access control: creating a regular view (A) or a secure view (E) that simply omits the CREDIT_CARD_NUMBER column prevents ANALYST_ROLE from ever seeing it, while dynamic data masking (B) keeps the column visible but replaces its values with masked output for unauthorized roles - granting UNMASK only to privileged roles is exactly how this feature is designed to work.
Option C is wrong because you cannot revoke a specific column's SELECT privilege after granting table-level SELECT - Snowflake's privilege model doesn't support column-level REVOKE on base tables; the role would still see all columns or none.
Option D is wrong because row access policies filter rows, not columns - they're designed to hide entire records based on conditions (e.g., a user only seeing their own region's data), not to redact a specific field within a row.
Memory tip: Think of it as three layers of column-hiding in Snowflake - Views (hide the column structurally), Secure Views (same, but prevents query plan inspection for extra protection), and Dynamic Data Masking (column stays, data is obscured). If the question asks about hiding a column, look for these three; if it mentions filtering rows, think row access policies.
Topics
Community Discussion
No community discussion yet for this question.