Storage Accounts, Redundancy and Encryption

What it is

A storage account is the container for blobs, files, queues and tables. When you create one, you decide its type, its performance, how its data is replicated and how it is encrypted.

Most of these choices are made at creation, so the exam asks what to choose for a given need, and how to change a setting afterward.

How it works

Account types and names

A storage account name must be 3 to 24 characters, lowercase letters and numbers only, and unique across Azure.

Redundancy

The read access versions, RA-GRS and RA-GZRS, let applications read the secondary copy at any time. With plain GRS or GZRS the secondary is used only after a failover.

You change the redundancy of an existing account in its Redundancy setting, and some conversions run as a managed process without downtime. For GRS and GZRS you can also start an account failover to the secondary region. After a failover the account becomes locally redundant in its new primary region.

Object replication

Object replication copies block blobs from a container in one storage account to a container in another, asynchronously, using rules that can filter by prefix. The accounts can be in different regions or subscriptions.

It has prerequisites: blob versioning must be on in both accounts, and change feed must be on in the source account. While a policy is active, writes to the destination container are blocked, although reads and deletes are still allowed.

Encryption

All data in a storage account is encrypted at rest with 256 bit AES. You choose who holds the key.

• Microsoft managed keys: the default, with nothing to manage.
• Customer managed keys: keys that you keep in Azure Key Vault or a managed HSM. The vault must have soft delete and purge protection turned on.
• Infrastructure encryption: a second layer of encryption, which must be chosen when the account is created.

For data in transit, secure transfer required forces HTTPS and encrypted SMB, and you can set a minimum TLS version.

Azure Storage Explorer and AzCopy

Azure Storage Explorer is a graphical app for Windows, macOS and Linux. You connect with your Microsoft Entra account, a SAS URL or an account key, and then browse, upload and manage data.

AzCopy is a command line tool for fast bulk copying. Sign in with Microsoft Entra, or append a SAS to the URL.

azcopy login
azcopy copy "C:\data" "https://contoso.blob.core.windows.net/backup" --recursive
azcopy sync "C:\data" "https://contoso.blob.core.windows.net/backup" --recursive

copy transfers files. sync makes the destination match the source. Copies between two storage accounts happen directly between them, not through your computer.

Creating an account from the command line

az storage account create --name stcontoso001 --resource-group rg-app --location westeurope --sku Standard_GRS --kind StorageV2

The --sku value sets the redundancy, for example Standard_LRS, Standard_ZRS, Standard_GRS or Standard_GZRS.

Choosing redundancy by requirement

Customer managed keys in steps

Using your own key has a fixed sequence.

1. Create an Azure Key Vault with soft delete and purge protection turned on.
2. Create a key in the vault.
3. Give the storage account a managed identity.
4. Give that identity permission to use the key, for example the Key Vault Crypto Service Encryption User role.
5. On the storage account, choose customer managed keys and select the key.

If the key is deleted or the permission is removed, the storage account can no longer read its data, which is why purge protection matters.

How the exam asks about this

• "Copy blobs automatically to another account." Object replication, with versioning on both and change feed on the source.
• "Encrypt with a key you control." Customer managed key in Key Vault.
• "Force encrypted connections." Secure transfer required.
• "Copy a folder to a container quickly." AzCopy.
• "Which failover leaves the account locally redundant?" A customer initiated account failover.