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.

• ✗

  Use a stored procedure that checks the document version before updating.

  Why it's wrong here

  Stored procedures in Cosmos DB execute within a transaction scope on a single partition, but they do not inherently provide optimistic concurrency control across multiple requests. You could implement a version check inside a stored procedure, but that would require custom logic and does not leverage the built-in ETag mechanism. Stored procedures are not the recommended way to handle concurrency because they add complexity and can become bottlenecks. The ETag-based approach is simpler and natively supported by the SDK, making it the better choice for preventing lost updates.

• ✓

  Enable the ETag property on the document and include it in the request options for replace operations.

  Why this is correct

  Cosmos DB provides optimistic concurrency control through the ETag property of a document. The ETag is a system-generated value that changes on every update. By including the ETag in the ItemRequestOptions for a replace operation, the SDK sends it as an If-Match header. If the document has been modified since the ETag was retrieved, the operation fails with a PreconditionFailed (412) error. This allows the application to handle conflicts gracefully, such as by retrying or notifying the user. This is the standard and recommended approach for optimistic concurrency in Cosmos DB.

• ✗

  Use a unique index on the document ID to prevent duplicate writes.

  Why it's wrong here

  Unique indexes enforce uniqueness on specified properties, but they do not help with optimistic concurrency control for updates. If two users try to update the same document, both updates would have the same document ID, and the index would not prevent the second write from overwriting the first. Unique indexes are useful for preventing duplicate documents, but they do not detect concurrent modifications. The ETag-based approach is specifically designed to handle this scenario by ensuring that the write only succeeds if the document has not changed since it was read.

• ✗

  Set the consistency level to Strong for the Cosmos DB account.

  Why it's wrong here

  Consistency levels in Cosmos DB control the trade-off between consistency and latency, but they do not provide optimistic concurrency control. Strong consistency ensures that reads always return the latest committed write, but it does not prevent two users from overwriting each other's changes if they both read the same document and then write. Optimistic concurrency requires a mechanism to detect conflicts at write time, such as ETags. Changing the consistency level would not solve the lost update problem and could increase latency, so it is not the correct solution.

Go deeper

Related to this question