What you will be able to do
- Tell Trust Center violations apart from detections, and know which application role each task needs
- Describe Snowflake's hierarchical key model, key rotation and Tri-Secret Secure
- Explain how an alert's condition triggers its action and how alerts send notifications
- Name the replication and failover objects and the business continuity scenarios they support
- Tell the two relationship types in data lineage apart
1.Trust Center: scanners, violations and detections
Trust Center is where you evaluate, monitor and reduce security risk in a Snowflake account. It runs scanners, grouped into scanner packages, that check the account against recommendations. A scanner can produce findings, but a run that finds no concern produces none. The Overview tab summarises the account's security posture and can generate a PDF posture report. You can also set up proactive notifications. Reader accounts are not supported.
| Aspect | Violation | Detection |
|---|---|---|
| What it represents | A configuration that does not meet a scanner's requirements | An event that happened at a specific time |
| Duration | Persists over time until the configuration changes | Occurs once |
| Remediation | Change the configuration, then the next scanner run clears it | Not directly possible; investigate and prevent similar events |
| Lifecycle | Can be triaged, resolved or reopened on the Violations tab | Cannot currently be managed |
Access is controlled through two application roles in the SNOWFLAKE database, which a user with ACCOUNTADMIN grants. In an organization account, GLOBALORGADMIN grants them instead. SNOWFLAKE.TRUST_CENTER_VIEWER is enough to view the Overview, Violations, Detections and AI Security tabs. SNOWFLAKE.TRUST_CENTER_ADMIN is needed to manage scanners and scanner packages and to manage the lifecycle of violation findings. When you mark a violation Resolved, its email notifications stop, but that is a status change. The finding only goes away once you actually fix the configuration.
USE ROLE ACCOUNTADMIN;
CREATE ROLE trust_center_admin_role;
GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_ADMIN TO ROLE trust_center_admin_role;
CREATE ROLE trust_center_viewer_role;
GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_VIEWER TO ROLE trust_center_viewer_role;Checkpoint 1 of 8· Check yourself
A team needs to turn scanner packages on and off and change which scanners run. What is the minimum application role it needs?
Viewing findings needs only TRUST_CENTER_VIEWER. Managing scanners and scanner packages needs TRUST_CENTER_ADMIN.
“a user with the ACCOUNTADMIN role must grant the SNOWFLAKE.TRUST_CENTER_VIEWER or SNOWFLAKE.TRUST_CENTER_ADMIN application role to your role.”Source: docs.snowflake.com
Sources1
2.Encryption key management and Tri-Secret Secure
All Snowflake customer data is encrypted by default with AES. You don't configure anything: Snowflake manages the keys, rotates them on a regular basis, and can re-encrypt (rekey) customer data periodically. The keys form a hierarchy rooted in a hardware security module hosted by the cloud provider. In this hierarchy each parent key encrypts, or wraps, the keys in the layer below.
The model has four levels: the root key, account master keys, table master keys and file keys. Each account has its own separate hierarchy, which isolates accounts from one another. A table master key encrypts a single table and a file key encrypts a single file, so each key protects a limited amount of data.
Keys in the Snowflake-managed hierarchy are rotated automatically when they are more than 30 days old. Rotation retires the active key and creates a new one. Only the active key encrypts new data. A retired key is used solely to decrypt data it already protects, and Snowflake destroys it once it is no longer needed. Rotation moves a key from active to retired. Rekeying moves it from retired to destroyed: if periodic rekeying is enabled, when a table's retired key is older than one year, Snowflake creates a new key and re-encrypts the data that the retired key protected. Periodic rekeying is available for Enterprise Edition accounts, where ACCOUNTADMIN enables it. Rekeying runs online in the background without affecting running workloads.
ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = TRUE;Customers who want a key of their own can enable Tri-Secret Secure. Their customer-managed key, held in the key management service of the cloud platform that hosts the account, is combined with a Snowflake-maintained key to create a composite master key. If the customer-managed key is revoked, Snowflake can no longer decrypt the data.
Checkpoint 2 of 8· Check yourself
What does enabling Tri-Secret Secure change?
Encryption is always on. Tri-Secret Secure adds a customer-managed key to the Snowflake-maintained key to form a composite master key.
“the combination of a Snowflake-maintained key and a customer-managed key creates a composite master key to protect customer data in Snowflake”Source: docs.snowflake.com
Sources2
3.Masking policies: conditional and tag-based
Dynamic Data Masking is a column-level security feature. A masking policy is a schema-level object that masks column data at query time, so the stored data is not changed. Row-level security works differently: a row access policy decides which rows a query returns.
A conditional masking policy decides whether to mask a column using the values of one or more other columns. Its arguments are column names. The first always names the column to mask, and the others are conditional columns. All columns named in the policy must be in the same table or view. Row access policies are listed as a limitation of conditional masking policies.
CREATE MASKING POLICY email_visibility AS (email varchar, visibility string) RETURNS varchar -> CASE WHEN CURRENT_ROLE() = 'ADMIN' THEN email WHEN VISIBILITY = 'PUBLIC' THEN email ELSE '***MASKED***' END;Tags can simplify masking. In tag-based masking you assign a masking policy to a tag, then assign the tag to a table or column. When the column's data type matches the policy signature, the column is protected automatically. Tag-based masking policies require Enterprise Edition or higher.
Checkpoint 3 of 8· Exam question
A finance schema owner writes a masking policy on the SALARY column that must reveal the raw value only to members of the same DEPARTMENT as the row being read, while every other role sees a fixed placeholder string. What masking policy design accomplishes this?
Correct answer: A — Pass DEPARTMENT as a second column argument so the masking policy branches its logic on that row's own value
- A. A conditional masking policy accepts a second column argument, such as DEPARTMENT, so the masking logic can branch on that column's value for each row rather than applying one blanket rule. This is the documented mechanism for row-dependent masking.
- B. Snowflake does not merge multiple masking policies assigned to the same column; only one masking policy can be assigned to a given column at a time, so this design is not supported.
- C. A row access policy filters which rows are returned at all and operates independently of masking; it does not give a masking policy visibility into DEPARTMENT for the conditional check requested here.
- D. A masking policy signature must declare every column it references as an argument; a single-argument signature has no way to receive DEPARTMENT values, so an embedded subquery cannot substitute for the missing argument.
Checkpoint 4 of 8· Exam question
A column named SSN has a masking policy assigned directly to it via CREATE TABLE, and the same column also inherits a different masking policy through a tag applied at the schema level. When a restricted role queries that column, which masking policy governs the returned value?
Correct answer: A — The directly assigned column-level masking policy takes precedence over the schema-level tag-based masking policy
- A. When a column carries both a directly assigned masking policy and a tag-based masking policy, Snowflake applies the directly assigned policy and ignores the tag-based one for that column. This precedence rule is documented explicitly for resolving such conflicts.
- B. Tag propagation determines which objects a tag-based policy reaches, but it does not grant tag-based policies priority over a policy assigned straight to the column; precedence runs the opposite direction.
- C. Snowflake resolves this conflict deterministically through precedence rather than by rejecting the query, so no error is raised when both a direct and a tag-based policy target the same column.
- D. Masking policies are not chained or stacked on a single column; only one policy signature is ever evaluated per column read, so sequential double-masking does not occur.
Checkpoint 5 of 8· Exam question
A table has a tag-based masking policy assigned to one of its columns through a tag at the database level. What limitation applies if an analyst tries to create a materialized view selecting from that table?
Correct answer: A — Materialized views cannot be created over a table that has a tag-based masking policy on any underlying column
- A. Snowflake does not permit creating a materialized view over a table where an underlying column carries a tag-based masking policy; the CREATE MATERIALIZED VIEW statement is rejected. This is a documented limitation distinct from ordinary views.
- B. The limitation blocks creation of the materialized view entirely rather than allowing creation with the masked column omitted; there is no partial-schema workaround for this restriction.
- C. Because the materialized view cannot be created at all while the tag-based policy is attached, there is no refresh cycle to describe re-evaluating the policy.
- D. The restriction applies specifically to materialized views, not standard views; ordinary views over tag-masked columns are supported and evaluate the policy normally.
4.Alerts and notifications
Trust Center watches security posture. Alerts let you watch any condition you can write in SQL. When you create an alert you give it a condition in IF( EXISTS( condition )), which can be a SELECT, a SHOW command or a CALL, and an action in THEN. If the condition returns one or more rows, Snowflake runs the action. An alert's name must be unique within the schema where it is created, and it can carry tags.
The WAREHOUSE clause names the virtual warehouse that provides compute to run the alert. For a serverless alert you do not set it. The SCHEDULE clause sets how often the condition is evaluated, either USING CRON with a time zone or an interval such as '1 MINUTE'. If you omit SCHEDULE, or set it to NULL, the alert runs on new data instead. To resume an alert with ALTER ALERT ... RESUME, or to suspend it, a role needs the OPERATE or OWNERSHIP privilege on it. You can also run one evaluation manually with EXECUTE ALERT.
CREATE OR REPLACE ALERT alert_new_rows
WAREHOUSE = my_warehouse
SCHEDULE = '1 MINUTE'
IF (EXISTS (
SELECT *
FROM my_table
WHERE row_timestamp BETWEEN SNOWFLAKE.ALERT.LAST_SUCCESSFUL_SCHEDULED_TIME()
AND SNOWFLAKE.ALERT.SCHEDULED_TIME()
))
THEN CALL SYSTEM$SEND_EMAIL(...);The action is often a notification. To send one, the action calls the SYSTEM$SEND_EMAIL or SYSTEM$SEND_SNOWFLAKE_NOTIFICATION stored procedure. Both work through a notification integration. An email notification integration is created with TYPE = EMAIL, and its ALLOWED_RECIPIENTS list limits who can receive messages (those users must have verified email addresses). Notifications appear elsewhere in governance too. Trust Center can send proactive notifications about security risks, and stops emailing about violations once they are marked Resolved.
Checkpoint 6 of 8· Check yourself
An alert's condition is a SELECT that returns zero rows in this run. What happens?
The action runs only when the condition statement returns one or more rows.
“If the statement returns one or more rows, the action for the alert is executed.”Source: docs.snowflake.com
5.Data replication and failover
Governance also means keeping data available. Snowflake's business continuity features are Replication and Failover/Failback, together with Client Redirect. Replication relies on two objects, a replication group and a failover group. Each copies a set of objects from a source account to one or more target accounts with point-in-time consistency. Targets can be in other regions or on other cloud platforms.
The two groups differ in what they allow. A replication group specifies what to replicate, where to, and how often, and its secondary copies are read-only. A failover group also enables failover, so a secondary can be promoted to read-write primary. To fail over, you must use a failover group, not a replication group. Groups can hold account objects such as warehouses, users and roles, along with databases and shares. Each group has its own replication schedule, and you can fail over all failover groups or only some. Failover and failback require Business Critical Edition or higher.
Replication is asynchronous, so secondaries lag the primary. A secondary is at most twice the refresh interval behind: with a 30-minute schedule, up to 60 minutes. Client Redirect provides a connection URL that clients use to connect, and it can point them at a different Snowflake account when you fail over.
These features cover four scenarios. A planned failover is a disaster recovery drill. An unplanned failover responds to an outage by promoting secondary objects in another region to read-write primaries. Migration moves an account to a different region or cloud platform. Multiple readable secondaries spread the risk of outages across several regions.
Checkpoint 7 of 8· Match them up
Match each business continuity scenario to its purpose.
Tap a term, then the definition that fits it.
Each scenario uses the same replication and failover building blocks for a different purpose.
“Planned failovers: For disaster recovery drills to test preparedness, and measure recovery point and time.”Source: docs.snowflake.com
6.Data lineage
Data lineage shows where an object's data came from and where it goes. A source object is upstream of its target, and the target is downstream. In Snowsight you explore lineage one step at a time in either direction. Lineage records two kinds of relationship. Data movement happens when operations such as CTAS, INSERT or MERGE copy or materialize data from one object into another. An object dependency happens when an object references a base object without copying its data, as a view does with a table.
Lineage ties into the rest of governance. It supports impact analysis and compliance by tracking where sensitive data flows, and it helps you work with tags and masking policies on columns.
Checkpoint 8 of 8· Check yourself
A view selects from a table. What kind of lineage relationship is that?
A view references its base table without copying or materializing the data, so the relationship is an object dependency.
“Object dependencies, when an object references a base object but does not materialize or copy data, such as when a view references a table.”Source: docs.snowflake.com
Sources9
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Marking a Trust Center violation as Resolved fixes the underlying problem.Why is that wrong?
Resolving a violation only changes its status and stops its notifications. Remediation means changing the configuration so the scanner stops reporting it.
Covered in Trust Center: scanners, violations and detections
2.Data at rest in Snowflake is encrypted only if a customer turns encryption on or brings their own key.Why is that wrong?
Snowflake encrypts all customer data by default and manages the keys itself. Tri-Secret Secure is an optional extra key, not what switches encryption on.
Practise it for real
Set up separate view-only and admin access to Trust Center
1.Run USE ROLE ACCOUNTADMIN; then create trust_center_admin_role and GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_ADMIN to it.
Why: Managing scanners and the violation lifecycle needs the admin application role, and ACCOUNTADMIN grants it.
You should see: The role exists and holds SNOWFLAKE.TRUST_CENTER_ADMIN.
2.Create trust_center_viewer_role and GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_VIEWER to it.
Why: Viewing violations, detections and the posture report needs only the viewer role.
You should see: The role exists and holds SNOWFLAKE.TRUST_CENTER_VIEWER.
3.Grant each custom role to a test user, sign in as the viewer user, and open the Manage scanners tab.
Why: This confirms the split between viewing and managing.
You should see: The viewer user can see findings but cannot manage scanners.
Stuck? Get a nudge
In an organization account, grant these application roles with GLOBALORGADMIN instead of ACCOUNTADMIN.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“You can use the Trust Center to evaluate, monitor, and reduce potential security risks in your Snowflake accounts.”
↩︎ Trust Center: scanners, violations and detections“use the GLOBALORGADMIN role, not ACCOUNTADMIN, to grant the Trust Center application roles”
↩︎ Trust Center: scanners, violations and detections“Email notifications are suppressed for resolved violations.”
↩︎ Trust Center: scanners, violations and detections“You can also use the Trust Center to configure proactive notifications that help you monitor your account for security risks.”
↩︎ Alerts and notifications“You can remediate violations by changing the configuration.”
↩︎ Exam trap 1“A detection occurs one time and represents a unique event.”
↩︎ Prediction“a user with the ACCOUNTADMIN role must grant the SNOWFLAKE.TRUST_CENTER_VIEWER or SNOWFLAKE.TRUST_CENTER_ADMIN application role to your role.”
↩︎ Checkpoint - 2.
“Snowflake uses strong AES encryption with a hierarchical key model rooted in a cloud-provider-hosted hardware security module.”
↩︎ Encryption key management and Tri-Secret Secure“each higher layer of keys (parent keys) encrypts the layer below (child keys)”
↩︎ Encryption key management and Tri-Secret Secure“hierarchical key model consists of four levels of keys”
↩︎ Encryption key management and Tri-Secret Secure“Keys in the Snowflake-managed key hierarchy are automatically rotated by Snowflake when they are more than 30 days old.”
↩︎ Encryption key management and Tri-Secret Secure“When retired, the key is used solely to decrypt customer data and is only available for accessing the data.”
↩︎ Encryption key management and Tri-Secret Secure“If periodic rekeying is enabled, then when the retired encryption key for a table is older than one year”
↩︎ Encryption key management and Tri-Secret Secure“All Snowflake customer data is encrypted by default.”
↩︎ Exam trap 2“the combination of a Snowflake-maintained key and a customer-managed key creates a composite master key to protect customer data in Snowflake”
↩︎ Checkpoint - 3.
“The first column always specifies the column to mask.”
↩︎ Masking policies: conditional and tag-based“Ensure all columns specified in the CREATE MASKING POLICY statement reside in the same table or view.”
↩︎ Masking policies: conditional and tag-based - 4.
“you assign a masking policy to a tag, then assign that tag to a table or column.”
↩︎ Masking policies: conditional and tag-based - 5.
“To send a notification, you can call the SYSTEM$SEND_EMAIL or SYSTEM$SEND_SNOWFLAKE_NOTIFICATION stored procedure.”
↩︎ Alerts and notifications“For serverless alerts, do not set this property.”
↩︎ Alerts and notifications“omitting this parameter or setting it to NULL creates an alert on new data”
↩︎ Alerts and notifications“If the statement returns one or more rows, the action for the alert is executed.”
↩︎ Checkpoint - 6.
“A comma-separated list of quoted email addresses that can receive notification emails from this integration.”
↩︎ Alerts and notifications - 7.
“Replication uses two Snowflake objects, replication group and failover group, to replicate a group of objects with point-in-time consistency”
↩︎ Data replication and failover“Unplanned failovers: In the case of an outage in a region or a cloud platform, promote secondary account objects and databases in another region”
↩︎ Data replication and failover“Secondary replica objects are at most 2x the time interval between scheduled refreshes behind the primary objects.”
↩︎ Data replication and failover“Client Redirect provides a connection URL that can be used by Snowflake clients to connect to Snowflake.”
↩︎ Data replication and failover“Planned failovers: For disaster recovery drills to test preparedness, and measure recovery point and time.”
↩︎ Checkpoint - 8.
“To enable failover (promotion of a secondary account to primary) during an outage, you must use a failover group instead of a replication group”
↩︎ Data replication and failover - 9.
“For example, CREATE TABLE AS SELECT (CTAS), INSERT, or MERGE operations on tables result in data movement.”
↩︎ Data lineage“Helps you work with tags and masking policies on columns to protect sensitive data.”
↩︎ Data lineage“Object dependencies, when an object references a base object but does not materialize or copy data, such as when a view references a table.”
↩︎ Checkpoint