AZ-900: Storage, Durability, and Data Choices

A photo-sharing application keeps uploaded images, user profiles, audit records and temporary processing files. Calling all four “data” hides the decisions that matter. Images behave like objects; application records may need transactional queries; diagnostic records grow over time; temporary files may not justify expensive geographic replication. The AZ-900 exam introduces Azure storage services and the reasons to choose among them. It also expects a basic understanding of redundancy, access tiers and common migration tools.

The strongest way to study these topics is to start with the data’s access pattern. Who reads it? Does an application need a filesystem interface, a disk attached to a machine, an object accessible over an API or a database query? How quickly must information return after an outage? Those questions reveal far more than a list of product names, and they explain why cost and recovery trade-offs are part of the design rather than an afterthought.

Object, file, queue and disk storage address distinct interactions

Azure Blob Storage is designed for storing unstructured objects such as media, exports, logs and backups. Applications can access blobs through supported APIs and controls without treating each blob as a file on a traditional shared network drive. Azure Files provides managed file shares using familiar file-sharing protocols for workloads that require that model. Managed disks provide block storage for Azure virtual machines; they are not a general replacement for multiuser file shares. Azure Queue Storage supports simple application messaging and work decoupling rather than storing the application’s final business records.

Consider the photo application. Original images and resized copies naturally fit an object storage pattern. A legacy finance application expecting a shared filesystem may be better served by a file-share option. A virtual machine’s operating-system disk belongs to the VM storage model. A queue can hold requests to process images asynchronously, which is different from persisting the images themselves. Service names are less important than recognizing the interface and lifetime of each item.

Storage accounts introduce choices about service support, redundancy and configuration. Not every storage feature is available under every account arrangement, and account settings can influence security, access and cost. AZ-900 seeks the conceptual families, not a command-by-command account creation procedure. Avoid using “cloud storage” as though all implementations expose the same operations or reliability guarantees.

Redundancy protects copies; it does not define recovery on its own

Locally redundant storage maintains copies within a region’s local infrastructure arrangement. Zone-redundant storage distributes replicas across multiple availability zones within a supported region. Geo-redundant options replicate data to a secondary region; variations differ in secondary read access and other behavior. Those choices change the failures the storage system can tolerate, but they are not a substitute for application-level recovery objectives or data-protection planning.

A file deleted by an authorized but mistaken administrator may be removed or affected across replicated copies; redundancy is not automatically a point-in-time backup. Similarly, maintaining geographically distributed copies does not by itself assure zero recovery-point loss or instantaneous application failover. Teams must understand the product’s failover capabilities, replication characteristics, access model and any additional backup or versioning controls required. A resilient application also needs compute, network and identity paths after a regional event.

Consider a retailer preserving transaction exports for audit. If losing any recent export is unacceptable, it may need a retention or backup policy beyond a simple redundancy setting. If the main requirement is to keep media available during a zonal disruption, zone-aware storage design may contribute directly. AZ-900 scenarios often turn on distinguishing the scope of protection from an oversold promise of universal fault tolerance.

Access tiers express how often data is worth retrieving

Blob storage access tiers help align cost with the frequency and speed of access. Frequently accessed data generally belongs in an appropriate online tier, while infrequently used or archival data may have different storage, access, retrieval or minimum-retention economics. The cheaper stored gigabyte is not necessarily the cheaper total workload. An archive that must be rehydrated urgently during an incident could undermine the business requirement, and repeatedly retrieving supposedly cold data can create additional charges.

Suppose daily product images remain popular for several months, but old exports are needed only for occasional audits. Lifecycle policies may help move eligible content between tiers according to age or other conditions. Yet automation is valuable only when the retention rule matches actual demand and legal requirements. If a regulation requires a document to remain readily accessible, using the cheapest deep-archive arrangement without considering retrieval time is a false economy.

Candidates should also recognize that performance, resilience and price interact. A heavily read media object might be cached near users through appropriate delivery architecture, but that does not make the original object store irrelevant. A backup’s storage tier, retention, redundancy and restoration process all matter. Describing the usage pattern first makes the correct service or tier easier to identify.

Separate operational storage from structured data services

The application’s user-profile records may belong in a database rather than a bucket of blobs. Relational databases are useful when data relationships, structured querying and transactional consistency requirements drive the workload. Non-relational options can be attractive for particular flexible schemas, distribution patterns or scale needs. This distinction is adjacent to AZ-900 storage objectives but should not be inflated into a full data-engineering course. Data-specific qualifications such as DP-900 explore Azure data concepts in greater detail.

A common architectural error is to equate “unstructured data” with “no useful metadata.” An image stored as a blob can still have application metadata in a database. Another error is to select a database because it has a search feature when the immediate requirement is simply to store large files cheaply. The application’s data model and read/write pattern should determine where content and metadata live. The right design can use multiple services without being needlessly complicated.

Azure storage tools do not override that architectural choice. Azure Storage Explorer helps users work with supported Azure storage data; AzCopy is a command-line utility for transferring data to and from Azure storage. Neither is a managed transactional database. Learn to distinguish a storage service, an operational tool and a migration service before answering a question that includes all three names.

Migration is about constraints beyond file copying

Azure Migrate supports assessment and migration planning for various supported environments and workloads. Azure Data Box addresses transfer scenarios where moving large datasets through physical devices can be more practical than sending everything over a network path. AzCopy is appropriate for supported data transfers when connectivity and operational constraints allow it. Azure File Sync can help coordinate supported Windows Server file shares with Azure Files, enabling a hybrid file-serving arrangement. Their purposes overlap only at the high level of moving or using data in Azure.

Imagine a branch office with hundreds of terabytes of historical files and a slow WAN connection. A simple command-line copy might take too long or interfere with business traffic, so offline transport could be worth assessing. By contrast, a small daily export from a well-connected location might be routine to upload. A company retaining on-premises file servers while moving selected data into cloud file shares has a different problem again. Choosing a tool requires an estimate of size, bandwidth, downtime tolerance, source type and target behavior.

The migration plan should also address permissions, metadata, integrity checks and user access after cutover. Moving bytes successfully does not prove that an application can use them. Fundamentals candidates need not memorize every supported tool switch, but they should understand why network transfer, offline transfer and hybrid synchronization are distinct solutions.

Protect data with identity, networking and lifecycle rules

Storage durability does not decide who can read the information. Azure storage access can involve identity-backed authorization, service-specific access controls and network restrictions. Sensitive content may need encryption, a restricted network path and short-lived delegated access where appropriate. One overly broad token or role assignment can expose data despite excellent redundancy. Teams should control privileged operations, record access needs and review how credentials or delegated links are issued and retired.

The concept of role-based access control matters especially when a storage account hosts data used by several applications. A person who can alter the storage resource’s configuration should not automatically be assumed to have a business reason to read every object. Similarly, resource-level governance controls and retention rules solve different problems. Security asks who can do something; governance asks which actions and configurations meet organizational policy; recovery asks how information will be restored after failure.

Monitoring is part of the picture. Capacity growth, operation counts, latency and errors may indicate a configuration or application problem. Unexpectedly high transaction charges can result from the access pattern even when stored capacity looks modest. Good operation includes measuring the workload rather than hoping the initial price estimate remains accurate forever.

Evaluate a realistic storage architecture end to end

Return to the photo-sharing application. The originals live as blobs, background processing requests are queued, user account details live in a suitable database and operational logs have their own retention requirements. Regional needs determine an appropriate redundancy plan; the business chooses tiers according to how often content is read. Network access and identity decide who may upload or retrieve files. A recovery exercise verifies that the application can reconstruct a useful service, not just that several copies of objects exist somewhere.

If the case changes, the design should change predictably. A new branch office expecting SMB access introduces a file-share requirement. A vast migration through a constrained network raises offline transfer as a candidate. A compliance rule requiring rapid retrieval may rule out an archive tier for particular records. Azure storage fundamentals is essentially the ability to map these specific needs to service categories and costs while avoiding the assumption that storage, databases, backup and file migration are all interchangeable products.