Error handling and retries in DynamoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output when a conditional write fails due to a condition check?

Consider the following DynamoDB operation using the AWS SDK:

const params = {
  TableName: 'Users',
  Key: { 'UserId': '123' },
  UpdateExpression: 'SET Age = :newAge',
  ConditionExpression: 'Age = :oldAge',
  ExpressionAttributeValues: {
    ':newAge': 30,
    ':oldAge': 25
  }
};

try {
  await dynamodb.update(params).promise();
  console.log('Update succeeded');
} catch (err) {
  console.log('Update failed:', err.code);
}

If the current Age of user 123 is 28, what will be printed?

A Update failed: ValidationException

B Update succeeded

C Update failed: ConditionalCheckFailedException

D Update failed: ResourceNotFoundException

💡 Hint

Think about what happens when the condition in ConditionExpression is not met.

The update will fail because the condition 'Age = :oldAge' is false (28 != 25). DynamoDB throws a ConditionalCheckFailedException in this case.

❓ query_result

intermediate

What happens when a DynamoDB request exceeds provisioned throughput?

When a DynamoDB query exceeds the provisioned throughput limits, what error code is returned by the service?

A ResourceInUseException

B ThrottlingException

C LimitExceededException

D ProvisionedThroughputExceededException

💡 Hint

Look for the specific error related to throughput limits in DynamoDB.

DynamoDB returns ProvisionedThroughputExceededException when the request rate is too high for the provisioned capacity.

📝 Syntax

advanced

Which retry strategy code snippet correctly retries a DynamoDB operation on throughput errors?

Given the following retry logic, which option correctly implements exponential backoff with jitter for retrying a DynamoDB operation?

DynamoDB

async function retryOperation(operation, maxRetries) {
  let retries = 0;
  while (retries < maxRetries) {
    try {
      return await operation();
    } catch (err) {
      if (err.code === 'ProvisionedThroughputExceededException') {
        const delay = Math.pow(2, retries) * 100 + Math.random() * 100;
        await new Promise(res => setTimeout(res, delay));
        retries++;
      } else {
        throw err;
      }
    }
  }
  throw new Error('Max retries reached');
}

A The code retries only once and does not handle jitter.

B The code correctly implements exponential backoff with jitter and retries on throughput errors.

C The code retries immediately without delay, causing rapid retries.

D The code retries on all errors, not just throughput errors.

💡 Hint

Check if the delay increases exponentially and includes randomness.

The code uses 2^retries * 100 ms plus a random 0-100 ms delay, which is exponential backoff with jitter. It retries only on ProvisionedThroughputExceededException.

🔧 Debug

advanced

Why does this DynamoDB retry loop never stop?

Consider this retry loop for a DynamoDB operation:

let retries = 0;
while (retries < 5) {
  try {
    await dynamodb.putItem(params).promise();
    break;
  } catch (err) {
    if (err.code === 'ProvisionedThroughputExceededException') {
      retries++;
    }
  }
}

Why might this loop never exit even after 5 retries?

A Because there is no delay between retries, causing immediate repeated failures.

B Because the retries counter is never incremented.

C Because the break statement is outside the try block.

D Because the error code is misspelled and never matches.

💡 Hint

Think about what happens if retries happen too fast.

Without delay, retries happen immediately, causing the same error repeatedly without giving DynamoDB time to recover, so the loop may appear stuck.

🧠 Conceptual

expert

What is the best practice for handling idempotency in DynamoDB retries?

When retrying write operations in DynamoDB due to transient errors, what is the recommended approach to ensure idempotency and avoid duplicate writes?

A Use a unique client-generated idempotency token as a condition attribute to prevent duplicate writes.

B Retry blindly without any checks because DynamoDB automatically prevents duplicates.

C Delete the item before retrying the write operation.

D Use a random delay before each retry to reduce duplicates.

💡 Hint

Think about how to uniquely identify each write attempt.

Using a unique idempotency token in a condition expression ensures that retries do not create duplicate items or overwrite unintended data.

Practice

1. What is the main purpose of using retries in DynamoDB error handling?

easy

A. To ignore all errors and continue processing

B. To permanently stop the operation when an error occurs

C. To automatically try the operation again after a temporary failure

D. To delete the data causing the error

Solution

1. Step 1: Understand retries in DynamoDB

   Retries are used to handle temporary errors like throttling by trying the operation again.

2. Step 2: Identify the purpose of retries

   Retries help keep the app stable by not failing immediately on temporary issues.

3. Final Answer:

   To automatically try the operation again after a temporary failure -> Option C

4. Quick Check:

   Retries = automatic retry after temporary failure [OK]

Hint: Retries mean trying again after temporary errors [OK]

Common Mistakes:

• Thinking retries stop all errors permanently
• Ignoring the need to check error types before retrying
• Assuming retries delete data

2. Which of the following is the correct way to catch a throttling exception in DynamoDB using Python?

easy

A. try:
# operation
except ThrottlingException:
# retry logic

B. try:
# operation
except Exception:
pass

C. if error == 'ThrottlingException':
retry()

D. catch ThrottlingException {
retry();
}

Solution

1. Step 1: Identify Python error handling syntax

   Python uses try-except blocks to catch exceptions, with except specifying the exception type.

2. Step 2: Match correct exception handling for throttling

   try: # operation except ThrottlingException: # retry logic correctly uses try-except with ThrottlingException to handle retries.

3. Final Answer:

   try: # operation except ThrottlingException: # retry logic -> Option A

4. Quick Check:

   Python try-except with specific exception = try: # operation except ThrottlingException: # retry logic [OK]

Hint: Python uses try-except to catch specific exceptions [OK]

Common Mistakes:

• Using incorrect syntax like catch instead of except
• Catching all exceptions without handling specific ones
• Using if statement instead of try-except for exceptions

3. Given this Python code snippet for DynamoDB, what will be the output if a throttling error occurs on the first attempt?

import boto3
from botocore.exceptions import ClientError

client = boto3.client('dynamodb')

try:
    response = client.put_item(TableName='MyTable', Item={'id': {'S': '123'}})
    print('Success')
except ClientError as e:
    if e.response['Error']['Code'] == 'ThrottlingException':
        print('Retrying...')
    else:
        print('Failed')

medium

A. Success

B. Retrying...

C. Failed

D. No output

Solution

1. Step 1: Understand the try-except block behavior

   If a ClientError occurs, the code checks the error code inside the except block.

2. Step 2: Check error code for throttling

   If the error code is 'ThrottlingException', it prints 'Retrying...'. Otherwise, it prints 'Failed'.

3. Final Answer:

   Retrying... -> Option B

4. Quick Check:

   Error code 'ThrottlingException' triggers 'Retrying...' [OK]

Hint: Check error code in except to decide output [OK]

Common Mistakes:

• Assuming success despite error
• Ignoring error code check and printing 'Failed'
• Expecting no output on error

4. Identify the error in this retry logic snippet for DynamoDB in Python:

try:
    response = client.get_item(TableName='MyTable', Key={'id': {'S': '123'}})
except ClientError as e:
    if e.response['Error']['Code'] == 'ThrottlingException':
        client.get_item(TableName='MyTable', Key={'id': {'S': '123'}})
    else:
        raise e

medium

A. No error, code retries correctly

B. Should not raise exception in else block

C. Error code check is incorrect

D. Retry call is not inside a try-except block

Solution

1. Step 1: Analyze retry call placement

   The retry call is made without a try-except block, so if it fails again, it will raise an unhandled exception.

2. Step 2: Understand proper retry handling

   Retries should be wrapped in try-except to handle repeated failures gracefully.

3. Final Answer:

   Retry call is not inside a try-except block -> Option D

4. Quick Check:

   Retry without try-except risks unhandled errors [OK]

Hint: Always wrap retries in try-except to catch repeated errors [OK]

Common Mistakes:

• Not wrapping retry calls in error handling
• Mischecking error codes
• Avoiding raising exceptions on unknown errors

5. You want to implement a retry mechanism for DynamoDB writes that retries up to 3 times with exponential backoff when a throttling error occurs. Which approach correctly combines error handling and retries?

hard

A. Use a loop with try-except catching throttling errors, sleep doubling wait time each retry, stop after 3 attempts

B. Call put_item once, then retry infinitely without delay on any error

C. Ignore errors and assume writes always succeed

D. Use try-except but do not check error codes before retrying

Solution

1. Step 1: Understand retry with exponential backoff

   Retries should be limited in number and wait time should increase to reduce load.

2. Step 2: Combine error handling and retry logic

   Use a loop with try-except to catch throttling errors, sleep with increasing delay, and stop after max retries.

3. Final Answer:

   Use a loop with try-except catching throttling errors, sleep doubling wait time each retry, stop after 3 attempts -> Option A

4. Quick Check:

   Retry loop + exponential backoff + error check = Use a loop with try-except catching throttling errors, sleep doubling wait time each retry, stop after 3 attempts [OK]

Hint: Retry with limited attempts and increasing delay on throttling [OK]

Common Mistakes:

• Retrying infinitely without delay
• Not checking error codes before retrying
• Ignoring errors completely