Examworthyexamworthy.comSnowPro Core Certification (COF-C03) cheat sheet
Snowflake
Free to share. Examworthy is not affiliated with or endorsed by Snowflake; COF-C03 and related marks belong to their respective owners.
At a glance
Format: Multiple choice and multiple select, at a Pearson VUE testing center or online proctored
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
COF-C03 is a pick-the-right-feature exam: almost every question is a scenario with a stated constraint - cost, recovery window, latency, or least privilege - and the right answer is the cheaper, lower-overhead Snowflake feature built for exactly that need, not the heavier one that also works.
Spot the trap
Tempting wrong answers, and why they failTempting but wrong
Snowflake's three layers are storage, an in-memory cache, and a reporting layer that renders dashboards.
Why it fails
An in-memory cache and a reporting layer are not the named architectural layers. The three layers are database storage, query processing, and cloud services. Caching does exist, but only transiently within the compute layer, not as a top-level layer.
Snowflake AI Data Cloud Features and Architecture
Tempting but wrong
Adding a clustering key on the join columns fixes a query that is spilling bytes to local and remote storage.
Why it fails
Clustering improves micro-partition pruning, which reduces partitions scanned, not memory pressure. Spilled bytes signal a memory shortfall, so the fix is a larger warehouse size for more memory and local SSD, not better pruning.
Performance Optimization, Querying, and Transformation
Tempting but wrong
Custom roles that create objects should be granted directly to ACCOUNTADMIN so account settings stay consistent.
Why it fails
Granting custom object-creating roles directly under ACCOUNTADMIN concentrates excessive privilege at the very top and breaks least privilege. The standard pattern is to grant them to SYSADMIN, which owns the object-creation branch; higher roles still inherit management ability.
Account Management and Data Governance
Tempting but wrong
A Snowflake user stage (@~) is automatically scoped to whichever single table you later load from it.
Why it fails
The user stage exists per user and is referenced with @~, but it is not bound to any one table. It can hold files destined for many tables, so the claimed automatic single-table scoping does not exist.
Data Loading, Unloading, and Connectivity
Tempting but wrong
A direct share granted by account locator lets a partner with no Snowflake account mount the shared database immediately.
Why it fails
A direct share to a consumer account requires the partner to already hold their own Snowflake account, because the grant targets that account's locator. A partner with no account has no locator to grant to, so a direct share cannot reach them. A provider-managed reader account is the route for an account-less consumer.
Data Collaboration
Tempting but wrong
Snowflake is built from a staging layer, a transformation layer, and a presentation layer like a traditional ETL pipeline.
Why it fails
That describes a generic ETL data-flow pattern, not the Snowflake platform. Snowflake's actual layers are database storage, query processing through virtual warehouses, and cloud services.
Snowflake AI Data Cloud Features and Architecture
Tempting but wrong
Converting to a multi-cluster warehouse stops a single query from spilling bytes to storage.
Why it fails
Additional clusters add concurrency capacity for separate queries, but any one query runs on a single cluster. Extra clusters give that query no more memory, so spilling continues; a larger warehouse size is what adds memory per cluster.
Performance Optimization, Querying, and Transformation
Tempting but wrong
Granting a privileged custom role to PUBLIC guarantees it reaches a senior role through inheritance.
Why it fails
PUBLIC sits at the bottom of the hierarchy and is automatically held by every user, so granting a privileged role beneath PUBLIC would expose object management to everyone. Object-creating custom roles belong under SYSADMIN instead.
Account Management and Data Governance
Key terms
Exam-day rules
- Read the scenario for the constraint first. The stated need - lowest cost, the recovery window, the latency target, least privilege, one output file - is what picks the feature, so find it before you judge the options.
- When two features both work, pick the cheaper, lower-overhead one built for the job. A larger warehouse over a multi-cluster for a lone spilling query, a materialized view over a task-rebuilt summary table, zero-copy cloning over an actual copy.
- Diagnose performance from what Query Profile shows, not from a favourite fix. Bytes spilled to storage mean a memory shortfall, so scale the warehouse size up; a clustering key, more clusters, or the result cache do not address spilling.
- Default to least privilege on the role hierarchy. Grant custom object-creating roles under SYSADMIN, use SECURITYADMIN for grants and ORGADMIN for provider setup, and never reach for ACCOUNTADMIN just because it would also work.
- Split the policies by what the requirement controls. If it is about which rows appear, it is a row access policy; if it is about how a column value looks, it is a masking policy; join a mapping table when assignments change often so you never edit the policy.
Revision schedule
- Day 1Map the blueprint and book a date
- Week 1Build the architecture and feature-decision maps
- Weeks 1 to 2Go deep on architecture and performance
- Weeks 2 to 3Lock governance and the role hierarchy
- Week 3Cover loading, unloading, and collaboration