Deploy and Manage a VM with Azure CLI

Deploy and manage Linux VMs on Azure using both the portal and CLI.

Introduction

30 Second Summary

Every time you stream a video, send a message, or check your bank balance, a virtual machine is doing the heavy lifting somewhere in the cloud. Managing these machines is the single most common task of a cloud administrator.

In this project, you will deploy and manage Linux virtual machines in Azure using both a graphical portal and the command line. You will create VMs, control their power states, resize them, and attach storage disks.

What You'll Build

A fully operational Linux virtual machine environment in Azure, created and managed using both the Azure Portal and Azure CLI.

By the end of this project, you'll have:

A Linux VM created via the Azure Portal with SSH access.
A second VM created entirely via Azure CLI, with all supporting resources auto-provisioned.
A managed data disk attached, partitioned, formatted, and mounted on your CLI-created VM.
Secret Mission: A Virtual Machine Scale Set configured for manual horizontal scaling.

Do I need any prerequisites?

You need a KodeKloud PRO subscription to access the Azure Playground sandbox used in this project. No prior CLI experience is required.

Launch the Sandbox and Learn Azure CLI Basics

Azure administrators manage virtual machines every day. The Azure CLI gives you a fast, scriptable way to deploy and control VMs without clicking through the portal for every task.

In this step, you'll launch the KodeKloud Azure sandbox, open Cloud Shell, and run your first CLI commands to identify your subscription and resource group.

In this step, get ready to:

Launch the KodeKloud Azure Playground and sign into the Azure Portal.
Open Cloud Shell and identify your subscription and resource group.
Learn the Azure CLI command pattern and explore available VM images.

Launch the KodeKloud Azure Playground

The KodeKloud Azure Playground gives you a sandboxed Azure environment for 3 hours. All resources are automatically deleted when your session ends, so there is no risk of surprise charges.

Log into your KodeKloud account and navigate to the Azure Playground under Playgrounds.
Click Start Lab to launch a new sandbox session.
On the launch page, locate the IAM user name (an email address) and password displayed on screen. These are your Azure login credentials for this session.
Click the Azure Portal link on the launch page.
Sign in using the IAM user name and password from the launch page.

Do not use your KodeKloud password

The Azure Portal login requires the IAM credentials shown on the playground launch page. Your KodeKloud account password will not work here. If you see a login error, double-check that you are using the playground-provided email and password.

Once signed in, type Resource groups in the portal search bar at the top and select Resource groups from the results.
Note the name of the pre-created resource group. You will use this name in every CLI command throughout the project.

Why can't I create my own resource group?

The KodeKloud sandbox restricts resource group creation to control costs. A resource group has already been created for you. All the resources you build in this project will go inside that existing group.

Can't sign into the Azure Portal?

Make sure you are using the IAM credentials from the playground launch page, not your personal KodeKloud login. If the login still fails, try opening the portal link in an incognito or private browser window to avoid cached credentials from another account.

Help me troubleshoot my KodeKloud Azure Playground login.

Open Cloud Shell and run your first commands

Cloud Shell is a browser-based terminal built into the Azure Portal. It comes pre-installed with the Azure CLI, so you do not need to install anything on your local machine.

Click the Cloud Shell icon (>_) in the top navigation bar of the Azure Portal.
When prompted to choose a shell, select Bash.
If prompted about storage, select No storage account required for an ephemeral session, choose your subscription from the dropdown, then click Apply.

A terminal panel opens at the bottom of your browser. You are now ready to run Azure CLI commands.

View your subscription details by running this command:

az account show

You should see JSON output containing your subscription name, subscription ID, and tenant ID.

List available resource groups by running:

az group list --output table

You should see a table with one row showing your pre-created resource group name and its location.

What is the --output table flag?

By default, Azure CLI returns results as JSON. Adding --output table formats the output as a human-readable table. You can also use --output tsv for tab-separated values useful in scripts.

See the available VM sizes in the East US region by running:

az vm list-sizes --location eastus --output table

You should see a large table listing VM sizes with columns for name, number of cores, memory in MB, and disk size.

The sandbox limits your size options

Even though the table shows many sizes, the KodeKloud sandbox restricts you to: Standard_B1s, Standard_B2s, Standard_DS1_v2s, and Standard_D2s_v3. You will use Standard_B1s (1 vCPU, 1 GB RAM) for your first VM.

Cloud Shell not opening?

Make sure you are clicking the >_ icon in the top navigation bar, not searching for Cloud Shell in the services menu. If it still does not appear, try refreshing the portal page or opening it in a private browser window.

Help me get Cloud Shell working in the Azure Portal.

Practice core CLI patterns

Every Azure CLI command follows the same pattern: az <service> <action> --parameter value. Once you learn this structure, you can manage any Azure resource from the command line.

Explore the VM subcommands by running:

az vm --help

You should see a list of available subcommands like create, delete, start, stop, and deallocate. These are the lifecycle commands you will use throughout this project.

What is the CLI pattern?

The Azure CLI always starts with az, followed by the service name (like vm, group, or disk), then an action (like create, list, or show), and finally parameters prefixed with --.

You can always append --help to any command to see its available options. This works at every level: az --help, az vm --help, or az vm create --help.

View the popular VM images available by running:

az vm image list --output table

You should see a table of commonly used images including Ubuntu, Debian, CentOS, and Windows Server. Look for the Ubuntu2204 entry. This is the image alias you will use to create your VMs.

What is a VM image?

A Virtual Machine image is a pre-built template containing an operating system and initial configuration. Instead of installing an OS from scratch, you pick an image and Azure launches a VM with that OS ready to go.

The UrnAlias column shows shorthand names like Ubuntu2204 that you can use directly in CLI commands instead of typing the full image URN.

Your sandbox is ready and you know how to navigate the CLI. Next up, you'll create your first virtual machine through the Azure Portal.

Create a VM via the Azure Portal

Azure Virtual Machines are the core compute resource for running workloads in the cloud. Creating a VM through the portal helps you understand every component that goes into a running machine.

In this step, you will create a Linux VM from scratch using the Azure Portal. You will configure its size, networking, and authentication settings, then verify it works by connecting over SSH.

In this step, get ready to:

Configure a Linux VM with networking and authentication settings in the Azure Portal.
Deploy the VM and observe the supporting resources Azure creates automatically.
Verify the VM works by connecting via SSH from Cloud Shell.

Configure the VM in the Azure Portal

In the search box at the top of the Azure Portal, type Virtual machines.
Select Virtual machines from the search results.
Click + Create, then select Azure virtual machine.

The Create a virtual machine page opens on the Basics tab. Fill in each section as follows.

Under Project details, select your pre-created resource group from the Resource group dropdown.
Under Instance details, enter portal-vm in the Virtual machine name field.
Set Region to (US) East US.
Set Image to Ubuntu Server 22.04 LTS - x64 Gen2.
Set Size to Standard_B1s (1 vCPU, 1 GB RAM).
Under Administrator account, change Authentication type to Password.
Enter azureuser in the Username field.
Create a strong password and enter it in both the Password and Confirm password fields. Remember this password for SSH later.
Under Inbound port rules, set Public inbound ports to Allow selected ports.
In the Select inbound ports dropdown, choose SSH (22).
Leave all other settings as their defaults.

What is a VM image?

A VM image is a pre-built template containing an operating system (and sometimes additional software). By selecting Ubuntu Server 22.04 LTS, you are telling Azure to install a fresh Ubuntu Linux OS on your virtual machine.

Why Standard_B1s?

The Standard_B1s size gives you 1 vCPU and 1 GB of RAM. It is the smallest (and cheapest) burstable size available in the KodeKloud sandbox. It is perfect for learning without wasting resources.

Review and deploy the VM

Click the Review + create tab at the top of the page.
Azure validates your configuration. Review the summary and notice the resources that will be created automatically: a VNet (virtual network), a public IP address, a Network Security Group (NSG), and an OS disk.
Click Create.
Wait for the deployment to complete. This takes 1-2 minutes.
Once the deployment succeeds, click Go to resource.

The VM overview page shows key details about your machine. Note the Public IP address, Status (Running), and Size displayed on this page.

What are all these extra resources?

When you create a VM, Azure automatically provisions supporting infrastructure so the machine can communicate with the internet and stay secure.

The VNet is a private network your VM lives in.
The Public IP gives your VM a routable internet address.
The NSG acts as a firewall, controlling which traffic reaches the VM.
The OS disk is a managed disk holding the Ubuntu operating system.

Seeing a validation error?

Make sure you selected the pre-created resource group (not Create new). The KodeKloud sandbox does not allow creating resource groups.

If the Standard_B1s size is not visible, confirm your region is set to East US. The sandbox only supports certain regions.

Help me fix a validation error when creating my VM

Verify the VM by connecting via SSH

Your VM is running, but you need to confirm you can actually log in. You will connect from Cloud Shell using SSH and the public IP address shown on the VM overview page.

Switch back to your Cloud Shell session (click the terminal icon in the top navigation bar if it has closed).
Connect to your VM by running this command:

ssh azureuser@[[PUBLIC_IP="your VM's public IP address from the overview page"]]

When asked "Are you sure you want to continue connecting?", type yes and press Enter.
Enter the password you created earlier when prompted.

What is the fingerprint prompt?

The first time you connect to any server over SSH, your client asks you to verify the server's identity. Typing yes saves the server fingerprint so you are not asked again on the next connection.

You are now inside your VM. Confirm it by running these commands:

hostname
lsblk

What do these commands show?

hostname prints the VM's name. You should see portal-vm.
lsblk lists all attached block devices (disks). Right now you only see the OS disk (typically sda or sdb).

Type exit and press Enter to disconnect from the VM and return to Cloud Shell.

Connection refused or timed out?

Double-check the public IP address on the VM overview page. Make sure you copied it exactly with no extra spaces.

If the connection hangs, confirm the VM status is Running (not Starting or Stopped). Wait a minute after deployment before retrying.

If you see "Permission denied", verify you are entering the password you set during VM creation (not your KodeKloud password).

Help me troubleshoot my SSH connection to portal-vm

Your first VM is live and accessible over SSH. Next up, you will learn to control this VM's lifecycle entirely from the command line, including stopping, deallocating, and resizing it.

Manage VM Lifecycle with Azure CLI

Your VM is up and running. In a real environment, VMs don't just run forever. You need to stop them for maintenance, resize them when workloads grow, and deallocate them to save costs.

Azure gives you fine-grained control over a VM's power state through the CLI. In this step, you'll use Azure CLI commands to stop, deallocate, resize, and restart your VM.

In this step, get ready to:

Stop and deallocate the VM using Azure CLI.
Resize the VM to a larger size while deallocated.
Understand the cost difference between stopped and deallocated states.

Inspect and stop the VM

Before changing any power state, it helps to confirm what you're working with. You'll inspect the VM's current details, then walk through the two distinct ways to stop it.

In Cloud Shell, inspect your VM by running this command:

az vm show -g [[RESOURCE_GROUP="your resource group name"]] -n portal-vm --output table

You should see a table with the VM's name, location, resource group, and current power state.

Stop the VM's operating system by running:

az vm stop -g [[RESOURCE_GROUP="your resource group name"]] -n portal-vm

This command shuts down the OS inside the VM. The command may take 30-60 seconds to complete.

Switch to the Azure Portal and navigate to your portal-vm overview page. The status now shows Stopped.

Why is the VM still costing money?

When a VM shows Stopped, Azure has shut down the operating system but the underlying hardware is still reserved for you. You continue to pay compute charges because no other customer can use that hardware.

To actually stop paying, you need to deallocate. This releases the hardware back to Azure's pool.

Deallocate the VM to release its compute resources by running:

az vm deallocate -g [[RESOURCE_GROUP="your resource group name"]] -n portal-vm

This command may take a minute to complete. Once it finishes, return to the portal and refresh the VM overview page.

Confirm the status now shows Stopped (deallocated). Compute charges have stopped. Only storage charges for the OS disk continue.

Command returning an error?

Double-check that the resource group name matches exactly what you saw in az group list --output table earlier. The name is case-sensitive.

If you see a message about the VM not being found, confirm you typed portal-vm (with a hyphen, not an underscore).

Help me troubleshoot my az vm deallocate command

Resize and restart the VM

With the VM deallocated, you can change its hardware size. This is how administrators upgrade VMs to handle heavier workloads without rebuilding from scratch.

Resize the VM from Standard_B1s to Standard_B2s by running:

az vm resize -g [[RESOURCE_GROUP="your resource group name"]] -n portal-vm --size Standard_B2s

What does Standard_B2s give you?

Standard_B2s provides 2 vCPUs and 4 GB of RAM. That is double the compute power of Standard_B1s (1 vCPU, 1 GB RAM). The B-series is Azure's burstable tier, ideal for workloads that don't need constant full CPU.

Start the VM again by running:

az vm start -g [[RESOURCE_GROUP="your resource group name"]] -n portal-vm

This command boots the VM on its new hardware. It may take a minute to complete.

Verify the new size by running:

az vm show -g [[RESOURCE_GROUP="your resource group name"]] -n portal-vm --query hardwareProfile.vmSize

You should see "Standard_B2s" in the output. You can also confirm in the portal by refreshing the VM overview page. The Size field now shows Standard_B2s and the status shows Running.

Resize command failing?

The VM must be in a deallocated state before you can resize it. If you skipped the az vm deallocate command, go back and run it first.

Also confirm you're using Standard_B2s (capital S at the end). The size name is case-sensitive.

Help me fix my az vm resize command

Understand the cost implications

The difference between Stopped and Stopped (deallocated) is one of the most commonly tested topics on the AZ-104 exam. Here is the breakdown.

Stopped vs Stopped (deallocated)

Stopped (via az vm stop): The OS shuts down, but the hardware stays reserved. You still pay compute charges. Use this when you need the VM back quickly on the same hardware.
Stopped (deallocated) (via az vm deallocate): The hardware is released back to Azure. Compute charges stop. Storage charges for the OS disk still apply. The VM may get different hardware when restarted.
Resizing requires deallocation first. You cannot resize a VM that is merely stopped.

AZ-104 exam relevance

The Deploy and manage Azure compute resources domain covers 20-25% of the AZ-104 exam. Questions about VM power states, resizing requirements, and cost implications appear frequently. Remember: deallocate to stop charges, deallocate before resize.

You now know how to manage a VM's entire lifecycle from the command line. Next up, you'll create a brand new VM entirely through Azure CLI, skipping the portal altogether.

Deploy a VM Using Azure CLI

In the previous step, you managed your portal VM's lifecycle entirely from Cloud Shell. You stopped, deallocated, resized, and restarted it without touching the portal UI.

Now you'll take Azure CLI even further by creating an entire VM from scratch using a single command. This is where the CLI becomes a real productivity tool for administrators.

In this step, get ready to:

Create a Linux VM entirely from Azure CLI.
Verify both VMs exist side by side.
SSH into the new VM and inspect its disk layout.

Create a VM with a single CLI command

When you created your first VM through the portal, you clicked through multiple screens to configure the image, size, networking, and authentication. The CLI lets you do all of that in one command.

In Cloud Shell, create a new VM by running this command:

az vm create \
  --resource-group [[RESOURCE_GROUP="your pre-created resource group name"]] \
  --name cli-vm \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --output json

What does this command do?

--resource-group places the VM in the same resource group you've been using throughout this project.
--name cli-vm gives the VM an identifiable name so you can distinguish it from your portal-created VM.
--image Ubuntu2204 selects Ubuntu Server 22.04 LTS, the same image you chose in the portal.
--size Standard_B1s picks the smallest available size (1 vCPU, 1 GB RAM).
--generate-ssh-keys creates an SSH key pair automatically instead of using password authentication.
--output json formats the result as JSON so you can clearly see the public IP address in the output.

This command takes about 1-2 minutes to complete. The CLI automatically creates all the supporting resources your VM needs.

What resources does Azure auto-create?

Just like the portal did, the CLI provisions a VNet (virtual network), a public IP address, a NSG (network security group), a NIC (network interface card), and an OS disk. You didn't specify any of these, but Azure created them with sensible defaults.

Once the command finishes, look at the JSON output. Find the publicIpAddress field and note this value down. You'll need it to SSH into the VM.

Seeing a permission or quota error?

Make sure you replaced the resource group placeholder with your actual pre-created resource group name. The KodeKloud sandbox does not allow creating new resource groups.
If you see a size-related error, confirm you used Standard_B1s exactly. The sandbox only allows specific VM sizes.
If your session expired (3-hour limit), start a new KodeKloud sandbox session and re-run the command.

help me troubleshoot my az vm create error in the KodeKloud Azure sandbox

Verify both VMs and connect via SSH

You now have two VMs in your resource group. One created through the portal, one through the CLI. Let's confirm they both exist and verify you can connect to the new one.

List all VMs in your resource group by running:

az vm list -g [[RESOURCE_GROUP="your pre-created resource group name"]] --output table

You should see both portal-vm and cli-vm listed in the table output.

SSH into the new CLI-created VM by running:

ssh azureuser@[[CLI_VM_IP="public IP from the JSON output"]]

Type yes when asked to accept the fingerprint. Since you used --generate-ssh-keys, no password is needed.
Once connected, check the disk layout by running:

lsblk

You should see only the OS disk (sda or sdb) and a temporary disk. No data disk is attached yet.

Disconnect from the VM by typing:

exit

SSH connection refused or timed out?

Double-check that you copied the correct IP address from the publicIpAddress field in the JSON output of your create command.
The VM may still be booting. Wait 30 seconds and try the SSH command again.
If you get a key mismatch error, the SSH keys may have been regenerated in a new session. Delete the offending key from ~/.ssh/known_hosts and retry.

help me fix my SSH connection to cli-vm in the KodeKloud sandbox

Compare portal and CLI workflows

When should I use the portal vs the CLI?

The portal is great for learning and one-off tasks. You can see every option visually, which helps when you're exploring a new service.

The CLI is faster for repeated tasks. It's scriptable and used in automation pipelines. When you need to create 10 identical VMs, a script beats clicking through 10 wizard flows.

Real Azure administrators use both daily. However, CLI skills are essential for the AZ-104 exam and for any production automation work.

Your two-VM environment is ready. Next up, you'll attach a data disk to your CLI VM and learn how to partition, format, and mount it from inside the machine.

Attach and Configure a Data Disk

You've deployed VMs using both the portal and CLI, and you know how to manage their lifecycle. But a VM with only an OS disk has no place to put application data, databases, or logs.

In this step, you'll attach a managed data disk to your CLI VM and initialize it from inside the VM. This is the same process an Azure administrator follows to add storage to any production workload.

In this step, get ready to:

Attach a 50 GB managed data disk to cli-vm using Azure CLI.
Partition, format, and mount the disk inside the VM.
Write a test file to confirm the disk works.

Attach a managed data disk to the CLI VM

Azure VMs come with an OS disk by default, but application data should live on a separate data disk. Separating data from the OS protects your files if you ever need to replace or resize the VM.

Attach a new 50 GB data disk to cli-vm by running this command in Cloud Shell:

az vm disk attach \
  -g [[RESOURCE_GROUP="your pre-created resource group name"]] \
  --vm-name cli-vm \
  --name myDataDisk \
  --size-gb 50 \
  --sku Standard_LRS \
  --new

What does this command do?

-g specifies the resource group where cli-vm lives.
--name myDataDisk names the new managed disk resource.
--size-gb 50 creates a 50 GB disk.
--sku Standard_LRS uses standard locally-redundant storage (standard HDD). The KodeKloud sandbox only supports Standard SSD and HDD.
--new tells Azure to create a brand new empty disk rather than attaching an existing one.

Verify the disk is attached by running:

az vm show -g [[RESOURCE_GROUP="your pre-created resource group name"]] -n cli-vm --query storageProfile.dataDisks

You should see JSON output listing one data disk named myDataDisk with a size of 50 GB.

Not seeing the disk in the output?

Double-check that you replaced the resource group placeholder with your actual pre-created resource group name.
Make sure the VM name is exactly cli-vm (case-sensitive).

Help me troubleshoot the az vm disk attach command.

SSH into the VM and initialize the disk

A newly attached disk is blank. Before you can store files on it, you need to partition it, format it with a filesystem, and mount it to a directory.

Connect to cli-vm over SSH by running:

ssh azureuser@[[CLI_VM_IP="your cli-vm public IP address"]]

Run lsblk to list all disks and find the new one:

lsblk

You should see sdc listed as a 50 GB disk with no mount point. The OS disk is sda and the temporary disk is sdb.

Partition the disk by running:

sudo fdisk /dev/sdc

How do I respond to the fdisk prompts?

The fdisk tool is interactive. Follow these prompts in order:

Type n and press Enter to create a new partition.
Press Enter to accept the default partition type (primary).
Press Enter to accept the default partition number (1).
Press Enter to accept the default first sector.
Press Enter to accept the default last sector (uses the full disk).
Type w and press Enter to write the partition table and exit.

Format the new partition with the ext4 filesystem by running:

sudo mkfs.ext4 /dev/sdc1

Create the mount point directory by running:

sudo mkdir /datadrive

Mount the partition to /datadrive by running:

sudo mount /dev/sdc1 /datadrive

Verify the disk is mounted by running:

df -h /datadrive

You should see /dev/sdc1 mounted on /datadrive with approximately 50 GB of available space.

What is ext4?

ext4 is the default Linux filesystem for general-purpose storage. It supports files up to 16 TB and volumes up to 1 EB, making it a solid choice for most workloads. Azure administrators also use XFS for high-throughput scenarios, but ext4 is the most common starting point.

Not seeing /dev/sdc in lsblk?

Make sure the az vm disk attach command completed successfully before you SSH into the VM.
If you see a different disk letter (like sdd), look for the 50 GB unformatted disk in the lsblk output and use that device name instead.

Help me find my data disk in the lsblk output.

Test the disk by writing data

The disk is mounted and ready. Let's write a file to confirm everything works end to end.

Write a test file to the data disk by running:

sudo sh -c 'echo "Hello from my data disk" > /datadrive/test.txt'

Read the file back to confirm it was written successfully:

cat /datadrive/test.txt

You should see Hello from my data disk printed in the terminal.

Run lsblk one final time to see the complete disk layout:

lsblk

You should now see sdc1 listed under sdc with the mount point /datadrive. This confirms your OS disk, temporary disk, and data disk are all visible.

Type exit to disconnect from the SSH session.

exit

Why separate data disks from the OS disk?

If you ever need to delete or recreate the VM, data on a managed data disk survives. You can detach the disk and reattach it to a new VM. The OS disk, on the other hand, is typically destroyed when you delete a VM.

This separation is a core IaaS pattern and a topic tested on the AZ-104 exam.

Permission denied when writing to /datadrive?

Make sure you're using sudo before the write command. The mount point is owned by root by default.
If you see "No such file or directory", confirm the mount succeeded by running df -h /datadrive first.

Help me write to my mounted data disk.

Secret mission

Create a Virtual Machine Scale Set

You've managed individual VMs. But what happens when your app needs to handle variable traffic? Create a Virtual Machine Scale Set that manages multiple identical VMs as a group, the same way production workloads handle horizontal scaling.

Clean Up Your Resources

This project runs entirely within the KodeKloud sandbox, so there are no ongoing costs. All resources are automatically deleted when your 3-hour session ends.

Resources you used:

portal-vm (VM, VNet, public IP, NSG, NIC, OS disk).
cli-vm (VM, VNet, public IP, NSG, NIC, OS disk).
myDataDisk (50 GB managed data disk attached to cli-vm).
app-scaleset (Virtual Machine Scale Set with up to 3 instances, if Secret Mission completed).

Keep everything running

No action needed. Choose this if you are still exploring Azure or want to continue practicing CLI commands within your sandbox session.

Your sandbox session remains active for up to 3 hours from when you launched it.
All resources will be automatically deleted when the session ends.
You can start a new sandbox session immediately after the current one expires.

Pause - I'll come back to this later

The KodeKloud sandbox does not support pausing. When your 3-hour session ends, all resources are deleted automatically.

If you want to free up compute resources within your session, deallocate both VMs by running these commands in Cloud Shell:

az vm deallocate -g <resource-group> -n portal-vm
az vm deallocate -g <resource-group> -n cli-vm

Replace <resource-group> with your pre-created resource group name.
Deallocated VMs release compute resources but retain their disks and configuration.
To resume later, launch a new sandbox session and recreate the resources from scratch using the CLI commands from this project.

Delete - I don't want to use this again

All resources are automatically deleted when your sandbox session ends. No manual cleanup is required.

If you want to delete resources early within your session, follow these steps in the Azure Portal:

Navigate to Virtual machines in the portal search bar.
Select portal-vm.
Click Delete in the top toolbar.
Check the boxes to also delete the associated NIC, public IP, and OS disk.
Click Delete to confirm.
Repeat for cli-vm.

For the data disk and scale set:

Navigate to Disks in the portal. Select myDataDisk, click Delete, and confirm.
Navigate to Virtual machine scale sets. Select app-scaleset, click Delete, and confirm.

Why bother deleting early?

Since the sandbox auto-cleans, early deletion is purely optional. Some learners prefer to practice teardown workflows as part of their administrator training.

Nice Work!

You just deployed, managed, and scaled Linux virtual machines in Azure using both the portal and the command line. These are the core compute skills that make up 20-25% of the AZ-104 exam.

You've learned how to:

Deploy Linux VMs through both the Azure Portal and Azure CLI, understanding how each method auto-provisions supporting resources like VNets, public IPs, and NSGs.
Manage VM lifecycle (stop, deallocate, resize, start) using CLI commands, including the critical cost difference between stopped and deallocated states.
Attach, partition, format, and mount a managed data disk on a running VM using Azure CLI and Linux disk utilities.
Secret Mission: Created and scaled a Virtual Machine Scale Set for horizontal scaling across multiple VM instances.

Ready to quiz yourself?