COF-C02 — Snowflake SnowPro Core Certification Exam Blueprint

How to Use This Exam Blueprint

Use this independent Exam Blueprint as a practical study map for the Snowflake SnowPro Core Certification (COF-C02) from Snowflake. It is designed to help you turn broad exam areas into concrete review tasks.

For each row or checkbox, mark your status:

• Green: you can explain it, choose the right option in a scenario, and recognize the relevant Snowflake SQL or object.
• Yellow: you recognize it but still confuse edge cases or need notes.
• Red: you would likely guess under exam pressure.

Do not treat this as an exact official weighting guide. Instead, use it to check readiness across the Snowflake platform concepts, administration tasks, SQL patterns, data loading workflows, performance decisions, security controls, and governance features that a Core-level candidate should be comfortable with.

COF-C02 readiness areas at a glance

Snowflake architecture and object model

Core architecture checks

Be ready to explain Snowflake as a platform where storage, compute, and services are separated.

Object hierarchy checklist

You should be able to describe the role of each object and where it fits.

• Organization
• Account
• Database
• Schema
• Table
• View
• Materialized view, when relevant
• Stage
• File format
• Pipe
• Stream
• Task
• Warehouse
• Role
• User
• Share
• Resource monitor
• Policy objects, such as masking or row access policies

Can you do this?

• Explain why suspending a warehouse does not delete data.
• Identify when a problem is likely caused by compute, storage design, access control, or data loading configuration.
• Read a fully qualified name such as DATABASE.SCHEMA.OBJECT.
• Explain why Snowflake does not require traditional manual index management for most table access patterns.
• Distinguish cloning, sharing, replication concepts, and copying data.
• Explain why metadata and object privileges matter in troubleshooting.

Security, identity, and access control

Security questions often test whether you can reason through role inheritance, object privileges, and least-privilege access.

Access control readiness table

Grant and role pattern recognition

You do not need to memorize every privilege combination, but you should recognize common grant patterns and troubleshoot missing privileges.

USE ROLE SECURITYADMIN;

CREATE ROLE analyst_ro;

GRANT USAGE ON DATABASE analytics TO ROLE analyst_ro;
GRANT USAGE ON SCHEMA analytics.marts TO ROLE analyst_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.marts TO ROLE analyst_ro;

GRANT ROLE analyst_ro TO USER candidate_user;

Access troubleshooting checklist

When a user cannot query data, check in this order:

1. Is the correct role active?
2. Is the role granted directly or through a role hierarchy?
3. Does the role have USAGE on the warehouse?
4. Does the role have USAGE on the database?
5. Does the role have USAGE on the schema?
6. Does the role have object-level access such as SELECT?
7. Is access affected by a masking policy, row access policy, secure view, or tag-based policy?
8. Is authentication or network policy blocking the session?
9. Are future grants needed for newly created objects?
10. Is ownership or managed access schema behavior relevant?

Virtual warehouses, compute, and cost control

Warehouse decision table

Compute cost reasoning

Be ready to reason directionally about credit consumption. If a rate table is provided in study material or a scenario, you should know how to apply it.

Readiness checks:

• Explain why a larger warehouse can finish work faster but may consume at a different credit rate.
• Explain why auto-suspend and auto-resume matter for interactive workloads.
• Distinguish warehouse size from multi-cluster scaling.
• Know when to isolate workloads with separate warehouses.
• Know how resource monitors help control or alert on credit usage.
• Recognize that storage, compute, and cloud services usage are separate cost considerations.

Warehouse configuration pattern

CREATE OR REPLACE WAREHOUSE wh_reporting
  WAREHOUSE_SIZE = 'MEDIUM'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

Be ready to identify what each setting is intended to influence: compute capacity, idle behavior, and automatic startup.

Data storage, table design, and semi-structured data

Table and storage concepts

Semi-structured data checklist

Snowflake Core candidates should be comfortable with semi-structured data at the concept and query level.

• Know when to use VARIANT.
• Distinguish VARIANT, OBJECT, and ARRAY.
• Parse nested JSON-like data using path notation.
• Cast semi-structured values to expected SQL types.
• Use FLATTEN to turn arrays into rows.
• Explain why schema-on-read can help with flexible ingestion.
• Identify when repeated casting or poor path filters may affect performance.
• Choose between raw landing tables and curated relational tables.

Example pattern:

SELECT
  payload:event_type::string AS event_type,
  payload:user:id::string AS user_id,
  item.value:sku::string AS sku
FROM raw_events,
LATERAL FLATTEN(input => payload:items) item;

Data modeling readiness prompts

Can you explain the tradeoff?

Data loading, staging, and unloading

Loading workflow map

Stage and COPY pattern recognition

CREATE OR REPLACE FILE FORMAT ff_csv
  TYPE = CSV
  SKIP_HEADER = 1
  FIELD_OPTIONALLY_ENCLOSED_BY = '"';

CREATE OR REPLACE STAGE stg_sales
  FILE_FORMAT = ff_csv;

COPY INTO sales_raw
FROM @stg_sales/inbound/
ON_ERROR = 'CONTINUE';

Be ready to interpret:

• Stage location and path.
• File format definition.
• Header handling.
• Error behavior.
• Whether files have already been loaded.
• Whether data lands in raw, staging, or production tables.
• Whether the load is manual, scheduled, or event-driven.

Data loading scenario checks

SQL transformations and data pipelines

Transformation artifacts

MERGE pattern recognition

MERGE INTO dim_customer t
USING staged_customer s
  ON t.customer_id = s.customer_id
WHEN MATCHED THEN UPDATE SET
  t.email = s.email,
  t.updated_at = s.updated_at
WHEN NOT MATCHED THEN INSERT
  (customer_id, email, updated_at)
VALUES
  (s.customer_id, s.email, s.updated_at);

Be ready to identify when MERGE is more appropriate than append-only insert.

Stream and task readiness

• Explain that a stream represents change tracking metadata, not a full independent copy of the table.
• Know why tasks need compute to execute.
• Recognize dependency chains between tasks.
• Understand that incremental processing requires careful handling of successful and failed runs.
• Know when a simple scheduled query is enough versus when change tracking is needed.

Performance tuning and query troubleshooting

Query diagnosis table

Slow-query decision path

    flowchart TD
	    A[Slow query] --> B{Queued before running?}
	    B -->|Yes| C[Check warehouse load, concurrency, workload isolation]
	    B -->|No| D{Scanning too much data?}
	    D -->|Yes| E[Check filters, clustering, partition pruning, data types]
	    D -->|No| F{Expensive joins or spill?}
	    F -->|Yes| G[Review join logic, intermediate rows, warehouse size]
	    F -->|No| H{Repeated dashboard or point lookup?}
	    H -->|Yes| I[Consider caching behavior, materialized view, search optimization, query rewrite]
	    H -->|No| J[Use query profile and history views to isolate bottleneck]

Performance traps

• Assuming a bigger warehouse always fixes poor SQL.
• Assuming multi-cluster warehouses speed up one long-running query.
• Ignoring query profile evidence.
• Filtering on expressions that reduce pruning effectiveness.
• Casting data repeatedly instead of modeling curated columns.
• Letting BI dashboards run broad SELECT * queries.
• Confusing result cache speed with underlying query efficiency.
• Clustering small or unsuitable tables unnecessarily.
• Mixing heavy ETL and interactive BI on the same warehouse without reason.

Data protection, governance, and recovery concepts

Protection and recoverability checklist

Governance controls

Governance scenario prompts

• A support analyst can query a table but should see masked customer identifiers. What control fits?
• Regional managers should see only rows for their region. What control fits?
• A data product is shared externally but should not expose underlying table details. What design choices matter?
• A new sensitive column was added. How should tags, policies, and grants be reviewed?
• A developer cloned production data into a test database. What masking or access implications should be checked?

Data sharing and collaboration

Sharing readiness table

Sharing decision checks

Monitoring, metadata, and administration

Metadata and observability artifacts

Be ready to recognize what kind of question each metadata source can answer.

Administration checks

• Know which built-in roles are commonly associated with account administration, security administration, system administration, and user-level activity.
• Understand why production work should not default to the most powerful role.
• Know how to inspect grants on users, roles, and objects.
• Understand account parameters at a conceptual level.
• Know how resource monitors support cost governance.
• Remember that some account usage views may not be real-time.
• Distinguish SHOW commands from account usage views and information schema views.
• Know when object ownership matters for administrative actions.

SQL and command readiness checklist

You should recognize the purpose of common Snowflake SQL patterns even if the exam scenario does not require writing full syntax from memory.

Can you do this? Core readiness checklist

Architecture and platform

• Explain Snowflake’s separation of storage, compute, and services.
• Identify which warehouse is used for a query.
• Explain why multiple workloads may use separate warehouses against the same data.
• Distinguish database objects from compute objects.
• Explain micro-partition pruning at a high level.
• Explain how cloning differs from copying.
• Explain why Snowflake metadata is important for optimization and administration.

Security

• Build a least-privilege access path for a reporting role.
• Troubleshoot missing database, schema, table, or warehouse privileges.
• Explain role inheritance.
• Identify when future grants are needed.
• Know when managed access schemas affect grant management.
• Choose masking or row access policies for sensitive data requirements.
• Recognize authentication and network access controls.

Data loading and transformation

• Choose between batch load and continuous ingestion concepts.
• Define what a stage and file format are used for.
• Interpret a COPY INTO command.
• Explain load error handling at a conceptual level.
• Query data from a VARIANT column.
• Use FLATTEN for arrays.
• Choose MERGE for upsert-style changes.
• Explain streams and tasks at a Core level.

Performance and operations

• Read query symptoms and choose the next diagnostic step.
• Distinguish scale up from scale out.
• Explain why query queueing happens.
• Identify cost levers for warehouses.
• Explain auto-suspend and auto-resume.
• Know when clustering may help.
• Know when caching may mislead performance testing.
• Use history and metadata views conceptually for troubleshooting.

Governance, protection, and sharing

• Choose a recovery approach using Time Travel or cloning concepts.
• Explain the difference between sharing and copying data.
• Identify provider and consumer roles in secure data sharing.
• Select secure views or policies for controlled data exposure.
• Explain how tags support governance workflows.
• Consider grants and policies when sharing or cloning data.

Scenario and decision-point practice

Use these prompts to test whether you can reason like a Snowflake SnowPro Core candidate.

Common weak areas and traps

Concept traps

• Confusing a warehouse with a place where data is stored.
• Treating Snowflake like a traditional indexed database in every tuning scenario.
• Assuming all performance problems are solved by increasing warehouse size.
• Forgetting that concurrency and single-query speed are different problems.
• Assuming shared data is physically copied into the consumer account.
• Confusing Time Travel concepts with long-term backup strategy.
• Treating streams as full data tables instead of change tracking metadata.

Security traps

• Granting table access but forgetting database and schema USAGE.
• Forgetting warehouse access when troubleshooting query failures.
• Using overly powerful roles for routine work.
• Ignoring role hierarchy and active role selection.
• Forgetting future grants for newly created objects.
• Overlooking masking or row access policies when query results appear incomplete.

Data loading traps

• Misconfigured file format.
• Loading the same files repeatedly or assuming files loaded when they did not.
• Ignoring rejected rows.
• Using relational columns too early when source structure is unstable.
• Not separating raw landing from curated analytics layers.
• Forgetting that loading and transformation consume compute.

Performance traps

• Relying on result cache during benchmarking.
• Filtering on transformed expressions that reduce pruning.
• Clustering without a clear access pattern.
• Mixing heavy ETL, ad hoc analytics, and BI dashboards on one warehouse without checking impact.
• Not using query history or profile information before changing configuration.

Final-week checklist

Seven-to-three days out

• Re-read your notes on architecture, warehouses, RBAC, loading, semi-structured data, and sharing.
• Build or review a small lab that creates a role, warehouse, database, schema, table, stage, and file format.
• Practice troubleshooting access failures from missing role, warehouse, database, schema, and table privileges.
• Review at least one COPY INTO load scenario and one unload scenario.
• Practice querying VARIANT data and using FLATTEN.
• Review slow-query decision points: queueing, pruning, joins, spill, caching, and warehouse sizing.
• Review governance controls: masking, row access, secure views, tags, and sharing.

Final two days

• Redo missed practice questions by topic, not just by score.
• For every missed question, write the decision rule you should have used.
• Explain scale up vs scale out without notes.
• Explain role hierarchy and active role behavior without notes.
• Explain stages, file formats, and COPY INTO without notes.
• Explain when to use a stream, task, view, materialized view, clone, or share.
• Review Snowflake SQL command patterns until you can recognize their purpose quickly.

Last review pass

• Skim this checklist and mark any remaining Yellow or Red items.
• Focus on scenario judgment, not memorizing unsupported numbers.
• Review common traps.
• Stop studying brand-new edge topics late unless they block a core concept.
• Use practice explanations to confirm why the right answer is right and why the distractors are wrong.

Practical next step

Turn each Yellow or Red item into a short practice task: explain the concept aloud, identify the relevant Snowflake object or command, and answer two or three scenario questions on that topic. Then move into mixed COF-C02 practice so you can switch between architecture, security, loading, performance, governance, and sharing decisions under exam-style pressure.