What you will be able to do
- Use OBJECT_DEPENDENCIES for impact analysis and know which dependencies it does not record
- Tell apart the direct_objects_accessed, base_objects_accessed and objects_modified fields in ACCESS_HISTORY
- Describe how DMFs, expectations, anomaly detection and the DMF schedule fit together in data quality checks
1.Object dependencies and impact analysis
Lineage starts with structure: which objects are built on which. Snowflake records these relationships in the Account Usage view OBJECT_DEPENDENCIES. In create view myview as select * from mytable;, the view is the referencing object and the table is the referenced object, because the table has to exist for the view to be created. Each dependency also has a type: it is tracked by name, by internal ID, or by both.
| Referencing object | Referenced object | Dependency type |
|---|---|---|
| View, dynamic table, SQL UDF, SQL UDTF | View, dynamic table, UDF, UDTF and other objects referenced by name | BY_NAME |
| External Stage | Storage Integration | BY_ID |
| Stream | Table, View, Secure View | BY_ID |
| External table | Stage | BY_ID |
| Materialized View | Table, External Table | BY_NAME_AND_ID |
Here is how impact analysis works in practice. A table owner plans to add a column. They query OBJECT_DEPENDENCIES for that table to find every view that would be affected, then schedule the changes so no queries break. Compliance officers run the same query to trace sensitive sources to their targets, for example under GDPR.
SELECT referencing_object_name, referencing_object_domain, referenced_object_name, referenced_object_domain FROM snowflake.account_usage.object_dependencies WHERE referenced_object_name = 'SALES_STAGING_TABLE' and referenced_object_domain = 'EXTERNAL TABLE';The view has known gaps:
- It does not record dependencies that Snowflake handles internally, such as a table cloned from another table.
- It only tracks Snowflake objects, so a dependency on an S3 bucket does not appear.
- It does not record replication.
- It misses objects called from inside a function, such as a stage passed to get_presigned_url.
- It cannot compute dependencies accurately when a definition uses session parameters.
- For BY_NAME_AND_ID dependencies, a CREATE OR REPLACE or a rename breaks the reference, and only the dependency from before the change is recorded.
Checkpoint 1 of 7· Check yourself
Which of these dependencies would you find in OBJECT_DEPENDENCIES?
A view selecting from a table is a standard BY_NAME dependency. Clones, external buckets and replication are all listed limitations.
“the view does not record the dependency necessary to create a new table from the clone of another table.”Source: docs.snowflake.com
Checkpoint 2 of 7· Exam question
A data engineer wants every column later classified and tagged `pii_email` across dozens of tables to automatically inherit the same masking behavior, without editing each column after classification runs. Which approach achieves this?
Correct answer: A — Create the masking policy once, then assign it directly to the tag with `ALTER TAG pii_email SET MASKING POLICY email_mask`, so every tagged column enforces it automatically.
- A. A masking policy assigned to a tag applies to every column carrying that tag, so newly classified columns pick up the masking behavior the moment they are tagged. This is the tag-based masking mechanism Snowflake governance relies on for scale.
- B. Attaching the policy column-by-column works but requires a manual ALTER for every table, which defeats the goal of automatic coverage as new columns get classified over time.
- C. Row access policies filter which rows a query returns; they do not redact or transform a column's value, so they cannot substitute for column-level masking of email data.
- D. Managing per-role SELECT grants does not mask the underlying value and creates a brittle privilege matrix that has to be maintained manually as roles and tables change.
Sources1
2.Access History: who read and wrote which columns
OBJECT_DEPENDENCIES shows how objects are built. Access History shows what queries actually did. It records reads, and it records writes such as INSERT, UPDATE, DELETE and COPY variants, from source objects to target objects. You query it through the ACCESS_HISTORY view in the ACCOUNT_USAGE and ORGANIZATION_USAGE schemas. Each row is one SQL statement, and each row includes the user who issued it. That connection between user, query, object, column and data is what makes it useful for audits, for example to find who performed a write on a table and when.
Each record covers three kinds of column: - source columns the query read directly or indirectly - projected columns that appear in the result - columns that shaped the result without being projected, such as WHERE-clause filters
| Column | What it records |
|---|---|
| direct_objects_accessed | Objects named directly in the query, either explicitly or through shortcuts such as * |
| base_objects_accessed | All base data objects needed to run the query, including columns, UDFs and stored procedures |
| objects_modified | Objects involved in a write operation in the query |
Example: view v1 selects c1 and c2 from table t and filters on c3. Columns C1 and C2 are source columns that the view reads directly, so they are recorded in base_objects_accessed. Column lineage extends the view to writes. It follows data from source columns to target columns through INSERT, MERGE and CTAS, across every later object that uses that data, as long as none of the objects in the chain are dropped.
Checkpoint 3 of 7· Match them up
Match each ACCESS_HISTORY field to what it captures
Tap a term, then the definition that fits it.
direct_objects_accessed reflects what the query text names. base_objects_accessed reflects the underlying objects the query needed. objects_modified covers writes.
“A JSON array of all base data objects to execute a query, including columns, external functions, UDFs, and stored procedures.”Source: docs.snowflake.com
Checkpoint 4 of 7· Exam question
An auditor asks a data engineer to list every table and view in the account where the tag `cost_center` has been applied, along with the tag value on each object. Which query approach should the engineer use?
Correct answer: A — Query `SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES`, filtering on `tag_name = 'COST_CENTER'` to return every object and its assigned tag value across the account.
- A. TAG_REFERENCES in ACCOUNT_USAGE records every object a tag has been assigned to along with the value set on it, which is exactly the account-wide inventory the auditor is asking for.
- B. DDL comments are free text and unrelated to the tag object; scanning them manually would miss objects tagged without a matching comment and does not query tag metadata at all.
- C. Searching column names for a literal string finds columns named after cost centers, not objects carrying the `cost_center` tag, so it misses tagged tables entirely and returns false positives.
- D. Grants describe role privileges, not tag assignments, so this view cannot answer which objects carry a particular tag or what value was set on them.
Checkpoint 5 of 7· Exam question
A compliance team needs to trace how a `region` tag applied to a raw table propagates when that table feeds a chain of downstream views used for reporting. Which mechanism gives them that lineage of tag propagation?
Correct answer: A — Query `SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES_WITH_LINEAGE`, which links a tagged object to the downstream objects that inherit the tag through dependencies.
- A. TAG_REFERENCES_WITH_LINEAGE is purpose-built to show how a tag on a source object propagates to the downstream objects that depend on it, which is the propagation trace the compliance team needs.
- B. TAG_REFERENCES only reports direct assignments on the object queried; manually joining per-view results across many objects is slow, error-prone, and does not represent an actual lineage feature.
- C. Time Travel reconstructs historical data and metadata states of a single object, not the dependency chain between that object and downstream views, so it cannot show tag propagation.
- D. Cloning copies the tags present on the source object at clone time, but it says nothing about whether existing downstream views inherit tag context, so it does not answer the lineage question.
3.Monitoring data quality with DMFs and expectations
Lineage tells you where data came from. Data quality checks tell you whether the data is still fit to use. A Snowflake data quality check is built from parts: - A data metric function (DMF) measures an attribute, such as the number of NULLs in a column. It does not decide whether that number is a problem. Snowflake provides system DMFs for common metrics, and you can write custom DMFs for others. - An expectation compares the DMF's result with a threshold. Results that fail are reported as expectation violations.
Cortex Data Quality can suggest checks for you based on your metadata and usage patterns.
| Part | Role |
|---|---|
| DMF | Measures an attribute of the data and returns a value |
| Expectation | Combined with a DMF to decide pass or fail and report violations |
| Anomaly detection | Uses history to flag DMF values outside a predicted range (currently volume and freshness) |
| DMF schedule | How often DMFs run on a table or view (hourly by default). It does not affect anomaly checks |
Checkpoint 6 of 7· Match them up
Match each part to its job
Tap a term, then the definition that fits it.
A DMF measures, an expectation judges, anomaly detection compares against a range predicted from history, and the schedule controls how often checks run.
“An expectation is combined with a DMF to create a data quality check.”Source: docs.snowflake.com
Where DMFs can run. You can set a DMF on tables (including temporary and transient tables), views, materialized views, dynamic tables, event tables, external tables and Iceberg tables. You cannot set one on hybrid tables, streams, object tags, shared tables or views, or reader-account objects. Trial accounts don't support DMFs, and an account can have at most 50,000 DMF associations.
What it costs. Scheduled DMFs run on serverless compute and are billed under "Data Quality Monitoring". Calling a DMF yourself in a SELECT costs nothing extra. To track the spend, query DATA_QUALITY_MONITORING_USAGE_HISTORY.
Checkpoint 7 of 7· Check yourself
A team wants to set a DMF on each of these objects. Which one is not supported?
Hybrid tables and streams are explicitly excluded. The other three are on the supported list.
“You cannot set a DMF on a hybrid table or a stream object.”Source: docs.snowflake.com
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.base_objects_accessed holds only the objects literally named in the query.Why is that wrong?
Objects named in the query, explicitly or through *, go in direct_objects_accessed. base_objects_accessed holds all the base data objects needed to run the query.
2.Every call to a DMF, including an ad hoc SELECT, is billed as Data Quality Monitoring.Why is that wrong?
You are billed only when a scheduled DMF runs on an object. Calling a DMF manually is not billed.
Covered in Monitoring data quality with DMFs and expectations
3.OBJECT_DEPENDENCIES shows a Snowflake object's dependency on the external cloud storage behind it.Why is that wrong?
The view tracks Snowflake objects only, so a dependency on an S3 bucket is not recorded.
Covered in Object dependencies and impact analysis
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Snowflake tracks object dependencies in the Account Usage view OBJECT_DEPENDENCIES.”
↩︎ Object dependencies and impact analysis“Snowflake refers to the view named myview as the referencing object and the table mytable as the referenced object.”
↩︎ Object dependencies and impact analysis“Querying the OBJECT_DEPENDENCIES view based on the table name returns all of the objects (e.g. views) that will be affected.”
↩︎ Object dependencies and impact analysis“Snowflake tracks object dependencies for Snowflake objects only.”
↩︎ Exam trap 3“the view does not record the dependency necessary to create a new table from the clone of another table.”
↩︎ Checkpoint - 2.
“Each row in the ACCESS_HISTORY view contains a single record per SQL statement.”
↩︎ Access History: who read and wrote which columns“The user access history can be found by querying the ACCESS_HISTORY view in the ACCOUNT_USAGE and ORGANIZATION_USAGE schemas.”
↩︎ Access History: who read and wrote which columns“Columns C1 and C2 are source columns that the view accesses directly, which are recorded in the base_objects_accessed column of the ACCESS_HISTORY view.”
↩︎ Access History: who read and wrote which columns“Snowflake tracks the data from the source columns through all subsequent table objects that reference data from the source columns (e.g. INSERT, MERGE, CTAS)”
↩︎ Access History: who read and wrote which columns - 3.
“A JSON array that specifies the objects that were associated with a write operation in the query.”
↩︎ Access History: who read and wrote which columns“directly named in the query explicitly or through shortcuts such as using an asterisk”
↩︎ Exam trap 1“A JSON array of all base data objects to execute a query, including columns, external functions, UDFs, and stored procedures.”
↩︎ Checkpoint - 4.
“doesn’t define whether that value constitutes a data quality issue; a DMF is a building block of a data quality check.”
↩︎ Monitoring data quality with DMFs and expectations“Currently, Snowflake can automatically detect anomalies in the volume and freshness of your data.”
↩︎ Monitoring data quality with DMFs and expectations“By default, the DMF schedule runs a DMF once every hour.”
↩︎ Monitoring data quality with DMFs and expectations“You are not billed for unscheduled data metric function usage, such as calling a DMF with a SELECT statement.”
↩︎ Exam trap 2“An expectation is combined with a DMF to create a data quality check.”
↩︎ Checkpoint“You cannot set a DMF on a hybrid table or a stream object.”
↩︎ Checkpoint