Implement and manage storage

Three roles have the ability to both list and regenerate storage account keys: Storage Account Key Operator Service Role, Storage Account Contributor, and Reader and Data Access. The Storage Account Encryption Scope Contributor role specifically grants management of encryption scopes only — it does not grant key management capabilities.

When a user needs to upload files to blob storage through the Azure portal using their Entra ID credentials, two roles are required together. The Reader role provides visibility into the storage account within the portal (management plane). The Storage Blob Data Contributor role grants the actual ability to write blob data (data plane). Neither role alone is sufficient — Reader without Storage Blob Data Contributor gives portal access but no write permission; Storage Blob Data Contributor alone may not provide portal navigation.

When building a custom role to allow users to view storage account configuration without touching data or keys, the correct permission to include in the role definition is "Microsoft.Storage/storageAccounts/read". This grants read-only access to the storage account's configuration properties. The broader wildcard "Microsoft.Storage/storageAccounts/*" would also grant write and delete operations, violating least privilege. Data-plane paths like blobServices/containers/blobs/read refer to blob data access, not account configuration.

When a storage account has firewall rules that restrict access to specific VNets or IP ranges, certain first-party Microsoft services can still reach the account through a bypass mechanism. This is configured in ARM templates as "bypass": "AzureServices" in the networkAcls section. Services that benefit from this bypass include Azure Backup, Azure Site Recovery, Azure Event Grid, Azure Event Hubs, and Azure IoT Hub, among others. The complete list of trusted services is available in the Azure Storage firewall documentation.

• A service endpoint is enabled on a subnet (e.g., Microsoft.Storage).
• The storage account's firewall is then configured to allow that specific subnet.
• Traffic from the subnet reaches storage via the Azure backbone — the subnet's private IP becomes the source IP at the storage level.
• The storage account still has a public DNS name and public IP; the firewall is what restricts who can reach it.
• The Microsoft.Storage.Global endpoint variant extends this to cross-region storage access over the backbone.

Without a service endpoint policy, a subnet with a Microsoft.Storage service endpoint can reach any storage account in Azure. A service endpoint policy narrows this down so that the subnet can only communicate with specific, explicitly named storage accounts. This prevents lateral movement — for example, a compromised VM cannot exfiltrate data to an attacker's storage account even though the storage service endpoint is enabled.

• blobTypes — specifies which blob subtypes to include in the report. Valid values are blockBlob, appendBlob, and pageBlob. Note that pageBlob is not available for accounts with hierarchical namespace (Data Lake Gen2) enabled.
• prefixMatch — filters the report to include only blobs whose names begin with a specified prefix. The prefix is matched against the container name portion of the path. For example, to capture only blobs in containers whose names start with "finance", set prefixMatch to "finance" — not the full path, just the prefix string.
• schedule — controls how frequently the inventory report is generated. The two options are Daily and Weekly.
• objectType — determines whether the report inventories individual blob objects or container objects.
• format — the output can be Csv or Parquet. The report is always saved to a blob container within the same storage account.

• Both the source and destination accounts must be general-purpose v2 (StorageV2) or Premium Block Blob accounts. BlobStorage accounts are not supported.
• Blob versioning must be enabled on both the source and destination accounts.
• Change feed must be enabled on the source account so that Azure can track which blobs have changed and need to be replicated.
• Object replication is not supported on accounts with hierarchical namespace (Data Lake Gen2) enabled.
• Archive-tier blobs cannot be replicated — only Hot and Cool blobs are replicated.

When setting up object replication, you configure a replication policy that maps source containers to destination containers. The destination account needs a container to receive the replicated blobs. File shares, queues, and tables are not part of object replication — only blob containers participate. The replication policy is defined on the source, and the destination container must already exist before replication can begin.

• Stored Access Policies: a maximum of 5 stored access policies can be defined per container. This limit also applies to queues, tables, and file shares. For example, if a container already has 2 stored access policies, you can create up to 3 more — not 4 or 5 additional ones.
• Immutable time-based retention policy: a maximum of 1 time-based retention policy per container. If a container already has one time-based retention policy locked or unlocked, no additional time-based retention policies can be created for that container. A separate legal hold can coexist alongside the single time-based policy.

• Time-based retention policy: blobs are protected from modification and deletion for a fixed interval. The policy can be in an unlocked state (configurable) or a locked state (permanent — interval can only be increased, never shortened or deleted). Once locked, the policy cannot be removed until all blobs within it have outlived the retention period.
• Legal hold: blobs are protected indefinitely until the legal hold tag is explicitly cleared. There is no time period — it holds as long as the tag exists. Multiple legal hold tags can be applied to a single container simultaneously.

• If the client's IP address falls outside the allowed IP range specified in the SAS, all requests are denied regardless of permissions or timing.
• If the current time is past the SAS expiry date, the token is no longer valid and all requests are denied.
• If the client's IP is within range and the request is within the validity window, the client receives exactly the permissions encoded in the SAS — no more, no less.
• A SAS token cannot grant permissions that exceed those held by the user or key used to generate it.

• The setting is called Shared access signature (SAS) expiration policy and is configured in the storage account under Settings → Configuration.
• You set a maximum allowed SAS interval in days. When a user generates a SAS with a duration that exceeds this interval, a warning message is displayed in the Azure portal at the time of generation.
• This is a storage account-level configuration — not an Azure Policy, not a lifecycle management rule, and not a resource lock.
• In addition to the warning, you can configure the policy to block the generation of SAS tokens whose duration exceeds the threshold, actively denying out-of-policy requests rather than just warning.

• azcopy make <URL> — creates a new blob container, file share, queue, or Data Lake filesystem. The URL must use the correct service endpoint. For a blob container: https://account.blob.core.windows.net/containername. For a file share: https://account.file.core.windows.net/sharename. For a Data Lake filesystem: https://account.dfs.core.windows.net/filesystemname. There is no images endpoint — it does not exist.
• azcopy copy <source> <destination> --recursive — copies a local folder and all its contents to a destination blob container (or file share). The --recursive flag is required to include subdirectories.
• azcopy sync <source> <destination> — compares source and destination and transfers only files that have changed. This is for synchronisation, not initial bulk copy. The --snapshot flag is not a valid AzCopy sync option.
• The Azure CLI commands az storage blob copy start and az storage blob copy start-batch are for server-side blob copies within or between Azure storage accounts — they do not support copying from a local path like D:\Folder1.

• Port 445 (TCP) — SMB. Required for Azure Files drive mapping.
• Port 443 (TCP) — HTTPS. Used for Azure portal, REST APIs, and Azure Bastion.
• Port 3389 (TCP) — RDP. Used for Windows Remote Desktop connections.
• Port 22 (TCP) — SSH. Used for Linux remote access.
• Port 80 (TCP) — HTTP. Web traffic; not used for Azure Files.

To map a drive or reference an Azure file share in a script, the UNC path follows this format:

\\storageaccountname.file.core.windows.net\sharename

For example, a storage account named contosostorage with a share named data is referenced as \\contosostorage.file.core.windows.net\data. The account name appears first, followed by the fixed endpoint domain file.core.windows.net, and then the share name — not the other way around.

• Microsoft network routing (default) — traffic enters the Microsoft global WAN at the point of presence closest to the client's location and travels entirely over Microsoft's private backbone to reach the storage account. This minimises latency for the end user because the data traverses the internet for the shortest possible distance before entering Microsoft's fast private network.
• Internet routing — traffic travels over the public internet until it reaches the Azure region where the storage account is located, then enters Microsoft's network at the region edge. This can reduce Microsoft's egress costs and may be preferred for cost-sensitive workloads where latency is less critical.

When you need users to see only specific blobs based on their blob index tags — for example, restricting visibility to blobs tagged with a certain department — the correct solution is a role assignment condition (Azure ABAC), not a SAS token and not a stored access policy. A role assignment condition allows you to filter which blobs a user with, say, Storage Blob Data Reader can actually see, based on tag values.

VM backup always uses a Recovery Services vault. Azure Backup vault is a newer vault type designed for managed disks, blobs, PostgreSQL, and AKS backup — not for virtual machines. A backup policy created in an Azure Backup vault has no option for VM protection. When asked which vault to use for VM backup, the answer is always Recovery Services vault.

Each rule has two sections: actions (what happens to matching blobs) and filters (which blobs the rule applies to).

"actions": {
  "baseBlob": {
    "tierToCool": { "daysAfterModificationGreaterThan": 45 }
  }
},
"filters": {
  "blobTypes": ["blockBlob"],
  "prefixMatch": ["container1/"]
}

Lifecycle management tier-transition actions — tierToCool, tierToCold, and tierToArchive — only work on blockBlob type blobs. Append blobs and page blobs do not support access tier changes. However, delete actions in lifecycle rules can apply to all three blob types. When the action is tiering, the blobTypes filter must be set to ["blockBlob"].

• Performance tier (Standard vs Premium) — determined by the underlying storage hardware; Standard and Premium use different backends that cannot be switched.
• Account kind (StorageV2, BlobStorage, FileStorage, BlockBlobStorage) — the account type defines which services and features are available and is set permanently at creation.
• Infrastructure encryption — an additional layer of encryption applied at the hardware level. Must be enabled at creation time and cannot be enabled or disabled on an existing account.
• Premium account sub-type (Block Blobs, File Shares, or Page Blobs) — for Premium accounts, the storage sub-type is fixed at creation.

• Encryption key source — can switch between Microsoft-managed keys and customer-managed keys at any time after creation.
• Redundancy (replication) — LRS, GRS, ZRS, and GZRS can generally be changed after creation, subject to account kind and tier constraints.
• Default access tier (Hot vs Cool) — can be updated post-creation.
• Blob public access, HTTPS-only, TLS version — all mutable post-creation.
• Network rules and firewall settings — VNet rules and IP allowlists can be added, modified, or removed at any time.

• The storage account is registered with Azure Key Vault as a managed storage account. Key Vault is granted the Storage Account Key Operator Service Role on the storage account.
• Key Vault stores the active key as a managed secret and regenerates it according to the configured regeneration period (e.g., every 90 days).
• Applications retrieve the current key from Key Vault using the secret name — they always get the latest active key without needing to be updated when rotation occurs.
• This configuration is done in Key Vault, not in the storage account's settings directly.

• Azure Files (SMB) — the primary and most common persistent volume type for ACI. Mounts an Azure file share into the container's file system path.
• Azure Files (NFS) — available for Linux containers using the NFS protocol.
• gitRepo volumes — mounts a Git repository as a volume at container startup (read-only).
• emptyDir volumes — temporary in-memory storage shared between containers in the same container group; does not persist beyond the container group's lifetime.

• Data is replicated asynchronously to a secondary paired region. The secondary endpoint is always readable (unlike standard GRS, where the secondary is only accessible after failover).
• The secondary endpoint URL follows the format: accountname-secondary.blob.core.windows.net.
• Because replication is asynchronous, there is always the possibility of some data loss (RPO > 0) in a failover scenario.
• Both IAM permissions and SAS tokens generated against the primary endpoint also work against the secondary endpoint — they are the same account.

To fail over an RA-GRS storage account so that the secondary region becomes the new primary, you initiate a storage account failover from the Redundancy blade in the Azure portal (via the "Prepare for failover" button), or by running Invoke-AzStorageAccountFailover in PowerShell. This is a distinct operation — it is not a redundancy setting change in the dropdown and it cannot be triggered via IAM, access keys, or SAS configuration. After failover, the account becomes LRS at the secondary location; geo-redundancy must be re-configured if needed.

• "Microsoft.Storage/storageAccounts/read" — allows viewing the storage account's configuration properties only (least privilege for config viewing).
• "Microsoft.Storage/storageAccounts/*" — allows all actions on storage accounts including write and delete (not least privilege).
• "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read" — data-plane permission for reading individual blob data (not a management-plane permission for account configuration).