How to Ingest CSV into S3 for Cost-Effective Athena Queries?

DEA-C01 By islever Editorial Last updated

Transform and process data. Perform data ingestion.

Short answer

D Use an AWS Glue ETL job to write the CSV source as Apache Parquet in the S3 data lake so Athena scans only the columns analysts query.

Question

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?
  1. Use an AWS Glue PySpark job to ingest the source data into the data lake in .csv format.
  2. Create an AWS Glue extract, transform, and load (ETL) job to read from the .csv structured data source. Configure the job to ingest the data into the data lake in JSON format.
  3. Use an AWS Glue PySpark job to ingest the source data into the data lake in Apache Avro format.
  4. Create an AWS Glue extract, transform, and load (ETL) job to read from the .csv structured data source. Configure the job to write the data into the data lake in Apache Parquet format. Correct Answer

Key Takeaways

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.

Common mistake: 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.

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

https://docs.aws.amazon.com/athena/latest/ug/columnar-storage.html

This link opens the official vendor documentation in a new tab.

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.

More DEA-C01 FAQ →

Community Votes

D
100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

  1. GiorgioGss 👍 3 Answered D
    MOST cost-effectively = parquet
  2. pypelyncar 👍 2 Answered D
    Athena is optimized for querying data stored in Parquet format. It can efficiently scan only the necessary columns for a specific query, reducing the amount of data processed. This translates to faster query execution times and lower query costs for data analysts who primarily focus on one or two columns
  3. FunkyFresco 👍 2 Answered D
    Cost effectively, and they are going to use only one or two columns, columnar.
  4. atu1789 👍 2 Answered D
    Glue + Parquet for cost efectiveness
  5. imymoco 👍 1
    Why not B? I think Athena also be able to handle json.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Amazon Redshift Compound Sort Key Query Optimization

S-grade

Secure Redshift Spectrum Access with VPC Endpoints

S-grade

Athena Federated Query for Multi-Source Iceberg Pipelines

S-grade

Reclaiming Storage in Amazon Redshift Materialized Views

S-grade

Practice All DEA-C01 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DEA-C01 Practice Test →

← Back to DEA-C01 Study Guide