Column-level security with masking policies in Snowflake - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is column-level security in Snowflake?

Column-level security restricts access to specific columns in a table, allowing control over who can see sensitive data in those columns.

beginner

What is a masking policy in Snowflake?

A masking policy defines rules to hide or obfuscate sensitive data in columns based on the user's role or context.

intermediate

How does a masking policy work in Snowflake?

When a user queries a column with a masking policy, Snowflake applies the policy's logic to show either the real data or masked data depending on the user's permissions.

intermediate

Can masking policies be applied to multiple columns in Snowflake?

Yes, you can create multiple masking policies and apply them to different columns as needed to protect sensitive information.

advanced

What is the benefit of using masking policies over just restricting access to columns?

Masking policies allow users to query data without errors but see masked values if they lack permission, improving usability while protecting sensitive data.

What does a masking policy in Snowflake do?

A Encrypts the entire database

B Deletes sensitive columns from tables

C Hides or masks data in columns based on user roles

D Creates backups of sensitive data

Masking policies control how data is shown to users by masking sensitive column data based on roles.

Which Snowflake object do you create to implement column-level masking?

A Stage

B Masking policy

C Warehouse

D Role

Masking policies are the objects that define how to mask column data.

If a user lacks permission, what will they see when querying a masked column?

A Masked or obfuscated data

B An error message

C The full original data

D No rows returned

Users without permission see masked data, not errors or full data.

Can a single masking policy be reused for multiple columns?

A Only for numeric columns

B No, each column needs a unique policy

C Only for columns in different tables

D Yes, if the masking logic applies to those columns

Masking policies can be reused if the same masking logic fits multiple columns.

What is a key advantage of masking policies compared to simply revoking column access?

A Users can still query data without errors but see masked values

B It permanently deletes sensitive data

C It speeds up queries

D It encrypts data at rest

Masking policies allow queries to run smoothly while protecting sensitive data by masking it.

Explain how column-level security with masking policies works in Snowflake.

Think about how data visibility changes depending on who queries it.

Describe the benefits of using masking policies for protecting sensitive data in Snowflake.

Consider why masking is better than just hiding columns.

Practice

1. What is the main purpose of a masking policy in Snowflake's column-level security?

easy

A. To create backups of sensitive columns

B. To hide or mask sensitive column data based on user roles

C. To encrypt the entire database automatically

D. To delete sensitive data permanently from a column

Solution

1. Step 1: Understand masking policy purpose

   Masking policies control how sensitive data is shown without changing the original data.

2. Step 2: Identify role-based data visibility

   They mask or reveal data depending on the user's role or permissions.

3. Final Answer:

   To hide or mask sensitive column data based on user roles -> Option B

4. Quick Check:

   Masking policy = role-based data masking [OK]

Hint: Masking policies control data visibility by user roles [OK]

Common Mistakes:

• Thinking masking deletes data
• Confusing masking with encryption
• Assuming masking backs up data

2. Which of the following is the correct syntax to create a masking policy in Snowflake?

easy

A. CREATE MASKING POLICY policy_name AS CASE WHEN CURRENT_ROLE() IN ('ANALYST') THEN val ELSE '****' END RETURNS STRING;

B. CREATE MASKING POLICY policy_name (val STRING) RETURNS STRING AS CASE WHEN CURRENT_ROLE() IN ('ANALYST') THEN val ELSE '****' END;

C. CREATE MASKING POLICY policy_name AS (val STRING) RETURNS STRING AS (CASE WHEN CURRENT_ROLE() IN ('ANALYST') THEN val ELSE '****' END);

D. CREATE MASKING POLICY policy_name RETURNS STRING AS (val STRING) CASE WHEN CURRENT_ROLE() IN ('ANALYST') THEN val ELSE '****' END;

Solution

1. Step 1: Recall correct syntax structure

   Snowflake masking policy syntax starts with CREATE MASKING POLICY name AS (input parameter) RETURNS type.

2. Step 2: Match syntax with options

   CREATE MASKING POLICY policy_name AS (val STRING) RETURNS STRING AS (CASE WHEN CURRENT_ROLE() IN ('ANALYST') THEN val ELSE '****' END); correctly uses AS (val STRING) RETURNS STRING followed by the CASE expression.

3. Final Answer:

   CREATE MASKING POLICY policy_name AS (val STRING) RETURNS STRING AS (CASE WHEN CURRENT_ROLE() IN ('ANALYST') THEN val ELSE '****' END); -> Option C

4. Quick Check:

   Correct syntax = CREATE MASKING POLICY policy_name AS (val STRING) RETURNS STRING AS (CASE WHEN CURRENT_ROLE() IN ('ANALYST') THEN val ELSE '****' END); [OK]

Hint: Syntax: CREATE MASKING POLICY name AS (param) RETURNS type [OK]

Common Mistakes:

• Placing RETURNS before AS
• Missing parentheses around input parameter
• Incorrect order of clauses

3. Given this masking policy:

CREATE MASKING POLICY mask_ssn AS (val STRING) RETURNS STRING AS (CASE WHEN CURRENT_ROLE() IN ('HR') THEN val ELSE 'XXX-XX-XXXX' END);

What will a user with role 'SALES' see when querying the masked SSN column?

medium

A. 'XXX-XX-XXXX'

B. NULL

C. The actual SSN value

D. An error message

Solution

1. Step 1: Analyze masking policy logic

   The policy shows the real value only if CURRENT_ROLE() is 'HR'. Otherwise, it masks with 'XXX-XX-XXXX'.

2. Step 2: Determine output for 'SALES' role

   Since 'SALES' is not 'HR', the user sees the masked string 'XXX-XX-XXXX'.

3. Final Answer:

   'XXX-XX-XXXX' -> Option A

4. Quick Check:

   Role not HR = masked value [OK]

Hint: If role not allowed, masking policy returns mask string [OK]

Common Mistakes:

• Assuming user sees actual data
• Expecting NULL instead of mask
• Thinking it causes an error

4. You created a masking policy but users still see unmasked data. What is the most likely cause?

medium

A. The masking policy was not attached to the column

B. The masking policy syntax has a typo

C. The user has the role that bypasses masking

D. The table is missing a primary key

Solution

1. Step 1: Check masking policy attachment

   Masking policies must be assigned to columns to take effect.

2. Step 2: Consider user roles and syntax

   While roles can bypass masking, if all users see unmasked data, likely the policy is not attached.

3. Final Answer:

   The masking policy was not attached to the column -> Option A

4. Quick Check:

   Policy attached = masking works [OK]

Hint: Attach masking policy to column to activate it [OK]

Common Mistakes:

• Ignoring policy attachment step
• Blaming user roles without checking
• Confusing table keys with masking

5. You want to create a masking policy that shows full email addresses to 'ADMIN' role, partially masks emails for 'SUPPORT' role (showing only domain), and masks completely for others. Which policy logic correctly implements this?

hard

A. CASE WHEN CURRENT_ROLE() = 'SUPPORT' THEN val WHEN CURRENT_ROLE() = 'ADMIN' THEN CONCAT('***@', SPLIT_PART(val, '@', 2)) ELSE '****' END

B. CASE WHEN CURRENT_ROLE() = 'ADMIN' THEN '****' WHEN CURRENT_ROLE() = 'SUPPORT' THEN val ELSE CONCAT('***@', SPLIT_PART(val, '@', 2)) END

C. CASE WHEN CURRENT_ROLE() IN ('ADMIN', 'SUPPORT') THEN val ELSE '****' END

D. CASE WHEN CURRENT_ROLE() = 'ADMIN' THEN val WHEN CURRENT_ROLE() = 'SUPPORT' THEN CONCAT('***@', SPLIT_PART(val, '@', 2)) ELSE '****' END

Solution

1. Step 1: Identify role conditions and outputs

   'ADMIN' sees full email (val), 'SUPPORT' sees masked local part but full domain, others see full mask.

2. Step 2: Match logic to requirements

   CASE WHEN CURRENT_ROLE() = 'ADMIN' THEN val WHEN CURRENT_ROLE() = 'SUPPORT' THEN CONCAT('***@', SPLIT_PART(val, '@', 2)) ELSE '****' END shows full val for ADMIN, partial mask for SUPPORT using CONCAT and SPLIT_PART, else full mask.

3. Final Answer:

   CASE WHEN CURRENT_ROLE() = 'ADMIN' THEN val WHEN CURRENT_ROLE() = 'SUPPORT' THEN CONCAT('***@', SPLIT_PART(val, '@', 2)) ELSE '****' END -> Option D

4. Quick Check:

   Role-based partial/full masking = CASE WHEN CURRENT_ROLE() = 'ADMIN' THEN val WHEN CURRENT_ROLE() = 'SUPPORT' THEN CONCAT('***@', SPLIT_PART(val, '@', 2)) ELSE '****' END [OK]

Hint: Order CASE by roles from most to less privileged [OK]

Common Mistakes:

• Swapping ADMIN and SUPPORT logic
• Showing full email to all roles
• Incorrect string functions usage