← Back to Articles         
Azure Storage Account: Azure Files, File Sync, Queue Storage, Table Storage

Azure Storage Account: Azure Files, File Sync, Queue Storage, Table Storage

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

Azure Storage Services – Complete Guide to Azure Files, File Sync, Queue Storage, Table Storage, Security, AzCopy and Storage Explorer

Azure Administration | AZ-104 | Hands-on Tutorials | Architecture | Interview Preparation

Introduction

Microsoft Azure provides several storage services designed for different application and infrastructure requirements. While Azure Blob Storage is primarily designed for object storage, other Azure Storage services support shared file systems, asynchronous messaging, structured NoSQL data, hybrid file synchronization, and enterprise data protection.

In this article, we will explore seven important areas of Azure Storage:

  1. Azure Files: Fully managed cloud file shares accessible through SMB, NFS, and REST APIs.

  2. Azure Queue Storage: Reliable asynchronous messaging between distributed application components.

  3. Azure Table Storage: Scalable, schemaless NoSQL storage for structured data.

  4. Azure File Sync: Synchronization between on-premises Windows file servers and Azure Files.

  5. Azure Storage Security: Firewalls, private endpoints, authentication, and immutable storage.

  6. AzCopy: High-performance command-line data transfers and migration.

  7. Azure Storage Explorer: A desktop application for managing Azure Storage resources.

The article includes practical Azure Portal demonstrations, Windows and Linux commands, Python and C# examples, real-world architecture scenarios, best practices, and important AZ-104 and technical interview questions.

The content follows the supplied learning material, with additional explanations and corrections where needed.

What You'll Learn

By the end of this article, you will understand:

  • How Azure Files differs from Azure Blob Storage.

  • How to create, mount, secure, and recover Azure file shares.

  • How snapshots and soft delete protect data.

  • How Azure File Sync and cloud tiering reduce on-premises storage requirements.

  • How Queue Storage enables asynchronous communication between applications.

  • How message visibility timeouts, retries, and idempotency work.

  • How Table Storage uses PartitionKey and RowKey.

  • How to design efficient NoSQL partitioning strategies.

  • How to restrict storage access using firewalls and private endpoints.

  • How to migrate data using AzCopy.

  • How immutable storage supports regulatory retention requirements.

  • How to administer storage through Azure Storage Explorer.

  • How to choose the correct storage service for real-world requirements.

 

Part 1: Azure Files

1.1 What Is Azure Files?

Azure Files is a fully managed cloud file-sharing service that provides shared file storage without requiring you to maintain a traditional file server.

In an on-premises environment, organizations commonly configure Windows Server file shares to provide centralized access to documents, configuration files, reports, and application data.

Azure Files provides similar functionality through Microsoft-managed infrastructure.

Supported access methods

Protocol

Purpose

SMB

Network file sharing for Windows and supported Linux clients

NFS

Network file sharing for supported Linux/Unix workloads

HTTPS/REST

Programmatic access without mounting

Azure SDK

Application integration with Azure Files

SMB commonly uses TCP port 445. Azure Files NFS uses NFSv4.1 over TCP port 2049.

Architecture

                    Azure Storage Account
                              |
                              v
                        Azure Files
                              |
                      my-file-share
                              |
             +----------------+----------------+
             |                |                |
             v                v                v
        Windows VM        Linux VM         Application
             |                |                |
         SMB 445          SMB / NFS         HTTPS REST
             |                |                |
             v                v                v
          Z:\Drive        /mnt/myfiles       Azure SDK

Multiple machines can access the same Azure file share, subject to permissions, network connectivity, and protocol support.

1.2 Why Do We Need Azure Files?

Consider a company operating three application servers.

Each server needs access to the same configuration documents, reports, and shared files.

Without centralized storage, administrators must manually copy files between servers or maintain a separate file server.

With Azure Files, all servers can access a centralized share.

             Azure File Share
               SharedData
                   |
       +-----------+-----------+
       |           |           |
       v           v           v
    Server 1    Server 2    Server 3
       |           |           |
       +-----------+-----------+
                   |
            Same shared files

Common use cases

Scenario

Benefit

Lift-and-shift migration

Move compatible file-share workloads to Azure

Shared application configuration

Centralized configuration access

Application reports

Multiple servers access generated reports

User home directories

Centralized user file storage

Shared application content

Consistent access across application instances

Hybrid file servers

Integrates with Azure File Sync

CI/CD workloads

Shared build files and caches where appropriate

Important: Azure Files is a managed file service, but it is not automatically a replacement for every workload that previously used a local disk. Applications with very high IOPS, strict latency requirements, or specialized locking behavior need compatibility and performance testing.

1.3 Azure Files vs Azure Blob Storage

Feature

Azure Files

Azure Blob Storage

Storage model

Managed file share

Object storage

Primary protocols

SMB, NFS, REST

HTTPS/REST

Folder structure

File-system directories

Blob names and optional hierarchical namespace

Traditional drive mounting

Native SMB/NFS

Requires additional tooling or supported integrations

Typical use

Shared folders, file servers

Images, videos, backups, documents

Application access

File-system APIs or SDK

Blob SDK or REST

Azure File Sync

Supported

Not directly supported

Shared network drive

Primary use case

Not its primary use case

For example, an ASP.NET Core application storing public article images would commonly use Blob Storage. An enterprise application that requires multiple servers to read and write files using standard network file-sharing protocols may benefit from Azure Files.

1.4 Azure Files Storage Tiers

The supplied material identifies four commonly encountered Azure Files tiers.

Tier

Storage

Recommended use

Transaction Optimized

Standard HDD

General-purpose workloads with frequent transactions

Hot

Standard HDD

Frequently accessed files

Cool

Standard HDD

Infrequently accessed data

Premium

SSD

Low-latency and performance-sensitive workloads

Important update: Azure Files provisioning models

Azure Files also distinguishes between provisioned and pay-as-you-go billing models. Modern SSD offerings can use provisioned v2, where storage capacity, IOPS, and throughput can be configured separately. HDD offerings and supported tier choices depend on the storage account and provisioning model.

Consequently, the statement that a tier can never be changed is too broad. Some access-tier changes are supported, while changing storage media or provisioning models can require migration to a new share.

Also, NFS support is associated with specific supported Azure Files configurations; it should not be assumed that every Premium or SSD share automatically supports every protocol.

Choosing a tier

              Application Requirement
                        |
                        v
              Shared File Storage?
                        |
                       Yes
                        |
           +------------+------------+
           |                         |
           v                         v
     Standard Workload         Low Latency Needed
           |                         |
           v                         v
       HDD Options               SSD Options
           |
     +-----+------+
     |     |      |
     v     v      v
 Transaction Hot  Cool
 Optimized

Always verify the available tiers, protocols, and pricing model when creating a new share.

1.5 Hands-on: Create an Azure File Share

Step 1: Create or select a storage account

  1. Sign in to the Azure Portal.

  2. Open Storage accounts.

  3. Select an existing compatible storage account or create a new one.

  4. Open Data storage → File shares.

  5. Select + File share.

Step 2: Configure the share

Setting

Example

Storage account

lwmstoragedemo

Share name

my-file-share

Tier

Transaction Optimized, if available

Protocol

SMB

Backup

Configure according to requirements

Select Create.

Step 3: Upload files

Open the share and select Upload.

Upload a sample document, then create a directory named configs and upload another file inside it.

The resulting structure will resemble:

my-file-share/
|
+-- sample-document.pdf
|
+-- configs/
    |
    +-- appsettings.json
    |
    +-- application-config.txt

Unlike blob name prefixes, Azure Files exposes real file-system directory operations.

1.6 Mount Azure Files on a Windows Laptop or VM

Azure Files can be accessed from a local Windows laptop if the network permits SMB connectivity and the share is configured for compatible authentication.

Step 1: Test port 445

Open PowerShell:

Test-NetConnection `
  -ComputerName lwmstoragedemo.file.core.windows.net `
  -Port 445

Expected result:

ComputerName     : lwmstoragedemo.file.core.windows.net
RemotePort       : 445
TcpTestSucceeded : True

If the result is False, the ISP, corporate firewall, local network, or storage network configuration may be blocking access.

Step 2: Mount the file share

For a demonstration using storage account key authentication:

net use Z: \\lwmstoragedemo.file.core.windows.net\my-file-share /user:Azure\lwmstoragedemo "YOUR_STORAGE_KEY" /persistent:yes

Replace YOUR_STORAGE_KEY with the actual storage account key.

After successful authentication, open File Explorer and navigate to:

Z:\

The Azure file share behaves like a mapped network drive.

Step 3: Disconnect the share

net use Z: /delete

Security recommendation: Prefer identity-based SMB authentication where supported. Storage account keys provide broad privileges and should not be embedded in application source code or shared with ordinary users.

For private or restricted networks, consider private endpoints and an appropriately configured VPN or ExpressRoute connection.

1.7 Mount Azure Files on Linux

Linux can mount Azure Files using SMB/CIFS, and supported NFS shares can use NFSv4.1.

SMB example on Ubuntu

Install the CIFS utilities:

sudo apt update
sudo apt install cifs-utils -y

Create the mount directory:

sudo mkdir -p /mnt/myfileshare

For a demonstration, mount using the storage account credentials:

sudo mount -t cifs \
  //lwmstoragedemo.file.core.windows.net/my-file-share \
  /mnt/myfileshare \
  -o vers=3.0,username=lwmstoragedemo,password=YOUR_STORAGE_KEY,serverino

Verify:

df -h
ls /mnt/myfileshare

In production, use a protected credentials file or another supported authentication mechanism rather than putting secrets directly in command history.

NFS example

For a properly configured NFS share and permitted network:

sudo mount -t nfs \
  -o vers=4.1,sec=sys \
  STORAGE_ACCOUNT.file.core.windows.net:/STORAGE_ACCOUNT/SHARE_NAME \
  /mnt/myfileshare

Use the exact NFS mount command generated by Azure for the selected share. NFS access depends on supported storage account settings and network restrictions.

1.8 Azure File Share Snapshots

A file share snapshot is a read-only, point-in-time representation of an Azure file share.

Snapshots are useful when files are accidentally deleted, overwritten, or corrupted.

               Azure File Share
                      |
              Current Files
                      |
          +-----------+-----------+
          |           |           |
          v           v           v
       Snapshot 1  Snapshot 2  Snapshot 3
        09:00 AM    11:00 AM    02:00 PM
          |           |           |
          v           v           v
       Historical Share States

Benefits

  • Restore accidentally deleted or overwritten files.

  • Recover previous file versions.

  • Establish recovery checkpoints.

  • Support backup and retention strategies.

Snapshots are incremental in their storage behavior: unchanged data can be shared, while changed or deleted data may increase billed snapshot storage.

They are not necessarily free, and they are not a substitute for a complete backup strategy.

Hands-on: Create and restore a snapshot

  1. Open Storage account → File shares → my-file-share.

  2. Navigate to Snapshots.

  3. Select Add snapshot.

  4. Optionally provide a description such as before-deployment.

  5. Create the snapshot.

  6. Modify or delete a test file in the active share.

  7. Open the snapshot and locate the previous version.

  8. Copy or restore the file using the available recovery operation.

You can also configure Azure Backup for supported Azure Files workloads to manage backup policies and retention.

1.9 Soft Delete for Azure File Shares

Soft delete protects against accidental deletion of an entire file share.

When enabled, a deleted share remains recoverable for the configured retention period.

Example

        Active File Share
               |
               v
         Delete Share
               |
               v
        Soft Deleted Share
               |
       +-------+--------+
       |                |
       v                v
  Undelete Share   Retention Expires
       |                |
       v                v
  Share Restored    Permanent Deletion

Hands-on: Enable soft delete

  1. Open the storage account.

  2. Navigate to Data protection.

  3. Enable Soft delete for file shares.

  4. Configure a retention period, for example, seven days.

  5. Save the configuration.

To test recovery, delete a nonproduction file share, display deleted shares, and select Undelete.

Snapshot vs soft delete

Feature

Snapshot

Soft delete

Primary purpose

Point-in-time recovery

Recover deleted shares

Recovery scope

Individual files or share content

Entire deleted share

Protects overwritten files

Yes, if captured in a snapshot

Not by itself

Protects deleted share

Depends on recovery configuration

Yes, within retention

Retention

Managed snapshots or backup policy

Configured soft-delete period

Key point: Soft delete at the share level does not provide general file-level version history. Use snapshots or backup for file-level recovery.

 

Part 2: Azure Queue Storage

2.1 What Is Azure Queue Storage?

Azure Queue Storage is a managed messaging service that allows applications to communicate asynchronously.

A queue stores messages sent by one application component until another component is ready to process them.

The component that sends messages is called a Producer, and the component that receives and processes messages is called a Consumer.

Architecture

                 ASP.NET Core Web API
                       Producer
                          |
                          | Send Message
                          v
                   Azure Queue Storage
                          |
                   +------+------+
                   | Order 1001  |
                   | Order 1002  |
                   | Order 1003  |
                   +------+------+
                          |
                          | Receive Message
                          v
                    Background Worker
                       Consumer
                          |
                          v
                     Process Order
                          |
                          v
                    SQL Database
                          |
                          v
                    Delete Message

The producer does not need to wait for the consumer to complete its work.

This pattern is known as asynchronous messaging or loosely coupled communication.

2.2 Why Do We Need Queue Storage?

Consider an e-commerce application.

When a customer places an order, the system may need to:

  • Save the order.

  • Generate an invoice.

  • Send a confirmation email.

  • Update inventory.

  • Notify the shipping service.

Without asynchronous processing, the user might wait while all these operations execute.

With Queue Storage, the API can persist the order, enqueue a processing request, and return a response quickly.

                Customer
                   |
                   v
              Place Order
                   |
                   v
             ASP.NET Core API
                   |
             Save Order in DB
                   |
                   v
             Send Queue Message
                   |
                   v
          Return Order Accepted
                   |
                   |
         Background Processing
                   |
                   v
             Queue Consumer
                   |
          +--------+--------+
          |        |        |
          v        v        v
       Invoice    Email   Inventory

Advantages

  1. Loose coupling: Producers and consumers operate independently.

  2. Improved responsiveness: Users do not wait for lengthy background operations.

  3. Reliability: Messages can remain queued while consumers are unavailable.

  4. Scalability: Multiple consumers can process queued workloads.

  5. Load buffering: Sudden traffic increases can be absorbed by the queue.

  6. Retry capability: Uncompleted messages can become visible again.

2.3 Azure Queue Storage Important Properties

Property

Description

Maximum message size

64 KiB

Queue capacity

Can contain very large numbers of messages, subject to account capacity

Default message TTL

7 days

Maximum TTL

Can be configured as unlimited for supported API versions

Visibility timeout

Temporarily hides received messages

Delivery guarantee

At least once

Message ordering

Strict FIFO is not guaranteed

Authentication

Microsoft Entra ID, SAS, or storage account keys

The supplied notes describe seven days as the maximum message lifetime. More precisely, seven days is the default; modern Azure Queue Storage APIs support longer or non-expiring message lifetimes.

2.4 What Is a Visibility Timeout?

A visibility timeout is the period during which a received message is hidden from other consumers.

Suppose a consumer receives a message with a visibility timeout of 30 seconds.

Time       Queue / Consumer Action
------------------------------------------------
00 sec     Consumer A receives Order 1001
           |
           v
           Message becomes invisible
           |
10 sec     Consumer A processes order
           |
20 sec     Processing completes
           |
25 sec     Consumer A deletes message
           |
           v
           Message permanently removed

Now consider a consumer failure:

00 sec     Consumer A receives message
              |
              v
10 sec     Consumer A crashes
              |
              v
30 sec     Visibility timeout expires
              |
              v
           Message becomes visible
              |
              v
           Consumer B receives message
              |
              v
           Processing retries

Important clarification

Visibility timeout reduces simultaneous processing but does not guarantee exactly-once processing.

For example, Consumer A might complete a database update but crash before deleting the message. Consumer B may subsequently process the same message.

Therefore, consumers must be designed to be idempotent.

2.5 What Is Idempotency?

Idempotency means processing the same logical request multiple times produces the same intended result as processing it once.

For example, if Order 1001 has already been processed, receiving the same queue message again should not generate a duplicate invoice or charge the customer twice.

Simple C# example

public async Task ProcessOrderAsync(int orderId)
{
    bool processed = await _db.ProcessedOrders
        .AnyAsync(x => x.OrderId == orderId);

    if (processed)
        return;

    // Process the order.
}

This demonstrates the concept, but a production implementation needs a database uniqueness constraint and transactional processing to prevent race conditions when two workers process the same order concurrently.

2.6 Hands-on: Create a Queue

Step 1: Open Queue Storage

  1. Open your storage account in Azure Portal.

  2. Navigate to Data storage → Queues.

  3. Select + Queue.

  4. Enter order-queue.

  5. Select OK.

Step 2: Add a message

Open order-queue and select Add message.

Enter:

{
  "orderId": "1001",
  "product": "Azure Course",
  "qty": 1
}

Configure the message expiry and select OK.

Add two more messages:

{
  "orderId": "1002",
  "product": "DevOps Course",
  "qty": 2
}
{
  "orderId": "1003",
  "product": "Linux Course",
  "qty": 1
}

You now have three messages waiting to be processed.

2.7 Peek vs Receive vs Delete

These operations have different meanings.

Operation

Purpose

Removes message?

Peek

Inspect a message without hiding it

No

Receive

Retrieve and temporarily hide a message

No

Delete

Permanently remove a message using its receipt

Yes

Message lifecycle

               Send Message
                    |
                    v
              Visible in Queue
                    |
             Receive Message
                    |
                    v
              Invisible State
                    |
          +---------+---------+
          |                   |
          v                   v
    Processing Success    Processing Failure
          |                   |
          v                   v
     Delete Message      Timeout Expires
          |                   |
          v                   v
       Completed         Visible Again
                              |
                              v
                         Retry Processing

2.8 Python Example: Send Messages

Install the Azure Queue Storage SDK:

pip install azure-storage-queue

Set a connection string through an environment variable rather than hardcoding it in the Python file.

import osfrom azure.storage.queue import QueueClientconnection_string = os.environ["AZURE_STORAGE_CONNECTION_STRING"]queue_client = QueueClient.from_connection_string(    connection_string,    "order-queue")orders = [    '{"orderId":"2001","product":"Azure Course","qty":1}',    '{"orderId":"2002","product":"DevOps Course","qty":2}',    '{"orderId":"2003","product":"Linux Course","qty":1}']for order in orders:    queue_client.send_message(order)    print(f"Sent: {order}")
 

Peek at messages

messages = queue_client.peek_messages(max_messages=10)for message in messages:    print(message.content)
 

Peeking does not make messages invisible or remove them.

2.9 ASP.NET Core Example: Send a Queue Message

For an ASP.NET Core application, install the package:

dotnet add package Azure.Storage.Queues

Configure the queue client

using Azure.Storage.Queues;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddSingleton(_ =>
{
    var connectionString =
        builder.Configuration.GetConnectionString("AzureStorage");

    return new QueueClient(connectionString, "order-queue");
});

var app = builder.Build();

Store the connection string in user secrets, environment variables, or another secure configuration provider.

Create an endpoint

app.MapPost("/orders", async (
    OrderRequest order,
    QueueClient queueClient) =>
{
    string json = JsonSerializer.Serialize(order);

    await queueClient.SendMessageAsync(json);

    return Results.Accepted();
});

app.Run();

record OrderRequest(int OrderId, string Product, int Qty);

Add the required namespace:

using System.Text.Json;

The queue must already exist, and the connection must have permission to send messages.

Example request

POST /orders
Content-Type: application/json

{
  "orderId": 1001,
  "product": "Azure Course",
  "qty": 1
}

The API submits the message without waiting for order-processing work to finish.

In a production order system, persist the order reliably and consider the transactional outbox pattern to avoid losing messages when database and queue operations cannot participate in one atomic transaction.

2.10 ASP.NET Core Background Worker: Receive Messages

A background worker can consume messages independently.

using Azure.Storage.Queues;
using Microsoft.Extensions.Hosting;

public class OrderWorker : BackgroundService
{
    private readonly QueueClient _queue;

    public OrderWorker(QueueClient queue)
    {
        _queue = queue;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            var response = await _queue.ReceiveMessageAsync(
                visibilityTimeout: TimeSpan.FromMinutes(2),
                cancellationToken: stoppingToken);

            var message = response.Value;

            if (message != null)
            {
                // Process the order successfully before deleting.

                await _queue.DeleteMessageAsync(
                    message.MessageId,
                    message.PopReceipt,
                    stoppingToken);
            }

            await Task.Delay(1000, stoppingToken);
        }
    }
}

Register the worker:

builder.Services.AddHostedService<OrderWorker>();

This example illustrates the receive/delete lifecycle. Production consumers should add exception handling, structured logging, idempotency, poison-message handling, and appropriate retry/backoff behavior.

2.11 Queue Storage vs Azure Service Bus

Feature

Azure Queue Storage

Azure Service Bus

Purpose

Simple asynchronous messaging

Enterprise messaging

Maximum message size

64 KiB

Depends on Service Bus tier

FIFO ordering

Not guaranteed

Supported through sessions

Dead-letter queue

Must be implemented by application

Built-in

Duplicate detection

Application responsibility

Available on supported tiers

Publish/subscribe

Not built in

Topics and subscriptions

Transactions

Limited storage operation model

Broker transaction capabilities

Complexity

Low

Higher

Choose Queue Storage for simple, scalable background workloads. Choose Service Bus when you require advanced broker capabilities such as sessions, dead-letter queues, duplicate detection, or topics.

 

Part 3: Azure Table Storage

3.1 What Is Azure Table Storage?

Azure Table Storage is a managed NoSQL service designed to store large amounts of structured, non-relational data.

Unlike SQL Server, Azure Table Storage does not require every record to follow the same column structure.

This is called a schemaless data model.

For example, a learning platform might store student course progress:

                  Azure Table Storage
                          |
                          v
                    courseprogress
                          |
           +--------------+--------------+
           |                             |
           v                             v
     PartitionKey                  PartitionKey
      student-001                   student-002
           |                             |
      +----+----+                        |
      |         |                        |
      v         v                        v
    day-07    day-08                   day-07
      |         |                        |
   score=92  completed=false          score=78

Each entity can contain different properties.

3.2 Important Table Storage Concepts

Concept

Description

Storage account

Hosts the Table Storage service

Table

Collection of entities

Entity

Individual record

Property

Field within an entity

PartitionKey

Groups related entities

RowKey

Uniquely identifies an entity within its partition

Timestamp

System-managed modification timestamp

ETag

Used for optimistic concurrency

The combination of PartitionKey and RowKey uniquely identifies an entity.

PartitionKey + RowKey = Unique Entity Identity

Example

PartitionKey

RowKey

Completed

Score

student-001

day-07

true

92

student-001

day-08

false

—

student-002

day-07

true

78

The same RowKey can exist in different partitions.

However, two entities cannot have the same combination of PartitionKey and RowKey in the same table.

3.3 What Is PartitionKey?

PartitionKey is used to logically group entities.

For example:

PartitionKey = student-001

        +--------------------+
        | student-001        |
        +--------------------+
        | day-01             |
        | day-02             |
        | day-03             |
        | day-04             |
        +--------------------+

A query for a specific partition can be efficient because Azure can identify the relevant partition.

However, Azure manages the physical distribution of partitions internally. You should not assume every entity with a particular key is permanently stored on one physical server.

Good partition-key design

A good partition key should:

  • Support the application's most common query patterns.

  • Distribute workload appropriately.

  • Avoid creating a single heavily accessed partition.

  • Support efficient point queries.

  • Minimize unnecessary cross-partition scans.

Example query

PartitionKey eq 'student-001'

For a single entity:

PartitionKey eq 'student-001'
and RowKey eq 'day-07'

A point query using both keys is generally the most efficient retrieval pattern.

3.4 Table Storage vs SQL Server

Feature

Azure Table Storage

Azure SQL Database

Database model

NoSQL key-value/attribute store

Relational

Schema

Flexible

Defined tables and columns

Primary lookup

PartitionKey + RowKey

Primary keys and indexes

SQL joins

Not supported

Supported

Foreign keys

Not supported

Supported

Complex aggregations

Limited

Supported

Transaction support

Atomic batches within supported partition constraints

Relational transactions

Best use

Simple large-scale key lookups

Relational business applications

For example, SQL Server is usually the better choice for an order-management system with customers, orders, order details, and payment relationships.

Table Storage can be a good choice for storing simple configuration records, device telemetry metadata, or user preferences.

3.5 Table Storage vs Azure Cosmos DB

Azure Cosmos DB is a broader managed NoSQL database platform offering advanced global distribution and multiple data models or APIs.

Feature

Azure Table Storage

Azure Cosmos DB

Complexity

Relatively simple

More advanced

Pricing

Storage and transactions

Depends on selected capacity model

Global distribution

Storage-account redundancy options

Advanced multi-region distribution

Query capabilities

Basic OData filters

Depends on selected API

Throughput management

Storage service limits

Provisioned or serverless options

Best fit

Straightforward key-based workloads

Applications needing advanced NoSQL capabilities

Azure Cosmos DB for Table also supports applications using the Table API, but it has different pricing, performance, and feature characteristics.

3.6 Hands-on: Create an Azure Table

Step 1: Create a table

  1. Open the storage account.

  2. Navigate to Data storage → Tables.

  3. Select + Table.

  4. Enter courseprogress.

  5. Select OK.

Step 2: Insert an entity

Open Storage browser → Tables → courseprogress and add:

Property

Type

Value

PartitionKey

String

student-001

RowKey

String

day-07

completed

Boolean

true

score

Int32

92

Insert another entity:

Property

Type

Value

PartitionKey

String

student-001

RowKey

String

day-08

completed

Boolean

false

The second entity does not require a score property.

This demonstrates schema flexibility.

Step 3: Query records

Apply the filter:

PartitionKey eq 'student-001'

Both records belonging to the student are returned.

3.7 C# Example: Insert and Query Table Entities

Install the package:

dotnet add package Azure.Data.Tables

Insert an entity

using Azure.Data.Tables;

string connectionString =
    Environment.GetEnvironmentVariable(
        "AZURE_STORAGE_CONNECTION_STRING")!;

var tableClient = new TableClient(
    connectionString,
    "courseprogress");

await tableClient.CreateIfNotExistsAsync();

var entity = new TableEntity(
    "student-001",
    "day-07")
{
    { "Completed", true },
    { "Score", 92 }
};

await tableClient.AddEntityAsync(entity);

Retrieve an entity

var response = await tableClient
    .GetEntityAsync<TableEntity>(
        "student-001",
        "day-07");

Console.WriteLine(response.Value["Score"]);

Query by partition

await foreach (var entity in tableClient
    .QueryAsync<TableEntity>(
        x => x.PartitionKey == "student-001"))
{
    Console.WriteLine(entity.RowKey);
}

3.8 Additional Concepts: ETag and Concurrency

An ETag represents the version of an entity.

It can help prevent one application instance from accidentally overwriting changes made by another.

             Application A
                  |
                  v
           Read Entity ETag1
                  |
                  |
             Application B
                  |
                  v
           Update Entity ETag2
                  |
                  |
             Application A
                  |
                  v
        Update Using Old ETag1
                  |
                  v
           Conflict Detected

This is called optimistic concurrency control.

Azure Table Storage also supports transactional entity batches, subject to constraints such as entities belonging to the same partition.

Important limitations

  • No native relational joins.

  • No foreign-key relationships.

  • Limited secondary indexing.

  • A maximum entity size of 1 MiB.

  • Partitioning must be designed around access patterns.

  • Very large or hot partitions can become performance bottlenecks.

 

Part 4: Azure File Sync

4.1 What Is Azure File Sync?

Azure File Sync enables organizations to synchronize files between on-premises Windows Servers and Azure file shares.

It is particularly useful for organizations migrating traditional file-server workloads to Azure without immediately removing their on-premises infrastructure.

Architecture

                     Microsoft Azure
                           |
                           v
                   Azure File Share
                     Cloud Endpoint
                           |
                           v
                   Azure File Sync
                           |
                 Storage Sync Service
                           |
                  +--------+--------+
                  |                 |
                  v                 v
            Windows Server 1  Windows Server 2
                  |                 |
              Sync Agent        Sync Agent
                  |                 |
                  v                 v
             Local Files       Local Files
                  |                 |
                  v                 v
                Users             Users

The Azure file share acts as the central cloud endpoint, while supported Windows Servers synchronize their local folders with it.

4.2 Why Do We Need Azure File Sync?

Consider a company using an on-premises Windows file server.

Employees access files using:

\\fileserver01\documents

The server is running out of disk space.

Replacing its storage hardware may be expensive, but migrating every application and user to a different file-access method may be difficult.

Azure File Sync allows the organization to keep its existing file-server access pattern while storing the complete synchronized dataset in Azure.

Benefits

  • Supports hybrid cloud environments.

  • Reduces on-premises storage requirements through cloud tiering.

  • Maintains familiar local file-server access.

  • Synchronizes files across multiple registered servers.

  • Provides centralized cloud storage.

  • Integrates with Azure Files backup and recovery options.

Azure File Sync is not an instantaneous replication system. Changes are synchronized asynchronously, and propagation times vary.

4.3 Important Azure File Sync Components

Component

Purpose

Storage Sync Service

Azure resource that manages synchronization

Sync Group

Defines related cloud and server endpoints

Cloud Endpoint

Azure file share used by the sync group

Server Endpoint

Local folder on a registered Windows Server

Registered Server

Windows Server registered with the sync service

Azure File Sync Agent

Software installed on Windows Server

Cloud Tiering

Moves infrequently accessed file content out of local storage

4.4 What Is Cloud Tiering?

Cloud tiering allows Azure File Sync to reduce the amount of local disk space consumed by infrequently accessed files.

Frequently accessed files can remain fully cached on the local server.

Less frequently accessed files can be replaced with small placeholders that preserve their file-system presence.

When a user opens a tiered file, Azure File Sync recalls its contents from Azure.

                   Windows File Server
                            |
                 +----------+----------+
                 |                     |
                 v                     v
              Hot Files             Cold Files
                 |                     |
                 v                     v
           Stored Locally        Placeholder Only
                                       |
                                       |
                               User Opens File
                                       |
                                       v
                                 Azure File Share
                                       |
                                       v
                                Download Content
                                       |
                                       v
                                  File Available

Cloud tiering comparison

Feature

Tiering disabled

Tiering enabled

Local file content

Full synchronized dataset

Selected content cached locally

Disk requirements

Higher

Potentially much lower

Hot-file access

Local

Local when cached

Cold-file access

Local

May require recall from Azure

Network dependency

Needed for synchronization

Also needed for recalling tiered content

Example

Suppose an organization has 1 TB of synchronized files but wants to maintain 20% free space on its local volume.

Azure File Sync can tier eligible content to help meet the configured free-space target.

However, this does not guarantee a fixed 80% disk-usage ceiling at every moment. Actual usage depends on file access patterns, available tiering candidates, recall activity, and synchronization state.

4.5 Hands-on: Configure Azure File Sync

This exercise requires a supported Windows Server and can incur Azure VM, storage, and network charges.

Step 1: Create a Storage Sync Service

  1. Open Azure Portal.

  2. Search for Azure File Sync.

  3. Select Create.

  4. Enter the following details.

Setting

Example

Resource group

storage-demo-rg

Storage Sync Service

lwm-file-sync

Region

Same region as the storage account

Select Review + create → Create.

Step 2: Create a Sync Group

Open the Storage Sync Service and select Sync groups → + Sync group.

Setting

Value

Sync group name

production-docs-sync

Storage account

lwmstoragedemo

Azure file share

my-file-share

Select Create.

Step 3: Install the Azure File Sync agent

On a supported Windows Server:

  1. Download the current Azure File Sync agent from Microsoft.

  2. Install the agent.

  3. Complete the required prerequisites.

  4. Register the server with the Storage Sync Service.

  5. Verify that the server appears under Registered servers.

Use the latest Azure File Sync support matrix to verify supported Windows Server versions and agent requirements.

Step 4: Add a server endpoint

Open the sync group and select Add server endpoint.

Setting

Value

Registered server

Your Windows Server

Local path

D:\FileShareData

Cloud tiering

Enabled

Volume free space

20%

Select Create.

Azure File Sync begins the synchronization process.

Step 5: Verify synchronization

Create a file inside:

D:\FileShareData

Wait for synchronization and confirm the file appears in the Azure file share.

You can also verify changes flowing from Azure to the server, subject to cloud change detection and synchronization delays.

4.6 Azure Files vs Azure File Sync

Azure Files

Azure File Sync

Managed cloud file-share service

Synchronization solution

Supports direct SMB/NFS access

Requires supported Windows Server endpoints

Stores file data in Azure

Synchronizes local and cloud file content

Can be mounted directly

Maintains local server paths

Suitable for cloud workloads

Suitable for hybrid file-server environments

Key point: Azure File Sync is not a separate replacement storage system. It extends Azure Files to Windows Server environments.

 

Part 5: Azure Storage Security

5.1 Storage Account Security Overview

Azure Storage security should be designed around several layers:

                  Client Application
                          |
                          v
                  Network Security
                          |
              Firewall / Private Endpoint
                          |
                          v
                    Authentication
                          |
             Entra ID / SAS / Account Key
                          |
                          v
                    Authorization
                          |
                     Azure RBAC
                          |
                          v
                    Azure Storage
                          |
                          v
               Encryption and Protection

The main security objectives are:

  • Restrict network connectivity.

  • Authenticate identities.

  • Grant minimum required permissions.

  • Encrypt data in transit and at rest.

  • Protect against accidental deletion.

  • Prevent unauthorized modification.

  • Monitor storage access.

5.2 What Is Azure Storage Firewall?

Azure Storage Firewall controls which networks can access supported storage endpoints through the public endpoint.

You can configure access for specific virtual networks, subnets, and public IP ranges.

Example

                  Internet Clients
                         |
                         v
                   Azure Storage
                      Firewall
                         |
               +---------+---------+
               |                   |
               v                   v
          Allowed IP           Blocked IP
               |                   |
               v                   v
         Access Permitted      Access Denied

Network permission does not replace authentication. An allowed client still needs valid authorization to access protected data.

5.3 Configure Storage Firewall

Step 1: Open networking settings

  1. Open your storage account.

  2. Navigate to Security + networking → Networking.

  3. Locate public network access settings.

Step 2: Restrict access

Choose the supported option for selected virtual networks and IP addresses.

Add:

  • Authorized virtual network subnets.

  • Office public IP addresses.

  • Approved client network ranges.

Save the configuration.

Step 3: Test

Attempt to access the storage account from an unauthorized network.

Data-plane requests without an applicable network exception should be blocked, typically with an HTTP 403 response.

Trusted Microsoft services

Azure Storage provides a trusted-services bypass for specifically supported services and scenarios.

This is not a blanket permission for every Azure service or every resource running inside Azure.

Enable exceptions only when required.

5.4 What Is a Private Endpoint?

A private endpoint provides a private IP address in an Azure virtual network for access to a supported Azure service.

For Azure Storage, this allows clients to access the relevant storage service over private connectivity.

                    Azure Virtual Network
                             |
                +------------+------------+
                |                         |
                v                         v
           Application VM            Private Endpoint
                                          |
                                     Private IP
                                          |
                                          v
                                    Azure Storage
                                          |
                                   Blob / File /
                                   Queue / Table

Private endpoints are configured for the required storage subresources, such as blob, file, queue, or table.

Benefits

  • Reduces exposure through public storage endpoints.

  • Supports private connectivity from Azure VNets.

  • Can support on-premises access through VPN or ExpressRoute.

  • Works with private DNS integration.

A private endpoint does not automatically disable public access. Configure public network access and DNS appropriately.

5.5 Storage Authentication Methods

Method

Description

Typical use

Microsoft Entra ID

Identity-based authentication

Recommended for supported application access

Managed Identity

Azure-managed application identity

Azure-hosted applications

SAS

Scoped, time-limited delegated access

Temporary access

Account key

Shared secret for storage account

Administrative or legacy scenarios

Identity-based SMB

Supported directory identity integration

Enterprise file shares

Recommended production architecture

                 ASP.NET Core Web API
                          |
                          v
                    Managed Identity
                          |
                          v
                   Microsoft Entra ID
                          |
                          v
                      Azure RBAC
                          |
                          v
                     Azure Storage

Managed identities eliminate the need to store long-lived account keys in application configuration.

5.6 Shared Access Signature (SAS)

A SAS token grants delegated access to Azure Storage resources according to its permissions and validity conditions.

For example, an application may generate a SAS URL that allows a user to upload a file for a limited time.

Common permissions

Permission

Purpose

Read

Read existing data

Write

Write data

Create

Create resources

Delete

Delete resources

List

List supported resources

Supported permissions vary by storage service and resource type.

Security best practices

  • Use the shortest practical expiry.

  • Grant only necessary permissions.

  • Use HTTPS.

  • Avoid logging SAS tokens.

  • Prefer user-delegation SAS for Blob Storage where appropriate.

  • Rotate or revoke credentials according to the selected SAS model.

 

Part 6: AzCopy

6.1 What Is AzCopy?

AzCopy is a command-line utility developed by Microsoft for transferring data to, from, and between supported Azure Storage services.

It is optimized for large-scale data transfers.

Common use cases

  • Uploading large folders to Azure Blob Storage.

  • Migrating data from on-premises servers.

  • Copying data between storage accounts.

  • Synchronizing local folders with supported storage destinations.

  • Transferring Azure Files data using supported operations.

  • Resuming or inspecting transfer jobs.

Architecture

                   Local File Server
                          |
                          v
                        AzCopy
                          |
                  Parallel Transfers
                          |
                          v
                    Azure Storage
                          |
                   +------+------+
                   |             |
                   v             v
              Blob Storage   Azure Files

6.2 Install AzCopy

Download AzCopy from Microsoft's official documentation:

Get started with AzCopy

After installation, verify:

azcopy --version

6.3 Authenticate Using Microsoft Entra ID

For supported storage operations:

azcopy login

You must have the appropriate Azure Storage data-plane permissions.

For example, a user uploading blobs may require the Storage Blob Data Contributor role.

AzCopy also supports SAS-based authentication and managed identity for supported environments.

6.4 Upload Files to Blob Storage

azcopy copy "C:\data\*" `
"https://mystorage.blob.core.windows.net/mycontainer?<SAS_TOKEN>" `
--recursive=true

This copies the contents of the local directory to the destination container.

Use a valid SAS token with the required permissions.

6.5 Copy Data Between Storage Accounts

azcopy copy \
"https://source.blob.core.windows.net/container?<SOURCE_SAS>" \
"https://destination.blob.core.windows.net/container?<DEST_SAS>" \
--recursive=true

The operation transfers data between supported storage endpoints.

The required authorization depends on the source and destination.

6.6 Synchronize Files

azcopy sync "C:\data" `
"https://mystorage.blob.core.windows.net/mycontainer?<SAS_TOKEN>" `
--recursive=true

AzCopy compares source and destination according to its supported synchronization behavior and transfers files that require updating.

Copy vs Sync

Copy

Sync

Copies selected source objects

Compares source and destination

Useful for bulk migration

Useful for repeated synchronization

Can overwrite destination data according to options

Transfers changed or missing data

Does not inherently mirror deletions

Can remove destination data with configured deletion options

Important: azcopy sync is not a continuous real-time synchronization service. It runs when invoked or scheduled.

Always review deletion-related options before synchronizing production data.

6.7 Monitor AzCopy Jobs

List jobs:

azcopy jobs list

Inspect a job:

azcopy jobs show JOB_ID

Resume a supported job:

azcopy jobs resume JOB_ID

AzCopy keeps job plan and log files that can assist with troubleshooting and resuming transfers.

6.8 AzCopy vs Azure Storage Explorer

Feature

AzCopy

Storage Explorer

Interface

Command line

Graphical

Bulk transfers

Excellent

Supported

Automation

Excellent

Primarily interactive

Scripting

Supported

Not its primary purpose

Manual file browsing

Limited

Excellent

Scheduled migration

Can be scripted

Requires other tooling

Best use

Large transfers and automation

Interactive storage administration

For a 2 TB data migration, AzCopy is generally more suitable than manually uploading files through the Azure Portal.

 

Part 7: Immutable Blob Storage

7.1 What Is Immutable Storage?

Immutable Blob Storage protects stored data against modification or deletion during a defined retention period or legal hold.

It follows the WORM principle:

Write Once, Read Many.

This is useful for compliance-sensitive records that must be preserved without unauthorized alteration.

Example

                   Financial Records
                          |
                          v
                    Blob Storage
                          |
                          v
                   WORM Protection
                          |
                 +--------+--------+
                 |                 |
                 v                 v
             Read Data        Modify / Delete
                 |                 |
                 v                 v
              Allowed             Blocked
                          |
                          v
                Retention / Hold Ends

Actual permitted operations depend on the configured immutability policy and supported append-write options.

7.2 Why Do We Need Immutable Storage?

Organizations may need to retain records for regulatory, legal, or audit requirements.

Examples include:

  • Financial transaction records.

  • Audit logs.

  • Legal documents.

  • Regulatory reports.

  • Compliance evidence.

  • Historical business records.

Immutable storage helps enforce retention requirements, but compliance with regulations such as SEC Rule 17a-4 depends on the full system design, configuration, operational controls, and applicable regulatory requirements.

7.3 Types of Immutability Policies

Policy

Description

Time-based retention

Protects data for a specified retention period

Legal hold

Protects data until the hold is removed

Time-based retention

For example, a financial record may need to remain immutable for seven years.

During the protected period, operations prohibited by the policy cannot be performed.

Legal hold

A legal hold is useful when records must be preserved for litigation or investigation and the required retention duration is unknown.

A legal hold remains effective until it is explicitly removed by an authorized operation.

7.4 Locked vs Unlocked Policies

Unlocked policy

Locked policy

Can be modified within supported rules

Cannot be removed or shortened

Suitable for initial validation

Suitable for finalized retention controls

More flexible

Stronger enforcement

Can be deleted where permitted

Cannot be deleted before expiry

Locking a time-based retention policy is a significant administrative decision.

Do not lock a policy until the retention configuration has been validated.

7.5 Hands-on: Configure Immutability

Step 1: Open a blob container

Navigate to:

Storage account → Containers → my-uploads

Step 2: Configure the policy

Open Access policy and locate the immutable blob storage configuration.

Choose a supported time-based retention policy and configure an example retention period of seven days.

Step 3: Test protection

Upload a test blob and attempt a prohibited modification or deletion.

Azure should reject the operation while the applicable policy protects the blob.

Step 4: Review locking

Before selecting Lock, confirm:

  • The correct container or blob is targeted.

  • The retention period is correct.

  • The business owner has approved the retention requirement.

  • The implications for deletion and cleanup are understood.

For learning exercises, avoid locking policies unnecessarily.

Important correction

The supplied material suggests that a retention timer resets whenever a blob is overwritten. This is not a general rule.

Retention behavior depends on whether the policy is container-level or version-level and which operations are permitted. Protected data generally cannot simply be overwritten in violation of the policy.

 

Part 8: Azure Storage Explorer

8.1 What Is Azure Storage Explorer?

Azure Storage Explorer is a free desktop application for managing Azure Storage resources through a graphical interface.

It supports Windows, macOS, and Linux.

Storage Explorer provides access to common storage resources, including:

  • Blob containers.

  • Azure file shares.

  • Queues.

  • Tables.

  • Supported local and emulator-based storage environments.

8.2 Why Use Storage Explorer?

The Azure Portal is convenient for administration, but Storage Explorer can be more practical for frequent file-management tasks.

Task

Azure Portal

Storage Explorer

Browse blobs

Supported

Supported

Upload multiple files

Supported

Drag-and-drop workflow

Browse Azure Files

Supported

Supported

View queue messages

Supported

Supported

Query Table Storage

Supported

Supported

Generate SAS

Supported

Supported

Manage multiple accounts

Supported

Desktop navigation

Run without a browser

No

Yes

Storage Explorer is a desktop application, but storage operations still require network connectivity. It should not be described as providing offline access to cloud data merely because the application can open without a browser.

8.3 Install Azure Storage Explorer

Download the application from:

Microsoft Azure Storage Explorer

Install it and open the application.

8.4 Connect to an Azure Subscription

  1. Open Storage Explorer.

  2. Select the account or connection option.

  3. Choose Add an Azure Account.

  4. Sign in using Microsoft Entra ID.

  5. Select the required tenant and subscription.

  6. Expand the storage account in the navigation panel

     

     

    Most Important Azure Storage Interview Questions

    Priority: 🔴 High – Must Know | 🟡 Medium – Should Know

    Group 1: Azure Files

    1. 🔴 What is Azure Files, and how is it different from Blob Storage?

    Azure Files provides managed file shares accessible through SMB, NFS, and REST. Blob Storage is object storage primarily accessed through REST APIs and SDKs.

    Key points: Azure Files = Shared drives; Blob Storage = Object storage.

    2. 🔴 What are the different Azure Files storage tiers?

    Transaction Optimized, Hot, and Cool are commonly used HDD tiers. SSD offerings provide higher performance and lower latency. Available options depend on the provisioning model.

    Key points: HDD = Cost optimization; SSD = Performance.

    3. 🔴 How do you mount Azure Files on a Windows machine?

    Use SMB over port 445 to map an Azure file share as a network drive.

    net use Z: \\account.file.core.windows.net\share /user:Azure\account "KEY"

    4. 🔴 What is the difference between Azure File Share snapshots and soft delete?

    Snapshots capture point-in-time file-share states for recovery. Soft delete protects an entire deleted share during a configured retention period.

    Key points: Snapshot = File recovery; Soft delete = Share recovery.

    Group 2: Azure File Sync

    5. 🔴 What is Azure File Sync, and why is it used?

    Azure File Sync synchronizes Azure file shares with on-premises Windows Servers. It enables hybrid file storage while maintaining existing local file-server access.

    6. 🔴 What is cloud tiering in Azure File Sync?

    Cloud tiering keeps frequently accessed files cached locally while replacing eligible infrequently accessed file content with placeholders. Files are recalled from Azure when needed.

    7. 🟡 What is the difference between a cloud endpoint and a server endpoint?

    A cloud endpoint represents an Azure file share. A server endpoint represents a local directory on a registered Windows Server.

    Group 3: Azure Queue Storage

    8. 🔴 What is Azure Queue Storage, and why is it used?

    Azure Queue Storage enables asynchronous communication between application components. Producers send messages, and consumers process them independently.

    Key points: Loose coupling, scalability, background processing.

    9. 🔴 What is a visibility timeout in Queue Storage?

    A visibility timeout temporarily hides a received message from other consumers. If the consumer fails without deleting it, the message becomes visible again.

    10. 🔴 What is the difference between Peek, Receive, and Delete?

    • Peek: Reads a message without hiding it.

    • Receive: Retrieves and temporarily hides a message.

    • Delete: Permanently removes a message after processing.

    11. 🔴 What happens if a consumer crashes while processing a queue message?

    The message becomes visible again after the visibility timeout if it was not deleted. Another consumer can receive and retry it.

    12. 🔴 What is idempotency, and why is it important in Queue Storage?

    Idempotency ensures processing the same logical message multiple times does not cause duplicate business operations. It is necessary because Queue Storage provides at-least-once delivery.

    13. 🔴 What is the difference between Azure Queue Storage and Azure Service Bus?

    Queue Storage supports simple asynchronous messaging. Service Bus provides advanced features such as dead-letter queues, sessions, duplicate detection, and publish-subscribe messaging.

    Group 4: Azure Table Storage

    14. 🔴 What is Azure Table Storage?

    Azure Table Storage is a schemaless NoSQL service for storing structured, non-relational data using key-based access.

    15. 🔴 What are PartitionKey and RowKey in Table Storage?

    PartitionKey groups related entities, while RowKey uniquely identifies an entity within a partition. Together, they form a unique composite key.

    16. 🔴 Why is PartitionKey important for performance?

    A well-designed PartitionKey enables efficient queries and distributes workload. Poor partitioning can create hotspots and reduce performance.

    17. 🔴 What is the difference between Azure Table Storage and Azure SQL Database?

    Table Storage is schemaless NoSQL with limited querying capabilities. Azure SQL Database is relational and supports joins, foreign keys, and complex queries.

    Group 5: Azure Storage Security

    18. 🔴 What is Azure Storage Firewall?

    Azure Storage Firewall restricts access to storage public endpoints based on configured network rules, such as approved IP addresses and virtual network subnets.

    19. 🔴 What is the difference between a storage firewall and a private endpoint?

    A storage firewall controls access to public endpoints. A private endpoint provides private connectivity to Azure Storage through a virtual network.

    20. 🔴 What is a Shared Access Signature (SAS)?

    A SAS grants delegated access to Azure Storage resources with specified permissions and validity conditions without sharing the storage account key.

    Group 6: AzCopy and Immutable Storage

    21. 🔴 What is AzCopy, and when should you use it?

    AzCopy is a command-line utility for high-performance transfers involving supported Azure Storage services. It is commonly used for bulk uploads and large-scale data migration.

    22. 🔴 What is the difference between azcopy copy and azcopy sync?

    azcopy copy transfers selected data, while azcopy sync compares source and destination and synchronizes changed or missing data, with optional deletion behavior.

    23. 🔴 What is immutable storage, and what are its policy types?

    Immutable Blob Storage protects data against prohibited modification or deletion. Its two main protection mechanisms are time-based retention and legal hold.

    Group 7: Real-Time Scenario-Based Questions

    24. 🔴 Your ASP.NET Core application needs to process thousands of orders asynchronously. Which Azure service would you use and why?

    Use Azure Queue Storage with background workers. The API sends messages without waiting for processing, improving responsiveness and supporting independent scaling.

    25. 🔴 Your organization wants to reduce on-premises file-server storage costs while retaining existing shared-folder paths. What would you recommend?

    Use Azure File Sync with cloud tiering. It synchronizes data with Azure Files and allows eligible infrequently accessed content to be tiered from local storage.

     

    Tags: Azure Storage, Azure Interview Questions, Azure Files, Azure File Sync, Azure Queue Storage, Azure Table Storage, Azure Storage Security, AzCopy, Immutable Storage, AZ-104, Azure Administrator, Cloud Computing

← Back to Articles