Creating GSI in DynamoDB - Quick Revision & Summary

Recall & Review

beginner

What is a Global Secondary Index (GSI) in DynamoDB?

A GSI is an index with a partition key and optional sort key that can be different from the base table's keys. It allows querying data efficiently using alternate keys.

beginner

Can a GSI have a different partition key than the main table?

Yes, a GSI can have a completely different partition key and sort key from the main table, enabling flexible queries.

intermediate

How do you create a GSI when creating a DynamoDB table?

You specify the GSI in the table creation request by defining its IndexName, KeySchema, Projection, and ProvisionedThroughput (if applicable).

intermediate

What is the purpose of the Projection attribute in a GSI?

Projection defines which attributes from the base table are copied into the GSI. It can be ALL, KEYS_ONLY, or INCLUDE specific attributes.

intermediate

Can you add a GSI to an existing DynamoDB table?

Yes, you can add a GSI to an existing table using the UpdateTable API, but it takes time to build and consumes throughput.

What does a Global Secondary Index allow you to do in DynamoDB?

A Encrypt data at rest

B Store data in a different AWS region

C Query data using alternate partition and sort keys

D Automatically backup your table

A GSI lets you query data efficiently using different partition and sort keys than the main table.

Which attribute defines what data is copied into a GSI?

A KeySchema

B Projection

C ProvisionedThroughput

D AttributeDefinitions

Projection specifies which attributes from the base table are included in the GSI.

Can a GSI have a sort key different from the main table?

A No

B Only for local secondary indexes

C Only if the table has no sort key

D Yes

A GSI can have a different partition key and sort key from the main table.

When adding a GSI to an existing table, what should you expect?

A Time to build and throughput consumption

B Table downtime

C Instant availability

D Automatic data deletion

Adding a GSI requires time to build and uses table throughput during creation.

Which of these is NOT a valid Projection type for a GSI?

A EXCLUDE

B KEYS_ONLY

C INCLUDE

D ALL

EXCLUDE is not a valid Projection type; valid types are ALL, KEYS_ONLY, and INCLUDE.

Explain what a Global Secondary Index is and why you would use one in DynamoDB.

Think about how you might want to find data using different keys than the main table.

Describe the steps and key parameters needed to create a GSI when creating a DynamoDB table.

Focus on the parts of the table creation request related to the GSI.

Practice

1. What is the main purpose of creating a Global Secondary Index (GSI) in DynamoDB?

easy

A. To automatically backup the table data

B. To increase the storage capacity of the table

C. To allow querying the table using alternative key attributes

D. To encrypt the table data at rest

Solution

1. Step 1: Understand what a GSI does

   A GSI lets you query a DynamoDB table using different key attributes than the primary key.

2. Step 2: Compare options to GSI purpose

   Options A, B, and D describe backup, storage, and encryption, which are unrelated to GSI functionality.

3. Final Answer:

   To allow querying the table using alternative key attributes -> Option C

4. Quick Check:

   GSI = alternative query keys [OK]

Hint: GSIs let you query by new keys without changing the table [OK]

Common Mistakes:

• Thinking GSI increases storage size
• Confusing GSI with backup or encryption features
• Assuming GSI changes the primary key

2. Which of the following is the correct syntax snippet to define a GSI named OrderDateIndex with OrderDate as the partition key in a DynamoDB table creation JSON?

easy

A. "GlobalSecondaryIndexes": [{"IndexName": "OrderDateIndex", "KeySchema": [{"AttributeName": "OrderDate", "KeyType": "HASH"}], "Projection": {"ProjectionType": "ALL"}}]

B. "GlobalSecondaryIndexes": [{"IndexName": "OrderDateIndex", "KeySchema": [{"AttributeName": "OrderDate", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"}}]

C. "GlobalSecondaryIndexes": [{"IndexName": "OrderDateIndex", "KeySchema": [{"AttributeName": "OrderDate", "KeyType": "PRIMARY"}], "Projection": {"ProjectionType": "ALL"}}]

D. "GlobalSecondaryIndexes": [{"IndexName": "OrderDateIndex", "KeySchema": [{"AttributeName": "OrderDate", "KeyType": "PARTITION"}], "Projection": {"ProjectionType": "ALL"}}]

Solution

1. Step 1: Identify correct KeyType for partition key in GSI

   The partition key in DynamoDB GSI uses KeyType "HASH".

2. Step 2: Check options for correct KeyType and syntax

   "GlobalSecondaryIndexes": [{"IndexName": "OrderDateIndex", "KeySchema": [{"AttributeName": "OrderDate", "KeyType": "HASH"}], "Projection": {"ProjectionType": "ALL"}}] uses "HASH" correctly; B uses "RANGE" (wrong for partition key), C uses invalid "PRIMARY", D uses invalid "PARTITION".

3. Final Answer:

   "GlobalSecondaryIndexes": [{"IndexName": "OrderDateIndex", "KeySchema": [{"AttributeName": "OrderDate", "KeyType": "HASH"}], "Projection": {"ProjectionType": "ALL"}}] -> Option A

4. Quick Check:

   Partition key = HASH [OK]

Hint: Partition key in GSI always uses KeyType 'HASH' [OK]

Common Mistakes:

• Using 'RANGE' instead of 'HASH' for partition key
• Using invalid KeyType values like 'PRIMARY' or 'PARTITION'
• Forgetting to define ProjectionType

3. Given a DynamoDB table with a GSI named UserEmailIndex where Email is the partition key, what will be the result of this query?

QueryInput = {
  TableName: "Users",
  IndexName: "UserEmailIndex",
  KeyConditionExpression: "Email = :email",
  ExpressionAttributeValues: {":email": "[e-mail]"}
}

medium

A. Returns all items where Email attribute equals '[e-mail]' using the GSI

B. Returns all items where Email attribute equals '[e-mail]' using the main table primary key

C. Returns an error because IndexName cannot be used in QueryInput

D. Returns all items regardless of Email attribute

Solution

1. Step 1: Understand QueryInput with IndexName

   Specifying IndexName in QueryInput tells DynamoDB to query the GSI instead of the main table.

2. Step 2: Analyze KeyConditionExpression

   The query filters items where Email equals '[e-mail]' on the GSI partition key.

3. Final Answer:

   Returns all items where Email attribute equals '[e-mail]' using the GSI -> Option A

4. Quick Check:

   Query with IndexName uses GSI keys [OK]

Hint: Use IndexName in query to search by GSI keys [OK]

Common Mistakes:

• Assuming query uses main table keys when IndexName is set
• Thinking IndexName causes error in QueryInput
• Ignoring KeyConditionExpression filtering

4. You tried to create a GSI with this snippet but got an error:

"GlobalSecondaryIndexes": [{
  "IndexName": "StatusIndex",
  "KeySchema": [{"AttributeName": "Status", "KeyType": "HASH"}],
  "Projection": {"ProjectionType": "INCLUDE", "NonKeyAttributes": []}
}]

What is the likely cause of the error?

medium

A. IndexName cannot contain the word 'Index'

B. NonKeyAttributes must be a non-empty array when ProjectionType is INCLUDE

C. KeyType must be RANGE for GSIs

D. ProjectionType cannot be INCLUDE for GSIs

Solution

1. Step 1: Check ProjectionType and NonKeyAttributes

   When ProjectionType is INCLUDE, NonKeyAttributes must be a non-empty array listing attributes to project.

2. Step 2: Verify given snippet

   NonKeyAttributes is [], which is empty and invalid when ProjectionType is INCLUDE.

3. Step 3: Eliminate other options

   ProjectionType INCLUDE is valid; KeyType HASH is valid for partition key; IndexName can contain 'Index'.

4. Final Answer:

   NonKeyAttributes must be a non-empty array when ProjectionType is INCLUDE -> Option B

5. Quick Check:

   INCLUDE projection requires NonKeyAttributes [OK]

Hint: INCLUDE projection needs NonKeyAttributes array [OK]

Common Mistakes:

• Using empty or missing NonKeyAttributes with INCLUDE
• Confusing KeyType HASH and RANGE for partition key
• Thinking IndexName naming causes errors

5. You have a DynamoDB table with primary key UserID. You want to query users by their City and SignupDate. Which GSI definition allows efficient queries for all users in a city sorted by signup date?

hard

A. "GlobalSecondaryIndexes": [{"IndexName": "CitySignupIndex", "KeySchema": [{"AttributeName": "SignupDate", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"}}]

B. "GlobalSecondaryIndexes": [{"IndexName": "CitySignupIndex", "KeySchema": [{"AttributeName": "SignupDate", "KeyType": "HASH"}, {"AttributeName": "City", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"}}]

C. "GlobalSecondaryIndexes": [{"IndexName": "CitySignupIndex", "KeySchema": [{"AttributeName": "City", "KeyType": "RANGE"}, {"AttributeName": "SignupDate", "KeyType": "HASH"}], "Projection": {"ProjectionType": "ALL"}}]

D. "GlobalSecondaryIndexes": [{"IndexName": "CitySignupIndex", "KeySchema": [{"AttributeName": "City", "KeyType": "HASH"}, {"AttributeName": "SignupDate", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"}}]

Solution

1. Step 1: Identify partition and sort keys for query pattern

   To query all users in a city sorted by signup date, City should be the partition key (HASH) and SignupDate the sort key (RANGE).

2. Step 2: Check options for correct KeySchema order

   "GlobalSecondaryIndexes": [{"IndexName": "CitySignupIndex", "KeySchema": [{"AttributeName": "City", "KeyType": "HASH"}, {"AttributeName": "SignupDate", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"}}] correctly sets City as HASH and SignupDate as RANGE. Options B and C swap keys incorrectly. "GlobalSecondaryIndexes": [{"IndexName": "CitySignupIndex", "KeySchema": [{"AttributeName": "SignupDate", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"}}] lacks partition key.

3. Final Answer:

   "GlobalSecondaryIndexes": [{"IndexName": "CitySignupIndex", "KeySchema": [{"AttributeName": "City", "KeyType": "HASH"}, {"AttributeName": "SignupDate", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"}}] -> Option D

4. Quick Check:

   Partition key = City, Sort key = SignupDate [OK]

Hint: Partition key first (HASH), sort key second (RANGE) in KeySchema [OK]

Common Mistakes:

• Swapping HASH and RANGE keys
• Missing partition key in GSI
• Using only one key when two are needed for sorting