{"id":1000116,"date":"2026-10-12T15:44:48","date_gmt":"2026-10-12T15:44:48","guid":{"rendered":"https:\/\/www.exam-topics.info\/blog\/microsoft-az-104-storage-redundancy-transfers\/"},"modified":"2026-10-20T09:47:33","modified_gmt":"2026-10-20T09:47:33","slug":"microsoft-az-104-storage-redundancy-transfers","status":"publish","type":"post","link":"https:\/\/www.exam-topics.info\/blog\/microsoft-az-104-storage-redundancy-transfers\/","title":{"rendered":"Microsoft AZ-104: Storage Redundancy and Transfers"},"content":{"rendered":"
\n

A storage account can report excellent durability while offering no protection against a user deleting the wrong directory. It can also contain three copies of every object in one region and still be exposed to a regional outage. Administrators need to ask what failure is being protected against before choosing LRS, ZRS, GRS or another replication option. The right redundancy setting is only one part of a storage design that also handles secure transfers, account configuration and recovery.<\/p>\n

A geo-replicated storage account may survive a regional outage and still lose its latest unreplicated writes; it will not automatically undo a valid deletion. Redundancy, object replication, backup, soft delete and versioning answer different recovery questions. In Microsoft AZ-104<\/a>, the decision begins with consistency, recoverability and the business operation that must be restored\u2014not a single feature checkbox.<\/p>\n

Start with the failure the business cannot tolerate<\/h2>\n

Ask whether the primary threat is a disk failure, an availability-zone outage, a regional disaster, accidental deletion or an attacker using valid credentials. Storage redundancy primarily protects against infrastructure failure. A deleted or overwritten object may propagate to every replica, so even the most resilient replication configuration is not a replacement for object versioning, soft delete or an independent backup strategy.<\/p>\n

Define a recovery point objective and recovery time objective for important workloads. RPO addresses how much recent data can be lost; RTO addresses how quickly acceptable service must be restored. Geo-replication can support regional recovery, but asynchronous replication introduces a nonzero data-loss window and failover itself takes operational time.<\/p>\n

The cheapest option is not always wrong and the most replicated option is not automatically correct. A re-creatable test dataset might need only local redundancy; a business-critical service may justify zone replication and secondary-region protection. Evaluate data sovereignty, application failover, service support and cost before changing the setting.<\/p>\n

LRS, ZRS, GRS and GZRS solve different problems<\/h2>\n

Locally redundant storage (LRS) maintains multiple copies in a single primary-region datacenter. Zone-redundant storage (ZRS) distributes synchronous copies across availability zones in the primary region. These options differ in exposure to a datacenter or zone outage. ZRS can maintain access during a zone failure in supported regions, while LRS has a narrower local protection boundary.<\/p>\n

Geo-redundant storage (GRS) adds asynchronous replication to a secondary region after local replication in the primary region. Geo-zone-redundant storage (GZRS) combines zone redundancy in the primary region with secondary-region replication. Read-access variants such as RA-GRS and RA-GZRS permit reads of replicated secondary data through the secondary endpoint. They do not make the secondary a normal writable primary before failover.<\/p>\n

Choose from supported account types, regions and services. Certain tiers or features impose restrictions on ZRS, GZRS and replication changes; do not assume an account can move between every combination immediately. A production migration may require a documented conversion or manual process and should include storage consumption, access tests and a rollback or recovery strategy.<\/p>\n

A failover is an application event, not a checkbox<\/h2>\n

During an account failover, the secondary region becomes the new primary endpoint and DNS-related routing changes. Applications with cached connections, location assumptions or dependencies in the affected region may still fail even if storage replication worked. Practice which clients need reconnect logic and how the application handles the last changes that were not yet replicated.<\/p>\n

Read access to a secondary region before failover is useful for continuity scenarios, but it has limitations. Applications must use the appropriate secondary endpoint and accept that the data can lag behind writes in the primary. Avoid displaying a stale financial balance as definitely current merely because the query to a read-access replica succeeded.<\/p>\n

A storage failover should be coordinated with infrastructure and compute recovery. The procedures in Azure Backup and Site Recovery<\/a> help distinguish point-in-time restoration from replica promotion and broader application disaster recovery. The administrator should know which operations require deliberate human authorization and which can be tested safely in advance.<\/p>\n

Object replication is not the same as account redundancy<\/h2>\n

Object replication can copy eligible block blobs between storage accounts under configured policies, including across regions. It is an application-oriented mechanism with prerequisites and object states that differ from built-in account-level redundancy. Its usefulness depends on the desired destination, object types, timing and operational ownership; it should not be presented as a universal failover mechanism.<\/p>\n

A content-distribution pipeline may deliberately replicate approved objects into another account to support a separate audience. A disaster-recovery design may instead prioritize regional replication of an account to restore the same service after an outage. Neither automatically protects against unauthorized source deletion without separate retention controls.<\/p>\n

Record which objects qualify for replication, whether versioning or change feeds are required by the selected feature path, and how permissions are maintained at the destination. Test new, updated and deleted-object scenarios rather than assuming every object lifecycle event has symmetrical behavior.<\/p>\n

Use Storage Explorer and AzCopy for different jobs<\/h2>\n

Azure Storage Explorer provides a visual interface for browsing and managing supported storage resources. It is useful when an operator needs to inspect containers, verify a transfer or compare account contents interactively. AzCopy is a command-line transfer utility suited to scripted copy and synchronization workflows. Neither bypasses authorization and network policy merely because the administrator is using a Microsoft tool.<\/p>\n

Storage access and SAS<\/a> should be tested before administrative transfers so SAS expiry, account keys and user-based data permissions are not confused. Pick the narrowest authorized identity and scope before using Storage Explorer or AzCopy to copy business data between accounts.<\/p>\n

For a migration, inventory object size, count, metadata, access tier and required permissions. A proof-of-concept transfer should test files with complex names, large objects, versioning expectations and restricted subfolders where relevant. Record throughput and error handling; the speed measured in a small local sample may not represent a large encrypted cross-region transfer.<\/p>\n

SAS tokens may be used for narrowly scoped transfers where appropriate, but they should expire and grant only required actions. Identity-based authorization can reduce reliance on shared keys. A command-line script containing a long-lived account key creates an avoidable security risk, particularly when copied into build logs or support tickets.<\/p>\n

Encryption and network access are independent layers<\/h2>\n

Azure Storage encrypts data at rest by default, with customer-managed key options for supported scenarios. A storage firewall determines which networks or clients can reach the public endpoint, while private endpoints can expose a private path from a virtual network. Having the correct role assignment and valid authentication does not make a client reachable if its network path is blocked.<\/p>\n

A private endpoint relies on name resolution. If a service name resolves to an unexpected public address from an on-premises client, the user may see what looks like a credential problem while the underlying issue is DNS or network routing. Review the private DNS configuration and client vantage point before weakening the firewall.<\/p>\n

The distinction matters in NSGs, Bastion and private endpoints<\/a> and the dedicated Azure DNS and load balancing<\/a> discussion. Each part of the path\u2014identity, resource data role, firewall, name resolution and service availability\u2014can fail separately. Good troubleshooting tests them in an order that preserves security.<\/p>\n

Protect data lifecycle without misusing redundancy<\/h2>\n

Blob versioning keeps prior versions for supported scenarios; soft delete creates a recovery window for deleted blobs or containers; lifecycle management automates movement between tiers and deletion based on rules. These settings are operational policies, not automatic proof that the last known good version can be restored within the business RTO. Retention windows and costs must be planned.<\/p>\n

Blob and Files lifecycle<\/a> controls address retention, version recovery and deletion behavior that a geo-replication setting does not undo. Set the expected recovery point and verify the preserved object version instead of assuming a replica is an independent backup.<\/p>\n

Archival tiers can be economical for infrequently read data, but they involve retrieval latency and service restrictions. Moving a record into a low-cost tier can break an application that assumes immediate access. When an organization has legal hold or retention requirements, verify the exact feature supports them rather than assuming storage lifecycle policies alone create compliant retention.<\/p>\n

Test recovery with a representative blob and file share. Know whether the scenario needs a previous version, snapshot, soft-deleted item or restored backup. Record which actor can authorize restoration and how the restored object will be validated before consumers rely on it.<\/p>\n

Make the storage decision reproducible<\/h2>\n

Build a short decision record around workload constraints: required region, availability zones, secondary-region access, maximum acceptable RPO, expected cost, retention obligations and transfer method. This avoids changing replication settings only after an outage reveals their limitations. Include the application owners who will need to test the service after a failover.<\/p>\n

Capacity and cost can change when moving to additional replicas, and a backup copy may incur its own storage and transfer charges. Use Subscriptions, budgets and Advisor<\/a> to monitor the budget impact; the alert informs an owner but will not automatically stop necessary replication. Tie spending discussions to the reliability guarantee the workload actually needs.<\/p>\n

For AZ-104 preparation, compare the failure scenarios rather than memorizing acronyms in isolation. Ask which option protects against a zone failure, which adds geo-replication, when secondary read access is possible and why deletion protection must be separate. Then practice a controlled transfer and verify both the authorization path and final data state.<\/p>\n

Recovery tests must examine usable data, not just storage health<\/h2>\n

A replicated account may pass an availability check while the application still fails because its identity assignment, private DNS configuration or key access did not survive the failover plan. Use recovery exercises that read a known record through the same application identity and network path the production workload uses. Confirm the content version and timestamp, not merely that the new storage endpoint responds. A DNS switch, an unauthorized client and stale secondary data have very different remedies.<\/p>\n

For a transfer, compare source and destination counts, representative checksums or supported integrity signals, metadata and permissions. Test cancellation and restart behavior, especially when an interrupted copy spans many objects. Keep a versioned migration manifest and do not delete the source before the business has accepted the result. Durability, recoverability and transfer correctness are independent properties; a reliable plan states which one each test is proving.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

A storage account can report excellent durability while offering no protection against a user deleting the wrong directory. It can also contain three copies of […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[38],"tags":[],"class_list":["post-1000116","post","type-post","status-publish","format-standard","hentry","category-microsoft"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/1000116","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/comments?post=1000116"}],"version-history":[{"count":4,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/1000116\/revisions"}],"predecessor-version":[{"id":1001421,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/1000116\/revisions\/1001421"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/media?parent=1000116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/categories?post=1000116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/tags?post=1000116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}