A company has an online order website that uses Amazon DynamoDB to store item inventory.

The goal is to reduce a given item’s price by 100 only when the resulting value would not fall below 500. That means the update should occur only when the current Price is at least 600 (because Price - 100 >= 500 ⇒ Price >= 600). The requirement also says to do this with the least number of calls to DynamoDB. The most efficient approach is to use a single UpdateItem call with a ConditionExpression so DynamoDB enforces the rule atomically.

Option B does exactly that: issue one UpdateItem request that updates Price = Price - :delta (using an update expression) while including a condition like Price >= :minPriceBeforeReduction (where :minPriceBeforeReduction is 600). If the condition is true, DynamoDB performs the update; if it’s false, DynamoDB rejects the write with ConditionalCheckFailedException. This avoids a separate read/query call and prevents race conditions where the price could change between a read and a subsequent write.

Option A requires two calls (Query then UpdateItem) and is vulnerable to time-of-check/time-of-use issues unless additional conditional logic is added to the update anyway. Option C adds an extra condition on category, but the requirement is “reduce all inventory prices” subject to the minimum resulting price; filtering by category is unnecessary and can cause eligible items in other categories to be skipped. Option D expresses the rule in a mathematical form; while conceptually correct, DynamoDB condition expressions do not generally support arbitrary arithmetic in the condition the same way as a simple comparison, so the standard implementation is to compare against 600 directly.

Therefore, B is the correct choice: one UpdateItem call with a condition expression Price >= 600 minimizes DynamoDB calls and enforces the pricing rule safely and atomically.