DEA-C01 Data Operations and Support Practice Question

A company stores raw clickstream data in an Amazon S3 bucket and uses AWS Glue crawlers to populate the AWS Glue Data Catalog. Analysts report that new partitions are not appearing in Amazon Athena queries even though new date-based folders exist in S3. The crawler runs successfully each night. What is the MOST likely cause?

⚠ Common exam trap

The trap here is assuming any nested folder structure is automatically treated as partitions, when only Hive-style key=value paths are recognized.

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

✓

The new folders do not follow the Hive-style partition naming convention (for example, year=/month=/day=) that the crawler and Athena expect.

Glue crawlers infer partitions from Hive-style key=value directory structures. When new folders use a plain date hierarchy without partition keys, the crawler treats them as ordinary prefixes and does not register partitions, so Athena cannot see the new data until the folder layout is corrected or partitions are added manually.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
The new folders do not follow the Hive-style partition naming convention (for example, year=/month=/day=) that the crawler and Athena expect.
Why this is correct
AWS Glue crawlers and Athena rely on Hive-style partition paths such as year=2024/month=01/day=15 to detect and register partitions automatically. If new folders are named plainly like 2024/01/15 without the key=value structure, the crawler will not recognize them as partitions, so they will not appear in the Data Catalog or in Athena query results.
✗
The crawler's 'Update the table definition in the Data Catalog' behavior is set to 'Create new partitions only' but the table was created manually without a partition key.
Why it's wrong here
Crawler behaviors control how table metadata is updated, but the described symptom is about partitions not appearing. Without a partition key, the crawler would still add columns and could not create partitions at all, yet the scenario implies folders already follow a date structure, so this is not the most likely cause.
✗
The S3 bucket has versioning enabled, which prevents the crawler from detecting new prefixes.
Why it's wrong here
S3 versioning retains multiple versions of objects but has no effect on prefix discovery by a Glue crawler. Crawlers list prefixes and objects via the S3 API regardless of versioning state, so versioning cannot be the reason new date folders are missing from the Data Catalog and unavailable to Athena.
✗
The crawler's output is configured to a different database, or the crawler has an exclude pattern that filters out the new date folders.
Why it's wrong here
A mismatch between the crawler's target database and the database queried in Athena, or an exclude pattern that omits the new prefixes, would indeed hide partitions. However, the scenario states the crawler runs successfully and folders exist, so an exclude pattern or wrong database is plausible but not the single most likely cause compared to a schema/partition detection issue.

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