AZ-104 Exam Ref Chapter 2: Implement and Manage Storage

Skill 2.1 — Configure Access to Storage Fundamentals

• Azure Storage Account Definition: The top-level resource for storing data in Azure. It is designed to be durable, highly available, secure, and massively scalable.

• Storage Services within an Account: A single storage account provides access to five distinct services:

  • Blobs: Used for arbitrary data storage (unstructured).

  • Tables: Used for structured NoSQL data.

  • Queues: Used for reliable messaging between application components.

  • File Shares: Managed SMB or NFS shares.

  • Disks: Virtual machine storage volumes.

• Storage Account Naming Requirements:

  • Must be globally unique across all of Azure.

  • Length must be between $3$ and $24$ characters.

  • Must contain only lowercase letters and numbers.

• Performance Tiers:

  • Standard: Utilizes magnetic disks. It is the best fit for general-purpose and cost-sensitive workloads. It supports all storage services (Blobs, Tables, Queues, Files, and unmanaged VM disks). Note: This setting cannot be changed after the account is created.

  • Premium: Utilizes SSD disks. It is designed for high I/O workloads. It supports only block blobs, page blobs, and file shares.

• Account Types:

  • General-Purpose V2 (GPv2): The recommended account type for most scenarios. It supports all storage services, Standard and Premium tiers, all access tiers (Hot, Cool, Cold, Archive), and all replication options.

  • General-Purpose V1 (GPv1): A legacy account type that is not recommended for new workloads.

  • Blob Storage Accounts: Legacy accounts that store only block blobs and append blobs. They support access tiers but not page blobs, meaning they cannot host unmanaged VM disks.

  • Block Blob Storage: A Premium-only account type specifically for block and append blobs.

  • File Storage: A Premium-only account type specifically for file shares.

• Upgrade Path: GPv1 and Blob Storage accounts can be upgraded to GPv2. This upgrade is irreversible. No other account type changes are supported.

Storage Redundancy and Replication Options

• Locally Redundant Storage (LRS):

  • Makes $3$ synchronous copies within a single datacentre.

  • Lowest cost replication option.

  • Provides no protection against a complete datacentre failure.

• Zone Redundant Storage (ZRS):

  • Makes $3$ synchronous copies across $3$ separate availability zones within one region.

  • Protects against the failure of a single datacentre.

• Geo-Redundant Storage (GRS):

  • Includes LRS in the primary region plus $3$ additional asynchronous copies to a secondary region located hundreds of miles away.

  • Replication typically completes within $15$ minutes, though there is no SLA guarantee.

• Read-Access Geo-Redundant Storage (RA-GRS):

  • Identical to GRS but provides read-only access to the data in the secondary region.

• Geo Zone-Redundant Storage (GZRS):

  • Includes ZRS in the primary region plus $3$ asynchronous copies to a second region.

• Read-Access Geo Zone-Redundant Storage (RA-GZRS):

  • Identical to GZRS but provides read-only access to the secondary region.

  • Only available for GPv2 accounts at the Standard tier.

• Configuration Note: When using Azure CLI or PowerShell, performance tier and replication are combined into a single SKU (e.g., Standard_LRS).

Access Tiers for Block Blob Storage

Access tiers allow for a trade-off between storage costs and access costs. Durability remains consistent across all tiers.

• Hot Tier: For frequently accessed data. Characterized by low access costs and higher storage costs.

• Cool Tier: For infrequently accessed data. Data must be stored for at least $30$ days. Features lower storage costs and higher access costs than the Hot tier.

• Cold Tier: For rarely accessed data. Data must be stored for at least $90$ days. Lower storage costs than the Cool tier with higher access costs.

• Archive Tier:

  • Used for long-term retention of rarely accessed data.

  • Tolerant of retrieval latency up to $15$ hours.

  • Data must be "rehydrated" (moved to a different tier) before it can be accessed.

  • Minimum recommended storage duration is $180$ days.

  • Archive is not supported for ZRS, GZRS, or RA-GZRS accounts.

Connectivity and Network Security

• Default State: Storage service endpoints are internet-facing by default.

• Storage Firewall: Restricts access to specific public IPv4 addresses or CIDR ranges.

  • Private IP addresses cannot be used in firewall rules.

  • CIDR ranges of $/32$ or $/31$ are not permitted.

  • Firewall applies to all endpoints (blobs, tables, queues, files).

  • Trusted Microsoft services (e.g., Azure Backup, Azure Site Recovery) can be granted access bypasses.

• Virtual Network Service Endpoints: Lock down a storage account to traffic from specific subnets in an Azure virtual network, removing public internet access.

  • Step 1: Enable the Microsoft.Storage service endpoint on the virtual network subnet.

  • Step 2: Configure permitted virtual networks/subnets in the storage account's Networking blade.

• Anonymous Access Levels: Specific to blob containers, separate from the firewall.

  • Private: No anonymous access.

  • Blob: Anonymous read access to individual blobs only.

  • Container: Anonymous read access to both blobs and the container listing.

  • Requirement: The "Allow Blob Anonymous Access" setting must be enabled at the storage account level first.

Shared Access Signatures and Access Policies

• Shared Access Signature (SAS) Token: A URI query string granting scoped, time-limited access without sharing account keys.

  • Controls include: accessible services, permissions, validity duration, and allowed IP addresses.

  • Requirement: Must always be distributed over HTTPS.

  • User Delegation SAS: Uses Entra ID credentials instead of account keys; supported only for Blob storage (containers and blobs).

• Stored Access Policies: Separates access parameters from the token itself.

  • Created on a container, table, queue, or file share.

  • Allows revocation of a SAS without regenerating account keys (by deleting/renaming the policy or changing expiry).

  • Propagation time for changes: up to $30$ seconds.

  • Limit: Maximum of $5$ stored access policies per resource.

• Access Keys: Every account has a primary and secondary key.

  • Possession of the name and one key grants full access.

  • Key Rolling: A zero-downtime strategy involving updating apps to use the secondary key while regenerating the primary key.

  • Regenerating a key immediately invalidates all associated SAS tokens.

  • Keys should be stored in Azure Key Vault (software-protected or HSM-protected).

  • BYOK: Bring Your Own Key refers to importing your own key to Azure Key Vault.

Identity-Based Access (Entra ID RBAC)

• Authentication: Entra ID returns an OAuth 2.0 token to authorize access. Supported for Blobs, Files, and Queues.

• Key Built-in Roles:

  • Storage Blob Data Owner: Full ownership and POSIX access control for Data Lake Storage Gen2.

  • Storage Blob Data Contributor: Read, write, and delete access to blobs.

  • Storage Blob Data Reader: Read-only access to blobs.

  • Storage Queue Data Contributor: Read, write, and delete access to queues.

  • Storage Table Data Contributor: Read, write, and delete access to tables/entities.

• Propagation: RBAC roles can take up to $5$ minutes to propagate after assignment.

Skill 2.2 — Configure and Manage Storage Accounts

• Redundancy Transitions: After creation, you can change replication modes between LRS, GRS, and RA-GRS. This happens asynchronously in the background.

• Object Replication: Asynchronous replication of block blobs between separate storage accounts based on rules.

  • Prerequisites: Blob versioning (source and destination) and Blob change feed (source).

  • Limitations: Does not work with Archive tier, snapshots, immutable blobs, or hierarchical namespaces (ADLS Gen2). Destination containers become read-only. Source can replicate to max $2$ destinations.

  • Rules: Up to $10$ rules via portal; up to $1000$ via JSON file.

• Storage Encryption: All data is encrypted using AES $256$-bit encryption (FIPS $140-2$ compliant). This cannot be disabled.

  • Customer-Managed Keys (CMK): Requires Azure Key Vault and a Managed Identity for the storage account.

Data Management Tools

• Azure Storage Explorer: Free cross-platform desktop GUI (Windows, macOS, Linux). Supports Blobs, Tables, Queues, Files, Cosmos DB, and ADLS.

• Storage Browser: Browser-based version within the Azure portal.

• AzCopy: Command-line utility for bulk transfers. It is fault-tolerant (resumes interrupted transfers).

  • azcopy login: Interactive authentication.

  • azcopy copy [local] [blob URL]: Upload file.

  • azcopy copy [blob URL] [local]: Download file.

  • azcopy sync [source] [dest]: Sync containers. Use --delete-destination to remove items in destination not present in source.

  • recursive=true: Flag for recursive folder uploads.

Skill 2.3 — Configure Azure Files and Azure Blob Storage

• Azure Files: Managed file shares supporting SMB $3.0+$, NFS, and REST API.

  • Port 445: Must be open for outside access. Often blocked by ISPs; workarounds include VPN or ExpressRoute.

  • Capacity: Standard shares default to $5$ TiB (can enable "large file share" for $100$ TiB). Premium shares default to $100$ TiB.

  • Mounting: Windows uses net use or cmdkey. Linux uses mount with cifs type.

• Blob Types (Type cannot be changed after creation):

  • Page Blobs: Optimized for random read/write. Used for VHD files for unmanaged disks. Max size: $8$ TiB.

  • Block Blobs: Optimized for general files/images/videos. Max size: approximately $190$ TiB.

  • Append Blobs: Optimized for append-only operations (logs). Max size: approximately $195$ GiB.

• Data Protection:

  • Soft Delete: Recovery for accidental deletions. Max retention: $365$ days. Azure Files default: $7$ days.

  • Blob Versioning: Scoped from $1$ to $365$ days (default $7$ days).

  • Point-in-time Restore: Reverts container objects. Requires versioning and change feed.

  • Snapshots (Files): Requires Azure Recovery Services vault and soft delete.

Configuring Lifecycle Management

• Logic: Uses automated "if-then" rules to transition blobs to cooler tiers or delete them based on last modification age.

• Limits: Max $100$ rules per account. Rules evaluated once per day.

• Timing: Policies take up to $24$ hours to go into effect, and actions take another $24$ hours to run ($48$ hours total).

Questions & Discussion: Thought Experiment

• Scenario: Design storage for an insurance company where everyone can read all department data, but users can only modify their own department's data. Data must be kept forever at lowest cost (rarely accessed after $2$ years).

• Solution Part 1 (Access): Create one container per department. Assign Storage Blob Data Reader role at the storage account level to everyone. Assign Storage Blob Data Contributor to each department group, but scope it only to their specific container.

• Solution Part 2 (Cost): Implement a lifecycle management rule. Set a condition to move blobs to the Archive tier after $730$ days ($2$ years) of no modification. This ensures long-term storage at the minimum possible cost.