DEA-C01 Data Operations and Support Practice Question
A data engineer is designing a data lake on Amazon S3. The data is ingested from multiple sources and must be queryable using Amazon Athena. The engineer needs to optimize query performance and reduce costs. Which THREE actions would achieve this?
⚠ Common exam trap
It's easy for candidates to confuse 'more files = more parallelism' with Athena's actual recommendation of fewer, larger files to minimize the overhead of S3 list and get operations, and they may also mistake S3 Select as a viable alternative to Athena for full SQL querying.
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
✓
Partition the data by a commonly used filter column.
Option B is correct because partitioning the S3 data by a commonly used filter column (e.g., date or region) lets Athena prune irrelevant partitions via partition projection or the AWS Glue Data Catalog, drastically reducing the bytes scanned and thus query latency and cost. Option D is correct because splittable compression formats like Snappy (and also LZO/BZip2) allow Athena to split large objects across multiple readers, preserving parallelism while lowering storage and scan costs; non-splittable formats like Gzip force a single reader per file. Option E is correct because columnar formats such as Apache Parquet or ORC enable column pruning and predicate pushdown, so Athena reads only the needed columns and row groups, cutting both I/O and cost compared to row-based CSV/JSON. Option A is incorrect because many small files create excessive per-file overhead in S3 listing, Glue catalog, and Athena planning, hurting performance and raising costs rather than increasing useful parallelism. Option C is incorrect because S3 Select is a lightweight object-level filtering feature, not a replacement for Athena's distributed SQL engine over a data lake, and it cannot perform joins, aggregations, or catalog-based queries.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store data in many small files to increase parallelism.
Why it's wrong here
Many small files increase per-object request overhead and metadata operations, degrading Athena scan efficiency and raising costs rather than reducing them. It is tempting because parallelism sounds beneficial, but the correct approach compacts files into right-sized objects and partitions data by query predicates.
- ✓
Partition the data by a commonly used filter column.
Why this is correct
Partitioning by a frequently filtered column lets Athena prune irrelevant S3 prefixes via partition metadata, scanning far less data. This directly reduces bytes scanned, cutting both query latency and per-query cost, satisfying the optimisation and cost-reduction requirements.
- ✗
Use S3 Select instead of Athena for queries.
Why it's wrong here
S3 Select filters individual objects during retrieval; it cannot join, aggregate, or query across the lake, so it cannot replace Athena's SQL engine over the dataset. It is tempting because it reduces bytes scanned for single-object lookups, and would be correct for extracting a subset of columns from one large CSV or Parquet file.
- ✓
Compress data with a splittable compression format like Snappy.
Why this is correct
Snappy is splittable, so Athena can read individual blocks in parallel across nodes rather than one reader per file. Smaller compressed objects also reduce S3 storage and scan costs, improving throughput while preserving parallelism for large datasets.
- ✓
Convert data to Apache Parquet or ORC format.
Why this is correct
Columnar formats store data by column, so Athena reads only referenced columns and skips the rest, dramatically reducing bytes scanned. Parquet and ORC also compress efficiently and support predicate pushdown, lowering both query latency and cost.
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
Related to this question
About these practice questions
This DEA-C01 question is part of Courseiva's 1,321-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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DEA-C01 practice question is part of Courseiva's free Amazon Web Services 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 DEA-C01 exam.