Masking, tagging, and the other controls that govern who sees what data
Snowflake provides a layered data governance framework built on RBAC combined with object-level and column/row-level controls. Key features include Object Tagging, Data Classification, Dynamic Data Masking, Row Access Policies, and Access History, which together enable discovery, protection, and auditing of sensitive data. These features integrate with Snowflake's centralized metadata to support compliance and internal security requirements without duplicating data.
1 · Learn the must-know
- Dynamic Data Masking applies masking policies to columns so unauthorized users see masked (e.g., redacted or partially obscured) data at query time, while authorized roles see plaintext; the underlying data is never altered.
- Row Access Policies restrict which rows a user can see based on conditions (e.g., mapping tables) evaluated at query runtime, enabling row-level security without creating multiple copies of a table.
- Object Tagging allows key-value pair tags to be assigned to tables, columns, warehouses, and other objects for tracking sensitive data, cost attribution, or classification purposes, and tags can trigger masking policies via tag-based masking.
- Data Classification is a feature that automatically analyzes and suggests semantic categories (e.g., PII like name, email) for columns, helping automate the tagging process for sensitive data discovery.
- Access History (a view in
ACCOUNT_USAGE) records read and write queries against tables/columns, enabling auditing of who accessed what data and supporting compliance reporting; it requires Enterprise Edition or higher. - Masking policies and row access policies are schema-level objects that can be applied to multiple tables/columns, and a single column can only have one masking policy at a time, though policies can reference tags for broader application.
2 · Check your understanding
A Snowflake Practitioner defines a masking policy on the SSN column in the CUSTOMERS table using CREATE MASKING POLICY mask_ssn AS (val string) RETURNS string -> CASE WHEN CURRENT_ROLE() = 'COMPLIANCE_OFFICER' THEN val ELSE '***-**-****' END. The ANALYST role currently sees masked values as expected. A new requirement states that the FRAUD_ANALYST role must also see unmasked values without creating a second masking policy or view. Which change should the Practitioner make?
What you have tried across SnowPro Core's objectives, not a readiness score.
Snowflake AI Data Cloud Features and Architecture31% of the exam0 of 6 tried
Account Management and Data Governance20% of the exam0 of 3 tried
Data Loading, Unloading, and Connectivity18% of the exam0 of 3 tried
Performance Optimization, Querying, and Transformation21% of the exam0 of 4 tried
3 · Keep going
Ready for more? Take a weighted mock or try free practice questions.