Why D? And why not the others?

Correct answer: D. Neither index type applies retroactively; a local secondary index must be defined at table creation time, so a strongly consistent alternate-sort-key query on an existing table cannot be added this way

Local secondary indexes are the only DynamoDB index type that can be read with strong consistency, but they share the base table's partition key and, critically, must be specified when the table is created; DynamoDB provides no way to add a local secondary index to a table that already exists, so a one-year-old production table can never gain one no matter how the requirement is phrased. Global secondary indexes can be added at any time and are useful for different partition or sort key combinations, but they only ever support eventually consistent reads, so they cannot satisfy the strong-consistency requirement even though they can be added later. The option describing a global secondary index because it supports strong consistency is wrong on the facts: global secondary indexes never support strongly consistent reads, only local secondary indexes do. The option describing a local secondary index created before any items are written is wrong because the constraint is about table creation time, not about whether items already exist; even an empty table cannot have a local secondary index added after its initial creation. The option describing a global secondary index because it can be added later with separate throughput is accurate about its mechanics but still wrong for this scenario because it ignores the explicit strong-consistency requirement.

Source: AWS DynamoDB documentation: general guidelines for secondary indexes (global vs. local)