ARA-C01 Question 284
Single answerReload process (load history)A data engineering team loads daily CSV files from an internal stage into the SALES_RAW table using COPY INTO. A network issue caused one file, sales_2026_04_15.csv, to be loaded with corrupted rows. The source team corrected the file contents but kept the same file name and re-uploaded it to the same stage path. When the engineers reran the same COPY INTO command, Snowflake did not reload the file. They need to reload only this corrected file without reprocessing other files that were already loaded successfully. Which action should the architect recommend?
- A
Run COPY INTO SALES_RAW with FORCE=TRUE and a FILES=('sales_2026_04_15.csv') filter
- B
Run TRUNCATE TABLE SALES_RAW, then rerun the original COPY INTO command so Snowflake clears the load history for the table
- C
Use INSERT OVERWRITE on SALES_RAW from the stage because overwrite operations ignore file load history
- D
Clone SALES_RAW to a new table and run COPY INTO against the clone so Snowflake treats all staged files as new
Show answer and explanation
Correct answer: A
Explanation
Snowflake's COPY INTO command maintains load metadata so that previously loaded files are not loaded again by default. This behavior helps prevent duplicate ingestion in recurring batch processes. When a file must be reloaded intentionally, the recommended approach is to use COPY INTO with FORCE=TRUE. In this scenario, adding FILES=('sales_2026_04_15.csv') is important because it constrains the reload to the single corrected file rather than causing other files in the stage to be reprocessed. Architects should also understand that table-level operations such as TRUNCATE do not reset file load history, which is why deleting or truncating data is not an appropriate remedy. This aligns with Snowflake documentation and best practices for staged data loading, COPY INTO behavior, and load history management.
- A. Correct.
Correct. Snowflake tracks loaded files in load metadata to prevent accidental duplicate loads. If the same file name is encountered again, COPY INTO skips it unless the architect explicitly overrides that behavior. Using FORCE=TRUE tells Snowflake to load the file even if it appears in load history, and restricting the operation with FILES=('sales_2026_04_15.csv') limits the reload to only the corrected file instead of reprocessing every file in the stage.
- B. Incorrect.
Incorrect. TRUNCATE TABLE removes rows from the table, but it does not clear the COPY load history metadata used to prevent reloading previously processed files. This is a common misconception because people assume table data and file load tracking are the same thing. In Snowflake, load history is maintained separately from the table contents, so truncating the table would create unnecessary data loss without solving the specific reload problem.
- C. Incorrect.
Incorrect. INSERT OVERWRITE is not the mechanism for reloading a staged file while bypassing COPY load history. The deduplication and file-tracking behavior relevant here applies to COPY INTO from staged files. Choosing INSERT OVERWRITE reflects a misunderstanding between table replacement semantics and staged file ingestion controls.
- D. Incorrect.
Incorrect. Cloning the table does not make staged files appear new in a way that solves this targeted reload requirement. The problem is not the table structure but the need to reload one specific file that Snowflake recognizes as already processed. Creating a clone adds complexity and does not represent the recommended or efficient approach for reloading a single corrected file.