Why do I get an authorization error even though I created the account?

Management access and data access are separate. Assign yourself a data role such as Storage Blob Data Contributor and allow a few minutes for it to apply.

Should I use the storage account keys instead?

Keys are simpler but powerful, and anyone holding one has full access. Prefer Entra authentication and role assignments, and use keys only when a tool requires them, rotating them regularly.

Azure Blob Storage Basics: Accounts, Containers, and Secure Access

Introduction

Azure Blob Storage is Azure's object storage service. Data lives in blobs, inside containers, inside a storage account. A common stumbling block is permissions: owning the account is not enough to read or write its data. This lesson creates the pieces, assigns the correct role, and moves files using Microsoft Entra sign-in instead of account keys.

Prerequisites

Azure CLI signed in
A resource group (previous lesson)

Step-by-Step Guide

Step 1: Understand the structure

A storage account is the top-level resource and provides a unique namespace. Its name must be globally unique, 3 to 24 characters, using only lowercase letters and numbers. Inside it, containers group blobs like top-level folders, and a blob is the stored file. The redundancy option, such as locally redundant (LRS), zone redundant (ZRS), or geo redundant (GRS), controls how many copies exist and where, and it affects price.

Step 2: Create the storage account

Creating resources is a management operation and uses your signed-in Entra credentials automatically. Replace the name with your own unique one.

az group create --name rg-demo --location westeurope

az storage account create \
  --name stdemo12345 \
  --resource-group rg-demo \
  --location westeurope \
  --sku Standard_LRS

Step 3: Give yourself a data role

Being the account owner does not let you read or write blob data. You need a data role such as Storage Blob Data Contributor, assigned at the scope of the storage account. Role assignments can take a few minutes to take effect. These commands use bash syntax; in PowerShell, assign variables like $STORAGE_ID = az storage account show ... --output tsv.

STORAGE_ID=$(az storage account show --name stdemo12345 --resource-group rg-demo --query id --output tsv)
USER_ID=$(az ad signed-in-user show --query id --output tsv)

az role assignment create \
  --role "Storage Blob Data Contributor" \
  --assignee-object-id "$USER_ID" \
  --assignee-principal-type User \
  --scope "$STORAGE_ID"

Step 4: Create a container and upload a blob

Data operations accept an authentication mode. Using login makes the CLI use your Entra identity instead of an account key, which is the safer choice because keys grant full access and are easy to leak. If you get an authorization error right after assigning the role, wait a few minutes and retry.

echo "hello cloud" > hello.txt

az storage container create \
  --account-name stdemo12345 --name files --auth-mode login

az storage blob upload \
  --account-name stdemo12345 --container-name files \
  --name hello.txt --file hello.txt --auth-mode login

Step 5: List, download, and clean up

List the blobs and download one to verify. When you are done, delete the resource group to remove the storage account and everything in it.

az storage blob list \
  --account-name stdemo12345 --container-name files \
  --output table --auth-mode login

az storage blob download \
  --account-name stdemo12345 --container-name files \
  --name hello.txt --file downloaded.txt --auth-mode login

az group delete --name rg-demo --yes --no-wait

FAQs

Why do I get an authorization error even though I created the account?: Management access and data access are separate. Assign yourself a data role such as Storage Blob Data Contributor and allow a few minutes for it to apply.
Should I use the storage account keys instead?: Keys are simpler but powerful, and anyone holding one has full access. Prefer Entra authentication and role assignments, and use keys only when a tool requires them, rotating them regularly.

Summary

Create a uniquely named storage account, assign a data role at its scope, then create containers and upload blobs with --auth-mode login. Keep keys out of scripts and delete the resource group when finished.