What you will be able to do
- Choose between Dynamic Data Masking and External Tokenization for sensitive columns
- Design a row access policy with a mapping table, and explain whose role evaluates it
- Explain what aggregation and projection policies restrict and the order in which policies are enforced
- Use secure views and object tags, and identify which governance features require Enterprise Edition
1.Column-level security: Dynamic Data Masking and External Tokenization
Snowflake's column-level security has two features, and both use masking policies. A masking policy is a schema-level object that you attach to columns in tables and views. Snowflake evaluates it at query time, wherever the column appears. Depending on the policy's conditions, the execution context and the role hierarchy, a user sees the plain-text value, a partially masked value or a fully masked value. With Dynamic Data Masking, the data is stored in plain text and masked when it is read. External Tokenization goes further. The data is tokenized before it is loaded, so Snowflake only stores tokens. A masking policy that calls an external function detokenizes the value at query time for authorized users.
| Aspect | Dynamic Data Masking | External Tokenization |
|---|---|---|
| What Snowflake stores | Plain-text values | Tokens created before loading |
| How authorized users see the real value | The masking policy returns plain text for them | A masking policy calls an external function to detokenize |
| Edition | Column-level Security requires Enterprise Edition or higher | Integrating a tokenization provider requires Enterprise Edition or higher |
Masking supports segregation of duties. A security or privacy officer chooses which columns to protect, not the object owner, and policies can even stop ACCOUNTADMIN or SECURITYADMIN from seeing data they don't need. You write a policy once and apply it to many columns. If you change the policy body, every column that uses it picks up the change without being re-attached. A column can have only one masking policy at a time. To attach or detach a policy, a role needs the APPLY privilege. To track where policies are set, use the POLICY_REFERENCES view in Account Usage.
Checkpoint 1 of 7· Check yourself
A compliance rule says card numbers must never be stored in Snowflake in readable form, but a few authorized queries must still be able to return the original value. Which approach fits?
With Dynamic Data Masking the data at rest is still plain text. Only External Tokenization keeps tokens in Snowflake and still lets authorized queries reverse them.
“External Tokenization enables accounts to tokenize data before loading it into Snowflake and detokenize the data at query runtime.”Source: docs.snowflake.com
Checkpoint 2 of 7· Exam question
An architect is deciding between an account role and a database role to grant privileges scoped entirely within one database. Which statement correctly distinguishes the two role types?
Correct answer: A — A database role is confined to the database in which it is created and cannot be activated directly in a session, so it must be granted to an account role before a user can use it.
- A. Database roles are scoped to the database that owns them and hold privileges on objects inside it, but a session can only activate account-level roles, so a database role reaches a user by being granted to an account role in the chain.
- B. This is incorrect and reverses the relationship: account roles activate directly in a session, while database roles are the ones that require a grant to an account role before their privileges apply.
- C. This is incorrect because database roles cannot be activated at all, and warehouses are account-level objects, so only an account role can hold USAGE on a warehouse.
- D. This is incorrect because account roles are not confined to a single database; they can hold privileges across any database, schema, or account-level object depending on what has been granted to them.
2.Row-level security with row access policies
A row access policy is a schema-level object that decides which rows of a table or view a query can return. It applies to SELECT and to the rows that UPDATE, DELETE and MERGE select. A simple policy might let one role see all rows. A more complex one looks up a mapping table, for example from tenant or region to the roles allowed to see it. Like masking, row access policies support segregation of duties, and they restrict even the object owner. You can set one policy on many tables and views, and you can change its expression with ALTER ROW ACCESS POLICY without detaching it, so the data stays protected while you edit.
Where the mapping table lives is a design decision. Snowflake recommends one central mapping table, stored in the same database as the protected table. This matters most when the policy calls IS_DATABASE_ROLE_IN_SESSION. Also know the policy's limits. A row access policy filters what users can see, but it does not stop inserts, and it does not stop users from updating or deleting rows they can see.
Checkpoint 3 of 7· Check yourself
A multi-tenant table is protected by a row access policy keyed on TENANT_ID. Which statement is true?
Row access policies control which rows a query returns. Snowflake says explicitly that they do not currently prevent inserts or changes to visible rows.
“Row access policies do not currently prevent rows from being inserted, or prevent visible rows from being updated or deleted.”Source: docs.snowflake.com
Checkpoint 4 of 7· Exam question
During a security review, an auditor asks why the ACCOUNTADMIN role is assigned to only two named users and neither uses it as their default role. Which practice does this configuration reflect?
Correct answer: A — ACCOUNTADMIN should be limited to a small number of trusted users and should not be a default role, so daily object-creation work happens under lower-privileged roles like SYSADMIN.
- A. Snowflake's guidance is to grant ACCOUNTADMIN sparingly, require multi-factor authentication for it, and avoid making it a default role so routine object creation and querying happen under SYSADMIN or custom roles instead.
- B. This is incorrect because Snowflake does not technically prevent ACCOUNTADMIN from being set as a default role; the restriction described is an operational best practice, not a platform limitation.
- C. This is incorrect because PCI DSS does not mandate a specific headcount for ACCOUNTADMIN grants; certification depends on broader control evidence, not a fixed number of admins.
- D. This is incorrect because SECURITYADMIN and ACCOUNTADMIN are independent system roles with no such activation dependency between them.
Sources3
3.Aggregation policies and projection policies
Masking hides individual values, but sometimes the requirement is about query patterns instead. An aggregation policy forces queries to aggregate the data before they return results. Each policy sets a minimum group size, and groups smaller than that are left out of the results, so nobody can isolate a single record. With entity-level privacy you also set an entity key, such as a household ID. The minimum then counts unique entities rather than records, which protects a whole household instead of one row. When a JOIN or UNION uses the same dataset more than once, Snowflake enforces the minimum separately for each reference. A projection policy controls something else: who can use a SELECT statement to project a column. These policies interact in a fixed order. Masking policies run before aggregation policies, so aggregations operate on masked values. Projection policies run after aggregation policies.
Checkpoint 5 of 7· Put it in order
Put these policy types in the order Snowflake enforces them, relative to each other
- 1.Aggregation policies are enforced
- 2.Masking policies are enforced
- 3.Projection policies are enforced
Masking comes before aggregation, so aggregations work on masked data. Projection policies come after aggregation policies.
“Projection policies are enforced after aggregation policies.”Source: docs.snowflake.com
4.Secure views and object tagging
A secure view protects two things: the view's definition, and the data that its optimizations could leak. Snowflake's documentation shows the leak with a division-by-zero filter on a regular view that reveals whether a hidden row exists. To create a secure view, add the SECURE keyword to CREATE VIEW or CREATE MATERIALIZED VIEW. To convert an existing view either way, set or unset SECURE with ALTER. Only users granted the role that owns the view can see its definition. Everyone else gets nothing from SHOW VIEWS, GET_DDL or the Information Schema VIEWS view. The exceptions are roles with IMPORTED PRIVILEGES on the SNOWFLAKE database, ACCOUNTADMIN and the SNOWFLAKE.OBJECT_VIEWER database role, which can read definitions through the Account Usage VIEWS view.
Object tags label Snowflake objects so you can track sensitive data and resource usage. Tags are available in every edition, but some tagging features require Enterprise Edition or higher. You can assign a masking policy to a tag, which is called tag-based masking. An external tokenization policy can be assigned to a tag the same way. The documentation supplied for this lesson does not cover how classification or lineage builds on tags.
Checkpoint 6 of 7· Check yourself
A user has SELECT on secure view V but has not been granted the role that owns V. They run GET_DDL on V. What do they see?
GET_DDL is one of the interfaces that hide a secure view's definition from anyone without the owning role.
“The definition of a secure view is only exposed to authorized users”Source: docs.snowflake.com
5.Editions, compliance and what these sources do not cover
When designing for compliance, start by asking which edition the account needs. The edition matrix splits the features this lesson covers into two groups.
| Feature | Standard | Enterprise and higher |
|---|---|---|
| Object-level access control | Yes | Yes |
| Object tags (some tagging features need Enterprise) | Yes | Yes |
| Column-level Security (masking policies) | No | Yes |
| Row-level Security (row access policies) | No | Yes |
| Aggregation policies and projection policies | No | Yes |
| Periodic rekeying of encrypted data | No | Yes |
For PII and PHI, this lesson's sources describe the controls, not a certification. Tokenization removes sensitive values before they reach Snowflake. Masking keeps privileged administrators from viewing data they don't need. Row access, aggregation and projection policies limit which records and columns a query can expose. The sources do not name the PCI DSS standard, do not list which edition supports PHI or PCI workloads, and do not cover storage integrations or data lineage. Check those against Snowflake's compliance and storage-integration documentation rather than assuming. The nearest thing to dependency tracking in these sources is POLICY_REFERENCES, which lists every object where a given masking policy is set.
Checkpoint 7 of 7· Check yourself
A Standard Edition account wants to connect its existing tokenization provider through Snowflake's External Tokenization. What is required?
External functions are available on their own, but integrating a provider with Snowflake External Tokenization requires Enterprise Edition or higher.
“if you choose to integrate your tokenization provider with Snowflake External Tokenization, you must upgrade to Enterprise Edition or higher.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The mapping table for a row access policy can go in any database, such as a central governance database far from the protected data.Why is that wrong?
Snowflake recommends a central mapping table stored in the same database as the protected table. This matters most when the policy calls IS_DATABASE_ROLE_IN_SESSION.
Covered in Row-level security with row access policies
2.Aggregation policies run on the raw values before masking, so a masked column can still be aggregated in the clear.Why is that wrong?
Masking policies are enforced first, so aggregations only ever see masked values.
Covered in Aggregation policies and projection policies
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“uses masking policies to selectively mask plain-text data in table and view columns at query time.”
↩︎ Column-level security: Dynamic Data Masking and External Tokenization“can prohibit privileged users with the ACCOUNTADMIN or SECURITYADMIN role from unnecessarily viewing data.”
↩︎ Column-level security: Dynamic Data Masking and External Tokenization“A column cannot be attached to multiple masking policies.”
↩︎ Column-level security: Dynamic Data Masking and External Tokenization“The POLICY_REFERENCES view provides a list of all objects in which a masking policy is set.”
↩︎ Editions, compliance and what these sources do not cover - 2.
“External Tokenization makes use of masking policies with external functions.”
↩︎ Column-level security: Dynamic Data Masking and External Tokenization“an external tokenization masking policy can be assigned to a tag to provide tag-based external tokenization.”
↩︎ Secure views and object tagging“Tokenization is the process of removing sensitive data by replacing it with an undecipherable token.”
↩︎ Editions, compliance and what these sources do not cover“External Tokenization enables accounts to tokenize data before loading it into Snowflake and detokenize the data at query runtime.”
↩︎ Checkpoint“if you choose to integrate your tokenization provider with Snowflake External Tokenization, you must upgrade to Enterprise Edition or higher.”
↩︎ Checkpoint - 3.
“A single policy can be set on different tables and views at the same time.”
↩︎ Row-level security with row access policies“create a centralized mapping table and store the mapping table in the same database as the protected table.”
↩︎ Exam trap 1“Snowflake evaluates the policy expression by using the role of the policy owner, not the role of the operator who executed the query.”
↩︎ Prediction“Row access policies do not currently prevent rows from being inserted, or prevent visible rows from being updated or deleted.”
↩︎ Checkpoint - 4.
“Every aggregation policy specifies a minimum group size.”
↩︎ Aggregation policies and projection policies“When an entity key is specified, the minimum group size defines the minimum number of unique entities that must appear in the group”
↩︎ Aggregation policies and projection policies“Masking policies are enforced before aggregation policies.”
↩︎ Exam trap 2“Projection policies are enforced after aggregation policies.”
↩︎ Checkpoint - 5.
“Projection policies that restrict who can use a SELECT statement to project a column.”
↩︎ Aggregation policies and projection policies“Object tags that can be applied to Snowflake objects to help track sensitive data and resource usage.”
↩︎ Secure views and object tagging“Row-level Security to apply row access policies to determine which rows are visible in a query result.”
↩︎ Editions, compliance and what these sources do not cover - 6.
“which allows the user to infer that at least one purple widget exists.”
↩︎ Secure views and object tagging“The definition of a secure view is only exposed to authorized users”
↩︎ Checkpoint