Table creation with AWS SDK in DynamoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Creating a DynamoDB table with correct key schema

Which option correctly creates a DynamoDB table named Users with a primary key UserId of type string using AWS SDK for JavaScript v3?

A const params = { TableName: 'Users', KeySchema: [{ AttributeName: 'UserId', KeyType: 'HASH' }], AttributeDefinitions: [{ AttributeName: 'UserId', AttributeType: 'B' }], BillingMode: 'PROVISIONED' };

B const params = { TableName: 'Users', KeySchema: [{ AttributeName: 'UserId', KeyType: 'RANGE' }], AttributeDefinitions: [{ AttributeName: 'UserId', AttributeType: 'S' }], BillingMode: 'PAY_PER_REQUEST' };

C const params = { TableName: 'Users', KeySchema: [{ AttributeName: 'UserId', KeyType: 'HASH' }], AttributeDefinitions: [{ AttributeName: 'UserId', AttributeType: 'N' }], BillingMode: 'PAY_PER_REQUEST' };

D const params = { TableName: 'Users', KeySchema: [{ AttributeName: 'UserId', KeyType: 'HASH' }], AttributeDefinitions: [{ AttributeName: 'UserId', AttributeType: 'S' }], BillingMode: 'PAY_PER_REQUEST' };

💡 Hint

Remember the primary key must be of type string and use 'HASH' as KeyType for partition key.

Option D correctly defines the primary key UserId as a string attribute with KeyType 'HASH'. Option D uses 'RANGE' which is for sort keys, not primary partition key. Option D wrongly sets attribute type to number. Option D uses binary type and PROVISIONED billing which is not required here.

❓ service_behavior

intermediate

Understanding billing mode impact on DynamoDB table

What is the main difference in behavior between PAY_PER_REQUEST and PROVISIONED billing modes when creating a DynamoDB table?

A PAY_PER_REQUEST charges based on actual read/write requests; PROVISIONED requires specifying capacity units upfront.

B PAY_PER_REQUEST requires specifying capacity units upfront; PROVISIONED charges based on actual usage.

C Both modes require specifying capacity units but differ in cost per unit.

D PROVISIONED mode automatically scales capacity based on traffic; PAY_PER_REQUEST does not.

💡 Hint

Think about how you pay for the table usage in each mode.

PAY_PER_REQUEST charges you only for the reads and writes you actually perform, so no need to set capacity. PROVISIONED requires you to set how many reads and writes per second you expect, paying for that capacity whether you use it or not.

❓ Architecture

advanced

Designing a DynamoDB table with composite primary key

You want to create a DynamoDB table named Orders where each order is uniquely identified by OrderId and CustomerId. Which option correctly defines the key schema for this composite primary key?

A KeySchema: [{ AttributeName: 'OrderId', KeyType: 'HASH' }, { AttributeName: 'CustomerId', KeyType: 'RANGE' }], AttributeDefinitions: [{ AttributeName: 'OrderId', AttributeType: 'S' }, { AttributeName: 'CustomerId', AttributeType: 'S' }]

B KeySchema: [{ AttributeName: 'CustomerId', KeyType: 'HASH' }, { AttributeName: 'OrderId', KeyType: 'RANGE' }], AttributeDefinitions: [{ AttributeName: 'OrderId', AttributeType: 'S' }, { AttributeName: 'CustomerId', AttributeType: 'S' }]

C KeySchema: [{ AttributeName: 'OrderId', KeyType: 'RANGE' }, { AttributeName: 'CustomerId', KeyType: 'HASH' }], AttributeDefinitions: [{ AttributeName: 'OrderId', AttributeType: 'S' }, { AttributeName: 'CustomerId', AttributeType: 'S' }]

D KeySchema: [{ AttributeName: 'OrderId', KeyType: 'HASH' }, { AttributeName: 'CustomerId', KeyType: 'HASH' }], AttributeDefinitions: [{ AttributeName: 'OrderId', AttributeType: 'S' }, { AttributeName: 'CustomerId', AttributeType: 'S' }]

💡 Hint

The partition key is HASH and the sort key is RANGE in a composite key.

Option A correctly sets OrderId as the partition key (HASH) and CustomerId as the sort key (RANGE). Option A reverses the keys but could be valid depending on design but here the question specifies unique by OrderId and CustomerId with OrderId first. Option A swaps HASH and RANGE incorrectly. Option A uses two HASH keys which is invalid.

❓ security

advanced

IAM policy for creating DynamoDB tables

Which IAM policy statement correctly allows a user to create DynamoDB tables but restricts deleting tables?

A {"Effect": "Deny", "Action": ["dynamodb:DeleteTable"], "Resource": "*"}

B {"Effect": "Allow", "Action": ["dynamodb:CreateTable"], "Resource": "*"}

C {"Effect": "Allow", "Action": ["dynamodb:CreateTable", "dynamodb:DeleteTable"], "Resource": "*"}

D {"Effect": "Allow", "Action": ["dynamodb:*"], "Resource": "*"}

💡 Hint

Allow only the create action and do not include delete.

Option B allows only the CreateTable action. Option B allows both create and delete, which is not restrictive. Option B denies delete but does not explicitly allow create, so user may not have create permission. Option B allows all DynamoDB actions, including delete.

✅ Best Practice

expert

Choosing partition key for high throughput DynamoDB table

You expect a DynamoDB table to receive thousands of requests per second. Which partition key design best supports even data distribution and avoids hot partitions?

A Use a single attribute with low cardinality, like a boolean flag, as the partition key.

B Use a monotonically increasing number as the partition key.

C Use a composite key combining a high-cardinality attribute and a timestamp prefix as partition key.

D Use a fixed string value as the partition key for all items.

💡 Hint

Think about how to spread requests evenly across partitions.

Option C combines a high-cardinality attribute with a timestamp prefix, which helps distribute writes evenly and avoid hot partitions. Option C has low cardinality causing hot spots. Option C with increasing numbers causes sequential writes to one partition. Option C uses a fixed value, causing all writes to one partition, creating a hot partition.

Practice

1. What is the main purpose of specifying a primary key when creating a DynamoDB table using the AWS SDK?

easy

A. To set the table's read and write capacity

B. To specify the table's encryption settings

C. To define the table's region

D. To uniquely identify each item in the table

Solution

1. Step 1: Understand the role of a primary key in DynamoDB

   The primary key uniquely identifies each item in the table, ensuring no duplicates.

2. Step 2: Differentiate from other table settings

   Read/write capacity, region, and encryption are important but unrelated to item uniqueness.

3. Final Answer:

   To uniquely identify each item in the table -> Option D

4. Quick Check:

   Primary key = unique item ID [OK]

Hint: Primary key means unique ID for each item [OK]

Common Mistakes:

• Confusing primary key with capacity settings
• Thinking primary key sets region or encryption
• Ignoring the uniqueness requirement

2. Which of the following is the correct way to specify the primary key attribute when creating a DynamoDB table using AWS SDK for JavaScript?

easy

A. "KeySchema": [{ "AttributeName": "UserId", "KeyType": "HASH" }]

B. "KeySchema": [{ "AttributeName": "UserId", "KeyType": "PRIMARY" }]

C. "KeySchema": [{ "AttributeName": "UserId", "KeyType": "PRIMARY_KEY" }]

D. "KeySchema": [{ "AttributeName": "UserId", "KeyType": "KEY" }]

Solution

1. Step 1: Recall AWS SDK syntax for KeySchema

   The correct key type for the partition key is "HASH" in the KeySchema array.

2. Step 2: Identify incorrect key types

   "PRIMARY", "PRIMARY_KEY", and "KEY" are not valid KeyType values in AWS SDK.

3. Final Answer:

   "KeySchema": [{ "AttributeName": "UserId", "KeyType": "HASH" }] -> Option A

4. Quick Check:

   KeyType for partition key = HASH [OK]

Hint: Use "HASH" for partition key in KeySchema [OK]

Common Mistakes:

• Using invalid KeyType values like PRIMARY or KEY
• Confusing KeyType with attribute types
• Missing the array structure for KeySchema

3. Given the following AWS SDK code snippet for creating a DynamoDB table, what will be the output if the table creation is successful?

const params = {
  TableName: "Products",
  KeySchema: [
    { AttributeName: "ProductId", KeyType: "HASH" }
  ],
  AttributeDefinitions: [
    { AttributeName: "ProductId", AttributeType: "S" }
  ],
  ProvisionedThroughput: {
    ReadCapacityUnits: 5,
    WriteCapacityUnits: 5
  }
};

const result = await dynamodb.createTable(params).promise();
console.log(result.TableDescription.TableName);

medium

A. Products

B. Table creation failed

C. undefined

D. Error: Missing KeySchema

Solution

1. Step 1: Understand the createTable response structure

   On success, createTable returns an object with TableDescription including TableName.

2. Step 2: Check the console.log statement

   It prints result.TableDescription.TableName, which is "Products" as specified.

3. Final Answer:

   Products -> Option A

4. Quick Check:

   Successful createTable logs table name [OK]

Hint: Successful createTable returns TableDescription with TableName [OK]

Common Mistakes:

• Expecting error messages on success
• Confusing undefined with valid output
• Missing await causing promise object logging

4. You try to create a DynamoDB table with the following parameters but get an error. What is the most likely cause?

const params = {
  TableName: "Orders",
  KeySchema: [
    { AttributeName: "OrderId", KeyType: "HASH" },
    { AttributeName: "OrderDate", KeyType: "RANGE" }
  ],
  AttributeDefinitions: [
    { AttributeName: "OrderId", AttributeType: "S" }
  ],
  ProvisionedThroughput: {
    ReadCapacityUnits: 10,
    WriteCapacityUnits: 10
  }
};

await dynamodb.createTable(params).promise();

medium

A. TableName is invalid

B. Missing AttributeDefinition for "OrderDate"

C. ProvisionedThroughput values are too high

D. KeyType "RANGE" is not allowed

Solution

1. Step 1: Check KeySchema and AttributeDefinitions consistency

   Both "OrderId" and "OrderDate" are in KeySchema, but only "OrderId" is defined in AttributeDefinitions.

2. Step 2: Identify missing attribute definition

   "OrderDate" must be defined in AttributeDefinitions to avoid error.

3. Final Answer:

   Missing AttributeDefinition for "OrderDate" -> Option B

4. Quick Check:

   All key attributes need AttributeDefinitions [OK]

Hint: Define all key attributes in AttributeDefinitions [OK]

Common Mistakes:

• Forgetting to define all key attributes
• Assuming RANGE is invalid KeyType
• Blaming ProvisionedThroughput or TableName

5. You want to create a DynamoDB table named "Employees" with a composite primary key consisting of "EmployeeId" (string) as the partition key and "Department" (string) as the sort key. You also want to set the read capacity to 3 and write capacity to 2. Which of the following AWS SDK parameter objects correctly creates this table?

hard

A. { TableName: "Employees", KeySchema: [{ AttributeName: "EmployeeId", KeyType: "HASH" }], AttributeDefinitions: [{ AttributeName: "EmployeeId", AttributeType: "S" }, { AttributeName: "Department", AttributeType: "S" }], ProvisionedThroughput: { ReadCapacityUnits: 3, WriteCapacityUnits: 2 } }

B. { TableName: "Employees", KeySchema: [{ AttributeName: "EmployeeId", KeyType: "RANGE" }, { AttributeName: "Department", KeyType: "HASH" }], AttributeDefinitions: [{ AttributeName: "EmployeeId", AttributeType: "S" }, { AttributeName: "Department", AttributeType: "S" }], ProvisionedThroughput: { ReadCapacityUnits: 3, WriteCapacityUnits: 2 } }

C. { TableName: "Employees", KeySchema: [{ AttributeName: "EmployeeId", KeyType: "HASH" }, { AttributeName: "Department", KeyType: "RANGE" }], AttributeDefinitions: [{ AttributeName: "EmployeeId", AttributeType: "S" }, { AttributeName: "Department", AttributeType: "S" }], ProvisionedThroughput: { ReadCapacityUnits: 3, WriteCapacityUnits: 2 } }

D. { TableName: "Employees", KeySchema: [{ AttributeName: "EmployeeId", KeyType: "HASH" }, { AttributeName: "Department", KeyType: "RANGE" }], AttributeDefinitions: [{ AttributeName: "EmployeeId", AttributeType: "N" }, { AttributeName: "Department", AttributeType: "S" }], ProvisionedThroughput: { ReadCapacityUnits: 3, WriteCapacityUnits: 2 } }

Solution

1. Step 1: Verify KeySchema order and types

   Partition key must have KeyType "HASH" and sort key "RANGE" in correct order: EmployeeId (HASH), Department (RANGE).

2. Step 2: Check AttributeDefinitions types

   Both EmployeeId and Department are strings, so AttributeType "S" is correct for both.

3. Step 3: Confirm ProvisionedThroughput values

   ReadCapacityUnits: 3 and WriteCapacityUnits: 2 match the requirement.

4. Final Answer:

   { TableName: "Employees", KeySchema: [{ AttributeName: "EmployeeId", KeyType: "HASH" }, { AttributeName: "Department", KeyType: "RANGE" }], AttributeDefinitions: [{ AttributeName: "EmployeeId", AttributeType: "S" }, { AttributeName: "Department", AttributeType: "S" }], ProvisionedThroughput: { ReadCapacityUnits: 3, WriteCapacityUnits: 2 } } -> Option C

5. Quick Check:

   Correct key order and attribute types = { TableName: "Employees", KeySchema: [{ AttributeName: "EmployeeId", KeyType: "HASH" }, { AttributeName: "Department", KeyType: "RANGE" }], AttributeDefinitions: [{ AttributeName: "EmployeeId", AttributeType: "S" }, { AttributeName: "Department", AttributeType: "S" }], ProvisionedThroughput: { ReadCapacityUnits: 3, WriteCapacityUnits: 2 } } [OK]

Hint: Partition key = HASH, sort key = RANGE, types must match [OK]

Common Mistakes:

• Swapping HASH and RANGE key types
• Mismatching attribute types (string vs number)
• Omitting sort key in KeySchema