Transaction conditions in DynamoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the result of this DynamoDB transaction condition?

Consider a DynamoDB transaction that includes a ConditionCheck on a table Users with the condition attribute_exists(UserID). The transaction tries to update a user with UserID = '123'. What happens if the user does not exist?

DynamoDB

TransactWriteItems: [
  {
    ConditionCheck: {
      TableName: 'Users',
      Key: { UserID: '123' },
      ConditionExpression: 'attribute_exists(UserID)'
    }
  },
  {
    Update: {
      TableName: 'Users',
      Key: { UserID: '123' },
      UpdateExpression: 'SET Age = :newAge',
      ExpressionAttributeValues: { ':newAge': 30 }
    }
  }
]

A The transaction succeeds and creates a new user with UserID '123' and Age 30.

B The transaction fails with a ConditionalCheckFailedException because the user does not exist.

C The transaction ignores the condition and updates the user if it exists.

D The transaction partially succeeds by updating the user but skips the condition check.

💡 Hint

Think about what attribute_exists means in a condition check.

The ConditionCheck requires that the attribute UserID exists for the transaction to proceed. If the user does not exist, the condition fails and the entire transaction is aborted with a ConditionalCheckFailedException.

📝 Syntax

intermediate

Which option correctly uses a transaction condition to ensure an item attribute equals a value?

You want to update a DynamoDB item only if its Status attribute equals 'Pending'. Which transaction condition syntax is correct?

A ConditionExpression: "Status = 'Pending'"

B ConditionExpression: "attribute_not_exists(Status) OR Status = 'Pending'"

C ConditionExpression: "attribute_exists(Status) AND Status = :status", ExpressionAttributeValues: { ':status': 'Pending' }

D ConditionExpression: "Status == 'Pending'"

💡 Hint

Remember to use expression attribute values for string comparisons in DynamoDB conditions.

Option C correctly uses attribute_exists to ensure the attribute is present and compares Status to a placeholder :status with the value 'Pending'. Option C uses a literal string, which is acceptable for simple cases. Option C uses invalid syntax with double equals. Option C allows the condition to pass if the attribute does not exist, which is not desired.

❓ optimization

advanced

How to optimize a transaction condition to reduce read capacity usage?

You have a transaction that updates an item only if its Version attribute matches a given number. You want to minimize read capacity units consumed by the condition check. Which approach is best?

A Use a <code>ConditionExpression</code> in the <code>Update</code> operation with <code>Version = :v</code> to check atomically.

B Use a <code>ConditionCheck</code> with <code>Version = :v</code> in the transaction to verify before update.

C Perform a separate <code>GetItem</code> before the transaction to check the version, then run the transaction without conditions.

D Skip the condition and rely on eventual consistency to handle conflicts.

💡 Hint

Think about how DynamoDB transactions handle conditions inside update operations.

Option A is best because embedding the condition inside the Update operation allows DynamoDB to perform the check atomically without extra read operations, saving read capacity. Option A uses a separate ConditionCheck which adds overhead. Option A requires two calls and more capacity. Option A risks data conflicts.

🔧 Debug

advanced

Why does this DynamoDB transaction fail with a ConditionalCheckFailedException?

Given this transaction snippet:

TransactWriteItems: [
  {
    Update: {
      TableName: 'Orders',
      Key: { OrderID: 'A1' },
      UpdateExpression: 'SET Status = :newStatus',
      ConditionExpression: 'Status = :expectedStatus',
      ExpressionAttributeValues: {
        ':newStatus': 'Shipped',
        ':expectedStatus': 'Processing'
      }
    }
  }
]

The transaction fails with ConditionalCheckFailedException. What is the most likely reason?

A The current <code>Status</code> attribute value is not 'Processing', so the condition fails.

B The <code>ExpressionAttributeValues</code> are missing a required value for <code>:Status</code>.

C The <code>UpdateExpression</code> syntax is invalid and causes the failure.

D The <code>Key</code> does not match any item, so the update fails silently.

💡 Hint

Check the condition expression and the current item state.

The condition requires the Status attribute to be exactly 'Processing' before updating. If the current status is different (e.g., 'Pending' or 'Shipped'), the condition fails and the transaction aborts with ConditionalCheckFailedException. Option A is incorrect because all placeholders are provided. Option A is invalid because the update syntax is correct. Option A would cause a different error.

🧠 Conceptual

expert

What is the atomic behavior of DynamoDB transactions with multiple condition checks?

You have a DynamoDB transaction with multiple ConditionCheck operations on different items. What happens if one condition fails?

A The transaction partially commits all operations before the failed condition.

B DynamoDB retries the transaction automatically until all conditions pass.

C Only the failed condition check is skipped; other operations proceed.

D The entire transaction fails and none of the writes or updates are applied.

💡 Hint

Recall the atomicity guarantees of DynamoDB transactions.

DynamoDB transactions are atomic, meaning all operations succeed or none do. If any ConditionCheck fails, the entire transaction is aborted and no changes are applied. There is no partial commit or automatic retry by DynamoDB.

Practice

1. What is the main purpose of using ConditionCheck in a DynamoDB transaction?

easy

A. To ensure certain conditions are met before making changes to data

B. To speed up the transaction by skipping checks

C. To delete all items in a table

D. To create a backup of the database

Solution

1. Step 1: Understand ConditionCheck role

   ConditionCheck verifies if specified conditions are true before allowing a transaction to proceed.

2. Step 2: Recognize transaction safety

   If conditions fail, the transaction is aborted, preventing unwanted data changes.

3. Final Answer:

   To ensure certain conditions are met before making changes to data -> Option A

4. Quick Check:

   Transaction conditions = safety check [OK]

Hint: ConditionCheck = verify before change [OK]

Common Mistakes:

• Thinking ConditionCheck speeds up transactions
• Confusing ConditionCheck with data deletion
• Assuming ConditionCheck creates backups

2. Which of the following is the correct syntax snippet for a ConditionCheck in a DynamoDB transaction?

easy

A. "ConditionCheck": {"Key": {"Id": {"N": 123}}, "TableName": "MyTable", "ConditionExpression": "attribute_exists(Id)"}

B. "ConditionCheck": {"Key": {"Id": "123"}, "TableName": "MyTable", "ConditionExpression": "attribute_exists(Id)"}

C. "ConditionCheck": {"Key": {"Id": {"S": "123"}}, "TableName": "MyTable", "ConditionExpression": "attribute_exists(Id)"}

D. "ConditionCheck": {"Key": {"Id": {"S": 123}}, "TableName": "MyTable", "ConditionExpression": "attribute_exists(Id)"}

Solution

1. Step 1: Check key format for string type

   DynamoDB expects string values to be wrapped as {"S": "value"} in JSON.

2. Step 2: Validate ConditionExpression and TableName

   ConditionExpression uses attribute_exists correctly; TableName is properly specified.

3. Final Answer:

   "ConditionCheck": {"Key": {"Id": {"S": "123"}}, "TableName": "MyTable", "ConditionExpression": "attribute_exists(Id)"} -> Option C

4. Quick Check:

   Correct JSON key format = "ConditionCheck": {"Key": {"Id": {"S": "123"}}, "TableName": "MyTable", "ConditionExpression": "attribute_exists(Id)"} [OK]

Hint: Use {"S": "string"} for string keys in ConditionCheck [OK]

Common Mistakes:

• Omitting the type wrapper like {"S": ...}
• Using number type for string keys
• Passing raw values without quotes

3. Given this transaction snippet, what happens if the item with Id = '101' does not exist?

{
  "TransactItems": [
    {
      "ConditionCheck": {
        "TableName": "Orders",
        "Key": {"Id": {"S": "101"}},
        "ConditionExpression": "attribute_exists(Id)"
      }
    },
    {
      "Update": {
        "TableName": "Orders",
        "Key": {"Id": {"S": "101"}},
        "UpdateExpression": "SET Status = :s",
        "ExpressionAttributeValues": {":s": {"S": "Processed"}}
      }
    }
  ]
}

medium

A. The update runs anyway, creating a new item

B. The transaction partially updates the item

C. The transaction ignores the ConditionCheck and updates

D. The transaction fails and no update happens

Solution

1. Step 1: Understand ConditionCheck with attribute_exists

   The ConditionCheck requires the item with Id '101' to exist for the transaction to proceed.

2. Step 2: Analyze transaction behavior on condition failure

   If the item does not exist, the condition fails, so the entire transaction is aborted and no update occurs.

3. Final Answer:

   The transaction fails and no update happens -> Option D

4. Quick Check:

   Condition failure aborts transaction = The transaction fails and no update happens [OK]

Hint: ConditionCheck failure stops whole transaction [OK]

Common Mistakes:

• Assuming update creates new item on failure
• Thinking transaction partially applies changes
• Ignoring ConditionCheck effect

4. You wrote this transaction but it always fails with a validation error:

{
  "TransactItems": [
    {
      "ConditionCheck": {
        "TableName": "Users",
        "Key": {"UserId": {"N": "abc"}},
        "ConditionExpression": "attribute_exists(UserId)"
      }
    }
  ]
}

What is the most likely cause?

medium

A. ConditionExpression syntax is wrong

B. The key type is incorrect; 'abc' is not a number

C. TableName is misspelled

D. ConditionCheck cannot be used alone

Solution

1. Step 1: Check key type and value

   The key uses type "N" (number) but the value "abc" is not numeric, causing validation error.

2. Step 2: Confirm other parts are correct

   ConditionExpression and TableName syntax are valid; ConditionCheck can be used alone.

3. Final Answer:

   The key type is incorrect; 'abc' is not a number -> Option B

4. Quick Check:

   Key type must match value format [OK]

Hint: Match key type with value format [OK]

Common Mistakes:

• Using non-numeric string with number type
• Assuming ConditionExpression syntax error
• Thinking ConditionCheck needs other actions

5. You want to update a user's email only if their current email is exactly '[e-mail]'. Which transaction condition setup achieves this safely?

hard

A. Use a ConditionCheck with ConditionExpression 'Email = :oldEmail' before the update

B. Use an Update with ConditionExpression 'attribute_exists(Email)'

C. Use a ConditionCheck with ConditionExpression 'attribute_not_exists(Email)'

D. Update without any condition; trust the data is correct

Solution

1. Step 1: Identify condition to match exact current email

   The condition must check that Email equals '[e-mail]' before updating.

2. Step 2: Use ConditionCheck to verify before update

   ConditionCheck with 'Email = :oldEmail' ensures update only happens if current email matches.

3. Final Answer:

   Use a ConditionCheck with ConditionExpression 'Email = :oldEmail' before the update -> Option A

4. Quick Check:

   Exact match condition before update = Use a ConditionCheck with ConditionExpression 'Email = :oldEmail' before the update [OK]

Hint: Check exact value with ConditionCheck before update [OK]

Common Mistakes:

• Using attribute_exists instead of exact match
• Checking attribute_not_exists which is opposite
• Skipping condition and risking wrong update