DEA-C01 Data Operations and Support Practice Question

A data engineer needs to set up a data catalog for a new data lake in AWS Glue. The data resides in S3 in Parquet format. The engineer wants to ensure that the schema is automatically detected and updated when new columns are added to the data. Which configuration should the engineer use?

⚠ Common exam trap

DEA-C01 often tests the confusion between crawler schema update behaviour and partition indexing, tricking candidates into picking an optimization feature when the question is about schema evolution.

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

✓

Configure the crawler's 'Schema updates' option to 'Update the table schema'.

The Glue crawler's 'Schema updates' option controls what happens when the crawler detects schema changes in the data. Setting it to 'Update the table schema' allows the crawler to add new columns and modify the existing table definition in the Data Catalog when new columns appear in the Parquet files. This is the correct configuration for automatic schema evolution.

Answer analysis

Option-by-option breakdown

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

✗
Add a partition index to the Glue Data Catalog table.
Why it's wrong here
A partition index accelerates partition pruning lookups; it does not detect or merge new columns into the table schema. It is tempting because indexes improve catalog query performance, but it would be correct when optimising filtered queries across many partitions, not schema evolution.
✓
Configure the crawler's 'Schema updates' option to 'Update the table schema'.
Why this is correct
The Glue crawler's schema-update behaviour controls whether re-crawls revise the Data Catalog table definition. Setting it to update the table schema lets the crawler add newly detected columns automatically, satisfying the requirement that schema changes in the Parquet data be picked up without manual intervention.
✗
Set the crawler's 'Database' output to a new database.
Why it's wrong here
Choosing an output database only names where tables are written; it does not enable schema change detection. It is tempting because database selection is part of crawler setup, but it would be correct when organising catalog objects into separate logical databases rather than handling evolving Parquet columns.
✗
Enable partition indexing on the table.
Why it's wrong here
Partition indexing speeds up partition retrieval and has no role in schema detection or column updates. It is tempting as a catalog optimisation, but it would be correct when reducing lookup latency for highly partitioned tables, not when new Parquet columns must be recognised automatically.

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