AZ-204 Develop for Azure storage Practice Question
Exhibit
Refer to the exhibit.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AzureAD": "<tenant-id>"
},
"Action": "Microsoft.Storage/storageAccounts/blobServices/containers/read",
"Resource": "<container-resource-id>/*",
"Condition": {
"IpAddress": {
"SourceIp": "203.0.113.0/24"
}
}
}
]
}Refer to the exhibit. You are configuring access to an Azure Storage container using Azure RBAC via a custom role definition. You want to allow a user to list blobs in a container only if the request originates from the IP range 203.0.113.0/24. However, the user reports that they can list blobs from any IP. What is the issue?
⚠ Common exam trap
The current exam trap note reinforces the incorrect premise that assigning a role to the tenant bypasses conditions. This is not how Azure RBAC conditions function. A more accurate trap might focus on common pitfalls like incorrect condition syntax, or the existence of other, unconditional role assignments that grant the same permissions.
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
✓
The Condition for IP address is incorrectly formatted
The current explanation is technically incorrect. Azure RBAC conditions are designed to add restrictions to role assignments and are evaluated for every request by any principal covered by that assignment, regardless of whether the assignment target is a specific user, group, or a broader scope like the tenant. Assigning a role to the tenant does not bypass conditions; the condition should still be enforced for all principals covered by that assignment. A more plausible reason for the observed behavior (user can list blobs from any IP) would be that the condition for the IP address is incorrectly formatted (Option D), causing it to always evaluate to true or be ignored, or that another role assignment without the condition exists for the user.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The Principal is set to an Azure AD tenant instead of a specific user or group
Why it's wrong here
Azure Role-Based Access Control (RBAC) assignments are designed to grant specific permissions to individual identities or collections of identities. A principal in an RBAC assignment must be a specific user, security group, managed identity, or service principal within an Azure AD tenant. Assigning a role to the entire Azure AD tenant ID itself is not a valid configuration, as RBAC operates on the granularity of specific security principals, not the directory container. This ensures precise control over who can perform actions.
- ✗
The Resource should be the storage account resource ID, not the container resource ID
Why it's wrong here
Azure RBAC allows for granular permission assignments, and scoping the resource to a specific container resource ID is entirely valid and often desired. When an operation, such as listing blobs, is intended for a particular container, assigning permissions directly at the container level adheres to the principle of least privilege. Assigning permissions at the broader storage account level would grant access to all containers within that account, which might be excessive if only one container requires access.
- ✗
The Action should be 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'
Why it's wrong here
The action 'Microsoft.Storage/storageAccounts/blobServices/containers/read' is the correct permission for operations that involve listing the contents of a container, such as enumerating blobs. This action grants the ability to read container properties and list blobs within it, but not to read the content of individual blobs. If the intent were to read the actual data of a specific blob, then 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read' would be required. For a "List" operation, the current action is appropriate.
- ✓
The Condition for IP address is incorrectly formatted
Why this is correct
Azure RBAC conditions support specifying source IP address ranges to restrict access, and the provided syntax for `ipAddress` is indeed correctly formatted. Conditions leverage attribute-based access control (ABAC) to add additional checks beyond role assignments, such as network location or specific blob index tags. The use of `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/sourceIp` with a CIDR range is a valid and common way to enforce network-based access restrictions within an RBAC 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 881 original AZ-204 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-204 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-204 exam.