{"id":2679,"date":"2026-10-08T18:04:35","date_gmt":"2026-10-08T18:04:35","guid":{"rendered":"https:\/\/www.exam-topics.net\/blog\/?p=2679"},"modified":"2026-10-12T20:46:57","modified_gmt":"2026-10-12T20:46:57","slug":"az-104-azure-blob-and-file-storage","status":"publish","type":"post","link":"https:\/\/www.exam-topics.net\/blog\/az-104-azure-blob-and-file-storage\/","title":{"rendered":"Microsoft AZ-104: Azure Blob and File Storage"},"content":{"rendered":"

The AZ-104 storage domain covers access controls, storage-account configuration, redundancy, replication, encryption, data-movement tools, Azure Files, Blob Storage, tiers, soft delete, snapshots, lifecycle management, and versioning. On the AZ-104 exam<\/a>, these topics are usually presented as administrative decisions: protect data correctly, choose the right access method, configure resilience, or manage the lifecycle of objects and file shares.<\/p>\n

Candidates with Azure fundamentals<\/a> knowledge may already know the difference between object and file storage at a high level. AZ-104 requires more operational depth. You need to understand how a storage account is secured, how data is moved, how recovery features behave, and which setting belongs to Blob Storage versus Azure Files.<\/p>\n

Start with the access path<\/h2>\n

Before configuring a storage feature, determine how clients will reach the account and how they will authenticate. The current blueprint includes storage firewalls and virtual networks, shared access signatures, stored access policies, access keys, and identity-based access for Azure Files. These mechanisms solve different problems and have different operational risk.<\/p>\n

Account keys are powerful credentials and should not be the default answer when a more limited mechanism can satisfy the requirement. A shared access signature can delegate specific permissions for a defined period, while identity-based approaches can integrate access with Microsoft Entra identities in supported scenarios. Network rules add another boundary by limiting where requests can originate.<\/p>\n

A secure design often combines identity and network controls rather than relying on one secret. For exam questions, read whether the requirement is about who can access, from where, for how long, or with what permissions.<\/p>\n

Use SAS and stored access policy deliberately<\/h2>\n

A shared access signature is useful when a client needs delegated access without receiving the storage account key. The permissions, resource scope, and validity period should be as narrow as the use case allows. Long-lived, overly broad SAS tokens create management and exposure risk.<\/p>\n

Stored access policies can help manage service SAS behavior by associating constraints with a named policy. That can make revocation or policy changes easier than depending only on parameters embedded in independently issued tokens. The exam may frame this as an administrative requirement to control delegated access over time.<\/p>\n

Do not confuse SAS with Azure RBAC or network rules. A token can authorize a request, while a firewall can still prevent the request from reaching the service. Troubleshooting storage access requires checking both authorization and network reachability.<\/p>\n

Configure redundancy around business requirements<\/h2>\n

Storage redundancy determines how Azure maintains copies of data and protects against different failure scopes. The correct choice depends on durability, availability, region strategy, and cost. AZ-104 administrators should be able to interpret a requirement and configure an appropriate redundancy option rather than simply choosing the most replicated design.<\/p>\n

Object replication is a separate capability that can copy blob data between storage accounts for specific scenarios. Do not treat it as a synonym for account redundancy. One is part of the storage account durability model; the other is an object-level replication mechanism with its own configuration.<\/p>\n

Encryption is another independent concern. Data durability does not replace encryption, and encryption does not provide recovery from deletion. Each control addresses a different failure or security condition.<\/p>\n

Know what belongs to Azure Files and what belongs to Blob Storage<\/h2>\n

Azure Files exposes file shares that can support familiar file-oriented access patterns. Blob Storage organizes object data in containers and is designed around object semantics. The exam can test which service fits an application as well as how to configure the service once selected.<\/p>\n

For Azure Files, current objectives include creating and configuring file shares, snapshots, soft delete, and identity-based access. For Blob Storage, they include containers, access tiers, soft delete, lifecycle management, and versioning. Some resilience concepts sound similar but are configured differently depending on the service.<\/p>\n

When reviewing a scenario, identify the data access pattern first. An application expecting object operations and lifecycle tiers points naturally toward blobs. A workload expecting shared file semantics points toward Azure Files.<\/p>\n

Use tiers and lifecycle management to control blob cost<\/h2>\n

Blob access tiers allow organizations to align storage cost with how frequently data is accessed. Lifecycle management can automate movement or expiration based on rules so that administrators do not manually reclassify large numbers of objects. The policy should reflect real retention and access behavior rather than an arbitrary age threshold.<\/p>\n

A lifecycle rule can reduce cost, but a poorly designed rule can also move frequently used data into a tier that creates retrieval delay or additional charges. The exam may provide access-frequency or retention clues that indicate the intended choice.<\/p>\n

Versioning and soft delete solve different recovery problems. Versioning preserves earlier versions when a blob changes, while soft delete protects against deletion for a configured retention period. Use the feature that matches the failure the organization needs to recover from.<\/p>\n

Protect Azure Files with snapshots and soft delete<\/h2>\n

File-share snapshots provide point-in-time views that can help recover previous file states, while soft delete protects the share itself from accidental deletion. These controls should be understood alongside backup strategy rather than treated as universal replacements for it.<\/p>\n

Administrative questions may ask which control can recover a recently deleted share versus which can restore an earlier state of files. The wording matters. Identify whether the failure is deletion of the share, modification of content, or loss beyond the configured retention window.<\/p>\n

As with blobs, recovery settings should be configured before an incident. Enabling a feature after data is lost does not retroactively create protection.<\/p>\n

Use Storage Explorer and AzCopy for operational movement<\/h2>\n

The current blueprint includes managing data with Azure Storage Explorer and AzCopy. Storage Explorer provides a graphical administrative experience across storage services, while AzCopy is designed for high-performance command-line data transfer. A scenario that emphasizes automation, scripting, or large transfers may point toward AzCopy, while an interactive administrative task may fit Storage Explorer.<\/p>\n

Operational tools still obey the account\u2019s authentication and network configuration. If a transfer fails, verify identity or credentials, firewall rules, endpoints, and the requested operation before assuming the tool itself is malfunctioning.<\/p>\n

For repeatable migration or synchronization work, document commands and access requirements so the process can be reproduced rather than depending on one administrator\u2019s interactive session.<\/p>\n

Study storage as a set of failure protections<\/h2>\n

Map each feature to the failure it addresses. Firewalls and identity protect access. Redundancy protects against infrastructure failure. Encryption protects confidentiality. Soft delete protects against accidental deletion. Versioning protects against overwrites or changes. Snapshots capture point-in-time file-share state. Lifecycle management controls long-term data placement and retention.<\/p>\n

The broader Microsoft certifications<\/a> contains deeper storage and architecture material, but AZ-104 focuses on configuring and managing these protections in an operational Azure environment.<\/p>\n

A strong study exercise is to take one storage account and write four incident scenarios: unauthorized access, regional resilience requirement, accidental deletion, and rising cost from cold data. Choose the control for each without using one feature as a substitute for another.<\/p>\n

Troubleshoot storage access in layers<\/h2>\n

A failed storage request can have several independent causes. The client may be outside the allowed network, the SAS may be expired or missing a permission, the account key may have been rotated, or the identity may lack the required role or file-share access. Troubleshooting is faster when you test the network path and authorization path separately rather than regenerating credentials repeatedly.<\/p>\n

Start by confirming the target account and service, then verify whether the network rules allow the client. After reachability is established, inspect the authentication method and permissions. If the request uses SAS, check resource scope, allowed operations, and validity period. If it uses an identity, confirm the assignment and the service\u2019s supported identity model. This sequence maps directly to the access controls listed in the AZ-104 blueprint.<\/p>\n

Avoid solving a narrow failure by opening the account to all networks or distributing an account key. Those changes may make the test succeed while violating the actual security requirement.<\/p>\n

Design recovery before data changes<\/h2>\n

Storage recovery features work best when they are selected against specific failure cases in advance. Blob versioning helps when content is overwritten. Blob or container soft delete helps with accidental deletion. File-share snapshots preserve point-in-time state, while Azure Files soft delete protects deleted shares. Redundancy protects against infrastructure failures but does not substitute for these logical recovery controls.<\/p>\n

Build a small recovery matrix when studying: failure, affected service, protection feature, retention requirement, and restore action. This prevents the common mistake of assuming that because data is replicated it can always be recovered after an administrator deletes or changes it.<\/p>\n

The same matrix is useful operationally. A team should know how long recovery data is retained, who is allowed to restore it, and how to test the procedure. A protection setting that has never been tested is only a configuration, not a proven recovery capability.<\/p>\n

Match administration tools to repeatability<\/h2>\n

Interactive tools are useful for inspection and one-time work, while repeatable data movement benefits from scripted commands and documented parameters. Whatever tool is selected, keep authentication and network requirements explicit so another administrator can reproduce the task without receiving an overly powerful credential.<\/p>\n

This is especially important during migrations. Test throughput and error handling with representative data, record the chosen access method, and verify the destination before scaling up the transfer. Operational discipline around the tool is part of managing storage reliably.<\/p>\n","protected":false},"excerpt":{"rendered":"

The AZ-104 storage domain covers access controls, storage-account configuration, redundancy, replication, encryption, data-movement tools, Azure Files, Blob Storage, tiers, soft delete, snapshots, lifecycle management, and versioning. On the AZ-104 exam, these topics are usually presented as administrative decisions: protect data correctly, choose the right access method, configure resilience, or manage the lifecycle of objects and […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,1],"tags":[],"class_list":["post-2679","post","type-post","status-publish","format-standard","hentry","category-microsoft","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2679","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/comments?post=2679"}],"version-history":[{"count":2,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2679\/revisions"}],"predecessor-version":[{"id":3928,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2679\/revisions\/3928"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/media?parent=2679"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/categories?post=2679"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/tags?post=2679"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}