SnowPro Core (COF-C03) · Free practice question 12 of 15
Clustering keys for partition pruning
A 5 TB table is loaded continuously and is currently unclustered. Queries that filter by `event_date` have become slow despite the WHERE clause being correct. Which is the most appropriate first step?
- A.Define a clustering key on `event_date` and allow Snowflake's background reclustering service to maintain it.
- B.Manually re-partition by running `CREATE TABLE … AS SELECT … ORDER BY event_date` once.
- C.Drop and reload the table to force micro-partition reorganization.
- D.Create a B-tree index on `event_date`.
Show answer and explanation
Correct answer: A. Define a clustering key on `event_date` and allow Snowflake's background reclustering service to maintain it.
Why: Clustering keys signal which column(s) should drive micro-partition pruning, and Snowflake reclusters in the background as data lands. There are no traditional B-tree indexes. A one-time CTAS orders the existing data but does nothing to keep new data clustered as it streams in.
More free SnowPro Core (COF-C03) questions
- Micro-partition immutability
- SECURITYADMIN for user and role management
- Multi-cluster warehouses for concurrency
- Snowflake edition for extended Time Travel
- Recovering a truncated table with Time Travel
- Types of internal stages
- File sizing for COPY INTO
- Query result cache
- Reader accounts for non-Snowflake consumers
- LATERAL FLATTEN on VARIANT arrays
- Streams and tasks for change data capture
- Network policies for IP allowlisting
- Zero-copy cloning for QA environments
- Snowpipe auto-ingest for low latency