Recommend a Data Solution for Protection and Durability — Lesson

When somebody asks an architect "is the data safe?", the honest answer requires unpacking the question into four sub-questions: safe from hardware failure, safe from regional disaster, safe from accidental deletion, and safe from unauthorized access. Azure's storage platform exposes a different control for each: redundancy SKU, geo-replication, soft-delete plus versioning, and network restriction (typically a private endpoint). For semi-structured and unstructured workloads — Azure Blob Storage, Azure Data Lake Storage Gen2, and Azure Files — the architect's job is to map a workload's recovery and compliance requirements onto these four levers, choosing the cheapest configuration that still meets every constraint.

This lesson takes you through each lever, the trade-offs that matter on the exam, and the reasoning patterns that distinguish a defensible design from an over-engineered or under-protected one. Reference material is drawn from the AZ-305 study guide chapters on durable storage design.

Why This Matters

A wrong redundancy choice is rarely caught in development — it is caught when a region goes down, when a developer's accidental az storage blob delete-batch command runs against production, or when an auditor asks for the WORM evidence proving last quarter's transaction logs are unaltered. Each of those moments is a career event. Cloud architects who can confidently navigate LRS versus GZRS, when RA-GRS makes sense, and how to combine versioning with immutable storage for compliance are the ones who get pulled into the most consequential design reviews. AZ-305 tests this reasoning in scenario form, and the same reasoning is what production teams use every week to keep regulators happy and incident bridges short.

Prerequisites

• Azure resource hierarchy (subscription → resource group → resource). Self-check: can you name three properties scoped at the storage-account level versus the container level?
• Storage account kinds (StorageV2, BlockBlobStorage, Premium). Self-check: which kind is required for the lowest-latency block-blob workloads?
• Availability zones versus regions. Self-check: how many availability zones must a region have to support ZRS?
• Microsoft Entra ID, RBAC, and managed identities for storage access. Self-check: which built-in role grants read access to blob data but not the account keys?
• Basic VNet concepts: subnets, NSGs, service endpoints. Self-check: how does a service endpoint differ from a private endpoint at the network layer?
• Azure Monitor diagnostic settings. Self-check: where do you route storage account logs so you can run KQL across them?

Learning Objectives

By the end of this lesson, learners will be able to:

1. Recommend the correct redundancy SKU (LRS, ZRS, GRS, GZRS, RA-GRS, RA-GZRS) for a given durability, availability, and budget profile.
2. Design a deletion-recovery posture for blob workloads that combines container soft-delete, blob soft-delete, and blob versioning appropriately.
3. Evaluate when Azure Storage object replication is the right answer versus geo-redundant SKUs or Azure Site Recovery.
4. Configure immutable storage with time-based retention and legal-hold policies to satisfy WORM compliance, distinguishing locked from unlocked policies.
5. Select the right network-isolation pattern (public, service endpoint, private endpoint, firewall) for a storage account, with attention to cross-region and on-premises access paths.
6. Combine all five levers into a coherent protection design and justify each decision against the workload's RPO, RTO, regulatory, and cost constraints.

Building Blocks

Durability — Imagine each copy of your data as a fire-resistant safe. Durability is the mathematical chance, over a year, that all your safes burn down at once. Formally, Azure publishes durability as a per-year probability of object loss; LRS is 99.999999999% (11 nines), ZRS is 99.9999999999% (12 nines), and any geo SKU is 99.99999999999999% (16 nines). Why it matters: durability is about bytes surviving, not being reachable. A region outage doesn't change durability — it changes availability.

Availability — Whether the front door of the safe room is open during business hours. Formally, Azure publishes a per-month uptime SLA for the read or write endpoint of a storage account: LRS and ZRS get 99.9% for read/write of the primary; RA-GRS and RA-GZRS get 99.99% read availability because the secondary endpoint can serve reads during a primary outage. Why it matters: availability is what your application sees during a failure scenario and is the metric that maps to user-visible incidents.

Replication scope — How far away the copies live. LRS keeps three copies in one datacenter (one fault-and-update domain pair). ZRS spreads three copies across three availability zones in the primary region. GRS/GZRS extends that with an asynchronous copy to a paired secondary region hundreds of kilometres away. Why it matters: replication scope is the lever that protects against the increasingly bad failure cases — disk failure, rack failure, datacenter loss, regional disaster.

Soft-delete — A trash can with a configurable retention period. Container soft-delete keeps deleted containers recoverable for 1 to 365 days; blob soft-delete does the same for individual blobs. Why it matters: most data-loss incidents are application bugs, fat fingers, or buggy automation — not regional failures. Soft-delete is the cheapest, most useful protection layer for this class of risk.

Versioning — A change log for blobs. Every overwrite creates a new version; the previous version is retained until a lifecycle rule prunes it. Why it matters: versioning catches the failure mode soft-delete misses — silent corruption from an Update rather than a Delete.

Immutable storage — A read-only seal on a blob. Time-based retention policies prevent modification or deletion until the policy expires; legal holds keep blobs immutable until the hold tag is removed. Locked policies cannot be reduced; unlocked policies can. Why it matters: regulators (SEC 17a-4(f), CFTC 1.31, FINRA 4511) require WORM (write-once, read-many) storage for certain records, and immutable blob storage is Azure's compliant answer.

Private endpoint — A network alias for a service that lives entirely inside your VNet. Each private endpoint binds to a sub-resource (blob, file, dfs, queue, table) and gets a private IP from your subnet. Why it matters: with a private endpoint and publicNetworkAccess: Disabled, the storage account effectively disappears from the internet; only the VNet (and peered or VPN-connected networks) can reach it.

The table below maps each building block to the primary risk it addresses, which is the mental shortcut to use in scenario questions.

Deep Dive

Redundancy SKUs — choosing how far the copies travel

Every Azure storage account picks exactly one redundancy SKU at create time, and four of the six options are intra-region while two are geo-replicated. The decision tree starts with the failure modes the workload must survive.

LRS is the price floor. Three synchronous copies sit on three different update-and-fault-domain combinations within a single datacenter, giving 11 nines of durability for the lowest cost per GB. It is appropriate for non-critical scratch space, intermediate analytics output, and any workload whose business rule is "just regenerate it from source if we lose it."

ZRS upgrades to three synchronous copies across three availability zones in the primary region. Durability rises to 12 nines and the workload now survives a single-datacenter loss without failover. The cost premium is roughly 20% to 25% over LRS. ZRS is the modern default for production workloads that don't need geo-replication, but only in regions with availability zones.

GRS adds an asynchronous copy of the entire account to the paired secondary region — a Microsoft-defined pairing such as East US to West US. The local copy uses LRS semantics inside the secondary region. Asynchronous means there is an RPO of typically less than 15 minutes for the geo-replicated copy. The secondary is invisible during normal operations; you only see it after a Microsoft-initiated or customer-initiated failover.

GZRS is GRS upgraded to use ZRS in the primary region — still LRS in the secondary. It is the recommended SKU for production data that must survive both zone and regional failures.

RA-GRS and RA-GZRS add read access to the secondary endpoint, exposed at <account>-secondary.blob.core.windows.net. This is critical for applications that need to keep serving reads during a primary-region outage without waiting for failover, and it is the only way to publish a 99.99% read SLA for the storage account.

[!IMPORTANT] Geo-replication is asynchronous. There is no synchronous geo SKU. If the workload has a true zero-RPO requirement, redundancy alone won't deliver it — pair a geo SKU with application-level write coordination or use a service whose cross-region semantics are stronger (for example, Cosmos DB multi-region writes for transactional data).

The Last Sync Time property exposes how far behind the geo-secondary is, which is the metric you would alert on for RPO adherence:

Soft-delete and versioning — the deletion-recovery layer

Redundancy protects bytes from physical loss. It does not protect them from a DELETE request, which faithfully replicates the deletion to every copy. To recover from accidental or malicious deletes you need a different mechanism.

Azure Blob Storage offers three closely related features that work in layers.

Container soft-delete retains deleted containers for 1 to 365 days. When enabled and a container is deleted, the container and its contents become hidden but recoverable through Restore-AzStorageContainer.

Blob soft-delete does the same for individual blobs and blob snapshots. It catches accidental delete blob calls or lifecycle-policy bugs that delete more than intended.

Blob versioning automatically creates a new version on every write or property change, so any overwrite is non-destructive. Combined with soft-delete, a deleted blob is fully recoverable: deleting a versioned blob marks the current version as deleted while preserving the version history.

[!TIP] Enable both blob versioning and blob soft-delete on any production blob account. Versioning catches overwrites that soft-delete alone misses; soft-delete extends recovery for the case where a tool deletes versions explicitly.

The cost shape of versioning is worth understanding. Each version stores the bytes of that version, so write-heavy workloads on large blobs can balloon costs. A lifecycle-management policy can move old versions to Cool or Cold tiers, or delete them after a window:

[!WARNING] Soft-delete retention is not the same as backup retention. A malicious actor with sufficient permissions can disable soft-delete and then delete blobs, and the retention period starts at the moment of deletion — not when the policy was set. For workloads that need protection against insider threats, layer immutable storage on top.

Object replication — selective async copy

Object replication is Azure's mechanism for asynchronously copying selected blobs from a source storage account to one or more destination accounts, optionally in different regions or subscriptions. It complements redundancy SKUs rather than replacing them.

The two are easy to confuse on the exam, so it is worth pinning down what makes object replication different. Geo-redundant SKUs (GRS, GZRS, RA-GRS, RA-GZRS) replicate the entire storage account to one specific paired region using Microsoft-managed asynchronous replication, with no customer control over the destination, the schedule, or the filtering. Object replication, by contrast, copies selected containers and prefixes to any storage account in any region you choose, runs as a customer-defined replication policy, and works between subscriptions or even tenants.

Practical use cases:

• Data locality: keep a copy of customer-uploaded blobs in a region close to a downstream analytics workload.
• Workload isolation: replicate prod blobs to a separate analytics account so analytics queries don't hit production traffic patterns.
• Cross-tenant share: replicate to a partner's storage account in a different Microsoft Entra ID tenant.

Both source and destination must have versioning enabled, and the source must have change feed enabled. Replication is one-directional per policy, but you can configure two policies (one in each direction) for active-active patterns.

Immutable storage — WORM compliance

For records that regulators expect to be unalterable for a defined retention period, Azure offers immutable blob storage at two scopes: container-level (the older option) and version-level (the modern, recommended option). Both rely on the same two policy types.

A time-based retention policy specifies how long the content must remain immutable. While the policy is in effect, no user — including the storage account owner — can delete or overwrite the content. Policies start in an unlocked state, where the retention period can be reduced or the policy removed. Once locked, the policy is permanent: the retention period can only be extended.

A legal hold is a tag-based mechanism for preserving content during litigation or investigation. Multiple legal holds can be applied; the content is immutable as long as any hold remains.

The combination satisfies WORM requirements for SEC Rule 17a-4(f), CFTC Regulation 1.31, and FINRA Rule 4511. Cohasset Associates has independently assessed Azure immutable blob storage as compliant with these regulations, which matters for regulated financial workloads.

Version-level immutability (the recommended option) lets different versions of the same blob carry different retention policies, which is essential when a record is amended and both old and new versions must be retained for separate windows. Container-level immutability applies one policy to every blob in the container, which is simpler but coarser.

[!IMPORTANT] Locked time-based retention policies are irrevocable. If you lock a 7-year retention policy on a 10 TB container by mistake, you cannot delete that data — or the storage account — until the retention expires. Microsoft Support cannot override this. Always test policies in an unlocked state first and budget for the worst-case retention cost.

Private endpoints — making the account disappear from the internet

A storage account is a public PaaS resource by default, reachable at <account>.blob.core.windows.net from the internet. For sensitive or regulated workloads this is unacceptable. Three mitigations exist, in increasing strength.

The storage firewall restricts the public endpoint to specific IP ranges or VNets. Traffic still traverses the Microsoft public IP space; only the source IP is filtered.

A service endpoint extends a VNet's identity to the public endpoint of the storage account, so traffic from the VNet uses an optimized route to the Microsoft backbone but still hits the public IP. The storage firewall can then restrict to that VNet.

A private endpoint allocates a private IP from your subnet that is bound to a specific sub-resource of the account (blob, file, dfs, queue, table, web). Combined with publicNetworkAccess: Disabled, the public endpoint is gone and the only reachable interface is the private one.

The DNS piece is what trips up most architects. The storage account hostname (<account>.blob.core.windows.net) is a CNAME to <account>.privatelink.blob.core.windows.net. With a private DNS zone (privatelink.blob.core.windows.net) linked to the VNet and an A record pointing to the private endpoint IP, clients in the VNet resolve the hostname to the private IP and connect privately. Without the private DNS zone, clients still resolve to the public IP and the connection fails when publicNetworkAccess is Disabled.

[!NOTE] Each sub-resource (blob, file, dfs, etc.) requires its own private endpoint. A common mistake is creating a blob private endpoint and assuming file is now also private — it is not. Audit the account by listing which sub-resources are actually used and create a private endpoint for each.

Worked Examples

Easy — Choosing redundancy for a media archive

Problem: Synthetic scenario (AZ-305 style) — Contoso Media stores 40 TB of video files in Azure Blob Storage. The files are reproducible from on-premises master tapes if lost. Cost is the priority. Which redundancy SKU should you recommend?

Solution:

1. Identify the durability target: the data is reproducible, so 11 nines is sufficient.
2. Identify the failure modes that matter: hardware failure within a datacenter is the only one with a real business impact; a regional disaster is recoverable from on-prem masters.
3. Identify the budget posture: the question explicitly prioritizes cost.
4. Recommend LRS. It delivers 99.999999999% durability at the lowest per-GB cost.

[!NOTE] Cost optimization in the Well-Architected Framework does not mean "always pick the cheapest." It means "spend money where it improves an outcome that matters." Here, paying for GZRS would buy survivability the workload doesn't need.

Medium — Recovery design for a SaaS tenant

Problem: Synthetic scenario (AZ-305 style) — A SaaS company stores customer-uploaded documents in Azure Blob Storage. Customers occasionally call support to recover documents they "didn't mean to delete" up to two weeks after the deletion. The company also wants to recover from an accidental delete-batch operation on an entire container. What features should be enabled?

Solution:

1. The two-week customer recovery window means soft-delete retention should be at least 14 days; pick 30 days for headroom.
2. Container-level deletion is a separate failure mode, so enable containerDeleteRetentionPolicy with the same retention.
3. To protect against silent overwrites (different from deletes), enable isVersioningEnabled.
4. Pair with a lifecycle policy to prune old versions so storage costs don't grow unboundedly.

[!NOTE] Versioning + soft-delete + container soft-delete is the canonical "deletion-recovery" stack. Each protects a different failure mode, and they compose without conflict.

Hard — End-to-end design for a regulated workload

Problem: Synthetic scenario (AZ-305 style) — Fabrikam Bank must store transaction confirmation PDFs for 7 years, immutable, with read access during a regional outage, no public network exposure, and a backup copy in a partner storage account in a different subscription. Recommend an end-to-end design.

Solution:

1. Immutability — version-level immutable storage with a locked time-based retention policy of 7 years on the relevant container. This satisfies SEC 17a-4(f) WORM requirements.
2. Redundancy — RA-GZRS. The "read access during regional outage" requirement rules out GRS/GZRS (no read access on secondary) and rules out LRS/ZRS (no regional protection). RA-GZRS adds zone redundancy in the primary region too.
3. Network — disable public network access; create a private endpoint on the blob sub-resource bound to the bank's VNet; configure the private DNS zone privatelink.blob.core.windows.net.
4. Cross-subscription copy — Azure Storage object replication policy with the bank's account as source and the partner's account as destination, filtered to the relevant container. Both accounts need versioning enabled.
5. Verification — set Azure Monitor alerts on Last Sync Time to detect replication lag; enable diagnostic settings to a Log Analytics workspace for audit trails.

[!NOTE] Each requirement maps to exactly one feature: immutability → time-based locked retention; cross-region read → RA-GZRS; network isolation → private endpoint plus disabled public access; cross-subscription copy → object replication. Recognising that decomposition is the AZ-305 reasoning pattern — break the scenario into independent constraints, choose a single feature for each, and only then look for conflicts.

Visual Explanations

The following TikZ figure shows the spatial layout of the redundancy SKUs across regions and zones — useful for internalising what "where the copies live" means.

Caption: LRS keeps all three copies in one availability zone; ZRS spreads them across three; geo SKUs add a far-region copy that is asynchronous and uses LRS semantics inside the secondary. This mental model lets you reason about which failure modes each SKU survives without memorising nine-counts.

The next visual, a Mermaid graph, captures the recovery layer that sits on top of whichever redundancy SKU you pick:

Caption: The deletion-recovery decision tree. Each operation type maps to a different protection feature; turn all three on for full coverage.

The final visual is a comparison table summarising when each immutability scope and policy combination is appropriate:

Common Mistakes

❌ Myth: "We are using GRS, so our application stays available during a regional outage." ✅ Reality: GRS keeps the bytes available in the secondary region, but only RA-GRS and RA-GZRS expose the secondary endpoint for reads during the outage. Without read access, the application sees timeouts until Microsoft (or the customer) initiates failover. Why it's tricky: durability and availability sound interchangeable, but they answer different questions. Durability asks "are the bytes still on disk somewhere?"; availability asks "can my app reach them right now?".

❌ Myth: "Soft-delete protects me from a malicious admin." ✅ Reality: A user with sufficient permissions can disable soft-delete and then permanently delete blobs. Once disabled, the retention clock is irrelevant. For protection against insiders, layer immutable storage (locked time-based retention) on top. Why it's tricky: soft-delete feels like a backup, but it is an operational recovery feature, not a security control. The same RBAC role that can delete blobs can usually disable soft-delete.

❌ Myth: "A locked time-based retention policy can be reduced if I open a Microsoft Support case." ✅ Reality: Locked policies are by design irrevocable. Microsoft Support cannot modify them. The retention period can only be extended — never shortened or removed — until the policy expires. Why it's tricky: "locked" sounds like a UI affordance that admins can override. In practice it is a regulatory feature whose entire value depends on being immutable, including against the cloud provider.

❌ Myth: "Disabling public network access on a storage account is enough to make it private." ✅ Reality: Without a private endpoint, disabling public access just blocks all access. With a private endpoint and the correct private DNS zone, clients in the VNet can reach the account using the same hostname they used before; clients outside cannot. Why it's tricky: the public endpoint and the private endpoint share the same hostname; only DNS resolution differs. Forgetting the private DNS zone is the most common cause of "I created a private endpoint and now nothing works."

Practice Exercises

🟢 Exercise 1 (Easy) — Identify the cheapest redundancy SKU that survives the loss of a single Azure datacenter (other than the one storing the data) without manual failover.

▶💡 Hint

"Survives loss of a datacenter" rules out single-DC SKUs.

▶✅ Solution

ZRS. It keeps three copies across three availability zones in the primary region, all synchronously written, so the loss of one zone is transparent to the application. GRS would also survive but at higher cost and with asynchronous semantics.

🟢 Exercise 2 (Easy) — A storage account uses RA-GRS. The primary region experiences a partial outage that affects writes. Can the application still read data? Can it write data?

▶💡 Hint

"RA" stands for "Read-Access" on the secondary.

▶✅ Solution

The application can read from the secondary endpoint (`

-secondary.blob.core.windows.net`) without waiting for failover. Writes still go to the primary; if the primary write endpoint is unhealthy, writes fail until either the primary recovers or a customer-initiated failover promotes the secondary.

🟡 Exercise 3 (Medium) — A team enabled blob soft-delete with 7-day retention but not blob versioning. A developer's pipeline overwrites the same latest.parquet blob with corrupted data. The corruption is detected 2 days later. Can they recover the original blob?

▶💡 Hint

Soft-delete and versioning protect against different operations.

▶✅ Solution

No. Soft-delete protects against delete blob operations, not overwrites. Without versioning, an overwrite replaces the bytes in place; the original is unrecoverable. The fix is to enable isVersioningEnabled so that every write creates a new version.

🟡 Exercise 4 (Medium) — Recommend a redundancy SKU and protection feature set for a Data Lake Storage Gen2 account holding 200 TB of analytics data. The data can be regenerated from upstream sources within 48 hours. The team has been burned by accidental directory deletes during pipeline development.

▶💡 Hint

"Regeneratable" is a hint about durability needs; "directory deletes" is a hint about recovery features.

▶✅ Solution

LRS for redundancy — the data is regeneratable, so 11 nines is sufficient and cost matters at 200 TB. Enable hierarchical namespace (already required for ADLS Gen2), blob soft-delete with 14-day retention, and container soft-delete. Versioning is less critical for analytics data that is typically append-only or written once per partition.

🟡 Exercise 5 (Medium) — A workload requires that data be unalterable for 5 years and that the retention period be adjustable for the first 30 days while testing the policy. After 30 days, the policy should become permanent. How do you configure this?

▶💡 Hint

Immutability policies have two states: unlocked and locked.

▶✅ Solution

Apply a version-level time-based retention policy of 1825 days in the unlocked state. During the first 30 days, the team can adjust the retention if needed. After validation, lock the policy; from that point on, the period can only be extended, never reduced.

🔴 Exercise 6 (Hard) — A company stores PII in blobs. Compliance requires no public IP exposure of the storage account, and the application runs in a peered hub-and-spoke topology with on-premises connectivity over ExpressRoute. Describe the minimum configuration.

▶💡 Hint

Private endpoints depend on DNS, and DNS in hybrid topologies depends on conditional forwarders.

▶✅ Solution

Set publicNetworkAccess: Disabled on the storage account. Create a private endpoint on the blob sub-resource in the spoke VNet. Create a private DNS zone privatelink.blob.core.windows.net and link it to the hub VNet (or any VNet that the spoke can resolve via). For on-premises access, configure the on-premises DNS servers to conditionally forward privatelink.blob.core.windows.net to an Azure DNS resolver (or a DNS forwarder VM in the hub) so on-prem clients also resolve to the private IP. Without the conditional forwarder, on-prem clients resolve to the (now blocked) public IP and connections fail.

🔴 Exercise 7 (Hard) — Two scenarios for cross-region data:

• Scenario A: a customer needs the entire account replicated to a paired region with read access during failover.
• Scenario B: a customer needs only the images container replicated to a partner's storage account in a different subscription.

Recommend the right Azure mechanism for each.

▶💡 Hint

One is account-wide and Microsoft-managed; the other is selective and customer-defined.

▶✅ Solution

Scenario A → RA-GZRS (or RA-GRS if zones are not available). Microsoft-managed, account-wide async replication with read endpoint on the secondary. Scenario B → Azure Storage object replication policy. Customer-defined, selective by container and prefix, supports cross-subscription destinations. Geo-redundant SKUs cannot target a custom destination, and object replication does not provide a Microsoft-managed failover endpoint.

🔴 Exercise 8 (Hard) — A team enables version-level time-based retention with a 10-year locked policy on a container holding 50 TB. Three months later, the team realises the retention period was supposed to be 5 years, not 10. What can they do?

▶💡 Hint

Locked time-based retention policies have specific allowed mutations.

▶✅ Solution

Nothing that reduces the retention. Locked policies allow only extensions to the retention period, not reductions. The 50 TB will remain immutable for the full 10 years; the storage account holding it cannot be deleted while the policy is in effect. The lesson is that locked policies should always be tested in unlocked form first, and the retention should be set to the exact regulatory requirement, not a "safe" larger number.

Summary & Concept Map

• Pick a redundancy SKU based on which failure mode the workload must survive: hardware (LRS), zone (ZRS), region (GRS/GZRS), region with read continuity (RA-GRS/RA-GZRS).
• Layer blob versioning, blob soft-delete, and container soft-delete to recover from accidental deletes and overwrites — three independent failure modes, three composable features.
• Use object replication when you need selective, cross-account, or cross-subscription async copies; geo SKUs cannot do this.
• Reach for immutable blob storage with locked time-based retention or legal holds when regulators (SEC 17a-4(f), CFTC 1.31, FINRA 4511) require WORM. Test unlocked first; locked is irrevocable.
• Disable public access and use private endpoints with the correct private DNS zone for any sensitive workload; remember each sub-resource needs its own private endpoint.
• AZ-305 reasoning pattern: decompose the scenario into independent constraints (durability, availability, recovery, compliance, network), pick one feature per constraint, then check for conflicts.

Caption: The five protection levers and how they relate. Redundancy is the foundation; versioning is the prerequisite for object replication; immutability and private endpoints layer on top of any redundancy choice. The next LO in this Topic moves to caching strategies for the same blob workloads.