A small IoT device registry for park sensors needs structured NoSQL-style entity rows with keys and attributes. Which Azure Storage service fits at a compare level?
Select an answer to reveal the explanation.
Short Explanation
Key-plus-attributes entity rows sound like Table storage — a simple structured NoSQL shelf. Blobs are objects, files are shares, queues are messages. Device registry entities map to tables.
Full Explanation
Azure Table storage stores structured NoSQL entity data using keys and attributes, which fits a small IoT device registry for park sensors where each device is an entity with properties rather than a full relational database or an unstructured object file. Blob storage targets unstructured objects such as images and documents; it is not optimized solely as a relational foreign-key store and is the wrong primary model for key-attribute registries. Azure Files provides file shares, not a NoSQL entity database presented as SMB message queues. Queue storage moves messages between producers and consumers; it is not the primary structured entity store for device registries. Table storage keeps the registry simple when relational power would be overkill for sensor metadata. Exam caveat: Table storage is a compare-level option for simple structured data—heavy relational queries, joins, and advanced indexing needs often push teams toward Azure SQL or other databases as the estate grows. Operational check: insert sample sensor entities with partition and row keys, query by device id, confirm attribute updates work for the registry size the parks team expects to grow into, and keep a sample entity template in the support runbook.