Two cairn-trail map builders must not overwrite the same GeoJSON blob at the same time. Which Blob Storage SDK concurrency tool should they use for an exclusive write?
Select an answer to reveal the explanation.
Short Explanation
A blob lease is the “occupied” sign on the editing desk: one writer holds it, others wait. Cosmos ETags guard Cosmos items, not blob bytes. Archive tier and VM disk leases solve different problems.
Full Explanation
Exclusive write coordination on a single blob is provided by blob leases. A writer acquires a lease (typically infinite or a timed lease with renewals), performs the update while presenting the lease ID, then releases the lease. Other clients without the lease ID cannot overwrite the leased blob, which prevents the two cairn-trail map builders from clobbering the same GeoJSON concurrently. This is the Blob Storage concurrency primitive designed for that scenario.
Relying on a Cosmos DB ETag on a shadow document fails because optimistic concurrency in Cosmos does not lock the blob data plane. Two writers can still overwrite the blob unless the blob itself is protected; cross-service ETags are not a substitute for a blob lease.
Attaching a VM disk lease to the storage account key fails conceptually: disk/lease notions for Azure Disks or page-blob VHDs are not how you serialize writes to an arbitrary GeoJSON block blob, and leasing does not attach to “the storage account key” as described.
Setting the blob access tier to Archive fails because Archive makes the object offline for read/write until rehydration; it is not a mutex and does not serialize online writers.
Exam caveat: leases expire if not renewed; a crashed writer can leave a lease until timeout unless you break lease with appropriate privileges—design renew/break handling deliberately. Operational check: acquire a lease in one process, attempt an overwrite without the lease ID from another, confirm failure, then release and verify the second writer can proceed.