DEA-C02 Data Movement Practice Question
A data engineer is using COPY INTO to load data from an external stage into a table. The source files contain a column with values like '00123' that must be stored as a VARCHAR to preserve leading zeros. The target column is defined as VARCHAR(10). During the load, the engineer notices that the leading zeros are being stripped and the values are stored as '123'. What is the most likely cause?
⚠ Common exam trap
The trap here is assuming that the target column's VARCHAR definition protects the data, when an inline transformation can convert it to a number before it ever reaches the column.
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 transformation in the COPY INTO statement is casting the field to a numeric type before loading, removing the leading zeros.
The most likely cause is a transformation in the COPY INTO statement that casts the field to a numeric type. Numeric conversion drops leading zeros, and the subsequent cast to VARCHAR cannot restore them. Ensuring the field is treated as a string throughout the load, or removing the numeric cast, will preserve the original formatting.
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 transformation in the COPY INTO statement is casting the field to a numeric type before loading, removing the leading zeros.
Why this is correct
If the COPY INTO statement includes a transformation such as $1:column::NUMBER or TO_NUMBER($1), the string is converted to a number, which drops leading zeros. The resulting numeric value is then implicitly cast back to VARCHAR for the target column, but the zeros are already lost. Removing or changing the transformation preserves the original string.
- ✗
The file format has the PARSE_JSON or similar option that interprets numeric-looking strings as numbers.
Why it's wrong here
PARSE_JSON is used when loading JSON into a VARIANT column, not for CSV loads into a VARCHAR column. It would not be applied to a CSV field. The described symptom of stripped leading zeros in a VARCHAR target is not caused by PARSE_JSON or similar JSON parsing options.
- ✗
The file format has the STRIP_OUTER_ARRAY option enabled, which removes leading zeros from string values.
Why it's wrong here
STRIP_OUTER_ARRAY is a JSON file format option that removes the outer array from a JSON document. It has no effect on CSV string values or leading zeros. Enabling it for a CSV load would not cause the described behavior and is not relevant to preserving numeric-looking strings.
- ✗
The target column is implicitly cast to a numeric type because the COPY INTO statement does not specify a transformation.
Why it's wrong here
COPY INTO does not implicitly cast a VARCHAR target column to a numeric type. If the target column is VARCHAR(10), string values are loaded as-is unless a transformation changes them. The leading zeros issue is more likely caused by how the source field is parsed or by a transformation expression that casts to a number.
About these practice questions
One of 229 original DEA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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 DEA-C02 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 DEA-C02 exam.