Week 4 Recap
Week 4 closes Domain 2, the 20% of COF-C03 that turns on governance, monitoring, and cost control. Today is a 30-minute closed-book drill, the recurring exam traps from Days 22 through 27, and the Week 4 Practice Test. Target 8 out of 10 to clear Week 5.
| Step | Time | What you do |
|---|---|---|
| 1. Closed-book drill | 30 min | Run the five drill tasks below. No tabs open. Write SQL on paper or a scratch buffer. |
| 2. Self-grade | 5 min | Open Snowsight, run your SQL, score yourself honestly. |
| 3. Read the gotchas | 10 min | Speed-read the patterns below. These are the recurring traps for Domain 2. |
| 4. Take the Week 4 Practice Test | 15 min | 10 mixed-format questions. Target: 8/10. Below that, re-read the day flagged in your wrong answers before Week 5. |
The 30-Minute Drill
Build a 3-role RBAC chain, mask one column, and protect one table with a row access policy. Write the full DDL from memory before opening Snowsight.
-- Try without peeking, then run this to verify:
USE ROLE USERADMIN;
CREATE ROLE drill_jr;
CREATE ROLE drill_sr;
CREATE ROLE drill_lead;
GRANT ROLE drill_jr TO ROLE drill_sr;
GRANT ROLE drill_sr TO ROLE drill_lead;
GRANT ROLE drill_lead TO ROLE SYSADMIN;
USE ROLE SYSADMIN;
CREATE OR REPLACE TABLE drill_customers (
id INT,
name STRING,
ssn STRING,
region STRING
);
USE ROLE ACCOUNTADMIN;
CREATE OR REPLACE MASKING POLICY drill_mask_ssn
AS (val STRING) RETURNS STRING ->
CASE WHEN CURRENT_ROLE() IN ('ACCOUNTADMIN','drill_lead')
THEN val
ELSE '***-**-' || RIGHT(val, 4)
END;
ALTER TABLE drill_customers MODIFY COLUMN ssn
SET MASKING POLICY drill_mask_ssn;
CREATE OR REPLACE ROW ACCESS POLICY drill_region_ra
AS (region STRING) RETURNS BOOLEAN ->
CURRENT_ROLE() = 'ACCOUNTADMIN'
OR region = 'APAC';
ALTER TABLE drill_customers
ADD ROW ACCESS POLICY drill_region_ra ON (region);
-- Cleanup
DROP TABLE drill_customers;
DROP MASKING POLICY drill_mask_ssn;
DROP ROW ACCESS POLICY drill_region_ra;
USE ROLE ACCOUNTADMIN;
DROP ROLE drill_jr; DROP ROLE drill_sr; DROP ROLE drill_lead;SYSADMIN to create the masking policy, that is the trap pattern. Governance policies sit with ACCOUNTADMIN or a role with the CREATE MASKING POLICY privilege. Re-read Day 23 if missed.Create a resource monitor and assign it to a warehouse. Quota of 5 credits per day, notify at 50% and 80%, suspend at 100%.
USE ROLE ACCOUNTADMIN;
CREATE OR REPLACE RESOURCE MONITOR drill_rm
WITH CREDIT_QUOTA = 5
FREQUENCY = DAILY
START_TIMESTAMP = IMMEDIATELY
TRIGGERS
ON 50 PERCENT DO NOTIFY
ON 80 PERCENT DO NOTIFY
ON 100 PERCENT DO SUSPEND;
ALTER WAREHOUSE lab_xs SET RESOURCE_MONITOR = drill_rm;
SHOW RESOURCE MONITORS LIKE 'drill_rm';
-- Cleanup
ALTER WAREHOUSE lab_xs UNSET RESOURCE_MONITOR;
DROP RESOURCE MONITOR drill_rm;NOTIFY, SUSPEND, SUSPEND_IMMEDIATE. Forgetting SUSPEND_IMMEDIATE is the most common gap. The resource monitor itself does not consume credits, only tracks them. This is sample question 2 territory. Re-read Day 26 if missed.Write the SQL that attributes warehouse compute credits to individual queries, grouped by user and role. From memory: which view, which column.
SELECT
USER_NAME,
ROLE_NAME,
WAREHOUSE_NAME,
COUNT(*) AS query_count,
SUM(CREDITS_ATTRIBUTED_COMPUTE) AS total_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY
WHERE START_TIME > DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY USER_NAME, ROLE_NAME, WAREHOUSE_NAME
ORDER BY total_credits DESC NULLS LAST;QUERY_HISTORY is the trap. QUERY_HISTORY reports cloud services credits per query, not warehouse compute credits. Reaching for WAREHOUSE_METERING_HISTORY is also wrong because it aggregates per warehouse per hour, not per query. The C03 answer for per-query attribution is QUERY_ATTRIBUTION_HISTORY. Re-read Day 27 if missed.Locate Trust Center in Snowsight and name its three scanner packages. Then state, in one sentence, which official sample question this answers.
Path:
Snowsight > Monitoring > Trust Center
(older accounts: Admin > Security > Trust Center)
Three scanner packages:
1. Security Essentials (enabled by default, free)
2. CIS Benchmarks (opt-in, evaluates account
against CIS Snowflake Benchmark)
3. Threat Intelligence (opt-in)
Sample Q3 answer:
Trust Center is the feature that evaluates your account
against security recommendations. Not Snowsight, not
ACCOUNT_USAGE, not Resource Monitors.Bonus speed round (60 seconds each):
Q: Which role can create a network policy?
A: SECURITYADMIN or higher, or any role with the global
CREATE NETWORK POLICY privilege. NOT SYSADMIN.
Q: Which function auto-detects PII columns?
A: EXTRACT_SEMANTIC_CATEGORIES. Pair it with
ASSOCIATE_SEMANTIC_CATEGORY_TAGS to apply tags.
Sample Q1 answer is “Data Classification”.
Q: Minimum edition for account replication?
A: Business Critical. Database replication is available
on lower editions; full account replication is BC+.
Q: How are masking, row access, and privacy policies
different?
A: Masking transforms column values.
Row access filters rows.
Privacy policies (aggregation / projection constraints)
restrict what can be revealed about individuals.
Three distinct features, all Enterprise+.
Q: Latency of ACCOUNT_USAGE views?
A: 45 minutes to 3 hours, varying by view. Never a single
flat number. QUERY_ATTRIBUTION_HISTORY is the outlier
at up to 8 hours.
Q: Minimum edition for ACCESS_HISTORY?
A: Enterprise. Same gate as Dynamic Data Masking and
Row Access Policies.
Q: Which view keeps storage rows for dropped tables
still in Time Travel or Fail-safe?
A: TABLE_STORAGE_METRICS. Other storage views do not.Week 4 Exam Gotchas
These are the patterns the exam reuses in scenario form. Each one has a Tell, the trigger phrase the question uses to set the trap. Learn the Tells and you will catch the trap before you read the options.
Gotcha 1: Network policies need SECURITYADMIN, not SYSADMIN
A CREATE NETWORK POLICY issued as SYSADMIN fails. The required role is SECURITYADMIN or higher, or any role with the global CREATE NETWORK POLICY privilege. Tell: a stem that names SYSADMIN as the role attempting to add an IP allowlist or restrict access. Pick the option that flags the role mismatch.
Gotcha 2: Network rules and network policies are not the same object
Network rules are schema-level objects that group IPs. Network policies attach those rules to an account or user. The COF-C03 question pattern phrases it as “which object contains the IP list” against “which object activates it”. The IP list lives in the rule. The policy activates it. Tell: any question that mentions both terms in the same stem.
Gotcha 3: Masking, Row Access, and Privacy Policies are three distinct features
Masking transforms column values based on the calling role. Row access filters which rows the role can see. Privacy policies are the newer aggregation-and-projection constraint family for differential-privacy-style protection. All three need Enterprise Edition or higher. Tell: a multi-select that asks “which of the following are Snowflake governance policies”. All three answers are correct.
Gotcha 4: Tag-based masking applies one policy to many columns
A masking policy attached to a tag protects every column that carries that tag, present and future. This is the C03 way to govern PII at scale. Tell: a scenario describing “hundreds of columns across many tables” needing the same redaction. The option that creates one policy per column is the wrong answer.
Gotcha 5: Data Classification is the auto-detect feature, not a manual tag
The sample question 1 answer is Data Classification. The function is EXTRACT_SEMANTIC_CATEGORIES. The companion procedure is ASSOCIATE_SEMANTIC_CATEGORY_TAGS, which writes the system tags. Privacy categories are IDENTIFIER, QUASI_IDENTIFIER, and SENSITIVE. Tell: any phrase like “automatically detect”, “identify sensitive columns”, or “classify PII without listing columns”.
Gotcha 6: Trust Center evaluates account security posture, not query performance
Trust Center is the answer for sample question 3. It runs scanner packages (Security Essentials by default; CIS Benchmarks and Threat Intelligence as opt-ins) and surfaces violations with remediation guidance. Tell: “evaluate the account against security recommendations” or “CIS”. Distractors usually offer Resource Monitors or Snowsight Activity, both of which are wrong.
Gotcha 7: Encryption is in every edition, including Standard
AES-256 at rest and TLS in transit ship with every account at signup. The edition gate sits one level up at customer-managed keys via Tri-Secret Secure, which is Business Critical and higher. Tell: a stem asking for the minimum edition to encrypt data. The answer is Standard. The question is built to make you reach for Business Critical.
Gotcha 8: Tri-Secret Secure is Business Critical, not Enterprise
Tri-Secret Secure combines a customer-managed key with a Snowflake-maintained key, sitting at the top of the hierarchical key model. It is a Business Critical feature, the same edition as PrivateLink and HIPAA support. Tell: “customer-managed key”, “CMK”, or “dual-key encryption”.
Gotcha 9: Database replication is broader than account replication
Database replication is available on Standard. Account replication and failover groups, the cross-region disaster-recovery feature, are Business Critical and higher. Tell: “failover”, “cross-region DR”, or “client redirect”. Those phrases force the answer to Business Critical.
Gotcha 10: Alerts use CREATE ALERT, not Resource Monitor triggers
A resource monitor sends notifications when a credit quota threshold is hit. An alert is a separate object built with CREATE ALERT, runs a scheduled query, and fires a notification integration when a condition is true. Tell: a stem that asks for an action triggered by a SQL condition (not a credit threshold).
Gotcha 11: Resource monitors do not consume credits
This is the verbatim sample question 2 answer. Resource monitors track credit consumption but are not themselves billed. They sit in the cost-control layer, not the compute layer. Tell: “impact on cost” or “additional credit usage” in a monitoring scenario. The right answer is “at no additional cost”.
Gotcha 12: Resource monitor triggers come in three flavours
NOTIFY sends an email and lets queries continue. SUSPEND stops new queries and lets running ones finish. SUSPEND_IMMEDIATE cancels everything in flight. Tell: a stem that says “let in-flight queries complete before shutdown”. That points to SUSPEND, not SUSPEND_IMMEDIATE. The wording is the entire question.
Gotcha 13: One account monitor, many warehouse monitors
An account can hold exactly one account-level resource monitor, and any number of warehouse-level monitors. Each warehouse can carry one monitor only. Tell: a multi-warehouse cost-control scenario with conflicting numbers in the options. The single-account-monitor rule is the discriminator.
Gotcha 14: Cloud Services credits are free up to 10% of compute
The Cloud Services layer consumes credits, but daily Cloud Services use is billed only above 10% of the day’s warehouse compute credits. Below the threshold, the consumption shows up in views but never appears on the bill. Tell: “cloud services billing” framed as an absolute. The 10% adjustment is the trap most candidates miss.
Gotcha 15: ACCOUNT_USAGE latency is a range, not a number
The latency band is 45 minutes to 3 hours, varying by view. QUERY_ATTRIBUTION_HISTORY is the outlier at up to 8 hours, since attribution is computed from rolled-up meter intervals. Tell: any option that pins the latency to a single number. It is almost always wrong.
Gotcha 16: ACCESS_HISTORY needs Enterprise; the other ACCOUNT_USAGE views do not
Most views in ACCOUNT_USAGE are on Standard. ACCESS_HISTORY is the lone Enterprise gate inside the must-know set. Same gate as Dynamic Data Masking and Row Access Policies. Tell: a Standard Edition account named in the stem alongside an audit or lineage requirement. The audit option is closed off.
Gotcha 17: QUERY_ATTRIBUTION_HISTORY answers “credits per query”
Cost-attribution questions on C03 land on QUERY_ATTRIBUTION_HISTORY, not QUERY_HISTORY and not WAREHOUSE_METERING_HISTORY. The headline column is CREDITS_ATTRIBUTED_COMPUTE. Tell: “attribute compute credits to individual queries, users, or roles”. Older study materials may not list this view at all.
Gotcha 18: TABLE_STORAGE_METRICS keeps rows for dropped tables
A dropped table can still incur storage costs while in Time Travel or Fail-safe. TABLE_STORAGE_METRICS is the only must-know view that preserves these rows with the DELETED timestamp set. Tell: any storage-billing question that mentions a table the user no longer owns.
Gotcha 19: Event tables are the logging-and-tracing destination, not ACCOUNT_USAGE
Logs and traces from stored procedures, user-defined functions, and Snowpark code land in an event table set at the account level, not in ACCOUNT_USAGE. Tell: “observability”, “trace events from a UDF”, or “application logs”. Reaching for QUERY_HISTORY is the trap.
Gotcha 20: Four SNOWFLAKE database roles delegate ACCOUNT_USAGE access
USAGE_VIEWER covers cost and usage views. GOVERNANCE_VIEWER covers governance and access views. OBJECT_VIEWER covers object metadata. SECURITY_VIEWER covers login and grant audits. Granting one of these is the recommended path, instead of granting ACCOUNTADMIN. Tell: a least-privilege question about giving a finance or audit team read access to usage data.
Week 4 Readiness Checklist
| If you can confidently… | You’re solid on | Otherwise re-skim |
|---|---|---|
| Name the role that can create a network policy (and one that cannot) | Day 22 | Day 22: Network Policies |
| Distinguish a network rule from a network policy in one sentence | Day 22 | Day 22: Network Rules |
| State what an event table captures and where it sits | Day 22 | Day 22: Logging & Tracing |
| Tell masking from row access from privacy policies on a multi-select | Day 23 | Day 23: Three policy types |
| Explain tag-based masking and when it beats per-column policies | Day 23, Day 24 | Day 23: Masking patterns |
Match Data Classification to EXTRACT_SEMANTIC_CATEGORIES | Day 24 | Day 24: Classification (sample Q1) |
| Name the three Trust Center scanner packages | Day 24 | Day 24: Trust Center (sample Q3) |
| State which edition encryption needs (and which one CMK needs) | Day 25 | Day 25: Encryption + Tri-Secret Secure |
| Match account replication and failover groups to Business Critical | Day 25 | Day 25: Replication editions |
Write a CREATE ALERT skeleton from memory, including the notification integration | Day 25 | Day 25: Alerts & Notifications |
| Name three resource monitor triggers and what each one does | Day 26 | Day 26: Resource Monitors (sample Q2) |
| Recall that resource monitors are billed at zero credits | Day 26 | Day 26: Resource Monitors (sample Q2) |
| Quote the Cloud Services 10% billing adjustment in one line | Day 26 | Day 26: Credit calculation |
| State the ACCOUNT_USAGE latency band as a range, not a number | Day 27 | Day 27: Latency |
| Pick the right view for “credits per query” without hesitation | Day 27 | Day 27: QUERY_ATTRIBUTION_HISTORY |
| Name the view that keeps dropped-table storage rows | Day 27 | Day 27: TABLE_STORAGE_METRICS |
| Recall the ACCESS_HISTORY edition gate without checking | Day 27 | Day 27: Edition gates |
| Match the four SNOWFLAKE database roles to their view families | Day 27 | Day 27: Delegated access |
Read the role and the edition in the stem first. Domain 2 questions are built around two specific anchors. The role decides whether the action is even allowed. SECURITYADMIN for network policies, ACCOUNTADMIN for resource monitors and most policy DDL, USERADMIN for user-and-role creation, SYSADMIN for warehouses and databases. The edition decides whether the feature exists at all. Encryption everywhere, Tri-Secret Secure at Business Critical, account replication at Business Critical, ACCESS_HISTORY at Enterprise, masking and row access and privacy policies at Enterprise. In training sessions I have run, candidates above 85% on Domain 2 treat “role + edition” as the first two filters on every question. They apply both before reading any option.
You’ve covered: network policies and network rules, plus event tables for logging and tracing (Day 22). The three governance policy families of masking, row access, and privacy (Day 23). Object tagging, Data Classification, and Trust Center (Day 24). The hierarchical key model with Tri-Secret Secure, account replication, and the Alerts and Notifications stack (Day 25). Resource monitors with their three trigger actions and the credit math (Day 26). And the ACCOUNT_USAGE schema with QUERY_ATTRIBUTION_HISTORY for per-query cost attribution (Day 27). Four of the five official COF-C03 sample questions live in this week’s material.
Take the Week 4 Practice Test (10 questions, mixed Domain 2 themes). Target: 8/10. If you score 6 or below, re-read the days flagged in your wrong answers before starting Week 5.
Tomorrow (Day 29): Week 5 begins. We move into Domain 3 sub-objective 3.1: Stages: internal versus external, server-side encryption, and directory tables. That is the first day of a six-day stretch on data movement. The stretch builds toward COPY INTO options, Snowpipe and Snowpipe Streaming, Streams and Tasks, and the connectors and Git integration on Day 34.
