AZ-305 Design data storage solutions 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.

• ✓

  Azure Blob Storage

  Why this is correct

  Azure Blob Storage is the correct choice because it is an object storage service purpose-built for massive amounts of unstructured data, including large binary files like images and videos. It exposes every blob via a unique HTTP/HTTPS URL, allowing both private access (using stored access policies or shared access signatures) and public access at the container or blob level, which is ideal for direct retrieval by clients or browsers. Blob Storage also scales to exabytes, offers tiered storage (hot, cool, archive) to optimize cost, and integrates with Azure CDN to serve media at scale, making it the de facto solution for storing and serving binary content.

• ✗

  Azure Files

  Why it's wrong here

  Azure Files is not appropriate here because it provides fully managed file shares that are primarily accessed via the Server Message Block (SMB) protocol or NFS, not via public HTTP/HTTPS URLs for anonymous content retrieval. While Azure Files does have a REST API, it is designed for file-level operations (e.g., creating directories and enumerating files) rather than serving high‑throughput, publicly accessible binary payloads like images and videos directly to end users. Its performance and access model are built for enterprise file shares and lift‑and‑shift applications, not for scaling to millions of concurrent HTTP downloads of large media files.

• ✗

  Azure Queue Storage

  Why it's wrong here

  Azure Queue Storage is fundamentally a message queue for asynchronous communication between application components, designed to store small messages — at most 64 KB each — rather than large binary files. Messages are retrieved with a pop receive operation that returns a message payload and a pop receipt, but there is no direct URL or streaming capability that lets a client fetch an image or video by HTTP. The service exists to decouple processes (e.g., queuing work for background jobs), not as a storage or content‑delivery back end, so storing videos in queues would be technically impossible and architecturally nonsensical.

• ✗

  Azure Table Storage

  Why it's wrong here

  Azure Table Storage is a NoSQL key‑value/entity store intended for semi‑structured or structured data, where each entity (up to 1 MB total size) is a collection of properties. Large binary files such as videos and high‑resolution images routinely exceed the per‑entity size limit, and even if they did not, Table Storage does not offer HTTP URL–based retrieval or support efficient streaming of binary content. It is optimized for low‑latency reads and writes of discrete data points (e.g., user state, metadata) rather than serving media payloads, so images and videos should never be stored directly in Table Storage — at most, you might store metadata about those blobs there.

Go deeper

Related to this question