Object Tagging, Data Classification & Trust Center in Snowflake
Sub-objective 2.2 lists three governance features that work together but answer different questions. Object tagging labels objects with metadata. Data classification auto-detects which columns hold sensitive data and tags them for you. Trust Center evaluates the whole account against security best practices. Two of these are direct C03 sample-question topics. Classification is sample question one, Trust Center is sample question three. Tagging is the layer that ties yesterday’s tag-based masking from Day 23 to today’s classification.
Today’s Concept
Micro-Concept 1: Object Tagging, Metadata for Governance
A tag is a schema-level object that stores a string label. You attach it to another object as a key and value pair. The key is the tag name. The value is whatever string you assign at the point of attachment.
Tags attach to almost anything: an account, a database, a schema, a table, a view, a column, a warehouse, even a user. You create one with CREATE TAG and attach it with ALTER ... SET TAG. One tag definition can be reused across thousands of objects with different values each time.
Two functions read tags back. SYSTEM$GET_TAG returns the value on one object. The TAG_REFERENCES table function lists every object carrying a tag. Tagging powers two governance jobs: finding sensitive data later, and driving the tag-based masking you met on Day 23.
Snowflake supports two operating models. A centralized model gives one tag_admin role the power to create and apply every tag. A decentralized model lets teams apply tags while the admin role still owns tag creation, keeping names consistent. Both appear in scenario questions about who should own tagging.
Micro-Concept 2: Tag Inheritance, Also Called Tag Lineage
Tag inheritance follows the securable object hierarchy. A descendant inherits any tag set on an ancestor. Tag a database, and every schema, table, and column inside it carries that tag. This single behaviour is why one tag can cover a huge surface.
Snowflake calls this propagation down the container hierarchy tag lineage. Tag a table, and all of its columns inherit the tag automatically. You do not re-apply it per column. The inherited value flows from the highest point where the tag was set.
An inherited value can be overridden lower down. Set the same tag explicitly on a column with a more specific value, and that value wins for the column. This is the same most-specific-wins idea as parameter precedence on Day 6, applied to metadata instead of settings.
One limit catches careful candidates. Inheritance does not reach nested objects built from a tagged object. A materialized view does not inherit tags from the base table it reads. That requires automatic tag propagation, a separate feature, not plain inheritance.
To audit tags with inheritance included, use TAG_REFERENCES_WITH_LINEAGE in the ACCOUNT_USAGE schema. The plain TAG_REFERENCES view shows only direct assignments. The lineage version shows direct plus inherited. The exam tests which one surfaces inherited tags.
Micro-Concept 3: Data Classification, Auto-Detecting Sensitive Columns
Data classification scans a table and identifies columns that hold personal data. It samples the column values, matches them against known patterns, and recommends a category. This is the feature behind C03 sample question one, where a compliance analyst needs to find sensitive data automatically.
Classification assigns two system tags to each detected column. The SEMANTIC_CATEGORY tag names the type of data, such as NAME or EMAIL. The PRIVACY_CATEGORY tag names the sensitivity, one of IDENTIFIER, QUASI_IDENTIFIER, or SENSITIVE.
-- Analyze a table and return recommended categories
SELECT EXTRACT_SEMANTIC_CATEGORIES('my_db.my_schema.customers');
-- Apply the recommended system tags to the columns
CALL ASSOCIATE_SEMANTIC_CATEGORY_TAGS(
'my_db.my_schema.customers',
EXTRACT_SEMANTIC_CATEGORIES('my_db.my_schema.customers'));Two facts matter here. The EXTRACT_SEMANTIC_CATEGORIES function needs a running warehouse, because it samples and scans data. And classification is an Enterprise Edition feature, the same floor as masking and tagging.
The newer way to run classification is a classification profile, created with SNOWFLAKE.DATA_PRIVACY.CLASSIFICATION_PROFILE. A profile classifies data automatically on a schedule and can be configured from the Trust Center interface. The function-based path above still works and is easier to demonstrate in a single lab.
Classification connects straight to Day 23. Once a column carries a classification tag, a tag-based masking policy keyed on that tag protects it with no per-column work. Detect, tag, mask: the tag is the bridge between finding sensitive data and protecting it.
Micro-Concept 4: Trust Center, Evaluating Your Security Posture
Trust Center is a built-in tool that checks your account against security best practices. It lives in Snowsight under Governance and security. This is the feature behind C03 sample question three, where the requirement is to evaluate the account against security recommendations.
The engine is a set of scanners. A scanner is a background process that inspects account configuration or activity for risk. Scanners are grouped into scanner packages. The findings appear as violations, each with a plain explanation and a suggested fix.
Three packages appear in questions. Security Essentials is the only package enabled by default. CIS Benchmarks checks the account against the Center for Internet Security Snowflake benchmarks. Threat Intelligence surfaces risks from anomalous activity. The other two stay off until an admin enables them.
Access is role-gated. The SNOWFLAKE.TRUST_CENTER_ADMIN application role manages scanners and schedules. The SNOWFLAKE.TRUST_CENTER_VIEWER role reads findings only. Trust Center reads metadata to confirm a configuration exists. It does not prove that the configuration is effective, a distinction worth keeping straight.
Micro-Concept 5: Data Lineage Through ACCESS_HISTORY
The fourth governance question in this area is data lineage: knowing what data was read and written, and how it flowed. The answer in Snowflake is the ACCESS_HISTORY view in the ACCOUNT_USAGE schema. It records the read and write history of objects touched by queries.
ACCESS_HISTORY requires Enterprise Edition or higher. This is verified by a SnowPro practice question on the minimum edition for the view. Standard accounts cannot use it, which is itself a recurring trap when a stem lists features by edition.
The view ties governance together. Tags tell you which columns are sensitive. Classification finds them. Masking and row access protect them. ACCESS_HISTORY then tells you who actually queried them, and column-level lineage shows where the data moved. Day 27 returns to this view for cost and audit work.
Cheat Sheet
| Topic | What to remember | Exam keyword |
|---|---|---|
| Tag basics | Schema-level object. A key plus a string value. Attaches to objects, columns, even users | “Metadata label” |
| Tag inheritance | Descendant inherits ancestor’s tag. Table tag flows to all its columns | “Tag lineage” |
| Override | Set the tag explicitly lower down with a more specific value. Most-specific wins | “Override inherited value” |
| Nested-object limit | A materialized view does NOT inherit the base table’s tags. That needs auto propagation | “No nested inheritance” |
| Audit with inheritance | TAG_REFERENCES_WITH_LINEAGE includes inherited tags. TAG_REFERENCES shows direct only | “With lineage” |
| Data classification | Auto-detects sensitive columns by sampling values. Needs a running warehouse | “Auto-detect PII” |
| Classification tags | Applies SEMANTIC_CATEGORY (type) and PRIVACY_CATEGORY (IDENTIFIER / QUASI_IDENTIFIER / SENSITIVE) | “Two system tags” |
| Trust Center | Evaluates the account against best practices using scanners in scanner packages | “Security posture” |
| Default package | Security Essentials is on by default. CIS Benchmarks and Threat Intelligence start off | “Security Essentials” |
| Trust Center roles | TRUST_CENTER_ADMIN manages scanners. TRUST_CENTER_VIEWER reads findings | “Admin manages scanners” |
| Data lineage | ACCESS_HISTORY in ACCOUNT_USAGE records reads and writes. Enterprise+ only | “ACCESS_HISTORY” |
Exam Tip
This area hands you two sample-question answers if you match the verb in the stem to the right feature.
The classification verb. When a stem says “automatically detect” or “discover sensitive columns” or “identify PII without manual review”, the answer is data classification. Sample question one frames a compliance analyst this way. Watch for the word “automatically”, which points to classification, not to masking or manual tagging.
The Trust Center verb. When a stem says “evaluate the account against security recommendations” or “check configuration against best practices”, the answer is Trust Center. Sample question three is exactly this. Do not confuse it with ACCOUNT_USAGE, which stores raw history rather than scoring your posture.
The inheritance trap. A scenario tags a database and asks what the columns show. The columns inherit the database tag. Then a column is tagged directly with a different value, and that more specific value wins for the column. Pick the answer where the explicit column value overrides the inherited one.
Hands-On Lab
lab_xs warehouse from Day 1. Run as ACCOUNTADMIN unless a step says otherwise.Set up a lab table with sensitive columns.
USE ROLE ACCOUNTADMIN;
USE WAREHOUSE lab_xs;
CREATE DATABASE IF NOT EXISTS day24_lab;
CREATE SCHEMA IF NOT EXISTS day24_lab.gov;
USE SCHEMA day24_lab.gov;
CREATE OR REPLACE TABLE class_test (
id INT, full_name STRING, email STRING, ssn STRING);
INSERT INTO class_test VALUES
(1, 'Alice Stone', '[email protected]', '123-45-6789'),
(2, 'Bob Reyes', '[email protected]', '987-65-4321'),
(3, 'Carol Diaz', '[email protected]', '555-11-2222');
SELECT * FROM class_test;full_name, email, and ssn all hold personal data. This is the table classification will scan in Step 4. For now it carries no tags.Create a user-defined tag and attach it to a column.
CREATE OR REPLACE TAG pii_tag
ALLOWED_VALUES 'low', 'high';
ALTER TABLE class_test
MODIFY COLUMN ssn SET TAG pii_tag = 'high';
-- Read the value back on the column
SELECT SYSTEM$GET_TAG('pii_tag', 'day24_lab.gov.class_test.ssn', 'COLUMN');SYSTEM$GET_TAG returns high for the ssn column. The ALLOWED_VALUES clause restricts which strings the tag accepts, which keeps tagging consistent across teams.Prove tag inheritance and then override it. Tag the table, watch a column inherit, then set a more specific value.
-- Set the tag on the whole table
ALTER TABLE class_test SET TAG pii_tag = 'low';
-- email inherits 'low' from the table
SELECT SYSTEM$GET_TAG('pii_tag', 'day24_lab.gov.class_test.email', 'COLUMN');
-- Override on email with a more specific value
ALTER TABLE class_test
MODIFY COLUMN email SET TAG pii_tag = 'high';
SELECT SYSTEM$GET_TAG('pii_tag', 'day24_lab.gov.class_test.email', 'COLUMN');email returns low, inherited from the table tag. After the explicit column tag, the second read returns high. The more specific column value wins. That is most-specific-wins applied to metadata.Run data classification. Let Snowflake detect the sensitive columns for you.
-- Needs a running warehouse: it samples the data
SELECT EXTRACT_SEMANTIC_CATEGORIES('day24_lab.gov.class_test');full_name comes back with a recommended NAME semantic category, email with EMAIL, ssn with a national-identifier category, each at a confidence level. The id column is not flagged. Snowflake found the personal data without you naming it.Apply the classification tags automatically. Turn the recommendations into system tags.
CALL ASSOCIATE_SEMANTIC_CATEGORY_TAGS(
'day24_lab.gov.class_test',
EXTRACT_SEMANTIC_CATEGORIES('day24_lab.gov.class_test'));
-- See the system tags that classification applied
SELECT * FROM TABLE(
day24_lab.INFORMATION_SCHEMA.TAG_REFERENCES_ALL_COLUMNS(
'day24_lab.gov.class_test', 'TABLE'));SNOWFLAKE.CORE.SEMANTIC_CATEGORY and SNOWFLAKE.CORE.PRIVACY_CATEGORY tags now sitting on the columns. A tag-based masking policy keyed on these tags would now protect them automatically, the bridge back to Day 23.Visit Trust Center. This step is in the Snowsight UI, not SQL.
Cleanup. Unset tags from columns, then drop the lab database and the tag.
USE ROLE ACCOUNTADMIN;
USE SCHEMA day24_lab.gov;
-- Drop the database: this removes the table and its tag assignments
DROP DATABASE IF EXISTS day24_lab;
-- pii_tag lived in the dropped schema, so it is gone with the database
-- Verify the Day 1 warehouse survives for tomorrow
SHOW WAREHOUSES LIKE 'LAB_XS';DROP DATABASE removes the table, the user-defined pii_tag, and every tag assignment inside the database in one step. The system classification tags live in SNOWFLAKE.CORE and are never dropped. The day10_orders table from Day 10 is untouched. lab_xs stays for tomorrow.Snowflake Documentation
Official docs for today’s topics. The exam pulls directly from these.
External References
Community resources to reinforce today’s concepts.
Practice Questions
Options:
A. Data classification
B. Dynamic data masking
C. Object tagging applied manually
D. Row access policies
Why A: Data classification samples column values and automatically detects personal data, then recommends semantic and privacy categories. The word “automatically detect” points straight to classification.
Why not B: Masking hides values in a column you already chose. It does not discover which columns are sensitive.
Why not C: Manual tagging is the work classification removes. The requirement explicitly rules out column-by-column review.
Why not D: Row access policies filter rows by role. They do nothing to identify sensitive columns.
Options:
A. The ACCOUNT_USAGE schema
B. Trust Center
C. A resource monitor
D. Object tagging
Why B: Trust Center runs scanners that check the account against best practices, including CIS Benchmarks, and reports violations with suggested fixes. That is exactly “evaluate against security recommendations”.
Why not A: ACCOUNT_USAGE stores raw usage and access history. It does not score posture or recommend fixes.
Why not C: A resource monitor tracks credit consumption, not security configuration. Re-read Day 26 if this felt close.
Why not D: Tagging labels objects with metadata. It does not assess account security.
Options:
A. A tag set on a table is inherited by all columns of that table
B. An inherited tag value cannot be changed on a child object
C. Setting the tag explicitly on a column with a more specific value overrides the inherited value
D. A materialized view automatically inherits the tags of the base table it reads
E. Tag inheritance is only available in Business Critical Edition
Why A: Inheritance flows down the securable object hierarchy. A table tag reaches every column in the table without re-applying it.
Why C: The most specific assignment wins. An explicit column value overrides the value inherited from the table.
Why not B: The opposite is true. The whole point of override is that a child can carry a more specific value.
Why not D: Inheritance does not reach nested objects. A materialized view needs automatic tag propagation, a separate feature.
Why not E: Tagging and inheritance require Enterprise Edition, not Business Critical.
Options:
A. QUERY_HISTORY, available in all editions
B. ACCESS_HISTORY, requiring Enterprise Edition
C. TAG_REFERENCES, available in all editions
D. LOGIN_HISTORY, requiring Business Critical Edition
Why B: ACCESS_HISTORY records the read and write history of objects and supports column-level lineage. Its documented minimum is Enterprise Edition.
Why not A: QUERY_HISTORY shows the queries themselves but not the object-level read and write lineage ACCESS_HISTORY provides.
Why not C: TAG_REFERENCES lists tag assignments. It does not track who read the data or how it flowed.
Why not D: LOGIN_HISTORY tracks authentication events, not data access, and it is not gated to Business Critical.
Options:
A. Classification assigns a SEMANTIC_CATEGORY tag that names the type of data, such as NAME or EMAIL
B. Classification assigns a PRIVACY_CATEGORY tag whose values include IDENTIFIER and SENSITIVE
C. Classification masks the detected columns automatically with no further setup
D. Classification runs on Standard Edition and needs no warehouse
E. Classification renames the detected columns to flag them as sensitive
Why A: The semantic category names the type of personal attribute, for example NAME or EMAIL, applied as the SEMANTIC_CATEGORY system tag.
Why B: The privacy category names the sensitivity. Its values are IDENTIFIER, QUASI_IDENTIFIER, and SENSITIVE.
Why not C: Classification only tags columns. Protection still needs a masking policy, though a tag-based policy can key off the classification tag. Re-read Day 23 if missed.
Why not D: Classification is Enterprise+ and the extract function needs a running warehouse to sample data.
Why not E: Classification never renames columns. It attaches tags and leaves names and data unchanged.
Today you learned: Object tagging attaches a metadata label, a key and a string value, to objects and columns. Tags inherit down the securable hierarchy, so a table tag reaches all its columns. A more specific value set lower down overrides the inherited one. Inheritance stops at nested objects like materialized views, which need automatic tag propagation instead.
Data classification auto-detects sensitive columns by sampling values, then applies two system tags: SEMANTIC_CATEGORY for the type and PRIVACY_CATEGORY for the sensitivity. It needs a running warehouse and Enterprise Edition. This is sample question one. Trust Center evaluates the account against best practices using scanners grouped into packages, with Security Essentials on by default. This is sample question three.
Data lineage comes from the ACCESS_HISTORY view in ACCOUNT_USAGE, an Enterprise+ feature that records reads and writes. Together these features detect, label, protect, and audit sensitive data, building on the tag-based masking from Day 23.
Tomorrow (Day 25): Encryption, Replication, Failover, and Alerts and Notifications. Encryption is always-on in every edition, the trap that catches candidates who assume it is Enterprise-only. Tri-Secret Secure raises the floor to Business Critical. You will also meet CREATE ALERT and notification integrations, two sub-objective 2.2 items that are easy to overlook.
