Objective and core distinction
Azure Blob Storage provides an object-storage interface for binary or text data. Azure Files provides managed file shares through supported protocols such as SMB or NFS. Azure Table Storage supplies a schemaless key/attribute NoSQL model. These categories describe interfaces and data use, not whether the underlying system ultimately stores bytes. A client’s required protocol and operations matter. An SMB client is not automatically compatible with NFS, and a generic REST endpoint is not automatically the Blob REST API. Also avoid an overbroad rule that Blob can never support file protocols:the retained documentation includes applicable NFS and SFTP capabilities. Name the supported configuration rather than replace it with a slogan.
Worked example
Fictional case:a design collective keeps large reference drawings and a separate index of their owners and dates. Its existing drawing client issues object requests to a Blob endpoint. A different application reads shared files through SMB. For an unchanged interface, the object client needs its Blob request contract preserved, and the SMB application needs its file-sharing contract preserved. A product’s ability to hold the same drawing bytes does not prove those requests are interchangeable. The owner/date catalogue is another representation:fixed metadata fields can describe unstructured drawing content without making the content relational. Follow each client operation before planning a substitution.
Changed condition and misconception
Now the file requirement changes from SMB to NFS. That change is material because the retained documentation lists applicable NFS support for both Blob and Files. The protocol alone may no longer uniquely select one. Ask about the needed operations, configuration and workload rather than inventing a universal winner. For Table Storage, do not read the product name as a promise of relational joins or fixed SQL columns. It is a key/attribute NoSQL store. Data selection should also separate a catalogue entity from the corresponding binary object. One may be updated or queried for a purpose different from retrieving the other.
Transfer check
Transfer check:a team says a file share and an object endpoint are compatible because both use a network and both contain images. What evidence would you request? Check basis:the exact client protocol/API, the required operations, and the supported service configuration. Network transport and byte content alone do not establish the application contract. Then suppose an approved toy capacity model adds a catalogue record for every image. Keep the per-image quantities and units explicit when calculating a subtotal; do not turn that arithmetic into a claim about actual provider overhead or billing. The linked tasks test protocol sufficiency, data models and one fully supplied quantity model.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
Identify data formats - Training | Microsoft LearnIntroduction to Azure Storage - Cloud storage on Azure | Microsoft Learn