Chapter 2

Implement and Manage Storage

Microsoft Azure Administrator (AZ-104) Study GuideBased on the Microsoft AZ-104 exam objectives

Storage is one of the most heavily tested areas of the AZ-104, worth roughly 15–20% of your exam score. Microsoft expects you to think like an administrator: choosing the right redundancy for a budget, locking down access with the correct combination of firewalls, SAS tokens, and identity controls, and managing the full lifecycle of blob and file data. This chapter builds that judgment call by call.

Storage Accounts: Types, Performance, and Redundancy

Every storage decision in Azure starts with the storage account — the container that holds all of your blobs, files, queues, tables, and disks, and the unit at which redundancy, encryption, and network rules are configured. Pick the wrong account type or redundancy option and you either overpay for years or discover too late that your data was never as protected as you assumed.

Storage account types

When you create a storage account you choose a performance tier and an account kind. The common combinations are:

• Standard general-purpose v2 (StorageV2). The default and the most flexible. Supports blobs (including Data Lake Storage Gen2 with hierarchical namespace), Azure Files, queues, tables, and disks. This is the right answer for most general workloads.
• Premium block blobs. SSD-backed, for high-throughput blob workloads such as big data analytics, media transcoding, or machine learning. Supports only block blobs and append blobs — not page blobs, files, queues, or tables.
• Premium file shares. SSD-backed, for Azure Files workloads that need consistently low latency and high IOPS, such as lift-and-shift file servers or databases on file shares.
• Premium page blobs. SSD-backed, for page blobs only — which in practice means unmanaged virtual machine disks. (Managed disks are the norm today, so you will rarely create one of these directly.)
• Standard general-purpose v1 (legacy) and BlobStorage (legacy) still exist but offer no advantage over StorageV2 for new deployments.

Performance tiers

Standard uses magnetic (HDD-based) media and is the economical choice for most data. Premium uses solid-state drives and delivers low, consistent latency. You choose the tier at creation and cannot change it afterward — a Standard account can never become Premium. Match the tier to the workload's latency and throughput requirements, not to the amount of data: a huge archive belongs on Standard, while a small but latency-sensitive database belongs on Premium.

Redundancy options

Redundancy is how Azure copies your data, and it is the single most tested storage topic. There are six options:

Key behaviors to internalize:

• Synchronous replication (LRS, ZRS) means a write is not acknowledged until all copies are written — slightly higher write latency, but no data loss window. Asynchronous replication (the geo part of GRS/GZRS) copies to the secondary region in the background, so there is a small recovery point objective (RPO), typically under 15 minutes but not guaranteed.
• ZRS requires a region with availability zones and is only offered on certain account types. Premium block blobs and premium file shares support LRS and ZRS only — there is no geo-redundant premium option. Premium page blobs support LRS only.
• With RA-GRS or RA-GZRS you get a second endpoint (-secondary) that your applications can read from at any time, not just during failover. Microsoft controls failover to the secondary region; you can initiate an account failover yourself, but it is a disruptive, last-resort operation.

Account creation constraints

Several choices are locked in at creation time and cannot be changed later:

• Storage account name: 3–24 characters, lowercase letters and numbers only, globally unique across all of Azure.
• Performance tier (Standard vs Premium): permanent.
• Account kind: you can upgrade GPv1 to GPv2, but you cannot convert between Standard and Premium, and you cannot change a premium block blob account into a premium file share account.
• Hierarchical namespace (Azure Data Lake Storage Gen2): enabled at creation on a StorageV2 account; it cannot be turned on later, and it cannot be disabled once enabled. In-place upgrades of existing accounts are not supported.
• Infrastructure encryption (double encryption): must be enabled at creation; it cannot be added to an existing account.
• Redundancy can be changed after creation for most conversions (for example LRS to GRS, or GRS to RA-GRS), but conversions involving premium tiers or to ZRS in unsupported regions are blocked — always verify before promising a customer it can be done later.

Securing Storage Access

Storage accounts hold some of an organization's most sensitive data, and the AZ-104 tests your ability to layer defenses: network controls decide who can reach the account, while SAS tokens, keys, and Entra authentication decide what they can do once they arrive. A question will often give you a requirement — "partners need read access to one container for 48 hours" — and expect you to select the most precise, least-privilege mechanism.

Storage firewalls and virtual network rules

Every storage account has a firewall under Networking. The default is to allow access from all networks; hardening it means switching the default action to Deny and then punching precise holes:

• IP network rules: allow specific public IP addresses or ranges.
• Virtual network rules: allow traffic from specific subnets. The subnet must have the Microsoft.Storage service endpoint enabled for this to work.
• Resource instance rules: allow specific Azure resource instances (such as a particular Azure Data Factory or Event Grid) to reach the account.
• Exceptions: you can allow trusted Microsoft services (backup, Site Recovery, Azure DevOps, and others) to bypass the firewall when they need access.

Private endpoints vs service endpoints

Both connect a virtual network to storage privately, but they work very differently:

• Service endpoints extend your virtual network's identity to the Azure Storage service over the Azure backbone. Traffic never traverses the public internet, but the storage account still uses its public endpoint — the service simply recognizes that the traffic comes from your VNet. No DNS changes are needed, and there is no extra cost. Service endpoints are also the prerequisite for VNet firewall rules.
• Private endpoints assign a private IP address from your VNet to the storage account, so the account is reachable only inside your network. This requires private DNS configuration (a private DNS zone for privatelink.blob.core.windows.net and similar) so the storage hostname resolves to the private IP. Private endpoints work from on-premises over VPN or ExpressRoute and are the stronger isolation option — the right choice when a compliance requirement says the storage account must not be reachable from the public internet at all.

SAS tokens: the three types

A shared access signature (SAS) is a signed URI that grants delegated access without revealing the account key. There are three types, and confusing them is one of the exam's favorite traps:

1. User delegation SAS — secured with Microsoft Entra credentials instead of the account key. Scoped to blob storage only (containers and blobs), and the user delegation key used to sign it is valid for a maximum of 7 days. This is the recommended SAS type whenever possible, because it never exposes the account key and it honors Azure RBAC: the user signing it must already have the appropriate data-plane permissions.
2. Service SAS — secured with the storage account key. Scoped to a specific resource: a container, blob, file share, queue, or table, with granular permissions (read, write, delete, list, and more). Can be bound to a stored access policy for server-side revocation.
3. Account SAS — secured with the storage account key. Broadest scope: it can delegate access to multiple services (blob, file, queue, table) at the account level. Cannot be bound to a stored access policy. Use it only when a service SAS cannot cover the need.

Best practices the exam expects you to know: always set the shortest expiry the scenario allows, always require HTTPS, restrict to the minimum permissions and narrowest scope, prefer user delegation SAS over account SAS, and never embed a SAS in client-side code where it can be harvested.

Stored access policies

A stored access policy groups the start time, expiry time, and permissions for service SAS tokens on a container, file share, queue, or table. Instead of baking those values into each SAS URI, the SAS references the policy by name. The payoff: you can revoke or modify all SAS tokens bound to the policy by changing or deleting the policy — no key regeneration required. Limits to remember: up to 5 stored access policies per container (or share/queue/table), and account SAS tokens cannot use them.

Note the subtle trap: if fifty SAS tokens all reference the same stored access policy, deleting that policy revokes all fifty. Selective revocation requires separate policies per token or per client.

Access key rotation

Every storage account has two access keys (key1 and key2), and either one grants full control — which is why keys should be a last resort, not a daily driver. The safe rotation procedure the exam expects:

1. Identify which key the application currently uses (say, key1).
2. Update the application to use the other key (key2) first and verify it works.
3. Regenerate key1.

There is never a moment when the application's active key is invalid, so rotation causes zero downtime. Regenerating the key the application is actively using is the classic wrong answer.

Microsoft Entra authentication for storage

For human users and managed workloads, Entra authentication is preferred over keys and SAS. It works through Azure RBAC data-plane roles — the management-plane roles you know from earlier chapters are not enough:

• Storage Blob Data Reader / Contributor / Owner for blob data.
• Storage File Data SMB Share Reader / Contributor / Elevated Contributor for Azure Files share access.
• Storage Queue Data Contributor, Storage Table Data Contributor, and similar for the other services.

The critical distinction: Contributor on a storage account lets you manage the account (rotate keys, change firewall rules) but does not let you read a single blob — blob content lives on the data plane. Assigning Contributor to someone who needs to read blobs is both insufficient and over-privileged; the least-privilege answer is Storage Blob Data Reader.

You can also harden the account itself: disabling shared key access (Allow storage account key access = Disabled) forces all clients to use Entra or SAS-with-policy authentication, and the account keys become unusable. This is the recommended posture for regulated environments.

Blob Storage

Blob storage is Azure's object store: massive scale, tiered pricing, and the home of backups, media, logs, datasets, and static websites. The exam focuses less on "what is a blob" and more on the cost-control machinery — access tiers, rehydration, lifecycle policies — and the three mechanisms that protect blob data: versioning, snapshots, and soft delete.

Containers and blobs

Blobs live in containers, which are roughly analogous to folders with access policies. Container names must be lowercase. There are three blob types:

• Block blobs — the default; for text, media, backups, and general data. This is what access tiers and lifecycle management apply to.
• Append blobs — optimized for append operations, such as logging.
• Page blobs — random read/write, used for virtual machine disks.

A container's public access level can be Private (default), Blob (anonymous read of blobs only), or Container (anonymous read of blobs and listing). The exam occasionally checks that you know anonymous access is off by default and must be explicitly enabled at both the account and container level.

Access tiers: Hot, Cool, Cold, Archive

Every block blob sits in an access tier that trades storage cost against access cost and retrieval speed:

• Hot — frequent access. Highest storage price, lowest access cost, instant retrieval. No minimum storage duration.
• Cool — infrequent access (backups, older media). Lower storage price, higher access cost. 30-day minimum storage duration — delete or move a blob sooner and you are still charged for 30 days.
• Cold — rarely accessed data kept online (compliance archives you might actually read). Lower still. 90-day minimum.
• Archive — offline tier for data that is almost never accessed. Cheapest storage by far, but the blob is not readable until rehydrated, and retrieval is slow and expensive. 180-day minimum.

You can set the tier per blob or set a default account tier (Hot or Cool only — Cold and Archive cannot be the account default). Moving a blob to a cooler tier is free-ish; the early-deletion clock is what punishes mistakes.

Rehydration: getting data out of Archive

An archived blob must be rehydrated to Hot, Cool, or Cold before it can be read. Two methods:

1. Copy the blob to a new blob in the target tier (or the same blob with a new tier) using the Copy Blob operation, specifying a rehydration priority.
2. Change the blob's tier to Hot on the existing blob (Set Blob Tier) — this also triggers rehydration.

Priorities and timing:

• Standard priority — rehydration can take up to 15 hours.
• High priority — rehydration typically completes in under 1 hour for blobs smaller than 10 GB, at a higher retrieval cost.

During rehydration the blob stays in Archive and remains unreadable; only when the copy completes does the target become available. You cannot rehydrate directly within Archive, and you cannot prioritize a tier-change the way you can a copy — priority is set on the copy operation.

Lifecycle management policies

Lifecycle management automates tier transitions and deletion for block blobs (in GPv2, BlobStorage, and premium block blob accounts) using JSON rules with two action types:

• Tier to Cool / Cold / Archive — move blobs based on age (days since last modification or last access, if access tracking is enabled).
• Delete — remove blobs (and optionally snapshots/versions) after a set age.

A typical policy: tier blobs to Cool after 30 days without modification, to Archive after 180 days, delete after 7 years. Filters can target prefixes (e.g., logs/) or blob index tags. Lifecycle management is the exam's expected answer whenever a requirement says "automatically" move or delete aging data — manual tier changes or scripts are the distractors.

Blob versioning vs snapshots vs soft delete

Three different safety nets, three different behaviors — the exam will ask you to pick between them:

• Blob versioning — automatic. When enabled at the account level, every write, overwrite, or delete creates a new version and preserves the previous one. Ideal for the "nightly ETL job overwrites blobs and we must keep every prior copy" scenario. Previous versions are billed at their tier's rates, and lifecycle policies can clean them up.
• Snapshots — manual point-in-time, read-only copies of a blob, taken on demand or by script. Ideal for "take a copy before a risky change so we can roll back." Snapshots are incremental (only changed blocks consume extra space).
• Soft delete for blobs — a retention safety net. Deleted blobs (and optionally deleted containers and snapshots) are retained in a recoverable state for a configurable 1–365 days, then permanently removed. It protects against accidental deletion, not against overwrites — for overwrites you need versioning.

Object replication

Object replication asynchronously copies block blobs between containers — in the same account, across accounts, across regions, or across subscriptions. Requirements:

• Blob versioning must be enabled on both source and destination accounts.
• Supported on standard GPv2 and premium block blob accounts.
• You define a replication policy on the source account listing destination containers and optional filters (prefix match).

Replication is one-way and eventual; it is a data-distribution and regional-availability mechanism, not a backup — a deleted source blob's delete marker replicates too, so pair it with soft delete or versioning retention for true protection.

Azure Files

Azure Files provides fully managed SMB and NFS file shares in the cloud — the lift-and-shift answer for applications that expect a traditional file share, and the backbone of scenarios like shared configuration stores, user profile disks (FSLogix), and hybrid file servers.

File share tiers

Unlike blob tiers, file share tiers are chosen at the share level (or via the account for premium):

• Premium — SSD-backed, provisioned IOPS and throughput. For latency-sensitive workloads: databases on shares, VDI profiles, high-throughput line-of-business apps. Supports SMB and NFS.
• Transaction optimized — HDD-backed, for transaction-heavy workloads where each operation is small (the old "Hot" HDD tier renamed).
• Hot — HDD-backed, general-purpose file shares with balanced storage and transaction costs.
• Cool — HDD-backed, for infrequently accessed file data (backups of shares, archival file data) at lower storage cost.

The exam's angle is usually cost: a share holding rarely-read archives belongs on Cool, not Premium. And note the asymmetry with blobs — file shares have no Archive tier and no rehydration concept.

Identity-based access

By default, Azure Files authenticates with the storage account key — which grants full admin control and cannot be scoped to a single share. For real user access, Azure supports identity-based authentication so domain users get per-share NTFS-style permissions:

• On-premises AD DS — join the storage account to your existing Active Directory domain. Best when users and the file infrastructure already live on-prem.
• Microsoft Entra Domain Services (Entra DS) — a managed domain in Azure; the storage account joins it. Best for cloud-only environments that still need Kerberos/NTLM semantics.
• Microsoft Entra Kerberos — users authenticate directly with their Entra ID identities for hybrid identities, without deploying domain controllers or Entra DS. Best for new hybrid deployments that want to avoid domain infrastructure.

Once identity auth is enabled, you assign share-level RBAC roles (Storage File Data SMB Share Reader/Contributor/Elevated Contributor) and then set NTFS ACLs on folders and files for fine-grained control. Both layers must allow access — RBAC gets you to the share, NTFS decides what you can touch inside it.

SMB and NFS protocols

• SMB (2.1, 3.0, 3.1.1) is the default and works from Windows, Linux, and macOS. SMB 3.x adds encryption in transit. Azure Files SMB shares can be mounted directly over the internet (port 445) or privately.
• NFS v4.1 is supported on premium file shares only, aimed at Linux workloads that need POSIX semantics. NFS shares do not support identity-based access the way SMB does — access is controlled at the network level.

Snapshots and soft delete for shares

• Share snapshots are manual, point-in-time, read-only copies of an entire file share — the file equivalent of blob snapshots. Taken before changes or on a schedule via script or Azure Backup.
• Soft delete for Azure Files retains deleted shares (not individual files) for a configurable retention period, protecting against accidental share deletion. For file-level recovery within a share, use snapshots or Azure Backup.

Azure File Sync basics

Azure File Sync extends Azure Files to on-premises Windows Servers:

• A Storage Sync Service in Azure manages sync groups; each sync group has one cloud endpoint (the Azure file share) and one or more server endpoints (folders on registered Windows Servers).
• Cloud tiering optionally keeps only frequently accessed files on the local server, recalling the rest from Azure on demand — letting a small on-premises disk front a much larger cloud share.
• It is a sync service, not backup: a file deleted on one endpoint deletes everywhere (subject to soft delete/snapshots). The exam tests this distinction — "we need deleted files recoverable" points to snapshots or backup, not to File Sync alone.

Moving Data into Azure

Getting data into (and around) Azure efficiently is an administrator's bread and butter. The exam covers three mechanisms: AzCopy for online transfers, Storage Explorer for interactive work, and the Import/Export service for offline bulk ingest.

AzCopy

AzCopy is the command-line utility for high-performance blob and file transfers. Core patterns:

azcopy copy "C:\data\logs" "https://mystorage.blob.core.windows.net/logs<SAS>" --recursive=true
azcopy sync "C:\data\logs" "https://mystorage.blob.core.windows.net/logs<SAS>" --recursive=true --delete-destination=true

• copy duplicates the source to the destination. sync makes the destination match the source — with --delete-destination=true it also removes files at the destination that no longer exist at the source, which is exactly what a mirror or replica job needs.
• Authentication options, in order of preference: Microsoft Entra ID (azcopy login — interactive or service principal), a SAS token appended to the URL, or the account key. The exam rewards Entra ID and penalizes hardcoded keys.
• AzCopy works across storage accounts, subscriptions, and even clouds (AWS S3 to Azure Blob), and it automatically parallelizes transfers for throughput.

Azure Storage Explorer

Storage Explorer is the free, cross-platform GUI for browsing and managing storage accounts: upload/download blobs and files, manage tables and queues, generate SAS tokens, and attach to accounts via key, SAS, or Entra sign-in. On the exam it appears as the answer to "an administrator needs an interactive tool to manage storage without writing code" — or as the tool used to create a SAS in a scenario.

Import/Export service and Data Box

When the dataset is too large for the network (terabytes, or a slow uplink), ship it:

• Azure Import/Export — you copy data to encrypted hard drives you own and ship them to an Azure datacenter for import into Blob storage (or export from Blob storage to drives you receive). Drives are encrypted with BitLocker.
• Azure Data Box — Microsoft ships you a ruggedized appliance (tens of terabytes) for large one-time migrations; Data Box Heavy scales further for petabyte-scale moves.

The exam's decision rule is volume and bandwidth: gigabytes over a good link → AzCopy; terabytes or a saturated/expensive link → Import/Export or Data Box.

Encryption

Encryption at rest is on by default for every storage account — but the AZ-104 expects you to know whose key is doing the encrypting, when double encryption applies, and how to scope different keys to different data.

Microsoft-managed keys vs customer-managed keys

• Microsoft-managed keys (default): Azure generates, stores, and rotates the encryption keys automatically. Zero configuration, suitable for most workloads.
• Customer-managed keys (CMK): you store your keys in Azure Key Vault (or Managed HSM) and point the storage account at them. You control the key lifecycle: you can rotate on your schedule, and you can revoke access instantly by disabling the key — rendering the data unreadable. CMK is the answer whenever a requirement mentions customer control of keys, revocation, or compliance mandates like "we must be able to make the data cryptographically inaccessible on demand."

CMK requirements worth memorizing: the key vault must have soft delete and purge protection enabled, and the storage account needs a managed identity (system- or user-assigned) with key permissions on the vault. Key rotation can be automatic (set an expiry/rotation policy on the key) or manual (create a new key version and update the account).

Infrastructure encryption

Infrastructure encryption adds a second layer of encryption at the physical infrastructure level, on top of the standard service-level encryption — true double encryption at rest. It must be enabled at storage account creation and cannot be added later. It is only available on certain account configurations. The exam tests the creation-time constraint: "can you enable it on the existing account?" — no.

Encryption scopes

Encryption scopes let you assign different encryption keys to different containers or blobs within one storage account — for example, each department's container encrypted with its own CMK, while the rest of the account uses Microsoft-managed keys. A blob uploaded with an encryption scope inherits that scope; the default scope applies when none is specified. This is the answer to "different keys for different datasets in the same account" without the cost and complexity of separate storage accounts.

Worked Scenarios

Worked scenario 1: Ransomware-proof backup storage

Situation: Your company keeps nightly VM backups as block blobs in a Cool-tier container. After a ransomware scare, leadership requires that (a) backups survive even if an attacker gains Contributor access to the subscription, and (b) storage costs drop because backups older than 90 days are never read.

Reasoning, step by step:

1. Surviving a compromised Contributor: Soft delete for blobs (with a long retention, e.g., 180 days) means even deleted blobs remain recoverable — but a Contributor could disable soft delete. Stronger: immutability policies (time-based retention) on the container make blobs undeletable until the retention period expires, and no role — not even Owner — can override a locked time-based policy. That directly answers requirement (a).
2. Cutting cost on old backups: A lifecycle management policy tiers blobs to Archive after 90 days without modification. Archive storage is the cheapest available, and since backups older than 90 days are never read, the retrieval penalty never materializes.
3. Key hygiene: Disable shared key access and require Entra authentication with Storage Blob Data roles, so a leaked account key alone grants nothing.

Answer in exam terms: time-based immutability policy (locked) + lifecycle policy (Cool → Archive at 90 days) + Entra-only authentication.

Worked scenario 2: Partner access to one container for a weekend

Situation: An external partner must upload analysis files to a single blob container Friday through Sunday. They are outside your network, have no Entra identities in your tenant, and must have zero access afterward without you chasing them to revoke anything.

Reasoning, step by step:

1. No Entra identities rules out user delegation SAS (it requires the signer to authenticate with Entra, and the partner has no identity). It also rules out RBAC roles.
2. Single container, write-only need, automatic expiry points to a service SAS scoped to that container with Write (and List, so they can verify uploads) permissions and an expiry of Sunday night.
3. Zero access afterward without manual revocation: a short-lived SAS simply expires. For defense in depth, bind it to a stored access policy so you can revoke early if the engagement ends Friday — and set the storage firewall to Deny with no exception for the partner's network? No — they need network access. Instead, restrict the SAS to HTTPS only and the minimum permissions.
4. The partner's IP changes frequently, so IP-restricted SAS is impractical; the short expiry is the control.

Answer in exam terms: service SAS (container-scoped, Write + List, 48–72 hour expiry, HTTPS-only), optionally bound to a stored access policy for early revocation.

Worked scenario 3: File shares for a hybrid workforce

Situation: 400 users — half on domain-joined Windows laptops managed by on-premises AD, half remote-only with Entra ID identities and no domain join — need mapped-drive access to departmental file shares with per-folder permissions. Latency matters; the file server being replaced was all-flash.

Reasoning, step by step:

1. Mapped-drive semantics with per-folder permissions means Azure Files with SMB and NTFS ACLs — blob storage cannot do this.
2. All-flash performance points to the Premium file share tier (provisioned IOPS/throughput), not Transaction optimized or Hot.
3. Mixed identities: the on-prem AD users are covered by joining the storage account to on-premises AD DS; the remote-only Entra ID users are covered by Microsoft Entra Kerberos — both can coexist, giving every user single sign-on with their own identity.
4. Per-folder permissions: assign the Storage File Data SMB Share Elevated Contributor (or Contributor) role at the share, then set NTFS ACLs on each department folder. RBAC alone cannot express folder-level permissions — a classic exam trap.
5. Private access: remote users connect over VPN/ExpressRoute to a private endpoint so share traffic never crosses the public internet.

Answer in exam terms: Premium Azure Files + SMB, on-prem AD DS join plus Entra Kerberos, share-level RBAC + NTFS ACLs, private endpoint for network isolation.

End-of-Chapter Test

1. You need to store virtual machine disks with geo-redundant replication. Which storage account configuration should you choose?

A) Premium page blobs with GRS B) Standard general-purpose v2 with GRS C) Premium block blobs with GZRS D) Standard general-purpose v2 with ZRS

1. A company policy requires that no storage account be reachable from the public internet, including from on-premises offices connected via ExpressRoute. What should you deploy?

A) A service endpoint for Microsoft.Storage on each virtual network B) A private endpoint for the storage account with private DNS configured C) Storage firewall IP rules allowing only the ExpressRoute public IPs D) A service SAS restricted to the on-premises IP range

1. You must grant a contractor read access to blobs in one container for exactly 7 days. The contractor has no Entra identity in your tenant, and you want the ability to revoke access early without regenerating the account key. What should you use?

A) An account SAS with a 7-day expiry B) A user delegation SAS with a 7-day expiry C) A service SAS bound to a stored access policy D) The storage account key shared via a secure channel

1. A blob in the Cool tier was uploaded 10 days ago and is deleted today. For how many days of Cool storage will you be billed?

A) 10 days B) 30 days C) 90 days D) 180 days

1. The legal team needs a 4 GB blob restored from the Archive tier within 3 hours. What should you do?

A) Copy the blob to the Hot tier using Standard priority rehydration B) Copy the blob to the Hot tier using High priority rehydration C) Change the blob's access tier to Cool and wait D) Enable blob versioning and restore the previous version

1. A nightly ETL process overwrites blobs in a container, and auditors require every previous version of each blob to be preserved automatically. What should you enable?

A) Soft delete for blobs with a 90-day retention period B) Blob versioning on the storage account C) Manual snapshots before each ETL run D) A lifecycle management policy that deletes old blobs

1. You need different encryption keys for the finance container and the marketing container within the same storage account. What should you use?

A) Two separate storage accounts with different Microsoft-managed keys B) Infrastructure encryption with two key vaults C) Encryption scopes with a customer-managed key per container D) A lifecycle management policy with key rotation rules

1. An application running on-premises needs to read blobs. The storage firewall denies all public networks, and the application cannot use Entra authentication. The application presents a valid SAS token but receives an authorization failure. What is the most likely cause?

A) The SAS token has expired B) The SAS permissions do not include Read C) The application's public IP is blocked by the storage firewall D) The SAS was created as a user delegation SAS instead of a service SAS

1. You are designing storage for a database workload that requires single-digit millisecond latency and must survive the loss of an entire datacenter without leaving the region. Which redundancy option fits at the lowest cost?

A) LRS on a Premium block blob account B) ZRS on a Premium block blob account C) GRS on a Standard general-purpose v2 account D) RA-GZRS on a Standard general-purpose v2 account

1. A storage account contains both frequently accessed web content and regulatory archives that must be kept for 7 years but are almost never read. What is the most cost-effective design?

A) Store everything in the Hot tier on a Premium block blob account B) Store web content in Hot and use a lifecycle management policy to tier archives to Archive after a set period C) Store everything in the Cool tier and manually rehydrate archives when needed D) Create two storage accounts, both using the Archive tier

1. Your security team requires the ability to instantly render all data in a storage account unreadable in the event of a suspected breach, without deleting the data. What should you implement?

A) Microsoft-managed keys with automatic rotation B) Customer-managed keys in Azure Key Vault with the ability to disable the key C) Infrastructure encryption enabled on the storage account D) A storage firewall with default action set to Deny

1. Remote users with only Microsoft Entra ID identities (no on-premises domain) need mapped-drive access to Azure file shares with single sign-on, and you cannot deploy domain controllers. Which identity solution should you use?

A) Join the storage account to on-premises AD DS B) Microsoft Entra Domain Services C) Microsoft Entra Kerberos D) Storage account key authentication with SMB

Answer Key

1. B — Page blob (VM disk) storage with geo-redundancy requires a Standard GPv2 account: premium page blobs support LRS only, and premium block blobs support only LRS/ZRS.
2. B — A private endpoint gives the storage account a private VNet IP and, with private DNS, removes all public-internet reachability, including over ExpressRoute. Service endpoints still use the public endpoint address.
3. C — A service SAS is container-scoped and, bound to a stored access policy, can be revoked early without key regeneration. User delegation SAS requires Entra identities; account SAS cannot use stored access policies.
4. B — Cool tier carries a 30-day minimum storage duration; deleting after 10 days still bills 30 days.
5. B — Standard priority rehydration can take up to 15 hours, missing the 3-hour deadline; High priority completes in under an hour for blobs under 10 GB.
6. B — Blob versioning automatically preserves a prior version on every overwrite. Soft delete protects against deletion, not overwrites; snapshots are manual.
7. C — Encryption scopes assign different customer-managed keys to different containers in one account. Separate accounts are unnecessary overhead for this requirement.
8. C — Network rules are evaluated before authentication: a valid SAS cannot bypass the storage firewall, so a blocked client IP produces an authorization failure.
9. B — ZRS replicates synchronously across three availability zones in-region, surviving datacenter loss; premium block blobs deliver the required latency. LRS cannot survive datacenter loss; GRS/GZRS add unneeded geo cost.
10. B — Lifecycle management automatically tiers aging blobs to Archive (cheapest long-term storage) while web content stays Hot. Archive-tier data is unreadable without rehydration, so putting web content there (D) breaks the site.
11. B — Disabling a customer-managed key in Key Vault instantly renders the data cryptographically inaccessible without deleting it. Microsoft-managed keys offer no customer revocation switch.
12. C — Microsoft Entra Kerberos gives Entra ID-only users Kerberos SSO to Azure Files without domain controllers or Entra DS. On-prem AD DS requires an existing domain; account keys provide no single sign-on.