Microsoft AZ-204: Azure Storage and Blob Storage — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Part of the Microsoft Azure Developer Associate AZ-204 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure Storage provides durable, massively scalable cloud storage for unstructured and structured data. For application development, focus on selecting the correct storage account type, configuring redundancy to meet RTO/RPO goals, choosing the right blob type and access tier for cost/performance, and securing access with Azure AD and SAS. Use lifecycle policies to automate data movement across tiers, serve static websites directly from Blob storage when appropriate, and apply Azure Files and Queue Storage where file semantics or message-based decoupling are required.

Storage account types and redundancy fundamentals

General-purpose v2 (GPv2) is the standard account type for most workloads. It supports blobs, files, queues, and tables, all access tiers, lifecycle management, and the latest features. Legacy BlobStorage accounts expose only the Blob service and tiering, but they lack the breadth of features and cost optimizations found in GPv2; new deployments should prefer GPv2. FileStorage accounts are premium, SSD-backed accounts dedicated to Azure Files, delivering consistent, low-latency IOPS and throughput for enterprise file workloads (e.g., profile shares, line-of-business apps). Choose FileStorage when you require premium performance for SMB/NFS shares; otherwise, GPv2 is the default.

Redundancy choices determine data durability and availability across failure domains:

• LRS (Locally Redundant Storage) synchronously stores three copies within a single datacenter. Lowest cost, no zone or regional protection. Use for dev/test, ephemeral workloads, or when you have higher-layer replication.
• ZRS (Zone-Redundant Storage) synchronously replicates across availability zones in a region, protecting from a zonal outage with high availability and no RPO. Choose for production in zonal regions requiring intra-region resiliency.
• GRS (Geo-Redundant Storage) stores three synchronous copies in the primary region (like LRS) and asynchronously replicates to a secondary paired region (LRS there). Typical RPO is less than 15 minutes; secondary is not readable by default. Select for disaster recovery when you do not need read access.
• RA-GRS (Read-Access Geo-Redundant Storage) adds read access to the secondary via -secondary endpoints. Use when you require cross-region disaster tolerance and read-mostly workloads during primary incidents, or for geo-proximity reads where eventual consistency is acceptable.

When you need both zone failure protection and cross-region DR, consider pairing ZRS locally with an additional geo-replicated account pattern at the solution level. Plan for account failover testing, understand DNS endpoint flips, and validate application retry policies to handle eventual consistency and clock skew during geo events.

Blob data model, tiers, and lifecycle management

Blobs come in three types with distinct semantics. Block blobs are optimized for streaming and random read of large objects such as images, videos, and backups. Uploads are chunked into blocks and committed, enabling parallel uploads and efficient retries. Append blobs are optimized for append-only workloads like telemetry and log capture; only append operations are allowed, which simplifies concurrency. Page blobs expose 512-byte aligned pages for random read/write I/O and back Azure virtual hard disks (VHDs) used by Azure VM disks; they are the only supported blob type for IaaS disks and large random I/O workloads.

Blob access tiers control cost and performance. Hot is optimized for frequent access with the lowest read/write latency and highest storage cost. Cool targets infrequently accessed data retained for at least 30 days, with lower storage cost but higher transaction/read costs and minimum retention charges. Archive is the lowest-cost tier for long-term retention; objects are offline and must be rehydrated to hot or cool before read. Rehydration can be requested with standard or high priority, trading cost for speed. You can set a default access tier at the account level (hot or cool) and override per blob; archive is per-blob only.

Lifecycle management policies automate data movement and retention to control cost and meet governance. At the account level, define rules that:

• Transition blobs or blob versions/snapshots to cool or archive after N days since last modified
• Delete blobs, snapshots, or versions after age thresholds
• Filter by container prefix and by blob index tags to target specific datasets (for example, tag env=prod and policy=retention-7y) Combine lifecycle rules with versioning and soft delete to protect against accidental deletions while still enforcing retention. Remember that archive has minimum retention and early deletion charges; design policies to minimize unnecessary rehydrations.

For change tracking and downstream processing, enable the storage account change feed to consume an ordered, immutable log of blob create, update, delete, and copy operations. This supports compliance and asynchronous processors that need exactly-once or at-least-once semantics with checkpointing.

Static website hosting in Blob storage exposes a special $web container served through a dedicated web endpoint. Configure index and error documents and publish static assets directly. The static website endpoint provides anonymous read access to site content independent of the blob public access setting; access via the blob endpoint can remain disabled. For custom domains and global acceleration, front the endpoint with Azure Front Door or Azure CDN. Private endpoints are not supported for the static website endpoint; use an edge service to secure and accelerate delivery where private access is required.

Security, identity, and controlled data access

Azure Storage encrypts data at rest by default with 256-bit AES using Microsoft-managed keys. For stricter control, enable customer-managed keys (CMK) stored in Azure Key Vault or Managed HSM to govern key rotation and separation of duties; grant the storage account’s managed identity wrap/unwrap permissions. For highly regulated workloads, enable infrastructure encryption to apply a second, independent encryption layer. Pair server-side encryption with client-side encryption if end-to-end cryptographic control is required.

Azure AD authorization integrates the data plane with RBAC for Blob and Queue services and for the Files REST API. Grant least-privilege roles such as Storage Blob Data Reader or Storage Blob Data Contributor to managed identities, users, or groups. In code, use DefaultAzureCredential to acquire OAuth 2.0 tokens and avoid embedding keys. For SMB access to Azure Files, enable identity-based authentication using Active Directory: join the storage account to on-premises AD DS (via Azure AD Kerberos for hybrid identities) or Azure AD DS, and use NTFS ACLs and RBAC (e.g., Storage File Data SMB Share Contributor) for share-level authorization. Ensure SMB 3.x with encryption over the wire and consider Private Endpoints, VPN, or ExpressRoute to traverse networks that block port 445.

Shared Access Signatures (SAS) delegate scoped, time-bound access without exposing account keys. Service SAS grants access to a specific service and resource (e.g., a single blob or container) with precise permissions and start/expiry times. Account SAS operates at the account level, spanning multiple services (blobs, files, queues, tables) and service APIs such as list or create. User delegation SAS is specific to Blob storage and is signed with a user delegation key obtained via Azure AD for a principal with appropriate RBAC; it removes key dependency and centralizes access control in Azure AD. Apply constraints including IP ranges, allowed protocols (HTTPS-only), and short lifetimes. Stored access policies centralize SAS constraints and enable revocation by updating or deleting the policy; they apply to service SAS and account SAS. User delegation SAS does not use stored access policies; revoke by expiring the user delegation key or removing Azure AD role assignments. Always prefer SAS over account keys, and prefer user delegation SAS when your app can acquire Azure AD tokens.

Azure Files and Queue Storage essentials

Azure Files provides fully managed SMB shares and an NFS option for POSIX scenarios. Use SMB shares for lift-and-shift migrations and app compatibility. Premium FileStorage accounts deliver predictable low-latency performance, while standard shares are economical for general-purpose file data. Manage shares and files via SMB clients or the REST API/SDKs. Azure File Sync enables hybrid file services by caching a cloud share on Windows Server, providing local performance and tiering cold data to the cloud, multi-site sync, and backup/offsite DR without traditional NAS refresh cycles. Combine Azure AD–based identity with NTFS ACLs to enforce least privilege, and use Private Endpoints to contain data exfiltration risk.

Azure Queue Storage enables decoupled, resilient application workflows. Each message can be up to 64 KB (larger payloads should reference blob URIs). The message time-to-live (TTL) determines automatic expiration; specify a positive value from seconds up to seven days, or -1 for no expiration. When a worker retrieves a message, it becomes invisible for its visibility timeout. If processing fails and the message is not deleted before the timeout, it reappears for another consumer. Tune visibility timeout to exceed worst-case processing time, and use idempotent handlers plus exponential backoff to reduce contention. Track the dequeue count to detect poison messages; when it exceeds a threshold, move the message to a dedicated poison queue for quarantine and analysis. Azure Functions queue triggers implement this pattern automatically with a -poison queue. For higher-throughput or FIFO needs with ordering guarantees, consider Service Bus queues; otherwise, Azure Queue Storage is lightweight and cost-effective.

Practical Problem Scenario

National Geographic must publish a high-traffic photography microsite with serverless image processing, cost-optimized storage, and hybrid access for an on-premises editorial tool. They also require secure, time-limited sharing links for partner agencies and robust message handling for background processing.

1. Create a GPv2 storage account with RA-GRS

• Why: GPv2 unlocks Blob, Files, and Queue services with lifecycle and tiering features. RA-GRS provides cross-region disaster tolerance and read access to secondary endpoints for continuity of read-mostly assets during regional incidents.

2. Enable static website hosting and deploy site assets to the $web container

• Why: Blob static websites eliminate web server management, deliver low-latency reads from the Hot tier, and scale globally. Pair later with Azure Front Door for custom domains, WAF, and edge caching.

3. Store original RAW images as block blobs; write-once telemetry as append blobs

• Why: Block blobs support large, parallel uploads and efficient delivery of web-optimized derivatives. Append blobs simplify concurrent log writes from processing pipelines without conflicts.

4. Define lifecycle policies to move originals to Cool after 30 days and Archive after 180 days; delete versions older than one year

• Why: Automated tiering reduces storage cost based on access patterns while retaining compliance copies. Version and snapshot cleanup controls bloat without manual intervention.

5. Secure data access with Azure AD and user delegation SAS for partners

• Why: Assign Storage Blob Data Reader to a managed identity in the sharing service, obtain user delegation keys, and mint short-lived, HTTPS-only SAS tokens with IP restrictions. This avoids distributing account keys and ties authorization to Azure AD.

6. Enable customer-managed keys with Key Vault and infrastructure encryption

• Why: CMK satisfies stricter compliance and rotation requirements, while double encryption provides defense in depth for sensitive media.

7. Integrate Azure Queue Storage for background image processing with an Azure Functions queue trigger; set visibility timeout to exceed max processing time and configure poison handling

• Why: Queues decouple the upload path from compute. Visibility timeout prevents duplicate work, and the Functions runtime routes failed items to a -poison queue automatically for investigation.

8. Publish editorial tooling via Azure Files using a premium FileStorage account and Azure File Sync to on-premises Windows Server

• Why: Editors gain low-latency SMB access with NTFS ACLs and identity-based authentication through AD, while Azure File Sync provides local caching and cloud tiering. The premium tier ensures consistent performance for interactive workloads.

9. Front the static website with Azure Front Door and enable caching and custom HTTPS

• Why: Edge POPs reduce latency globally, custom domains meet branding requirements, and WAF adds security without changing the storage backend.

10. Enable the storage account change feed and archive to a compliance store

• Why: An immutable, ordered log of blob changes supports downstream analytics, auditing, and replay for reproducible content pipelines.

← Azure Functions and Serverless Computing · All domains · Azure Cosmos DB →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →