DA0-002 Data Acquisition and Preparation Practice Question
A data engineer is acquiring semi-structured JSON event logs from a mobile application. Each event contains nested objects and arrays, and some fields are missing depending on event type. Before loading into a relational warehouse, the engineer must flatten and validate the data. Which TWO acquisition practices are most appropriate for this semi-structured source? (Choose two.)
⚠ Common exam trap
The trap here is treating JSON flexibility as a reason to postpone structure, when the acquisition layer should still enforce a target schema and validate records.
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
✓
Validate required fields, data types, and allowed enumerations during ingestion, and quarantine records that fail validation for later review.
Semi-structured acquisition works best when the pipeline imposes a governed target schema and validates records at ingestion. Mapping nested paths to flat, typed columns with explicit null handling makes missing fields intentional, while validation with quarantine protects the warehouse from malformed data and schema drift. Deferring parsing to reports, discarding optional fields, or auto-inferring schemas all trade short-term convenience for long-term inconsistency and lost information.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Validate required fields, data types, and allowed enumerations during ingestion, and quarantine records that fail validation for later review.
Why this is correct
Because JSON allows missing keys and mixed types, ingestion-time validation catches malformed records before they pollute the warehouse. Quarantining failures preserves evidence for debugging and reprocessing once the upstream bug is fixed. Enforcing enumerations on event names prevents silent schema drift, and separating valid from invalid records keeps downstream transformations and aggregates trustworthy.
- ✗
Store each raw JSON document as a single text column and defer all parsing to report-level SQL using string functions.
Why it's wrong here
Keeping JSON as opaque text forces every consumer to parse it repeatedly, which is slow and error-prone. It prevents the warehouse from enforcing types, so invalid dates or numbers surface only in reports. Missing-field handling becomes ad hoc per query, and nested arrays are especially painful to explode with string functions. This design also blocks efficient indexing and aggregation on commonly used attributes.
- ✗
Allow the ingestion job to infer types from each batch and create new columns automatically whenever an unfamiliar key appears.
Why it's wrong here
Automatic type inference and column creation produce unstable schemas: the same field may be integer in one batch and string in another, breaking comparisons and joins. Uncontrolled columns accumulate from typos or one-off events, degrading performance and governance. Schema evolution should be a deliberate, reviewed change to the mapping, not an automatic side effect of whatever keys happen to arrive.
- ✗
Load only the fields that are present in every event type and discard optional fields to guarantee a uniform structure.
Why it's wrong here
Dropping optional fields removes potentially valuable context such as device model or campaign ID that appears only on certain events. Uniformity is achieved by omission, which biases analysis and cannot be recovered later without returning to raw logs. A better approach is to include optional fields as nullable columns so their absence is represented explicitly rather than erasing the information.
- ✓
Define an explicit target schema and use schema-on-read extraction that maps nested JSON paths to flat columns, applying defaults or nulls for missing fields.
Why this is correct
Semi-structured data still needs a governed target shape for relational loading. Mapping nested paths to flat columns with defined types and null handling makes missing fields explicit rather than accidental, so validation rules can run consistently. This also decouples the landing schema from upstream JSON changes, letting the pipeline evolve through mapping updates instead of rewriting every downstream consumer.
Go deeper
Related to this question
About these practice questions
This DA0-002 question is part of Courseiva's 1,004-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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 CompTIA exam blueprint
This DA0-002 practice question is part of Courseiva's free CompTIA 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 DA0-002 exam.