# Azure CLI Cheat Sheet — Storage & Networking

> **Tool:** Azure CLI (az)
> **Category:** Cloud CLIs
> **Verified against:** Azure CLI 2.87.0, flags verified via `az <cmd> --help`, 2026-08-21
> **Official docs:** https://learn.microsoft.com/cli/azure

Storage accounts, blob containers/objects, and virtual network/subnet/NSG (network security group) setup.

## Storage accounts

```bash
az storage account create --resource-group my-rg --name mystorageaccount --sku Standard_LRS --location eastus
az storage account list --resource-group my-rg --output table
```

A storage account name must be globally unique across all of Azure (not just your subscription) — a `create` failing with a name-already-taken error is common and not a permissions problem.

## Blob containers

```bash
az storage container create --account-name mystorageaccount --name my-container --auth-mode login
az storage container list --account-name mystorageaccount --auth-mode login
```

`--auth-mode login` uses your `az login` identity (with the right RBAC role, e.g. Storage Blob Data Contributor) instead of a storage account key — prefer it over the legacy key-based auth mode for anything beyond a quick local test.

## Uploading and downloading blobs

```bash
az storage blob upload --account-name mystorageaccount --container-name my-container --name file.txt --file ./file.txt --auth-mode login
az storage blob download --account-name mystorageaccount --container-name my-container --name file.txt --file ./file.txt --auth-mode login
az storage blob list --account-name mystorageaccount --container-name my-container --auth-mode login --output table
```

## Blob lifecycle management policies

```bash
az storage account management-policy create \
  --account-name mystorageaccount --resource-group my-rg \
  --policy @lifecycle-policy.json
az storage account management-policy show --account-name mystorageaccount --resource-group my-rg
```

The `--policy` argument takes a JSON document (rules for tiering to cool/archive or deleting blobs after N days, matched by name prefix or blob index tags) — there's no flag-based way to define individual rules, you always author the full policy document and apply it in one call. See `learn.microsoft.com/azure/storage/blobs/lifecycle-management-overview` for the JSON schema.

## Generating a SAS (Shared Access Signature) token

```bash
az storage blob generate-sas \
  --account-name mystorageaccount --container-name my-container --name file.txt \
  --permissions r --expiry 2026-09-01T00:00Z --auth-mode login --as-user --full-uri
az storage account generate-sas \
  --account-name mystorageaccount \
  --services b --resource-types sco --permissions rwl --expiry 2026-09-01T00:00Z
```

`--auth-mode login --as-user` generates a *user delegation* SAS, signed with your Entra ID identity instead of a long-lived storage account key — this is the recommended approach since the resulting token is scoped to your own RBAC permissions and can't outlive a key rotation. `az storage account generate-sas` mints an account-level SAS instead of one scoped to a single blob/container — broader, so scope `--permissions`/`--resource-types` as tightly as the use case allows.

## Virtual networks and subnets

```bash
az network vnet create --resource-group my-rg --name my-vnet --address-prefixes 10.0.0.0/16
az network vnet subnet create --resource-group my-rg --vnet-name my-vnet --name my-subnet --address-prefixes 10.0.1.0/24
az network vnet list --resource-group my-rg --output table
```

## Network security groups (NSGs)

```bash
az network nsg create --resource-group my-rg --name my-nsg --location eastus
az network nsg rule create \
  --resource-group my-rg --nsg-name my-nsg --name allow-https \
  --priority 100 --access Allow --direction Inbound --protocol Tcp \
  --destination-port-ranges 443 --source-address-prefixes '*'
```

An NSG is attached to a subnet or a NIC, not to a VNet directly — the Azure equivalent of an AWS security group, but rule priority (lower number = evaluated first, first match wins) is explicit and load-bearing here in a way AWS security groups don't require.