Storage account

What it is

A storage account is the top-level Azure resource that gives you a namespace of durable cloud storage. It exposes one or more Azure Storage data services (blobs, files, tables, queues) behind a set of shared settings: replication, performance tier, access tier, networking, and encryption.

Why it exists

Instead of managing disks or servers for data, a storage account is wholly managed: you choose a name, kind, redundancy, and these apply consistently across every data service inside it. It is the unit you deploy, secure, and pay for.

Key ideas

• Unique name across Azure: The account name (3–24 lowercase alphanumerics) forms a global URL, <name>.blob.core.windows.net, <name>.file.core.windows.net, <name>.queue.core.windows.net, <name>.table.core.windows.net.
• Kinds (account types) — determine which services + performance are available:
  • Standard general-purpose v2 (GPv2) — the default; all 4 services; hot/cool/cold tier (no archive at account level except blobs).
  • Premium block blobs — high IOPS block blobs, no archives.
  • Premium file shares — SMB/NFS shares on SSD (higher cost, lower latency).
  • Premium page blobs — for unmanaged VM disks / page blobs.
  • (Legacy) BlobStorage and GPv1 — historical; prefer GPv2.
• Settings are per-account: replication, access tier(s), performance tier, network/firewall, keys.
• Containers are inside accounts — an account holds containers (blobs), shares (files), tables, queues. You cannot change account type after creation (you can migrate data).

How it fits (diagram)

Exam notes

• One storage account name is globally unique, DNS-based, lowercase.
• Default redundancy is LRS; you pick on creation (can be changed later).
• Endpoint URLs are the 4 *.core.windows.net subdomains — memorize which service maps to which.
• Standard vs Premium is a performance decision, GPv2 vs others is a kind decision.
• Think of an account as the container; blobs/shares/tables/queues live inside it.

Related

redundancy-lrs-zrs-grs · access-tier · storage-performance · blob-storage · azure-files · storage-network-rule · storage-access-keys · sas-token

📘 Source: Microsoft Learn — Storage Account

Storage redundancy & replication

What it is

Azure Storage replication (redundancy) copies your data multiple times so it survives hardware failure, datacenter loss, or region-wide disasters. It is chosen per storage account and cannot be changed to a higher tier after creation (can be upgraded, not downgraded).

Why it exists

Durability (no data loss) and availability (data stays reachable) are the core promise of cloud storage. Replication determines your RPO/RTO in a disaster and your cost.

The redundancy ladder (memorize!)

Strategy	Copies	Where	Survives
LRS	3	1 datacenter	drive/rack/node failure only
ZRS	3	3 availability zones, same region	entire datacenter loss
GRS	3 + 3	primary region (LRS) + async copy to secondary region	region-wide disaster (RPO ~15 min)
GZRS	3 + 3	primary across 3 AZs (ZRS) + async secondary region	both AZ loss AND regional disaster

• RA-GRS / RA-GZRS add read access to the secondary copy (you can read locally redundant data in the secondary region even in normal operation).
• GRS/GZRS require the primary replica to be LRS/ZRS respectively.

How it fits (diagram)

Diagrams courtesy of Microsoft Learn / Azure docs: storage/common/storage-redundancy

Exam notes

• Default = LRS. Choose ZRS/GRS/GZRS explicitly.
• GRS is asynchronous to the secondary region → small RPO (~15 min). Only RA-* gives you readable secondary.
• LRS alone is not a full disaster strategy — it does not survive a datacenter loss.
• You can change redundancy after creating the account (upgrade paths exist); not all downgrades allowed.

Related

storage-account · storage-performance · blob-storage · azure-files

📘 Source: Microsoft Learn — Redundancy Lrs Zrs Grs

Storage performance tier (Standard vs Premium)

What it is

Together with kind, the performance tier chooses the backing hardware. Standard = magnetic/HDD-class (cost-effective, GB on-the-fly) and Premium = SSD-backed (high IOPS + throughput, low latency, priced higher). Standard is also called general-purpose; premium comes in account kinds like Premium block blobs and Premium file shares.

Why it exists

Not all workloads need SSD. Tiered per account = the sweet spot between cost and IO performance so you don’t overpay for a backup archive on premium SSD, nor starve a transactional database on HDD.

Key ideas

• Standard general-purpose v2 — the common default; supports blobs, files, tables, queues; auto access tiers.
• Premium block blob storage (PA_BLOB) — high performance for high-throughput block blobs (e.g., analytics, IoT); no access tiers.
• Premium file shares — SMB/NFS on SSD; for database/file workloads needing consistent low latency. Backed by premium SSD-managed data.
• Premium page blobs — foundation for unmanaged VM disks and premium SSD-powered managed disks (also used by VMs).
• Premium accounts generally have higher per-GB cost but better IOPS/latency; Standard is elastic.

How it fits (diagram)

Exam notes

• Performance = hardware (SSD vs magnetic); Kind = which services & features. Pick both at creation.
• Premium block blobs have no access tiers (hot-only).
• Premium file shares enable low-latency consistent IOPS for file workloads.
• VM disks: page blobs = unmanaged attached disks; premium = SSD-backed.

Related

storage-account · blob-storage · azure-files · redundancy-lrs-zrs-grs

📘 Source: Microsoft Learn — Storage Performance

Blob access tiers

What it is

Access tiers let you optimize blob storage cost by the expected access frequency. Hot = frequent, Cool = infrequent, Cold = rarely, Archive = long-term rarely-accessed. The tier trades storage cost against access/retrieval cost and latency.

Why it exists

Most data (‘unstructured/marketing/backup/compliance’) is accessed rarely once written. Paying full hot-tier price for it wastes money. Tiers align cost with access patterns.

The tiers

• Hot — high storage cost, near-zero retrieval, lowest latency. Default for new blobs.
• Cool — lower storage, higher access cost + minimum 30-day storage period. For data inactive >30 days.
• Cold (added 2024) — cheaper storage than cool, higher access cost + 90-day minimum. Rarely accessed.
• Archive — lowest storage cost, offline: you must rehydrate (move back to hot/cool) before reading, which takes hours. Min storage 180 days; not for GPv1.

Tier can be set at the storage-account default or per blob. Movement is automatic via lifecycle management rules (based on age, last-modified) or manually with az storage blob set-tier.

How it fits (diagram)

Exam notes

• Archive tiers are offline — no immediate read; reheat (rehydrate) required.
• Lifecycle management automates tier moves + deletion by rules (e.g., cool after 30d, archive after 90d, delete after 365d).
• Cool/cold/archive carry minimum storage-duration penalties if deleted early.
• Account-level default tier vs per-blob tier: per-blob wins.

Related

blob-storage · storage-account · storage-performance · immutable-storage

📘 Source: Microsoft Learn — Access Tier

Azure Blob Storage

What it is

Blob Storage is Azure’s object store for unstructured data — files, images, videos, backups, logs, documents. Data is stored in containers as blobs, addressable over HTTP(S) via REST: <account>.blob.core.windows.net/<container>/<blob>.

Why it exists

Applications need cheap, massively scalable storage for binary/unstructured payloads that isn’t tied to a filesystem or a database schema. Blobs support trillions of objects and PB-scale, with tiered pricing.

Key ideas

• Hierarchy: storage account → container (like a folder/drive root) → blob.
• Blob types:
  • Block blob — default; text/binaries; efficient for uploads (blocks can be uploaded in parallel).
  • Append blob — optimized for append (logging) — only append is allowed.
  • Page blob — random read/write, fixed 512-byte pages; backs unmanaged VM disks / VHDs.
• Access tiers (hot/cool/cold/archive) + lifecycle management automate cost.
• Features: snapshots, soft delete, versioning, immutability (immutable-storage), object replication (replicate blobs to another account), hierarchical namespace (for Data Lake Gen2).
• Concurrency: ETag / conditional headers for lease & overwrite safety.

How it fits (diagram)

Diagrams courtesy of Microsoft Learn / Azure docs: storage/blobs/storage-blobs-introduction

Exam notes

• Container = organizational unit for blobs — a single flat namespace + optional hierarchy.
• Know which blob type is for what: logs→append, VM disks→page, everything else→block.
• “Hot” is the default tier for new blobs.
• Azure Data Lake Storage Gen2 = blob storage with a hierarchical namespace.

Related

storage-account · access-tier · storage-performance · azure-tables · azure-queues · immutable-storage

📘 Source: Microsoft Learn — Blob Storage

Azure Files

What it is

Azure Files is a fully managed cloud file share you can mount from Windows, Linux, and macOS machines over SMB and NFS protocols — like a shared network drive (“<account>.file.core.windows.net<share>”).

Why it exists

When existing/lift-and-shift apps need a traditional file share (directories, ACLs, drive-letter mount) rather than object blobs, Azure Files gives a native SMB/NFS endpoint in the cloud with AD/Entra identity-based auth — no file server to run.

Key ideas

• Shares live in a storage account (standard file shares in GPv2; premium file shares in the premium kind).
• Mount everywhere via SMB 3.x / NFS v4.1; cache locally with Azure File Sync for l​​hybrid scenarios.
• Identity & authZ: on-prem AD DS, Microsoft Entra ID (Kerberos), or shared keys.
• Features: file share snapshots (read-only point-in-time copies), soft delete for file shares, restore from snapshots, cross-protocol vs SMB/NFS choice.
• vs Blob storage: blobs = object store/PaaS; Azure Files = shared-drive/file share for file-based apps.

How it fits (diagram)

Exam notes

• Azure Files = file shares (SMB/NFS); Azure Blob = object containers. Choose files when you need mountable shared directories.
• Snapshots = instant read-only backups of a share; soft delete recovers deleted shares.
• Premium file shares use SSD for consistent, low-latency IOPS.
• File Sync is the tool to extend an on-prem Windows file server to the cloud.

Related

storage-account · file-sync · blob-storage · azure-tables

📘 Source: Microsoft Learn — Azure Files

Azure File Sync

What it is

Azure File Sync keeps an on-premises Windows Server file server in sync with a cloud Azure file share. It centralizes your files in Azure while keeping a high-performance cache on the local server — a hybrid pattern for preferring cloud while staying on-prem.

Why it exists

You want cloud durability/central access but your line-of-business apps still need a local Windows file server mount + latency. File Sync gives one identity across local cloud-copied shares and enables the “primary data in Azure, cache on-prem” model.

Key ideas (the three pieces)

1. Storage Sync Service — the top-level Azure resource that orchestrates sync.
2. Sync group — defines what syncs to where (one cloud endpoint + one or more server endpoints).
3. Cloud endpoint / Server endpoint — an Azure file share (cloud) and a folder on a registered Windows Server (server).

• Cloud tiering: files can be tiered to the cloud — only a local pointer/heat-based stubs remain; cold files stay cloud-only and hydrate on demand, saving local disk.
• Windows Server Failover Clustering, Distributed File System (DFS), Azure Backup integrate with it.

How it fits (diagram)

Exam notes

• File Sync requires Windows Server server agents; it is not for Linux.
• Cloud tiering offloads cold files to Azure → local space is reclaimed, files recall on access.
• One sync group = one cloud endpoint + multiple server endpoints; many-to-one, one-to-many, multi-site.
• Purpose: centralize in Azure Files while caching locally — you do NOT need a second manual copy job.

Related

azure-files · storage-account · storage-browser

📘 Source: Microsoft Learn — File Sync

Azure Table storage

What it is

Azure Table storage is a NoSQL key-value / key-attribute store for structured, semi-structured data — billions of rows without a fixed schema. Each row (entity) has a partition key + row key (the composite primary key) and attribute columns.

Why it exists

Cost-effective, schema-less storage for structured app data (user profiles, device metadata, logs) that doesn’t need a full relational database. Tables scale out by partition for parallel throughput.

Key ideas

• Entity = row; attributes = columns; a partition groups entities by partition key for atomic operations & load distribution.
• Composite primary key: PartitionKey + RowKey (together unique).
• Schemaless — entities can have different attributes; via the OData/REST table service.
• Cheap per-GB — good for large structured datasets with simple lookups.
• Part of a storage account alongside blobs/queues/files; addressable at <account>.table.core.windows.net.
• Managed offering Azure Cosmos DB (Table API / Azure Table) can replace it for premium.

How it fits (diagram)

Exam notes

• PartitionKey + RowKey = primary key; partition = unit of scale & atomic batch.
• Tables are schema-less — use for structured, not relational.
• Contrast with queues (messages, transient) vs blobs (unstructured files).

Related

storage-account · azure-queues · blob-storage

📘 Source: Microsoft Learn — Azure Tables

Azure Queue storage

What it is

Azure Queue storage is a managed message queue for decoupling application components. Producers add messages to a queue; consumers retrieve and process them asynchronously — smoothing bursts and enabling retry/backpressure without tight coupling.

Why it exists

Web/app tiers often need to hand work to a background worker (e.g., “resize this image”, “send email”). A queue stores that work durably so the producer never blocks and the consumer can scale independently.

Key ideas

• Queue = ordered list of messages within a storage account; URL <account>.queue.core.windows.net/<queue>.
• Message lifecycle: add → becomes visible → consumer dequeues (invisible during visibility timeout) → process → delete. If not deleted before timeout, message becomes visible again (automatic retry).
• Max message size 64 KB (default); base64 optional for binary.
• Not strictly FIFO — no guaranteed ordering across consumers (contrast with Service Bus which offers FIFO/sessions for enterprise messaging).
• Pairing: a poison-message pattern lets misprocessable messages be parked after retries.

How it fits (diagram)

Diagrams courtesy of Microsoft Learn / Azure docs: storage/queues/storage-queues-introduction

Exam notes

• Queue = durable, transient, decoupling; Service Bus = advanced enterprise messaging (FIFO, sessions, topics).
• Message stays until consumed & deleted; visibility timeout governs retries.
• Max 64 KB message default; queues live in a storage account.
• Part of the same storage account namespaces as blobs/tables.

Related

storage-account · azure-tables · blob-storage

📘 Source: Microsoft Learn — Azure Queues

Storage access keys & connection strings

What it is

Each storage account has two 512-bit access keys (key1, key2). They are the master credentials granting full control over every data service in the account — equivalent to root. Tools/auth use them via Shared Key authorization or in connection strings.

Why it exists

You need a simple, high-privilege credential to authenticate admin/data operations against your storage account. Two keys let you rotate one without downtime (rotate key1 while clients still use key2, etc.).

Key ideas

• Full access: ownership-level read/write on blobs, files, tables, queues. Guard them like passwords.
• Connection string = account name + key (+ endpoint suffix) — what apps/tools (AzCopy, Storage Explorer) use.
• Regeneration immediately invalidates the old key — re-fetch before rotating to avoid breaking clients.
• Prefer lower-privilege access:
  • SAS tokens for scoped, time-limited delegated access (don’t share keys).
  • Managed identity / RBAC (Azure AD) — the modern preferred auth (e.g., Storage Blob Data Reader role).
• Rotate keys periodically; consider Microsoft Entra ID auth where possible.

How it fits (diagram)

Exam notes

• Two keys enable trouble-free rotation/regeneration.
• Keys = full control; SAS = scoped + expiring; Azure AD/RBAC = identity-based, best practice.
• Regenerating a key invalidates anything using it (including SAS issued from it in some models).
• Never embed keys in code — use managed identities or SAS.

Related

storage-account · sas-token · storage-network-rule · rbac · entraid

📘 Source: Microsoft Learn — Storage Access Keys

Shared Access Signature (SAS)

What it is

A Shared Access Signature (SAS) is a delegated, time-limited, scoped token granting access to a specific storage account/service/container/queue/share without exposing the account key. It’s a signed URI with permissions + expiry embedded in query params.

Why it exists

You need to let a client (a script, a partner, a web app) access a slice of storage for a limited time without handing over the master key. SAS is the least-privilege, revocable mechanism.

Types (compare)

• Account SAS — permissions across services (blob/file/table/queue) at account scope.
• Service SAS — scoped to one service/container/queue/share.
• User delegation SAS (blob) — signed with Azure AD, more secure (no key needed), only for blobs.
• Optionally governed by a stored access policy on a container/share for easier revocation.

What params a SAS URI carries

• Permissions (r/w/d/l…), start & expiry times, allowed IPs & protocol, allowed services/resource types (sv, sp, st/se, sig signature).
• sig is the HMAC signature proving the token wasn’t tampered with; key/identity used to create it.

How it fits (diagram)

Diagrams courtesy of Microsoft Learn / Azure docs: storage/common/storage-sas-overview

Exam notes

• 3 S’s to memorize: Sign (issuer needs permission to sign), Specify (permissions/expiry/scope/IPs), Send (anyone holding the token can use it until expiry).
• Regenerating the account key invalidates SAS created from it; user-delegation SAS is safer.
• Stored access policy gives central control/revocation vs standalone SAS.
• Minimize the blast radius: short expiry, least privilege, restrict IP/protocol.

Related

storage-access-keys · storage-account · storage-network-rule

📘 Source: Microsoft Learn — Sas Token

Storage firewall & network access (network rules)

What it is

Storage network rules control where data-plane traffic may come from. By default a storage account is publicly reachable; you can lock it down to Allow access from selected networks (specific VNets/subnets and IP ranges) or Disabled (no public endpoint).

Why it exists

Storage holds sensitive data. Restricting the network surface reduces attack/exfiltration risk and lets you enforce that only traffic from your VNets/on-prem trusted ranges can reach it.

Key ideas

• Public network access: All networks vs Selected networks vs Disabled.
• Virtual network rules — authorize specific VNet/subnets (via service endpoints or private endpoints).
• IP rules — allow specific public IP ranges (e.g., your office or Azure IPs).
• Private endpoints — assign a private IP inside your VNet to the storage account (or to specific subresources like blob/file), removing it from the public internet.
• Trusted Microsoft services exception lets Azure services (Backup, Log Analytics, AzCopy w/ managed identity) bypass the firewall when enabled.
• Applies at the storage account level; combined with SAS/keys/RBAC for defense-in-depth.

How it fits (diagram)

Exam notes

• Network rules are separate from authentication — they filter who can reach the endpoint, not what they may do.
• Private endpoint puts storage on a private IP in your VNet (most secure); service endpoint uses the public IP but restricted to the subnet.
• When locking down, remember the trusted services exception or your backups/AzCopy will fail.
• Restrict both the management and data planes where applicable.

Related

storage-account · sas-token · storage-access-keys

📘 Source: Microsoft Learn — Storage Network Rule

Immutable storage (WORM) for Azure Blob

What it is

Immutable storage makes blobs write-once, read-many (WORM): data can be created and read but cannot be modified or deleted for the configured period. It’s the Azure Storage compliance feature for regulatory retention (e.g., SEC 17a-4, FINRA, HIPAA).

Why it exists

Regulators require that certain records be stored unalterable and undeletable for a fixed time (to prevent tampering or malicious deletion). Immutability guarantees even a compromised admin account can’t purge the evidence during the retention window.

Key ideas

• Two forms of policy (applied at container or account-versioning level):
  1. Time-based retention — hold for N days; you can extend but NOT shorten/remove until expiry.
  2. Legal hold — no set duration; holds until explicitly cleared (applies to all blobs in scope).
• Modes:
  • Governance — enabled/disabled by privileged users (still “live” admin overrides allowed with Set-StorageBlobImmutabilityPolicy).
  • Compliance — irreversible; once locked, no one (even Microsoft) can reduce or remove it. Required to meet strict regulations.
• Works on top of blob versions/snapshots: blobs within scope can’t be overwritten/deleted until the policy lifts.
• Scope: container-level policy or account-level versioning immutability.

How it fits (diagram)

Diagrams courtesy of Microsoft Learn / Azure docs: storage/blobs/immutable-storage-overview

Exam notes

• WORM = immutable/unalterable during retention.
• Compliance-locked is bulletproof (cannot be undone); governance allows limited privileged overrides.
• Support via time-based retention and legal hold.
• Not for file shares by default — this is a blob (and account-versioning) capability.

Related

blob-storage · storage-account · access-tier

📘 Source: Microsoft Learn — Immutable Storage

AzCopy

What it is

AzCopy is a command-line utility for copying data to/from Azure Storage — blobs, files, and tables. It’s the primary tool for migrating/copying data at scale into and between storage accounts.

azcopy copy \\path\\file.txt https://<account>.blob.core.windows.net/<container>/ --sas-token=<...>

Why it exists

The portal and Storage Explorer are fine interactively, but migrations, ETL, and synchronization need a scriptable, high-throughput, resumable CLI — AzCopy is exactly that.

Key ideas

• Copy in any direction: on-prem ↔ storage, blob ↔ blob (same or different account), across tiers/containers, file shares.
• Auth options: SAS tokens, connection strings/keys, or Microsoft Entra ID (managed identity/--login). Best practice = Entra/Azure AD.
• azcopy copy (copy) vs azcopy sync (one-way mirror / incremental) — sync copies only differences (compare by name + last-modified/hash).
• Features: resumable/large-file parallel transfer, recursive --recursive, --include-pattern/--exclude, snapshot support, server-side copy vs local streaming.
• Runs on Windows, Linux, macOS; also available as AzCopy in the Storage browser and in azcopy container/Docker.
• Used heavily with SAS and paired with Storage Explorer for GUI operations.

How it fits (diagram)

destination (blob/file/table) with SAS or Entra auth —>

Exam notes

• azcopy sync = mirror (incremental, only diffs); azcopy copy = overwrite copy. Choose sync for ongoing one-way sync.
• Auth with SAS or Azure AD (Entra); keys/SAS in URI.
• For data migration into one storage account, AzCopy is the exam’s headline tool (with azcopy sync/copy), and Storage Explorer is the GUI companion.

Related

blob-storage · azure-files · storage-access-keys · sas-token · storage-browser

📘 Source: Microsoft Learn — Azcopy

Azure Storage browser & Storage Explorer

What it is

Storage browser is the graphical way to manage storage — available in the Azure portal (storage account → Storage browser) and as the standalone Azure Storage Explorer desktop app (and in VS Code / Azure CLI). It gives a point-and-click UI over blobs, file shares, queues, and tables.

Why it exists

For interactive/one-off data management (upload a file, create a share, inspect a queue) a GUI is faster and less error-prone than scripting. Storage Explorer is the desktop tool when you need it outside the portal.

Key ideas

• Portal Storage browser: browse/save blobs (containers), file shares, queues, and tables inside any storage account — upload/download/delete, view properties, generate SAS.
• Azure Storage Explorer (desktop app): standalone cross-platform client connecting to all storage services + emulator; supports AzCopy integration for large/bulk transfers, SAS-based access, cross-account copy.
• Works alongside azcopy (CLI/bulk) — Storage Explorer = graphical, AzCopy = scriptable.
• Sign in with Azure AD / Microsoft account or via connection strings / SAS.

How it fits (diagram)

Exam notes

• Storage browser (portal) and Storage Explorer are the GUI tools; AzCopy is the CLI bulk tool.
• Check “Use Azure Storage Explorer” unit — it’s how you visually manage shares/blobs.
• Both log in with Azure AD or a SAS/connection string.

Related

storage-account · blob-storage · azure-files · azure-queues · azcopy

📘 Source: Microsoft Learn — Storage Browser