10.2 Identity, Storage, and Compute Integrated Cases
Key Takeaways
- Compute access to storage usually requires both a valid network path and the correct identity or key-based authorization model.
- Managed identities plus data-plane roles are preferred when a workload needs least-privilege access to Azure resources.
- Storage firewall and private endpoint settings can make correct credentials appear broken.
- VM, App Service, and container troubleshooting should start with logs, identity assignment, role scope, and endpoint reachability.
- Case questions often hinge on whether an administrator should change RBAC, app configuration, storage networking, or deployment artifacts.
Case 1: VM backup job writes reports to Blob Storage
A finance team runs a scheduled script on an Azure VM. The script writes daily reports to a blob container. Yesterday the storage account firewall was changed to selected networks only. Today the script fails. The VM has a system-assigned managed identity, and that identity has Storage Blob Data Contributor on the container.
Do not remove the role assignment. The identity and data-plane role are probably correct. The new variable is the storage network perimeter. Check whether the VM subnet is allowed through a virtual network rule, service endpoint, private endpoint, or trusted access pattern that fits the organization requirement. If the storage account should have no public access, use a private endpoint and private DNS. If public endpoint access is acceptable only from a known subnet, use storage firewall virtual network rules with the required service endpoint configuration.
Troubleshooting sequence:
- From the VM, resolve the storage account name and note whether it returns public or private addresses.
- Confirm storage account networking: public access, selected networks, private endpoint connections, and firewall exceptions.
- Confirm the VM subnet route table and NSG allow the required outbound path.
- Confirm the managed identity exists on the VM.
- Confirm the role assignment is a data role at container, account, resource group, or subscription scope as required.
- Review Storage logs or diagnostic settings if enabled.
CLI checks:
az vm identity show -g rg-app -n vm-report-01
az role assignment list --assignee <principal-id> --scope <container-or-storage-scope> -o table
az storage account show -g rg-data -n examstorage104 --query networkRuleSet
az network private-endpoint-connection list -g rg-data -n examstorage104 --type Microsoft.Storage/storageAccounts -o table
The correct fix depends on the stated constraint. If the requirement says keep storage public network access disabled, create or fix the private endpoint and private DNS zone link. If the requirement says allow only the VM subnet, add the subnet to the storage firewall and ensure the service endpoint for Microsoft.Storage exists. If the requirement says least privilege, do not switch to account keys just because they are convenient.
Case 2: App Service reads blobs with managed identity
An App Service app was moved from connection-string storage keys to managed identity. The app starts successfully but receives 403 when reading blobs. The app's system-assigned identity is enabled. A developer assigned Reader on the storage account.
Reader is not enough for blob data. It allows viewing management properties, not reading blob content. Assign Storage Blob Data Reader or Storage Blob Data Contributor depending on whether the app only reads or also writes. Scope it as narrowly as the requirement allows. For a single container, container scope is better than subscription scope.
Portal path: Storage account > Access control (IAM) for management and data roles at account scope, or container-level access control where supported in the data service experience. App identity path: App Service > Identity. App logs path: App Service > Log stream and Diagnose and solve problems.
A complete remediation note would say: The app authenticates as its managed identity, but the identity has a management-plane Reader role instead of a blob data-plane role. Assign Storage Blob Data Reader at the target container scope and keep storage keys out of app settings.
Case 3: Container App pulls image and mounts Azure Files
A containerized report processor runs in Azure Container Apps. It pulls an image from Azure Container Registry and mounts an Azure Files share for temporary exchange files. The latest revision will not start. Logs show one error about unauthorized image pull and another about file share mount failure.
This is a chain failure. Treat each dependency separately. For ACR, confirm the Container App identity and AcrPull role assignment at the registry scope. Confirm the image reference includes the login server, repository, and tag. For Azure Files, confirm the storage account, share name, mount configuration, secret reference, and network reachability. If identity-based Azure Files access is required, confirm the supported identity model and SMB requirements. If the mount uses storage keys, confirm the secret value is current.
Do not fix an ACR pull failure by changing Azure Files permissions. Do not fix an Azure Files mount failure by assigning AcrPull. In an integrated case, several symptoms can be true at once. AZ-104 rewards isolating the failing operation.
Case 4: Bicep deployment creates VM and storage dependencies
A Bicep file deploys a VM, managed identity, storage account, private endpoint, and role assignment. Deployment fails with authorization errors when creating the role assignment. The operator has Contributor on the resource group.
Contributor can deploy many resources but cannot grant access. Role assignment operations require Microsoft.Authorization role assignment permissions, such as Owner or User Access Administrator at the relevant scope. The correct answer is not to make the VM identity Owner. The deployment identity needs permission to create the assignment, and the workload identity should receive only the data role it needs.
Interpret this as a deployment-control problem, not a runtime-workload problem. Activity log and deployment operations show the failing resource provider operation. Use az deployment group show and az deployment operation group list to inspect failures.
az deployment group create -g rg-app -f main.bicep
az deployment operation group list -g rg-app -n <deployment-name> -o table
Remediation patterns to memorize
| Symptom | Likely root cause | Correct remediation |
|---|---|---|
| VM script gets 403 to blobs | Missing blob data role | Assign Storage Blob Data Reader or Contributor at correct scope |
| VM script times out to storage | Network path, firewall, DNS, or route | Fix subnet allowance, private endpoint, DNS, NSG, or UDR |
| App Service has Reader but cannot read blobs | Management role instead of data role | Assign blob data role to managed identity |
| Container cannot pull ACR image | Missing AcrPull, wrong tag, registry firewall | Fix identity role, image reference, or network path |
| Bicep role assignment fails | Deployment identity lacks grant permissions | Use Owner/User Access Administrator for deployment identity |
The exam wording often gives the intended constraint: least privilege, no secrets, no public access, no downtime, or repeatable deployment. Respect that constraint. A storage key may make a demo pass, but it is not the best answer when a managed identity and data role satisfy the requirement.
A VM managed identity has Storage Blob Data Contributor, but the VM times out when reaching a storage account after the firewall is changed to selected networks. What should be investigated first?
An App Service app with system-assigned identity has Reader on a storage account but cannot read blob content. What is the likely fix?
A Bicep deployment fails only when creating a role assignment. The operator has Contributor. What permission issue is most likely?