DEA-C01 Data Operations and Support Practice Question

A company uses Amazon S3 to store raw data and runs AWS Glue ETL jobs to transform it into Parquet. The data is then queried using Amazon Athena. Queries are slow and expensive due to high scan volumes. Which THREE design changes can improve query performance and reduce costs? (Select THREE.)

⚠ Common exam trap

Candidates often confuse bucketing with partitioning, or assume that increasing file count always improves parallelism, when in fact small files harm performance in distributed query engines like Athena.

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 data to a columnar format like Parquet or ORC if not already

Option B is correct because columnar formats such as Parquet or ORC let Athena read only the columns referenced in a query, dramatically reducing the bytes scanned compared to row-based formats like CSV or JSON. Option C is correct because splittable compression such as Snappy (or Zstandard) reduces storage and scan volume while still allowing Athena to split large files across parallel readers, unlike non-splittable gzip on a single object. Option E is correct because partitioning by frequently filtered columns such as date or region enables partition pruning, so Athena skips reading irrelevant S3 prefixes and scans far less data. Option A is not appropriate because shrinking files to 1 MB creates a huge number of small files, increasing S3 LIST and request overhead and hurting, not helping, Athena performance. Option D is not appropriate here because bucketing on high-cardinality columns does not reduce the data scanned by Athena and is generally used for join optimization in Hive/Spark, not for lowering Athena scan 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.

✗
Increase the number of files by reducing file size to 1 MB
Why it's wrong here
Small 1 MB files multiply S3 list and open operations, and Athena's per-file overhead dominates, increasing scan time and cost rather than reducing it. Compaction into larger files is the goal. This would suit streaming ingestion needing low-latency writes, not analytical query workloads.
✓
Convert the data to a columnar format like Parquet or ORC if not already
Why this is correct
Columnar formats such as Parquet or ORC store data by column, so Athena reads only the columns referenced in a query instead of every field. This directly cuts bytes scanned, which is the billed metric, lowering both query latency and cost for the existing Glue-produced data.
✓
Compress the data using a splittable compression format like Snappy
Why this is correct
Snappy is splittable, so Athena and Glue can parallelise reads across a single compressed file rather than one worker per file. Combined with reduced bytes on disk, this lowers scan volume and cost while preserving parallelism, unlike non-splittable gzip.
✗
Use bucketing on high-cardinality columns
Why it's wrong here
Bucketing partitions files by hash of a column, which helps only when queries filter on that column with high selectivity; high-cardinality columns produce excessive buckets and little pruning benefit. It would be right for a frequently filtered, moderate-cardinality join key.
✓
Partition the data by commonly filtered columns such as date or region
Why this is correct
Partitioning by frequently filtered columns such as date or region lets Athena prune partitions via the metastore, reading only matching S3 prefixes. This directly reduces bytes scanned, the cost driver, and speeds queries that filter on those columns.

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