How to Ingest CSV into S3 for Cost-Effective Athena Queries?
A data engineer must ingest a source of structured data that is in .csv format into an Amazon S3 data lake. The .csv files contain 15 columns. Data analysts need to run Amazon Athena queries on one or two columns of the dataset. The data analysts rarely query the entire file. Which solution will meet these requirements MOST cost-effectively?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests columnar versus row-oriented storage for Athena, and the trap is assuming CSV, JSON, or Avro are equally cost-effective for one- or two-column queries.
Converting a 15-column CSV source into Apache Parquet with an AWS Glue ETL job lets Athena scan only the queried columns, making it the most cost-effective design for analysts who rarely read the entire file.
Choosing JSON because Athena can query it, without recognizing that JSON remains row-oriented and can force more data to be scanned for narrow column queries.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Amazon Athena charges based on data scanned, and Apache Parquet's columnar format lets Athena read only the columns referenced by a query. Because analysts query one or two of the 15 columns and rarely scan the whole file, converting the CSV source to Parquet with an AWS Glue ETL job minimizes bytes scanned and therefore query cost. Parquet also supports compression and column-level statistics, further reducing I/O for selective Athena queries. Option D matches both the ingestion mechanism and the storage format required for this cost profile.Why the Other Options Are Wrong
Option A merely re-ingests the data as CSV, so Athena still scans row-oriented files and cannot skip unneeded columns efficiently. Option B uses JSON, which Athena can query but which is row-oriented and typically less efficient for narrow column projections, so it is not the most cost-effective choice. Option C uses Apache Avro, another row-based serialization format, which does not deliver Parquet's column-pruning benefit for one- or two-column Athena queries.Community Comment Notes
GiorgioGss captures the decision as "MOST cost-effectively = parquet," while pypelyncar notes that Athena can scan only the necessary columns in Parquet and reduce data processed. FunkyFresco also points to the columnar advantage for queries that use only one or two columns. imymoco asks why JSON is not equally suitable, which reflects the common trap of assuming Athena's JSON support removes the scan-cost disadvantage.Official Reference
Exam Strategy
When a scenario emphasizes that analysts rarely query the entire file and use only specific columns, prioritize columnar formats such as Parquet and avoid formats that force scanning all columns. Look for AWS Glue ETL to convert CSV to Parquet rather than re-storing raw CSV.
Frequently Asked Questions
Why is JSON not the most cost-effective choice if Athena supports it?
JSON is row-oriented, so Athena can still scan more data for one- or two-column queries; Parquet's columnar layout reduces bytes scanned and query cost.
Does keeping the data as CSV affect Athena query cost?
Yes. CSV is row-based, so Athena reads whole rows even when analysts query only one or two columns, increasing data scanned and cost.
Related Analysis
Practice All DEA-C01 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DEA-C01 Practice Test →