The table does not have the specified index

TL;DR — The IndexName in your Query/Scan doesn't exist on that table (from this client's region + account), is misspelled, or the GSI is still CREATING and not queryable yet. Confirm the exact index name and status with DescribeTable, then fix the call.

What it means

ValidationException: The table does not have the specified index: <IndexName>

# what the engine actually returns, reproduced against DynamoDB Local:
ValidationException: The table does not have the specified index: no-such-index

You asked DynamoDB to Query or Scan a specific secondary index by name, and the table (as this client sees it) has no index by that name in a usable state. It's an HTTP 400 ValidationException — client-side and not retryable until the name/status is right.

Why it happens

• Typo or wrong case — index names are case-sensitive; GSI1 ≠ gsi1.
• Index belongs to a different table — you copied the IndexName from another table's schema.
• The GSI isn't ACTIVE yet — a newly created global secondary index can't be queried until its status goes CREATING → ACTIVE (it backfills first).
• Wrong region/account — the client points at a region where the table (or its index) doesn't exist (the same lineup issue as a missing table).
• DynamoDB Local drift — a stale local shared-local-instance.db that predates the index; recreate it.

How to fix it

1. List the real index names and status:

   aws dynamodb describe-table --table-name <Table> \
     --query "Table.GlobalSecondaryIndexes[].{Name:IndexName,Status:IndexStatus}"

   CopyCopied
2. Copy the name verbatim into IndexName — match case exactly.
3. Wait for ACTIVE. If the GSI is CREATING, the query only works once backfill finishes (DescribeTable shows IndexStatus).
4. Confirm region + account with aws sts get-caller-identity and pin the client's region.
5. On DynamoDB Local, delete the local db file and re-run your table/index setup so the index exists locally.
6. Verify the key condition matches the index schema. A valid index name with a key condition on the wrong attributes still fails — but with a different error; rule out name/status first.

Working across several tables and indexes? DynoTable's Table dialog lists each table's GSIs and their status, so you can pick an index that actually exists — and is ACTIVE — instead of guessing the name. It also creates and drops a GSI when the index you needed is genuinely missing.

Query it in DynoTable

Open the table in DynoTable with ⌘K and expand the Indexes panel — every GSI name and IndexStatus is listed without a CLI call. Pick the index from the dropdown in the query panel instead of typing IndexName by hand; DynoTable only offers indexes that exist on the connected table.

If the GSI is still CREATING, refresh the table metadata from the sidebar until status flips to ACTIVE. Use the Query Builder to compose a GSI query and copy the generated IndexName into your SDK code. Switch profiles with ⌘P when the index exists in one Region but not another. Setup: Connect to AWS, Install.

Sources

• Managing Global Secondary Indexes in DynamoDB (verified 2026-07-13)
• Query — Amazon DynamoDB API Reference (verified 2026-07-13)

Related errors

• ResourceNotFoundException — the whole table (not just an index) can't be found.
• Query key condition not supported — the index exists but your key condition is wrong for it.
• Code example: Query a GSI in Node.js — IndexName wired correctly.
• Learn: GSI vs LSI · GSIs are eventually consistent · Indexes overview

References

• Managing Global Secondary Indexes in DynamoDB — Amazon DynamoDB Developer Guide
• Query — Amazon DynamoDB API Reference
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide

Last verified 2026-07-13 against the official AWS documentation linked above.