Microsoft Azure
Beginner 14 min read Microsoft Azure

Virtual Machines & Microsoft Entra ID

Azure Virtual Machines are IaaS servers launched from images and sizes with managed disks for storage. Availability sets and availability zones keep them highly available. Microsoft Entra ID (formerly Azure AD) is the identity platform behind everything, and RBAC roles plus managed identities decide who and what can act. Learn how the compute and identity layers fit together.

Azure VMimageVM sizeavailability setavailability zonemanaged diskMicrosoft Entra IDRBACmanaged identityservice principal
Prerequisites: Azure Platform Overview
Introduction

What is this?

Azure Virtual Machines are IaaS compute resources: you pick an image (Windows Server, Ubuntu, and others), choose a size (CPU and memory), attach managed disks for storage, and place the VM in a virtual network with a network security group. Availability sets and availability zones protect against maintenance and datacenter failures. Microsoft Entra ID (formerly Azure Active Directory) is the identity platform for everything — users, groups, service principals — and RBAC roles define what each identity may do, while managed identities let VMs and apps authenticate to Azure services without storing any secret.

Motivation

Why do you need it?

  • VMs are the foundation of most lift-and-shift workloads, and many DevOps platforms (agents, databases, legacy apps) run on them.
  • SSH and Remote Desktop access, size selection and disk management are daily DevOps decisions.
  • Availability sets and zones are how you meet the 99.9% VM SLA in production.
  • Entra ID plus RBAC is the security backbone of Azure — almost every access error traces back to an RBAC decision.
  • Managed identities are the secure pattern for giving applications Azure permissions without keys in code.
Think about it

Mental model

Imagine

Assigning office space and building badges

Think of

Azure VMs and Entra ID

A VM is a workstation you pick from a catalog (image and size), set on a desk (managed disk) in a specific room (subnet). Availability sets are like guaranteeing each team has desks in multiple buildings so one fire drill never empties the team. Entra ID is the building badge system — a badge (identity) unlocks specific floors (RBAC roles), and a managed identity is a robot that carries a badge automatically, without a password taped to its wrist.

Mechanics

How it works

  • You create a VM from an image and size in a resource group; Azure provisions compute, attaches managed disks and joins the VM to the virtual network.
  • Availability sets spread VMs across fault domains (physical racks) and update domains (maintenance batches); availability zones place them in separate facilities.
  • Managed disks are Azure-managed SSD or HDD volumes; the OS disk and data disks can be snapshotted, resized and encrypted.
  • Entra ID authenticates users and service principals; RBAC roles (Owner, Contributor, Reader, custom) are assigned at a scope — management group, subscription, resource group or resource.
  • A managed identity is an Entra ID identity with automatically rotated credentials; the VM or app uses it to call Azure services with no secret stored anywhere.

Creating a VM and securing it with identity.

Pick image and size
Choose placement
Attach managed disks
Join the virtual network
Assign a managed identity
RBAC grants access
Reference

Key commands

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

Create the resource group that will hold the VM.

az vm create --resource-group rg-dev --name web-vm --image UbuntuLTS --size Standard_B2s --generate-ssh-keys

Provision a Linux VM with an SSH key in one command.

az vm list --resource-group rg-dev -o table

List VMs in the group with their power states.

az vm show --resource-group rg-dev --name web-vm --query powerState

Check whether the VM is actually running.

az vm identity assign --resource-group rg-dev --name web-vm

Attach a system-assigned managed identity to the VM.

az role assignment list --assignee <principal-id>

See which RBAC roles an identity currently holds.

Hands-on

Examples

Create a VM and inspect its properties

Create a VM and inspect its properties
$ az vm create --resource-group rg-dev --name web-vm \
    --image UbuntuLTS --size Standard_B2s \
    --admin-username devops --generate-ssh-keys
 
{
  "id": "/subscriptions/.../resourceGroups/rg-dev/providers/Microsoft.Compute/virtualMachines/web-vm",
  "location": "eastus",
  "powerState": "VM running",
  "publicIpAddress": "52.1.2.3"
}
 
$ az vm show --resource-group rg-dev --name web-vm \
    --query "{Sku:hardwareProfile.vmSize,Location:location,Power:powerState}" -o table
Sku            Location    Power
Standard_B2s   eastus      VM running

az vm create provisions the VM in one command — image, size, admin user and SSH key. The output shows the resource ID, power state and public IP. az vm show with a --query pulls specific properties the way automation scripts do. The generated SSH key lives under ~/.ssh, and you connect with the user and public IP it returns.

Real world

In production

  • Run stateless web tiers across availability zones behind Azure Load Balancer for high availability.
  • Use managed identities instead of keys or connection strings stored on the VM.
  • Control cost and compliance with Azure Policy and autoshutdown schedules on every dev VM.
  • Build golden images with Packer or the Shared Image Gallery to eliminate configuration drift.
  • Reach VMs in private subnets through Azure Bastion instead of exposing SSH to the internet.
Guidelines

Best practices

  • Right-size VMs: start small, watch metrics, and scale out before scaling up.
  • Deploy at least two instances in an availability set or across zones to meet the VM SLA.
  • Assign managed identities and least-privilege RBAC roles to everything.
  • Enable disk encryption and Microsoft Defender for Cloud on VM workloads.
  • Separate data disks from the OS disk and snapshot them on a schedule.
Watch out

Common mistakes

  • Leaving VMs running 24/7 on paid sizes just in case they are needed.
  • Placing VMs in a public subnet with SSH open to the whole internet.
  • Storing admin passwords or connection strings inside images or user data.
  • Assigning Contributor at subscription scope to a development service principal.
  • Forgetting that a single VM in an availability set has no SLA protection.
Root cause analysis

Common issues

Error
ssh: connect to host port 22: Operation timed out
Root cause

The NSG blocks port 22 from your IP, or the VM has no public IP or route.

Fix

Add an inbound NSG rule for port 22 from your IP and confirm the VM has a public IP in a subnet with internet routing.

Error
The requested size for resource 'web-vm' is currently not available in location 'eastus'
Root cause

The VM size is not offered (or is out of stock) in the region or zone.

Fix

Check az vm list-skus --location eastus and choose an available size.

Error
Insufficient privileges to complete the operation
Root cause

The signed-in identity lacks RBAC permissions on the resource group.

Fix

Assign an appropriate role (Owner, Contributor, or a scoped custom role) to the identity and retry.

When things break

Debugging tips

  • Check VM boot diagnostics when SSH is unreachable — they show serial console output.
  • Verify the network security group allows your source IP on port 22 or 3389 before blaming the image.
  • Use az vm show --query powerState to confirm the VM is actually running.
  • For authorization errors, list the identity's roles and their scope with az role assignment list.
  • Check the activity log to see who created or modified the VM.
Interviews

Interview checkpoint

Practice

Hands-on lab

Set Up SSH Keys and Identity Locally
25 min · beginner
In progress
Objectives
  • Create the standard ~/.ssh directory with correct permissions
  • Generate a key pair with ssh-keygen the way az vm create does
  • Lock down the private key and inspect its fingerprint
  • Authorize the key locally and verify your identity

Set Up SSH Keys and Identity Locally

25 min · beginner

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which Azure feature spreads VMs across fault domains and update domains to survive rack failures and planned maintenance?

2

A managed identity requires storing a client secret somewhere on the VM.

3

An app running on a VM gets AuthorizationFailed when it calls Key Vault. What is the most likely cause?

Quick reference

Cheat sheet

VM essentials
ImageOS template, e.g. UbuntuLTS, WindowsServer
SizeStandard_B2s — vCPU and memory
Managed diskSSD/HDD volume, snapshot-able
Availability setFault + update domain spread
Availability zoneSeparate facility within a region
Identity building blocks
Microsoft Entra IDIdentity platform (formerly Azure AD)
Service principalIdentity for an application
RBAC roleOwner, Contributor, Reader, custom
Managed identityAuto-rotated identity for workloads
ScopeManagement group, subscription, RG, resource
Go deeper

Official documentation

Azure Virtual Machines overview
docs
Virtual machines and availability zones
docs
What is Microsoft Entra ID?
docs
What is Azure role-based access control?
docs
What are managed identities?
docs