GSI & LSI Interview Questions

It lets you Query on an attribute that is not the table’s primary key—email, status+date, orderId—without scanning. The GSI has its own partition and sort keys and its own capacity. If every access path already fits the base key, you do not need a GSI.

An LSI shares the table’s partition key and offers an alternate sort key, and it is strongly consistent with the base item collection. You must create LSIs at table creation, and they count toward item-collection size. GSIs can use a different partition key and can be added later.

KEYS_ONLY stores table and index keys; INCLUDE adds named attributes; ALL copies the whole item. Fatter projections cost more writes and storage. Fetch missing attributes with a follow-up Get only when that extra read is rarer than the write amplification of ALL.

Every base-table write that touches GSI keys is projected into the index, consuming GSI WCUs independently. A hot GSI throttles even if the table has spare capacity. On-demand tables still isolate that pressure per index, so you watch GSI metrics separately.

Only if that same value is also the GSI’s partition key. Otherwise you Query the index key you defined. Treating a GSI like a SQL covering index on arbitrary columns is the usual beginner mistake.

DynamoDB removes the item from the old index key and writes it under the new one. That is two index writes, so capacity and streams-style side effects can surprise you. Missing the new key attribute drops the item from the GSI entirely.

Sparse indexes omit items that lack the GSI key attributes. A null or removed email means no GSI row. That is useful for “pending” subsets; it is a bug if you expected every user to be searchable by email.

When the index is only a lookup to the base keys and you will GetItem for the payload, or when the item is large and rarely needed on that path. INCLUDE is the usual compromise for a few display fields. ALL is convenient and often the most expensive default.

Only items that set GSI PK/SK are projected, so a “needsReview=true” attribute can be the index key. Clearing it removes the item from the index without a Scan. Sparse GSIs stay small and cheap when the subset is rare.

GSI reads are eventually consistent; a Query right after a write can miss the new projection. Strongly consistent reads are for the base table (and LSIs). UX that requires read-your-writes should read the table key, not the GSI, or tolerate a brief lag.

Each projected index multiplies WCUs on every write that touches its keys. Five ALL-projection GSIs can dominate cost and latency. Audit unused indexes, shrink projections, and drop GSIs whose Query volume does not justify the write tax.

One physical GSI holds many logical access patterns by writing different typed values into the same two attributes. It saves index quota and cost versus one GSI per query. The team must document which entity types occupy GSI1 or Query results become mixed garbage.

When you need a strongly consistent alternate sort order on the same partition key and you can declare it at table creation. LSIs also avoid GSI replication lag. If you need a different partition key or must add the index later, you want a GSI.

Use ExclusiveStartKey from LastEvaluatedKey and do not invent your own offset. Pages are not stable if the index is taking writes; document that. A Limit is a max of evaluated items, not a SQL OFFSET, so filtered queries may return short pages.

Create the index and let DynamoDB backfill; watch OnlineIndexPercentageProgress and GSI throttles. Backfill consumes capacity—use on-demand or raise provisioned headroom first. Do not point production traffic at the GSI until the index status is ACTIVE and lag looks healthy.

Successful table writes with ProvisionedThroughputExceededException on the index, or GSI consumed WCUs pegged while table WCUs are not. Celebrity GSI keys (status=NEW) are a classic cause. Shard the index key or stop using a low-cardinality GSI PK.

GSI PK=email, SK=userId (or the table PK), projection KEYS_ONLY or INCLUDE of display fields. Enforce email uniqueness with a transaction or a condition that the GSI key is not already taken—DynamoDB will not do SQL UNIQUE for you. Handle email changes as a GSI key update.

Default quotas cap GSIs per table (commonly 20) and LSIs (5) and you cannot add LSIs after create. Designs that need a GSI per report will run out. Overloaded GSIs and sparse indexes are how mature schemas stay inside the quota.

Create a new GSI with the right keys and projection, dual-read until ACTIVE, switch queries, then delete the old index. Deleting first drops the access path. Watch write amplification while both indexes exist; that window should be short.

Transactional writes still project to GSIs and can fail if the index is throttled or a condition on the transaction fails. GSI uniqueness is not transactional in the SQL sense. Design conditions on base-table items; do not assume the GSI is a locked unique constraint.