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.