10.5 Permissions, Network, and Storage Troubleshooting Chain

The storage troubleshooting chain

Storage cases are dense because Azure Storage supports multiple authorization models and multiple network access patterns. A blob read can fail because the user has the wrong role, the managed identity is not assigned, the SAS token expired, the storage firewall blocks the client, the private endpoint DNS is wrong, the container name is wrong, or the blob was moved to an access tier that changes retrieval behavior. The exam will usually give a clue. Your job is to read the clue in the right order.

Start with the operation. Is the caller listing containers, reading a blob, writing a file share, mounting SMB, using AzCopy, or configuring the account? Listing storage account properties is not the same as reading data. Mounting Azure Files over SMB is not the same as downloading a blob over HTTPS.

Then classify the symptom.

Branch 1: RBAC and managed identity

A managed identity is a principal. It still needs role assignments. For Blob Storage data, management-plane roles such as Reader or Contributor are not enough to read or write blob content. Use data roles such as Storage Blob Data Reader, Storage Blob Data Contributor, or Storage Blob Data Owner depending on the requirement.

Scope matters. Assigning a data role at subscription scope may work, but it is broader than needed if the app only needs one container. Assign at container or storage account scope when that meets the requirement. Also check propagation delay, wrong identity selection, and user-assigned versus system-assigned identity confusion.

A VM or App Service may have multiple identities. The application must request a token as the identity you granted. If a user-assigned identity has the role but the app uses the system-assigned identity, authorization fails. In an exam question, watch for wording such as the identity was created versus the identity was assigned to the app.

Branch 2: SAS tokens

A SAS token is not just a password string. It encodes scope, permissions, service, resource type, start time, expiry time, protocol, signed IP range, and sometimes a stored access policy relationship. When AzCopy fails with a SAS token, inspect these properties.

Common traps:

1. SAS start time is in the future because of clock skew.
2. SAS has read permission but the operation is write, create, delete, or list.
3. SAS is scoped to a blob but the command lists the container.
4. SAS permits HTTPS only, but the client attempts HTTP.
5. SAS has an IP restriction that excludes the client or hosted agent.
6. Stored access policy was changed or deleted, invalidating dependent SAS behavior.

Least privilege applies here too. If the requirement is temporary upload to one container, issue a SAS with only required permissions and a short expiry. Do not regenerate account keys unless the keys are compromised or the scenario specifically requires invalidating key-based access.

Branch 3: Storage firewall and private endpoints

A correct token can still fail when the network path is blocked. Storage firewalls can restrict public endpoint access to selected networks. Private endpoints provide private IP access to storage subresources. Service endpoints can allow VNet subnet traffic to the storage public endpoint with network rules.

For private endpoints, validate DNS from the client machine. The storage account name should resolve to a private IP associated with the private endpoint. If it resolves publicly while public network access is disabled, the connection fails. If it resolves privately but traffic still fails, inspect NSGs, UDRs, peering DNS behavior, and whether the private endpoint subresource matches the service being used, such as blob versus file.

Commands to collect evidence:

nslookup examstorage104.blob.core.windows.net
az storage account show -g rg-data -n examstorage104 --query networkRuleSet
az network private-endpoint list -g rg-data -o table
az role assignment list --assignee <principal-id> --all -o table

Branch 4: Azure Files specifics

Azure Files can use access keys, SAS in some scenarios, identity-based access patterns, snapshots, and backup. SMB access also depends on port 445 availability from the client network unless using supported private connectivity patterns. Corporate networks often block outbound SMB. A blob troubleshooting answer may be wrong for Azure Files because the protocol and authorization model differ.

If a Windows VM cannot mount a file share, check the storage account network rules, private endpoint for file, DNS, port 445 path, share name, key or identity configuration, and NTFS/share permissions when identity-based access is used. If the requirement says avoid account keys, choose identity-based Azure Files access where supported and configured correctly.

Remediation discipline

Never widen access before you know the branch. Publicly enabling a storage account may hide a DNS problem, but it violates a no-public-access requirement. Assigning Owner may hide a missing data role, but it violates least privilege. Regenerating account keys may break other workloads.

Write the fix in this format: Because the symptom is <403/timeout/not found>, and evidence shows <specific setting>, remediate by <specific minimal change>. Example: Because the VM resolves blob storage to a public IP while public access is disabled, fix the private DNS zone link to the VM VNet. Do not enable public network access.

This chain is useful beyond storage. It teaches the AZ-104 habit: classify, prove, then change.