COF-C03 - Data Loading, Unloading, and Connectivity - Section 3.2

Use COPY INTO to bulk load data, including load validation, error handling, and transformations during load.

Use the COPY INTO table command to bulk load staged files: validate before loading with VALIDATION_MODE, control bad records with ON_ERROR, and apply simple transformations (column reordering, casts, and omissions) during the load. Recognise that load metadata prevents the same file being loaded twice within the load-history window.

COPY INTO tablebulk loadingVALIDATION_MODEON_ERRORload metadatatransformations during load

Practice question for this objective

Free sampleData Loading, Unloading, and Connectivitymedium

A data engineer is preparing a one-off bulk load of a new CSV feed into a permanent table and wants to confirm that every row in the staged files will parse cleanly against the table definition before any rows are actually committed. The check must inspect the real files in the stage and report parsing problems without writing data into the target table. Which approach to the COPY INTO command meets this need?

COPY INTO sales_raw
  FROM @feed_stage/sales/
  FILE_FORMAT = (TYPE = CSV)
  • ARun COPY INTO with ON_ERROR set to CONTINUE so that any rows that fail to parse are skipped and the remaining valid rows are still loaded into the target table
  • BRun COPY INTO with the FORCE option enabled so that already loaded files are reprocessed and the command surfaces every parsing error encountered during the rerun
  • CRun COPY INTO with VALIDATION_MODE set to RETURN_ALL_ERRORS so the staged files are parsed and any errors are reported back while no rows are written to the target table Correct
  • DRun COPY INTO with PURGE set to TRUE so the files are scanned and removed from the stage, after which the load history can be inspected for any parsing errors
Recognise that VALIDATION_MODE parses staged files and reports load errors without committing any rows to the target table. VALIDATION_MODE instructs COPY INTO to run the load as a validation pass: it reads and parses the actual staged files against the file format and table, returns the errors it would have hit, and writes nothing to the target table. ON_ERROR, FORCE, and PURGE all govern an actual committing load, so none of them gives a true no-write dry run.

Why A is wrong: ON_ERROR with CONTINUE actually loads the good rows and skips bad ones, so it writes data into the target rather than validating without committing, which the requirement forbids.

Why B is wrong: FORCE only makes Snowflake reload files it has already loaded by ignoring load metadata, so it still commits rows and does not act as a non-committing validation step.

Why C is correct: VALIDATION_MODE parses the staged files exactly as a load would and returns the errors it finds without inserting any rows, which precisely matches a pre-load dry run against the real files.

Why D is wrong: PURGE deletes staged files after a successful load and does not suppress writing rows, so it neither validates ahead of loading nor keeps the target table empty as required.

See more COF-C03 practice questions, answers explained.

More in this domain

Back to all Data Loading, Unloading, and Connectivity objectives, or the COF-C03 cert hub.

Examworthy is not affiliated with or endorsed by Snowflake. Original, blueprint-aligned practice material only.