Snowflake Object Tagging and Sensitive Data Classification

1.What a tag is and where you can set it

A tag is a schema-level object. Its name must be unique within its schema. When you assign it to another object you give it a string value, and Snowflake stores the pair as a key and a value. One tag can be set on many object types at once, for example a warehouse and a table. Many tables can share one value, such as cost_center = 'sales', or each can have its own.

Tags are inherited down the securable object hierarchy. A tag on an account flows to its warehouses, and a tag on a table flows to every column in it. This is why tagging works for governance: once you tag tables, views and columns and then query those tags, you can find every object holding sensitive information. Data stewards can then decide how to protect that data. Tags on warehouses do a different job: they group resource usage by cost center or project.

You can set a tag when you create an object (CREATE WAREHOUSE mywarehouse WITH TAG (cost_center = 'sales');) or later (ALTER WAREHOUSE wh1 SET TAG cost_center = 'sales';). For columns, use CREATE TABLE, CREATE VIEW, ALTER TABLE … MODIFY COLUMN, or ALTER VIEW. Snowflake suggests two ways to manage tags. In a centralized approach, a tag_admin custom role both creates and applies tags. In a decentralized approach, tag_admin creates the tags so names stay consistent, and individual teams apply them. In the centralized example, the role gets CREATE TAG on a schema and the global APPLY TAG privilege on the account.

There are quotas. One object can carry at most 50 tags. Separately, all the columns of one table combined can carry at most 50 *different* tags.

CREATE TABLE t1 (
  COL1 INT WITH TAG (tag1='col1', tag2='col1'),
  COL2 INT WITH TAG (tag1='col2')
  )
  WITH TAG (tag3='t1');

Sources1

2.Controlling tag values and automatic propagation

Free-text values cause drift: one team writes Finance, another writes fin. The ALLOWED_VALUES parameter limits a tag to a fixed list of values. A tag can have up to 5,000 values, and each value can be up to 256 characters. Use ALTER TAG … ADD ALLOWED_VALUES or DROP ALLOWED_VALUES to change the list, and call SYSTEM$GET_TAG_ALLOWED_VALUES to see it.

CREATE TAG cost_center ALLOWED_VALUES 'finance', 'engineering';

The PROPAGATE parameter makes a tag follow data and dependencies automatically, so a sensitivity label on a source also reaches what is built from it. If propagation is on, the order of values in the allowed list can decide which value wins when propagated values conflict. Creating and setting tags works on every edition. Tag propagation and tag-based masking policies require Enterprise Edition or higher.

CREATE TAG data_sensitivity PROPAGATE =  ? ;

Sources21

3.Monitoring tags: how did this tag get here?

Snowflake can attach a tag in five ways. Someone sets it manually with CREATE or ALTER. The object inherits it from higher in the hierarchy. It propagates from an object this one depends on, or from an object whose data moved here. Classification sets it on a column found to hold sensitive data. Or it comes along when a table is created with CREATE TABLE … LIKE or CREATE TABLE … CLONE.

When you audit tags, the method usually matters as much as the value. A propagated sensitivity tag tells you the data came from a sensitive source. Several views and functions expose an apply_method column that records how each tag was attached: the ACCOUNT_USAGE.TAG_REFERENCES view, the INFORMATION_SCHEMA.TAG_REFERENCES and TAG_REFERENCES_ALL_COLUMNS functions, and ACCOUNT_USAGE.TAG_REFERENCES_WITH_LINEAGE.

SELECT tag_name, tag_value, apply_method, level, domain FROM TABLE(my_db.INFORMATION_SCHEMA.TAG_REFERENCES('my_table', 'TABLE'));

Snowsight also has a Governance & security » Tags & policies area with a dashboard and a Tagged Objects tab for filtering. It needs Enterprise Edition or higher, plus either ACCOUNTADMIN or a role granted the GOVERNANCE_VIEWER and OBJECT_VIEWER database roles.

Sources12

4.Sensitive data classification: tags applied for you

Manual tagging only works if someone already knows where the sensitive data is. Sensitive data classification finds it automatically. Each column classified as sensitive gets two labels. The semantic category says what kind of personal attribute it is, such as a name, an address or a national identifier. Snowflake provides native categories, and you can add custom ones. The privacy category says how sensitive it is: IDENTIFIER, QUASI_IDENTIFIER or SENSITIVE.

Snowflake records these results as two system-defined tags, SNOWFLAKE.CORE.SEMANTIC_CATEGORY and SNOWFLAKE.CORE.PRIVACY_CATEGORY. A tag map links your own tags to these system tags. For example, whenever SEMANTIC_CATEGORY = 'NAME' is applied, Snowflake also applies tag_db.sch.pii = 'Highly confidential'. As a result, your existing tag-driven monitoring picks up newly found sensitive columns without extra work.

Classification settings are saved in a classification profile. You can create one in the Trust Center or with SQL. With SQL, associating the profile with a database to start classification is a separate step. A profile can also turn on AI mode, which uses the openai-gpt-5-mini model to find more semantic categories. Tags lead directly to protection: if a tag-based masking policy is attached to a user-defined tag, columns are masked as soon as classification applies that tag. This works for new data as it arrives.

Sources3

5.Monitoring what classification covers and costs

Using classification to monitor data starts with knowing what is being classified. When a database is associated with a classification profile, Snowflake classifies all the tables and views in it automatically. One caveat: views are excluded by default. In Snowsight, go to Governance & security » Trust Center, then Data Security, then Dashboard, and find the *Databases monitored by classification* tile. It lists databases as Monitored or Partially monitored. A database is *partially monitored* when someone used SQL to set a profile on a schema instead of on the whole database. To get the same list in SQL:

SELECT SYSTEM$SHOW_SENSITIVE_DATA_MONITORED_ENTITIES('DATABASE');

Classification runs on serverless compute and consumes credits. AI mode adds token charges on top. Classifying a view can cost more than classifying a table, depending on how complex the view's query is. Materialized views don't carry this extra cost. To see spending, open Admin » Cost management, choose Consumption, and filter by the *Sensitive Data Classification* service type. You can also query METERING_HISTORY in ACCOUNT_USAGE.

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Object tagging as a whole requires Enterprise Edition.Why is that wrong?

   Any edition can create and set tags. Only advanced features, namely tag propagation and tag-based masking policies, require Enterprise Edition or higher.

   Covered in Controlling tag values and automatic propagation

2. 2.Associating a database with a classification profile means every view in it is classified too.Why is that wrong?

   Views are left out of classification unless you include them, partly because classifying a view can cost more than classifying a table.

   Covered in Monitoring what classification covers and costs

3. 3.Creating a classification profile with SQL starts classification right away.Why is that wrong?

   With SQL, associating the profile with a database is a separate step, and that step is what starts classification.

   Covered in Sensitive data classification: tags applied for you