DP-900 Practice Question: Describe considerations for working with non-relational data on Azure

Answer analysis

Option-by-option breakdown

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

• ✗

  Azure Blob Storage with soft delete

  Why it's wrong here

  Soft delete in Azure Blob Storage only safeguards against accidental deletion by retaining snapshots of blobs; it does not provide any file-locking or byte-range write coordination. Blob storage is object storage, not file storage, so concurrent writers to the same blob are subject to last-writer-wins semantics with no built-in mutual exclusion. Even with soft delete enabled, simultaneous processes writing to the same large binary would overwrite each other's changes, leading to data corruption or lost updates. This option fails the requirement because it lacks the concurrency control needed for multi-process writes.

• ✓

  Azure Files

  Why this is correct

  Azure Files is the correct choice because it provides fully managed, cloud-native file shares accessible via the SMB protocol, which supports mandatory file and byte-range locking. This enables multiple VMs or processes to safely read from and write to the same large file concurrently without application-level coordination. Azure Files handles the underlying storage, offering high availability and low latency, while the SMB locking semantics ensure that writes are serialized appropriately. This directly satisfies the requirement for concurrent access to a single large binary.

• ✗

  Azure Disks

  Why it's wrong here

  Azure Disks are block-level virtual hard disks (VHDs) attached to a single virtual machine; they are not designed for direct multi-VM or multi-process concurrent access. Sharing the same disk across machines typically requires cluster shared volumes (CSV) or specialized software like Failover Clustering, which adds complexity and is not a straightforward or fully managed solution. Without such clustering, only one VM can mount the disk, so other processes cannot perform concurrent byte-range writes to the same file. This option is not suitable for the stated scenario because its architecture is per-VM, not shared-file oriented.

• ✗

  Azure NetApp Files

  Why it's wrong here

  Azure NetApp Files, while providing high-performance, scalable file storage via NFS and SMB protocols, does not natively facilitate concurrent byte-range writes to the *same file* from multiple processes without application-level locking, which would lead to contention in this scenario. It is tempting because it excels at providing shared access to large files for demanding workloads like databases or HPC, where processes typically write to different files or manage sequential updates to a single file.

Go deeper

Related to this question