A city open-data team wants blobs for documents and queues for async job messages under one Azure Storage setup. What should they understand about a storage account?
Select an answer to reveal the explanation.
Short Explanation
One account can be a Swiss Army knife—blob endpoint here, queue endpoint there, same namespace roof. The open-data team does not need a new subscription for every service. Queues and tables are storage services too, not orphans outside the account.
Full Explanation
One storage account can expose multiple storage services under a shared namespace, which is exactly what a city open-data team needs when documents live as blobs and async job messages live as queues in the same Azure Storage setup. The account provides endpoints and shared configuration for blobs, files, queues, and tables as enabled, so teams do not need a separate subscription merely to use more than one storage service.
Each service always requires a separate Azure subscription with no shared account overstates isolation and contradicts the multi-service account model. Queues can exist only outside any storage account boundary is incorrect—queues are a storage-account data service. A storage account may host blobs but never queues or tables is a false limitation at fundamentals level; accounts are designed as multi-service hosts.
Exam caveat: security, networking, and lifecycle settings often apply at account scope, so mixing highly sensitive and public open-data workloads in one account may be an organizational policy issue even when technically possible. Operational check: enable blob and queue services under one municipal storage account, send a test message to a queue and upload a sample open-data blob, and verify both succeed under the same account namespace.