Technical Lab: Configure Azure Storage Firewalls and Virtual Networks
Questions
Question 1 — Multiple Choice
A security team requires that a Storage Account accept traffic only from a specific subnet in a VNet, blocking everything else, including access through the Azure portal from machines outside that subnet.
Which combination of configurations correctly meets this requirement?
A. Set the default action to Allow and add the subnet as a virtual network rule.
B. Set the default action to Deny and add the subnet as a virtual network rule, with the Microsoft.Storage service endpoint enabled on the subnet.
C. Set the default action to Deny and add only the private IP range of the subnet as an IP firewall rule.
D. Set the default action to Deny, add the subnet as a virtual network rule, and enable the Allow trusted Microsoft services option.
Question 2 — Technical Scenario
A developer configures a Storage Account firewall as follows:
Default action: Deny
Virtual network rules: none
IP rules: none
Enabled exceptions: Allow trusted Microsoft services
When trying to access the storage via Azure Backup, access works correctly. However, when trying to access via an Azure Function hosted on a Consumption plan, access is denied.
What is the most likely cause of this behavior?
A. Azure Functions on Consumption plan do not support VNet integration, therefore they can never access storage accounts with restrictive firewall.
B. The Allow trusted Microsoft services option covers Azure Backup as it's a trusted first-party service, but Azure Functions on Consumption plan are not listed in that category of trusted services.
C. The Azure Function is trying to use access key authentication, which is automatically blocked when the firewall is active.
D. The Consumption plan does not allow the use of Managed Identity, preventing any form of authenticated access to the storage account.
Question 3 — True or False
When adding an IP rule to a Storage Account firewall, it's possible to specify a private RFC 1918 IP address (like 10.0.0.5) to restrict access to resources within an Azure VNet.
Question 4 — Technical Scenario
A company needs diagnostic logs from Azure resources to be sent to a Storage Account protected by firewall. The diagnostics are configured through Azure Monitor. After enabling the firewall with default action Deny and no additional rules, the logs stop arriving.
What is the minimum configuration needed to restore log delivery without exposing the storage account to arbitrary public IPs?
A. Add the Azure Monitor public IP ranges as IP firewall rules on the storage account.
B. Temporarily disable the firewall during the log collection window and re-enable it afterwards.
C. Enable the Allow trusted Microsoft services exception on the storage account.
D. Create a virtual network rule pointing to the subnet where Azure Monitor is hosted.
Question 5 — Multiple Choice
When configuring a virtual network rule on a Storage Account, an administrator tries to add a subnet, but the option is unavailable for that specific subnet.
What is the most likely cause of this behavior?
A. The subnet belongs to a VNet in a different region from the Storage Account, and virtual network rules only accept subnets from the same region.
B. The Microsoft.Storage service endpoint is not enabled on the subnet in question.
C. The subnet already has a Network Security Group (NSG) associated, which prevents service endpoint configuration.
D. The Storage Account is configured with GRS redundancy, which is not compatible with virtual network rules.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
For only one subnet to have access, the default action must be Deny, blocking everything that isn't explicitly allowed. The subnet needs to be added as a virtual network rule, and for this the Microsoft.Storage service endpoint must be enabled on the subnet, as it allows VNet traffic to reach the storage account control plane through Microsoft's backbone.
Alternative A fails because default action Allow permits all traffic by default, negating the requirement premise. Alternative C fails because private RFC 1918 IP addresses are not accepted in Storage Account IP firewall rules, which require public IPs. Alternative D would also add trusted Microsoft services as an exception, which broadens access beyond what's required, although not incorrect in all contexts, it's not the minimal and precise answer for the presented requirement.
Answer Key — Question 2
Answer: B
The Allow trusted Microsoft services option covers a specific and documented set of Microsoft services, such as Azure Backup, Azure Site Recovery, Azure Monitor, among others. Azure Functions on Consumption plan are not part of this list because they operate on shared and dynamic compute infrastructure, without service identity managed by Azure itself at the platform level for this purpose.
Alternative A is incorrect: Azure Functions on Consumption plan can access storage accounts with restrictive firewall, provided they are correctly configured with regional VNet integration or another valid approach. Alternative C is incorrect because the firewall doesn't block by authentication type. Alternative D is incorrect because Consumption plan does support Managed Identity for authentication, although this alone doesn't solve the network problem described.
Answer Key — Question 3
False
Storage Account IP firewall rules accept only public IP addresses or public CIDR ranges. Private RFC 1918 addresses (like 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) are explicitly rejected by the portal and API. To restrict access to resources in a VNet using private IPs, the correct mechanism is the virtual network rule, which requires service endpoint enabled on the subnet. Confusing IP rule with virtual network rule is a common error that leads to incorrect isolation configurations.
Answer Key — Question 4
Answer: C
Azure Monitor is listed among the trusted Microsoft services supported by Storage Account. Enabling this exception allows Azure Monitor to write diagnostic logs without needing to expose the storage to dynamic and broad public IP ranges or create virtual network rules.
Alternative A would require opening the storage to a dynamic and broad public IP range, increasing the attack surface. Alternative B is operationally unsustainable and represents a security control failure. Alternative D is unfeasible because Azure Monitor doesn't operate from a customer-controlled VNet subnet, therefore there's no subnet to reference in a virtual network rule.
Answer Key — Question 5
Answer: B
For a subnet to be added as a virtual network rule in a Storage Account, the Microsoft.Storage service endpoint must be previously enabled on that subnet. Without it, the portal and API don't recognize the subnet as eligible for this type of rule.
Alternative A is incorrect because virtual network rules accept subnets from VNets in any region, not just the same region as the storage account. Alternative C is incorrect because the presence of an NSG doesn't prevent service endpoint enablement. Alternative D is incorrect because GRS redundancy has no relation to virtual network rules support, both are orthogonal configurations.