How to Use This Quick Reference
This independent Quick Reference supports candidates preparing for the Snowflake SnowPro Core Certification (COF-C02). Use it to review high-yield Snowflake concepts, decision points, SQL patterns, and common exam traps.
Focus on recognizing what the scenario is really asking:
| If the question emphasizes… | Think first about… |
|---|
| Slow queries | Warehouse size, pruning, clustering, query profile, caching |
| Too many users waiting | Multi-cluster warehouse, concurrency, queuing |
| Least privilege | Roles, grants, ownership, managed access schemas |
| Recovery from accidental change | Time Travel, UNDROP, zero-copy clone |
| Disaster recovery | Replication, failover, Fail-safe distinction |
| Batch ingestion | Stages, file formats, COPY INTO <table> |
| Near-continuous ingestion | Snowpipe or Snowpipe Streaming |
| Change data capture | Streams plus tasks |
| Shared read-only data | Secure data sharing, listings, reader accounts |
| Column/row protection | Masking policies, row access policies, secure views |
Snowflake Architecture Mental Model
Snowflake separates storage, compute, and cloud services. Many COF-C02 questions test whether you know which layer solves the problem.
| Layer / concept | What it does | Exam reminders |
|---|
| Cloud services layer | Authentication, authorization, metadata, parsing, optimization, transaction management | Not the same as a virtual warehouse; some features use Snowflake-managed compute/background services |
| Virtual warehouse | User-managed compute for SQL queries, DML, loading, unloading, and many tasks | Scale up for more power per query; scale out with multi-cluster for concurrency |
| Storage layer | Compressed, columnar data stored in Snowflake-managed storage | Independent of warehouse size; data persists when warehouses suspend |
| Micro-partitions | Immutable storage units with metadata used for pruning | Good pruning reduces scanned data; poor clustering can increase scans |
| Database and schema | Logical containers for objects | Warehouses do not “contain” databases; any role with privileges can query using any usable warehouse |
| Account | Security, users, roles, warehouses, databases, integrations | Most administrative objects live at account scope |
| Organization | Higher-level grouping of Snowflake accounts | Relevant for cross-account governance, usage visibility, replication, and account management |
Object Hierarchy
| Level | Examples | Notes |
|---|
| Organization | Accounts | Managed outside an individual database |
| Account | Users, roles, warehouses, databases, integrations, network policies | Account-level privileges matter |
| Database | Schemas, database roles | USAGE on database is required before schema/object access |
| Schema | Tables, views, stages, file formats, pipes, streams, tasks, functions, procedures | USAGE on schema is required before object access |
| Object | Table, view, stage, task, stream, pipe | Object-specific privileges apply |
Feature Selection Matrix
| Scenario | Choose / consider | Avoid this trap |
|---|
| Run interactive SQL queries | Virtual warehouse | Storage alone does not execute queries |
| Speed up one large resource-heavy query | Larger warehouse, query rewrite, pruning, clustering, materialized view where appropriate | Multi-cluster mainly improves concurrency, not single-query speed |
| Reduce user queuing during BI workload | Multi-cluster warehouse, appropriate scaling policy | Increasing warehouse size may not solve concurrency |
| Lower idle compute cost | Auto-suspend, right-size warehouses, resource monitors | Auto-resume can restart spend if users/tools keep querying |
| Batch load staged files | COPY INTO <table> | Do not confuse with unload syntax |
| Near-continuous file ingestion | Snowpipe | Snowpipe is not the same as a user-managed warehouse load |
| Low-latency streaming ingestion | Snowpipe Streaming | Different pattern from file-based Snowpipe |
| Transform data after load | SQL, tasks, streams, dynamic tables | COPY supports limited transformation patterns; complex ELT belongs elsewhere |
| Track table changes | Stream | A stream records change metadata; it does not execute processing |
| Schedule SQL or pipeline steps | Task | A task executes SQL; it does not itself detect all changes unless paired with logic such as a stream |
| Declarative incremental transformation | Dynamic table | Do not confuse with a materialized view; dynamic tables use target lag semantics |
| Repetitive query acceleration | Materialized view, clustering, search optimization, query design | Each has maintenance/cost tradeoffs |
| Query external cloud files without loading | External table or direct stage query | External data often lacks the same performance characteristics as loaded Snowflake tables |
| Share data read-only | Secure data sharing, listing, reader account | Consumers cannot update shared provider data |
| Protect sensitive columns | Masking policy, tag-based governance, secure views | Granting SELECT alone does not mask data |
| Restrict rows by user/role/context | Row access policy, secure view | Column masking and row filtering solve different problems |
Roles, Users, and Privileges
Snowflake uses role-based access control. Users receive roles; roles receive privileges; roles can be granted to other roles to form a hierarchy.
System and Common Role Types
| Role / type | Typical purpose | Exam reminders |
|---|
ORGADMIN | Organization-level administration | Used for organization/account management, not normal object ownership |
ACCOUNTADMIN | Top account administration | Powerful; avoid as a daily operating role in least-privilege scenarios |
SECURITYADMIN | Role and privilege administration | Common role for managing grants |
USERADMIN | User and role creation | Focused on identity objects |
SYSADMIN | Warehouses, databases, schemas, and general object administration | Often owns non-security account objects |
PUBLIC | Automatically available to all users | Do not place sensitive privileges here |
| Custom account roles | Business/application access | Preferred for least privilege |
| Database roles | Database-scoped privileges | Useful for packaging database access and sharing privileges cleanly |
Privilege Patterns
| Object | Common privileges to recognize | Notes |
|---|
| Warehouse | USAGE, OPERATE, MONITOR, MODIFY, OWNERSHIP | USAGE lets a role run queries using the warehouse |
| Database | USAGE, CREATE SCHEMA, MONITOR, OWNERSHIP | Database USAGE alone does not grant table access |
| Schema | USAGE, object creation privileges, OWNERSHIP | Schema USAGE is required before object privileges are useful |
| Table | SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, OWNERSHIP | Standard table constraints are not generally enforced except cases such as NOT NULL |
| View | SELECT, OWNERSHIP | Secure views protect definition and are important in sharing scenarios |
| Stage | USAGE, plus read/write style privileges depending on stage type | Internal and external stages differ operationally |
| File format | USAGE | Needed when referenced by stages or COPY |
| Task | OPERATE, MONITOR, OWNERSHIP | Owner role needs required privileges for the task SQL |
| Stream | SELECT, OWNERSHIP | Reading a stream consumes change records in transactional workflows |
High-Yield RBAC Rules
| Rule | Why it matters |
|---|
| Privileges are granted to roles, not directly to normal application logic | Exam scenarios usually expect role design |
| A user has one primary role in a session, with optional secondary roles | Created objects are owned by the active primary role |
OWNERSHIP controls an object and is required for many grant/alter operations | Transferring ownership can affect existing grants |
MANAGE GRANTS can administer privileges broadly | Usually associated with security administration |
| Future grants automate privileges on new objects | Schema-level future grants can take precedence over database-level future grants |
| Managed access schemas centralize grant control | Object owners inside the schema do not freely grant access like normal schemas |
USAGE is required up the hierarchy | Table SELECT is not enough without database and schema USAGE |
| Least privilege favors custom roles | Do not use ACCOUNTADMIN just to query a table |
Common Grant Pattern
USE ROLE SECURITYADMIN;
CREATE ROLE analyst_ro;
GRANT USAGE ON WAREHOUSE wh_bi TO ROLE analyst_ro;
GRANT USAGE ON DATABASE analytics TO ROLE analyst_ro;
GRANT USAGE ON SCHEMA analytics.mart TO ROLE analyst_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.mart TO ROLE analyst_ro;
GRANT SELECT ON FUTURE TABLES IN SCHEMA analytics.mart TO ROLE analyst_ro;
GRANT ROLE analyst_ro TO USER j_smith;
Managed Access Schema Pattern
USE ROLE SYSADMIN;
CREATE SCHEMA analytics.secure WITH MANAGED ACCESS;
Use managed access when the scenario requires centralized privilege control within a schema.
Warehouses and Compute
A virtual warehouse is compute. It can be started, suspended, resized, and configured for concurrency.
Warehouse Decision Table
| Need | Best fit | Key distinction |
|---|
| Faster single complex query | Larger warehouse, query tuning, pruning | Size up for more compute per query |
| More concurrent users | Multi-cluster warehouse | Scale out for concurrency |
| Avoid idle credits | Auto-suspend | Suspends compute when idle |
| Reduce manual startup | Auto-resume | Convenient, but may restart spend unexpectedly |
| Control spend | Resource monitors, right-sizing, usage review | Monitors can notify and/or suspend depending on configuration |
| Isolate workloads | Separate warehouses by workload/team | Prevents ETL from starving BI queries |
| Investigate queueing | Query history, warehouse load history, query profile | Queueing often signals concurrency pressure |
Scale Up vs Scale Out
| Choice | Use when | Does not primarily solve |
|---|
| Increase warehouse size | Individual queries need more CPU/memory/I/O | High concurrency by itself |
| Multi-cluster warehouse | Many queries/users run at the same time | A single query that is poorly written |
| Separate warehouses | Workloads need isolation, cost attribution, or different sizing | Poor role design or bad SQL |
| Query optimization | Too much data scanned, poor joins, repeated expensive logic | User queuing caused by too few clusters |
Warehouse Configuration Snippet
CREATE OR REPLACE WAREHOUSE wh_bi
WAREHOUSE_SIZE = 'MEDIUM'
AUTO_SUSPEND = 300
AUTO_RESUME = TRUE
INITIALLY_SUSPENDED = TRUE;
Resource Monitor Concept
CREATE OR REPLACE RESOURCE MONITOR rm_bi
WITH CREDIT_QUOTA = 1000
FREQUENCY = MONTHLY
TRIGGERS
ON 75 PERCENT DO NOTIFY
ON 100 PERCENT DO SUSPEND;
For the exam, focus on what resource monitors do: track credit usage and trigger actions. Do not rely on memorizing arbitrary quotas.
| Mechanism | What it does | Exam trap |
|---|
| Persisted query result cache | Reuses exact eligible query results when underlying data and context allow | Does not prove the warehouse/query design is efficient |
| Warehouse cache | Local cache associated with an active warehouse | Suspending a warehouse can reduce cache benefit |
| Metadata pruning | Uses micro-partition metadata to skip irrelevant data | Functions on filter columns can reduce pruning effectiveness |
| Clustering | Improves physical organization for pruning on large tables | Not usually useful for small tables or rarely filtered data |
| Automatic clustering | Snowflake-managed maintenance for clustering | Can add background cost |
| Search optimization service | Helps selective lookup/search patterns | Not a replacement for every performance issue |
| Materialized view | Stores precomputed results for eligible query patterns | Maintenance has cost and restrictions |
| Query profile | Shows scan, joins, spills, pruning, queueing | Use it to diagnose, not guess |
- Check whether the query was queued.
- Check whether the warehouse was undersized or overloaded.
- Inspect bytes/partitions scanned.
- Look for poor filter predicates or functions blocking pruning.
- Check join order, join keys, and data skew.
- Look for local or remote disk spill.
- Decide whether to resize, scale out, rewrite SQL, cluster, or precompute.
Storage, Tables, and Data Protection
Table and Object Choices
| Object type | Use when | Key exam distinction |
|---|
| Permanent table | Durable business data | Supports Time Travel and Fail-safe behavior according to configured retention/edition |
| Transient table | Intermediate or reproducible data where Fail-safe is not needed | Lower protection than permanent tables |
| Temporary table | Session-scoped work data | Exists only for the session and can shadow same-named permanent objects in that session |
| External table | Query files in external cloud storage | Data remains external; metadata must reflect files |
| Dynamic table | Declarative transformation maintained to a target lag | Useful for ELT pipelines without hand-written stream/task logic |
| Materialized view | Precompute eligible query results | Performance feature, not a general ETL scheduler |
| View | Logical query abstraction | Standard view does not store data |
| Secure view | Protect view definition and support controlled sharing | Common for data sharing and sensitive logic |
Time Travel, Fail-safe, and Cloning
| Feature | Purpose | User-accessible? | Exam reminders |
|---|
| Time Travel | Query, clone, or restore historical data within retention | Yes | Use for accidental deletes, updates, drops, and point-in-time clone |
UNDROP | Restore dropped object within Time Travel retention | Yes | Applies only while recoverable |
| Fail-safe | Snowflake-managed disaster recovery protection | Not directly queryable by users | Not a substitute for Time Travel or backups |
| Zero-copy clone | Fast metadata-based copy of an object/database/schema | Yes | Clone shares existing storage until changes diverge |
| Point-in-time clone | Clone from historical state | Yes, within Time Travel retention | Useful for investigation or rollback |
Common Data Protection Traps
| Trap | Correct understanding |
|---|
| “Fail-safe lets users run historical queries” | Time Travel does that; Fail-safe is not user-queryable |
| “Cloning immediately doubles storage” | Zero-copy cloning shares storage until changes occur |
| “Transient means temporary” | Transient objects persist until dropped; temporary objects are session-scoped |
| “A dropped object is always recoverable” | Recovery depends on Time Travel retention and object type |
| “Clone copies everything exactly” | Verify privileges, policies, integrations, and supported COPY GRANTS behavior |
Time Travel Query Pattern
SELECT *
FROM orders AT (OFFSET => -3600);
Clone Pattern
CREATE TABLE orders_restore
CLONE orders AT (OFFSET => -3600);
Data Loading, Unloading, and Stages
COPY INTO Direction
| Command shape | Meaning |
|---|
COPY INTO table FROM @stage | Load data into Snowflake |
COPY INTO @stage FROM table_or_query | Unload data from Snowflake |
Stage Types
| Stage type | Reference | Use when | Notes |
|---|
| User stage | @~ | Personal ad hoc files | Tied to a user |
| Table stage | @%table_name | Files associated with one table | Convenient for simple loads |
| Named internal stage | @stage_name | Shared managed staging area | Snowflake stores the staged files |
| Named external stage | @stage_name with cloud URL/integration | Files already in cloud storage | Uses cloud storage such as Amazon S3, Azure storage, or Google Cloud Storage |
Batch Load Workflow
| Step | Snowflake object / command |
|---|
| Define file interpretation | File format |
| Define file location | Stage |
| Load rows | COPY INTO <table> |
| Inspect results/errors | Load history, validation, rejected files/errors |
| Automate recurring loads | Snowpipe, tasks, orchestration |
CREATE OR REPLACE FILE FORMAT ff_csv
TYPE = CSV
SKIP_HEADER = 1
FIELD_OPTIONALLY_ENCLOSED_BY = '"'
NULL_IF = ('', 'NULL');
CREATE OR REPLACE STAGE stg_orders
FILE_FORMAT = ff_csv;
COPY INTO raw.orders
FROM @stg_orders
ON_ERROR = CONTINUE;
External Stage Pattern
CREATE OR REPLACE STAGE stg_ext_orders
URL = 's3://example-bucket/orders/'
STORAGE_INTEGRATION = my_storage_integration
FILE_FORMAT = ff_csv;
For exam purposes, know that external stages usually use a storage integration rather than embedding long-lived credentials.
Validation and Load Troubleshooting
COPY INTO raw.orders
FROM @stg_orders
VALIDATION_MODE = RETURN_ERRORS;
| Problem | Likely cause | What to check |
|---|
| No rows loaded | Path/pattern mismatch, files already loaded, empty files | Stage listing, load history, file names |
| Column mismatch | Wrong delimiter, header handling, file format | File format options |
| Permission error | Missing stage/storage integration privileges | Role grants and cloud storage permissions |
| Partial load | ON_ERROR behavior | Copy output and rejected rows |
| Duplicate data | Reprocessed files or manual reload | Load history and file naming strategy |
| Slow load | File sizing, warehouse size, compression, file count | Use reasonably sized files and appropriate warehouse |
Unload Example
COPY INTO @exports/orders/
FROM (
SELECT order_id, order_date, amount
FROM mart.orders
)
FILE_FORMAT = (TYPE = CSV COMPRESSION = GZIP)
HEADER = TRUE;
Snowpipe vs COPY INTO
| Feature | COPY INTO | Snowpipe |
|---|
| Pattern | Batch/manual or orchestrated load | Near-continuous file ingestion |
| Compute | User-selected warehouse | Snowflake-managed compute |
| Trigger | SQL command or tool | Cloud notifications or REST-style ingestion pattern |
| Best for | Scheduled bulk loads, backfills | Frequent arriving files |
| Exam trap | Not automatic unless orchestrated | Not ideal for all large historical backfills |
SQL and Semi-Structured Data
Core SQL Concepts
| Concept | Exam reminders |
|---|
| DDL | Creates/alters/drops objects, such as tables, warehouses, schemas |
| DML | Changes data, such as INSERT, UPDATE, DELETE, MERGE |
| DCL | Grants/revokes privileges |
| Transactions | Snowflake supports ACID transactions |
CREATE OR REPLACE | Replaces the object; can drop existing data/metadata depending on object |
| Constraints | Standard table PRIMARY KEY, UNIQUE, and FOREIGN KEY constraints are generally informational; NOT NULL is enforced |
| Identifier case | Unquoted identifiers are stored uppercase; quoted identifiers preserve case and require exact reference |
Semi-Structured Types
| Type | Purpose |
|---|
VARIANT | Stores semi-structured values such as JSON |
OBJECT | Key-value structure |
ARRAY | Ordered collection |
FLATTEN | Expands arrays/objects into rows |
PARSE_JSON | Converts JSON text into VARIANT |
TRY_TO_* functions | Convert safely without failing the whole query on bad values |
JSON Query Pattern
SELECT
event_data:customer.id::STRING AS customer_id,
event_data:order.amount::NUMBER AS amount
FROM raw.events;
Flatten Pattern
SELECT
e.event_id,
item.value:sku::STRING AS sku,
item.value:quantity::NUMBER AS quantity
FROM raw.events e,
LATERAL FLATTEN(input => e.event_data:items) item;
Timestamp Distinctions
| Type | Meaning | Use when |
|---|
TIMESTAMP_NTZ | No time zone | Local/business timestamp without zone conversion |
TIMESTAMP_LTZ | Stored relative to session local time zone behavior | User-facing local time zone handling |
TIMESTAMP_TZ | Includes time zone offset | Need explicit offset preservation |
Streams, Tasks, and ELT Automation
Streams and Tasks
| Feature | What it does | Key distinction |
|---|
| Stream | Tracks change data for a table/view-like source | A stream stores offsets/change metadata; it does not run code |
| Standard stream | Tracks inserts, deletes, and updates | Updates can appear as delete/insert-style change records |
| Append-only stream | Tracks appended rows | Useful when only inserts matter |
| Task | Executes SQL on a schedule or dependency | Task owner role must have privileges |
| Task graph | Parent/child task workflow | Useful for multi-step pipelines |
| Dynamic table | Maintains query result based on target lag | Declarative alternative for many incremental transformation patterns |
Stream and Task Pattern
CREATE OR REPLACE STREAM orders_stream
ON TABLE raw.orders;
CREATE OR REPLACE TASK merge_orders_task
WAREHOUSE = wh_etl
SCHEDULE = 'USING CRON 0 * * * * UTC'
WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
MERGE INTO mart.orders t
USING (
SELECT *
FROM orders_stream
WHERE METADATA$ACTION = 'INSERT'
) s
ON t.order_id = s.order_id
WHEN MATCHED THEN
UPDATE SET amount = s.amount
WHEN NOT MATCHED THEN
INSERT (order_id, amount)
VALUES (s.order_id, s.amount);
After creating a task, remember that tasks may need to be resumed before they run.
ALTER TASK merge_orders_task RESUME;
Dynamic Table Pattern
CREATE OR REPLACE DYNAMIC TABLE mart.daily_sales
TARGET_LAG = '1 hour'
WAREHOUSE = wh_etl
AS
SELECT
order_date,
SUM(amount) AS total_amount
FROM raw.orders
GROUP BY order_date;
Automation Decision Table
| Requirement | Prefer |
|---|
| Process every change from a source table | Stream plus task |
| Schedule a SQL statement | Task |
| Build a task dependency chain | Task graph |
| Maintain transformed result to freshness target | Dynamic table |
| Load files as they arrive | Snowpipe |
| Batch reload/backfill | COPY INTO with warehouse |
Views, Sharing, and Collaboration
View and Sharing Choices
| Need | Use |
|---|
| Reusable query abstraction | View |
| Protect view definition or expose controlled logic | Secure view |
| Precompute query results | Materialized view |
| Share read-only live data | Secure data sharing |
| Publish discoverable data product | Listing |
| Share with consumer without their own Snowflake account | Reader account |
Secure Data Sharing Concepts
| Provider does | Consumer does |
|---|
| Creates share/listing | Creates database from share/listing |
| Grants privileges on selected database objects | Uses own compute to query shared data |
| Controls exposed objects | Cannot update provider’s shared objects |
| Can expose secure views for filtered data | Sees only what provider grants |
Provider Pattern
CREATE OR REPLACE SECURE VIEW share_db.public.v_sales AS
SELECT region, order_date, amount
FROM mart.sales
WHERE region IS NOT NULL;
CREATE SHARE sh_sales;
GRANT USAGE ON DATABASE share_db TO SHARE sh_sales;
GRANT USAGE ON SCHEMA share_db.public TO SHARE sh_sales;
GRANT SELECT ON VIEW share_db.public.v_sales TO SHARE sh_sales;
Exact account-identification syntax for adding consumers can vary by account naming context, but the exam concept is stable: the provider grants selected objects to a share, and the consumer creates a database from that share.
Sharing Traps
| Trap | Correct understanding |
|---|
| “Sharing copies data into the consumer account” | Direct sharing exposes live read-only data without copying table data |
| “Consumers pay provider warehouse cost” | Consumers generally use their own compute, except reader-account-style scenarios |
| “A share gives all database objects automatically” | Provider grants only selected objects |
| “Shared data can be updated by the consumer” | Shares are read-only to consumers |
| “A normal view is always safe for sharing sensitive logic” | Secure views are designed for protected definitions and controlled sharing |
Governance, Security, and Compliance Controls
Security Control Matrix
| Requirement | Snowflake control |
|---|
| Centralized user authentication | SSO / federated authentication |
| Additional login protection | MFA |
| Automated user and group lifecycle | SCIM integration |
| Service/application authentication | Key-pair authentication, OAuth, integrations |
| Restrict login by IP/network | Network policy |
| Private network connectivity | Private connectivity options supported by the cloud/provider |
| Least privilege | Custom roles, role hierarchy, database roles |
| Sensitive column protection | Masking policy |
| Row-level filtering | Row access policy |
| Classify or manage objects by metadata | Tags and governance features |
| Audit access | Access history and query history |
| Protect shared logic | Secure views / secure functions |
| External cloud access | Storage integrations and external access integrations where applicable |
Masking Policy Pattern
CREATE OR REPLACE MASKING POLICY mask_email
AS (val STRING) RETURNS STRING ->
CASE
WHEN CURRENT_ROLE() IN ('PII_READ') THEN val
ELSE '***MASKED***'
END;
ALTER TABLE customer
MODIFY COLUMN email
SET MASKING POLICY mask_email;
Row Access Policy Pattern
CREATE OR REPLACE ROW ACCESS POLICY region_filter
AS (region STRING) RETURNS BOOLEAN ->
CURRENT_ROLE() = 'SALES_ADMIN'
OR region = CURRENT_ROLE();
ALTER TABLE sales
ADD ROW ACCESS POLICY region_filter ON (region);
Governance Traps
| Trap | Correct understanding |
|---|
| “Masking removes data from the table” | Masking changes what users see at query time |
| “Row access and masking are interchangeable” | Row access filters rows; masking transforms column values |
| “A secure view replaces RBAC” | Secure views complement grants; users still need privileges |
| “Network policy controls table access” | Network policy controls connection access, not object authorization |
| “Tags enforce security by themselves” | Tags classify/label; policies and governance logic enforce behavior |
| Source | Use for | Exam reminders |
|---|
SHOW commands | Immediate metadata visible to current role | Good for quick object inspection |
DESCRIBE commands | Object definitions and properties | Useful for table, stage, warehouse, task inspection |
INFORMATION_SCHEMA | Database-scoped metadata and history functions/views | Scope and retention differ from account-level views |
SNOWFLAKE.ACCOUNT_USAGE | Account-level usage, history, governance views | May have latency; useful for auditing and trend analysis |
ORGANIZATION_USAGE | Organization-level usage across accounts | Requires appropriate organization-level access |
| Query history | Query troubleshooting, user activity, warehouse use | Use for performance and audit review |
| Load/copy history | Data loading diagnostics | Helps detect loaded files and errors |
| Task history | Task runs and failures | Check schedule, state, role privileges, SQL errors |
| Warehouse load history | Queuing and concurrency | Useful for sizing and multi-cluster decisions |
| Access history | Object access auditing | Useful for governance and impact analysis |
Common Troubleshooting Scenarios
| Symptom | Likely cause | Best next checks |
|---|
| “Insufficient privileges” | Missing role grant, database/schema USAGE, or object privilege | SHOW GRANTS, current role, role hierarchy |
| Query cannot run | No current warehouse or no warehouse USAGE | USE WAREHOUSE, warehouse grants |
| Query is queued | Warehouse overloaded or suspended/resuming | Warehouse load history, multi-cluster settings |
| Query scans too much data | Poor pruning, broad filters, function-wrapped predicates | Query profile, clustering, SQL rewrite |
| Unexpected result cache use | Same eligible query/context and unchanged data | Disable/rewrite for testing if needed |
COPY loads zero files | Path/pattern issue or files already loaded | LIST @stage, copy history |
| Snowpipe not loading | Notification, pipe, stage, or privilege issue | Pipe status, cloud notification setup, load history |
| Task does not run | Task suspended, schedule issue, missing privileges | SHOW TASKS, task history, owner role |
| Stream is stale/unusable | Changes not consumed within retention window | Stream state and table retention |
| Shared data not visible | Consumer database/share privileges missing | Provider grants and consumer role privileges |
High-Yield Distinctions
| Distinction | Remember |
|---|
| Larger warehouse vs multi-cluster warehouse | Larger helps individual query power; multi-cluster helps concurrency |
| Auto-suspend vs resource monitor | Auto-suspend stops idle compute; resource monitor tracks credit consumption and can trigger actions |
| Time Travel vs Fail-safe | Time Travel is user-accessible recovery; Fail-safe is Snowflake-managed recovery protection |
| Clone vs CTAS | Clone is metadata-based and can be point-in-time; CTAS creates a new table from query results |
| Temporary vs transient | Temporary is session-scoped; transient persists but lacks Fail-safe protection |
| Internal stage vs external stage | Internal stores files in Snowflake; external references cloud storage |
COPY INTO table vs COPY INTO @stage | Into table loads; into stage unloads |
| Snowpipe vs task | Snowpipe ingests files; task runs SQL |
| Stream vs task | Stream tracks changes; task executes processing |
| Dynamic table vs stream/task | Dynamic table is declarative freshness-based transformation; stream/task is procedural pipeline logic |
| View vs materialized view | View is logical; materialized view stores maintained results |
| Secure view vs masking policy | Secure view protects logic/exposure; masking policy protects column values at query time |
| Database role vs account role | Database role is scoped to one database; account role can span account objects |
| Share vs replication | Share exposes read-only data; replication copies data/objects for availability or locality |
| External table vs loaded table | External table references files; loaded table stores data in Snowflake-managed storage |
Exam-Day Decision Checklist
Before answering a scenario question, classify the requirement:
- Layer: Is the issue storage, compute, cloud services, security, or data movement?
- Goal: Is the priority cost, performance, recovery, governance, concurrency, or automation?
- Access path: Does the role have warehouse, database, schema, and object privileges?
- Compute ownership: Is compute user-managed, Snowflake-managed, provider-paid, or consumer-paid?
- Data state: Is data loaded into Snowflake, staged, external, shared, cloned, or historical?
- Pipeline pattern: Batch load, continuous ingestion, scheduled SQL, CDC, or declarative transformation?
- Protection need: Restore data, mask columns, filter rows, audit access, or restrict login?
- Performance signal: Queueing, scanned partitions, spills, poor pruning, or repeated computation?
Next Step
Use this Quick Reference to target weak areas, then move into COF-C02 scenario practice. For every missed question, map the explanation back to one of these decision points: warehouse sizing, RBAC grants, loading pattern, Time Travel/clone recovery, semi-structured SQL, sharing, or governance.