AZ-305 Design data storage solutions Practice Question
Exhibit
Refer to the exhibit.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AzureAD": "users@contoso.com"
},
"Action": "Microsoft.Storage/storageAccounts/blobServices/containers/read",
"Resource": "/subscriptions/12345/resourceGroups/RG1/providers/Microsoft.Storage/storageAccounts/storage1/blobServices/default/containers/container1",
"Condition": {
"IpAddress": {
"SourceIp": "192.168.1.0/24"
}
}
}
]
}Refer to the exhibit. You have an Azure Storage account with hierarchical namespace enabled. You create this JSON policy to assign to a container. Users report that they can access the container from any IP, not just the specified range. What is the most likely reason?
⚠ Common exam trap
A common mix-up: candidates confuse RBAC conditions with Azure Storage firewall rules, assuming that IP conditions can be applied directly in RBAC role assignments for data plane operations, when in fact IP restrictions must be configured separately via the storage account's networking blade.
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
✓
IP address conditions are not supported in RBAC for Azure Storage data plane operations
RBAC roles for Azure Storage data plane operations do not support IP address conditions in role assignments. IP address conditions are only supported for Azure Resource Manager (control plane) RBAC roles, not for data plane operations like accessing blob or container data. Since the policy uses RBAC with an IP condition, the condition is ignored, and access is allowed from any IP.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Hierarchical namespace disables IP-based restrictions
Why it's wrong here
Enabling hierarchical namespace (Azure Data Lake Storage Gen2) changes the file-system layout and ACL semantics, but it does not alter how the storage account firewall evaluates network traffic. IP-based restrictions are enforced by the storage account's network rules, which remain fully functional regardless of the namespace setting. A conditional assignment's failure to restrict by IP is therefore unrelated to hierarchical namespace, so this is not a valid reason.
- ✗
Anonymous access is enabled on the container
Why it's wrong here
If anonymous access were enabled at the container level, users could read blobs without authentication, but that would not cause an RBAC condition to be ignored. In fact, anonymous requests bypass Azure RBAC entirely, so any conditional access policy derived from RBAC would not even apply to those requests. Since the scenario almost certainly involves an authenticated user, anonymous access cannot explain why the conditional IP restriction fails; the root cause is the absence of IP as a supported condition attribute in RBAC for storage data plane operations.
- ✓
IP address conditions are not supported in RBAC for Azure Storage data plane operations
Why this is correct
Azure RBAC condition expressions, part of ABAC (attribute-based access control), support a limited set of attributes for a given action. For Azure Storage data-plane operations, the supported condition attributes include container names, blob paths, tags, and request metadata—but the client's IP address is not among them. Therefore, any attempt to add an IP-address condition to an RBAC role assignment for a storage scope will not be evaluated, and the policy cannot restrict traffic by IP. The recommended mechanism for IP filtering is the storage account firewall, which operates independently of RBAC.
- ✗
The resource scope is incorrect; RBAC cannot be assigned at the container level
Why it's wrong here
Azure RBAC assignments are hierarchical and can be scoped to a management group, subscription, resource group, or any resource—including an individual container within a blob storage account. For example, you can assign the 'Storage Blob Data Contributor' role at the container scope, so the container is a valid, supported scope for role assignments. Because RBAC at the container scope is fully valid, the issue is not an incorrect resource scope but rather the unsupported IP condition in the assignment.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
One of 795 original AZ-305 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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-305 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-305 exam.