AZ-204 Develop for Azure storage Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Store the counter in Azure Cosmos DB and use stored procedures to increment atomically.

  Why this is correct

  Azure Cosmos DB stored procedures execute as a single, ACID-compliant transaction within a logical partition. When a stored procedure increments a counter, all operations within that procedure—reading the current value, incrementing it, and writing the new value—are guaranteed to either fully succeed or fully fail. This transactional boundary ensures that concurrent attempts to update the counter will not result in lost updates, making the increment operation truly atomic.

• ✗

  Use Azure Queue Storage to queue increment messages.

  Why it's wrong here

  Azure Queue Storage is primarily a messaging service designed for decoupling components and facilitating asynchronous communication. While it can store messages indicating an increment, it does not inherently provide a mechanism for atomically updating a shared counter. A separate consumer process would need to read these messages and then attempt to update a counter stored elsewhere, introducing potential race conditions and requiring additional logic (like distributed locks or transactional updates in the target store) to ensure atomicity.

• ✗

  Store the counter in Azure Table Storage and use optimistic concurrency with ETags.

  Why it's wrong here

  Azure Table Storage supports optimistic concurrency control using ETags, which helps detect conflicts but does not guarantee atomicity for the update operation itself. When an ETag mismatch occurs, the update fails, requiring the client to retry the entire operation. This means the initial attempt was not atomic; the system state was not guaranteed to be consistent after the first try, and multiple retries might be necessary to achieve a successful update, which is not an atomic operation by definition.

• ✗

  Use Append Blob to append each increment as a new block and sum them later.

  Why it's wrong here

  Append Blobs are optimized for append-only operations, such as logging, where new blocks are added to the end of the blob. While appending a single block is an atomic operation, the overall process of reading the current counter value, calculating a new value, and then appending it as a new block is not atomic. Furthermore, summing all blocks later to determine the current counter value introduces latency and potential inconsistencies if new appends occur concurrently, failing to provide an immediately consistent and atomic counter.

Go deeper

Related to this question