Java / Azure Virtual Machines (VMs) Interview questions

An Azure Virtual Machine is an on-demand IaaS compute resource that runs a full Windows or Linux operating system on Microsoft's Hyper-V based infrastructure. You pick the image, size, disks and network settings, and Azure takes care of the physical hardware, the hypervisor and the datacenter.

Because you own everything from the guest OS upward (patching, runtimes, security settings, applications), a VM gives the most control among Azure compute options. The flip side is more operational work than PaaS services such as App Service.

Typical uses are lift-and-shift of existing servers, software with OS-level dependencies, dev/test environments, self-managed databases and high-performance workloads.

An Azure VM is not one object but a set of linked resources: the VM itself (size, image, OS profile), at least one OS disk, optional data disks, a network interface placed in a subnet, and usually a network security group.

All of these live in a resource group, and deleting the VM does not automatically delete its disks, NIC or IP unless you set the delete option.

Azure groups VM sizes into families by workload profile: general purpose, compute optimized, memory optimized, storage optimized, GPU and HPC.

Names follow a pattern. In Standard_D4s_v5, D is the family, 4 is the vCPU count, s means premium storage support and v5 is the hardware generation.

Azure managed disks come in five types, ordered here from highest to lowest performance: Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD and Standard HDD.

Premium and Ultra disks require VM sizes that support premium storage, which is the s in many size names.

The temporary disk is local storage on the physical host that runs your VM. It is meant for scratch data such as page files, swap and caches, not for anything you cannot afford to lose.

Its contents survive a normal reboot but are wiped when the VM is redeployed, resized to a different host, deallocated and restarted elsewhere, or moved during maintenance. On Windows it appears as D:; on Linux it is usually mounted at /mnt.

Not every size has one. Sizes such as Ddsv5 include a temp disk while Dsv5 does not, so check the size before relying on it. Never put application data or databases on it.

A managed disk is a block storage volume whose underlying storage account, placement and replication are handled by Azure. You only choose the type, size and performance tier; you never see or manage a storage account.

Benefits over the older unmanaged disks include simpler scaling, better availability when used with availability sets, support for snapshots and images, Azure RBAC on each disk, and server-side encryption by default.

Managed disks support LRS (three copies in one datacenter) and, for some disk types, ZRS (copies across zones). Geo-redundant options are not offered, so cross-region protection needs Azure Backup or Site Recovery.

An Availability Set is a logical grouping that spreads VMs across separate hardware inside one datacenter so a single rack failure or maintenance event does not take down every VM.

It does this with two concepts. Fault domains are groups sharing a power source and network switch (up to 3 in most regions). Update domains are groups rebooted together during planned maintenance (5 by default, up to 20).

Put each tier of an application (for example two web VMs and two database VMs) in its own availability set and front the web tier with a load balancer. The service is free; you pay only for the VMs. It protects against hardware faults, but not against a whole datacenter outage.

Availability Zones are physically separate datacenters within one Azure region, each with independent power, cooling and networking. Zone-enabled regions have at least three zones.

You can pin a VM to a specific zone, or deploy several VMs across zones so that the loss of an entire datacenter leaves the others running. Zone-redundant services such as Standard Load Balancer and ZRS disks extend this protection.

Zones sit closer together than regions, so latency between them is low enough for synchronous replication. Cross-zone data transfer may be billed on some services, so check pricing.

A Virtual Machine Scale Set (VMSS) lets you create and manage a group of load-balanced VMs from a single definition, with the instance count growing or shrinking automatically based on demand or a schedule.

You define the image, size, networking and extensions once. Azure keeps the instances consistent, replaces unhealthy ones and can spread them across fault domains and zones. A scale set can hold up to 1,000 instances.

Autoscale rules come from Azure Monitor autoscale, for example adding two instances when average CPU stays above 70% for 10 minutes. Scale sets suit stateless web tiers, batch jobs and containerized worker pools.

Create a resource group first, then run az vm create with the image, size and admin credentials. The CLI builds the NIC, VNet, public IP and NSG for you if you do not supply existing ones.

az group create --name rg-demo --location eastus

az vm create \
  --resource-group rg-demo \
  --name vm01 \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys

az vm open-port --resource-group rg-demo --name vm01 --port 80

--generate-ssh-keys creates a key pair under ~/.ssh if none exists, and az vm open-port adds an NSG rule. For Windows, use a Windows image alias and --admin-password instead of SSH keys.

A Network Security Group (NSG) is a stateful packet filter that allows or denies inbound and outbound traffic to Azure resources using rules based on source, source port, destination, destination port and protocol.

Rules carry a priority from 100 to 4096; the lowest number is evaluated first and processing stops at the first match. You can attach an NSG to a subnet, a NIC, or both, in which case traffic must pass both.

Azure bills VM compute per second, and you can lower the rate by committing, using spare capacity or reusing licenses. Disks, public IPs and bandwidth are billed separately.

Most production estates mix them: reservations for the steady baseline, pay-as-you-go for spikes and Spot for batch work.

Reserved VM Instances are a pre-purchase of VM compute capacity for a 1 or 3 year term in exchange for a discount of up to roughly 70% against pay-as-you-go, depending on size, region and term.

The discount applies only to the compute portion of the bill. Storage, networking and, for Windows VMs, the license are billed separately unless covered by Hybrid Benefit. The reservation is matched automatically to running VMs that fit its scope (a subscription, a resource group or shared across a billing scope).

With instance size flexibility, the discount can apply to other sizes in the same size series, so resizing within a series does not waste the reservation. Reservations suit steady workloads that run around the clock; use a savings plan if your sizes and regions change often.

Spot VMs run on Azure's unused capacity at a steep discount, sometimes up to 90% below pay-as-you-go. The catch is that Azure can take the capacity back, evicting your VM at short notice.

Eviction happens when Azure needs the capacity or when the Spot price exceeds your maximum price. You get roughly 30 seconds of warning through Scheduled Events in the Instance Metadata Service. Spot VMs carry no SLA.

Good fits are fault-tolerant, restartable workloads: batch processing, CI build agents, rendering and dev/test. Avoid them for single-instance production services or databases without replicas.

Azure Bastion is a managed PaaS service that gives you RDP and SSH access to VMs through the Azure portal (or native client) over TLS on port 443, so the VMs need no public IP and no open management ports.

You deploy it into a dedicated subnet named AzureBastionSubnet (at least /26) in the VNet. Bastion then reaches VMs over their private IPs, and it works with peered VNets too.

Compared with a jump box, there is no VM to patch or harden, and the service is hardened against port scanning. SKUs (Developer, Basic, Standard, Premium) add features such as native client support, file transfer and session recording.

An Azure VM can have private and public IP addresses, both attached to its NIC's IP configuration.

A dynamic private IP is only released when the NIC is deleted, but setting it to static guarantees the address for things like DNS servers and domain controllers.

Windows VMs are reached with RDP (TCP 3389) and Linux VMs with SSH (TCP 22). Both can be used directly over a public IP, over a private network such as VPN or ExpressRoute, or through Azure Bastion.

For production, avoid exposing 3389 or 22 to the internet. Use Bastion, Just-In-Time access or a VPN, and prefer SSH keys over passwords on Linux.

VM extensions are small packages that run inside a VM after deployment to configure it, install software or enable monitoring. They are installed and run by the Azure VM Agent.

Common ones are the Custom Script Extension (runs a script from storage or inline), Azure Monitor Agent, the Desired State Configuration extension, Azure Disk Encryption and the antimalware extension.

az vm extension set \
  --resource-group rg-demo --vm-name vm01 \
  --publisher Microsoft.Azure.Extensions --name CustomScript \
  --settings '{"commandToExecute":"apt-get update && apt-get install -y nginx"}'

If the VM Agent is stopped or missing, extensions fail to provision, so check the agent status first when troubleshooting.

Azure Hybrid Benefit lets you apply existing on-premises licenses to Azure workloads so you pay only the base compute rate instead of a rate that includes the license.

It covers Windows Server and SQL Server licenses that have Software Assurance or a qualifying subscription, and also supports Red Hat and SUSE Linux subscriptions. For Windows Server VMs the saving can reach around 40%, and it stacks with reservations for larger discounts.

You enable it per VM (the license type setting in the portal or --license-type Windows_Server in the CLI). Keep your license records in order, because you are responsible for being compliant.

An Azure VM moves through Starting, Running, Stopping, Stopped, Deallocating and Deallocated. The distinction between Stopped and Deallocated matters because only a deallocated VM stops compute billing.

flowchart LR
  A[Starting] --> B[Running]
  B --> C[Stopping]
  C --> D["Stopped - still allocated"]
  B --> E[Deallocating]
  D --> E
  E --> F[Deallocated]
  F --> A
  D --> A

Shutting down from inside the guest OS leaves the VM in Stopped (allocated). Using Stop in the portal, or az vm deallocate, releases the compute resources.

A managed identity is an identity in Microsoft Entra ID that Azure creates and manages for your VM, so applications on the VM can get tokens to access other Azure resources without any stored credentials.

There are two kinds. A system-assigned identity is tied to one VM and deleted with it. A user-assigned identity is a standalone resource that can be attached to many VMs.

You grant the identity an Azure RBAC role (for example Key Vault Secrets User or Storage Blob Data Reader). Code on the VM then requests a token from the Instance Metadata Service, which removes passwords and connection secrets from config files.

Azure Backup protects Azure VMs by taking scheduled, policy-driven backups of all their disks and storing recovery points in a Recovery Services vault.

On the first run it installs a backup extension. Each job takes a snapshot, which allows fast instant restore from the snapshot tier, and then transfers the data to the vault. Windows VMs get application-consistent backups through VSS; Linux uses pre/post scripts for that.

• Create new VM from a recovery point
• Replace existing disks on the original VM
• Restore disks and build the VM yourself
• File recovery by mounting the recovery point

Retention is defined in the policy (daily, weekly, monthly, yearly), and vault data can be replicated with GRS for regional protection.

The Instance Metadata Service (IMDS) is a REST endpoint available inside every Azure VM at the non-routable address 169.254.169.254. It returns information about the running instance and issues managed identity tokens.

curl -H "Metadata:true" \
  "http://169.254.169.254/metadata/instance?api-version=2021-02-01" 

• /metadata/instance for VM size, region, zone, network and tags
• /metadata/identity/oauth2/token for managed identity tokens
• /metadata/scheduledevents for maintenance and Spot eviction notices

The request must include the Metadata: true header, which helps block simple server-side request forgery. The service is reachable only from within the VM.

A stopped VM has been shut down but still holds its hardware allocation, so you keep paying for compute. A deallocated VM has released that hardware, so compute billing stops and only storage is charged.

The CLI trap is that az vm stop does not deallocate. Use az vm deallocate if the goal is to save money.

Both spread VMs to survive failures, but an Availability Set spreads them across racks inside one datacenter, while Availability Zones spread them across separate datacenters in a region.

A VM cannot be in both an availability set and a zone. If the region supports zones, choose zones for new designs; use availability sets where zones are unavailable.

Azure VMs can use host-level caching, where reads (and optionally writes) are served from the host's local memory and SSD before hitting remote storage. Each disk has a host caching setting: None, ReadOnly or ReadWrite.

A common SQL Server pattern is ReadOnly on data file disks and None on log disks. Ultra Disks and Premium SSD v2 do not support host caching, because they are already designed for very low latency.

Resizing changes the VM size to a different vCPU, memory and bandwidth profile. In the portal use Size, or use az vm resize in the CLI. A restart happens as part of the change.

az vm list-vm-resize-options -g rg-demo -n vm01 -o table
az vm deallocate -g rg-demo -n vm01
az vm resize -g rg-demo -n vm01 --size Standard_D4s_v5
az vm start -g rg-demo -n vm01

If the new size is available on the current hardware cluster, Azure just reboots the VM. If not, you must deallocate first so Azure can place it on another cluster, which also wipes the temporary disk.

Check the limits before you resize: the number of data disks, premium storage support, VM generation (Gen1 or Gen2), accelerated networking support and regional quota.

Autoscale uses Azure Monitor autoscale settings attached to the scale set. A profile defines the minimum, maximum and default instance counts, and rules inside it add or remove instances.

• Metric-based rules: for example, scale out by 2 when average CPU is above 70% for 10 minutes, scale in by 1 below 30%.
• Schedule-based profiles: fixed capacity at certain times, such as business hours.
• Predictive autoscale: uses CPU history to scale out ahead of a recurring load.

A cooldown period after each action prevents flapping, where the set scales out and in repeatedly. Always keep the scale-in threshold well below the scale-out threshold. Scale-in policy (Default, NewestVM, OldestVM) decides which instances are removed first.

In Uniform mode a scale set creates identical instances from one model. In Flexible mode the set orchestrates regular Azure VMs, which can differ in size and configuration, while still giving you scale-out, zone spreading and fault domain control.

Microsoft recommends Flexible orchestration for new deployments. Keep Uniform for existing designs that rely on features not yet carried over.

Azure Load Balancer works at layer 4 (TCP/UDP). By default it uses a five-tuple hash of source IP, source port, destination IP, destination port and protocol to pick a healthy backend VM for each new flow.

flowchart LR
  C[Client] --> F["Frontend IP"]
  F --> R{Load balancing rule}
  R --> V1["VM 1 - healthy"]
  R --> V2["VM 2 - healthy"]
  R -.->|probe failed| V3["VM 3 - removed"]

Health probes (TCP, HTTP or HTTPS) check each VM, and a failed probe takes it out of rotation until it recovers. You can switch to source IP affinity (2-tuple or 3-tuple) if clients need to stick to one VM.

Standard SKU is zone-redundant and secure by default, so you need an NSG that permits the traffic. For layer 7 routing such as URL paths or TLS offload, use Application Gateway instead.

A generalized image has machine-specific data (hostname, users, SIDs, SSH host keys) stripped out so it can be used to create many unique VMs. A specialized image is an exact copy of a VM, identity included, and is used to clone or restore that machine.

Generalizing is one-way for the source VM, which becomes unusable afterwards, so take a copy first if you still need it.

Azure Compute Gallery stores, versions and shares VM images. You organize them as a gallery, which holds image definitions (OS type, publisher/offer/SKU, generalized or specialized), which in turn hold image versions.

az sig create -g rg-img --gallery-name myGallery
az sig image-definition create -g rg-img --gallery-name myGallery \
  --gallery-image-definition web-base --publisher Contoso --offer web --sku base \
  --os-type Linux --os-state Generalized
az sig image-version create \
  --resource-group rg-img --gallery-name myGallery \
  --gallery-image-definition web-base --gallery-image-version 1.0.0 \
  --managed-image /subscriptions/<id>/resourceGroups/rg-img/providers/Microsoft.Compute/images/web-img \
  --target-regions eastus westeurope

Image versions can replicate to multiple regions for faster, more reliable deployments, and access is controlled with Azure RBAC. You can also share across subscriptions and tenants. Scale sets and VMs reference a specific version or latest.

A proximity placement group (PPG) is a logical grouping that asks Azure to place its VMs physically close together, ideally in the same datacenter, to minimize network latency between them.

They help latency-sensitive tiers such as an application server talking to its database in chatty, low-latency patterns, or tightly coupled HPC jobs. PPGs work with standalone VMs, availability sets and scale sets within one region.

The trade-off is flexibility. Tighter placement raises the chance of allocation failures, especially when you add VMs later or use scarce sizes. Deploy all VMs in the group in a single request, start with the most constrained size, and avoid using a PPG together with multi-zone spreading because the two goals conflict.

Azure regularly updates the host platform. Most updates are memory-preserving: the VM is paused for a few seconds (typically 10 or less) and resumes without a reboot. A smaller set requires a reboot or a move to a new host.

• Azure notifies you in advance for events that need a reboot or redeployment.
• VMs in an availability set are updated one update domain at a time, with a 30-minute pause between domains.
• Scheduled Events in IMDS let the VM see upcoming events and react, for example by draining connections.
• Maintenance configurations let you control timing on Dedicated Hosts and isolated VM sizes.

Plan for restarts by running at least two instances behind a load balancer, and make sure applications start cleanly after a reboot.

Azure sends a Preempt notice through Scheduled Events about 30 seconds ahead, then stops the VM. What happens next depends on the eviction policy you chose at creation.

Eviction is triggered by capacity needs or by the Spot price passing your maximum. Setting the max price to -1 means you will pay up to the regular on-demand price, so you are evicted only for capacity reasons.

Handle it in the app: poll the scheduled events endpoint, checkpoint work and keep jobs restartable.

Accelerated networking uses SR-IOV to give the VM direct access to the physical network card, bypassing the host's virtual switch for most traffic. Packets go straight between the VM and the NIC's virtual function.

The result is lower latency, less jitter and lower CPU use for networking, which matters for high-throughput or chatty workloads. On Linux the VM sees both a synthetic NIC and a Mellanox virtual function that are bonded together.

az network nic create -g rg-demo -n nic01 --vnet-name vnet1 --subnet app \
  --accelerated-networking true

It is supported on most general purpose and compute optimized sizes with at least 2 vCPUs, and on supported OS images. You can enable it on an existing NIC while the VM is deallocated.

Server-side encryption (SSE) encrypts managed disk data at rest in the storage service and is on by default. Azure Disk Encryption (ADE) encrypts volumes inside the guest OS using BitLocker on Windows or DM-Crypt on Linux, with keys held in Key Vault.

For stronger coverage, enable encryption at host, which encrypts temp disks and caches before data leaves the host. Microsoft has announced a retirement plan for ADE, so check current guidance before choosing it for new builds.

Trusted Launch protects the VM's boot chain against rootkits and bootkits. Confidential VMs go further and encrypt memory in hardware, protecting data in use from the host, hypervisor and even Azure operators.

Pick Trusted Launch as a sensible default for Gen 2 VMs and Confidential VMs for regulated data or multiparty computation where even the cloud operator must be excluded.

Just-In-Time (JIT) VM access in Microsoft Defender for Cloud keeps management ports (such as 22, 3389, 5985 and 5986) closed by default and opens them only for an approved user, source IP and time window.

1. JIT adds a deny rule to the NSG (or Azure Firewall) for the chosen ports.
2. A user requests access, choosing the port, their IP and a duration (up to 24 hours).
3. If RBAC allows it, Defender adds a temporary allow rule with higher priority.
4. When the time expires, the allow rule is removed and the port is closed again.

Every request is logged, so you get an audit trail. JIT requires Defender for Servers Plan 2 and the VM must be protected by an NSG or firewall.

Azure Update Manager assesses missing updates and installs them on Azure VMs and Azure Arc-enabled servers, on a schedule or on demand, without needing an Automation account.

1. Enable periodic assessment so it checks for missing patches regularly.
2. Create a maintenance configuration that defines the schedule, update classifications and any KB inclusions or exclusions.
3. Assign VMs to the configuration, directly or through dynamic scopes based on tags and locations.
4. Review compliance and run history in the portal.

The VM patch mode matters too. AutomaticByPlatform lets Azure orchestrate patching with availability-aware safe deployment, ImageDefault uses the OS's own settings and Manual leaves you in control. It replaces the older Automation Update Management solution.

Azure gives you host-level metrics out of the box and richer guest-level data once you install the Azure Monitor Agent (AMA).

Memory is not visible from the host, so you need the agent for it. Send data to a Log Analytics workspace, build alert rules on metrics or log queries, and route notifications with action groups. The old Log Analytics (MMA) agent was retired in August 2024, so use AMA.

Custom data is a blob of up to 64 KB that you pass at VM creation. On Linux images with cloud-init, Azure delivers it and cloud-init runs it during first boot, so you can install packages and write files without logging in.

#cloud-config
package_upgrade: true
packages:
  - nginx
runcmd:
  - systemctl enable --now nginx

az vm create -g rg-demo -n web01 --image Ubuntu2204 \
  --custom-data cloud-init.txt --generate-ssh-keys

It runs only at initial provisioning, not on later reboots. On Windows, custom data is just written to a file and not executed automatically. Do not put secrets in it, since it can be read from within the VM.

The VM SLA depends on how you deploy. A single VM using premium storage for all disks gets 99.9%. Two or more VMs in an availability set get 99.95%, and two or more across zones get 99.99%.

Spot VMs have no SLA. Note that the SLA covers VM connectivity, not your application, so design the app tier and data layer for the same level.

Choose VMs when you need control of the operating system: custom drivers, installed software, specific kernels, licensing tied to a machine, or lift-and-shift of an app that cannot be changed.

If the app is a standard web app, App Service removes most operational work. If it is containerized and needs orchestration, AKS fits. Many teams run a mix, with VMs for the legacy parts.

Use Azure Dedicated Host when you need a physical server used only by your organization, typically for compliance or licensing reasons.

• Isolation: no other customer's VMs share the hardware.
• Licensing: bring per-core or per-socket licenses (Windows Server, SQL Server) and use them with visibility of the physical host.
• Maintenance control: choose when platform updates apply, using maintenance configurations.
• Placement control: host groups spread hosts across fault domains and zones.

You pay for the entire host regardless of how many VMs run on it, so it only pays off at reasonable utilization. Each host supports one VM series and size family. If you only need isolation without managing hosts, consider isolated VM sizes.

Azure Site Recovery (ASR) continuously replicates a VM's disks to a target region, so you can fail over to a ready copy if the source region has an outage.

flowchart LR
  A["Source VM in region 1"] -->|Mobility service sends changes| B["Cache storage account"]
  B --> C["Replica disks in region 2"]
  C --> D{Failover}
  D --> E["VM created in region 2"]
  E --> F["Reprotect and failback"]

Changes are tracked and sent through a cache storage account in the source region. Crash-consistent recovery points are created every 5 minutes, and app-consistent points on a schedule you set. A recovery plan orders the failover of multiple VMs and runs scripts.

Use test failover to rehearse in an isolated network without affecting production. After the incident you can reprotect and fail back.

A snapshot is a one-time, read-only, point-in-time copy of a single managed disk. Azure Backup is a managed service that automates scheduled, policy-based backups of the whole VM with retention and application consistency.

Snapshots suit a quick rollback before a risky change. For real data protection use Azure Backup, because a snapshot kept in the same region is lost together with the region.

Work from the outside in: confirm the VM is healthy, then the network path, then the guest OS.

1. Check the VM is Running and review Resource Health and boot diagnostics (screenshot) for a stuck boot.
2. Confirm the public IP or Bastion path, and that you are connecting to the right address.
3. Use Network Watcher IP flow verify and Effective security rules to see whether an NSG blocks TCP 3389.
4. Use Connection troubleshoot to test the path from a source to the VM.
5. Run Test-NetConnection from another VM and check the guest firewall.
6. Use Run Command to check the TermService service and RDP registry settings.
7. Use Reset password / Reset configuration (VMAccess) to repair RDP settings and credentials.
8. As a last resort, redeploy to a new host, or attach the OS disk to a rescue VM with az vm repair.

Serial Console is the fallback when the network is not working at all.

Start by removing waste, then right-size, then commit. The order matters, because reserving a VM that should have been smaller locks in the waste.

1. Right-size using Azure Advisor recommendations and CPU and memory metrics.
2. Deallocate dev/test VMs when idle, with auto-shutdown schedules (stopped but allocated VMs still bill).
3. Delete orphans: unattached disks, idle public IPs and old snapshots.
4. Use Reservations or a savings plan for steady workloads.
5. Apply Hybrid Benefit for eligible Windows, SQL, Red Hat and SUSE licenses.
6. Use Spot VMs for fault-tolerant batch jobs.
7. Choose the right disk tier and consider burstable B-series for light, spiky workloads.
8. Use autoscale and set budgets, tags and alerts in Cost Management.

The supported way is Azure Resource Mover, which replicates the VM's disks to the target region and recreates the VM and its dependencies there, with minimal downtime.

flowchart LR
  A["Add resources"] --> B["Validate dependencies"]
  B --> C[Prepare]
  C --> D["Initiate move"]
  D --> E{Commit or discard}
  E --> F["Delete source"]

1. Add the VM and let Resource Mover include dependencies (VNet, NIC, NSG, public IP, disks).
2. Validate dependencies and fix any blockers, such as unsupported items or quota.
3. Prepare to start replicating disks to the target region.
4. Initiate move to create the VM in the target region.
5. Commit to finish the move or discard to roll back, then delete source resources if no longer needed.

Public IP addresses change, so update DNS. Check that the target region supports the VM size and that you have quota. You can also use Site Recovery or copy a snapshot and rebuild the VM manually.