Azure Storage Account and Blob Storage – Complete Guide with Practical Examples, Security, Lifecycle Management, and Interview Questions
Azure Storage | Cloud Computing | Beginner to Advanced | Hands-on Tutorial
Article focus: Azure Storage Account, Blob Storage, redundancy, access tiers, SAS tokens, lifecycle management, static website hosting, blob versioning, data protection, and cost optimization.
What You'll Learn
By the end of this article, you will understand:
-
What an Azure Storage Account is and how its unified namespace works.
-
The four Azure Storage services: Blob, Files, Queue, and Table.
-
Standard and Premium storage performance tiers.
-
Replication strategies: LRS, ZRS, GRS, GZRS, RA-GRS, and RA-GZRS.
-
Blob Storage architecture, containers, and blob types.
-
Hot, Cool, Cold, and Archive access tiers.
-
Lifecycle management for automatic tier transitions and deletion.
-
Shared Access Signatures (SAS) and secure file sharing.
-
Hosting static websites directly from Azure Blob Storage.
-
Blob versioning, soft delete, and restoring previous versions.
-
Authentication using Microsoft Entra ID, RBAC, and Managed Identity.
-
Integrating Azure Blob Storage with ASP.NET Core.
-
Monitoring, cost optimization, and production best practices.
-
Important Azure Storage interview questions and answers.
Part 1 – Introduction to Azure Storage
1. What is Azure Storage?
Azure Storage is Microsoft's cloud-based storage platform for storing structured and unstructured data.
Instead of maintaining physical storage servers, hard disks, backup infrastructure, and storage networking, organizations can use Azure-managed storage services.
Azure Storage provides:
-
Scalability for large amounts of data.
-
High durability through data replication.
-
Security through encryption and access controls.
-
Access over HTTP/HTTPS and supported file-sharing protocols.
-
Integration with Azure services and applications.
-
Usage-based pricing.
Real-world example
Consider an e-commerce application built using ASP.NET Core and Angular.
The application may need to store customer profile images, product photographs, invoices, audit logs, and background-processing messages.
Instead of storing everything in SQL Server, we can use different Azure Storage services.
Angular Application
|
v
ASP.NET Core API
|
+---------+---------+
| |
v v
SQL Server Azure Storage Account
(Business Data) |
+----------+----------+
| | |
v v v
Blob Queue Table
Storage Storage Storage
|
Product Images
Invoice PDFs
User Documents
Key point: SQL Server stores relational business data, while Blob Storage is designed for large-scale object storage.
2. What is an Azure Storage Account?
An Azure Storage Account is a top-level Azure resource that provides a unique namespace and configuration boundary for supported Azure Storage services.
It controls settings such as:
-
Storage account name.
-
Azure region.
-
Performance tier.
-
Replication strategy.
-
Networking and firewall access.
-
Authentication and authorization.
-
Data protection and encryption.
A general-purpose v2 (StorageV2) account can provide Blob, File, Queue, and Table storage.
Storage Account Architecture
Azure Subscription
|
v
Resource Group
|
v
Azure Storage Account
mystorageaccount
|
+---------------+---------------+
| | |
v v v
Blob Storage Azure Files Queue Storage
| | |
Images File Shares Messages
Videos Shared Files Background Jobs
Documents
|
v
Table Storage
|
NoSQL Entities
Four main storage services
|
Service |
Purpose |
Example |
|---|---|---|
|
Blob Storage |
Unstructured object data |
Images, videos, PDFs |
|
Azure Files |
Managed file shares |
Shared folders |
|
Queue Storage |
Asynchronous messaging |
Background processing |
|
Table Storage |
NoSQL key-value entities |
Simple application records |
Important: These services can share a general-purpose storage account, but some Premium storage workloads require specialized account types.
3. Azure Storage Account Naming Rules
Storage account names must satisfy the following requirements:
-
Between 3 and 24 characters.
-
Lowercase letters and numbers only.
-
No spaces or special characters.
-
Globally unique across Azure.
Example:
Valid:
jntechstorage2026
mystorage123
Invalid:
MyStorage
my-storage
storage_account
Storage service endpoint URLs
Assume your storage account is named jntechstorage2026.
|
Service |
Endpoint |
|---|---|
|
Blob |
|
|
File |
|
|
Queue |
|
|
Table |
|
The account name is globally unique because it forms part of the DNS hostname.
Part 2 – Azure Storage Performance Tiers
4. Standard vs Premium Storage
Azure provides different performance options depending on the workload.
|
Feature |
Standard |
Premium |
|---|---|---|
|
Storage technology |
Cost-optimized storage infrastructure |
SSD-backed infrastructure |
|
Performance |
General-purpose |
Low-latency, high-performance |
|
Cost |
Lower |
Higher |
|
Typical workload |
Images, documents, backups |
High-performance file and blob workloads |
|
Account types |
General-purpose v2 |
Specialized Premium account types |
Standard Storage
Suitable for:
-
Website images.
-
PDF documents.
-
Application backups.
-
Log files.
-
General-purpose application storage.
Premium Storage
Suitable for:
-
Applications requiring consistently low latency.
-
High-throughput block blob workloads.
-
Performance-sensitive Azure Files shares.
-
Specialized page blob workloads.
Premium block blob, Premium file share, and Premium page blob capabilities depend on the account type and service configuration.
Recommendation: Use Standard Storage for most learning environments and typical portfolio applications. Select Premium only when workload performance measurements justify it.
Part 3 – Azure Storage Replication and Redundancy
5. Why is Replication Important?
Storage hardware, data centers, and entire Azure regions can experience failures.
Azure Storage redundancy maintains multiple copies of data to reduce the risk of data loss.
The selected replication strategy determines where those copies are stored and which failures the storage service can tolerate.
6. Locally Redundant Storage (LRS)
LRS stores three copies of data within a single physical location in the primary region.
Azure Region
|
v
One Data Center
|
+--------+--------+
| | |
v v v
Copy 1 Copy 2 Copy 3
Advantages: Lowest redundancy cost, three locally replicated copies, and protection against individual storage hardware failures.
Limitation: Does not protect against the loss of the entire data center or region.
Use cases: Development environments, test workloads, and data that can be recreated.
7. Zone-Redundant Storage (ZRS)
ZRS replicates data synchronously across three availability zones within the primary Azure region.
Azure Region
|
+-----------+-----------+
| | |
v v v
Zone 1 Zone 2 Zone 3
| | |
Copy 1 Copy 2 Copy 3
Each zone has independent power, cooling, and networking infrastructure.
Advantages: Protects against the failure of an availability zone and offers stronger availability than LRS.
Limitation: Does not provide protection against a complete regional outage.
8. Geo-Redundant Storage (GRS)
GRS stores three copies in the primary region and asynchronously replicates data to a secondary region, where another three copies are maintained.
Primary Region
|
LRS
Three Copies
|
|
Asynchronous Replication
|
v
Secondary Region
|
LRS
Three Copies
Advantages: Protects against regional disasters and provides six copies across two regions.
Limitations: Higher cost and possible data loss during regional failover because cross-region replication is asynchronous.
9. Geo-Zone-Redundant Storage (GZRS)
GZRS combines ZRS in the primary region with asynchronous replication to an LRS configuration in the secondary region.
Primary Region
|
+------------+------------+
| | |
Zone 1 Zone 2 Zone 3
| | |
Copy 1 Copy 2 Copy 3
|
v
Async Replication
|
v
Secondary Region
|
LRS - 3 Copies
Advantages: Protects against zone failures and provides regional disaster recovery capability.
Replication comparison
|
Option |
Copies |
Primary region |
Secondary region |
|---|---|---|---|
|
LRS |
3 |
One physical location |
No |
|
ZRS |
3 |
Three availability zones |
No |
|
GRS |
6 |
LRS |
LRS |
|
GZRS |
6 |
ZRS |
LRS |
Additional concepts: RA-GRS and RA-GZRS
Read-access geo-redundant storage provides read access to the secondary region while normal replication is operating.
-
RA-GRS: GRS with secondary read access.
-
RA-GZRS: GZRS with secondary read access.
This can support applications that need secondary-region reads, although secondary data may be stale because replication is asynchronous.
Interview key point: Replication provides durability and disaster resilience, but it does not replace backup, versioning, or protection against accidental deletion.
Part 4 – Creating an Azure Storage Account
10. Step-by-Step: Create a Storage Account
Step 1 – Open Azure Portal
Visit Azure Portal.
Search for Storage accounts and select Create.
Step 2 – Configure the Basics tab
|
Field |
Example value |
|---|---|
|
Subscription |
Your Azure subscription |
|
Resource group |
|
|
Storage account name |
|
|
Region |
Your preferred supported region |
|
Performance |
Standard |
|
Redundancy |
LRS |
Step 3 – Configure Advanced Settings
Review:
-
Secure transfer required: Enabled.
-
Minimum TLS version: TLS 1.2 or higher, where supported.
-
Anonymous blob access: Disabled unless specifically required.
-
Hierarchical namespace: Disabled for this general Blob Storage demonstration.
Step 4 – Configure Networking
For a simple learning environment, public network access may be enabled.
For production applications, consider selected networks, private endpoints, and network restrictions.
Step 5 – Review and Create
Click Review + create, validate the settings, and select Create.
After deployment, open the storage account to explore Containers, File shares, Queues, Tables, Data protection, Networking, and Lifecycle management.
Part 5 – Azure Blob Storage
11. What is Azure Blob Storage?
Blob stands for Binary Large Object.
Azure Blob Storage is an object storage service designed for massive amounts of unstructured data.
Examples include images, videos, audio, PDF documents, backups, application logs, and static website assets.
Blob Storage hierarchy
Storage Account
jntechstorage
|
+-------------+-------------+
| | |
v v v
Container Container Container
images documents backups
| | |
logo.png resume.pdf dbbackup.bak
photo.jpg invoice.pdf
A container is a logical grouping of blobs. Containers cannot be nested within other containers, although blob names can use / separators to simulate folders.
Blob URL structure
https://<account>.blob.core.windows.net/<container>/<blob>
Example:
https://jntechstorage2026.blob.core.windows.net/images/logo.png
A blob URL identifies the resource but does not automatically grant access.
12. Types of Azure Blobs
Azure supports three main blob types.
|
Type |
Description |
Common use |
|---|---|---|
|
Block Blob |
Stores data as blocks |
Images, PDFs, videos |
|
Append Blob |
Optimized for appending data |
Logs and audit streams |
|
Page Blob |
Supports random reads/writes in 512-byte pages |
VHD and specialized disk workloads |
Block Blob
Block blobs are the most commonly used type.
They are suitable for uploading and downloading application files and large binary objects.
Append Blob
Append blobs support append operations without rewriting the complete object.
They are useful for sequential logging workloads. They are not a substitute for immutable audit storage unless additional protections are configured.
Page Blob
Page blobs support random-access operations.
They are used for VHD-style workloads. Azure managed disks abstract away much of the underlying storage implementation.
Interview key point: For uploading images and PDF documents from an ASP.NET Core application, choose Block Blob.
13. Create a Container and Upload Files
Step 1 – Create Container
Navigate to:
Storage Account
|
v
Data Storage
|
v
Containers
|
v
+ Container
Enter:
Container Name: my-uploads
Public Access: Private
Select Create.
Step 2 – Upload a File
Open my-uploads, click Upload, select an image or PDF, and retain Block Blob as the type.
Select the Hot access tier and complete the upload.
Step 3 – Test Blob Access
Copy the blob URL and open it in a browser.
If the container is private and no authorization is supplied, Azure denies access, commonly returning an authorization-related HTTP error.
This is expected behavior.
14. Blob Container Public Access Levels
|
Access level |
Read blob |
List container |
|---|---|---|
|
Private |
Authorization required |
Authorization required |
|
Blob |
Anonymous read allowed |
Anonymous listing denied |
|
Container |
Anonymous read allowed |
Anonymous listing allowed |
Anonymous access works only when the storage account and relevant policies permit it.
For production applications, use private containers and grant access through Microsoft Entra ID or carefully scoped SAS tokens.
Part 6 – Blob Access Tiers
15. Why Do We Need Access Tiers?
Not every file is accessed frequently.
For example:
-
Today's invoice may be accessed repeatedly.
-
A document from last month may be accessed occasionally.
-
A backup from last year may rarely be needed.
Azure offers different access tiers to optimize storage and retrieval costs.
16. Hot, Cool, Cold, and Archive Tiers
|
Tier |
Typical usage |
Storage cost |
Access cost |
Availability |
|---|---|---|---|---|
|
Hot |
Frequently accessed |
Highest |
Lowest |
Online |
|
Cool |
Infrequently accessed |
Lower |
Higher |
Online |
|
Cold |
Rarely accessed |
Lower still |
Higher |
Online |
|
Archive |
Long-term retention |
Lowest |
Highest retrieval overhead |
Offline |
Hot Tier
Designed for frequently accessed data such as product images, active documents, and website assets.
Cool Tier
Suitable for infrequently accessed data that still needs immediate availability.
Cool tier has a minimum retention billing period, commonly 30 days.
Cold Tier
Suitable for rarely accessed data that must remain online.
Cold tier has a minimum retention billing period, commonly 90 days.
Archive Tier
Designed for long-term storage where immediate retrieval is unnecessary.
Archived blobs must be rehydrated to an online tier before normal reading.
Archive has a minimum retention billing period, commonly 180 days.
Important: Archive rehydration
Rehydration can take several hours, potentially up to approximately 15 hours for standard-priority retrieval.
High-priority retrieval may be faster but is more expensive and is not guaranteed to complete immediately.
Access tier transition
New File
|
v
Hot
|
After 30 Days
|
v
Cool
|
After 90 Days
|
v
Archive
|
Rehydration Required
|
v
Hot / Cool
The day thresholds in this example are illustrative policy choices, not mandatory Azure defaults.
Key point: Storage cost generally decreases as data moves to colder tiers, but access and retrieval costs increase. Early deletion charges may apply.
Part 7 – Azure Blob Lifecycle Management
17. What is Lifecycle Management?
Azure Blob Lifecycle Management automates data transitions and deletion based on defined conditions.
Without lifecycle management, administrators must manually move or delete old blobs.
With lifecycle policies, Azure evaluates rules periodically and performs eligible actions.
Example policy
|
Condition |
Action |
|---|---|
|
Last modified more than 30 days ago |
Move to Cool |
|
Last modified more than 90 days ago |
Move to Archive |
|
Last modified more than 365 days ago |
Delete |
These conditions use last-modified age, not last-access age. The two are different and should not be confused.
Lifecycle flow
Blob Uploaded
|
v
Hot Storage
|
Age > 30 Days
|
v
Cool Storage
|
Age > 90 Days
|
v
Archive Storage
|
Age > 365 Days
|
v
Delete Blob
18. Create a Lifecycle Policy in Azure Portal
Navigate to:
Storage Account
|
v
Data Management
|
v
Lifecycle Management
|
v
Add Rule
Configure:
|
Setting |
Value |
|---|---|
|
Rule name |
|
|
Scope |
All blobs |
|
Blob type |
Block blobs |
|
Blob subtype |
Base blobs |
Under the base blob conditions, configure the tier transitions and deletion thresholds.
Select Add to save the rule.
Azure evaluates lifecycle policies on a periodic basis, typically daily. Execution is asynchronous, so actions should not be treated as guaranteed to occur at an exact clock time.
Important production considerations
-
Scope policies to the intended containers or prefixes.
-
Avoid applying deletion policies to critical data unintentionally.
-
Consider minimum retention charges.
-
Understand how versioning and soft delete affect deletion.
-
Configure separate rules for old versions when necessary.
-
Use last-access-based rules only when the required tracking configuration is supported and enabled.
Part 8 – Shared Access Signatures (SAS)
19. What is a Shared Access Signature?
A Shared Access Signature is a signed token that grants limited access to Azure Storage resources.
It can specify permissions, resource scope, validity period, and protocol restrictions.
A SAS is useful when an application needs to provide temporary file access without making the entire container public.
Example scenario
A customer wants to download an invoice PDF stored in a private container.
Instead of making the container public, the application generates a read-only SAS URL that expires after a short period.
Customer Browser
|
v
ASP.NET Core API
|
Validate Customer
|
v
Generate SAS
|
v
Return SAS URL
|
v
Azure Blob
|
v
Download PDF
20. SAS URL Structure
Example:
https://jntechstorage2026.blob.core.windows.net/
invoices/invoice.pdf
?sv=2023-11-03
&se=2026-10-16T10%3A00%3A00Z
&sr=b
&sp=r
&sig=SIGNATURE
|
Parameter |
Meaning |
|---|---|
|
|
Storage service version |
|
|
Expiry time |
|
|
Signed resource |
|
|
Permissions |
|
|
Cryptographic signature |
Common permission letters include r for read, w for write, d for delete, and l for list, depending on the SAS type and resource.
A SAS is a bearer credential: anyone possessing a valid SAS URL can exercise its granted permissions until it expires or otherwise becomes invalid.
21. Types of SAS
|
SAS type |
Description |
|---|---|
|
User Delegation SAS |
Signed using a delegation key obtained through Microsoft Entra ID |
|
Service SAS |
Grants access to a specific storage service |
|
Account SAS |
Can grant access across supported storage services and operations |
Production recommendation: Prefer User Delegation SAS for Blob Storage when possible, using Microsoft Entra ID instead of distributing account keys.
22. Generate a SAS Token in Azure Portal
-
Open the storage account and navigate to the private container.
-
Select the required blob.
-
Open Generate SAS.
-
Select the available signing method.
-
Grant only the required permission, such as Read.
-
Set a short expiration period and HTTPS-only access.
-
Generate the SAS URL.
-
Test it in a browser.
For a demonstration, account-key signing may be used when permitted. Production environments should favor identity-based authorization.
SAS Security Best Practices
-
Use HTTPS only.
-
Grant minimum required permissions.
-
Keep expiry periods short.
-
Never publish SAS URLs in source control.
-
Do not log complete SAS tokens.
-
Avoid exposing account keys.
-
Validate application-level authorization before issuing a SAS.
Part 9 – Static Website Hosting with Azure Blob Storage
23. What is Azure Static Website Hosting?
Azure Storage supports hosting static website content directly from a storage account.
It can serve HTML, CSS, JavaScript, images, and other static files without provisioning an Azure VM or App Service compute instance.
When static website hosting is enabled, Azure creates a special container named $web.
Architecture
User Browser
|
v
Azure Static Website Endpoint
|
v
Storage Account
|
v
$web Container
|
+--------+--------+
| | |
v v v
index.html style.css app.js
Suitable applications
-
Static portfolio websites.
-
Landing pages.
-
Documentation websites.
-
Static React or Angular build outputs.
-
HTML/CSS/JavaScript websites.
Limitations
Azure Blob Static Website Hosting cannot directly execute server-side ASP.NET Core code.
An Angular application hosted there can still call a separately hosted ASP.NET Core Web API.
24. Host a Static Website – Step by Step
Step 1 – Enable Static Website Hosting
Navigate to:
Storage Account
|
v
Data Management
|
v
Static Website
|
v
Enabled
Configure:
Index Document: index.html
Error Document: 404.html
Click Save.
Azure creates the $web container and provides a primary website endpoint.
The endpoint's zone identifier is assigned by Azure; do not assume it will always be z13.
Step 2 – Create index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Azure Static Website</title>
</head>
<body>
<h1>Hello from Azure Storage!</h1>
<p>This website is hosted using Azure Blob Storage.</p>
</body>
</html>
Step 3 – Upload Files
Open the $web container and upload index.html.
Step 4 – Test the Website
Open the primary endpoint displayed in the Static website settings.
Your HTML page should load.
Step 5 – Configure a Custom Domain
For production websites, configure DNS and HTTPS using a supported front-end service such as Azure Front Door or Azure CDN where appropriate.
Custom-domain HTTPS should not be assumed to work simply by creating a CNAME record.
25. Azure Blob Static Website vs Azure App Service
|
Feature |
Blob Static Website |
Azure App Service |
|---|---|---|
|
Static HTML/CSS/JS |
Yes |
Yes |
|
Angular/React SPA |
Yes |
Yes |
|
ASP.NET Core Web API |
No |
Yes |
|
Server-side execution |
No |
Yes |
|
Compute plan |
Not required |
Required |
|
Deployment slots |
No |
Supported on eligible tiers |
|
Built-in application runtime |
No |
Yes |
Example architecture: Angular + ASP.NET Core
User Browser
|
+---------+---------+
| |
v v
Angular Frontend ASP.NET Core API
Azure Storage Azure App Service
| |
| v
| SQL Database
| |
+-------------------+
|
Blob Storage
Images/Documents
Additional consideration: Blob static hosting has limited SPA route fallback and HTTP status customization. Angular applications using client-side routing may benefit from Azure Static Web Apps or a front-end routing service.
Part 10 – Azure Blob Versioning
26. What is Blob Versioning?
Blob Versioning is a data protection feature that preserves previous versions of a blob when it is modified or deleted.
Each stored version has a unique version identifier.
Example
Suppose a file named resume.pdf is uploaded multiple times.
resume.pdf
|
+------------+------------+
| | |
v v v
Version 1 Version 2 Version 3
Original Updated Current
With versioning enabled, older versions can be accessed or restored.
Benefits
-
Recover accidentally overwritten files.
-
Access historical versions.
-
Improve operational recovery.
-
Support document revision history.
Versioning is not a complete backup or disaster-recovery strategy on its own.
27. Enable Blob Versioning
Navigate to:
Storage Account
|
v
Data Management
|
v
Data Protection
|
v
Enable Versioning for Blobs
|
v
Save
Versioning availability depends on the storage account configuration and supported features.
28. Practical Demo – Restore an Older Version
Step 1 – Create Version 1
Create notes.txt:
Version 1 - Original Content
Upload it to my-uploads.
Step 2 – Upload Version 2
Modify the file:
Version 2 - Updated Content
Upload it again using the same blob name and overwrite the existing blob.
Step 3 – View Versions
Open the blob and select the available version-history view.
You can inspect version IDs and historical content.
Step 4 – Restore Version 1
Select the required historical version and use the available restore or copy-to-current operation.
The restored content becomes the current blob.
Important: Versioning is not retroactive. Enabling it does not automatically create historical versions of changes that happened before the feature was enabled.
29. Blob Versioning vs Soft Delete
|
Feature |
Versioning |
Soft Delete |
|---|---|---|
|
Main purpose |
Preserve historical content |
Recover deleted resources |
|
Accidental overwrite |
Yes |
Can help with recovery when configured |
|
Accidental deletion |
Historical versions may remain |
Retains deleted data |
|
Retention |
Versions persist until removed by applicable operations/policies |
Configured retention period |
|
Additional cost |
Yes |
Yes |
Recommended protection architecture
Blob Storage
|
+----------+----------+
| |
v v
Versioning Soft Delete
| |
Recover Older Recover Deleted
Versions Blobs
| |
+----------+----------+
|
v
Lifecycle Policies
|
Retention Control
For stronger protection, consider container soft delete, point-in-time restore where supported, and immutability policies for regulatory requirements.
30. Blob Versioning and Storage Cost
Each retained version can contribute to storage consumption.
For example, if a 10 MB block blob is repeatedly overwritten and ten full versions are retained, the logical retained data can total approximately 100 MB.
Actual billing depends on storage operations, block reuse, tier, redundancy, and retained data.
To control costs, configure lifecycle policies for historical versions.
Permanently deleting versions
Deleting a current blob does not necessarily remove its historical versions.
To permanently remove retained versions, you must consider:
-
Whether blob or container soft delete is enabled.
-
Whether the version is protected by immutability or a legal hold.
-
Whether permanent deletion is supported and enabled for the relevant resource.
-
Whether old versions must first pass through a soft-delete retention period.
Deleting the current version alone should not be treated as permanent deletion of all stored data.
Part 11 – Azure Storage Security and Authentication
31. How is Azure Blob Storage Secured?
Azure Storage provides multiple security mechanisms to protect data against unauthorized access.
Security can be applied at different layers.
Client Application
|
v
HTTPS / TLS
|
v
Azure Storage Account
|
+------------+------------+
| | |
v v v
Identity Networking Encryption
and RBAC Controls at Rest
|
v
Container
|
v
Private Blob
Important security features
|
Feature |
Purpose |
|---|---|
|
Microsoft Entra ID |
Identity-based authentication |
|
Azure RBAC |
Role-based authorization |
|
Managed Identity |
Access without application-managed credentials |
|
SAS |
Temporary delegated access |
|
Storage firewall |
Restrict network access |
|
Private Endpoint |
Private connectivity through a virtual network |
|
Encryption at rest |
Protect stored data |
|
HTTPS |
Protect data during transmission |
32. Microsoft Entra ID and Azure RBAC
Microsoft Entra ID provides identity-based authentication for Azure Storage.
Azure Role-Based Access Control determines which storage operations an identity can perform.
Common Blob Storage roles
|
Role |
Permissions |
|---|---|
|
Storage Blob Data Reader |
Read and list blob data |
|
Storage Blob Data Contributor |
Read, write, and delete blob data |
|
Storage Blob Data Owner |
Full blob data access, including managing access through supported mechanisms |
Important: Azure management roles such as Contributor do not automatically grant Blob data-plane permissions through Microsoft Entra ID.
33. What is Managed Identity?
Managed Identity allows an Azure resource, such as Azure App Service, to authenticate to other Azure services without storing passwords or storage account keys in application configuration.
Example
ASP.NET Core API
Azure App Service
|
v
Managed Identity
|
v
Microsoft Entra ID
|
RBAC Authorization
|
v
Azure Blob Storage
Advantages
-
No storage account keys in source code.
-
No manual password rotation.
-
Integration with Azure RBAC.
-
Reduced risk of credential exposure.
For production applications, Managed Identity with appropriate RBAC permissions is generally preferable to storing storage account connection strings.
Part 12 – Azure Blob Storage with ASP.NET Core
34. How to Upload a File to Azure Blob Storage Using C#
Azure provides the Azure.Storage.Blobs NuGet package for interacting with Blob Storage.
Step 1 – Install Packages
dotnet add package Azure.Storage.Blobs
dotnet add package Azure.Identity
Step 2 – Configure Program.cs
using Azure.Identity;
using Azure.Storage.Blobs;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();
builder.Services.AddSingleton(_ =>
new BlobServiceClient(
new Uri(builder.Configuration["Storage:BlobServiceUri"]!),
new DefaultAzureCredential()));
var app = builder.Build();
app.MapControllers();
app.Run();
Step 3 – Configure appsettings.json
{
"Storage": {
"BlobServiceUri": "https://jntechstorage2026.blob.core.windows.net"
}
}
DefaultAzureCredential supports local developer authentication and Managed Identity when deployed to Azure.
The application identity needs the appropriate Blob Storage data role.
Step 4 – Create Blob Storage Service
using Azure.Storage.Blobs;
public class BlobStorageService
{
private readonly BlobServiceClient _blobServiceClient;
public BlobStorageService(BlobServiceClient blobServiceClient)
{
_blobServiceClient = blobServiceClient;
}
public async Task<string> UploadAsync(
Stream fileStream,
string fileName,
string contentType)
{
var container = _blobServiceClient
.GetBlobContainerClient("my-uploads");
var blob = container.GetBlobClient(fileName);
await blob.UploadAsync(
fileStream,
new Azure.Storage.Blobs.Models.BlobUploadOptions
{
HttpHeaders =
new Azure.Storage.Blobs.Models.BlobHttpHeaders
{
ContentType = contentType
}
});
return blob.Uri.ToString();
}
}
Step 5 – Register the Service
builder.Services.AddScoped<BlobStorageService>();
Step 6 – Create Upload API
using Microsoft.AspNetCore.Mvc;
[ApiController]
[Route("api/files")]
public class FilesController : ControllerBase
{
private readonly BlobStorageService _blobService;
public FilesController(BlobStorageService blobService)
{
_blobService = blobService;
}
[HttpPost("upload")]
public async Task<IActionResult> Upload(IFormFile file)
{
if (file == null || file.Length == 0)
return BadRequest("File is required.");
var fileName =
$"{Guid.NewGuid():N}{Path.GetExtension(file.FileName)}";
using var stream = file.OpenReadStream();
var url = await _blobService.UploadAsync(
stream,
fileName,
file.ContentType);
return Ok(new { FileUrl = url });
}
}
This is a simplified learning example. For production, add file-size limits, extension and content validation, malware scanning where appropriate, authorization, and robust exception handling.
Also note that the returned blob URL does not automatically grant read access to a private container.
35. Real-World ASP.NET Core Architecture
For an article publishing platform, Blob Storage can store uploaded article images and documents while SQL Server stores article metadata.
Angular Admin
|
v
ASP.NET Core API
|
+---------+---------+
| |
v v
SQL Server Blob Storage
| |
Article Title Article Image
Description PDF Documents
Category Attachments
Image URL
Recommended workflow
-
The administrator uploads an image through Angular.
-
ASP.NET Core validates the file.
-
The API uploads the image to a private Blob container.
-
Azure returns the blob's resource URL.
-
SQL Server stores the blob name or URL as metadata.
-
The application provides authorized access to the image when needed.
For publicly accessible article images, a CDN or other controlled public delivery mechanism can be considered.
Part 13 – Monitoring, Cost Optimization, and Best Practices
36. Azure Storage Monitoring
Azure Monitor provides metrics and diagnostic capabilities for Azure Storage.
Important metrics include:
|
Metric |
Purpose |
|---|---|
|
Used Capacity |
Monitor storage consumption |
|
Transactions |
Monitor storage operations |
|
Availability |
Measure successful service availability |
|
Success E2E Latency |
Measure end-to-end request latency |
|
Success Server Latency |
Measure storage service processing latency |
|
Ingress |
Monitor incoming data |
|
Egress |
Monitor outgoing data |
Use Azure Monitor alerts to detect abnormal activity, capacity growth, or availability issues.
37. Azure Storage Cost Components
Azure Storage billing depends on several factors.
-
Amount of stored data.
-
Performance and access tiers.
-
Replication strategy.
-
Read, write, and other transactions.
-
Data retrieval and transfer.
-
Retained blob versions and snapshots.
-
Soft-deleted data.
-
Early deletion charges where applicable.
Example
Assume a storage account contains:
Current Blobs = 10 GB
Previous Versions = 15 GB
Snapshots = 5 GB
-----
Logical Total = 30 GB
All retained data may contribute to billable storage, subject to actual block usage and billing rules.
Therefore, checking only the size of current blobs can underestimate total storage consumption.
38. Blob Snapshot vs Blob Versioning
|
Feature |
Snapshot |
Versioning |
|---|---|---|
|
Creation |
Explicit operation |
Automatically preserves previous states |
|
Purpose |
Point-in-time copy |
Automatic version history |
|
Identifier |
Snapshot timestamp |
Version ID |
|
Restore |
Copy snapshot data |
Promote or copy an older version |
|
Cost |
Retained data is billable |
Retained data is billable |
Snapshots are useful when an application or administrator needs an explicitly created point-in-time copy.
Versioning is useful when historical copies should be retained automatically.
39. Azure Storage Best Practices
For production environments:
-
Use private containers by default.
-
Prefer Microsoft Entra ID and Managed Identity.
-
Grant minimum required RBAC permissions.
-
Disable anonymous access unless needed.
-
Require HTTPS and modern TLS.
-
Use private endpoints for sensitive workloads.
-
Enable appropriate soft delete and versioning protections.
-
Use lifecycle management to control historical data costs.
-
Choose redundancy based on business recovery requirements.
-
Configure Azure Monitor alerts.
-
Avoid storing account keys and SAS tokens in source code.
-
Test data restoration and disaster recovery procedures.
Part 14 – Practical Troubleshooting
40. Common Azure Blob Storage Problems
|
Problem |
Possible cause |
Recommended action |
|---|---|---|
|
AuthorizationPermissionMismatch |
Identity lacks required data permissions |
Verify Blob data RBAC role |
|
AuthenticationFailed |
Invalid signature or credentials |
Verify SAS and authentication |
|
PublicAccessNotPermitted |
Anonymous access disabled |
Use authorized access |
|
BlobNotFound |
Incorrect blob path or deleted blob |
Verify name and versions |
|
ContainerNotFound |
Incorrect container name |
Check container existence |
|
Slow archive retrieval |
Blob is offline |
Rehydrate the blob |
|
Unexpected storage bill |
Versions, snapshots, redundancy, transactions |
Review usage and retention |
|
Static website returns 404 |
Missing index file or incorrect route |
Verify |
For private blobs, a missing or invalid authorization mechanism can produce different error codes depending on the request and storage configuration.
Part 15 – Important Azure Storage Interview Questions and Answers
The following questions focus specifically on the topics covered in this article.
Group 1 – Azure Storage Fundamentals
Q1. What is Azure Storage?
Azure Storage is a Microsoft-managed cloud storage platform for storing structured and unstructured data. It supports services such as Blob, Files, Queue, and Table Storage.
Q2. What is an Azure Storage Account?
A Storage Account is a top-level Azure resource providing a unique namespace and configuration for supported storage services, including security, redundancy, and networking.
Q3. What are the four main Azure Storage services?
Blob Storage stores objects, Azure Files provides file shares, Queue Storage supports messaging, and Table Storage stores NoSQL entities.
Q4. What is the difference between Standard and Premium Storage?
Standard Storage is cost-optimized for general workloads. Premium Storage uses performance-optimized infrastructure for workloads requiring low latency and higher throughput.
Q5. Why must a storage account name be globally unique?
Because the account name forms part of Azure Storage DNS endpoints, such as accountname.blob.core.windows.net.
Group 2 – Azure Storage Redundancy
Q6. What is the difference between LRS and ZRS?
LRS maintains three copies within one physical location. ZRS distributes three copies across three availability zones in a supported region.
Q7. What is the difference between GRS and GZRS?
GRS uses LRS in the primary and secondary regions. GZRS uses ZRS in the primary region and LRS in the secondary region.
Q8. What is RA-GRS?
RA-GRS is Read-Access Geo-Redundant Storage. It allows read access to the secondary region, although replicated data may be delayed.
Q9. Does GRS guarantee zero data loss during regional failover?
No. Replication to the secondary region is asynchronous, so recently written data may not yet have been replicated.
Group 3 – Blob Storage
Q10. What is Azure Blob Storage?
Azure Blob Storage is an object storage service designed for unstructured data such as images, videos, documents, and backups.
Q11. What are the three blob types?
Block Blob, Append Blob, and Page Blob.
Q12. What is the difference between Block Blob and Append Blob?
Block Blob supports general file storage and block-based updates. Append Blob is optimized for sequentially appending new data.
Q13. Which blob type is suitable for uploading PDF files?
Block Blob is the preferred type for storing PDFs, images, videos, and general application files.
Q14. Can a Blob container contain another container?
No. Containers cannot be nested, but blob names can contain separators that create a virtual folder structure.
Group 4 – Access Tiers and Lifecycle Management
Q15. What are the Azure Blob access tiers?
Hot, Cool, Cold, and Archive. They provide different storage and retrieval pricing characteristics.
Q16. What is the difference between Hot and Cool tiers?
Hot has higher storage cost and lower access cost. Cool has lower storage cost but higher access and retrieval costs.
Q17. What is Archive Storage?
Archive is an offline access tier designed for rarely accessed, long-term data. Archived blobs require rehydration before normal access.
Q18. What is Blob rehydration?
Rehydration is the process of returning an archived blob to an online tier such as Hot or Cool.
Q19. What is Azure Blob Lifecycle Management?
Lifecycle Management automatically transitions or deletes eligible blobs according to rules based on properties such as age, access time, and blob type.
Q20. How frequently are lifecycle policies evaluated?
Azure evaluates lifecycle management rules periodically, typically once per day. Actions execute asynchronously.
Group 5 – Shared Access Signatures and Security
Q21. What is a SAS token?
A Shared Access Signature grants limited access to Azure Storage resources through a signed token with defined permissions and validity.
Q22. What are the three types of SAS?
User Delegation SAS, Service SAS, and Account SAS.
Q23. Which SAS type is recommended for Blob Storage?
User Delegation SAS is generally preferred because it uses Microsoft Entra ID authorization rather than requiring account-key-based signing.
Q24. What is the difference between SAS and RBAC?
RBAC grants permissions to identities through Azure authorization. SAS delegates scoped access through a signed token.
Q25. What is Managed Identity?
Managed Identity allows Azure resources to authenticate securely to other Azure services without storing application-managed credentials.
Group 6 – Static Website Hosting
Q26. Can Azure Blob Storage host a website?
Yes. Azure Storage can host static websites containing HTML, CSS, JavaScript, and other static files.
Q27. What is the $web container?
It is the special container automatically created when static website hosting is enabled in an Azure Storage Account.
Q28. Can we host an ASP.NET Core Web API in Blob Storage?
No. Blob Static Website Hosting cannot execute server-side application code. ASP.NET Core APIs require a compatible compute service.
Q29. Can we host Angular in Azure Blob Storage?
Yes. Angular build output can be hosted as static files. However, client-side routing and custom HTTP responses may require additional configuration or a different hosting service.
Group 7 – Blob Versioning and Data Protection
Q30. What is Azure Blob Versioning?
Blob Versioning automatically retains previous versions when a supported blob is modified or deleted, allowing historical versions to be accessed or restored.
Q31. What is the difference between Blob Versioning and Soft Delete?
Versioning maintains historical blob states. Soft Delete retains deleted data for a configured retention period to support recovery.
Q32. What is the difference between Blob Snapshot and Versioning?
Snapshots are explicitly created point-in-time copies. Versioning automatically maintains historical versions of supported blobs.
Q33. Does Blob Versioning increase storage cost?
Yes. Retained versions consume billable storage, depending on their stored data and block usage.
Q34. How do you restore a previous blob version?
Identify the required historical version and use the available copy or make-current operation to restore its contents.
Q35. How can you permanently delete old blob versions?
Delete the relevant historical versions and account for soft-delete retention, immutability policies, and any applicable permanent-delete capabilities. Lifecycle rules can automate removal of eligible older versions.
Group 8 – ASP.NET Core and Real-Time Scenarios
Q36. How do you upload files to Azure Blob Storage using ASP.NET Core?
Use the Azure.Storage.Blobs SDK and BlobClient.UploadAsync() after authenticating with an authorized identity.
await blobClient.UploadAsync(fileStream, overwrite: true);
Q37. How do you securely connect Azure App Service to Blob Storage?
Enable Managed Identity on App Service, assign the required Storage Blob Data role, and authenticate through DefaultAzureCredential.
Q38. Where should you store uploaded images in an ASP.NET Core application?
Store image content in Blob Storage and keep the blob name, URL, or other metadata in SQL Server.
Q39. How can you reduce Azure Blob Storage costs?
Choose suitable access tiers, use lifecycle management, remove unnecessary versions and snapshots, and select redundancy based on actual recovery requirements.
Q40. What happens when a blob is overwritten while versioning is enabled?
Azure preserves the previous blob state as a historical version, subject to the supported blob type and account configuration.
Part 16 – Key Takeaways
Azure Storage provides scalable cloud storage without requiring organizations to manage physical storage infrastructure.
The most important concepts are:
-
Storage Account: The top-level resource and namespace for Azure Storage services.
-
Blob Storage: Object storage for unstructured application data.
-
Redundancy: LRS, ZRS, GRS, and GZRS provide different resilience levels.
-
Blob Types: Block, Append, and Page blobs support different workloads.
-
Access Tiers: Hot, Cool, Cold, and Archive help optimize storage costs.
-
Lifecycle Management: Automatically transitions or deletes eligible data.
-
SAS: Provides temporary, permission-scoped access to storage resources.
-
Static Website Hosting: Serves static web assets without an application server.
-
Versioning and Soft Delete: Provide recovery options for modified and deleted data.
-
Managed Identity: Enables secure application access without embedded credentials.
-
ASP.NET Core Integration: Uses the Azure Storage SDK to upload, retrieve, and manage application files.
For .NET developers, Azure Blob Storage is particularly valuable for storing application images, user uploads, documents, backups, and other binary content independently of the application's relational database.
Tags: Azure Storage, Azure Blob Storage,
Azure Storage Account, Azure Redundancy, Azure SAS, Blob Lifecycle Management, Blob Versioning, Azure Static Website, Azure Security, ASP.NET Core, Azure Interview Questions, Microsoft Azure