A company stores time-series data about user clicks in an Amazon S3 bucket. The raw data consists of millions of rows of user activity every day. ML engineers access the data to develop their ML…

Question

Options

• AKeep all the time-series data without partitioning in the S3 bucket. Manually move data that is
• BCreate AWS Lambda functions to copy the time-series data into separate S3 buckets. Apply S3
• COrganize the time-series data into partitions by date prefix in the S3 bucket. Apply S3 Lifecycle
• DPut each day's time-series data into its own S3 bucket. Use S3 Lifecycle policies to archive S3

• B
  5% (1)
• C
  86% (18)
• D
  10% (2)

Explanation

Organizing time-series data into date-based partitions (e.g., s3://bucket/year=2026/month=05/day=15/) is the optimal pattern for Athena because it allows the query engine to prune partitions - scanning only the 3 relevant day-folders instead of the entire dataset, dramatically reducing scan time and cost. S3 Lifecycle policies then handle the 30-day retention requirement automatically, archiving older partitions to Glacier without manual intervention.

Why the distractors fail:

• A - No partitioning forces Athena to full-scan millions of rows every query, which is the worst possible performance outcome.
• B - Lambda-driven copying into separate buckets adds unnecessary complexity and latency; it doesn't improve Athena query performance the way partitioning does, and managing cross-bucket Lifecycle policies is fragile.
• D - One bucket per day violates S3 best practices (buckets are not partitions) and Athena works within a single bucket/prefix structure via partitions, not separate buckets; cross-bucket querying requires federated queries which adds overhead.

Memory tip: Think of Athena partitions like a filing cabinet with labeled folders - Athena only opens the drawer labeled "last 3 days" instead of rifling through 30 days of files. Partition by the dimension you filter on.

No community discussion yet for this question.