COF-C03 Data Loading, Unloading, and Connectivity Practice Question
A data engineer is using the Snowpipe REST API to ingest data from an external stage. They need to ensure that the pipe does not reprocess files that have already been loaded. Which mechanism does Snowpipe use to track which files have been processed?
⚠ Common exam trap
The trap here is assuming that stage metadata or file naming prevents reprocessing, but Snowpipe's internal history is the authoritative source.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
A load history table maintained by Snowpipe
Snowpipe uses an internal load history that records the filename and checksum of each ingested file. When a new file notification arrives, Snowpipe consults this history to determine if the file has already been processed. This prevents duplicate ingestion even if the same file is staged multiple times. The other options do not provide this tracking capability.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A unique file naming convention enforced by the user
Why it's wrong here
Snowpipe does not rely on file naming conventions to avoid reprocessing. Even if files have unique names, Snowpipe uses its internal load history to determine if a file has already been loaded. A naming convention alone does not prevent duplicate ingestion, so this option is not the correct mechanism.
- ✗
A metadata table in the INFORMATION_SCHEMA
Why it's wrong here
INFORMATION_SCHEMA views provide metadata about pipes and load history, but they do not control file processing. Snowpipe uses its own internal metadata to track ingested files. Querying INFORMATION_SCHEMA does not prevent reprocessing; it is only for monitoring. Therefore, this is not the mechanism that prevents duplicate loads.
- ✗
A hash of the file stored in the stage metadata
Why it's wrong here
While Snowpipe computes a checksum for each file, the checksum is stored in Snowpipe's internal load history, not in the stage metadata. The stage itself does not track which files have been processed; it is a passive storage location. Relying on stage metadata would not prevent reprocessing, so this option is incorrect.
- ✓
A load history table maintained by Snowpipe
Why this is correct
Snowpipe maintains an internal load history that records the filename and checksum of each file it has processed. When a new file notification is received, Snowpipe checks this history to avoid reprocessing files that have already been loaded. This mechanism ensures exactly-once ingestion per file, making it the correct answer.
About these practice questions
Courseiva writes every COF-C03 question from scratch — 280 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Snowflake exam blueprint
This COF-C03 practice question is part of Courseiva's free Snowflake certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the COF-C03 exam.