Azure Storage Services and Account Types Explained

Azure Storage is one platform that hosts four distinct data services — Blob storage for unstructured objects, Azure Files for mountable SMB/NFS file shares, Queue storage for asynchronous messaging, and Table storage for NoSQL key-value data — and you choose an account type that determines which of those services you get and on what hardware. General-purpose v2 supports all four and is Microsoft’s recommended default; specialized Premium account types trade that flexibility for higher throughput and lower latency on one workload.

The four storage services

Each service targets a data shape the other three handle poorly:

• Blob storage stores massive volumes of unstructured data — images, video, log files, backups — accessed over HTTP/HTTPS. It’s Azure’s object storage service, the rough equivalent of Amazon S3.
• Azure Files provides fully managed cloud file shares over the SMB and, for Linux workloads, NFS protocols. Multiple machines, cloud or on-premises, can mount the same share concurrently, which makes it the go-to choice for replatforming an application that expects a mapped network drive without rewriting its code.
• Queue storage holds large numbers of small messages that decouple application components — one part of an app posts a message, another retrieves and processes it later, enabling asynchronous communication.
• Table storage is a NoSQL key-value store for structured, non-relational data addressed by partition key and row key, well suited to huge volumes of records — device telemetry, for example — that need fast lookups without a relational schema.

Azure managed disks are a related but separate resource: they’re the block-level virtual hard disks attached to virtual machines as OS and data disks, provisioned on their own rather than created inside a general-purpose storage account. Under the hood, managed disks are actually stored as page blobs, a specific blob type built for the random read/write access pattern that disk I/O needs — alongside block blobs (discrete files uploaded in blocks, the default for most Blob storage data) and append blobs (optimized for sequential, append-only writes such as log files).

Storage account types

An Azure Storage account is the container you provision that determines which services are available and what hardware backs them:

• General-purpose v2 (GPv2) is the recommended account type for most scenarios. It supports blob containers, file shares, queues, and tables in a single account, along with every access tier, the latest pricing and security features, and a full choice of storage redundancy options from locally redundant to geo-zone-redundant.
• General-purpose v1 is a legacy account type that predates GPv2 and lacks its access tiers and newer capabilities — you’ll mainly see it as the “wrong, outdated” answer choice.
• Premium block blob storage accounts use solid-state drives to deliver high transaction rates and low, consistent latency for block and append blob workloads — a fit for scenarios writing and reading millions of small objects per second where standard performance becomes a bottleneck.
• Premium page blob storage accounts are SSD-backed and built for disk-style random read/write access, such as an unmanaged legacy VHD stored directly as a page blob rather than as a managed disk.
• FileStorage accounts provide premium, SSD-backed Azure Files shares for latency-sensitive, IOPS-intensive SMB workloads — but the account holds only file shares, not blob, queue, or table data.

Trying to create a file share or queue inside a Premium block blob (BlockBlobStorage) account fails outright: that account type is scoped strictly to block and append blobs, and Azure does not silently fall back to standard performance or convert the account to GPv2 to accommodate the request.

Performance tier vs account type

It’s easy to conflate “performance tier” with “access tier,” but AZ-900 tests them as separate concepts. The performance tier — Standard or Premium — is selected when you create the account and determines the underlying hardware: Standard uses traditional magnetic media, Premium uses SSDs. Access tiers (Hot, Cool, Cold, Archive) are a separate, blob-only cost lever layered on top of a Standard GPv2 account, controlled by how frequently the data is read — covered in depth in Azure Blob Storage Access Tiers: Hot, Cool, Cold, and Archive. A common wrong-answer pattern pairs a Premium account with a Cool or Archive access tier — that combination doesn’t exist, because access tiers only apply to Standard GPv2 accounts.

Comparing the account types

Account type	Services supported	Performance	Typical fit
General-purpose v2	Blob, Files, Queue, Table	Standard (with premium blob/file variants available separately)	Default choice for most workloads
General-purpose v1	Blob, Files, Queue, Table	Standard, legacy	Rarely the right answer; superseded by GPv2
Premium block blob	Block and append blobs only	Premium (SSD)	High-transaction-rate object workloads
Premium page blob	Page blobs only	Premium (SSD)	Unmanaged VHDs, disk-style random I/O
FileStorage	Azure Files only	Premium (SSD)	Latency-sensitive, high-IOPS SMB shares

Naming and organizing data

Storage account names must be globally unique across Azure, three to twenty-four characters long, and made up of only lowercase letters and numbers — no hyphens, underscores, or uppercase letters. Within a GPv2 account, you can enable Data Lake Storage Gen2 by turning on hierarchical namespace, which organizes blob data into a directory-and-file structure instead of a flat namespace — a common requirement for big-data analytics workloads that need to traverse folders efficiently. Getting large volumes of data into these accounts in the first place is a separate problem, covered in Azure Data Migration Tools: AzCopy, Data Box, and Azure Migrate.

How the AZ-900 exam tests this

• Service-by-clue matching. A stem describing unstructured media served over HTTP points to Blob storage; SMB-mounted shares point to Azure Files; asynchronous inter-component messages point to Queue storage; schema-less key-value records point to Table storage. The exam rarely names the service directly — it describes the access pattern instead.
• “Which account type is recommended” defaults to General-purpose v2 unless the scenario specifies a performance-critical, single-service workload that justifies a Premium account.
• Invalid-combination traps. Watch for an option pairing a Premium account with an access tier like Cool or Archive, or an attempt to add a file share and a queue to a Premium block blob account — both are impossible configurations designed to test whether you actually understand account type boundaries.
• Underlying-blob-type questions ask what backs a managed disk (page blobs) or what an append-only logging workload should use (append blobs), testing the block/page/append distinction rather than the account type itself.

Getting comfortable with which service and account type a scenario is quietly describing is most of what this domain tests — work through AZ-900 practice questions that rotate through Blob, Files, Queue, and Table scenarios to build that recognition. Once an application actually needs to reach these services privately from inside a virtual network, the mechanism is the private endpoint covered in Azure Hybrid Connectivity: VPN Gateway, ExpressRoute, and Private Endpoints.

Quick reference

• Blob storage: unstructured objects over HTTP/HTTPS. Azure Files: SMB/NFS file shares. Queue storage: asynchronous messaging. Table storage: NoSQL key-value data.
• Managed disks are a separate resource type, stored under the hood as page blobs.
• General-purpose v2 is the recommended default account type and supports all four services plus every access tier.
• Premium block blob, Premium page blob, and FileStorage are specialized, single-service SSD-backed account types.
• Performance tier (Standard/Premium) is set at account creation and picks the hardware; access tiers (Hot/Cool/Cold/Archive) are a separate, Standard-GPv2-only cost lever for blob data.
• A Premium account paired with an access tier, or a Premium block blob account holding a file share or queue, is an invalid configuration.
• Storage account names: 3–24 characters, lowercase letters and numbers only, globally unique.
• Enable hierarchical namespace (Data Lake Storage Gen2) on Blob storage for directory-structured big-data workloads.