Configure & Manage Azure Storage Accounts and Redundancy (AZ-104)

A storage account provides a unique namespace in Azure for your data and is the resource you create before you can store a single blob or file. When you create one, three early choices shape everything that follows: account kind, performance tier, and redundancy (covered in the next section).

For account kind, the modern default is general-purpose v2 (GPv2). It supports all storage services — blobs, files, queues, and tables — and all access tiers (hot, cool, cold, and archive), so it is the right answer for virtually every new account. Older kinds still appear in questions: general-purpose v1 is legacy and lacks access tiers, BlobStorage is a superseded blob-only kind, and premium block blob, premium file shares, and premium page blob accounts are specialized premium options.

For performance, you choose between two tiers. Standard uses magnetic disks, is the most cost-effective, and suits the majority of workloads. Premium uses solid-state disks for low latency and high transaction rates and is required for scenarios such as premium file shares or high-performance block-blob workloads; premium is a specific account kind chosen at creation, not a switch you flip later. Other settings you set at creation include the region, subscription, and resource group. On the exam, unless a scenario calls out low latency or premium file shares, general-purpose v2 with Standard performance is the expected default.

Redundancy determines how many copies of your data Azure keeps and where, and it is the single most tested concept in this topic. Every option keeps at least three copies; they differ in whether those copies survive a hardware fault, a whole-datacenter (zone) failure, or an entire region going down.

The four base options build on each other. Locally redundant storage (LRS) keeps three copies within a single datacenter — the cheapest, but a datacenter disaster loses the data. Zone-redundant storage (ZRS) spreads three copies across three availability zones in one region, surviving the loss of a zone. Geo-redundant storage (GRS) keeps three LRS copies in your primary region and asynchronously copies the data to a paired secondary region hundreds of miles away, surviving a full regional outage. Geo-zone-redundant storage (GZRS) is the premium combination: ZRS in the primary region plus geo-replication to the secondary — the highest durability.

On the exam, survive a full region outage means GRS or GZRS, while survive a datacenter outage but stay in one region means ZRS.

Geo-redundant storage protects your data by copying it to a second region, but by default that secondary copy is not readable. With plain GRS or GZRS, the data in the secondary region sits idle for disaster recovery only — you cannot read it unless Microsoft initiates a failover that promotes the secondary to primary. If your application just needs the data to exist elsewhere for recovery, GRS or GZRS is enough.

The read-access variants change this. RA-GRS and RA-GZRS add read access to the secondary region at any time, without waiting for a failover. Azure exposes a second endpoint — the account name with a -secondary suffix — that your application can read from directly. This is the detail the exam hammers on: if a requirement says the application must be able to read from the secondary region, only RA-GRS or RA-GZRS satisfies it; plain GRS and GZRS do not.

Two practical points. First, the secondary is eventually consistent — geo-replication is asynchronous, so recent writes may not yet be present when you read the secondary; you can check the Last Sync Time property to see how current it is. Second, reads to the secondary are read-only; you cannot write there. A common use is offloading read traffic to the secondary endpoint or serving read requests during a primary-region disruption. On the exam, read from the secondary is the exact trigger phrase for the RA- variants.

Object replication asynchronously copies block blobs from a source storage account to a destination storage account, according to replication rules you define. It is distinct from redundancy: redundancy copies an account within Microsoft's own infrastructure automatically, whereas object replication copies selected blobs between two storage accounts you own, which can be in different regions and even different subscriptions.

The key prerequisite you must remember is that blob versioning must be enabled on both the source and the destination accounts — object replication relies on versioning to track and copy changes, and you cannot configure a rule without it. You also enable the change feed on the source account. A replication policy contains one or more rules, each mapping a source container to a destination container, optionally filtered by a blob-name prefix, and you choose whether to copy existing blobs or only new ones.

Typical uses are minimizing read latency by keeping a copy near consumers in another region, distributing processing so compute runs close to the data, and cost optimization by replicating to an account that uses different access tiers. Because replication is asynchronous, the destination is eventually consistent with the source, not instantaneous. On the exam, watch for two triggers: copy block blobs between two storage accounts points to object replication, and any object-replication question mentioning a prerequisite is testing that blob versioning is required on both accounts. Object replication applies to block blobs only — not files, queues, or tables.

All data written to Azure Storage is encrypted at rest automatically, and you cannot turn it off. This is Storage Service Encryption (SSE): it uses 256-bit AES and is transparent, so applications read and write normally while Azure encrypts on write and decrypts on read. The exam fact to lock in is that encryption at rest is always on — there is no unencrypted option for a storage account.

What you can configure is who manages the keys:

• Microsoft-managed keys — the default. Azure creates, stores, and rotates the encryption keys for you, with no action required.
• Customer-managed keys (CMK) — you supply and control the key in Azure Key Vault (or Key Vault Managed HSM). You gain control over rotation, revocation, and auditing, at the cost of managing the key lifecycle yourself. This is the option for compliance requirements that demand your organization holds the keys.

For an extra layer, you can enable infrastructure encryption when you create the account, which encrypts data twice — once at the service level and again at the infrastructure level, each with a separate key — for scenarios that require double encryption. Infrastructure encryption must be chosen at account creation and cannot be added afterward.

On the exam, encryption is always on describes SSE; we must control and rotate our own keys points to customer-managed keys in Key Vault; and encrypt the data twice points to infrastructure encryption.

Two Microsoft tools handle bulk data movement and management, and the exam expects you to know which is which. Azure Storage Explorer is a free, cross-platform graphical (GUI) desktop application for Windows, macOS, and Linux. You connect it to accounts with your Entra sign-in, an access key, a SAS, or a connection string, then browse containers, file shares, queues, and tables in a familiar tree, uploading and downloading with drag-and-drop and managing access policies and properties visually. It is the tool for interactive, point-and-click management.

AzCopy is a command-line utility built for high-performance, scriptable bulk transfer. It moves data efficiently between local storage and Azure, or directly account-to-account (server-to-server), and it excels at large migrations and repeatable, automated jobs you place in scripts or pipelines. A typical command copies a folder into a container:

azcopy copy "C:\data\*" "https://acct.blob.core.windows.net/container?[SAS-token]" --recursive

AzCopy authenticates with a SAS token or a Microsoft Entra login, resumes interrupted transfers, and is in fact the engine Storage Explorer uses under the hood for its transfers. The decision is straightforward: choose Storage Explorer for a visual, ad-hoc experience, and choose AzCopy for scripted, automated, or very large transfers. On the exam, a GUI to browse and manage storage is Storage Explorer, while scriptable command-line bulk copy or automate large data transfers is AzCopy.

Put redundancy to work with a decision the exam loves. Your company runs a customer-facing application whose data must survive a complete outage of its primary Azure region, and the architecture team also wants the application to read from the secondary region — both to serve some read traffic there and to keep functioning if the primary is unreachable. Which redundancy option do you choose?

Start by eliminating options. LRS and ZRS both stay within a single region, so neither survives a regional outage — both are out. GRS and GZRS do replicate to a second region and survive a region outage, but their secondary copy is not readable until a failover, so they fail the read-from-secondary requirement. That leaves the read-access variants: RA-GRS or RA-GZRS, which add read access to the secondary endpoint at any time.

Between the two, choose RA-GZRS if you also want the primary region protected against a zone failure — its primary copy is zone-redundant — and RA-GRS if locally redundant primary storage is acceptable and you want lower cost. Either way, your application reads the secondary through the -secondary endpoint, remembering that it is eventually consistent. The exam pattern is reliable: survive a region outage narrows you to the geo options, and adding read from the secondary region forces the answer to RA-GRS or RA-GZRS.