ARA-C01 Data Engineering 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.

• ✓

  Create a view that exposes the fixed top-level keys with colon path notation (for example, src:payload:eventType) and leave the raw VARIANT column available for ad hoc queries.

  Why this is correct

  Colon path notation accesses specific keys of a VARIANT without destroying the rest of the document. The base column remains queryable, so unknown or deeply nested attributes stay available for later analysis, while consumers get stable projections of the known top-level keys. This is the standard Snowflake pattern for selectively surfacing semi-structured fields without losing fidelity.

• ✗

  Use LATERAL FLATTEN with the RECURSIVE argument set to TRUE on the raw VARIANT column to expand every nested key into separate rows, then filter the resulting KEY column to the known top-level keys.

  Why it's wrong here

  RECURSIVE TRUE recursively expands all nested arrays and objects, producing a row per leaf rather than preserving the remaining structure. Filtering afterward still materializes the full recursive explosion, which is wasteful and does not keep the untouched structure intact in a single VARIANT value. This contradicts the goal of flattening only selected top-level keys while retaining the rest.

• ✗

  Load the JSON into a relational table with one column per possible nested key, using the INFER_SCHEMA option of COPY INTO to auto-detect every attribute at load time.

  Why it's wrong here

  INFER_SCHEMA produces a column layout from the files it samples, but it does not guarantee coverage of keys that appear later or vary in casing across sources. Committing to a fixed relational shape discards attributes not detected during inference and breaks when new keys arrive. It also does not preserve the original structure for downstream exploration.

• ✗

  Store each event as a separate row using the PARSE_JSON function and then apply OBJECT_KEYS to return only the known top-level keys as an array column.

  Why it's wrong here

  OBJECT_KEYS returns the names of keys in an object, not their values, so this yields a list of key names rather than the desired projected attributes. The remaining nested values are not conveniently exposed, and downstream queries would still need path traversal. It also does not preserve the full document alongside the fixed key set.