Least-Overhead Schema Discovery for Changing S3 Text Files

The deciding qualifier is "LEAST operational overhead"

Every option satisfies the functional requirement — all four end with a table that Amazon Athena and Amazon Quick Suite can query, so the discriminator is purely maintenance effort as columns keep being added to the text files. The qualifier eliminates candidates one by one.

Option A gives predefined column names immediately, but "Update the table when the company adds new columns" is a manual ALTER TABLE task each time the file structure changes. That is recurring human effort, so A fails the LEAST test.

Option B and Option D both require you to "Write a custom grok classifier" / "Write a custom XML classifier" that matches the predefined column names and schema. Authoring, testing and maintaining a custom pattern is exactly the overhead the question wants you to avoid — and an XML classifier is mismatched to plain text files anyway. Both are eliminated by the same overhead clause.

Option C is the only one that leans on the "built-in classifier in AWS Glue": the crawler infers the schema from the S3 objects and writes it to the Data Catalog, and re-running the crawler picks up newly added columns automatically. Human involvement is reduced to scheduling or triggering the crawler — no custom patterns to maintain and no hand-written DDL. That is why C is the correct answer: built-in classification plus crawler-driven schema discovery yields the least operational overhead while still producing predefined, catalogued column names usable from Athena and Quick Suite.

A common counterargument is that A looks simpler because it is fewer components; but "simplicity of setup" is not "least operational overhead over time" — the ongoing manual updates make A the heavier choice.