Azure Virtual Machine Management – Complete Guide to High Availability, VM Scale Sets, Disk Management, Snapshots, Custom Images, and Azure Backup

Azure Fundamentals | Azure Virtual Machines | Step-by-Step Practical Guide | Interview Preparation

Introduction

Creating an Azure Virtual Machine is only the first step in managing cloud infrastructure. In production environments, applications must remain available during hardware failures, handle sudden increases in traffic, store data reliably, and recover quickly from accidental deletion or system corruption.

Microsoft Azure provides several services to address these requirements, including Availability Sets, Availability Zones, Virtual Machine Scale Sets (VMSS), Managed Disks, Snapshots, Custom Images, and Azure Backup.

In this article, we will explore these services in detail, understand how they work, and walk through practical examples using the Azure Portal, Windows Server, and Ubuntu Linux.

The article follows the supplied Azure VM management training material, with additional explanations and operational precautions where useful.

What You'll Learn

1. Availability Sets: Protect Azure VMs against physical hardware failures and planned maintenance using Fault Domains and Update Domains.

2. Availability Zones: Distribute VMs across physically separate datacenters within an Azure region.

3. Virtual Machine Scale Sets (VMSS): Automatically scale VM instances based on CPU utilization and application demand.

4. Azure Managed Disks: Understand Standard HDD, Standard SSD, Premium SSD, and Ultra Disk.

5. Data Disk Management: Attach, initialize, format, and mount data disks on Windows Server and Ubuntu Linux.

6. VM Snapshots: Capture point-in-time copies of managed disks and restore them when required.

7. Custom VM Images: Configure an Ubuntu VM with Nginx, capture a reusable image, and deploy another VM from it.

8. Azure Backup: Configure Recovery Services Vaults, backup policies, recovery points, and retention.

9. Backup Retention: Understand daily, weekly, monthly, and yearly retention policies, including overlapping recovery points.

10. VM Recovery: Explore replacing existing VMs, creating new VMs, restoring disks, and recovering individual files.

11. Cost Management: Understand backup storage costs, VM cleanup, and resource deletion.

12. Interview Preparation: Review important interview questions and answers based exclusively on the concepts covered in this article.

Before We Begin – Set Up an Azure VM

The practical demonstrations require an existing Azure Virtual Machine.

If you already created an Ubuntu VM during your previous Azure VM exercise, you can reuse it. If it is stopped and deallocated, start it from the Azure Portal.

Otherwise, create a new VM with the following configuration.

A B1s VM is suitable for basic demonstrations, subject to regional availability and subscription quotas.

Cost note: These exercises are not automatically free. VM compute, managed disks, public IP addresses, snapshots, image storage, and Azure Backup can incur charges. Free-account credits or applicable offers may offset some costs.

Part 1 – Azure Availability Sets

1.1 Why Do We Need High Availability?

Every Azure VM runs on physical infrastructure inside a Microsoft datacenter.

This infrastructure includes:

• Physical servers and processors

• RAM and storage hardware

• Network adapters and switches

• Power supplies

• Hypervisors

Even though Azure manages the underlying infrastructure, physical hardware can fail or require maintenance.

There are two important types of infrastructure events.

Consider an ASP.NET Core Web API hosted on a single Azure VM.

                  Internet
                     |
                     v
             Azure Virtual Machine
                     |
                     v
               ASP.NET Core API
                     |
                     v
                SQL Database

           Physical Server Fails
                     |
                     v
             Application Unavailable

If the underlying physical server fails, the application may become temporarily unavailable.

For business-critical applications, this is unacceptable.

The solution is to deploy multiple VM instances and distribute them across independent infrastructure.

1.2 What Is an Availability Set?

An Azure Availability Set is a logical grouping of virtual machines that helps distribute them across different Fault Domains and Update Domains within an Azure datacenter.

Its primary purpose is to reduce the risk that a single hardware failure or planned maintenance event will affect every VM running an application.

Availability Set Architecture

                       Internet
                          |
                          v
                    Load Balancer
                          |
             +------------+------------+
             |            |            |
             v            v            v
           VM 1         VM 2         VM 3
             |            |            |
             v            v            v
        Fault Domain 0  Fault Domain 1  Fault Domain 2
          Rack A         Rack B         Rack C
             |            |            |
        Update Domain 0  Update Domain 1  Update Domain 2

              Availability Set
                  my-app-avset

The Load Balancer distributes incoming requests to healthy VM instances. The Availability Set provides infrastructure placement protection.

1.3 What Is a Fault Domain?

A Fault Domain (FD) represents a group of physical infrastructure components that share a common potential point of failure, such as power or networking equipment.

Azure distributes VMs across available Fault Domains to reduce the impact of localized hardware failures.

Example

Suppose Rack B experiences a power failure.

                   Load Balancer
                         |
           +-------------+-------------+
           |             |             |
           v             v             v
         VM 1          VM 2          VM 3
           |             |             |
        Rack A         Rack B        Rack C
           |             |             |
        Running        FAILED        Running
           |                           |
           +-------------+-------------+
                         |
                  Traffic Continues

Result: Only the VM affected by the failed Fault Domain becomes unavailable. Other healthy VMs continue serving requests.

The number of supported Fault Domains depends on the Azure region and configuration. Three domains in this example are illustrative, not a universal guarantee.

1.4 What Is an Update Domain?

An Update Domain (UD) is a logical group of VMs that Azure may restart together during planned platform maintenance.

Azure uses Update Domains to stagger maintenance instead of restarting every VM in the Availability Set simultaneously.

Example

Azure Planned Maintenance
            |
            v
     Restart UD 0
            |
       VM 1 Restarts
       VM 2 Running
       VM 3 Running
            |
            v
     Restart UD 1
            |
       VM 1 Running
       VM 2 Restarts
       VM 3 Running
            |
            v
     Restart UD 2
            |
       VM 1 Running
       VM 2 Running
       VM 3 Restarts
            |
            v
     Maintenance Complete

This helps maintain application availability during planned platform updates.

It does not eliminate every possible outage. Application-level redundancy, health checks, load balancing, and appropriate deployment configuration remain necessary.

1.5 Fault Domain vs Update Domain

Key Points

• Fault Domains protect against localized physical failures.

• Update Domains reduce simultaneous maintenance interruptions.

• Availability Sets work within a single datacenter placement scope.

• Multiple VMs are required to benefit from redundancy.

• A Load Balancer is typically used to route traffic to healthy instances.

1.6 Availability Set SLA

Azure's commonly documented Availability Set VM SLA is:

The approximate maximum downtime corresponding to 99.95% availability over a 30-day period is 21.6 minutes.

An SLA is a service commitment with eligibility conditions and possible service credits, not a guarantee that the application will never experience downtime.

1.7 Practical Demo – Create an Availability Set

Step 1 – Start Creating a VM

1. Open the Azure Portal.

2. Search for Virtual machines.

3. Select + Create → Azure virtual machine.

4. Open the Basics tab.

Step 2 – Configure Availability Options

Find the Availability options dropdown.

Select:

Availability set

Step 3 – Create an Availability Set

Select Create new.

Click OK.

The supported Fault Domain count varies by region. The Azure Portal will expose the supported configuration.

Step 4 – Assign VMs

Create the first VM using my-app-avset.

When creating the second and third VMs, select the same Availability Set.

Azure distributes the instances across the available Fault and Update Domains.

For a demonstration that only explores the settings, you can cancel the VM creation wizard without deploying additional resources.

Important: An existing VM cannot simply be assigned to a different Availability Set after deployment. Plan the Availability Set during VM creation.

Part 2 – Azure Availability Zones

2.1 What Are Availability Zones?

An Azure Availability Zone is a physically separate group of datacenters within an Azure region.

Each zone is designed with independent:

• Power infrastructure

• Cooling systems

• Networking infrastructure

Zones within the same region are connected through high-performance private networking.

Availability Zones provide a higher level of infrastructure isolation than Availability Sets.

Not every Azure region or VM SKU supports Availability Zones. Zone availability must be checked for the selected region and service.

2.2 Availability Zone Architecture

                    Azure Region
                       East US
                          |
              +-----------+-----------+
              |           |           |
              v           v           v
           Zone 1      Zone 2      Zone 3
              |           |           |
          Datacenter  Datacenter  Datacenter
              A           B           C
              |           |           |
             VM 1        VM 2        VM 3
              |           |           |
              +-----------+-----------+
                          |
                          v
                Zone-Redundant
                 Load Balancer
                          |
                          v
                       Internet

Each zone provides independent infrastructure.

If one zone experiences a datacenter-level outage, instances in the other zones can continue operating.

2.3 Availability Zone Failure Scenario

Suppose an application is deployed across three Availability Zones.

                Production Application
                          |
                          v
                    Load Balancer
                          |
             +------------+------------+
             |            |            |
             v            v            v
           Zone 1       Zone 2       Zone 3
             |            |            |
            VM 1         VM 2         VM 3
             |            |            |
          Running       FAILED       Running
             |                         |
             +------------+------------+
                          |
                          v
                 Application Available

If Zone 2 becomes unavailable, the application can continue using VMs in Zones 1 and 3, provided the application and its dependencies are designed for zone failure.

2.4 Availability Zone SLA

The approximate maximum downtime corresponding to 99.99% availability over a 30-day period is 4.32 minutes.

2.5 Availability Sets vs Availability Zones

Neither option makes the application automatically highly available. You still need sufficient healthy instances, load balancing, and resilient storage and database dependencies.

2.6 Practical Demo – Create a VM in an Availability Zone

Step 1 – Open VM Creation

Navigate to:

Azure Portal → Virtual machines → Create → Azure virtual machine

Step 2 – Select Availability Zone

On the Basics tab:

1. Select the desired Azure region.

2. Find Availability options.

3. Select Availability zone.

4. Choose Zone 1.

Step 3 – Deploy Additional VMs

For high availability, deploy additional instances into other supported zones.

The VMs remain within the same Azure region but are deployed into separate zone infrastructure.

For a settings-only exercise, click Cancel before creating the VM.

Key Points

• Availability Sets provide hardware-level fault isolation.

• Availability Zones provide datacenter-level fault isolation.

• Availability Zones are generally preferred when the application requires zone-level resilience.

• Cross-zone networking may introduce additional costs.

• The application architecture must support failover.

Part 3 – Azure Virtual Machine Scale Sets (VMSS)

3.1 Why Do We Need VM Scale Sets?

Consider an ASP.NET Core application hosted on a single Azure VM.

During normal business hours, the application receives 500 requests per minute.

During a promotional event, traffic increases to 5,000 requests per minute.

The VM may experience:

• High CPU utilization

• Increased memory usage

• Slow API responses

• Request timeouts

• Application unavailability

One solution is to deploy a larger VM, but this means paying for high capacity even when traffic is low.

A better solution is to scale the number of VM instances based on demand.

3.2 What Is a VM Scale Set?

An Azure Virtual Machine Scale Set (VMSS) is an Azure compute service that allows you to deploy and manage a group of virtual machines using a shared configuration and scaling policies.

VM Scale Sets support:

• Horizontal scaling

• Automatic instance creation

• Automatic instance removal

• Load Balancer integration

• Availability Zone integration

• Centralized VM management

The instances are commonly created from a shared VM image and configuration. Flexible orchestration also supports greater differences and control between individual VMs.

3.3 VMSS Architecture

                        Internet
                           |
                           v
                    Azure Load Balancer
                           |
             +-------------+-------------+
             |             |             |
             v             v             v
           VM 1          VM 2          VM 3
             |             |             |
             +-------------+-------------+
                           |
                           v
                       Azure Monitor
                           |
                    CPU Utilization
                           |
                    CPU > 70% for 5 min
                           |
                           v
                     Autoscale Rule
                           |
                           v
                    Add 2 New VMs
                           |
                 +---------+---------+
                 |                   |
                 v                   v
                VM 4                VM 5

Azure Monitor metrics can be used by autoscale rules to determine when instances should be added or removed.

3.4 What Is Scale-Out?

Scale-out means adding more VM instances to handle increased traffic.

Example:

Normal Traffic
      |
      v
    2 VMs
      |
      v
CPU > 70% for 5 minutes
      |
      v
Autoscale Triggered
      |
      v
Add 2 VMs
      |
      v
    4 VMs

Scale-out increases the number of available servers.

3.5 What Is Scale-In?

Scale-in means removing unnecessary VM instances when demand decreases.

Example:

Low Traffic
      |
      v
    4 VMs
      |
      v
CPU < 30% for 10 minutes
      |
      v
Autoscale Triggered
      |
      v
Remove 1 VM
      |
      v
    3 VMs

Scale-in reduces infrastructure costs.

3.6 Example Autoscale Configuration

The minimum instance count helps preserve baseline capacity, while the maximum limits resource consumption and cost.

Actual scaling also depends on metric aggregation, cooldown periods, available capacity, and successful instance provisioning.

3.7 VMSS Orchestration Modes

Azure supports two VMSS orchestration modes.

Flexible orchestration is generally recommended for new deployments when its capabilities match the workload.

Uniform orchestration remains useful for highly standardized deployments and certain scale-set features.

3.8 VMSS and Load Balancer

VMSS and Azure Load Balancer are separate services.

• VMSS: Manages the number and lifecycle of VM instances.

• Load Balancer: Distributes incoming network traffic among backend instances.

A VMSS can exist without a Load Balancer, for example, when processing background jobs. However, web applications typically require an appropriate load-balancing or application-routing service.

Practical Example – ASP.NET Core Web API

                    Client Requests
                          |
                          v
                    Load Balancer
                          |
             +------------+------------+
             |            |            |
             v            v            v
         Web API 1    Web API 2    Web API 3
             |            |            |
             +------------+------------+
                          |
                          v
                  Shared SQL Database

All API instances connect to the same shared database.

Important: Applications deployed to automatically scaled VMs should avoid storing essential session state or user data only on the local VM. New instances must be able to start and serve traffic independently.

The supplied training material schedules the complete VMSS and Load Balancer deployment demonstration for Day 8.

Key Points

• VMSS enables horizontal scaling.

• Scale-out adds instances; scale-in removes instances.

• Autoscale rules can use CPU metrics.

• Minimum and maximum limits help control availability and cost.

• Load balancing is typically required for user-facing web applications.

• Flexible and Uniform orchestration serve different deployment requirements.

Part 4 – Azure Disk Management

4.1 What Is Azure Managed Disk?

An Azure Managed Disk is a block-level storage resource managed by Microsoft Azure and used by Azure Virtual Machines.

When creating a VM, Azure automatically provisions an OS disk. Additional data disks can be attached to store application files, database files, logs, and other persistent data.

Azure manages the underlying storage infrastructure, so you do not need to manually create and maintain storage accounts for managed VM disks.

Azure VM Disk Architecture

                 Azure Virtual Machine
                          |
            +-------------+-------------+
            |             |             |
            v             v             v
         OS Disk       Data Disk    Temporary Disk
            |             |             |
      Operating OS    Application     Swap / Cache
      System Files    Data / Logs     Temporary Files
            |             |             |
        Persistent     Persistent      Ephemeral
            |             |             |
       Managed Disk   Managed Disk    Local Storage

Separating the operating system and application data improves storage management, backup planning, and migration flexibility.

4.2 Types of Azure Managed Disks

Azure provides four commonly used managed disk performance categories in the supplied material.

These are illustrative performance figures from the supplied material, not universal current limits. Actual performance depends on disk SKU, size, provisioned performance, VM limits, and Azure service capabilities. Azure also offers newer disk options such as Premium SSD v2.

Standard HDD

Standard HDD is a low-cost disk type suited to workloads with limited performance requirements.

Typical use cases: Development environments, testing, and infrequently accessed data.

Standard SSD

Standard SSD provides a balance between cost and performance.

Typical use cases: Small websites, development servers, lightly loaded production applications, and CI/CD agents.

Premium SSD

Premium SSD is designed for workloads requiring more predictable, higher-performance storage.

Typical use cases: Production databases, enterprise applications, and transaction-intensive workloads.

Ultra Disk

Ultra Disk is designed for demanding workloads requiring very high IOPS and throughput.

Typical use cases: SAP HANA, high-frequency transaction processing, and performance-sensitive databases.

4.3 What Are IOPS and Throughput?

IOPS (Input/Output Operations Per Second) measures how many read or write operations a disk can perform per second.

Throughput measures how much data can be transferred per second, commonly expressed in MB/s.

For example, a database executing many small transactions often requires high IOPS, while an application reading or writing large files may require high throughput.

Disk latency is another important performance metric because it measures how long an individual I/O request takes.

4.4 Three Types of Disks Associated with Azure VMs

Important: Temporary Disk

Temporary disks are not durable storage. Their contents can be lost during deallocation, redeployment, host maintenance, or other VM lifecycle events.

Not every Azure VM size provides a local temporary disk.

Never store critical application data, database files, or irreplaceable documents on temporary disks.

4.5 Practical Demo – Attach a Data Disk Using Azure Portal

Step 1 – Open VM Disk Settings

Navigate to:

Azure Portal → Virtual machines → Select VM → Disks

You will see the existing OS disk and any attached data disks.

Step 2 – Create a New Data Disk

Select Create and attach a new disk.

Select Save.

Azure provisions and attaches the managed disk. Supported data-disk attachment operations can be performed without restarting the VM.

Step 3 – Initialize the Disk

The disk is now attached to the VM, but it must be prepared by the guest operating system before normal file storage can begin.

The steps differ between Windows Server and Ubuntu Linux.

4.6 Practical Demo – Initialize a Data Disk on Windows Server

Step 1 – Connect to the VM

Navigate to:

Azure Portal → Windows VM → Connect → RDP

Download the RDP file and sign in.

Step 2 – Open Disk Management

Press Win + R and execute:

diskmgmt.msc

Disk Management displays the available storage devices.

You may see:

Disk 0
    |
    +-- C: Operating System

Disk 1
    |
    +-- Unknown
    +-- Not Initialized
    +-- Unallocated

Confirm the disk number and capacity before proceeding. Disk numbering is not guaranteed to be identical on every VM.

Step 3 – Initialize the Disk

Right-click the new disk and select Initialize Disk.

Windows offers two partition styles.

Select GPT and click OK.

Step 4 – Create a Volume

Right-click the unallocated space and select New Simple Volume.

Complete the wizard:

1. Choose the maximum volume size.

2. Assign drive letter E:.

3. Select NTFS.

4. Keep the default allocation unit size.

5. Enter volume label DataDisk.

6. Enable quick format.

7. Click Finish.

Step 5 – Verify

Open File Explorer.

You should see:

This PC
   |
   +-- Local Disk (C:)
   |
   +-- DataDisk (E:)

Create a folder or test file on E: to verify that the new disk is usable.

Key Points

• An attached disk must be initialized before use.

• GPT is preferred for modern data disks.

• NTFS is a common Windows Server filesystem.

• Confirm the disk identity before initializing or formatting it.

• The data disk remains separate from the OS disk.

4.7 Practical Demo – Initialize a Data Disk on Ubuntu Linux

Step 1 – Connect Using SSH

ssh -i ~/Downloads/your-key.pem azureuser@<your-vm-ip>

Replace the placeholder with your VM's public IP address.

Step 2 – List Block Devices

lsblk

Example output:

NAME    SIZE  TYPE  MOUNTPOINT
sda      30G  disk
└─sda1   30G  part  /
sdb       4G  disk
└─sdb1    4G  part  /mnt
sdc       4G  disk

In this example:

• /dev/sda is the OS disk.

• /dev/sdb is the temporary disk.

• /dev/sdc is the newly attached data disk.

Important: Linux disk names can differ between VM generations, images, and storage controllers. Some Azure VMs use NVMe device names. Verify the actual device using lsblk, disk size, and Azure disk identifiers before running partitioning commands.

Step 3 – Partition the Data Disk

For this example, assume the new empty disk is /dev/sdc.

sudo fdisk /dev/sdc

Inside fdisk, use the following commands:

The exact prompts depend on the partition-table type. For a modern GPT partition table, use g first if needed, then create the partition.

Expected result:

/dev/sdc
    |
    +-- /dev/sdc1

Step 4 – Format the Partition

sudo mkfs.ext4 /dev/sdc1

This creates an ext4 filesystem on the new partition.

Warning: Formatting destroys existing filesystem data on the selected partition. Perform this step only on the verified new disk.

Step 5 – Create a Mount Point

sudo mkdir -p /mnt/data

Mount the partition:

sudo mount /dev/sdc1 /mnt/data

Step 6 – Verify the Mount

df -h

Example:

Filesystem    Size   Used   Avail   Mounted on
/dev/sda1      30G     5G     25G   /
/dev/sdc1     3.9G    24M    3.7G   /mnt/data

Step 7 – Make the Mount Persistent

A manual mount normally does not survive a reboot unless configured for automatic mounting.

The source material uses:

echo '/dev/sdc1 /mnt/data ext4 defaults 0 0' | sudo tee -a /etc/fstab

This demonstrates the purpose of /etc/fstab, but using a device name such as /dev/sdc1 is less reliable because Linux device assignments can change.

For a more robust configuration, identify the filesystem UUID:

sudo blkid /dev/sdc1

Back up the configuration:

sudo cp /etc/fstab /etc/fstab.bak

Edit the file:

sudo nano /etc/fstab

Add an entry using the actual UUID returned by blkid:

UUID=<actual-uuid> /mnt/data ext4 defaults,nofail 0 2

Save the file and validate the configuration:

sudo systemctl daemon-reload
sudo mount -a

Check the file:

cat /etc/fstab

Step 8 – Test the Disk

sudo touch /mnt/data/testfile.txt
ls -l /mnt/data

Expected result:

testfile.txt

The data disk is now partitioned, formatted, mounted, and configured for automatic mounting.

Linux Data Disk Workflow

Attach Azure Managed Disk
            |
            v
       Run lsblk
            |
            v
   Identify New Disk
            |
            v
    Partition with fdisk
            |
            v
    Format with mkfs.ext4
            |
            v
   Create Mount Directory
            |
            v
    Mount the Partition
            |
            v
    Configure /etc/fstab
            |
            v
     Verify Persistence

Key Points

• lsblk lists block devices.

• fdisk manages partitions.

• mkfs.ext4 creates an ext4 filesystem.

• mount attaches a filesystem to a directory.

• df -h verifies mounted filesystems and capacity.

• /etc/fstab configures persistent mounts.

• UUID-based mounts are generally safer than device-name-based mounts.

Part 5 – Azure VM Snapshots

5.1 What Is a Snapshot?

An Azure Snapshot is a read-only, point-in-time copy of a managed disk.

Snapshots capture disk state so that new managed disks can later be created from that state.

Azure supports full and incremental snapshot capabilities, depending on the snapshot configuration.

5.2 Why Do We Need Snapshots?

Snapshots are useful before performing potentially risky operations such as:

• Operating system upgrades

• Application installations

• Configuration changes

• Disk migrations

• VM decommissioning

• Creating a duplicate disk for testing

Snapshot Workflow

                  Azure VM
                     |
                     v
                  OS Disk
                     |
                     v
              Create Snapshot
                     |
                     v
          Point-in-Time Disk Copy
                     |
          +----------+----------+
          |                     |
          v                     v
     Create New Disk       Retain for
          |                Later Recovery
          v
    Attach or Use
    as Replacement

5.3 Snapshot vs Azure Backup

Snapshots are useful, but they are not a replacement for a complete backup strategy.

5.4 Practical Demo – Create a VM Snapshot

Step 1 – Open VM Disks

Navigate to:

Azure Portal → Virtual machines → Select VM → Disks

Step 2 – Open the OS Disk

Click the OS disk name to open the managed disk resource.

Step 3 – Create a Snapshot

Select Create snapshot.

Select Review + create → Create.

Step 4 – Verify

Search for Snapshots in the Azure Portal.

Confirm that the snapshot appears.

Step 5 – Restore from the Snapshot

Open the snapshot and select Create disk.

Azure creates a new managed disk from the snapshot.

For an OS disk, you can use the restored disk to create a VM or follow a supported OS-disk replacement procedure. Simply attaching it as an ordinary data disk will not cause the VM to boot from it.

Key Points

• Snapshots are read-only point-in-time disk copies.

• Snapshots can be used to create replacement or cloned disks.

• Snapshot storage is billable.

• Application consistency requires appropriate preparation.

• Azure Backup is preferable for scheduled production recovery.

Part 6 – Azure Custom VM Images

6.1 What Is a Custom VM Image?

A Custom VM Image is a reusable VM deployment image containing an operating system and predefined software configuration.

Instead of manually configuring each new VM, administrators can prepare one source VM, capture its image, and use that image to deploy additional VMs.

A custom image can include the OS disk and, depending on the image configuration, data-disk definitions and contents.

6.2 Why Do We Need Custom Images?

Consider deploying ten Ubuntu VMs for an application.

Without a custom image, each VM might require manual installation of:

• Nginx

• Application dependencies

• Runtime packages

• Configuration files

• Application files

With a custom image, the configuration is prepared once and reused.

Custom Image Workflow

              Create Ubuntu VM
                     |
                     v
                Install Nginx
                     |
                     v
              Deploy HTML Page
                     |
                     v
              Configure Server
                     |
                     v
               Generalize VM
                     |
                     v
               Deallocate VM
                     |
                     v
              Capture VM Image
                     |
                     v
               Custom Image
                     |
           +---------+---------+
           |         |         |
           v         v         v
          VM 1      VM 2      VM 3

Each VM is created from the same prepared image.

6.3 Generalized vs Specialized Images

A generalized image removes machine-specific identity information and allows Azure to provision a new VM identity.

A specialized image retains the source machine's configuration and identity characteristics.

The following demonstration uses a generalized Linux image.

For production environments, Azure Compute Gallery is generally preferable to standalone managed images when image versioning, sharing, replication, or large-scale deployment is required.

6.4 Practical Demo – Create an Ubuntu VM with Nginx

We will:

1. Create an Ubuntu VM.

2. Install Nginx.

3. Deploy a custom HTML page.

4. Generalize the VM.

5. Capture a custom image.

6. Deploy a new VM from the image.

7. Verify that Nginx is already installed.

Step A – Create the Source VM

Open:

Azure Portal → Virtual machines → Create

Configure:

Select Review + create → Create.

Download the SSH private key when prompted.

Step B – Open HTTP Port 80

After deployment, navigate to the VM's Networking settings.

Add an inbound Network Security Group rule.

This permits inbound HTTP traffic, subject to other applicable network and host firewall rules.

Step C – Connect to the Source VM

ssh -i ~/Downloads/nginx-source-vm-key.pem azureuser@<vm-public-ip>

Step D – Install Nginx

Update package information and install Nginx:

sudo apt update
sudo apt install nginx -y

Verify the service:

sudo systemctl status nginx

Expected status:

Active: active (running)

Step E – Create a Custom HTML Page

Open the default Nginx page:

sudo nano /var/www/html/index.html

Replace its contents with:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport"
          content="width=device-width, initial-scale=1.0">

    <title>Azure Custom Image Demo</title>

    <style>
        body {
            font-family: Arial, sans-serif;
            display: flex;
            justify-content: center;
            align-items: center;
            height: 100vh;
            margin: 0;
            background-color: #0078d4;
            color: white;
            text-align: center;
        }

        .card {
            background: rgba(255,255,255,0.15);
            padding: 40px 60px;
            border-radius: 12px;
        }

        h1 {
            font-size: 2.5em;
            margin-bottom: 10px;
        }

        p {
            font-size: 1.2em;
            opacity: 0.9;
        }
    </style>
</head>

<body>
    <div class="card">
        <h1>Deployed from Custom Image</h1>
        <p>
            This VM was launched from
            an Azure Custom Image.
        </p>
        <p>
            Nginx was pre-installed —
            zero setup required.
        </p>
    </div>
</body>
</html>

Save the file using:

Ctrl + X → Y → Enter

Step F – Verify the Website

Open a browser and navigate to:

http://<vm-public-ip>

The custom HTML page should appear.

The source VM is now ready for image preparation.

6.5 Generalize the Ubuntu VM

Generalization prepares the source VM for cloning.

It removes provisioning-specific information so that new VMs can receive their own identities.

Step 1 – Run the Azure Linux Agent

sudo waagent -deprovision+user -force

This operation is intended to remove provisioning artifacts and user information, including relevant machine-specific configuration.

The precise cleanup depends on the Azure Linux Agent, image, and provisioning configuration. Cloud-init-managed images may require additional cleanup procedures.

Step 2 – Exit SSH

exit

Do not sign back in and modify the source VM after preparing it for image capture.

Important: Generalizing is a destructive lifecycle operation for the source VM. A VM marked generalized in Azure cannot be restarted and used normally as the original standalone VM. Use a dedicated template VM.

6.6 Deallocate the Source VM

In Azure Portal:

Virtual machines → nginx-source-vm → Stop

Wait for the status:

Stopped (deallocated)

The distinction matters because merely shutting down the operating system does not necessarily deallocate Azure compute resources.

6.7 Capture the Custom Image

Open the source VM and select Capture.

The precise capture wizard varies depending on the Azure Portal experience and whether Azure Compute Gallery is selected.

For the managed-image demonstration, use:

Follow the wizard to create the image.

If the Azure Portal uses Azure Compute Gallery as the default image workflow, follow the gallery image-version process instead.

6.8 Deploy a New VM from the Image

Search for Images or navigate to the captured image resource.

Select Create VM.

Create the VM.

After deployment, add an inbound NSG rule for TCP port 80.

Verify the Clone

Open:

http://<clone-vm-public-ip>

Expected page:

Deployed from Custom Image

This VM was launched from an Azure Custom Image.

Nginx was pre-installed — zero setup required.

You can also connect using SSH and run:

sudo systemctl status nginx

Expected:

Active: active (running)

The clone already contains the Nginx installation and website files.

How This Relates to VMSS

VM Scale Sets can deploy instances from a prepared image.

                  Custom VM Image
                         |
                         v
                  VM Scale Set
                         |
             +-----------+-----------+
             |           |           |
             v           v           v
           VM 1        VM 2        VM 3
             |           |           |
             +-----------+-----------+
                         |
                         v
                   Load Balancer

This reduces repeated software installation and helps maintain consistent instance configurations.

New VM startup time still depends on provisioning, operating system startup, application initialization, and health checks.

Key Points

• Custom images enable repeatable VM deployments.

• Images can contain installed applications and configuration.

• Generalization prepares a source VM for new identities.

• waagent -deprovision+user is used in the supplied Linux example.

• Windows generalized-image preparation typically uses Sysprep.

• The source VM should be dedicated to image creation.

• Azure Compute Gallery supports image versioning and broader image distribution.

Part 7 – Azure Backup

7.1 What Is Azure Backup?

Azure Backup is Microsoft's managed backup and recovery service.

It protects supported Azure and on-premises workloads by creating recovery points that can be used to restore data after accidental deletion, corruption, or infrastructure failures.

Azure Backup can protect workloads such as:

• Azure Virtual Machines

• SQL Server running inside Azure VMs

• Azure Files

• Supported Azure Blob workloads

• Supported on-premises servers through backup agents

This article focuses on Azure VM backup.

7.2 Why Do We Need Azure Backup?

Consider a production application running on an Azure VM.

Potential incidents include:

• Accidental file deletion

• Operating system corruption

• Failed application updates

• Malware or ransomware

• VM deletion

• Disk corruption

Without a recoverable backup, restoring the application and its data may be difficult or impossible.

Azure Backup provides scheduled recovery points and managed retention policies.

7.3 Azure Backup Architecture

                 Azure Virtual Machine
                           |
                           v
                    Backup Extension
                           |
                           v
                     Backup Policy
                           |
              +------------+------------+
              |                         |
              v                         v
        Backup Schedule           Retention Rules
              |                         |
              +------------+------------+
                           |
                           v
                    Recovery Points
                           |
                           v
                  Recovery Services
                        Vault
                           |
                           v
                   Restore When Needed

The Recovery Services Vault manages the backup data and recovery points associated with protected workloads.

7.4 What Is a Recovery Services Vault?

A Recovery Services Vault is an Azure resource used to manage backup data, recovery points, policies, and supported recovery operations.

For Azure VM backup, the vault must be created in the same Azure region as the VMs being protected.

Recovery Services Vault Properties

LRS vs GRS

GRS is not the same as automatically being able to restore in another region. Cross-region restore depends on the supported workload and configured features.

Soft Delete

Soft delete retains deleted backup data for a protection period before permanent removal.

The supplied material describes a 14-day soft-delete period. Azure Backup supports configurable retention and additional protection controls, so the actual retention and billing behavior should be checked in the vault settings.

7.5 Practical Demo – Create a Recovery Services Vault

Step 1 – Open Azure Portal

Search for:

Recovery Services vaults

Select + Create.

Step 2 – Enter Vault Details

Select Review + create → Create.

Step 3 – Explore Vault Properties

Open the newly created vault.

Navigate to:

Recovery Services vault → Properties

Review:

• Backup storage redundancy

• Security settings

• Backup configuration

• Soft-delete settings

If the default storage redundancy is GRS and cross-region protection is not required, LRS may reduce storage costs.

Choose the redundancy setting before protecting workloads where possible, because changing redundancy later can be restricted.

Part 8 – Azure Backup Policies and Retention

8.1 What Is a Backup Policy?

A Backup Policy defines when backups occur and how long recovery points are retained.

A policy typically includes:

1. Backup frequency and schedule.

2. Daily retention.

3. Weekly retention.

4. Monthly retention.

5. Optional yearly retention.

6. Instant recovery snapshot retention, where supported.

Backup Policy Workflow

                     Backup Policy
                           |
             +-------------+-------------+
             |                           |
             v                           v
       Backup Schedule             Retention Policy
             |                           |
       Daily 2:00 AM             +--------+--------+
                                 |        |        |
                                 v        v        v
                               Daily    Weekly   Monthly
                               7 Days   4 Weeks  12 Months
                                 |        |        |
                                 +--------+--------+
                                          |
                                          v
                                    Recovery Points
                                          |
                                          v
                                  Recovery Services
                                       Vault

8.2 Understanding Daily Retention

Daily retention defines how many days daily recovery points remain available.

Example:

Backup Schedule: Daily at 2:00 AM
Daily Retention: 7 Days

Day 1  --> Recovery Point
Day 2  --> Recovery Point
Day 3  --> Recovery Point
Day 4  --> Recovery Point
Day 5  --> Recovery Point
Day 6  --> Recovery Point
Day 7  --> Recovery Point

After the configured retention period, a daily recovery point can expire unless another retention rule still requires it.

Use case: Recovering files or application state from recent days.

8.3 Understanding Weekly Retention

Weekly retention preserves selected recovery points for a specified number of weeks.

Example:

Weekly Retention: 4 Weeks

Week 1 Sunday --> Recovery Point
Week 2 Sunday --> Recovery Point
Week 3 Sunday --> Recovery Point
Week 4 Sunday --> Recovery Point

Use case: Recovering from a problem discovered several weeks later.

8.4 Understanding Monthly Retention

Monthly retention preserves selected recovery points for a specified number of months.

Example:

Monthly Retention: 12 Months

January   --> Recovery Point
February  --> Recovery Point
March     --> Recovery Point
April     --> Recovery Point
...
December  --> Recovery Point

Use case: Long-term recovery, auditing, and compliance requirements.

8.5 Detailed Example – Daily, Weekly, and Monthly Retention

Consider this policy:

The supplied material illustrates how recovery points can be preserved across these tiers.

Daily Recovery Points

Daily Retention: 7 Days

May 13 --> Daily Backup
May 14 --> Daily Backup
May 15 --> Daily Backup
May 16 --> Daily Backup
May 17 --> Daily Backup
May 18 --> Daily Backup
May 19 --> Daily Backup

Weekly Recovery Points

Weekly Retention: 4 Weeks

Apr 26 --> Weekly Backup
May 03 --> Weekly Backup
May 10 --> Weekly Backup
May 17 --> Weekly Backup

These dates are the Sundays in the illustrative 2026 period.

Monthly Recovery Points

Monthly Retention: 12 Months

Jun 2025 --> Monthly Recovery Point
Jul 2025 --> Monthly Recovery Point
Aug 2025 --> Monthly Recovery Point
...
Apr 2026 --> Monthly Recovery Point
May 2026 --> Monthly Recovery Point

The exact retained date depends on the selected monthly backup rule, such as the first Sunday of the month.

8.6 Why Do We Need Multiple Retention Tiers?

Keeping every daily backup for an entire year may be unnecessary for many workloads.

Tiered retention provides different levels of recovery history.

The objective is to balance recoverability, operational requirements, and storage cost.

8.7 How Retention Tiers Overlap

An important concept is that a single backup job can produce a recovery point that satisfies multiple retention rules.

For example, consider a backup taken on a Sunday that is also the selected monthly retention day.

                 Sunday Backup Job
                      2:00 AM
                         |
                         v
                  Recovery Point
                         |
             +-----------+-----------+
             |           |           |
             v           v           v
         Daily Rule   Weekly Rule  Monthly Rule
             |           |           |
           7 Days      4 Weeks     12 Months
             |           |           |
             +-----------+-----------+
                         |
                         v
                 Recovery Point Kept
              Until Applicable Rules
                      Expire

This does not mean Azure must create three separate full backups.

The same recovery point may qualify for multiple retention categories.

8.8 What Happens When a Daily Recovery Point Expires?

Suppose a recovery point qualifies for both daily and weekly retention.

                 Recovery Point
                       |
             +---------+---------+
             |                   |
             v                   v
        Daily Retention     Weekly Retention
            7 Days              4 Weeks
             |                   |
             v                   |
        Daily Expires            |
             |                   |
             +---------+---------+
                       |
                       v
               Point Still Kept
               by Weekly Rule
                       |
                       v
               Weekly Rule Expires
                       |
                       v
               Eligible for Removal

The weekly retention requirement prevents the point from being deleted when its shorter daily retention period ends.

8.9 Example – 30 Days, 12 Weeks, and 12 Months

Consider:

The supplied training example estimates:

• 30 daily recovery points.

• 12 weekly recovery points.

• 12 monthly recovery points.

That gives approximately 54 tier assignments before accounting for overlap.

The actual number of distinct recovery points can be lower because some points satisfy more than one tier. It also depends on when protection started, successful backup jobs, and the exact retention configuration.

This is more storage-efficient than retaining every daily point for a full year, although actual Azure Backup storage charges depend on data changes, backup architecture, and storage consumption rather than recovery-point count alone.

8.10 Configuring Backup Retention in Azure Portal

Create or edit a VM backup policy.

Example configuration:

Backup Schedule
    |
    +-- Daily at 2:00 AM UTC
    |
    +-- Instant Recovery Snapshot
    |       |
    |       +-- Retain for 2 Days
    |
    +-- Daily Backup Point
    |       |
    |       +-- Retain for 30 Days
    |
    +-- Weekly Backup Point
    |       |
    |       +-- Every Sunday
    |       +-- Retain for 12 Weeks
    |
    +-- Monthly Backup Point
    |       |
    |       +-- First Sunday
    |       +-- Retain for 12 Months
    |
    +-- Yearly Backup Point
            |
            +-- January, First Sunday
            +-- Retain for 3 Years

Each retention category can be configured according to the supported policy options.

Instant Recovery Snapshot

Azure VM Backup supports instant recovery through locally retained snapshots.

These snapshots enable faster restore operations for supported scenarios because the restore can use the snapshot rather than first retrieving all required backup data from the vault tier.

The source material uses a two-day instant recovery retention example and describes a short retention window.

Instant recovery snapshots are not the same as long-term vault recovery points, and their storage location and retention depend on Azure's backup implementation.

Key Points

• Backup policies control scheduling and retention.

• Daily retention supports recent recovery.

• Weekly retention supports medium-term recovery.

• Monthly and yearly retention support long-term recovery.

• A recovery point may satisfy multiple retention rules.

• Retention should be designed around recovery requirements and cost.

Part 9 – Enable Azure VM Backup

9.1 Practical Demo – Configure VM Backup

Step 1 – Open Recovery Services Vault

Navigate to:

Azure Portal → Recovery Services vaults → my-backup-vault

Select Backup.

Step 2 – Select the Workload

Choose:

Select Backup.

Step 3 – Select a Backup Policy

The supplied material describes an example default policy with:

• Daily backup at 2:30 AM UTC.

• Daily retention of 30 days.

• Weekly retention of 12 weeks.

Default policy settings can vary, so review the policy displayed in your vault rather than assuming those values.

Step 4 – Select the VM

Select Add, choose the VM, and confirm.

Step 5 – Enable Backup

Click Enable Backup.

Azure configures protection for the selected VM and deploys or configures the required backup extension where applicable.

Part 10 – Azure Backup Recovery Points

10.1 What Is a Recovery Point?

A Recovery Point represents a recoverable state of the protected VM at a particular point in time.

Recovery points are created through scheduled or on-demand backup operations.

10.2 Recovery Point Consistency Types

Application-Consistent Backup

On supported Windows workloads, Azure Backup can use VSS mechanisms to coordinate application consistency.

Linux consistency mechanisms depend on supported configurations and pre/post scripts or other workload-aware procedures.

Application-consistent backups are especially valuable for databases and transaction-intensive applications.

Crash-Consistent Backup

A crash-consistent backup captures the disk state without application-aware preparation.

It is conceptually similar to the disk state following an unexpected power interruption.

Applications may need to perform recovery operations after restoration.

Key Point: For databases, use an appropriate application-consistent or database-aware backup strategy rather than relying only on crash-consistent VM backups.

10.3 Practical Demo – Trigger an On-Demand Backup

Step 1 – Open Backup Items

Navigate to:

Recovery Services vault → Backup items → Azure Virtual Machine

Select the protected VM.

Step 2 – Start Backup

Select Backup now.

Choose the retention date for the on-demand recovery point.

For example, select a date one week in the future, subject to the policy's supported retention limits.

Click OK.

Step 3 – Monitor the Backup Job

Navigate to:

Recovery Services vault → Backup jobs

Select the backup job.

You can review its progress and completion status.

An initial small-VM backup may take tens of minutes, but duration varies with disk size, changed data, extension status, and service conditions.

Step 4 – Verify Recovery Points

Return to:

Backup items → Azure Virtual Machine → Select VM

Review the recovery points and their details.

The recovery-point list allows you to identify which points are available for restoration.

Part 11 – Azure VM Restore Options

Azure Backup provides several recovery workflows.

The supplied material groups them into four practical restore options.

11.1 Restore Option Architecture

                  Azure Backup
                 Recovery Point
                       |
                       v
                Select Restore
                       |
         +-------------+-------------+
         |             |             |
         v             v             v
    Replace VM      Create VM     Restore Disks
         |             |             |
         v             v             v
    Restore Over    New VM with   New Managed
    Existing VM     Backup Data   Disks
                       |
                       |
              Separate File Recovery
                       |
                       v
                Recover Files

11.2 Option 1 – Replace Existing VM

This restores a protected VM using an earlier recovery point.

Use case: A VM becomes corrupted after an operating system update.

The restore workflow replaces the relevant VM disks with recovered disk state, subject to supported restore conditions.

Because this affects the existing VM, carefully review the selected recovery point before proceeding.

11.3 Option 2 – Create a New VM

This restores the backup as a separate VM.

Use case: You want to verify a recovery point without modifying the original VM.

Example:

                Recovery Point
                      |
                      v
                 Restore VM
                      |
              +-------+-------+
              |               |
              v               v
         Original VM       Restored VM
          Unchanged          New Copy

This is useful for testing recovery procedures.

11.4 Option 3 – Restore Disks Only

This restores managed disks from the selected recovery point.

You can inspect the restored disks and attach them to an appropriate VM.

Use case: You want to recover disk contents or rebuild a VM manually.

11.5 Option 4 – File-Level Recovery

File-level recovery allows supported files to be recovered without restoring an entire VM.

Azure provides a recovery workflow that can expose backup contents through a mounted recovery volume or script-driven access.

Use case: A user accidentally deletes an important configuration file.

You can recover the required file rather than restoring the entire VM.

Restore Options Comparison

11.6 Practical Demo – Explore Restore Options

Step 1 – Open the Restore Wizard

Navigate to:

Recovery Services vault → Backup items → Select VM → Restore VM

Select a recovery point.

Review the available restore options. Their labels and availability depend on the VM configuration and Azure Portal workflow.

Step 2 – Explore File Recovery

Return to the protected VM's backup page.

Select File Recovery.

Review the recovery-point selection and downloadable recovery script options.

For this demonstration, you do not need to complete an actual restore.

Select Cancel when finished.

Key Points

• Replacing an existing VM is appropriate for supported in-place recovery scenarios.

• Creating a new VM preserves the original.

• Restoring disks provides more manual control.

• File recovery is useful for individual files.

• Restore procedures should be tested periodically, not only after a failure.

Part 12 – Cost Management and Resource Cleanup

Azure resources can continue generating charges after a demonstration is completed.

Potential charges include:

• VM compute

• Managed disks

• Public IP addresses

• Snapshots

• Custom image storage

• Backup protected-instance charges

• Backup storage consumption

12.1 Stop VM Backup

Open:

Recovery Services vault → Backup items → Select VM

Select Stop backup.

Azure may offer options to retain or delete backup data.

For a disposable demonstration, select the appropriate delete-backup-data workflow if the recovery points are no longer needed.

Be aware that soft-delete retention, immutable vault settings, and other protection controls can affect when backup data is permanently deleted.

12.2 Delete the Resource Group

Navigate to:

Azure Portal → Resource groups → vm-mgmt-rg

Select Delete resource group.

Confirm the resource group name.

This deletes resources within the resource group, subject to resource locks and deletion dependencies.

Before deletion, verify that the group contains no resources you still need.

12.3 Delete the Recovery Services Vault

A Recovery Services Vault may not be deletable while it contains protected items, retained backup data, or other dependencies.

Complete the supported backup cleanup process first.

If the vault is in the same resource group, it is included in the resource-group deletion attempt. If deletion is blocked, resolve the vault dependencies and retry.

Important: Deallocating a VM stops compute billing for that VM, but associated storage and other resources may continue to incur charges.

Part 13 – Complete Azure VM Management Architecture

The following diagram combines the major concepts discussed in this article.

                         Internet
                            |
                            v
                   Azure Load Balancer
                            |
                            v
                   VM Scale Set (VMSS)
                            |
              +-------------+-------------+
              |             |             |
              v             v             v
           Zone 1        Zone 2        Zone 3
              |             |             |
              v             v             v
             VM 1          VM 2          VM 3
              |             |             |
              +-------------+-------------+
                            |
                +-----------+-----------+
                |                       |
                v                       v
           Managed Disks          Custom VM Image
                |                       |
          +-----+-----+                 |
          |           |                 v
          v           v             New VM Instances
       OS Disk     Data Disk
          |           |
          +-----+-----+
                |
                v
          Azure VM Backup
                |
                v
        Recovery Services Vault
                |
         +------+------+------+
         |      |      |      |
         v      v      v      v
       Daily  Weekly Monthly Yearly
         |      |      |      |
         +------+------+------+
                |
                v
           Recovery Points
                |
                v
         Restore VM / Disks
           or Files

This is a conceptual architecture. In a real deployment, you would also design the database layer, networking, identity, monitoring, application health checks, and disaster recovery requirements.

Part 14 – Important Interview Questions and Answers

The following questions are based on the topics covered in this article.

Group 1 – Availability Sets and Availability Zones

Q1. What is an Azure Availability Set?

An Availability Set is a logical grouping of VMs distributed across Fault Domains and Update Domains to reduce downtime caused by hardware failures and planned maintenance.

Q2. What is a Fault Domain?

A Fault Domain represents infrastructure that can be affected by a common physical failure, such as shared power or networking equipment.

Q3. What is an Update Domain?

An Update Domain is a logical group of VMs that Azure may restart together during planned platform maintenance.

Q4. What is the difference between Fault Domain and Update Domain?

Fault Domains protect against unplanned hardware failures. Update Domains reduce simultaneous interruptions during planned maintenance.

Q5. What is an Azure Availability Zone?

An Availability Zone is a physically separate datacenter group within an Azure region, with independent power, cooling, and networking infrastructure.

Q6. What is the difference between Availability Sets and Availability Zones?

Availability Sets protect against localized hardware and maintenance failures. Availability Zones provide isolation from larger datacenter or zone failures.

Q7. What are the VM SLAs for Availability Sets and Availability Zones?

Qualifying multi-VM Availability Set deployments commonly have a 99.95% SLA. Qualifying deployments across Availability Zones commonly have a 99.99% SLA.

Q8. Can we add an existing VM to an Availability Set?

No. Availability Set placement must be configured during VM creation. Existing VMs generally need to be recreated to change this placement.

Q9. Which should be used for a production application?

Availability Zones are generally preferred when zone-level resilience is required and supported. The application must also be designed for failover.

Group 2 – Virtual Machine Scale Sets

Q10. What is Azure VMSS?

Azure Virtual Machine Scale Sets allow multiple VM instances to be deployed, managed, and scaled using shared configurations and scaling policies.

Q11. What is the difference between scale-out and scale-in?

Scale-out adds VM instances when demand increases. Scale-in removes unnecessary instances when demand decreases.

Q12. How does VMSS autoscaling work?

Autoscale evaluates configured metrics, such as average CPU utilization, and adds or removes VM instances when defined conditions are met.

Q13. What is the difference between Flexible and Uniform orchestration?

Flexible orchestration provides greater control over individual VMs. Uniform orchestration emphasizes consistently configured instances managed as a scale set.

Q14. Why is a Load Balancer used with VMSS?

A Load Balancer distributes incoming traffic among healthy VM instances. VMSS manages instance capacity, while the Load Balancer manages traffic distribution.

Q15. Can VMSS work without a Load Balancer?

Yes. Background processing workloads may not require inbound load balancing. Web applications typically use a load-balancing or routing service.

Group 3 – Azure Disk Management

Q16. What is an Azure Managed Disk?

A Managed Disk is Azure-managed block storage used by virtual machines for operating system and application data.

Q17. What are the main Azure disk types?

Standard HDD, Standard SSD, Premium SSD, and Ultra Disk are the four disk categories covered in this article.

Q18. What is the difference between an OS disk and a data disk?

The OS disk contains the operating system. A data disk stores application files, logs, databases, or other persistent data.

Q19. What is a temporary disk?

A temporary disk provides nonpersistent local storage for supported VM sizes. Its contents can be lost during VM lifecycle events.

Q20. What are IOPS and throughput?

IOPS measures disk read/write operations per second. Throughput measures the amount of data transferred per second.

Q21. How do you initialize a data disk in Windows?

Open Disk Management, initialize the disk using GPT, create a new simple volume, assign a drive letter, and format it using NTFS.

Q22. How do you initialize a data disk in Linux?

Identify the disk with lsblk, partition it using fdisk, format it using mkfs.ext4, mount it, and configure /etc/fstab for persistence.

Q23. What is the purpose of /etc/fstab?

/etc/fstab defines filesystem mount configurations so that supported filesystems can be mounted automatically during system startup.

Q24. Why is UUID recommended in /etc/fstab?

UUID identifies a filesystem independently of device names, which can change after VM restarts or storage configuration changes.

Group 4 – VM Snapshots and Custom Images

Q25. What is an Azure VM Snapshot?

An Azure Snapshot is a read-only, point-in-time copy of a managed disk that can be used to create a new disk.

Q26. What is the difference between a snapshot and Azure Backup?

A snapshot provides a disk-level point-in-time copy. Azure Backup provides managed backup