An Azure storage account is a starting point for storing objects, shared files and queue messages. The right choice depends on how an application uses its data. A photo upload, a shared folder and a background-work message may all need storage, but they should not automatically use the same service.
This guide uses a proposed training project: a small application accepts an image, saves it privately and asks a background worker to process it. The example helps separate service selection, data permissions, access tiers and recovery decisions.
Blob Storage, Azure Files or Queue Storage?
- Blob Storage: stores unstructured objects such as images, documents and backups. Blobs sit inside containers within a storage account.
- Azure Files: provides managed file shares for workloads that need file-share access rather than an object API.
- Queue Storage: stores messages so one application component can hand work to another. A message might identify an uploaded image that a worker must process.
In the example, put the image in Blob Storage and send a small work message through Queue Storage. Azure Files would become relevant if a component specifically required a shared filesystem. This is an illustrative design choice; application requirements determine the final architecture. Microsoft’s Azure Storage introduction explains the services and supported account types.
Design the account and container deliberately
Before creating the account, record the region, workload, redundancy choice and expected access pattern. Use an account name that meets Azure’s naming requirements, then create a private container such as training-images. Upload harmless sample files rather than personal or production data.
Choose descriptive object names such as practice/originals/sample-01.jpg. A naming convention makes it easier to understand which application step created a file. Keep the original and processed outputs distinguishable so your test does not accidentally overwrite its own input.
Management permissions are not blob data permissions
Being able to see a storage account in the Azure portal does not necessarily grant access to its blob contents. For Entra-authorised blob access, use an appropriate data role, such as Storage Blob Data Reader for reading or Storage Blob Data Contributor for reading and writing. Scope the role to the smallest suitable boundary.
The portal can also need management-plane Reader access to navigate resources. Account-key access is another path, so understand the authentication method used during each test. Microsoft’s blob role assignment guide explains the distinction. Review Entra ID and RBAC basics before assigning broad access to resolve an error.
Hot, cool, cold and archive tiers
For supported blob workloads, access tiers trade storage cost against access cost and retention expectations. Hot suits frequently accessed objects. Cool and cold suit progressively less frequent access. Archive is offline: reading an archived blob requires rehydration to an online tier first.
Do not apply these blob tier names to every Azure Files share or queue message. Also check supported redundancy combinations, retrieval charges and early deletion charges before moving data. The Microsoft access-tier reference contains the current constraints.
For the sample project, keep the active demonstration image online. A file needed during tomorrow’s demo is a poor candidate for archive merely because its storage rate looks lower. Estimate the whole access pattern: how often the worker reads, how many outputs it writes and when old samples can be removed.
A beginner lab with measurable checks
- Create a small sandbox. Use an authorised subscription and a dedicated resource group. Review the selected services’ costs before deployment.
- Prepare private storage. Create a suitable account and the
training-imagescontainer. Leave anonymous access disabled. - Grant the test identity data access. Apply the required blob data role at an appropriate scope and record which identity will perform the upload.
- Upload one small sample. Record the blob name, size and selected tier. Download it through an authorised client and compare it with the original.
- Check an unauthorised attempt. Confirm a direct anonymous request does not expose the private object. Record the result separately from the authenticated download.
- Describe the queue hand-off. Define a sample message containing the blob identifier and an operation such as thumbnail generation. Queue access needs its own suitable authorisation; a blob role does not grant it.
- Clean up the exercise. Remove only the test resources you no longer need and check for remaining chargeable components.
This is a proposed exercise, not a claim that the pipeline has been executed. Keep a short results sheet with expected versus observed outcomes. If you implement a worker, decide how it should behave when the referenced image is missing or processing is retried.
Redundancy and recovery answer different questions
Redundancy choices determine how copies are distributed across infrastructure, zones or regions. They are not a substitute for planning recovery from accidental deletion or unwanted application changes. Compare the redundancy requirement with the workload’s availability needs using Microsoft’s storage redundancy guide. Document what failure your design addresses and what it does not.
Troubleshoot before broadening access
For a 403 response, check the actual authentication method, identity, role scope and any network restriction. For a missing object, check the container and complete blob name. For an archived object, check its tier and rehydration state. If requests cannot reach the endpoint, use the network troubleshooting guide.
Once manual access works, explore automating the application with Azure Pipelines or GitHub Actions. For a course covering these connected administration skills, review Softenant’s Azure training in Vizag and compare its syllabus with your learning checklist.