← Back to Articles         
Azure Storage Account and Blob Storage

Azure Storage Account and Blob Storage

Published on 15 Oct 2026     31 min read Microsoft AZURE
Azure Storage Account

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:

  1. What an Azure Storage Account is and how its unified namespace works.

  2. The four Azure Storage services: Blob, Files, Queue, and Table.

  3. Standard and Premium storage performance tiers.

  4. Replication strategies: LRS, ZRS, GRS, GZRS, RA-GRS, and RA-GZRS.

  5. Blob Storage architecture, containers, and blob types.

  6. Hot, Cool, Cold, and Archive access tiers.

  7. Lifecycle management for automatic tier transitions and deletion.

  8. Shared Access Signatures (SAS) and secure file sharing.

  9. Hosting static websites directly from Azure Blob Storage.

  10. Blob versioning, soft delete, and restoring previous versions.

  11. Authentication using Microsoft Entra ID, RBAC, and Managed Identity.

  12. Integrating Azure Blob Storage with ASP.NET Core.

  13. Monitoring, cost optimization, and production best practices.

  14. 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

https://jntechstorage2026.blob.core.windows.net

File

https://jntechstorage2026.file.core.windows.net

Queue

https://jntechstorage2026.queue.core.windows.net

Table

https://jntechstorage2026.table.core.windows.net

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-demo-rg

Storage account name

jntechstorage2026

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

auto-tier-rule

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

sv

Storage service version

se

Expiry time

sr

Signed resource

sp

Permissions

sig

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

  1. Open the storage account and navigate to the private container.

  2. Select the required blob.

  3. Open Generate SAS.

  4. Select the available signing method.

  5. Grant only the required permission, such as Read.

  6. Set a short expiration period and HTTPS-only access.

  7. Generate the SAS URL.

  8. 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

  1. The administrator uploads an image through Angular.

  2. ASP.NET Core validates the file.

  3. The API uploads the image to a private Blob container.

  4. Azure returns the blob's resource URL.

  5. SQL Server stores the blob name or URL as metadata.

  6. 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:

  1. Use private containers by default.

  2. Prefer Microsoft Entra ID and Managed Identity.

  3. Grant minimum required RBAC permissions.

  4. Disable anonymous access unless needed.

  5. Require HTTPS and modern TLS.

  6. Use private endpoints for sensitive workloads.

  7. Enable appropriate soft delete and versioning protections.

  8. Use lifecycle management to control historical data costs.

  9. Choose redundancy based on business recovery requirements.

  10. Configure Azure Monitor alerts.

  11. Avoid storing account keys and SAS tokens in source code.

  12. 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 $web content and routing

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

 

 

 

← Back to Articles