So you're preparing for the SnowPro Core COF-C03 exam and looking for real practice questions. Maybe you've been working with Snowflake for a while and want to validate your knowledge. Or maybe you're new to Snowflake and want to know exactly what you're up against. This SnowPro Core study guide and practice test pulls together the patterns that matter across 1008+ exam questions. Architecture decisions, governance rules, loading patterns, performance traps, and the specific questions that show up again and again. No fluff about "embarking on your data cloud journey." Real stuff that gets you passing scores. Let's get into it.
SnowPro Core COF-C03 Exam Quick Facts | Detail | Info | |
|
| | Exam Code | COF-C03 | | Certification | SnowPro Core Certification | | Questions | ~55-60 | | Time | 90 minutes | | Passing Score | 750/1000 (75%) | | Cost | $175 USD | | Format | Multiple choice, multiple select | | Prerequisites | None |
Domain 1: Snowflake Architecture (31%): The Biggest Section This is where the exam starts and where most people lose points. You need to understand Snowflake's three-layer architecture cold:: Storage layer: micro-partitioned, compressed, columnar. Managed by Snowflake. You don't touch it directly.: Compute layer: virtual warehouses. Independent clusters that run queries, loads, transformations, Snowpark.: Cloud services layer: metadata, optimization, auth, access control, query parsing, transaction coordination. The exam loves this question: "Why doesn't resizing a warehouse reorganize table storage?" Because compute and storage are separate. Warehouse size affects compute, not physical data layout. This shows up in multiple variations. Warehouse types you must know: | Warehouse Type | Use When | |
|
| | Standard | Most general workloads | | Multi-cluster | Many concurrent queries, need auto-scaling | | Snowpark-optimized | Memory-intensive Snowpark workloads | Warehouse sizing traps:: Scaling up (larger warehouse) = more resources per query. Helps a single slow query.: Scaling out (multi-cluster) = more concurrent query capacity. Helps when queries queue.: Increasing warehouse size does NOT fix concurrency. Multi-cluster does.: Snowpark-optimized needs to be explicitly chosen. Standard warehouses aren't enough for heavy Snowpark. Workload isolation: Use separate warehouses for ELT, BI, data science, and loading. This is the exam-favorite answer for "how do I prevent one workload from starving another?" Not separate accounts. Not bigger warehouses. Separate independent warehouses. Table types: | Table Type | Persistence | Time Travel | Fail-safe | |
|
|
|
| | Permanent | Until dropped | Yes (1-90 days) | 7 days | | Transient | Until dropped | 0-1 day max | None | | Temporary | Session only | 0-1 day max | None | | External | N/A (files in cloud) | No | No | | Iceberg | Until dropped | No (use Snowflake managed Iceberg) | Varies | The exam tests transient vs temporary constantly. Transient persists across sessions until explicitly dropped but has no Fail-safe. Temporary is session-scoped. Views: | View Type | What It Does | |
|
| | Standard | Logical, runs underlying query each time | | Secure | Hides view definition from non-owners, can be shared | | Materialized | Precomputed results, auto-maintained by Snowflake | Secure view = protects definition/exposure, can be shared safely. Materialized view = precomputed results for repeated expensive queries. The exam mixes these up constantly. Semi-structured data: Store JSON in VARIANT. Use FLATTEN to expand arrays into rows. Use dot notation or bracket notation for path queries. FLATTEN โ clustering (clustering improves pruning, doesn't expand arrays).
Domain 2: Account Management and Governance (20%) RBAC is everything here. The exam repeats one pattern: roles get privileges, users get roles. Never grant privileges directly to users. System-defined roles (know the hierarchy): | Role | Scope | Common Misuse | |
|
|
| | ORGADMIN | Organization (multi-account) | Day-to-day work | | ACCOUNTADMIN | Entire account | Routine development | | SECURITYADMIN | Grants and roles management | Querying data | | SYSADMIN | Creates warehouses, databases | Top-level account config | | USERADMIN | Users and roles creation | Object-level governance | | PUBLIC | Everyone | Sensitive data access | Governance features and when to use them: | Feature | Use For | Don't Confuse With | |
|
|
| | Masking policy | Show different column values per role | Row access policy (filters rows) | | Row access policy | Filter visible rows by role/context | Masking (filters column values) | | Tags | Classification, governance tracking | Query performance | | Resource monitor | Credit limits/alerts | Query optimization | | Network policies | Control client IP access | Data pruning | Row access policy vs masking policy is a heavily tested distinction. Row policies filter which rows a user sees (e.g., regional manager sees only their region). Masking policies change column values per role (e.g., show full SSN to HR, masked to others). Different problems, different solutions. Managed access schemas: Let the schema owner manage object grants within their schema. Centralized control without SECURITYADMIN doing it all. The exam-favorite answer for "how do I delegate grant management?" Edition matters: Some features (dynamic data masking, external tokenization) depend on Snowflake edition. Increasing warehouse size doesn't unlock governance features. If a scenario mentions advanced security/governance, check whether edition is the constraint. Streams = change data capture for incremental processing. Tracks inserts, updates, deletes. The exam tests this against file formats (which handle parsing, not change tracking).
Domain 3: Data Loading, Unloading, and Connectivity (18%) Loading paths: | Method | When to Use | |
|
| | COPY INTO | Bulk load from stage into table | | Snowpipe | Continuous, serverless ingestion from files arriving in cloud storage | | External stage | Reference S3, Azure Blob, GCS directly | | Internal stage | Files uploaded to Snowflake-managed storage | Snowpipe is the answer whenever the scenario says "continuous," "automatic," or "as files arrive." Monthly manual COPY is not continuous ingestion. COPY error handling: COPY supports ON_ERROR = CONTINUE or RETURN_ALL_ERRORS to keep loading when some records are malformed and capture details for remediation. The exam tests this scenario specifically. Dynamic tables: Declarative incremental transformation with target lag. When the scenario says "declarative pipeline that refreshes incrementally," think dynamic tables. Not manual CTAS. Streams + tasks = CDC + scheduling combo. Streams detect changes. Tasks schedule downstream processing. Task graphs: Dependencies between scheduled tasks. When one step must run after another completes, use task graphs. Connectivity: Snowflake drivers/connectors for Java, Python, etc. Snowsight is the browser UI. SnowSQL is the CLI. For application connectivity, it's always the driver/connector: not "use only Snowsight." File formats control CSV, JSON, Parquet parsing (delimiters, headers, compression). They don't do change tracking. They don't load data themselves. They define format options for COPY.
Domain 4: Performance Optimization (21%) The pruning question is everywhere. When a large table scan shows poor partition pruning on common filters (like date), the answer depends on the cause:: After heavy D messy DML โ Define a clustering key on the filtered column: Common filter columns on very large tables โ Clustering key improves micro-partition pruning: Selective point lookups โ Search Optimization Service Clustering key vs search optimization vs materialized view: | Fix | Problem It Solves | |
|
| | Clustering key | Poor pruning on large tables with specific filter patterns | | Search Optimization Service | Point lookups returning small result sets | | Materialized view | Repeated expensive queries that benefit from precomputation | Query Profile = your best friend for diagnosing slow queries. Shows execution plan, scans, joins, spills. The exam uses this as the answer for "where is time spent." Exploding joins = massive intermediate rows. Fix: review join predicates for selectivity. Not Fail-safe (Fail-safe is disaster recovery, not query optimization). Warehouse size vs warehouse count: Single slow query? Resize up. Many concurrent queuing queries? Multi-cluster. The exam tests this distinction repeatedly. Metadata queries: Some operations (like COUNT(*) on metadata) can be answered from table metadata without scanning actual data. Know that this exists but doesn't replace actual data access for real queries.
Domain 5: Data Collaboration (10%): Small but Trap-Heavy Secure Data Sharing = live data access without file copies. Provider shares, consumer queries directly. No nightly CSV exports. No COPY INTO from consumer side. When to use what: | Method | Scenario | |
|
| | Direct share | Known Snowflake consumer accounts | | Listing | Broader distribution via Snowflake Marketplace | | Reader account | Consumers without their own Snowflake account | Direct share vs Listing: Direct shares are for specific known accounts. Listings are for Marketplace discovery. The exam will give you a scenario about sharing with a known partner: that's a direct share, not a public listing. Time Travel vs Fail-safe vs Cloning: | Feature | Who Can Use It | Duration | Purpose | |
|
|
|
| | Time Travel | Account users | 0-90 days (configurable) | User-initiated data recovery | | Fail-safe | Snowflake only (emergency) | 7 days after Time Travel | Snowflake-managed disaster recovery | | Zero-copy cloning | Account users | Immediate | Development/testing with current data | Time Travel is user-accessible. Fail-safe is Snowflake-managed only: users can't query it. The exam tests this distinction constantly. "Who can recover data in Fail-safe?" Nobody. Only Snowflake support. Zero-copy cloning uses no additional storage until data changes. Great for dev/test. The exam uses this as the answer for "quickly create a copy of production data without duplicating storage." Replication: Cross-region or cross-account copying of databases and objects for DR or geographic distribution.
