An Azure storage account is a single namespace that holds an account's blob, file, queue, and table data behind one HTTPS endpoint [1]. It is also an Azure Resource Manager resource, which means it lives inside a resource group and inherits the role assignments and policies attached to that container [1]. Getting the seven portal tabs right is one of the most heavily tested skills on the AZ-104 exam Implement and manage storage carries 15 to 20 percent of the score [2].
Prerequisites
Access and identity
Contributor or Owner on the target subscription is the baseline. If customer-managed keys are in play, you also need a user-assigned managed identity that can read from Azure Key Vault.
Design decisions before opening the portal
Settle the resource group, primary region, paired secondary region, and an account name between 3 and 24 characters using only lowercase letters and digits [1]. Decide the workload profile (blob, file, queue, table), performance tier, network exposure model (public, service endpoint, or private endpoint), and the default access tier. Make these calls on paper first they constrain everything downstream.
Local tooling
Install Azure Storage Explorer and AzCopy for post-deploy validation. Both are called out explicitly under the AZ-104 storage objectives [2].
1. Plan the Storage Account (Basics Tab)
The Basics tab asks for Subscription, Resource group, Storage account name, Region, Preferred storage type, Performance, and Redundancy [1]. Every later tab keys off these answers, which is exactly why most misconfigurations start here.
Subscription and resource group. Pick the subscription that owns the workload, then either reuse a resource group or create one inline [1]. Keep the storage account in the same resource group as the workload it backs deletion, RBAC, and cost reporting all stay aligned that way.
Account name. The name has to be globally unique across Azure and conform to the 3-to-24 lowercase-and-digits rule [1]. The portal validates uniqueness in real time, so a clash fails fast.
Region. Pick the region closest to the consuming compute, then note its Azure paired region. The paired region is where GRS and GZRS perform asynchronous replication it is not user-selectable.
Preferred storage type and performance. Standard maps to general-purpose v2 (StorageV2), which Microsoft recommends as the default and which supports every redundancy option plus hierarchical namespace [1]. Premium splits into three purpose-built accounts: BlockBlobStorage for low-latency blob workloads, FileStorage for premium Azure Files, and StorageV2 with Premium_LRS for premium page blobs [1].
Redundancy. The dropdown changes based on the performance tier you chose. Standard general-purpose v2 exposes all six options LRS, GRS, RA-GRS, ZRS, GZRS, RA-GZRS [1]. Premium BlockBlobStorage and FileStorage offer LRS and ZRS only, and premium page blob accounts are LRS only [1]. Decide before clicking Next.
2. Choose the Right Redundancy
Redundancy is the question AZ-104 keeps coming back to. The right answer sits at the intersection of durability, region pair availability, workload type, and cost.
LRS replicates synchronously to a single physical datacenter and delivers at least 99.999999999 percent (11 nines) of durability per year at the lowest price [3]. Reach for it when the data can be regenerated or when geo-resilience is handled at a higher layer.
ZRS replicates synchronously across three or more availability zones in the primary region and reaches at least 99.9999999999 percent (12 nines) of durability [3]. Microsoft recommends ZRS as the primary-region choice for Azure Files and Azure Data Lake Storage workloads [3].
GRS pairs LRS in the primary region with asynchronous LRS replication to the paired secondary region [3]. GZRS does the same with ZRS in the primary region [3]. Both target at least 99.99999999999999 percent (16 nines) of durability over a year [3]. Asynchronous geo-replication for block blobs holds a recovery point objective of 15 minutes or less [3].
Data in the secondary region is not readable or writable under normal conditions. Read access requires turning on Make read access to data available in the event of regional unavailability, which promotes the account to RA-GRS or RA-GZRS [1]. RA-GRS and RA-GZRS lift the read SLA to at least 99.99 percent on the hot tier [3]. The secondary endpoint appends -secondary to the account name for example, myaccount-secondary.blob.core.windows.net and the same access keys work for both endpoints [3].
Two limits matter for the exam. Premium accounts cannot select GRS or GZRS [1]. Azure Files does not support RA-GRS or RA-GZRS at all [3]. Picking either combination in the portal leaves the option missing or greyed out, and that is the expected behaviour.
3. Configure Advanced Settings
The Advanced tab is where most of the hardening choices land.
The minimum TLS version defaults to TLS 1.2, which makes the account reject any client still negotiating TLS 1.0 or TLS 1.1 [1]. Leave it at 1.2 unless a legacy integration is documented and time-boxed.
Require secure transfer for REST API operations forces every request to arrive over HTTPS and is the Microsoft-recommended setting [1]. Keep it on.
Enable storage account key access controls whether Shared Key authorization is even possible. Disabling it pushes every client onto Microsoft Entra ID, which Microsoft characterizes as the more secure path [1]. The portal-side Default to Microsoft Entra authorization in the Azure portal is the matching UX setting for human access.
Hierarchical namespace converts the account into Azure Data Lake Storage Gen2 and changes how directories behave it cannot be toggled later without rebuilding. SFTP, NFS v3, and large file shares are workload-specific and worth enabling only when those protocols are genuinely needed.
The default access tier is set here as well. Pick Hot for frequently read data and Cool for infrequently read but quickly retrievable data. The tier can be changed per blob later, but the account default sets the tone.
4. Configure Networking
Public network access has three settings: enabled from all networks, enabled from selected virtual networks and IP addresses, or disabled [1]. Production accounts belong on one of the latter two. Network routing defaults to Microsoft network routing leave it there unless a specific internet-routing requirement exists [1].
Azure Storage firewall rules come in four categories: virtual network rules, IP network rules, resource instance rules, and trusted service exceptions [4]. With rules in place, only sources explicitly allowed can reach the public endpoint [4]. Each storage account supports up to 400 virtual network rules and up to 400 IP network rules those are the ceilings AZ-104 expects you to recognize [4].
When you create a virtual network rule in the portal, the required service endpoint is added to the subnet automatically: Microsoft.Storage for same-region access or Microsoft.Storage.Global for cross-region access [4]. Skipping the portal and adding the rule through the CLI without that service endpoint is the most common reason a firewall rule misbehaves.
A private endpoint assigns a private IP from the chosen virtual network directly to the storage account and removes public exposure entirely [1]. Combine that with public access set to disabled, and the account is unreachable from the internet.
One detail catches candidates every cycle. Network rules decide whether traffic is allowed to arrive authorization still applies on top of that. Even when a client comes from an allowed VNet or IP, it still needs valid Shared Key, SAS, or Microsoft Entra ID credentials [4].
5. Configure Data Protection
Microsoft recommends enabling blob soft delete, container soft delete, and file share soft delete, each with a retention of at least seven days [1]. Treat seven days as the floor, not the target. Production storage typically holds soft-deleted state for 14 to 30 days.
Blob versioning, blob change feed, and operational backup with Azure Backup are configured on this tab as well. Object replication rules live here when same-region or cross-region blob replication is required.
Point-in-time restore for containers has prerequisites that the portal auto-enables blob versioning, blob soft delete, and blob change feed all switch on as part of the wizard [1]. Trying to enable point-in-time restore through scripts on an account where those three are off returns a validation error.
6. Configure Encryption
Data is encrypted with Microsoft-managed keys by default [1]. Switching to customer-managed keys stores the key in Azure Key Vault and accesses it through a user-assigned managed identity [1]. Granting that identity the Key Vault Crypto Service Encryption User role is the step administrators forget.
Encryption scopes apply at the blob container level and allow different keys for different containers inside one account. Useful for multi-tenant setups or per-classification segregation.
Infrastructure encryption is off by default. Turning it on adds a second encryption layer at the infrastructure level on top of the service-level encryption producing double encryption at rest [1]. Enable it for regulated workloads where double encryption is a stated control. It cannot be enabled after the account is created.
Azure Storage also runs continuous CRC-based integrity checks against stored data and calculates network checksums on traffic, repairing any corruption it detects from redundant copies [3]. That behaviour is built in and needs no configuration.
7. Apply Tags
Five tags cover the governance baseline expected on production storage: cost center, environment (prod, dev, test), owner, workload or application, and data classification or compliance label. Tags applied on the storage account propagate to billing exports and to Azure Policy evaluation that is what makes them load-bearing.
8. Review + Create
Azure runs portal validation against every field on this tab. A validation pass means the parameters are internally consistent it does not mean the deployment will succeed in the target region.
Use Download a template for automation to export the resulting ARM template. That export is the seed of every Bicep or Terraform module the team will write afterward, and it is the easiest way to reconcile portal clicks with declarative infrastructure.
Submit Create and watch the notification pane for the deployment outcome.
9. Verify the Deployment
Confirm the primary endpoint resolves and, for geo-redundant accounts, that the -secondary endpoint resolves too [3]. Test that an HTTP request is refused while an HTTPS request succeeds that validates the secure transfer setting.
Assign Storage Blob Data Contributor to a test Entra identity and confirm it can write a blob through Storage Explorer. Generate a user delegation SAS, then create a stored access policy on a container and bind a service SAS to it. Rotate one of the two account access keys, repoint a client to the new key, and confirm the rotation does not break access.
For Azure Files, configure identity-based access using either Microsoft Entra Kerberos for hybrid identities or AD DS authentication for joined machines [2]. Mount the share from a test client to verify the identity flow.
Run azcopy copy against a small directory tree to confirm AzCopy authentication and throughput. If object replication is configured, write a blob to the source and check arrival in the destination. Delete a blob and confirm soft delete retains it for the configured period.
Troubleshooting Common Issues
- Name validation fails. The account name is already taken globally, contains an uppercase letter, or includes a hyphen. All three are blocked by the 3-to-24 lowercase-and-digits rule [1].
- ZRS missing from the redundancy dropdown. ZRS is not offered in every region. Pick a region from the published ZRS list.
- GRS or GZRS missing on a premium account. Premium BlockBlobStorage and FileStorage support LRS and ZRS only, and premium page blob accounts are LRS only [1].
- Clients drop after TLS 1.2 enforcement. Legacy SDKs still negotiate TLS 1.0 or 1.1 and get rejected on the handshake [1]. Upgrade the client.
- Shared Key request returns 403. Storage account key access was disabled, which removes Shared Key authorization and requires Microsoft Entra ID [1].
- Firewall blocks a client even though a VNet rule exists. The subnet is missing the
Microsoft.StorageorMicrosoft.Storage.Globalservice endpoint that the portal would have added automatically [4]. - Private endpoint reachable from the VNet but DNS still returns the public IP. The private DNS zone for
privatelink.blob.core.windows.netis missing or not linked to the consuming VNet. - CMK enable fails with access denied. The user-assigned managed identity does not have the required Key Vault permissions [1].
- Point-in-time restore option is greyed out. Blob versioning, blob soft delete, and blob change feed have not all been enabled [1].
- Azure Files refuses to offer RA-GRS or RA-GZRS. Azure Files does not support either tier [3].
Summary
The seven-tab portal walkthrough produces a storage account that is named correctly, sized to the workload, redundant against the failure mode the business actually cares about, and locked down at the network and identity layers. Standard general-purpose v2 with ZRS or GZRS covers most workloads; premium accounts trade geo-redundancy for latency [1][3]. TLS 1.2, HTTPS-only, disabled Shared Key access, and customer-managed keys with infrastructure encryption are the hardening defaults to keep in place [1]. Soft delete at seven days minimum, versioning, change feed, and point-in-time restore are the data-protection defaults AZ-104 expects [1]. Verify with Storage Explorer, AzCopy, a SAS test, and an RBAC test before handing the account to a workload owner [2]. That sequence maps directly to the AZ-104 Implement and manage storage domain at 15 to 20 percent of the exam [2].