Snowflake Encryption, Replication, Failover & Alerts
Sub-objective 2.2 closes with four features that protect data and keep it available. Encryption guards data at rest and in transit, and it is always on in every edition. Replication and failover copy data across regions for business continuity, with a sharp edition line you must know. Alerts and Notifications watch the account and tell you when something happens. Encryption is the most common trap here, because candidates assume it is an upgrade feature. It is not. Alerts and Notifications are the easiest to skip, yet the C03 outline names them directly.
Today’s Concept
Micro-Concept 1: Always-On Encryption
Snowflake encrypts all customer data by default. Data at rest uses AES-256. Data in transit uses TLS. You do not enable it, configure it, or pay extra for it.
The edition rule is the whole point of this concept. Encryption is on for every edition, from Standard upward. A stem that says “encryption requires Enterprise Edition” is false. So is any claim that you must switch it on.
Two things sit outside this baseline. Customer-managed keys arrive with Tri-Secret Secure, covered in Micro-Concept 3. Yearly rekeying is an Enterprise feature, covered next. The base encryption itself never depends on edition.
Micro-Concept 2: The Hierarchical Key Model, Rotation, and Rekeying
Snowflake wraps each key with the key above it. This is the hierarchical key model. It has four levels. The root key lives in a hardware security module. Below it sits the account master key, then the table master key, then the file keys that encrypt the micro-partition data.
Each parent key wraps the keys at the level below. A key is never stored in the clear. Unwrapping a child key requires the parent, and the root never leaves the hardware security module. The four named tiers are the most testable fact, because distractors invent levels like “database master key” or “schema master key” that do not exist.
Root key (in HSM)
└─ Account Master Key (AMK)
└─ Table Master Key (TMK)
└─ File keys (encrypt micro-partition data)Two lifecycle terms ride on this model, and the exam tests the difference. Key rotation runs automatically when a key is more than 30 days old. It retires the old key and starts a new one for fresh data. Rotation happens on every edition, with no setup.
Rekeying is the other term. When enabled, Snowflake re-encrypts data whose retired key is older than one year, then destroys the old key. You turn it on with ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = TRUE. Rekeying requires Enterprise Edition or higher. The trap is matching the period to the wrong feature: rotation is 30 days and free on all editions, rekeying is yearly and Enterprise+.
Micro-Concept 3: Tri-Secret Secure
Tri-Secret Secure combines a customer-managed key with a Snowflake-managed key. The two are merged into a composite master key, which then wraps the account master key. Snowflake alone cannot decrypt the data, and the customer alone cannot either.
The customer key lives in the cloud provider’s key service, such as AWS KMS or Azure Key Vault. Revoking access to that key blocks all decryption, which is the control customers want for compliance. This is sometimes called a customer kill switch.
The edition line is the exam fact. Tri-Secret Secure requires Business Critical Edition or higher. It is the same floor as PrivateLink and the compliance options from Day 3. Plain AES-256 encryption is all editions. Customer-managed keys via Tri-Secret Secure are Business Critical+.
Micro-Concept 4: Replication and Failover
Replication copies objects and data to another Snowflake account, usually in a different region or cloud. Failover promotes that secondary copy to primary when the first region has an outage. Together they give cross-region business continuity.
The edition split is the single most tested point in this area, and candidates I have trained miss it often. Database replication and share replication work on all editions. Replication of all other account objects, plus failover and failback, requires Business Critical Edition or higher.
The grouping objects matter for the wording. A replication group holds databases and shares for synchronized copying. A failover group adds the ability to promote the secondary, and failover groups exist only on Business Critical and above. So a Standard account can replicate a database for read access, but it cannot fail over.
Client Redirect finishes the picture. It uses a connection object with a single URL that points clients at whichever account is currently primary. After a failover, you redirect the connection and applications follow without code changes. Client Redirect is also Business Critical+.
Micro-Concept 5: Alerts and Notifications
The C03 outline lists Alerts and Notifications under sub-objective 2.2 by name. They are easy to overlook because they read like monitoring rather than governance. Expect at least one question, often on syntax.
An alert is a schema-level object with three parts. A schedule sets how often it runs. A condition is a query inside IF (EXISTS (...)). An action is the SQL that runs when the condition returns rows. Alerts run on a schedule, not on events.
An alert needs compute, and you have two choices. Name a warehouse with WAREHOUSE =, or omit that property to get a serverless alert that Snowflake runs for you. For a condition that rarely fires, serverless avoids paying a full minute of warehouse time per run.
A notification integration is the object that sends messages out. It comes in three types: EMAIL, QUEUE for cloud message queues like AWS SNS or Azure Event Grid, and WEBHOOK for targets such as Slack or PagerDuty. Email goes only to addresses that belong to verified users in the same account.
The action then calls a procedure to send the message. SYSTEM$SEND_EMAIL handles a simple email through an email integration. SYSTEM$SEND_SNOWFLAKE_NOTIFICATION adds CC and BCC and can target queues and webhooks. An alert that detects a problem and emails you wires these pieces together, which is exactly the lab below.
Cheat Sheet
| Topic | What to remember | Exam keyword |
|---|---|---|
| Base encryption | AES-256 at rest, TLS in transit, always on, every edition, no setup | “All editions” |
| Key hierarchy | Root (HSM) wraps AMK wraps TMK wraps file keys. Four real levels | “Hierarchical key model” |
| Key rotation | Automatic at 30 days. Retires old key. All editions, no config | “30 days” |
| Rekeying | Yearly re-encryption of retired keys. PERIODIC_DATA_REKEYING. Enterprise+ | “Yearly, Enterprise+” |
| Tri-Secret Secure | Customer key plus Snowflake key into a composite master key. Business Critical+ | “Customer-managed key” |
| Replication editions | Database and share replication on all editions. Everything else needs Business Critical+ | “DB replication all editions” |
| Failover and Client Redirect | Failover groups, failover/failback, and Client Redirect are Business Critical+ | “Failover = BC+” |
| Alert anatomy | Schedule plus IF (EXISTS(...)) THEN action. Schedule-based, not event-based | “Runs on a schedule” |
| Alert compute | Specify a warehouse, or omit it for a serverless alert | “Serverless if no warehouse” |
| Notification types | EMAIL, QUEUE (SNS / Event Grid / Pub/Sub), WEBHOOK (Slack, Teams, PagerDuty) | “Three integration types” |
Exam Tip
Three edition lines decide most questions in this area. Get them straight and the distractors fall away.
The encryption trap. Base AES-256 encryption is on for every edition. Any answer that gates encryption itself behind Enterprise or Business Critical is wrong. Only two things move up the editions: yearly rekeying needs Enterprise+, and customer-managed keys via Tri-Secret Secure need Business Critical+.
The rotation versus rekeying period. Rotation is 30 days and automatic on all editions. Rekeying is yearly and Enterprise+. If a stem pairs “30 days” with “Enterprise only”, it has swapped the two. Read the period and the edition together.
The replication line. Database and share replication run on all editions. Failover, failback, Client Redirect, and replication of other account objects need Business Critical+. A common catch: a Standard account that can replicate a database but cannot fail over to it.
Do not skip Alerts. Sub-objective 2.2 names Alerts and Notifications outright. Remember the shape: SCHEDULE, then IF (EXISTS (condition)) THEN action, with a warehouse named or omitted for serverless. Alerts run on a schedule, so “fires the instant data lands” is a trap.
Hands-On Lab
lab_xs warehouse from Day 1. Run as ACCOUNTADMIN. Replace the placeholder email with the verified email on your trial user.Inspect encryption and rekeying parameters.
USE ROLE ACCOUNTADMIN;
USE WAREHOUSE lab_xs;
-- Account-level encryption-related parameters
SHOW PARAMETERS LIKE '%ENCRYPT%' IN ACCOUNT;
-- The yearly rekeying switch (Enterprise+). Default is false.
SHOW PARAMETERS LIKE 'PERIODIC_DATA_REKEYING' IN ACCOUNT;PERIODIC_DATA_REKEYING, and on a trial it sits at false. That single switch is the yearly Enterprise+ feature from Micro-Concept 2.Read the replication landscape (concept-only).
-- Regions you could replicate into
SHOW REGIONS;
-- Accounts in your organization enabled for replication
SHOW REPLICATION ACCOUNTS;SHOW REGIONS lists the targets a replication group could point at. On a single-account trial, SHOW REPLICATION ACCOUNTS returns just your account or nothing. Why concept-only: a real failover group needs a second Business Critical account in another region, which a trial does not provide. You are confirming the commands exist, not building the group.Create an email notification integration.
CREATE OR REPLACE NOTIFICATION INTEGRATION my_email_int
TYPE = EMAIL
ENABLED = TRUE
ALLOWED_RECIPIENTS = ('[email protected]'); -- must be a verified user email
SHOW NOTIFICATION INTEGRATIONS;EMAIL. The other two types, QUEUE and WEBHOOK, route to cloud queues and to Slack or PagerDuty instead.Create an alert that emails you when a query failed in the last hour.
CREATE OR REPLACE ALERT my_alert
WAREHOUSE = lab_xs -- omit this line to make it a serverless alert
SCHEDULE = '60 MINUTE'
IF (EXISTS (
SELECT 1
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE EXECUTION_STATUS = 'FAIL'
AND START_TIME > DATEADD('hour', -1, CURRENT_TIMESTAMP())
))
THEN CALL SYSTEM$SEND_EMAIL(
'my_email_int',
'[email protected]',
'Failed query alert',
'A query failed in the last hour. Check QUERY_HISTORY.'
);SCHEDULE, the IF (EXISTS(...)) condition, and the THEN action. Delete the WAREHOUSE line and the same alert becomes serverless. ACCOUNT_USAGE has up to a few hours of latency, so this alert reflects older failures, which is fine for the demo.Resume the alert, then inspect it.
-- A new alert starts suspended. Resume it to let the schedule run.
ALTER ALERT my_alert RESUME;
SHOW ALERTS;
-- Execution attempts, once the schedule has run at least once
SELECT name, state, scheduled_time
FROM TABLE(INFORMATION_SCHEMA.ALERT_HISTORY())
ORDER BY scheduled_time DESC;SHOW ALERTS now reports state = started. ALERT_HISTORY stays empty until the first scheduled run, which can take up to the full hour you set.Clean up.
DROP ALERT IF EXISTS my_alert;
DROP INTEGRATION IF EXISTS my_email_int;lab_xs warehouse stays, since later days reuse it. The day10_orders table from Day 10 is untouched. Nothing in this lab created persistent data.Snowflake Documentation
Official docs for today’s topics. The exam pulls directly from these.
External References
Reference pages to reinforce today’s concepts.
Practice Questions
Options:
A. Account master keys
B. Database master keys
C. File keys
D. Secure view keys
E. Schema master keys
Why A: The account master key is the second tier, sitting under the root key in the hardware security module and wrapping the table master key.
Why C: File keys are the bottom tier. They encrypt the micro-partition data files and are wrapped by the table master key.
Why not B: There is no database master key tier. The hierarchy goes root, account master, table master, file. Database is not a key level.
Why not D: A secure view is an access-control object, not an encryption key. No such key exists.
Why not E: Schema is a level in the object hierarchy from Day 5, but not in the key hierarchy. The trap reuses a familiar word in the wrong context.
Options:
A. Standard Edition
B. Enterprise Edition
C. Business Critical Edition
D. Any edition, since encryption is always on
Why C: A customer-managed key plus revocation is Tri-Secret Secure. It builds a composite master key from the customer key and the Snowflake key. Its minimum is Business Critical Edition.
Why not A: Standard gives always-on AES-256, but no customer-managed key. There is no kill switch to revoke.
Why not B: Enterprise adds yearly rekeying, not customer-managed keys. The rekeying confusion is the intended catch here.
Why not D: Base encryption is every edition, true, but the question asks for a customer-managed key, which Tri-Secret Secure alone provides.
Options:
A. An alert fires the instant matching data is written to the table
B. An alert evaluates its condition on a schedule, and the action runs only if the condition returns rows
C. An alert must always be assigned a virtual warehouse and cannot use serverless compute
D. An alert runs immediately after creation with no further action needed
Why B: An alert pairs a SCHEDULE with IF (EXISTS (condition)) THEN action. The schedule decides when the condition is checked, and the action runs only when rows come back.
Why not A: Alerts are schedule-based, not event-based. They do not fire the moment data lands.
Why not C: Omitting the WAREHOUSE property creates a serverless alert that Snowflake runs for you. A warehouse is optional.
Why not D: A new alert starts suspended. You must run ALTER ALERT ... RESUME before the schedule takes effect.
Options:
A. EMAIL
B. WEBHOOK
C. SFTP
D. JDBC
E. SNOWPIPE
Why A: EMAIL sends to verified user email addresses in the account, used by SYSTEM$SEND_EMAIL.
Why B: WEBHOOK posts to targets like Slack, Microsoft Teams, or PagerDuty. The third valid type, not listed, is QUEUE for cloud message queues.
Why not C: SFTP is a file transfer protocol. Snowflake has no SFTP notification integration.
Why not D: JDBC is a client driver from Day 34’s territory, not a notification type.
Why not E: Snowpipe loads data. It is not a notification integration, though it can consume cloud queue events.
Options:
A. Correct. Encryption is an Enterprise feature that an admin enables
B. Incorrect. Encryption is always on in every edition, and the 30-day key rotation is automatic on all editions
C. Correct for at-rest data only. In-transit encryption is Business Critical+
D. Incorrect, but only yearly rekeying and that runs on all editions
Why B: AES-256 at rest and TLS in transit are on by default for every edition, with no switch to flip. Automatic key rotation at 30 days also runs on all editions.
Why not A: This is the headline trap of the topic. Encryption is not an upgrade feature and is not toggled by an admin.
Why not C: Both at-rest and in-transit encryption apply on every edition. In-transit TLS is not gated to Business Critical.
Why not D: The claim is indeed incorrect, but yearly rekeying is the one piece that needs Enterprise+, so “runs on all editions” is wrong. Re-read Micro-Concept 2 if this felt close.
Today you learned: Snowflake encrypts all data by default with AES-256 at rest and TLS in transit, on every edition, with no setup. The hierarchical key model has four tiers: root key in a hardware security module, account master key, table master key, and file keys. Keys rotate automatically at 30 days on all editions. Yearly rekeying is optional and requires Enterprise Edition.
Tri-Secret Secure adds a customer-managed key combined with Snowflake’s key into a composite master key, and it requires Business Critical Edition. Replication has a sharp edition line: database and share replication work on all editions, while failover, failback, Client Redirect, and other account-object replication need Business Critical and above. A failover group, available only on Business Critical+, is what lets a secondary be promoted to primary.
Alerts and Notifications are named directly in sub-objective 2.2. An alert combines a schedule with an IF (EXISTS(...)) THEN action body, runs on a virtual warehouse or serverless, and starts suspended until resumed. A notification integration sends messages out as EMAIL, QUEUE, or WEBHOOK, called through SYSTEM$SEND_EMAIL or SYSTEM$SEND_SNOWFLAKE_NOTIFICATION.
Tomorrow (Day 26): Resource Monitors and Credit Calculation. You will see how resource monitors cap and track warehouse credit usage, why they consume no credits themselves, and how that connects to C03 sample question two. It opens sub-objective 2.3 on cost and monitoring.
