DEA-C02 Data Movement Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Define the column as TIMESTAMP_NTZ and rely on implicit casting during the COPY INTO operation.

  Why it's wrong here

  Snowflake does not implicitly cast a JSON string value into TIMESTAMP_NTZ during a COPY INTO load into a VARIANT column. Implicit casting applies to scalar values, not nested semi-structured fields. The load will succeed but the value remains a string inside VARIANT, so downstream queries that expect a timestamp will fail or return incorrect comparisons.

• ✓

  Use a transformation in the COPY INTO statement with the TO_TIMESTAMP function on the JSON field.

  Why this is correct

  COPY INTO supports column-level transformations in the SELECT clause of the statement. Applying TO_TIMESTAMP($1:event_time::STRING) converts the ISO-8601 string to a TIMESTAMP_NTZ as the data is loaded, eliminating a separate post-load step. This is the intended mechanism for inline type conversion during ingestion of semi-structured files.

• ✗

  Apply a masking policy on the VARIANT column to convert the string to a timestamp at query time.

  Why it's wrong here

  Masking policies are used for data governance to obfuscate or redact values, not for type conversion. They also do not change the stored data type of the column. Using a masking policy here would not produce a TIMESTAMP_NTZ value and would add unnecessary governance complexity without solving the ingestion requirement.

• ✗

  Create a file format with the TIMESTAMP_FORMAT option set to 'YYYY-MM-DD"T"HH24:MI:SS'.

  Why it's wrong here

  TIMESTAMP_FORMAT is only applied when loading into a timestamp-typed column, not when the target is a VARIANT column. The file format option will be ignored for the JSON field, leaving the string unchanged inside the VARIANT. A transformation in the COPY statement is required to materialize a timestamp value.