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.