DEA-C01 Practice Question 26: Athena Partition Projection

The delay before scanning is partition metadata retrieval. "Normally, when processing queries, Athena makes a GetPartitions call to the AWS Glue Data Catalog before performing partition pruning. If a table has a large number of partitions, using GetPartitions can affect performance negatively." Partition projection removes that call entirely: Athena calculates partition values and locations in memory from range and type properties you set on the table, so it never asks the catalog. Because the partitions are computed rather than looked up, the feature "also automates partition management because it removes the need to manually create partitions"; the nightly registration job disappears. Date-based, continuously increasing partitions like these are the textbook projectable structure.

Option B changes how partitions are registered but still registers them. The GetPartitions call at query time is unaffected, so the multi-minute planning delay remains, and the maintenance job is still there, just written differently.

Option C has the same limitation and adds cost. A crawler run every hour over a prefix with 1.5 million partitions is itself expensive and slow, and the catalog is still queried at plan time.

Option D is a real feature that genuinely speeds up GetPartitions filtering, so it is the strongest distractor. But it only makes the lookup faster; the call still happens, and partition indexes do nothing about having to register new partitions each day. Projection is the option that eliminates both problems rather than trimming one.

Reference: Use partition projection with Amazon Athena