DEA-C01 Data Store Management Practice Question

A media company stores millions of small JSON files in an Amazon S3 bucket and queries them with Amazon Athena. Analysts report that queries scan far more data than expected, and costs are rising. The data engineer confirms that the files are uncompressed, use no partitioning, and are stored as newline-delimited JSON. Which change will MOST reduce the data scanned per query?

⚠ Common exam trap

The trap here is treating operational knobs such as Transfer Acceleration or workgroup limits as performance optimizations for Athena scan volume.

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

✓

Convert the files to Apache Parquet, compress with Snappy, and partition the S3 prefix by event date.

Converting to a columnar format, compressing with a splittable codec, and partitioning by a common filter column collectively minimize bytes read. Parquet enables column pruning, Snappy reduces stored size, and date partitioning enables partition pruning so only relevant prefixes are read. This combination produces the largest reduction in data scanned and therefore in Athena query cost.

Answer analysis

Option-by-option breakdown

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

✓
Convert the files to Apache Parquet, compress with Snappy, and partition the S3 prefix by event date.
Why this is correct
Parquet is columnar, so Athena reads only the columns referenced in the query, and Snappy compression reduces bytes scanned further. Partitioning by event date lets the query engine prune irrelevant prefixes entirely. Together these three changes attack data scanned from three angles: column pruning, compression, and partition pruning, delivering the largest reduction.
✗
Add more small files to increase parallelism across Athena workers.
Why it's wrong here
Adding more small files worsens the problem. Each file incurs open, metadata, and listing overhead, and Athena still scans every byte of every file that matches the query. Small-file proliferation increases per-query overhead and can slow planning, so this action moves in the opposite direction of the goal.
✗
Enable S3 Transfer Acceleration on the bucket.
Why it's wrong here
Transfer Acceleration speeds up uploads and downloads over long distances by routing through edge locations. It does not change how Athena reads data, so it has no effect on bytes scanned or query cost. The analysts' problem is scan volume, not transfer latency, making this change irrelevant to the stated goal.
✗
Increase the Athena workgroup's data usage control limit.
Why it's wrong here
Data usage controls cap or alert on bytes scanned per query; they do not reduce the amount of data a query reads. Raising the limit simply allows more expensive queries to run. The goal is to lower data scanned, so this control change addresses governance rather than optimization.

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 Store Management Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question