An Azure administrator may use Blob Storage for application objects, logs and backups, while Azure Files presents managed file shares through supported protocols. Their data protection options overlap conceptually but not identically. A blob version is not an Azure Files share snapshot; a storage tier is not a recovery point; and a geo-redundant account is not a substitute for recovery against a malicious deletion. Microsoft AZ-104<\/a> expects an administrator to select the appropriate control for the data source.<\/p>\n Imagine a team keeping customer reports in Blob containers and configuration files on an Azure file share. The team wants cheap storage for old reports, recovery after accidental deletion, and the ability to restore a file from last week. Make the recovery objectives explicit: how much data loss is acceptable, what scope must be restored, how far back should versions exist, and who is authorized to recover or permanently remove objects.<\/p>\n The current Microsoft AZ-104 exam objectives<\/a> name containers, file shares, storage tiers, blob versioning, blob and container soft delete, Azure Files snapshots\/soft delete, and blob lifecycle policies. Treat these as a protection lifecycle to design and test, rather than product switches to memorize.<\/p>\n An Azure storage account sets regional, redundancy, network and encryption boundaries. Within supported account kinds, containers organize blob objects and shares organize file data. Record whether a proposed workload needs object access or file semantics, the permitted clients, protocol compatibility, and expected number and size of files. Do not assume every storage account capability or service SKU supports every feature.<\/p>\n An object-storage client commonly accesses a container or blob through HTTPS and role or delegated-token authorization. Azure Files clients may use SMB or NFS under documented prerequisites. Identity-based SMB access needs its own directory and share-level configuration; it is not achieved by copying Blob data-plane assignments. Test authorization with the actual chosen client protocol.<\/p>\n Storage identity and SAS authorization<\/a> should be tested against the actual operation. A principal permitted to upload a report is not necessarily permitted to remove prior versions, change lifecycle rules or permanently delete a protected object. Separate routine application write access from the more sensitive permissions required for data recovery and retention management.<\/p>\n Blob storage tiers are cost and access-pattern decisions. Hot and cool and other supported online tiers differ in storage, read\/write and retention-related charges, while archive is an offline access model requiring rehydration before ordinary reading. A cheap-looking tier may cost more when applications constantly retrieve content, especially if minimum retention penalties apply. Check current supported account type, region, service and tier behavior before applying a rule.<\/p>\n Classify objects by observed access and legal retention. A frequently accessed live report should not be sent to an offline tier purely because it is several weeks old. A compliance copy rarely accessed for years may justify colder storage, but recovery time must fit the organization’s promise. A design that optimizes storage cost while breaking an incident response time objective is not successful.<\/p>\n Test the consequences of a tier move on a disposable object. Record object state and anticipated retrieval behavior, including whether a rehydration step is needed. Document estimates as estimates\u2014not measured production savings\u2014and validate current billing and feature rules using first-party storage documentation.<\/p>\n Blob versioning retains prior versions when supported and configured; blob soft delete provides a recoverable state after certain deletions for the configured retention period. Container soft delete helps recover deleted containers. These features address different incidents and have separate scope, settings and cost implications. Do not assume enabling a single checkbox guarantees recovery from every overwrite or whole-container deletion.<\/p>\n Create a disposable report, modify it, and delete it under the selected protection settings. List versions and deleted entities using a supported tool, select the intended recovery point, and compare the restored content with the original. The test should demonstrate not only that a recovery control exists but that the right version is accessible to an authorized operator.<\/p>\n Retention and immutable storage policies may create additional requirements for protected workloads. Separate a regulated retention control from everyday accidental-delete recovery. Changing an account setting after an object has been lost may not retroactively restore it. Configure, test and document protection before the incident.<\/p>\n Azure Files provides share snapshots for point-in-time copies of the share’s state and soft-delete mechanisms for supported deleted-share recovery. A share snapshot is not a VM snapshot and should not be confused with a backup vaulted under Azure Backup. Decide whether the business needs a quick file rollback, a long-retained audited backup, or a broader disaster recovery plan.<\/p>\n Run a lab in which a test file is created, a share snapshot is taken, and the file is changed. Inspect the snapshot view and restore the earlier file content according to the supported mechanism. Test a deleted share only when the account’s configuration actually supports soft delete. Verify security and user access after recovery instead of expecting restored files to solve unrelated identity failures.<\/p>\n Vault-based backup and native blob or file versioning protect against different failure modes. Versioning and snapshots may recover a previous object state, while a supported vault policy can provide a separately managed recovery point. Neither mechanism should be represented as a verified restore until a controlled recovery test has succeeded.<\/p>\n Lifecycle rules evaluate eligible blob properties, prefixes and age conditions, then apply actions such as moving objects to suitable tiers or deleting them. A misconfigured prefix or broad rule can apply to more data than planned. Start with a narrow test container and a deterministic object naming scheme rather than enabling a policy against an entire production account.<\/p>\n Create test objects with differing access and modification histories. For each object, predict which rule should match, expected transition timing, and what downstream application behavior will change. Distinguish a policy being configured from the asynchronous evaluation and action actually occurring. Inspect operation logs and storage state before declaring a successful migration.<\/p>\n Versioned objects and soft-deleted content can also affect retention economics. Account for old versions, snapshots and protective copies when calculating storage growth. A lifecycle policy designed without a view of protected historical data may lower the visible active-tier bill while retaining expensive unreachable versions or deleting evidence needed for recovery.<\/p>\n Write three incident cards: an overwritten invoice, an accidentally deleted share, and a full region outage. For the overwrite, blob versioning may provide the direct recovery path. For the deleted share, Azure Files soft delete or an existing snapshot may be relevant depending on configuration and incident scope. For a region outage, redundancy and broader recovery services determine whether another site can run the workload.<\/p>\n Run each card against the chosen account and record the recovery prerequisite, available point in time, administrator permission, restore side effects, and whether recovery was actually tested. A redundancy tier such as GRS can protect copies against infrastructure failure but does not prevent every logical deletion from propagating.<\/p>\nCreate accounts, containers, and file shares with clear boundaries<\/h2>\n
Understand hot, cool, cold, and archive trade-offs<\/h2>\n
Use versioning and soft delete for separate failure cases<\/h2>\n
Protect Azure Files with share snapshots and soft delete<\/h2>\n
Design lifecycle management without deleting useful evidence<\/h2>\n
Choose a recovery design based on explicit incidents<\/h2>\n