Task 2.1: Implement security for storage accounts

• ADisable public access on the Function App and add a private endpoint beside the custom topic

  Incorrect

  The events never reach the topic, so the function's network path isn't the problem.

• BGrant the Function App's managed identity Storage Blob Data Owner on the scanned account

  Incorrect

  The function never runs, so its data permissions aren't what fails here.

• CAllow access to the custom topic from public IP addresses

  Correct

  Defender for Storage can't deliver events to Event Grid topics that accept only private endpoint connections.

• DTurn off blob index tags so that results are sent only to Event Grid

  Incorrect

  Index tags and Event Grid events are independent result methods; disabling tags doesn't route events.

For custom automation, malware scanning can publish each scan result to an Event Grid custom topic that a Function App or webhook subscribes to. When you create the topic, allow access from public IP addresses: Defender for Storage can't deliver to topics that only accept private endpoint connections.

• ARemove the policy and set AllowCrossTenantReplication to false on the older accounts

  Correct

  Accounts created before December 15, 2023 have no value for the property, so cross-tenant policies stay possible until you set it to false.

• BNothing beyond removing the policy, because cross-tenant replication is blocked by default on every account

  Incorrect

  Only accounts created after December 15, 2023 block it by default.

• CTurn off blob versioning on the source account

  Incorrect

  Versioning is required for object replication and can't be turned off while a policy exists; it doesn't control which tenants a policy spans.

• DDisable Shared Key authorization on the destination account

  Incorrect

  Object replication across tenants is governed by the AllowCrossTenantReplication property, not by Shared Key settings.

Setting AllowCrossTenantReplication to false prevents object replication policies whose source and destination are in different Microsoft Entra tenants. New accounts created after December 15, 2023 default to false, but older accounts don't return a value until it's set explicitly and can still take part in cross-tenant policies.

• AA 2 GB ZIP archive uploaded to a blob container

  Incorrect

  Archives within the supported size are scanned.

• BA blob overwritten with new content

  Incorrect

  Overwriting an existing blob triggers a new scan.

• CA file copied into an Azure file share in the account

  Correct

  On-upload malware scanning isn't supported for Azure Files.

• DA blob committed with PutBlockList after several PutBlock calls

  Incorrect

  The commit finalizes the blob and triggers a scan.

• EA 60 GB disk image uploaded as a block blob

  Correct

  Blobs larger than 50 GB aren't scanned.

On-upload scanning is triggered by operations that raise BlobCreated or BlobRenamed events, such as uploads, overwrites and commits like PutBlockList; incremental PutBlock calls are scanned only when committed. Malware scanning handles blobs up to 50 GB, doesn't support legacy v1 accounts, and on-upload scanning isn't available for Azure Files.

• AThe Block action denies every service SAS, so only user delegation SAS still works

  Incorrect

  Block denies only out-of-policy SAS; in-policy service SAS tokens keep working.

• BThe policy also caps the validity of the storage account keys at 24 hours

  Incorrect

  A SAS expiration policy limits SAS validity intervals, not the account keys.

• CThe tokens must reference a stored access policy once Block is set

  Incorrect

  Block isn't supported for service SAS with a stored access policy, so that wouldn't be required.

• DThe tokens don't include a signed start time, which makes them out of policy

  Correct

  With an expiration policy, every SAS needs a signed start, and Block denies out-of-policy SAS.

A SAS expiration policy sets an upper limit on the validity interval of a user delegation, service or account SAS. Out-of-policy SAS are those with no signed start or an interval longer than the limit. With the default Log action, such requests are allowed and logged in SasExpiryStatus; with Block, they're denied.

• AMinimum TLS version set to TLS 1.3

  Incorrect

  Azure Storage doesn't support enforcing TLS 1.3 as the minimum version.

• BMinimum TLS 1.2, with the gap recorded

  Correct

  TLS 1.2 is the highest minimum you can enforce; clients that support TLS 1.3 negotiate it automatically.

• CSecure transfer required, which forces TLS 1.3

  Incorrect

  Secure transfer requires HTTPS, not a particular TLS version.

• DA private endpoint, which only accepts TLS 1.3

  Incorrect

  Private endpoints change the network path, not the TLS version.

Azure Storage supports TLS 1.2 and TLS 1.3, but it doesn't currently support enforcing TLS 1.3 as an account's minimum TLS version; the recommended minimum is TLS 1.2. Clients that support TLS 1.3 negotiate it automatically. Before tightening the minimum, use storage logs and the TlsVersion property to find clients that would be rejected.

• AAdd a virtual network rule with a service endpoint

  Correct

  IP rules have no effect on same-region requests, so the subnet has to be allowed with a virtual network rule.

• BTurn on the exception for trusted Azure services

  Incorrect

  Trusted services are specific Azure services, not your own VMs.

• CAdd the VM's private IP address as an IP network rule

  Incorrect

  IP network rules accept only public addresses, and private ranges aren't allowed.

• DMove the VM's public IP to a Standard SKU address

  Incorrect

  The SKU doesn't change how the firewall treats same-region traffic.

IP network rules have no effect on requests that originate from the same Azure region as the storage account, because services in the same region communicate over private Azure addresses. Use virtual network rules, which need a service endpoint on the subnet, or private endpoints to allow same-region clients.

• AClean or Infected

  Incorrect

  Those aren't the documented values.

• BScanned or Skipped

  Incorrect

  Those aren't the documented values.

• CNo threats found, Malicious, Error or Not scanned

  Correct

  These are the scan result values written to the index tag.

• DLow, Medium or High

  Incorrect

  Those resemble alert severities, not scan results.

By default, Defender for Storage writes malware scan results to two blob index tags on every scanned blob: the scan result, which is No threats found, Malicious, Error or Not scanned, and the time of the scan.

• AAdd 198.51.100.8 and 198.51.100.9 as individual IP address rules

  Correct

  Ranges with /31 or /32 prefixes aren't supported, so you add individual addresses.

• BChange it to 198.51.100.8/24

  Incorrect

  That would allow far more addresses than intended.

• CEnable the trusted Azure services exception

  Incorrect

  That exception is for specific Azure services, not your addresses.

• DUse a virtual network rule for the range

  Incorrect

  Virtual network rules allow subnets, not public IP ranges.

Storage firewall IP network rules don't support small address ranges with /31 or /32 prefix sizes. Configure these addresses as individual IP address rules instead.

• APer storage account per hour

  Incorrect

  Malware scanning is billed by volume scanned.

• BPer malicious file found

  Incorrect

  Billing doesn't depend on findings.

• CPer blob uploaded, regardless of size

  Incorrect

  Billing depends on volume, not blob count.

• DPer GB scanned

  Correct

  Malware scanning is billed by the volume of data scanned, in GB.

Malware scanning is billed per GB scanned, so the cost follows the volume of data uploaded and scanned rather than the number of blobs, accounts or findings.

• AOnly in an Azure Key Vault Premium vault

  Incorrect

  Standard vaults and Managed HSM can hold the key too.

• BIn Azure Key Vault or Azure Key Vault Managed HSM

  Correct

  Customer-managed keys must be stored in one of these.

• CIn the storage account's own encryption settings

  Incorrect

  The account references a key; it doesn't store it.

• DIn any HSM reachable over the internet

  Incorrect

  The key must be in Key Vault or Managed HSM.

Azure Storage encrypts all data at rest with Microsoft-managed keys by default. For more control, customer-managed keys can be used; they must be stored in Azure Key Vault or Azure Key Vault Managed HSM, which support the same APIs.