2.1 — Foundation

Storage Account

A Storage Account is the top-level container for all Azure storage services. One account = one namespace, one set of access keys, one firewall, one redundancy configuration. Everything storage-related sits inside it.

A Storage Account is not storage itself. It is the container, the envelope, the building that holds your storage. Inside one storage account you can have blob containers, file shares, queues, and tables, all completely different storage types, managed through one account with one set of access keys, one firewall, and one redundancy configuration. Think of it as a warehouse building. The building has one address, your storage account name, which becomes a globally unique DNS prefix like kubestgprod.blob.core.windows.net. The building has one security system, your account keys and firewall rules. Inside are different rooms, the blob room for unstructured data, the files room for shared drives, the queue room for messages, the table room for key-value data. The name is tested on almost every exam. Between 3 and 24 characters. Lowercase letters and numbers only. No hyphens, no underscores, no uppercase. Globally unique because it becomes part of a public DNS hostname. For account type, you almost always want GPv2, General Purpose version 2. It supports all four storage services, all access tiers, and all redundancy options. It is the default and right choice 95 percent of the time. One account equals one redundancy setting. You cannot have some blobs in LRS and others in GRS inside the same account. The redundancy choice is account-wide. That is why teams often use multiple storage accounts, hot operational data in a cheaper LRS account, compliance archives in a GRS account. The two account keys are like master keys. Anyone with either key has complete access to everything in the account. No expiry, no scope limitation. Treat them like the root password. Never put them in application code. Use SAS tokens for scoped access or Managed Identity for zero-credential access.. Remember: Storage Account is the container, not the data. Name must be 3 to 24 characters, lowercase and numbers, globally unique. GPv2 is your default. One account equals one redundancy, one firewall, one set of keys.

📖 Storage Account — Complete Explanation

Every piece of data in Azure Blob, Azure Files, Azure Queues, or Azure Tables lives inside a Storage Account. It's the top-level container — not the data itself, but the envelope that holds everything.

One account = one namespace. Your storage account name becomes the globally unique DNS prefix: kubestgprod.blob.core.windows.net. This is why names must be globally unique — two storage accounts cannot share a public hostname.

One account = one set of keys. There are exactly two account keys (Key1 and Key2). Anyone with either key has full access to everything inside — all blobs, all files, all queues. This is why you almost never use account keys directly. Instead you use SAS tokens (scoped, time-limited) or Managed Identity (no keys involved).

One account = one firewall. Storage firewall rules apply at the account level, not per container. If you restrict to a VNet subnet, that restriction applies to all blobs, files, and queues in that account.

One account = one redundancy configuration. You can't have some blobs in LRS and others in GRS inside the same account. The redundancy choice is account-wide. This is why large organisations often have multiple storage accounts — one for hot operational data (LRS, cheaper) and one for compliance archives (GRS, more durable).

🏭

The Metaphor

A Storage Account is like a warehouse building. The building has one address (endpoint), one security system (access keys + firewall), and one backup policy (redundancy). Inside the building are different rooms: the Blob room (open shelves — any box, any size), the Files room (filing cabinets — familiar Windows share), the Queue room (conveyor belt — messages in order), and the Table room (index cards — simple key-value data).

Storage Account — Complete Architecture

Storage Account Types

Type	Services	Access Tiers	Redundancy	Use
GPv2 (General Purpose v2)	Blob, Files, Queue, Table	Hot/Cool/Cold/Archive	All options	DEFAULT — always use this
Premium Block Blob	Blob ONLY	Always Hot	LRS / ZRS only	IoT telemetry, analytics, low latency <1ms
Premium File Shares	Files ONLY	N/A	LRS / ZRS only	High-performance SMB file shares
GPv1 (legacy)	All	None	All options	Avoid — upgrade to GPv2

💡

Kube context

For Kube IoT sensor data (high write throughput, sub-millisecond latency required): Premium Block Blob. For general config files, reports, exports: GPv2. Premium cannot have Archive tier — all data stays Hot.

Naming Rules — Exam Tested

Storage Account Naming

3–24 Characters · Lowercase + Numbers Only · Globally Unique

Valid: kubestgprod, iotdata2026, kiran123storage

Invalid: Kube-Storage (has uppercase + hyphen), st (too short), a-very-long-storage-account-name-that-exceeds-24 (too long)

Why globally unique: the storage account name becomes part of the public DNS endpoint (name.blob.core.windows.net). Two accounts cannot share a DNS name.

⚠️

Most Failed Naming Exam Questions

kube-storage — INVALID (has hyphen)
KubeStorage — INVALID (uppercase letters)
ps — INVALID (only 2 chars, minimum is 3)
Common trap: they give you 4 names and ask which is valid — look for hyphens and capitals first.

2.2 — Durability

Redundancy Options

MS Docs

Azure replicates your data automatically. You choose HOW MANY copies and WHERE. More geographic spread = higher durability = higher cost.

💾

The Metaphor

LRS: 3 copies in the same room. Room burns down → all gone.
ZRS: 3 copies in 3 different buildings (zones) in the same city. City floods → all gone.
GRS: 3 copies in your city + 3 copies in another city 500km away. Your city destroyed → second city has it.
GZRS: Best of both — 3 copies across 3 buildings in your city AND 3 in another city.

Redundancy — Visual Comparison

SKU	Copies	Zones	Regions	Read Secondary	Data stays in 1 region?
LRS	3	1	1	✗	✓ Yes
ZRS	3	3	1	✗	✓ Yes
GRS	6	1	2	Failover only	✗ No
GZRS	6	3	2	Failover only	✗ No
RA-GRS	6	1	2	✓ Always	✗ No
RA-GZRS	6	3	2	✓ Always	✗ No

⚠️

Premium Storage + Redundancy Limitation

Premium Block Blob and Premium File Shares only support LRS or ZRS. No GRS, no RA-GRS. If compliance requires geo-redundancy AND you need premium performance — you cannot have both in a single account. Use GPv2 GRS for compliance or accept LRS for premium.

📋

Scenario → Answer Map

"Data MUST stay in one region (compliance/sovereignty)" → LRS or ZRS only
"Survive complete regional outage" → GRS or GZRS
"Read from secondary during normal operations" → RA-GRS or RA-GZRS
"Cheapest possible" → LRS
"IoT data, highest write throughput" → Premium Block Blob (LRS)

2.3 — Blob Storage

Blob Storage

MS Docs

Blob = Binary Large OBject. Unstructured data — any format, any size. The workhorse of Azure storage. IoT sensor data, images, videos, backups, logs — all go here.

Three Blob Types

Blob Types — Write Patterns

Access Tiers — Cost vs Access Speed

MS Docs

📦

The Metaphor

Hot = items on your desk. Instant access, most expensive real estate.
Cool = items in a nearby filing cabinet. Still accessible, cheaper space.
Cold = items in the office storeroom. Rarely needed, cheaper rent.
Archive = items in an off-site warehouse. Cheapest storage, but you need to order them and wait for delivery (rehydration).

Access Tiers — Storage Cost vs Access Cost Tradeoff

⚠️

Archive Rehydration — Exam Always Tests This

Cannot read Archive blobs directly — get error 409 BlobArchived.
Must rehydrate first (change tier to Hot or Cool):
Standard priority: up to 15 hours — cheaper
High priority: under 1 hour — costs more, for urgent recovery

Early deletion penalty: Move blob to Archive at day 1, then delete at day 50 — you still pay for 180 days. Same for Cool (30 days) and Cold (90 days). Azure charges the MINIMUM duration regardless of actual time stored.

Lifecycle Management Policy

Automated Tier Movement

Set Rules Once — Azure Moves Blobs Automatically

Lifecycle policies define: IF blob is X days old AND matches filters → THEN move to tier or delete.

Example For Kube IoT sensor data:
Day 0–30: Hot (active queries)
Day 30–90: Cool (occasional access)
Day 90–365: Archive (compliance)
Day 365: Delete

Important: Policies run ONCE PER DAY. Changes take up to 24 hours to apply. Not real-time. New policy can take up to 24 hours before its first evaluation.

JSON — Lifecycle Policy (Kube platform Data)

{
  "rules": [
    {
      "name": "iot-data-lifecycle",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["sensor-data/"]  // only this folder
        },
        "actions": {
          "baseBlob": {
            "tierToCool":    { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
            "delete":         { "daysAfterModificationGreaterThan": 365 }
          },
          "snapshot": {
            "delete": { "daysAfterCreationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

# Apply via CLI
az storage account management-policy create \
  --account-name kubestgprod \
  --resource-group RG-Kube-Prod \
  --policy @lifecycle-policy.json

Soft Delete & WORM Immutability

Soft Delete

Deleted but Recoverable

When enabled, deleted blobs go to a soft-deleted state for 1–365 days (you configure).

Two separate settings (exam important):
Blob soft delete: protects individual blobs
Container soft delete: protects entire containers

Must enable BOTH separately. Enabling blob soft delete does NOT protect containers and vice versa.

Immutability / WORM

Write Once, Read Many

Blobs in immutable state cannot be modified or deleted for the retention period.

Two types:
Time-based retention: locked for defined period (e.g. 7 years)
Legal hold: locked indefinitely until hold removed

Once a policy is locked (not just set): even admins cannot remove it. Required for SEC 17a-4 compliance.

Versioning & Snapshots

Feature	How It Works	Exam Key Point
Blob Versioning	Every PUT/overwrite creates new version automatically	Recover previous version of overwritten blob
Blob Snapshot	Point-in-time read-only copy you trigger manually	Must be manually created; doesn't auto-capture changes
Object Replication	Async copy of blobs from source to dest storage account	Requires versioning enabled on both accounts

2.4 — File Shares

Azure Files

MS Docs

Azure Files provides fully managed file shares accessible via SMB or NFS — the same protocol as Windows shared drives. Lift-and-shift file servers to cloud without changing how apps access them.

Azure Files is Microsoft's managed file share service. The key insight: it works exactly like the Windows shared drives you already know, but instead of a file server in a cupboard, it is a fully managed cloud service. When you mount an Azure File Share, it appears as a drive letter on Windows or a mount point on Linux. Applications do not know they are talking to the cloud. They think they are using a local network drive. Zero application changes when migrating from on-premises file servers. Two protocols. SMB, Server Message Block, is the Windows file sharing protocol running on port 445. Azure Files supports SMB 3.0 with encryption in transit. You can mount from Windows, Linux, and macOS. NFS, Network File System, is the Linux world's protocol running on port 2049. Azure Files supports NFS 4.1, but only on Premium tier accounts and only for Linux clients. The most common real-world problem: port 445 is blocked by many internet service providers and corporate firewalls. If someone tries to mount from home, they often fail silently. The fix is either VPN to the corporate network first, or use Azure File Sync. Azure File Sync installs an agent on your Windows Server. The agent creates a bidirectional sync between a local folder and an Azure File Share. All files exist in Azure at all times as the source of truth. On the local server, cold files are replaced with lightweight placeholders that stream from Azure transparently when you open them. This is called cloud tiering. Your server has a small fast SSD with only the hot files, while the full dataset lives in Azure. Fast local performance for active files, cloud economics for everything else, Azure durability for disaster recovery. For authentication: on-premises AD DS, Entra ID Kerberos, or Entra Domain Services.. Remember: Azure Files is managed SMB or NFS. Port 445 is often blocked, use VPN or File Sync. File Sync installs an agent on Windows Server and enables cloud tiering. Authentication supports on-premises AD, Entra ID Kerberos, and Entra Domain Services.

🗂️

The Metaphor

Azure Files is like your office's shared network drive (\\server\shared) — but instead of a physical server in the cupboard, Microsoft runs it. Your Windows laptop maps it as Z:, your Linux VM mounts it at /mnt/share. Both see the same files. No server to patch, no disk to replace, no backup to configure.

Feature	SMB (Standard)	NFS (Premium only)
Protocol	SMB 3.0 / 2.1	NFS 4.1
OS	Windows, Linux, macOS	Linux only
Storage tier	Standard GPv2	Premium File Shares only
Port	445 (often blocked by ISPs)	2049
Auth	AD DS / Entra ID / storage key	Storage key only
Encryption	In-transit (TLS)	In-transit NOT supported

⚠️

Port 445 Blocked at Home — Most Common Azure Files Issue

Many ISPs and home routers block TCP port 445 (SMB) as an anti-malware measure. Symptom: Azure file share mounts fine in office, fails at home.

Fix options: (1) Connect via VPN to corporate network, then mount. (2) Use Azure File Sync with local cache instead of direct mount. (3) Use Azure Bastion/Jump box to access from within the VNet.

Azure File Sync

🔄

The Metaphor

Azure File Sync turns your Windows Server into a local cache of the Azure file share. Hot files stay on local SSD (fast access). Cold files exist only in Azure (cloud tiering). When someone opens a cold file — it streams down transparently. Like Google Drive File Stream, but for enterprise file servers.

Azure File Sync — Bidirectional Sync Architecture

Blobfuse2

Mount Blob Container as Linux Filesystem

Blobfuse2 = a FUSE (Filesystem in Userspace) driver that mounts a Blob container as a Linux directory.

Your app reads/writes files normally (/mnt/blobdata/sensor.json) — under the hood it's actually reading/writing Azure Blob over HTTPS.

Compare: Azure File Sync = bidirectional sync with local cache. Blobfuse2 = direct mount, no local copy, every read/write goes to Azure. Different use cases.

Use: ML training jobs accessing large datasets, Linux apps that expect a filesystem path but data lives in Blob.

2.5 — Security

Access & Security

MS Docs

Four ways to access Azure Storage. Choose based on how much access you need to grant, to whom, and for how long.

How you secure access to Azure Storage is where most security incidents begin. Not from sophisticated attacks, but from mismanaged keys and overly permissive access. Four ways to control access: account keys, Shared Access Signatures, Entra ID, and network controls. Account keys are master keys. There are exactly two. Whoever has either key has complete unrestricted access to everything in that storage account. No expiry. No scope limitation. These must never appear in application code, environment variables, or source control. Shared Access Signatures, SAS tokens, are the right tool for most scenarios. A SAS is a URL granting specific scoped time-limited access. Read access only, to this specific container, for the next two hours, only from this IP address. Far safer than an account key. Three types of SAS. Account SAS covers all services, signed by account key. Service SAS covers one service, also signed by account key. User Delegation SAS is the most secure, signed by an Entra ID credential, not the account key. When. the exam asks for the most secure SAS type, the answer is always User Delegation SAS. Critical exam scenario: how do you revoke a SAS before it expires? If the SAS is backed by a Stored Access Policy, delete the policy and every SAS referencing it is immediately invalidated. If the SAS has no stored access policy, your only option is rotating the account key that signed it, which invalidates every SAS signed by that key, including ones used by other applications. Always back SAS tokens with Stored Access Policies. Entra ID authentication uses RBAC roles like Storage Blob Data Reader directly assigned to identities. For VM applications, use Managed Identity. No credentials in code at all. Network controls: IP rules, Service Endpoints requiring two steps, or Private Endpoints giving the storage account a private IP inside your VNet.. Remember: Account keys are master keys, treat accordingly. User Delegation SAS is most secure. Stored Access Policy is the only way to revoke SAS without rotating the key.

SAS Tokens — Shared Access Signatures

🎟️

The Metaphor

Your account key is a master key that opens everything forever. You'd never hand that to a contractor.

A SAS token is a scoped, time-limited visitor pass: "You can enter the Blob room only, read files only, for the next 2 hours, only from this IP address." When it expires — gone. No need to change the master key.

SAS Token Types — Security Ranking

Animated — SAS Revocation: With Policy vs Without Policy

⚠️

How to REVOKE a SAS Token — Critical Exam Question

If Stored Access Policy exists: Delete the policy → SAS immediately revoked ✅ (fastest, no impact on other apps)

If raw SAS (no policy): Only option is rotate the account key → ALL SAS tokens signed by that key are invalidated → breaks other apps using same key ⚠️

Best practice: Always back SAS tokens with a Stored Access Policy for easy, targeted revocation. One policy can control many SAS tokens.

          
          Azure CLI — Generate SAS + Stored Access Policy
        
# Create Stored Access Policy on container
az storage container policy create \
  --account-name kubestgprod \
  --container-name sensor-data \
  --name "read-policy-2026" \
  --permissions r \
  --expiry "2026-12-31"

# Generate SAS backed by that policy
az storage container generate-sas \
  --account-name kubestgprod \
  --name sensor-data \
  --policy-name "read-policy-2026" \
  --output tsv

# Revoke: just delete the policy
az storage container policy delete \
  --account-name kubestgprod \
  --container-name sensor-data \
  --name "read-policy-2026"
# SAS tokens backed by this policy now INVALID ✅

Storage Firewall & Virtual Network Access

Method	What It Does	Cost	Traffic Path	On-Prem Access
No restriction	Storage accessible from anywhere (default)	Free	Public internet	✓
IP firewall rules	Allow specific public IPs only	Free	Public internet from allowed IPs	✓ if IP listed
Service Endpoint	VNet traffic via MS backbone, restrict to subnet	Free	VNet → MS backbone → Storage public IP	✗ Cannot use
Private Endpoint	Storage gets private IP inside your VNet	Hourly + data	Stays entirely in VNet	✓ Via VPN/ER

⚠️

Service Endpoint Requires TWO Steps — Most Missed

Step 1: Enable Service Endpoint (Microsoft.Storage) on the VM's subnet
Step 2: Add VNet/subnet rule in Storage Account firewall → Selected Networks → Add VNet

Step 1 alone = VMs route via MS backbone but Storage still accepts traffic from anywhere.
Step 2 alone (without Step 1) = Rule exists but traffic still routes over internet.
Both required for private-backbone + restricted access.

Identity-Based Access for Azure Files

Azure Files — Auth Options

Share-Level + File/Dir Level Permissions

Azure Files supports identity-based access — no storage key needed:

On-premises AD DS: join storage account to on-prem AD, use Windows NTFS permissions + SMB ACLs
Entra ID Kerberos: for cloud-only (no on-prem DC needed), hybrid identities
Entra Domain Services: Azure-managed AD DS

Two layers of permissions:
Share-level RBAC: Storage File Data SMB Share Contributor/Reader
Directory/file NTFS ACLs: granular file-level permissions via Windows File Explorer or icacls

2.6 — Migration

Data Transfer & Migration Tools

MS Docs

Tool	Direction	Speed	Best For	Key Fact
AzCopy	Local↔Azure or Azure↔Azure	Fast (parallel)	Scripted bulk transfers, storage-to-storage copy	No local download on account-to-account copy
Storage Explorer	GUI tool	Medium	Ad-hoc management, browsing, small transfers	Desktop app — free download
Azure Import/Export	Physical disk to/from Azure	Ship days	When internet is too slow for data volume	You ship drives to MS datacenter
Data Box	Physical appliance	Ship days	80TB–1EB offline transfer	MS ships you a device, you fill it, ship back
Data Box Heavy	Physical appliance	Ship days	1EB+ transfers	Largest — 770TB usable capacity per device
Azure File Sync	On-prem server↔Azure Files	Continuous	Lift-and-shift + hybrid file servers	Bidirectional — NOT one-way like AzCopy

📋

AzCopy vs Azure File Sync — Key Difference

AzCopy: one-time or scheduled one-way copy. Not continuous. CLI-based.
Azure File Sync: continuous bidirectional sync with local caching. Server-based agent.

Exam scenario: "Copy 500GB from storage account A to storage account B" → AzCopy
Exam scenario: "Windows file server needs to sync with Azure Files ongoing" → Azure File Sync

          
          AzCopy — Key Commands
        
# Copy local folder to Blob container
azcopy copy 'C:\sensor-data\*' \
  'https://kubestgprod.blob.core.windows.net/sensor-data?<SAS>' \
  --recursive

# Copy between two storage accounts (no local download)
azcopy copy \
  'https://source.blob.core.windows.net/container?<SAS>' \
  'https://dest.blob.core.windows.net/container?<SAS>' \
  --recursive

# Sync (like rsync — only copies changed/new files)
azcopy sync \
  'C:\reports' \
  'https://kubestgprod.blob.core.windows.net/reports?<SAS>' \
  --delete-destination true

# Authenticate with Managed Identity (recommended)
azcopy login --identity
# Then copy without SAS token
azcopy copy 'source' 'destination'

Exam Prep

Phase 2 — Exam Q&A

Exam Guide

Click to reveal. Based on real AZ-104 exam patterns from last 2–3 years.

Q A company needs to store 7 years of IoT sensor logs for compliance. The data is never accessed after 90 days. Minimize cost. What storage tier and settings?

ANSWER

GPv2 storage account + Archive tier after 90 days + Lifecycle Management Policy.

Configure lifecycle rule: move to Cool at 30 days, Archive at 90 days, delete at 7 years (2555 days).
Also enable WORM immutability policy (locked) if regulatory compliance requires data cannot be modified/deleted during retention period (e.g., SEC 17a-4).

⚠️ Trap: if using Archive, you cannot read data directly. Any compliance read access requires rehydration (up to 15 hours). Factor this into SLA planning.

Q A storage account is shared with an external partner via SAS token. The partner's credentials were compromised. The SAS has no Stored Access Policy. How do you revoke access immediately?

ANSWER

Rotate the storage account key that was used to sign the SAS token.

This immediately invalidates ALL SAS tokens signed by that key. Side effect: any other app using that key or SAS tokens from it will also break — must update those apps with new key/SAS.

Lesson: Always create SAS tokens backed by Stored Access Policy. Then you can delete the policy to revoke specific SAS without affecting others.

Q A VM cannot access Azure Storage even though a Service Endpoint is configured on the subnet. What is the most likely missing step?

ANSWER

Storage Account firewall not configured to allow the VNet/subnet.

Service Endpoint has 2 required steps:
✅ Step 1 done: Service Endpoint enabled on subnet
❌ Step 2 missing: Storage Account → Networking → Selected Networks → Add the VNet and subnet

Without Step 2, storage still accepts traffic from everywhere (default allow) but the Service Endpoint provides no restriction OR the firewall may be set to deny all, blocking the VM.

Q You need to grant an external vendor read access to specific blobs for 48 hours. The most secure method that doesn't use account keys?

ANSWER

User Delegation SAS token (signed by Entra ID credentials, Blob only, expiry 48 hours).

User Delegation SAS = most secure because:
1. Not signed by account key (key not exposed)
2. Backed by Entra ID identity (audited)
3. Max validity = 7 days (capped by Azure)
4. Revocable by revoking the delegating user's permissions

⚠️ User Delegation SAS works for Blob service only. Not supported for Files, Queue, or Table.

Q An admin deleted critical production blobs by mistake. Soft delete was NOT enabled. Is recovery possible?

ANSWER

If versioning was enabled: yes — restore from previous version. If soft delete AND versioning both disabled: no recovery possible.

Recovery options in order of preference:
1. Blob versioning: previous versions available if enabled
2. Azure Backup: operational backup for Blob (requires Backup Vault)
3. Object Replication: if configured to another account, copies exist there
4. No options if none of the above were configured

Best practice: enable both soft delete AND versioning on production storage.

Q Which is correct for a storage account name? (a) Kube-Storage (b) kubestorage2026 (c) ps (d) kube_storage

ANSWER

(b) kubestorage2026

(a) INVALID — uppercase P + hyphen
(b) VALID — lowercase letters and numbers, 22 chars ✅
(c) INVALID — only 2 chars (minimum 3)
(d) INVALID — underscore not allowed

Rules: 3–24 chars · lowercase letters and numbers ONLY · no hyphens · no underscores · globally unique

Q A company needs storage that survives complete regional outage AND allows reading from secondary region without waiting for failover. What redundancy option?

ANSWER

RA-GRS (Read-Access Geo Redundant Storage) or RA-GZRS.

RA-GRS = 6 copies across 2 regions, secondary region readable always via -secondary suffix URL
RA-GZRS = same but primary region uses 3 availability zones (more resilient)

⚠️ GRS alone does NOT allow reading secondary. Must be RA-GRS or RA-GZRS for live read access.

Phase 2 — Cheat Sheet

Storage account name has hyphen — valid?INVALID — lowercase + numbers only, no hyphens

Cheapest long-term storageArchive tier — lowest storage cost

Log files, append-only writesAppend Blob

VM disk storage typePage Blob (VHD files)

Cannot read Archive blobRehydrate first — Standard (15hr) or High priority (<1hr)

Lifecycle policy not working after creationUp to 24 hours for first evaluation — expected

Revoke SAS immediately, no policyRotate account key — breaks all SAS from that key

Most secure SAS typeUser Delegation SAS — signed by Entra ID, Blob only

IoT data, sub-ms latencyPremium Block Blob (LRS only, no Archive)

Data must stay in one regionLRS or ZRS only

Read secondary without failoverRA-GRS or RA-GZRS

Service Endpoint still accessible from internetMissing Step 2 — Storage firewall must add VNet rule

500TB offline migrationAzure Data Box — physical appliance

AzCopy vs Azure File SyncAzCopy = one-way, one-time. File Sync = bidirectional, continuous

Blob soft delete vs Container soft deleteEnable both separately — one doesn't cover the other