DEA-C01 Data Operations and Support Practice Question

A data engineer is running an Amazon Athena query that scans a large amount of data in Amazon S3, resulting in high costs. The data is stored in Parquet format in a partitioned table. Which strategy would be MOST effective in reducing the amount of data scanned?

⚠ Common exam trap

The trap is assuming that compression or storage-class optimization reduces Athena query cost — candidates forget that Athena bills on bytes scanned, so only partition pruning and columnar formats actually lower the bill.

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

✓

Ensure the query includes a WHERE clause that filters on partition columns.

In Athena, partition pruning is the single most effective way to reduce data scanned because Athena only reads the S3 prefixes that match the partition filter. Adding a WHERE clause on partition columns (A) lets the query engine skip entire partitions, dramatically lowering both cost and runtime. This is especially impactful with Parquet, which already supports columnar projection and predicate pushdown.

Answer analysis

Option-by-option breakdown

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

✓
Ensure the query includes a WHERE clause that filters on partition columns.
Why this is correct
Partition pruning uses the WHERE clause on partition columns to skip entire partitions of the Parquet table, so Athena reads only matching S3 prefixes. This directly reduces bytes scanned, which is the cost driver for the query.
✗
Convert the Parquet files to CSV format and apply GZIP compression.
Why it's wrong here
CSV is row-based and uncompressed columns cannot be pruned, so Athena reads far more bytes than Parquet's columnar encoding allows; GZIP only shrinks each file. It is tempting because compression reduces storage footprint, and it would suit archival storage rather than scan-cost reduction on an already columnar table.
✗
Use S3 Intelligent-Tiering storage class to reduce storage costs.
Why it's wrong here
Intelligent-Tiering changes storage pricing tiers based on access patterns; it does not alter how much data Athena scans per query, so scan costs are unchanged. It is tempting because it lowers S3 storage bills automatically, and it would be correct for cost-optimising infrequently accessed objects rather than reducing query bytes.
✗
Increase the number of partitions by adding more partition columns.
Why it's wrong here
Adding partition columns creates more, smaller partitions but does not reduce bytes read unless queries filter on those columns; over-partitioning also increases metadata overhead. It is tempting because partitioning prunes data, and it would be correct when the new columns match common query predicates and existing partitions are too coarse.

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