Composite primary key in DynamoDB - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a composite primary key with partition key 'UserId'.

DynamoDB

KeySchema: [{ AttributeName: 'UserId', KeyType: '[1]' }]

Drag options to blanks, or click blank then click option'

APRIMARY

BRANGE

CHASH

DINDEX

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'RANGE' instead of 'HASH' for the partition key.

Using 'PRIMARY' or 'INDEX' which are not valid KeyType values.

The partition key in DynamoDB is defined with KeyType 'HASH'.

2fill in blank

medium

Complete the code to add a sort key named 'OrderId' in the composite primary key.

DynamoDB

KeySchema: [
  { AttributeName: 'UserId', KeyType: 'HASH' },
  { AttributeName: 'OrderId', KeyType: '[1]' }
]

Drag options to blanks, or click blank then click option'

APRIMARY

BINDEX

CHASH

DRANGE

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'HASH' instead of 'RANGE' for the sort key.

Using 'PRIMARY' or 'INDEX' which are not valid KeyType values.

The sort key in DynamoDB is defined with KeyType 'RANGE'.

3fill in blank

hard

Fix the error in the attribute definitions for the composite primary key.

DynamoDB

AttributeDefinitions: [
  { AttributeName: 'UserId', AttributeType: '[1]' },
  { AttributeName: 'OrderId', AttributeType: 'S' }
]

Drag options to blanks, or click blank then click option'

AS

BBOOL

CB

DN

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'N' (number) when the attribute is a string.

Using 'BOOL' which is not valid for key attributes.

Both partition and sort keys must have a valid attribute type. 'S' means string type.

4fill in blank

hard

Fill both blanks to complete the table creation with composite primary key.

DynamoDB

CreateTable({
  TableName: 'Orders',
  KeySchema: [
    { AttributeName: '[1]', KeyType: 'HASH' },
    { AttributeName: '[2]', KeyType: 'RANGE' }
  ],
  AttributeDefinitions: [
    { AttributeName: 'UserId', AttributeType: 'S' },
    { AttributeName: 'OrderId', AttributeType: 'S' }
  ]
})

Drag options to blanks, or click blank then click option'

AUserId

BOrderDate

COrderId

DCustomerId

Attempts:

3 left

💡 Hint

Common Mistakes

Swapping partition and sort key names.

Using attribute names not defined in AttributeDefinitions.

The composite primary key uses 'UserId' as partition key and 'OrderId' as sort key.

5fill in blank

hard

Fill all three blanks to define a composite primary key and attribute types correctly.

DynamoDB

CreateTable({
  TableName: 'Purchases',
  KeySchema: [
    { AttributeName: '[1]', KeyType: 'HASH' },
    { AttributeName: '[2]', KeyType: 'RANGE' }
  ],
  AttributeDefinitions: [
    { AttributeName: '[1]', AttributeType: 'S' },
    { AttributeName: '[2]', AttributeType: 'N' }
  ]
})

Drag options to blanks, or click blank then click option'

ACustomerId

BPurchaseDate

COrderId

DUserId

Attempts:

3 left

💡 Hint

Common Mistakes

Mismatching attribute names between KeySchema and AttributeDefinitions.

Using wrong attribute types for keys.

The partition key is 'CustomerId' with type 'S' (string), and the sort key is 'PurchaseDate' with type 'N' (number).

Practice

1.

What is a composite primary key in DynamoDB?

easy

A. A key that allows duplicate items

B. A key made of only one attribute

C. A key made of two attributes: PartitionKey and SortKey

D. A key used only for indexing

Solution

1. Step 1: Understand primary key types in DynamoDB

   DynamoDB supports simple primary keys (one attribute) and composite primary keys (two attributes).

2. Step 2: Identify composite primary key components

   A composite primary key consists of a PartitionKey and a SortKey to uniquely identify items.

3. Final Answer:

   A key made of two attributes: PartitionKey and SortKey -> Option C

4. Quick Check:

   Composite primary key = PartitionKey + SortKey [OK]

Hint: Composite key always has PartitionKey and SortKey [OK]

Common Mistakes:

• Thinking composite key has only one attribute
• Confusing composite key with secondary indexes
• Believing composite key allows duplicates

2.

Which of the following is the correct way to define a composite primary key in DynamoDB table creation?

{
  "TableName": "Orders",
  "KeySchema": [
    {"AttributeName": "CustomerId", "KeyType": "HASH"},
    {"AttributeName": "OrderDate", "KeyType": "RANGE"}
  ]
}

easy

A. Use KeyType RANGE for both attributes

B. Use KeyType RANGE for PartitionKey and HASH for SortKey

C. Use KeyType HASH for both attributes

D. Use KeyType HASH for PartitionKey and RANGE for SortKey

Solution

1. Step 1: Recall KeyType meanings

   In DynamoDB, HASH means PartitionKey and RANGE means SortKey.

2. Step 2: Match KeyType to attributes

   PartitionKey must be HASH and SortKey must be RANGE for composite keys.

3. Final Answer:

   Use KeyType HASH for PartitionKey and RANGE for SortKey -> Option D

4. Quick Check:

   PartitionKey=HASH, SortKey=RANGE [OK]

Hint: HASH = PartitionKey, RANGE = SortKey in KeySchema [OK]

Common Mistakes:

• Swapping HASH and RANGE roles
• Using same KeyType for both keys
• Confusing attribute names with KeyType

3.

Given a DynamoDB table with composite primary key (UserId as PartitionKey, Timestamp as SortKey), what will this query return?

{
  "TableName": "UserActivity",
  "KeyConditionExpression": "UserId = :uid and Timestamp > :time",
  "ExpressionAttributeValues": {
    ":uid": {"S": "user123"},
    ":time": {"N": "1609459200"}
  }
}

medium

A. All activities of user123 with Timestamp greater than 1609459200

B. All activities of all users with Timestamp greater than 1609459200

C. All activities of user123 regardless of Timestamp

D. Syntax error due to missing SortKey in query

Solution

1. Step 1: Understand KeyConditionExpression

   It filters items by PartitionKey equality and SortKey condition.

2. Step 2: Analyze the query conditions

   UserId = :uid restricts to user123; Timestamp > :time filters timestamps after 1609459200.

3. Final Answer:

   All activities of user123 with Timestamp greater than 1609459200 -> Option A

4. Quick Check:

   PartitionKey + SortKey condition filters items [OK]

Hint: PartitionKey = value AND SortKey condition filters items [OK]

Common Mistakes:

• Thinking query returns all users' data
• Ignoring SortKey condition
• Assuming syntax error without SortKey equality

4.

What is wrong with this DynamoDB query using composite primary key (UserId as PartitionKey, OrderId as SortKey)?

{
  "TableName": "Orders",
  "KeyConditionExpression": "OrderId = :oid",
  "ExpressionAttributeValues": {
    ":oid": {"S": "order789"}
  }
}

medium

A. PartitionKey UserId is missing in KeyConditionExpression

B. SortKey OrderId cannot be used in KeyConditionExpression

C. ExpressionAttributeValues syntax is incorrect

D. TableName is invalid

Solution

1. Step 1: Recall query requirements for composite keys

   Queries must specify PartitionKey equality in KeyConditionExpression.

2. Step 2: Check the given query

   Only SortKey OrderId is used; PartitionKey UserId is missing, causing error.

3. Final Answer:

   PartitionKey UserId is missing in KeyConditionExpression -> Option A

4. Quick Check:

   PartitionKey must be in query condition [OK]

Hint: Always include PartitionKey equality in query [OK]

Common Mistakes:

• Using only SortKey in query condition
• Assuming SortKey alone can identify items
• Ignoring required PartitionKey in queries

5.

You want to store blog posts in DynamoDB. Each post has a AuthorId and a PostDate. You want to quickly find all posts by an author sorted by date. Which composite primary key design is best?

hard

A. PartitionKey: PostDate, SortKey: AuthorId

B. PartitionKey: AuthorId, SortKey: PostDate

C. PartitionKey: AuthorId only, no SortKey

D. PartitionKey: PostDate only, no SortKey

Solution

1. Step 1: Identify query pattern

   You want to find all posts by an author, sorted by date.

2. Step 2: Choose PartitionKey and SortKey accordingly

   PartitionKey should be AuthorId to group posts by author; SortKey should be PostDate to sort posts by date.

3. Final Answer:

   PartitionKey: AuthorId, SortKey: PostDate -> Option B

4. Quick Check:

   Group by author, sort by date = AuthorId + PostDate [OK]

Hint: PartitionKey groups, SortKey sorts related items [OK]

Common Mistakes:

• Swapping PartitionKey and SortKey roles
• Using only one key losing sorting ability
• Choosing SortKey that doesn't support query pattern