AZ-500 Secure compute, storage, and databases Practice Question
Your organization uses Azure Storage for sensitive financial data. You need to restrict access to storage accounts based on the client's IP address. Which Azure Storage service feature should you configure?
⚠ Common exam trap
Many exam-takers confuse Shared Access Signatures (SAS) with network-level access control, mistakenly thinking SAS tokens can restrict by IP, when in fact SAS tokens only grant access to anyone holding the token unless you explicitly configure an IP ACL within the SAS token itself—but the question asks for a storage service feature, not a token-level option, and the correct answer is the Firewall and virtual networks feature.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Firewalls and virtual networks
Firewalls and virtual networks allow you to restrict access to Azure Storage accounts based on source IP address ranges, including specific client IPs. This is the correct feature because it provides network-level access control that can block or allow traffic from defined IP addresses, which directly meets the requirement to restrict access based on the client's IP address.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Firewalls and virtual networks
Why this is correct
Firewalls and virtual networks is the correct answer because it is the Azure Storage account networking feature that lets you define IP address rules, including ranges and specific IPs, to restrict access to the storage account. When you configure these firewall rules, only requests originating from allowed IP addresses (or from selected virtual networks using service endpoints) can reach the storage endpoint, effectively blocking all other clients. This directly satisfies the requirement to restrict storage access by IP address.
- ✗
Shared access signatures (SAS)
Why it's wrong here
Shared access signatures (SAS) are incorrect because a SAS provides delegated, time-limited access to specific storage resources (containers, blobs, queues, tables) with granular permissions (read, write, delete, etc.) via a token in the URI or headers. While you can associate a SAS with an IP address range at the service level by setting the 'iprange' parameter (e.g., using the storage account shared access policy), SAS itself is fundamentally an authorization mechanism, not a network access control. The SAS token does not selectively filter or block clients based on source IP before they reach the storage service; it merely allows a bearer to access resources. Therefore, SAS cannot be used as the primary tool to restrict access by IP address across the storage account.
- ✗
Azure Private Link
Why it's wrong here
Azure Private Link is incorrect for IP-based restriction because it provides private connectivity to the storage account by creating a private endpoint that assigns a private IP address from your virtual network to the storage service. With Private Link, traffic flows over the Microsoft backbone and is isolated from the public internet, but access control is enforced through network security rules on the virtual network and the private endpoint's subnet, not through IP rules on the storage account itself. Private Link does not allow you to specify a list of public IP addresses that can access the storage account; instead, it restricts access to a specific VNet and its subnets. While Private Link can prevent public internet exposure, it is not designed for IP-address-based allowlisting.
- ✗
Microsoft Entra ID role-based access control
Why it's wrong here
Microsoft Entra ID role-based access control (RBAC) is incorrect because it governs identity-based permissions to the storage account's control plane (e.g., assigning the 'Storage Blob Data Contributor' role to a user or service principal) and data plane with Microsoft Entra ID integration. RBAC determines what operations a principal can perform (read, write, delete) but does not filter or restrict access based on the client's IP address. It cannot block or allow traffic from specific IP ranges; it only checks the authenticated identity's permissions. Therefore, RBAC is not a mechanism for IP-based network restriction, which is why it is not the correct answer here.
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-500 question from scratch — 617 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-500 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-500 exam.