DEA-C01 Data Operations and Support Practice Question

A company uses Amazon S3 to store large CSV files and runs Amazon Athena queries on them. The queries are becoming slower as data grows. A data engineer suggests converting the files to Apache Parquet format and partitioning the data. What is the primary benefit of converting to Parquet?

⚠ Common exam trap

Many exam-takers confuse the general benefits of Parquet (compression, schema evolution, nested data) with the primary performance benefit for Athena, which is columnar pruning reducing scanned data.

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

✓

Parquet stores data in a columnar format, reducing the amount of data scanned per query.

Parquet is a columnar storage format that stores data by columns rather than rows. When Athena queries only a subset of columns, it can read just those columns from disk, drastically reducing the amount of data scanned per query. This directly addresses the performance slowdown because Athena charges by data scanned, and less scanning means faster queries and lower costs.

Answer analysis

Option-by-option breakdown

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

✗
Parquet allows schema evolution without rewriting files.
Why it's wrong here
Schema evolution is handled by table formats such as Iceberg or Glue, not by Parquet itself, and it does not address query latency. It is tempting because Parquet files do carry schemas, and schema evolution would be the correct concern when source columns change frequently.
✗
Parquet supports nested data structures that CSV cannot.
Why it's wrong here
Parquet's columnar layout lets Athena read only referenced columns, cutting scanned bytes; nested structures are supported but irrelevant to slow CSV queries. It is tempting because nested data is a genuine Parquet capability, and it would be the deciding factor when source data is hierarchical JSON.
✓
Parquet stores data in a columnar format, reducing the amount of data scanned per query.
Why this is correct
Parquet's columnar layout lets Athena read only the columns referenced in each query rather than every field in each row, so far less data is scanned from S3. Partitioning prunes whole prefixes, but the format change itself is what satisfies the stem's primary benefit of reduced scan volume.
✗
Parquet is compressed by default, reducing storage costs.
Why it's wrong here
Compression reduces storage cost, but the stem asks why queries are slow; Parquet's columnar format and predicate pushdown cut scanned data, which is the performance gain. Compression is tempting because Parquet does compress by default, and it would be the answer if the goal were lowering S3 storage spend.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DEA-C01 Data Operations and Support Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question