Implement security for storage accounts

An account key pasted into a public repository is enough to read every blob in the account, unless one of the other controls on that account refuses the request first. Storage security is not one switch: its settings span five controls, and the useful question in any scenario is which of them is missing.

The five, in the order they apply:

1. Transport. Secure transfer required rejects plain HTTP, and the account's minimum TLS version sets the floor for the handshake (Require secure transfer^[1]).
2. Network admission. The storage firewall decides whether this source may reach the account's public endpoint at all (Azure Storage firewall rules^[2]).
3. Authorization. Microsoft Entra ID with role-based access control (RBAC), or a signed token, decides whether this caller may perform this operation (Authorize access to data^[3]).
4. Data protection. Encryption at rest, soft delete, versioning, and immutable storage decide how the bytes are encrypted and how long an earlier state survives (Azure Storage encryption^[4]).
5. Threat detection. Microsoft Defender for Storage analyzes access telemetry and, with malware scanning turned on, the uploaded content itself (What is Microsoft Defender for Storage^[5]).

Transport, network admission, and authorization can each refuse an individual request; data protection and threat detection act on data already written and on the telemetry around it. Network admission and authorization are the two gates that must both pass, and passing one says nothing about the other. That is the sentence to keep: an allowed network is not a permission, and a permission is not a network path. The figure below traces one request through the five and groups the ones that act on stored data rather than on the request.

The terms data plane and control plane appear throughout this page. Data-plane operations read and write the contents of the account, over REST endpoints such as blob.core.windows.net or over SMB for Azure Files. Control-plane operations manage the account resource itself through Azure Resource Manager: creating it, changing its firewall, listing its access keys. The two are governed separately, and mixing them up is the single most productive trap on this objective.

Two of this domain's sibling pages own the surface next door. Implement security for databases owns Azure SQL platform security, auditing, and Defender for Databases; Implement security for Azure network services owns the virtual network machinery itself, network security groups (NSGs), Azure Firewall, and private endpoints. This page owns the storage account: its own firewall, how its data operations are authorized, how deleted data is recovered or made unchangeable, and Defender for Storage.

That seam carries a difference worth stating before it bites. An NSG evaluates its rules in priority order and stops at the first match, so exactly one rule decides the outcome. The storage firewall has no priorities and no deny entries: it has a default action, plus a set of allow entries, and a request is admitted when any entry matches it. When a scenario puts both objects in the same sentence, ask which one is doing the deciding.

If you can name which of the five controls a setting belongs to, you can usually name what it does not do, and that is where most of the exam's distractors live.

Encryption at rest is not something you turn on. Azure Storage encrypts all data written to it with 256-bit AES, always, for blobs, files, queues, and tables, and the encryption cannot be disabled (Azure Storage encryption for data at rest^[4]). What you actually configure are two different things: who owns the key, and how many independent layers wrap the data. Those two choices, together with the transport settings, are the first control and the encryption half of the fourth: this section covers what protects the bytes, while recovering or freezing them comes later. In transit, the two settings are equally narrow, and they are separate from each other.

In transit: two settings, two jobs

Secure transfer required makes the account reject requests that arrive over HTTP, so REST calls must use HTTPS (Require secure transfer^[1]). The setting is enabled by default on newly created accounts, and for Azure Files it also refuses SMB connections that are not encrypted.

The minimum TLS version is a separate setting that fixes the floor for the handshake rather than deciding whether encryption is used at all (Enforce a minimum TLS version^[6]). Set it to TLS 1.2. Azure Storage supports TLS 1.3 and a capable client negotiates it automatically, but 1.2 is the highest value the account's minimum-version setting accepts, so a requirement worded as "enforce TLS 1.3" is not satisfiable through this setting. Raising the floor is the classic wrong answer to "block unencrypted requests", because a client speaking HTTP never reaches a TLS handshake at all.

At rest: who owns the key

By default the account encryption key is Microsoft-managed. A customer-managed key changes ownership, not strength: you store a key in Azure Key Vault or Managed HSM, and Azure Storage uses it to wrap the account encryption key, so revoking or rotating your key controls access to the data (Customer-managed keys for Azure Storage encryption^[7]). The key vault must have both soft delete and purge protection enabled, and the storage account reaches the key through a managed identity holding get, wrapKey, and unwrapKey permissions. Disabling the key makes data operations fail with 403 rather than corrupting anything, and you can switch between Microsoft-managed and customer-managed keys at any time.

An encryption scope narrows that choice below account level: it applies its own key, Microsoft-managed or customer-managed, to a container or to individual blobs (Encryption scopes^[8]). Use one when a single account holds data belonging to different tenants or classifications that must not share a key.

At rest: how many layers

Infrastructure encryption is the second layer. With it enabled, Azure encrypts the data twice, once at the service level and once at the infrastructure level, with separate keys, so a single compromised key or algorithm implementation does not expose the data (Enable infrastructure encryption^[9]). Account-level infrastructure encryption can only be enabled when the account is created, which makes account-wide double encryption a design decision rather than a remediation; in an existing account, infrastructure encryption can instead be enabled for a new encryption scope. A customer-managed key is not a substitute: it changes who holds the service-level key without adding a layer. The figure below shows how the two stack.

For Blob Storage there is a third option worth recognizing even though it is rarer in practice: with customer-provided keys, a client supplies an encryption key on each individual read and write request, and Azure uses it for that operation without storing it (Customer-provided keys^[10]).

Taken together: the transit settings decide what a client may speak, key ownership decides who can revoke access, and layer count decides how much independent protection sits under a single key compromise. A scenario that names a compliance requirement for double encryption wants infrastructure encryption; one that names control of rotation wants a customer-managed key.

Network rules have no effect until the default action is Deny. Everything else in this section depends on that one line, because an account whose default action is still Allow already permits every source, so adding allow entries changes nothing (Set the default public network access rule^[11]). In the portal the equivalent choice is Networking, then public network access: Enabled from all networks, Enabled from selected networks, or Disabled. In the CLI it is --default-action Deny; in PowerShell, -DefaultAction Deny.

Once the default is Deny, four kinds of network rule can let traffic back in (Azure Storage firewall rules and network access^[2]):

• A virtual network rule admits a subnet.
• An IP network rule admits a public IPv4 address or range.
• A resource instance rule admits one specific Azure resource that cannot be described by a subnet or an address.
• A trusted-service exception admits trusted Azure services, typically so they can write or read resource logs and metrics.

There are no priorities and no deny entries in that list: a request is admitted when any entry matches it, which is the contrast with the priority-ordered, first-match NSG evaluation described on the sibling network services page. The figure below traces the admission decision end to end.

A virtual network rule is two configurations

Allowing a subnet takes a rule on the storage account and a service endpoint on the subnet, and they live in different resources. A service endpoint is not a private endpoint: it is a property of the subnet that makes this firewall rule work, while a private endpoint is a separate way of reaching the account, covered on the sibling network services page. The endpoint type matters: Microsoft.Storage reaches storage accounts in the same region as the virtual network, while Microsoft.Storage.Global reaches accounts in any region, and a subnet can carry only one of the two (Virtual Network service endpoints^[12]). The Azure portal creates the endpoint for you as you select the subnet; PowerShell and the Azure CLI do not, which is why a scripted deployment so often ends with a correct-looking rule and a subnet that still gets 403. An account supports up to 400 virtual network rules.

Enabling a service endpoint has a second-order effect that surprises people. Traffic from that subnet stops using a public source address, so any IP rule that used to admit it no longer applies.

IP rules only speak public IPv4

Each IP network rule admits a public IPv4 range, up to 400 per account, and the usual case is an on-premises network reached through its internet-facing addresses or its ExpressRoute NAT addresses. Two restrictions turn up constantly in scenarios: private RFC 1918 addresses are rejected, and IP rules do not restrict requests from Azure clients in the same region as the storage account (Restrictions for IP network rules^[13]). A virtual machine in the account's own region is therefore not something you can select with an IP rule at all; that case wants a virtual network rule or private connectivity.

Resource instance rules and the trusted-service exception

Some Azure resources have no stable address and live in no subnet of yours. A resource instance rule names one such resource, and the role assignments held by that resource decide what it may then do with the data; the resource must be in the same tenant as the storage account, though it may sit in any subscription in that tenant (Create a resource instance network rule^[14]).

The trusted-service exception is broader: it admits a documented list of Microsoft services that connect with strong authentication (Trusted Azure services^[15]). It is a network path and nothing more. A trusted service still needs a role assignment or a token to read data, and treating the exception as an authorization step is a distractor the exam reuses.

What the firewall does not cover

Firewall rules are enforced on data-plane traffic: REST calls to the blob, file, queue, and table endpoints, and SMB for Azure Files. They do not restrict Azure Resource Manager operations against the account resource, so an administrator can still change the firewall itself, read the access keys, or delete the account from anywhere the control plane accepts them. Those need role assignments, resource locks, and Azure Policy instead.

A private endpoint is the other way to reach the account, and it belongs to the sibling page on Azure network services; the point to carry here is that adding one does not close the public endpoint. Public network access is its own setting, and only Disabled shuts the public door (Use private endpoints for Azure Storage^[16]). Even then, resource instance rules and trusted-service exceptions configured before that switch remain in effect, so those resources might still reach the account (Storage network security restrictions^[13]). Firewall changes also take up to a minute to take effect after you save them, which is worth knowing before you conclude a rule did not work.

In short: default action first, then the narrowest entry that admits the traffic you actually need, and never mistake either step for a permission.

Assigning Contributor to a team so they can "get to the data" is the most expensive mistake on this objective, and not for the reason people expect. The role does not authorize a single data operation through Microsoft Entra ID; it authorizes the caller to read the account keys, and from there everything is possible. Data authorization and account management are different scopes, and this section is about keeping them apart.

Data roles, not management roles

To authorize blob, queue, table, or file operations with Entra credentials, assign a Storage data role: Storage Blob Data Reader, Storage Blob Data Contributor, Storage Blob Data Owner, and their queue, table, and file equivalents (Assign an Azure role for access to blob data^[17]). Assign it at the narrowest useful scope: a container or a queue, not the whole subscription. Control-plane roles such as Owner, Contributor, and Storage Account Contributor manage the account and can list its keys, but none of them authorizes a data operation through an Entra token (Azure built-in roles for Storage^[18]). The portal exposes this directly: when you browse a container you choose whether to authenticate with the account key or with your Entra account, and only the latter uses your data role.

Two account-level switches close the gaps around that model. Setting AllowSharedKeyAccess to false rejects every request authorized with an account key, which includes the service SAS and account SAS tokens signed with it (Prevent Shared Key authorization^[19]). Rotating both keys does not achieve this: rotation replaces the credential and leaves the authorization method enabled. Separately, disallowing anonymous public read access on the account stops a container being made publicly readable at all (Configure anonymous read access^[20]).

The three shared access signatures

A shared access signature (SAS) is a signed URL that carries its own permissions and expiry, for callers with no identity in your tenant. There are three types, and they differ in what signs them (Grant limited access with shared access signatures^[21]). The figure below groups them by that difference, which is also the order of preference:

• A user delegation SAS is signed with a user delegation key that Entra issues to a security principal, so no account key is involved. It is supported for Blob Storage, and Microsoft recommends it wherever delegated blob access can go through Entra authorization (Create a user delegation SAS^[22]). Revoking the user delegation key invalidates every SAS signed with it.
• A service SAS is signed with an account key and delegates access to resources in a single storage service. It is the only type that can reference a stored access policy.
• An account SAS is signed with an account key and can delegate access across one or more services, including service-level operations such as reading account properties. It is the broadest and the last resort.

A stored access policy lives on the container, queue, table, or share and defines start time, expiry, and permissions for the service SAS tokens that reference it (Define a stored access policy^[23]). That indirection is what makes those tokens revocable: change the policy and every token referencing it changes with it; delete the policy and they all stop working, with no key rotation. Stored access policies are not supported for account SAS or user delegation SAS tokens, so they are not the central-revocation mechanism for a user delegation SAS. The equivalent lever there is revoking the user delegation key.

Two more constraints apply to every SAS regardless of type. A SAS expiration policy on the account can log the use of tokens issued with a longer lifetime than your chosen limit or block requests made with them, depending on the configured action (Configure a SAS expiration policy^[24]). And a SAS never widens network access: an IP-restricted SAS narrows the token holder's reach, but it cannot admit a caller the firewall refuses.

Disallow Shared Key and issue a user delegation SAS with the Azure CLI

The first command applies the account-level switch discussed above; the second issues a token for one blob, signed through Entra with --auth-mode login --as-user, which is what makes it a user delegation SAS rather than a service SAS:

# Reject account-key authorization, including service SAS and account SAS
az storage account update \
  --name mystorageaccount --resource-group myresourcegroup \
  --allow-shared-key-access false

# ...

# Delegated read access to one blob, signed with a user delegation key
az storage blob generate-sas \
  --account-name mystorageaccount \
  --container-name uploads --name report.pdf \
  --permissions r --expiry 2026-08-01T00:00Z \
  --auth-mode login --as-user --https-only

The pattern to carry into the exam: prefer an Entra role over any token, prefer a user delegation SAS over any key-signed token, and reach for a service SAS only when the requirement is central revocation through a stored access policy.

Two families of control answer two different questions, and the wrong one is always on the answer sheet. Recoverability asks "can I get it back after someone deletes it"; immutability asks "can the delete happen at all". Soft delete, versioning, and point-in-time restore belong to the first. Time-based retention policies and legal holds belong to the second.

Getting data back

Blob soft delete retains a deleted or overwritten blob, snapshot, or version for a retention period of 1 to 365 days, after which it is permanently removed (Soft delete for blobs^[25]). It does not recover a deleted container: that needs container soft delete, a separate setting with its own retention period (Soft delete for containers^[26]).

Blob versioning automatically captures the previous state as a distinct version every time a blob is written or deleted, with no application change (Blob versioning^[27]). A snapshot is the manual equivalent, taken deliberately by an application. Versioning protects the history of a changing blob, which is a different guarantee from container soft delete: the first keeps every prior state of an object, the second brings back a container that was removed. Frequently overwritten data makes versioning expensive, which is the practical reason to scope it.

Point-in-time restore rewinds block blob data in one or more containers to a chosen earlier moment. It sits on top of the other two, and its prerequisites are the exam's favorite detail: blob versioning, blob change feed, and blob soft delete must all be enabled, and the restore window must be shorter than the soft-delete retention period (Point-in-time restore for block blobs^[28]). The change feed is an ordered, durable log of supported changes to the account's blobs, which is what makes a coherent rewind possible (Change feed support^[29]). Geo-redundant replication does none of this: it copies the current state to another region, so a deletion replicates faithfully.

Azure Files has its own recovery pair rather than sharing the blob features: share snapshots are read-only point-in-time copies, and share soft delete recovers a deleted file share within its retention window (Prevent accidental deletion of Azure file shares^[30]).

Preventing the delete

Immutable storage for blobs provides write once, read many (WORM) protection through two mechanisms (Immutable storage for Azure Blob Storage^[31]). A time-based retention policy protects data for a defined interval: while it is unlocked you can shorten, extend, or delete the policy for testing, and once locked you can only extend the interval, so the data cannot be modified or deleted until the interval expires. A legal hold has no end date; it protects the data until someone with the right permission explicitly clears its tags. Those are the legal hold's own tags, not the blob index tags that carry malware scan results later on this page.

Scope is the second axis. A policy can apply to a whole container, or to individual blob versions, which is finer grained and requires blob versioning to be enabled (Version-level WORM policies^[32]).

Control	Answers	Needs first
Blob soft delete	Recover a deleted or overwritten blob within 1 to 365 days	Nothing
Container soft delete	Recover a deleted container	Nothing
Blob versioning	Recover any earlier state of a changing blob	Nothing
Point-in-time restore	Rewind containers to a chosen time	Versioning, change feed, soft delete
Time-based retention policy	Block modification and deletion until the interval expires	Versioning, for version-level scope
Legal hold	Block modification and deletion until the hold is cleared	Versioning, for version-level scope

Read a scenario for its verb. "Restore", "recover", and "accidental" point at the first family; "cannot be deleted", "regulatory", and "for seven years" point at the second. Both families can be enabled together, and Defender for Storage's built-in malware remediation depends on the first one, as the next sections show.

Defender for Storage is agentless, and its most useful property is that it sees your storage traffic without you configuring a single log. It continuously analyzes the data-plane and control-plane telemetry of Azure Blob Storage, Azure Files, and Azure Data Lake Storage, so you do not need to enable resource logs or diagnostic settings for its detections to work (What is Microsoft Defender for Storage^[5]). A scenario that offers "enable resource logs first" as a prerequisite is offering a distractor.

What the plan includes

The plan has three capabilities, and two of them are configurable features you turn on inside it. Activity monitoring is the always-present layer: it applies Microsoft Threat Intelligence, behavioral models, and machine learning to access patterns and raises alerts for anomalies such as access from a Tor exit node, unusual extraction volumes, or the use of a leaked, overly permissive SAS token.

Malware scanning inspects object content with Microsoft Defender Antivirus and is billed per GB scanned, which is why it has its own cost controls. Sensitive data threat detection^[33] adds sensitivity context through sampled content inspection: an agentless engine uses smart sampling to find resources holding sensitive data, integrating Microsoft Purview sensitive information types and classification labels, so an alert on a container of customer records is prioritized above one on a container of build artifacts. It is enabled or disabled at no extra cost, and it is not a malware feature.

Malware scanning is not hash reputation analysis

Two different detections share the word malware, and the exam separates them by depth versus breadth of coverage: the full scan is deeper, the hash check is available more widely. Malware scanning performs a full content scan with Microsoft Defender Antivirus, including hash reputation analysis as part of its method, and it is a paid feature available only on the current Defender for Storage plan. Hash reputation analysis on its own compares the hashes of newly uploaded blobs and files against known malware from Microsoft Defender Threat Intelligence; it is available in all plans, and it does not cover every protocol or operation, with SMB file shares and blobs created through Put Block plus Put Block List among the unsupported cases.

Enablement scope and the override switch

Enable the plan at subscription scope when every current and future storage account should be protected; new accounts in that subscription are then covered automatically. Account-level enablement exists for the cases where a single account needs its own settings or where subscription-level enablement is not possible (Enable Defender for Storage in the Azure portal^[34]).

The two scopes meet at one setting. Subscription-level settings are inherited by every storage account in the subscription, and Override Defender for Storage subscription-level settings is what lets one account keep different feature or malware-cap settings, or be excluded from protection entirely (Advanced configurations for malware scanning^[35]). Without the override, editing the account's settings is the same as editing everyone's: changing the subscription-wide cap to accommodate one busy account changes the cap inherited by every other account too. Setting an Event Grid custom topic on an account is one of the changes Microsoft explicitly pairs with turning the override on. In short: activity monitoring comes with the plan, malware scanning and sensitive data threat detection are the features you switch on, and the override is what lets one account differ from the subscription.

A scan result is only useful if something acts on it, and Defender for Storage offers four places to consume one: a blob index tag on the object, a security alert in Defender for Cloud, an Event Grid event, and a row in a Log Analytics workspace (Set up automated remediation for malware detection^[36]). Choosing among them is a question of what has to happen next, not of preference. The figure below follows one upload from commit to response: the destinations that receive every scan result, and the built-in remediation that fires only on a malicious one.

What triggers a scan, and what it costs

On-upload scanning is driven by blob events, not by a schedule: an upload, an overwrite, or a rename raises a BlobCreated or BlobRenamed event and the service reads the blob, scans it in memory, and discards the content immediately (On-upload malware scanning^[37]). Incremental writes are the exception worth remembering: Put Block on a block blob and AppendFile in Data Lake Storage Gen2 do not trigger a scan on their own, because the scan happens when the change is committed with Put Block List or FlushWithClose. Enabling the feature also creates an Event Grid system topic in the storage account's resource group, which is how the service listens for those events, and it is separate from the custom topic you may configure for results.

Because billing is per GB scanned, the plan caps monthly volume per storage account. The default limit is 10,000 GB of uploaded data per month per account; when it is reached, scanning stops for the rest of the calendar month with roughly a 20 GB deviation, and the cap resets at midnight UTC at month end. A cap change takes up to an hour to take effect, and in the REST API a capGBPerMonth value of -1 means unlimited scanning. Two alerts warn you at 75 percent of the cap and when scanning stops. Throughput is bounded as well: on-upload scanning processes up to 50 GB per minute per storage account, and sustained upload rates above that can leave blobs unscanned. Exclusion filters, up to 24 values matching blob prefixes, suffixes, or a maximum size, keep predictable traffic such as logs out of the billed volume.

Routing results: Event Grid for action, Log Analytics for the record

An Event Grid custom topic receives every scan result as an event for near-real-time automation, typically consumed by a Function App or a Logic App that deletes, quarantines, or alerts. The topic has three requirements that come up as scenario constraints: it must use the Event Grid schema, it must sit in the same region as the storage account because cross-region delivery is not supported, and it must allow access from public IP addresses, because Defender for Storage cannot deliver to a topic that only accepts private endpoint connections. A Log Analytics workspace answers the other question, retention: every result is stored in a table named StorageMalwareScanningResults for query, audit, and compliance (Advanced configurations for malware scanning^[35]). Azure Event Hubs is not one of the destinations, however plausible it sounds.

Each event carries the blob URI, the scan finish time, and a scanResultType of Malicious, No threats found, or Not Scanned, with scanResultDetails naming the malware found or the reason a blob was skipped. Automation keys off scanResultType; nothing else in the payload decides the outcome.

Remediation: built in, or preventive with ABAC

The built-in option is soft delete malicious blobs. When enabled, Defender for Storage soft deletes any blob a scan finds malicious, so it is quarantined but still recoverable for investigation. It is off by default, it can be set at subscription or account level, and if the storage account does not already have blob soft delete enabled, turning this feature on enables it. The retention period defaults to seven days and can be set between 1 and 365 days in the account's own soft-delete settings, and malicious blobs that are soft deleted always carry index tags. Turning blob soft delete off on the account afterwards stops the remediation from working; Defender does not re-enable it and raises an alert instead.

That whole path is reactive: the blob was written, scanned, and then removed. The preventive alternative uses the scan result as an access-control attribute. Attribute-based access control (ABAC) conditions on a role assignment can test the blob index tag that carries the scan result, so applications and users read only blobs whose result is clean, and unscanned or malicious blobs are unreachable rather than merely flagged (ABAC conditions for Blob Storage^[38] and the available attributes^[39]). Applications can also check the index tag themselves before processing a blob, or subscribe to the Event Grid events and process only the clean results.

One more scanning mode fills the gap on data that is already stored: on-demand scanning scans the existing contents of a storage account when you ask it to, for incident response or for onboarding an account whose history was never inspected (On-demand malware scanning^[40]).

The decision to carry: Event Grid when a result must trigger something, Log Analytics when it must be kept, blob index tags plus ABAC when unclean data must never be readable in the first place.

SC-500 storage questions are usually a well-formed configuration with exactly one thing missing, and four answers that each fix a different control. Reading the stem for which of the five controls it names is faster than evaluating the options one by one.

Network admission

A stem describing allow rules that "do not work" may be about the default action. Adding virtual-network and IP rules while the default action is still Allow changes nothing; set it to Deny first. When a subnet still receives 403 after a virtual-network rule was added by script, the missing half is the Microsoft.Storage or Microsoft.Storage.Global service endpoint on the subnet. When the client is an Azure virtual machine in the same region as the account, an IP rule is the wrong tool at any address, and a private RFC 1918 address is never a valid IP rule. An NSG rule on an unrelated subnet is a distractor: it never governs who reaches a storage account's public endpoint.

Authorization

"Can manage the account but gets 403 on the data" is Storage Account Contributor or Contributor without a Storage data role. "Delegated access without handing out the account key" is a user delegation SAS, not an account SAS. "Revoke the token through a stored access policy" is a service SAS bound to that policy. A user delegation SAS cannot reference a stored access policy, but it can be centrally revoked by revoking its user delegation key. "Stop account-key authorization" is AllowSharedKeyAccess set to false; rotating both keys leaves the method enabled. Remember that disallowing Shared Key also stops the service SAS and account SAS tokens signed with that key, while a user delegation SAS keeps working.

Encryption

"Block unencrypted requests" is Secure transfer required, not the minimum TLS version. "Enforce TLS 1.3 as the minimum" is not configurable; TLS 1.2 is the floor the setting accepts. "Own the key rotation and revocation" is a customer-managed key in Key Vault or Managed HSM. "Encrypt twice with different keys" is infrastructure encryption. If an existing account needs it account-wide, the honest answer is a new account; for Blob data, a new encryption scope can enable it within the existing account.

Resilience

"Recover a deleted blob" is blob soft delete; "recover a deleted container" is container soft delete; "keep every prior version" is versioning. "Restore to a specific time" is point-in-time restore, and any option that omits versioning, change feed, or soft delete from the prerequisites is wrong. "Must not be deletable for a period" is a time-based retention policy, locked; "until the investigation ends" is a legal hold. Geo-redundancy answers durability, never recovery from a deletion.

Defender for Storage

"Protect all current and future accounts" is subscription-level enablement; "different settings for this one account" is the override switch, and changing the subscription cap instead is the trap. "Near-real-time automated response to every scan result" is an Event Grid custom topic, in the same region and reachable over public IP; "retain every result for audit" is a Log Analytics workspace; Event Hubs is not an option. "Quarantine malicious uploads without building automation" is soft delete malicious blobs. "Only clean blobs may be read" is an ABAC condition on the scan-result index tag. And when a stem stresses that resource logs are not enabled, that is not an obstacle to Defender for Storage detections at all.