AZ-104 Skill 2: Implement and Manage Storage

Deep-dive guide | Storage security, management, and data lifecycle for the Azure Administrator

Storage is the persistent backbone of every cloud workload. Without it, compute is stateless, file shares disappear, and business continuity is impossible. Microsoft allocates 15–20% of the AZ‑104 exam to storage because, as an administrator, you will spend a significant portion of your time configuring access, protecting data, and managing cost and performance across a range of storage services.

This article goes beyond the exam objectives to map every tested storage skill to the underlying Azure domains, the architecture decisions that shape storage design, and the real‑world enterprise scenarios where you apply that knowledge.

1. Overview

#

Storage in Azure is not a single service—it is a platform of services built on a unified storage account architecture. The three most important storage types you manage are:

• Blob Storage – object storage for unstructured data: logs, images, backups, data lakes.
• Azure Files – fully managed SMB/NFS file shares for lift‑and‑shift, shared configuration, and user home drives.
• Managed Disks – block storage for Azure Virtual Machines (covered in depth in the compute skill area).

Why storage matters in cloud architecture:

• Data persistence – applications need durable, available data.
• Security – data must be encrypted at rest and in transit, with fine‑grained access controls.
• Cost management – different access tiers and lifecycle policies allow you to match cost to usage patterns.
• Disaster recovery – replication and backup strategies define your recovery point and recovery time objectives.

Every other workload—compute, networking, monitoring—relies on storage. The exam tests your ability to configure storage accounts, enforce security, optimize data lifecycle, and ensure data can be recovered when disaster strikes.

2. Skill Area Breakdown

#

Storage Security & Access

#

Administrators control who (or what) can reach storage and from where.

• Shared access signatures (SAS) – delegated, time‑limited, scoped permissions to storage objects without exposing the account key.
• Stored access policies – server‑side policies that govern SAS tokens, allowing revocation and parameter reuse.
• Access keys – root credentials for the storage account; must be managed and rotated securely.
• Identity‑based access – Azure AD authentication for Azure Files over SMB, using Kerberos; also enables RBAC on blob data.
• Storage firewalls and virtual networks – network‑level restrictions that limit access to specific IP ranges or VNets.
• Private endpoints – assign a private IP from your VNet to the storage account, completely isolating data plane traffic from the internet.

Storage Accounts

#

The container for all storage services: Blob, File, Queue, Table.

• Account types – General Purpose v2 (recommended), v1 (legacy), BlobStorage (legacy).
• Performance tiers – Standard (HDD‑backed, cheaper) or Premium (SSD, low latency).
• Redundancy – determines how data is replicated within a region or across regions.
• Object replication – asynchronous, blob‑level copy between storage accounts for compliance or low‑latency access.
• Encryption – automatically enabled with Microsoft‑managed keys; customer‑managed keys supported via Key Vault.
• Management tools – Azure Storage Explorer (GUI) and AzCopy (CLI) for data movement and management.

Blob Storage

#

Unstructured object data stored in containers.

• Containers – logical grouping of blobs; access policy can be set at container level.
• Access tiers – Hot (frequent access), Cool (infrequent, lower storage cost, higher access cost), Cold (online, very low storage cost, higher access cost), Archive (offline, cheapest storage, hours to rehydrate).
• Lifecycle management – automated rules to move blobs to cooler tiers or delete them after a defined period.
• Versioning – automatically keeps previous versions of a blob on write/delete, enabling point‑in‑time recovery.
• Soft delete – retains deleted blobs or containers for a configurable retention period (1–365 days), allowing recovery.

Azure Files

#

Fully managed file shares that use SMB or NFS protocols.

• File shares – mountable from cloud or on‑premises via SMB 3.0; also REST API.
• Snapshots – point‑in‑time read‑only copies of the entire share, for backup and self‑service restore.
• Soft delete – retains deleted shares or files for recovery.
• Hybrid access – Azure File Sync caches frequently accessed files on Windows Server, tiering older data to Azure.

3. Azure Domains Mapping

#

Every storage exam skill draws from one or more foundational domains.

Understanding the domain helps you connect the exam objective to the correct architectural principle. For example, configuring soft delete is a data protection activity; choosing between LRS and GRS is a backup & DR and storage decision.

4. Azure Architecture Mapping

#

This section links storage administration to the architectural choices that underpin a well‑designed Azure estate.

Storage Architecture

#

• Service selection: Blob for unstructured data and logs, Azure Files for shared drives, Managed Disks for VM persistent storage. Each has unique performance, protocol, and cost profiles.
• Storage account design: A storage account is a management and security boundary. Best practice: separate production and non‑production accounts, segregate workloads by data classification.
• Scalability: Storage accounts scale to 2 PB per account and 120 Gbps egress. Premium accounts have lower capacity limits but higher IOPS. Design for scale limits when planning large data lakes.

Data Durability Architecture

#

Redundancy options provide trade‑offs between cost, availability, and regional resilience:

Architecture decision: LRS for non‑critical dev data, ZRS for high availability within a region, GRS for production workloads requiring regional disaster recovery, RA‑GRS when you need to serve read traffic from the secondary region during an outage.

Data Lifecycle Architecture

#

Access tiers and lifecycle management are the primary cost‑optimization levers.

• Hot – high storage cost, low access cost. Use for active data.
• Cool – lower storage cost, higher access cost. At least 30 days storage. Good for short‑term backup.
• Cold – even lower storage cost, higher access cost. At least 90 days. For long‑term infrequent access.
• Archive – offline, lowest storage cost, high retrieval cost and latency. Requires rehydration (hours). For compliance archives.

Lifecycle management rules automate moving blobs between tiers and deleting old versions. For example: “Move blobs to Cool after 30 days without modification, delete after 365 days.” This is a core exam topic.

Backup & Recovery Architecture

#

Administrators implement RPO and RTO objectives through:

• Azure Backup – agent‑based or agentless, application‑consistent snapshots for VMs, files, and databases. Recovery Services vault stores backup policies and long‑term retention.
• Snapshots – instant point‑in‑time copies (for files and blobs). Not a full backup but useful for quick restore of accidental deletions.
• Soft delete and versioning – first line of defense against accidental deletion or ransomware; can restore previous versions without calling support.
• Object replication – provides near‑real‑time replication of blob containers across regions, enabling read‑only copies in secondary regions.

Secure Storage Architecture

#

Storage security is layered:

• Network isolation: Use Service Endpoints or Private Endpoints to keep traffic on the Azure backbone. Storage firewalls restrict by IP/VNet.
• Authentication: Prefer Azure AD and Managed Identities over access keys. For Azure Files, join the storage account to AD DS or Entra Domain Services for Kerberos‑based identity access.
• Authorization: Use RBAC for control plane (manage storage accounts) and data plane (blob/file operations). SAS for delegated, scoped access to objects.
• Encryption: Enabled by default (Microsoft‑managed keys). Customer‑managed keys allow you to control key lifecycle in Azure Key Vault, required by many compliance standards.

A secure enterprise pattern:

Traffic never transits the public internet, and the storage account firewall is set to deny all public access.

5. Azure Services Deep Dive

#

Storage Account

#

• Architecture: A single storage account can host Blob, File, Queue, and Table services. Each has its own endpoint (<name>.blob.core.windows.net, .file.core.windows.net).
• Account types: Always choose General Purpose v2 for new deployments (supports all redundancy, tiers, and lifecycle policies). BlobStorage accounts are legacy and limited.
• Performance: Standard (magnetic HDD, lower cost) vs Premium (SSD, low latency for high IOPS workloads like Azure Files Premium or page blobs). The exam may test when to use Premium (e.g., production Azure Files for SQL Server workloads).

Blob Storage

#

• Containers: Access level can be Private (no anonymous), Blob (anonymous read of blobs), or Container (anonymous read of container + blobs). For exam, private is default and recommended.
• Access tiers: Set at account level or at blob level. A blob can be hot, cool, cold, or archive. Archive blobs are offline; to read, you must rehydrate.
• Versioning: Enable at account level. All write operations create a new version; you can list and restore previous versions. Each version incurs storage costs.
• Lifecycle management: Rules are JSON‑based, defined at account level. Common filters: days since creation, days since last access, blob prefix.

Azure Files

#

• SMB access: Requires port 445 open (often blocked by ISPs for residential networks but not enterprise). Two ways to mount: storage account key (less secure) or Azure AD identity with Kerberos (requires hybrid identity or Entra Domain Services).
• Azure File Sync: A Windows Server agent that syncs specific folders with an Azure file share, optionally tiering older files to the cloud (cloud tiering).
• Enterprise scenarios: Multi‑site file server replacement, home drives, app configuration sharing.

Managed Disks

#

While formally part of the compute skill area, managed disks are Azure’s block storage for VMs. Administrators choose:

• Standard HDD – low cost, low IOPS.
• Standard SSD – consistent latency for web servers.
• Premium SSD – high IOPS/low latency for databases.
• Ultra Disk – sub‑millisecond latency, configurable IOPS/throughput (not in AZ‑104).

Storage account‑based unmanaged disks are legacy; the exam expects you to know managed disks. They are encrypted at rest by default with platform‑managed keys.

Storage Security Features (Exam‑Focus)

#

• SAS: A URI that grants specific permissions (r, w, d, l) for a specified time. Can be account‑level or service‑level. A stored access policy on a container can modify or revoke a SAS without regenerating keys.
• Shared keys: Full admin access to the storage account. Use only for legacy apps; rotate regularly.
• RBAC: Use built‑in roles like Storage Blob Data Contributor, Storage File Data SMB Share Contributor for data plane access. Works with Azure AD.
• Private Endpoint: The most secure option; storage account accessible only via private IP. Requires a VNet, private DNS zone.

6. Storage Decision Framework

#

When to use which Azure storage service:

Cost considerations:

• Blob storage costs = stored GB + read/write operations + data egress.
• Azure Files = provisioned capacity (premium) or pay‑per‑use (standard).
• Managed Disks = provisioned capacity regardless of usage.

7. Real‑World Enterprise Scenario

#

Company: Global Engineering Corp runs a web application in two Azure regions (East US, West Europe) for performance and resilience. They need:

1. Shared application configuration files that must be mounted by VMs in both regions.
2. Long‑term backup of application logs retained for 7 years to meet regulatory requirements.
3. Cross‑region resilience: if one region goes down, the other region must still serve content.
4. Secure access: no exposure to the public internet.
5. Cost optimization: logs older than 90 days are rarely accessed.

Solution design:

• Azure Files with Azure File Sync: Deploy a file share in East US as primary. Azure File Sync agents on Windows Servers in both regions sync to that share, providing local fast access with cloud tiering. Alternatively, use a premium file share with private endpoints in both regions (but that would require cross‑region mounting latency). The sync model works better for multiple regions.
• Blob Storage for logs: A General Purpose v2 storage account in East US with RA‑GRS redundancy. Containers configured with private endpoint.
• Lifecycle management: Rule: logs older than 90 days move to Cool tier, older than 365 days to Archive tier. This keeps recent data accessible and older data at minimal cost.
• Soft delete and versioning: Enabled on the storage account to protect against accidental deletion.
• Security: All storage accounts have public access disabled, private endpoints connected to hub VNets, and use Azure AD authentication for Azure Files access. RBAC grants only log‑reader role to developers.

Why this works:

• Redundancy (RA‑GRS) provides read‑only region‑pair copy for disaster recovery.
• Lifecycle management reduces cost automatically.
• Private endpoints meet security requirement.
• Azure Files + sync handles shared configuration.

8. AZ‑104 Exam Thinking

#

Microsoft’s storage questions test operational configuration under specific requirements.

Storage Account Questions

#

Often ask: “Which redundancy should you choose to meet a requirement for region‑level disaster recovery while minimizing cost?”

• Key: GRS provides cross‑region replication; RA‑GRS adds read access to secondary (more expensive). Choose GRS if read access not needed. LRS/ZRS are for single‑region only.

Security Questions

#

Focus on the appropriate access method:

• SAS when you need delegated, time‑limited access to specific blobs without sharing the account key.
• Stored access policy when you need to revoke a SAS later.
• Identity‑based access for Azure Files when requirement says “authenticate using Active Directory”.
• Private endpoint for network isolation when public access is prohibited.
• Storage firewall to restrict to a VNet or on‑premises public IP range.

Blob Storage Questions

#

Lifecycle management and soft delete appear together:

• “You need to automatically delete blobs older than 365 days and restore blobs deleted accidentally in the last 14 days.” Answer: lifecycle rule + soft delete enabled with retention 14 days.
• “Which tier has the lowest storage cost but the highest retrieval latency?” Archive.
• “What must you do before you can read a blob in Archive tier?” Rehydrate (change tier to Hot/Cool).

Reasoning approach:

1. Identify the primary requirement: durability, cost, access speed, compliance.
2. Map requirement to the appropriate redundancy, tier, or access method.
3. Look for constraints: regional replication, no internet access, AD authentication.
4. Choose the least complex solution that meets all constraints.

9. Practice Scenarios

#

Scenario 1

#

You manage a storage account with GRS replication. The primary region suffers a major outage. You must be able to read the data while Microsoft completes the region failover.

What should you have configured beforehand?

• A. Enable RA‑GRS on the storage account.
• B. Configure object replication to another account.
• C. Create a SAS token for the secondary endpoint.
• D. Set the account to use ZRS.

Correct answer: A
Explanation: RA‑GRS provides read access to the secondary region’s copy even before Microsoft initiates a failover. GRS alone only allows read after failover.
Architecture reasoning: For business continuity where immediate read access is needed during a primary region disaster, RA‑GRS is the appropriate redundancy choice.
Related services: Storage Account redundancy, RA‑GRS.

Scenario 2

#

A developer reports they accidentally deleted a critical blob in a container. No snapshot or backup was taken. You need to restore it with minimal data loss, assuming the storage account was configured with default settings.

What should you have enabled in advance?

• A. Blob versioning
• B. Soft delete for blobs
• C. Point‑in‑time restore
• D. Object replication

Correct answer: B
Explanation: Soft delete retains deleted blobs for the configured retention period and allows undeleting them. Versioning protects against overwrites, not deletions. Point‑in‑time restore requires both soft delete and versioning, and is more complex. Object replication is not a restore mechanism.
Architecture reasoning: Soft delete is the first line of defense against accidental deletion and should be enabled on all production storage accounts.
Related services: Blob soft delete.

Scenario 3

#

Your company requires that all access to a storage account be restricted to a specific VNet and that no traffic travels over the public internet.

Which two configurations should you implement?

• A. Create a private endpoint for the storage account in the VNet.
• B. Enable storage account firewall with the VNet’s public IP range.
• C. Configure a service endpoint on the VNet subnet.
• D. Configure the storage account firewall to deny all public network access.

Correct answer: A and D
Explanation: A private endpoint assigns a private IP, keeping traffic off the internet. Setting public network access to “Disabled” ensures no public endpoint is reachable. A service endpoint still uses the storage account’s public endpoint, although traffic stays on the Azure backbone; the requirement is “no public internet”, private endpoint is the most restrictive and correct.
Architecture reasoning: Private endpoints are the gold standard for network isolation, used heavily in enterprise landing zones.
Related services: Private Link, storage firewall.

Scenario 4

#

You need to provide a third‑party auditor read‑only access to a specific blob container for 7 days, without creating an Azure AD account for them and without using shared account keys.

What should you create?

• A. A user delegation SAS token scoped to the container.
• B. A stored access policy with read permissions.
• C. An account SAS token with read permissions.
• D. A managed identity for the auditor.

Correct answer: A
Explanation: A user delegation SAS is secured by Azure AD credentials and can be scoped to a container. Stored access policies are not tokens; they need to be associated with a SAS. Account SAS still uses the account key indirectly; user delegation SAS is key‑free. Since the auditor doesn’t have an Azure AD account, you’d generate a user delegation SAS using your own identity (or a service principal) and provide the SAS token. That meets the requirement. (Note: The auditor doesn’t need an account; they just receive the SAS URL.)
Architecture reasoning: User delegation SAS is the modern, secure way to grant delegated access without keys.
Related services: Blob Storage, SAS, Azure AD.

Scenario 5

#

A storage account holds application logs. You need to move blobs that haven’t been accessed in 90 days to a lower‑cost tier, and delete them after 365 days. The solution must be automated and require no manual intervention.

What should you configure?

• A. An Azure Automation runbook that runs daily.
• B. A lifecycle management rule.
• C. An Azure Function with a timer trigger.
• D. Azure Backup with retention policy.

Correct answer: B
Explanation: Blob lifecycle management provides built‑in, serverless, automated tiering and deletion based on days since last access or creation.
Architecture reasoning: Use platform‑native features whenever possible to reduce management overhead. Lifecycle management is the go‑to for blob tiering automation.
Related services: Blob lifecycle management.

10. Common Exam Mistakes

#

• Confusing Blob Storage with Azure Files: Blob = object (REST, no SMB); Files = SMB mountable. If the scenario mentions “drive letter” or “mounted share”, it’s Azure Files.
• Choosing the wrong redundancy: Selecting GRS when ZRS would suffice (and is cheaper). GRS is for regional disaster recovery; ZRS is for intra‑region high availability. Read the requirement carefully.
• Misunderstanding SAS permissions: An account SAS can grant permissions to multiple services; a service SAS is limited to one. Stored access policies are optional and provide revocation capability.
• Ignoring lifecycle management for cost control: Manually moving blobs or writing scripts when a simple lifecycle rule would solve the problem.
• Using access keys when RBAC or managed identities are available: The exam rewards modern, secure practices. If Azure AD authentication is possible, it’s often the correct answer.
• Forgetting that soft delete for containers must be enabled separately from blobs.
• Archive tier misconceptions: Archive blobs are offline. You cannot read them without rehydrating, which can take hours. If the requirement says “immediate access,” Archive is wrong.
• Assuming tags are inherited by resources within a storage account: They are not; tagging strategy must be enforced via Azure Policy.

11. Skill 2 Learning Checklist

#

Must Know (exam‑critical)

#

• Create and configure a General Purpose v2 storage account
• Understand and select the correct redundancy option (LRS, ZRS, GRS, RA‑GRS)
• Generate and use a SAS token (service, account, user delegation)
• Configure stored access policies to manage SAS tokens
• Configure storage firewall and virtual network rules
• Configure private endpoints for storage accounts
• Enable and configure blob soft delete and versioning
• Create and configure a blob container
• Set blob access tier (Hot, Cool, Archive) at blob level
• Create and manage a lifecycle management rule (tier blobs, delete)
• Create and configure an Azure file share
• Configure file share snapshots and soft delete
• Use Storage Explorer and AzCopy for data movement

Should Know (strong working knowledge)

#

• Understand and implement object replication between accounts
• Configure identity‑based access for Azure Files (Azure AD Kerberos)
• Know storage account encryption options (Microsoft‑managed vs customer‑managed keys)
• Manage storage account keys (rotation, key vault integration)
• Understand the implications of changing the account access tier
• Use Azure File Sync for hybrid scenarios

Nice to Know (architecture context)

#

• Compare Premium vs Standard performance for file shares and page blobs
• Understand blob index tags for data classification
• Familiarity with immutable storage policies (WORM) for compliance
• Know storage account scale limits and design for them
• Understand the role of Azure NetApp Files for high‑performance NFS

12. What’s Next

#

Storage is the data layer that compute will consume. In AZ‑104 Skill 3: Deploy and Manage Azure Compute Resources, you’ll attach managed disks, mount file shares, and configure VMs and containers—all while applying the security and lifecycle patterns you’ve mastered here.

AZ‑104 Skill 3: Deploy and Manage Azure Compute Resources →

Related Architecture and Domain Content

#

• Storage domain deep‑dive: /azure/domains/storage
• Security domain overview: /azure/domains/security
• Governance domain (tagging & policy): /azure/domains/governance
• Storage architecture design: /azure/architecture/storage-architecture
• Data lifecycle architecture: /azure/architecture/data-lifecycle-architecture
• Backup and recovery architecture: /azure/architecture/backup-and-recovery-architecture
• Storage Account service reference: /services/storage-account
• Blob Storage service reference: /services/blob-storage
• Azure Files service reference: /services/azure-files
• Managed Disks reference: /services/managed-disks
• Azure Backup service guide: /services/backup