COF-C02 — Snowflake SnowPro Core Certification Quick Reference

Compact Quick Reference for the Snowflake SnowPro Core Certification (COF-C02): architecture, RBAC, warehouses, loading, SQL, sharing, governance, and performance.

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 queriesWarehouse size, pruning, clustering, query profile, caching
Too many users waitingMulti-cluster warehouse, concurrency, queuing
Least privilegeRoles, grants, ownership, managed access schemas
Recovery from accidental changeTime Travel, UNDROP, zero-copy clone
Disaster recoveryReplication, failover, Fail-safe distinction
Batch ingestionStages, file formats, COPY INTO <table>
Near-continuous ingestionSnowpipe or Snowpipe Streaming
Change data captureStreams plus tasks
Shared read-only dataSecure data sharing, listings, reader accounts
Column/row protectionMasking 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 / conceptWhat it doesExam reminders
Cloud services layerAuthentication, authorization, metadata, parsing, optimization, transaction managementNot the same as a virtual warehouse; some features use Snowflake-managed compute/background services
Virtual warehouseUser-managed compute for SQL queries, DML, loading, unloading, and many tasksScale up for more power per query; scale out with multi-cluster for concurrency
Storage layerCompressed, columnar data stored in Snowflake-managed storageIndependent of warehouse size; data persists when warehouses suspend
Micro-partitionsImmutable storage units with metadata used for pruningGood pruning reduces scanned data; poor clustering can increase scans
Database and schemaLogical containers for objectsWarehouses do not “contain” databases; any role with privileges can query using any usable warehouse
AccountSecurity, users, roles, warehouses, databases, integrationsMost administrative objects live at account scope
OrganizationHigher-level grouping of Snowflake accountsRelevant for cross-account governance, usage visibility, replication, and account management

Object Hierarchy

LevelExamplesNotes
OrganizationAccountsManaged outside an individual database
AccountUsers, roles, warehouses, databases, integrations, network policiesAccount-level privileges matter
DatabaseSchemas, database rolesUSAGE on database is required before schema/object access
SchemaTables, views, stages, file formats, pipes, streams, tasks, functions, proceduresUSAGE on schema is required before object access
ObjectTable, view, stage, task, stream, pipeObject-specific privileges apply

Feature Selection Matrix

ScenarioChoose / considerAvoid this trap
Run interactive SQL queriesVirtual warehouseStorage alone does not execute queries
Speed up one large resource-heavy queryLarger warehouse, query rewrite, pruning, clustering, materialized view where appropriateMulti-cluster mainly improves concurrency, not single-query speed
Reduce user queuing during BI workloadMulti-cluster warehouse, appropriate scaling policyIncreasing warehouse size may not solve concurrency
Lower idle compute costAuto-suspend, right-size warehouses, resource monitorsAuto-resume can restart spend if users/tools keep querying
Batch load staged filesCOPY INTO <table>Do not confuse with unload syntax
Near-continuous file ingestionSnowpipeSnowpipe is not the same as a user-managed warehouse load
Low-latency streaming ingestionSnowpipe StreamingDifferent pattern from file-based Snowpipe
Transform data after loadSQL, tasks, streams, dynamic tablesCOPY supports limited transformation patterns; complex ELT belongs elsewhere
Track table changesStreamA stream records change metadata; it does not execute processing
Schedule SQL or pipeline stepsTaskA task executes SQL; it does not itself detect all changes unless paired with logic such as a stream
Declarative incremental transformationDynamic tableDo not confuse with a materialized view; dynamic tables use target lag semantics
Repetitive query accelerationMaterialized view, clustering, search optimization, query designEach has maintenance/cost tradeoffs
Query external cloud files without loadingExternal table or direct stage queryExternal data often lacks the same performance characteristics as loaded Snowflake tables
Share data read-onlySecure data sharing, listing, reader accountConsumers cannot update shared provider data
Protect sensitive columnsMasking policy, tag-based governance, secure viewsGranting SELECT alone does not mask data
Restrict rows by user/role/contextRow access policy, secure viewColumn 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 / typeTypical purposeExam reminders
ORGADMINOrganization-level administrationUsed for organization/account management, not normal object ownership
ACCOUNTADMINTop account administrationPowerful; avoid as a daily operating role in least-privilege scenarios
SECURITYADMINRole and privilege administrationCommon role for managing grants
USERADMINUser and role creationFocused on identity objects
SYSADMINWarehouses, databases, schemas, and general object administrationOften owns non-security account objects
PUBLICAutomatically available to all usersDo not place sensitive privileges here
Custom account rolesBusiness/application accessPreferred for least privilege
Database rolesDatabase-scoped privilegesUseful for packaging database access and sharing privileges cleanly

Privilege Patterns

ObjectCommon privileges to recognizeNotes
WarehouseUSAGE, OPERATE, MONITOR, MODIFY, OWNERSHIPUSAGE lets a role run queries using the warehouse
DatabaseUSAGE, CREATE SCHEMA, MONITOR, OWNERSHIPDatabase USAGE alone does not grant table access
SchemaUSAGE, object creation privileges, OWNERSHIPSchema USAGE is required before object privileges are useful
TableSELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, OWNERSHIPStandard table constraints are not generally enforced except cases such as NOT NULL
ViewSELECT, OWNERSHIPSecure views protect definition and are important in sharing scenarios
StageUSAGE, plus read/write style privileges depending on stage typeInternal and external stages differ operationally
File formatUSAGENeeded when referenced by stages or COPY
TaskOPERATE, MONITOR, OWNERSHIPOwner role needs required privileges for the task SQL
StreamSELECT, OWNERSHIPReading a stream consumes change records in transactional workflows

High-Yield RBAC Rules

RuleWhy it matters
Privileges are granted to roles, not directly to normal application logicExam scenarios usually expect role design
A user has one primary role in a session, with optional secondary rolesCreated objects are owned by the active primary role
OWNERSHIP controls an object and is required for many grant/alter operationsTransferring ownership can affect existing grants
MANAGE GRANTS can administer privileges broadlyUsually associated with security administration
Future grants automate privileges on new objectsSchema-level future grants can take precedence over database-level future grants
Managed access schemas centralize grant controlObject owners inside the schema do not freely grant access like normal schemas
USAGE is required up the hierarchyTable SELECT is not enough without database and schema USAGE
Least privilege favors custom rolesDo 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

NeedBest fitKey distinction
Faster single complex queryLarger warehouse, query tuning, pruningSize up for more compute per query
More concurrent usersMulti-cluster warehouseScale out for concurrency
Avoid idle creditsAuto-suspendSuspends compute when idle
Reduce manual startupAuto-resumeConvenient, but may restart spend unexpectedly
Control spendResource monitors, right-sizing, usage reviewMonitors can notify and/or suspend depending on configuration
Isolate workloadsSeparate warehouses by workload/teamPrevents ETL from starving BI queries
Investigate queueingQuery history, warehouse load history, query profileQueueing often signals concurrency pressure

Scale Up vs Scale Out

ChoiceUse whenDoes not primarily solve
Increase warehouse sizeIndividual queries need more CPU/memory/I/OHigh concurrency by itself
Multi-cluster warehouseMany queries/users run at the same timeA single query that is poorly written
Separate warehousesWorkloads need isolation, cost attribution, or different sizingPoor role design or bad SQL
Query optimizationToo much data scanned, poor joins, repeated expensive logicUser 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.

Caching, Pruning, and Performance

MechanismWhat it doesExam trap
Persisted query result cacheReuses exact eligible query results when underlying data and context allowDoes not prove the warehouse/query design is efficient
Warehouse cacheLocal cache associated with an active warehouseSuspending a warehouse can reduce cache benefit
Metadata pruningUses micro-partition metadata to skip irrelevant dataFunctions on filter columns can reduce pruning effectiveness
ClusteringImproves physical organization for pruning on large tablesNot usually useful for small tables or rarely filtered data
Automatic clusteringSnowflake-managed maintenance for clusteringCan add background cost
Search optimization serviceHelps selective lookup/search patternsNot a replacement for every performance issue
Materialized viewStores precomputed results for eligible query patternsMaintenance has cost and restrictions
Query profileShows scan, joins, spills, pruning, queueingUse it to diagnose, not guess

Performance Troubleshooting Checklist

  1. Check whether the query was queued.
  2. Check whether the warehouse was undersized or overloaded.
  3. Inspect bytes/partitions scanned.
  4. Look for poor filter predicates or functions blocking pruning.
  5. Check join order, join keys, and data skew.
  6. Look for local or remote disk spill.
  7. Decide whether to resize, scale out, rewrite SQL, cluster, or precompute.

Storage, Tables, and Data Protection

Table and Object Choices

Object typeUse whenKey exam distinction
Permanent tableDurable business dataSupports Time Travel and Fail-safe behavior according to configured retention/edition
Transient tableIntermediate or reproducible data where Fail-safe is not neededLower protection than permanent tables
Temporary tableSession-scoped work dataExists only for the session and can shadow same-named permanent objects in that session
External tableQuery files in external cloud storageData remains external; metadata must reflect files
Dynamic tableDeclarative transformation maintained to a target lagUseful for ELT pipelines without hand-written stream/task logic
Materialized viewPrecompute eligible query resultsPerformance feature, not a general ETL scheduler
ViewLogical query abstractionStandard view does not store data
Secure viewProtect view definition and support controlled sharingCommon for data sharing and sensitive logic

Time Travel, Fail-safe, and Cloning

FeaturePurposeUser-accessible?Exam reminders
Time TravelQuery, clone, or restore historical data within retentionYesUse for accidental deletes, updates, drops, and point-in-time clone
UNDROPRestore dropped object within Time Travel retentionYesApplies only while recoverable
Fail-safeSnowflake-managed disaster recovery protectionNot directly queryable by usersNot a substitute for Time Travel or backups
Zero-copy cloneFast metadata-based copy of an object/database/schemaYesClone shares existing storage until changes diverge
Point-in-time cloneClone from historical stateYes, within Time Travel retentionUseful for investigation or rollback

Common Data Protection Traps

TrapCorrect 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 shapeMeaning
COPY INTO table FROM @stageLoad data into Snowflake
COPY INTO @stage FROM table_or_queryUnload data from Snowflake

Stage Types

Stage typeReferenceUse whenNotes
User stage@~Personal ad hoc filesTied to a user
Table stage@%table_nameFiles associated with one tableConvenient for simple loads
Named internal stage@stage_nameShared managed staging areaSnowflake stores the staged files
Named external stage@stage_name with cloud URL/integrationFiles already in cloud storageUses cloud storage such as Amazon S3, Azure storage, or Google Cloud Storage

Batch Load Workflow

StepSnowflake object / command
Define file interpretationFile format
Define file locationStage
Load rowsCOPY INTO <table>
Inspect results/errorsLoad history, validation, rejected files/errors
Automate recurring loadsSnowpipe, tasks, orchestration

File Format and Load Example

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;
ProblemLikely causeWhat to check
No rows loadedPath/pattern mismatch, files already loaded, empty filesStage listing, load history, file names
Column mismatchWrong delimiter, header handling, file formatFile format options
Permission errorMissing stage/storage integration privilegesRole grants and cloud storage permissions
Partial loadON_ERROR behaviorCopy output and rejected rows
Duplicate dataReprocessed files or manual reloadLoad history and file naming strategy
Slow loadFile sizing, warehouse size, compression, file countUse 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

FeatureCOPY INTOSnowpipe
PatternBatch/manual or orchestrated loadNear-continuous file ingestion
ComputeUser-selected warehouseSnowflake-managed compute
TriggerSQL command or toolCloud notifications or REST-style ingestion pattern
Best forScheduled bulk loads, backfillsFrequent arriving files
Exam trapNot automatic unless orchestratedNot ideal for all large historical backfills

SQL and Semi-Structured Data

Core SQL Concepts

ConceptExam reminders
DDLCreates/alters/drops objects, such as tables, warehouses, schemas
DMLChanges data, such as INSERT, UPDATE, DELETE, MERGE
DCLGrants/revokes privileges
TransactionsSnowflake supports ACID transactions
CREATE OR REPLACEReplaces the object; can drop existing data/metadata depending on object
ConstraintsStandard table PRIMARY KEY, UNIQUE, and FOREIGN KEY constraints are generally informational; NOT NULL is enforced
Identifier caseUnquoted identifiers are stored uppercase; quoted identifiers preserve case and require exact reference

Semi-Structured Types

TypePurpose
VARIANTStores semi-structured values such as JSON
OBJECTKey-value structure
ARRAYOrdered collection
FLATTENExpands arrays/objects into rows
PARSE_JSONConverts JSON text into VARIANT
TRY_TO_* functionsConvert 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

TypeMeaningUse when
TIMESTAMP_NTZNo time zoneLocal/business timestamp without zone conversion
TIMESTAMP_LTZStored relative to session local time zone behaviorUser-facing local time zone handling
TIMESTAMP_TZIncludes time zone offsetNeed explicit offset preservation

Streams, Tasks, and ELT Automation

Streams and Tasks

FeatureWhat it doesKey distinction
StreamTracks change data for a table/view-like sourceA stream stores offsets/change metadata; it does not run code
Standard streamTracks inserts, deletes, and updatesUpdates can appear as delete/insert-style change records
Append-only streamTracks appended rowsUseful when only inserts matter
TaskExecutes SQL on a schedule or dependencyTask owner role must have privileges
Task graphParent/child task workflowUseful for multi-step pipelines
Dynamic tableMaintains query result based on target lagDeclarative 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

RequirementPrefer
Process every change from a source tableStream plus task
Schedule a SQL statementTask
Build a task dependency chainTask graph
Maintain transformed result to freshness targetDynamic table
Load files as they arriveSnowpipe
Batch reload/backfillCOPY INTO with warehouse

Views, Sharing, and Collaboration

View and Sharing Choices

NeedUse
Reusable query abstractionView
Protect view definition or expose controlled logicSecure view
Precompute query resultsMaterialized view
Share read-only live dataSecure data sharing
Publish discoverable data productListing
Share with consumer without their own Snowflake accountReader account

Secure Data Sharing Concepts

Provider doesConsumer does
Creates share/listingCreates database from share/listing
Grants privileges on selected database objectsUses own compute to query shared data
Controls exposed objectsCannot update provider’s shared objects
Can expose secure views for filtered dataSees 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

TrapCorrect 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

RequirementSnowflake control
Centralized user authenticationSSO / federated authentication
Additional login protectionMFA
Automated user and group lifecycleSCIM integration
Service/application authenticationKey-pair authentication, OAuth, integrations
Restrict login by IP/networkNetwork policy
Private network connectivityPrivate connectivity options supported by the cloud/provider
Least privilegeCustom roles, role hierarchy, database roles
Sensitive column protectionMasking policy
Row-level filteringRow access policy
Classify or manage objects by metadataTags and governance features
Audit accessAccess history and query history
Protect shared logicSecure views / secure functions
External cloud accessStorage 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

TrapCorrect 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

Monitoring and Metadata Reference

SourceUse forExam reminders
SHOW commandsImmediate metadata visible to current roleGood for quick object inspection
DESCRIBE commandsObject definitions and propertiesUseful for table, stage, warehouse, task inspection
INFORMATION_SCHEMADatabase-scoped metadata and history functions/viewsScope and retention differ from account-level views
SNOWFLAKE.ACCOUNT_USAGEAccount-level usage, history, governance viewsMay have latency; useful for auditing and trend analysis
ORGANIZATION_USAGEOrganization-level usage across accountsRequires appropriate organization-level access
Query historyQuery troubleshooting, user activity, warehouse useUse for performance and audit review
Load/copy historyData loading diagnosticsHelps detect loaded files and errors
Task historyTask runs and failuresCheck schedule, state, role privileges, SQL errors
Warehouse load historyQueuing and concurrencyUseful for sizing and multi-cluster decisions
Access historyObject access auditingUseful for governance and impact analysis

Common Troubleshooting Scenarios

SymptomLikely causeBest next checks
“Insufficient privileges”Missing role grant, database/schema USAGE, or object privilegeSHOW GRANTS, current role, role hierarchy
Query cannot runNo current warehouse or no warehouse USAGEUSE WAREHOUSE, warehouse grants
Query is queuedWarehouse overloaded or suspended/resumingWarehouse load history, multi-cluster settings
Query scans too much dataPoor pruning, broad filters, function-wrapped predicatesQuery profile, clustering, SQL rewrite
Unexpected result cache useSame eligible query/context and unchanged dataDisable/rewrite for testing if needed
COPY loads zero filesPath/pattern issue or files already loadedLIST @stage, copy history
Snowpipe not loadingNotification, pipe, stage, or privilege issuePipe status, cloud notification setup, load history
Task does not runTask suspended, schedule issue, missing privilegesSHOW TASKS, task history, owner role
Stream is stale/unusableChanges not consumed within retention windowStream state and table retention
Shared data not visibleConsumer database/share privileges missingProvider grants and consumer role privileges

High-Yield Distinctions

DistinctionRemember
Larger warehouse vs multi-cluster warehouseLarger helps individual query power; multi-cluster helps concurrency
Auto-suspend vs resource monitorAuto-suspend stops idle compute; resource monitor tracks credit consumption and can trigger actions
Time Travel vs Fail-safeTime Travel is user-accessible recovery; Fail-safe is Snowflake-managed recovery protection
Clone vs CTASClone is metadata-based and can be point-in-time; CTAS creates a new table from query results
Temporary vs transientTemporary is session-scoped; transient persists but lacks Fail-safe protection
Internal stage vs external stageInternal stores files in Snowflake; external references cloud storage
COPY INTO table vs COPY INTO @stageInto table loads; into stage unloads
Snowpipe vs taskSnowpipe ingests files; task runs SQL
Stream vs taskStream tracks changes; task executes processing
Dynamic table vs stream/taskDynamic table is declarative freshness-based transformation; stream/task is procedural pipeline logic
View vs materialized viewView is logical; materialized view stores maintained results
Secure view vs masking policySecure view protects logic/exposure; masking policy protects column values at query time
Database role vs account roleDatabase role is scoped to one database; account role can span account objects
Share vs replicationShare exposes read-only data; replication copies data/objects for availability or locality
External table vs loaded tableExternal table references files; loaded table stores data in Snowflake-managed storage

Exam-Day Decision Checklist

Before answering a scenario question, classify the requirement:

  1. Layer: Is the issue storage, compute, cloud services, security, or data movement?
  2. Goal: Is the priority cost, performance, recovery, governance, concurrency, or automation?
  3. Access path: Does the role have warehouse, database, schema, and object privileges?
  4. Compute ownership: Is compute user-managed, Snowflake-managed, provider-paid, or consumer-paid?
  5. Data state: Is data loaded into Snowflake, staged, external, shared, cloned, or historical?
  6. Pipeline pattern: Batch load, continuous ingestion, scheduled SQL, CDC, or declarative transformation?
  7. Protection need: Restore data, mask columns, filter rows, audit access, or restrict login?
  8. 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.