Microsoft Azure
Beginner 13 min read Microsoft Azure

Azure Storage & Databases

Azure Storage is the platform's storage layer: a storage account holds Blob (object), File, Queue and Table services, and Azure Files serves SMB/NFS shares. Azure SQL Database is fully managed relational storage, and Cosmos DB is a globally distributed NoSQL database. Learn the services, redundancy tiers, and when to choose each.

storage accountBlobcontainerAzure FilesAzure SQLCosmos DBpartition keyredundancyLRSZRSaccess tier
Prerequisites: Azure Platform Overview
Introduction

What is this?

Azure Storage is Microsoft's managed storage platform. A storage account is the top-level container offering four services: Blob (object storage for files, images and backups), Files (managed SMB/NFS shares), Queue (message passing) and Table (key-value storage). On the database side, Azure SQL Database is a fully managed relational engine built on SQL Server, and Cosmos DB is a globally distributed, multi-model NoSQL database with SLA-backed latency. Redundancy options (LRS, ZRS, GRS, GZRS) define how many copies survive failures.

Motivation

Why do you need it?

  • Storage accounts hold the data layer of most Azure applications — backups, media, logs and static assets.
  • Blob plus Azure Files covers both object storage and file-share workloads on one platform.
  • Azure SQL removes the operational burden of running SQL Server, while Cosmos DB scales globally with sub-10ms reads.
  • Choosing between relational (Azure SQL) and NoSQL (Cosmos DB) is a core architecture and interview decision.
  • Redundancy and tiering decisions directly drive durability, latency and monthly cost.
Think about it

Mental model

Imagine

A warehouse with different sections

Think of

Azure Storage and databases

The warehouse is the storage account. One section shelves boxes by a catalog number (Blob), another holds shared folders on racks (Azure Files), a third is a conveyor belt of messages (Queue), and a small cabinet keeps simple key-value records (Table). Two offices run the databases: the SQL office keeps strict relational ledgers with joins, while the Cosmos office replicates every record to branch offices worldwide and answers any lookup in milliseconds from wherever you stand.

Mechanics

How it works

  • You create a storage account with a globally unique name, a region, a redundancy tier (LRS/ZRS/GRS/GZRS) and an access tier.
  • Blob containers hold blobs addressed by a path; hot, cool and archive tiers trade cost against latency.
  • Azure Files exposes file shares over SMB or NFS, mountable from Azure VMs and on-premises clients.
  • Azure SQL Database is provisioned or serverless, with automated backups, point-in-time restore and built-in high availability.
  • Cosmos DB replicates data across regions at a chosen consistency level and partitions items by a partition key for scale.

Serving data through a storage account and managed databases.

Create a storage account
Upload blobs to a container
Mount a file share
Azure SQL Database
Cosmos DB replicates
Redundancy guarantees durability
Reference

Key commands

az storage account create --name devopsstore2026 --resource-group rg-dev --sku Standard_ZRS --location eastus

Create a storage account with zone-redundant storage.

az storage container create --name logs --account-name devopsstore2026

Create a container inside the storage account.

az storage blob upload --account-name devopsstore2026 --container-name logs --file app.log --name app.log

Upload a file as a blob into a container.

az storage blob list --account-name devopsstore2026 --container-name logs -o table

List the blobs in a container.

az storage share create --account-name devopsstore2026 --name myshare --quota 100

Create an Azure Files share with a 100 GB quota.

az cosmosdb create --name mydb --resource-group rg-dev --locations regionName=eastus

Create a Cosmos DB account in a single region.

Hands-on

Examples

Create a storage account and upload a blob

Create a storage account and upload a blob
$ az storage account create --name devopsstore2026 --resource-group rg-dev \
    --sku Standard_ZRS --location eastus
{
  "id": "/subscriptions/.../storageAccounts/devopsstore2026",
  "primaryEndpoints": { "blob": "https://devopsstore2026.blob.core.windows.net/" },
  "sku": { "name": "Standard_ZRS" }
}
 
$ az storage blob upload --account-name devopsstore2026 \
    --container-name logs --name app.log --file app.log
Finished[#############################################################]  100.0000%

az storage account create provisions the account with its redundancy tier and endpoints. The blob upload targets a container and a blob name, so the file becomes addressable at https://devopsstore2026.blob.core.windows.net/logs/app.log. Containers, not the account, are the main organization and access-control boundary.

Real world

In production

  • Store backups, media and static assets in Blob with lifecycle rules that move data hot to cool to archive.
  • Use Azure Files to lift and shift on-premises file servers without changing applications.
  • Run Azure SQL Database in serverless mode for spiky dev workloads and provisioned tiers for steady production.
  • Put high-throughput, globally-read item data in Cosmos DB at the consistency level your app can tolerate.
  • Gate storage access with managed identities and RBAC rather than sharing account keys.
Guidelines

Best practices

  • Choose redundancy from your RPO: ZRS for in-region resilience, GRS or GZRS for regional disaster recovery.
  • Store account keys in Key Vault and prefer Entra ID and RBAC access to storage over shared keys.
  • Enable versioning, soft delete and access logs on critical containers.
  • Choose partition keys that spread Cosmos DB data evenly to avoid hot partitions.
  • Set retention and lifecycle policies from day one — storage costs grow silently.
Watch out

Common mistakes

  • Leaving every storage account on LRS and losing data to a regional outage.
  • Uploading secrets or credentials as blobs in a container with public access.
  • Using Blob storage where an SMB file share is what the application actually needs.
  • Choosing Cosmos DB for relational data and fighting to model joins and transactions.
  • Paying archive-tier prices for data that is read frequently enough to belong in the hot tier.
Root cause analysis

Common issues

Error
AuthorizationFailure: This request is not authorized to perform this operation
Root cause

The identity lacks RBAC on the container, or an invalid account key was used.

Fix

Assign the Storage Blob Data Contributor role and prefer Entra ID authentication over shared keys.

Error
The container 'logs' does not exist
Root cause

The command targeted the wrong account or container name.

Fix

List with az storage container list --account-name <name> and re-run with the exact name.

Error
Cosmos DB requests are throttled
Root cause

Request units are exceeded, or a hot partition concentrates traffic on one logical key.

Fix

Raise RU/s, enable autoscale, or redesign the partition key to spread load.

When things break

Debugging tips

  • Read the exact error code — 403 with AuthorizationFailure is RBAC, 404 NotFound is a missing container or blob.
  • Use az storage blob list to confirm the blob and its access tier before debugging access.
  • For Azure SQL connection issues, verify the server firewall allows your client IP or the app's subnet.
  • Monitor Cosmos DB's normalized request units to spot hot partitions.
  • Check storage metrics for throttling (ServerBusy) when operations suddenly slow down.
Interviews

Interview checkpoint

Practice

Hands-on lab

Simulate Storage Tiers and Lifecycle Management
20 min · beginner
In progress
Objectives
  • Build a storage-account directory structure with containers
  • Write blobs into hot and cool tiers
  • Simulate a geo-redundant copy of critical data
  • Move aged blobs to an archive tier and verify sizes

Simulate Storage Tiers and Lifecycle Management

20 min · beginner

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which Azure Storage service provides managed SMB/NFS file shares mountable by VMs?

2

A storage account name must be globally unique across all Azure customers.

3

A customer stored data on LRS and a regional outage destroyed the primary account. What would have prevented the loss?

Quick reference

Cheat sheet

Storage services
Storage accountContainer for all four services
BlobObject storage — files, images, backups
Azure FilesSMB/NFS file shares
QueueMessage passing between components
TableKey-value NoSQL store
Redundancy and databases
LRS / ZRS3 copies in one facility / across zones
GRS / GZRSGeo-secondary region / zone + geo
Access tierHot, cool, archive
Azure SQLManaged relational (SQL Server engine)
Cosmos DBGlobally distributed NoSQL
Go deeper

Official documentation

Azure Storage overview
docs
Storage account overview
docs
Introduction to Blob storage
docs
What is Azure Files?
docs
What is Azure SQL Database?
docs
What is Azure Cosmos DB?
docs