Object replication is a policy, not a one-time copy
A Microsoft AZ-104 administrator must distinguish replication of supported blobs between storage accounts from an AzCopy migration or built-in geo-redundancy. Object replication uses a defined source account, destination account, containers, and rules that select eligible objects and versions. It is asynchronous. It is not a tool to synchronize arbitrary Azure Files shares, and the successful upload of one source blob does not prove its destination replica exists immediately.
Begin with a scenario: a regional operations team wants specific invoice blobs available under another account’s independently managed access rules. List source and target account capabilities, network requirements, region, prefix selection and acceptable lag before selecting the service. If the true need is just a one-off export, a controlled AzCopy operation may be more appropriate and easier to verify.
Check prerequisites before creating a replication rule
Account kind and feature support matter. Review whether object versioning and change feed are required on participating accounts for the chosen replication configuration, and check Microsoft’s documented tier, blob type and rule restrictions. A rule that depends on unsupported configurations should be rejected during planning rather than debugged as an ordinary delay. Design with the current object replication reference.
Define a source container, a destination container and a prefix-limited selection. Create three test blobs: one inside the prefix, one outside and one revised after the policy is enabled. Predict which versions will replicate, inspect status and record any lag. A missing target object might indicate an ineligible blob, incorrect rule, account permission or simply incomplete asynchronous propagation.
Differentiate replication, redundancy and backup
Storage redundancy determines which infrastructure failure domains each of LRS, ZRS, GRS and GZRS can protect. Those are platform redundancy choices, while object replication provides selected object copies across managed accounts. A second independently authorized account can have an operational purpose that built-in redundancy does not satisfy; it also creates its own access and monitoring obligations.
Neither a secondary replica nor a redundant account should be described as a complete backup. Logical deletion or unwanted updates might propagate according to the mechanism, and recovery may require versioning, soft delete or protected backups. Write down the scenario you need to recover from: physical infrastructure fault, mistaken overwrite, deliberate deletion, or prolonged access loss. Choose controls for that failure, not the product with the most replicas.
Understand default encryption and customer-managed keys
Azure Storage encrypts at rest by default. In supported scenarios, customer-managed keys can give the organization authority over key lifecycle, but the storage service must still be permitted to reach its key store. A missing permission or disabled key can affect application availability even when all storage networking and data roles look correct. Record key ownership, version/rotation strategy, access restrictions and recovery before changing encryption settings.
Encryption keys used for data-at-rest protection are distinct from storage account access keys used to authorize certain requests. Rotating the latter can break Shared Key integrations; changing a customer-managed encryption key can affect data availability. Conflating both as ‘storage key rotation’ obscures the failure and permission model. Never expose key material or SAS tokens in an example’s logging output.
Choose AzCopy for verified movement
AzCopy supports data movement operations for compatible Azure Storage services. Decide whether the job should copy a bounded selection of objects, synchronize a target or migrate a dataset. Commands with overwrite or delete behavior require stronger review because the destination might contain independent business records. Review the current AzCopy v10 documentation for syntax, authentication modes, resumption and supported sources.
Generate a manifest of a dozen disposable objects with names, lengths and metadata important to the consumer. Use an authorized identity or narrowly scoped SAS, execute the transfer, then compare the destination with the manifest. A zero exit code is valuable but does not establish application-level correctness when path transformations, existing objects, metadata or retention policies also matter.
Inspect results in Storage Explorer
Azure Storage Explorer offers a graphical inspection path for supported blobs and file shares. Choose the smallest appropriate authentication method, inspect the source and destination inventories, and make sure it is clear whether the tool is using an interactive identity, SAS or account key. The same person might have management-plane visibility yet lack Blob data permissions, which explains some apparently inconsistent outcomes.
Review object properties, tier, name, last modification and the relevant replicated version. Test that an intentionally excluded object is not present. If an operator cannot see a container, troubleshoot endpoint/network path and data authorization separately.
Apply a failure matrix to migration
Create three intentional failures: an expired transfer SAS, a destination network restriction, and a replication rule whose prefix excludes the uploaded object. Each should produce different evidence and different corrective action. Do not grant a broad account-level role to solve all three. Capture the request’s error type and, where available, diagnostic correlation details without retaining secrets.
Before deleting a source account after a migration, require verified target inventory, application reconnection, retention checks, rollback and an owner sign-off. A transfer test in one region does not guarantee every feature will work in the target account. Account settings, endpoint names, private DNS and service-level ACLs can need separate updates.
Verify that the selected migration or replication method did what was intended
First describe the outcome precisely. If the goal is a one-time migration, use an appropriately scoped AzCopy job and compare the destination inventory with a source manifest that records object names, sizes, expected metadata and any permitted overwrite behavior. Review potentially destructive synchronization options before targeting an account that already contains production data. A completed transfer command does not prove that the new application identity can open every migrated object.
If the requirement is continuing propagation of selected blob versions, configure supported object replication policies on compatible source and destination accounts and check which containers, versions and prefixes are eligible. Monitor actual destination availability and account for asynchronous lag. This is different from selecting LRS, ZRS or GRS for infrastructure resilience, and neither mechanism automatically provides recoverability from an unwanted logical deletion.
Finally check failures at the correct boundary: an expired SAS can block AzCopy, storage network rules can reject an otherwise authorized request, a mismatched replication filter can omit objects, and a customer-managed encryption key that is inaccessible can affect the destination independently of Blob permissions. Record the evidence and the smallest safe correction for each case rather than granting a broader role to make a demonstration succeed.