Sequence 2 — Create & Configure Storage Accounts

Prerequisites: Sequence 1 (you know what a storage account is and which services it hosts) · What you'll be able to do: create an account end-to-end in the portal, CLI and PowerShell · pick the right kind and performance tier · obey the naming/region rules · manage an account after creation (upgrade, move, delete) · Est. time: ~14 min.

1. The big picture: an account is an ARM resource

A storage account is an Azure Resource Manager (ARM) resource. That single fact drives the whole creation workflow:

• Every account must live in a resource group — a logical container in a single subscription. You either create a new one or pick an existing one.
• The account gets a globally unique namespace (https://<name>.blob.core.windows.net, etc. — see Sequence 1) accessible over HTTP/HTTPS worldwide.
• All four data services (blobs, files, queues, tables) live inside the same account and are billed together as a group.

Three properties are decided at creation and can never be changed afterwards: the account name, the kind (account type), and — implicitly — the performance tier. Get these right the first time; everything else (networking, data protection, most encryption settings) can be tuned later.

2. Naming, region & placement — the Basics tab

The Basics tab is the only tab you must complete; everything else can take defaults via Review + create.

Memory hook for naming: "3 to 24, lowercase + digits, unique on the planet." The name becomes part of every endpoint URL, which is why it must be globally unique and DNS-safe.

Choose the region to co-locate data with the apps that use it — accessing data from a different region incurs egress charges.

3. The decision that's permanent: kind + performance tier

Two linked choices define the account type. In the portal you pick Performance then a sub-type; in CLI/PowerShell you set them with the kind and sku/SkuName parameters.

Standard vs Premium

Account kinds (current)

The SKU encodes BOTH performance and redundancy in one string: Standard_GRS = standard tier + geo-redundant storage. (Redundancy itself is Sequence 3.)

Legacy kinds — recognize and avoid

Critical exam fact: you cannot change an account to a different kind after creation — the one exception is the one-way in-place upgrade from v1 / legacy Blob Storage → GPv2. To switch performance tier (Standard↔Premium) you must create a new account and copy the data.

4. The remaining creation tabs — what each decides

After Basics, the portal organizes everything else into tabs. Most can also be set after creation; a few are creation-only.

Default access tier (Hot vs Cool) is chosen here and applies to new blobs: Hot = frequently accessed (default); Cool = infrequently accessed. (The full four-tier story — Hot/Cool/Cold/Archive — is Sequence 10.)

5. Hierarchical namespace / Azure Data Lake Storage Gen2

On the Advanced tab, Enable hierarchical namespace (HNS) converts the account's flat blob namespace into a true file-system hierarchy of directories — this is what makes the account Azure Data Lake Storage Gen2.

• Supported on GPv2 and Premium block blobs; not on Premium file shares or page blobs.
• Ideal for analytics, big data, and HPC workloads (atomic directory operations, POSIX-style ACLs).
• In templates/Bicep the property is isHnsEnabled; in CLI --enable-hierarchical-namespace true; in PowerShell -EnableHierarchicalNamespace $true.

Like the kind, HNS is a creation-time decision for practical purposes — plan it up front.

6. Create it three ways

Azure portal

Navigate to Storage accounts → Create, fill in the Basics tab, optionally adjust other tabs, then Review + create.

Azure CLI

# 1. Resource group
az group create --name storage-resource-group --location eastus

# 2. Standard GPv2 account, read-access geo-redundant, hardened defaults
az storage account create \
  --name mystorageacct2026 \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_RAGRS \
  --kind StorageV2 \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false

Add --enable-hierarchical-namespace true to make it an ADLS Gen2 account.

Azure PowerShell

$rg = "storage-resource-group"; $loc = "eastus"
New-AzResourceGroup -Name $rg -Location $loc

New-AzStorageAccount -ResourceGroupName $rg `
  -Name mystorageacct2026 `
  -Location $loc `
  -SkuName Standard_RAGRS `
  -Kind StorageV2 `
  -AllowBlobPublicAccess $false `
  -MinimumTlsVersion TLS1_2

Add -EnableHierarchicalNamespace $true for ADLS Gen2. (Bicep/ARM/Terraform/azd are also supported but out of AZ-104 scope.)

Pattern to memorize: resource group first → then the account with --kind StorageV2 + a Standard_* SKU + secure defaults (TLS1_2, public access off).

7. Managing the account after creation

az storage account delete --name mystorageacct2026 --resource-group storage-resource-group

Deleting the resource group deletes the account and every other resource in it — handle with care.

Key takeaways

• N-K-P first, permanent forever: Name, Kind, Performance can't be changed after creation (only exception: v1/legacy-Blob → GPv2 one-way upgrade).
• Naming: 3–24 chars, lowercase + digits, globally unique — it's a DNS subdomain.
• Default & recommended = Standard general-purpose v2 (kind StorageV2). Premium = SSD, low latency, three flavors (block blobs / file shares / page blobs).
• SKU = performance + redundancy in one token (Standard_GRS).
• HNS turns the account into ADLS Gen2 — a creation-time choice, GPv2 or Premium block blobs only.
• Tabs: Basics (mandatory) → Advanced (HNS, default tier) → Networking (Seq 8) → Data protection (Seq 11/13) → Encryption (Seq 4) → Security (TLS 1.2 default) → Tags.
• Region drives billing, latency, and option availability; co-locate to avoid egress charges.
• Delete = data gone. Back up first.

Exercises

1. Recall: State the four naming rules for a storage account name.
2. Recall: Which kind value creates the default, recommended account type, and what does Microsoft call it?
3. Applied: A team needs the lowest possible latency for millions of small block blobs. Which performance tier and account kind do you choose, and what backs it physically?
4. Applied: You have a general-purpose v1 account and want access tiers and lifecycle management. What's the supported, in-place path — and what's the catch?
5. Scenario: A data-engineering group will run analytics with directory-level operations and POSIX ACLs over petabytes of data. Which single Advanced-tab toggle is essential, on which account kinds is it available, and why can't you defer the decision?
6. Scenario: A colleague created a Standard_LRS GPv2 account in West Europe but now needs it in East US with Premium performance. Can either change be done in place? What must they actually do?

Coming up next

Sequence 3 — Storage Redundancy & Disaster Recovery: the SKU's redundancy half explained — LRS, ZRS, GRS, GZRS and their read-access variants, plus failover.