Section 7 of 14
This is the largest domain in raw content. It covers virtual machines, scale sets, containers (ACI and AKS), App Service, and the deployment tooling (ARM templates, Bicep). Compute questions love to test cost optimization, availability, and the order of operations.
A VM in Azure is Infrastructure-as-a-Service: you manage the OS and everything above. Azure manages the hypervisor, hardware, and physical networking. You pay per second of running time plus the disks attached.
| Series | Optimized for | Use case |
|---|---|---|
| D / Ds | General purpose | Web, app, small DBs - balanced CPU/memory |
| E / Es | Memory optimized | Large DBs, SAP HANA, in-memory analytics |
| F / Fs | Compute optimized | Batch, game servers, CPU-heavy work |
| N / NC / ND | GPU enabled | ML training, rendering, deep learning |
| L / Ls | Storage optimized | Local high-throughput disk workloads |
| B | Burstable | Banks CPU credits when idle, useful for dev/test |
| M | Memory optimized (very large) | Massive databases needing TBs of RAM |
Format: Standard_<family><sub-family><vCPUs><features>_<version>
D4s_v5 = D family, 4 vCPUs, 's' supports Premium SSD, version 5
Ds = supports Premium SSD
d = has local SSD temp disk
a = AMD processor
l = lower memory variant
Resize behavior depends on the target hardware cluster If the new size is on the SAME hardware cluster, the VM just restarts (brief outage). If the new size is on a DIFFERENT hardware cluster, the VM must be DEALLOCATED (stopped + deallocated, not just stopped). Stopping a VM in the OS keeps it allocated and still bills you. Deallocate from the portal/CLI to actually stop charging.
If a VM is in an availability set and you want to resize it to a size unavailable in that cluster, you must STOP ALL VMs in the availability set first. Not just the one you are resizing.
Redeploy moves a VM to a new host. Used to recover from hardware issues or maintenance. Caveats:
Temporary disk data is LOST (D: drive on Windows, /dev/sdb on Linux)
Dynamic IP addresses (private and public if dynamic) are released and a new one is assigned
OS disk data is preserved (it lives on managed disk storage, not the host)
| Method | Description | Default port |
|---|---|---|
| RDP | GUI session for Windows VMs | TCP 3389 |
| SSH | Encrypted login for Linux VMs | TCP 22 |
| WinRM | Command-line session for Windows VMs | TCP 5985/5986 |
| Azure Bastion | Browser-based RDP/SSH over SSL - no public IP on VM | TCP 443 (to Bastion) |
Azure Bastion is the right answer when the question wants secure VM access WITHOUT giving the VM a public IP. Bastion sits in its own subnet (named AzureBastionSubnet, /26 or larger) and acts as a managed jump box. Users RDP/SSH through the browser.
Microsoft's SLA for a single VM depends entirely on how you architect for redundancy. Pick the right level based on the SLA the question demands.
| Configuration | SLA | Scope | Best for |
|---|---|---|---|
| Single VM + Premium SSD | 99.9% | One rack in one datacenter | Dev/test only |
| Availability Set (2+ VMs) | 99.95% | Multiple racks in one datacenter | Protection from rack failure & patching |
| Availability Zone (2+ VMs across zones) | 99.99% | Multiple physical datacenters in one region | Protection from datacenter failure |
| Multi-Region with ASR | Custom | Different Azure regions | Full regional disaster recovery |
Availability Sets vs Availability Zones - the most-tested confusion Availability Set = same datacenter, different racks (fault domains) and patching schedule (update domains). Protects against rack and patching failures. Availability Zone = separate physical datacenters in the same region. Each AZ has its own power, cooling, networking, and control plane. AZ > Set. Always prefer Availability Zones when the region supports them. Use Sets only for backwards compatibility or if AZs are unavailable.
Fault Domain - protection from UNPLANNED hardware failure (power, network, rack)
Update Domain - protection from PLANNED maintenance and patching
Defaults: 2 fault domains, 5 update domains (max 20 update domains)
You configure both when creating an Availability Set
Availability Sets require VMs to be STOPPED/DEALLOCATED before being added. You cannot add a running VM to an availability set. The set must also be specified at VM creation - you cannot move a VM into an availability set later without recreating it.
PPGs colocate resources in the same datacenter for ultra-low latency. They must match the region of the resources placed in them. A scale set in West Europe cannot use a PPG in East Europe.
| Event type | Azure platform action |
|---|---|
| Unplanned hardware maintenance | Live migration initiated |
| Unexpected downtime | Auto-heal: VM is moved to a healthy host |
| Planned maintenance | No action required from user (Azure handles transparently) |
Microsoft loves cost questions. The right answer depends on the workload pattern.
| Option | Savings | Best for | Catch |
|---|---|---|---|
| Spot VMs | Up to 90% | Batch, CI/CD, dev/test | Can be evicted with 30 seconds notice |
| Reserved Instances | Up to 72% | Predictable, always-on workloads | 1 or 3 year commitment |
| Azure Hybrid Benefit | Up to 40% on top | Existing Windows/SQL/RHEL licenses | Requires Software Assurance |
| Savings Plan | Up to ~65% | Flexible compute spend | 1 or 3 year, must commit hourly spend |
| B-series VMs | Variable | Bursty/idle workloads | Banks credits when idle, bursts when busy |
Spot VMs are NOT guaranteed. They use Azure spare capacity and can be evicted with 30 seconds notice when capacity is needed elsewhere or your max price is exceeded. Never use for critical 24/7 workloads. Best for interruptible work.
Reserved Instance + Hybrid Benefit can stack. A Windows VM on a 3-year RI with Azure Hybrid Benefit removes both the compute discount AND the OS licensing cost.
Scale sets are groups of identical VMs that auto-scale based on rules. They are how you scale horizontally - add more VMs as load grows. This is opposed to vertical scaling, which means making one VM bigger (and which requires deallocating).
| Mode | Description | When to use |
|---|---|---|
| Uniform | All VMs are identical - same image, size, extensions | Traditional model, most predictable |
| Flexible | Can mix VM sizes, include spot instances, manually add VMs | More flexibility, hybrid scaling strategies |
Every autoscale rule must define:
Minimum, maximum, and default instance counts
Scale-out trigger and scale-in trigger (typically based on CPU%)
Cooldown period between scaling actions
Autoscale is HORIZONTAL scaling - adding/removing VMs. If a question describes a workload that needs to 'handle increased load automatically', the answer is VMSS, NOT resizing the VM.
When you scale out, new VM instances are provisioned from the base image. To ensure they have your software installed (e.g. NGINX, IIS), you use one of these:
Desired State Configuration (DSC) extension - declarative, ongoing enforcement
Custom Script Extension - runs a script during provisioning
Bake software into a custom image
If the question says 'ensure NGINX is installed on all VMSS instances after deployment', and you are deploying via ARM template, the answer is the DSC extension (or Custom Script Extension). NOT Intune (that is for endpoints), NOT App Service Deployment Center (that is for web apps).
App Service is Platform-as-a-Service for hosting web apps, APIs, and mobile backends. You bring the code, Azure handles the OS, runtime, scaling, and patching.
| Tier | SLA | Key features | Notes |
|---|---|---|---|
| Free | None | Basic hosting only | No custom domain, no SSL, no backup, no scaling |
| Shared | None | Custom domain support | Still on shared infrastructure, no SSL |
| Basic | 99.95% | Custom domain + SSL, manual scale | Production-capable but no backups, no slots |
| Standard | 99.95% | Backups, 5 slots, autoscale | MINIMUM for deployment slots and daily backups |
| Premium | 99.95% | 20 slots, VNet integration, more performance | Higher-scale production |
| Isolated | 99.95% | App Service Environment in your VNet | Compliance/isolation scenarios |
Tier-locked features to memorize App Service Backups require Standard tier or higher. Free and Shared do NOT support backups. Deployment Slots require Standard or higher (5 slots on Standard, 20 on Premium). Custom Domains require Shared tier or higher. SSL Certificates require Basic or higher. Autoscaling (not just manual scale) requires Standard or higher.
| Feature | Description |
|---|---|
| Staging slot | Used for validating changes before pushing to production |
| Auto Swap | Ensures smooth zero-downtime switch from staging to production |
| Slot-Specific Settings | Settings marked as 'slot setting' do NOT swap - they stick to their slot (e.g. connection strings, environment variables) |
| Swap with preview | Preview what will happen before actually swapping |
| Custom Domain Mapping | Redirects default app URL to your branded domain |
If a question describes a bad deployment that needs to be rolled back, the answer is SWAP THE SLOTS again (reverse swap). The old version is now in the staging slot - swap to revert. This is faster than redeploying or restoring from backup.
When adding a custom domain to App Service, the FIRST step is to create a DNS record - either a CNAME (for subdomains like www) or an A record (for root/apex domains). After verification, you bind the domain. Optionally, upload a custom SSL certificate.
Deployment Center (GitHub, Azure Repos, Bitbucket, Local Git)
FTP/FTPS
ZIP/WAR deploy via Kudu
Container deployment from Azure Container Registry or Docker Hub
Web Deploy from Visual Studio
Autoscale in App Service uses scale-out rules based on metrics (CPU %, memory %, queue length, custom metrics). Requires Standard tier or higher. Configure minimum, maximum, default instance counts and scale-in/scale-out thresholds, exactly like VMSS.
Azure has two main container services. ACI is for simple, short-lived containers. AKS is for orchestrated, complex container workloads.
| Aspect | Azure Container Instances (ACI) | Azure Kubernetes Service (AKS) |
|---|---|---|
| Type | Serverless, no orchestration | Full Kubernetes orchestration |
| Best for | One-off jobs, sidecar patterns, CI/CD bursts | Microservices at scale, complex apps |
| Billing | Pay per second the container runs | Pay for node VMs |
| Management | Zero - no nodes to manage | You manage node pools |
| Networking | Simple, can be in VNet | Multiple plugins, complex |
| Container OS | Linux or Windows (Windows = single container only) | Linux or Windows nodes |
ACI Container Groups - Linux only for multi-container Container Groups (multiple containers sharing networking/storage) are LINUX ONLY in ACI. Windows ACI supports only a single container at a time. If a question shows Windows containers needing to share resources, the answer is NOT a container group.
| Model | How it works | IP space |
|---|---|---|
| Kubenet | Pods share node IP, NAT for outbound | Separate pod CIDR, lots of NAT rules |
| Azure CNI | Each pod gets its own IP from the node's subnet | Same subnet as nodes (can exhaust IPs) |
| Azure CNI Dynamic | Pods get IPs from a separate subnet, allocated in batches | Different subnet from nodes |
| Azure CNI Overlay | Pods use an overlay network (separate CIDR), no IP exhaustion | Preferred for new clusters |
If on-prem clients need to talk to pods using the pod's IP address directly, the answer is Azure CNI (or its variants). Kubenet uses NAT and pods do not have routable IPs.
To grant users access to AKS, the first step is configuring the OAuth 2.0 authorization endpoint in your Entra tenant. AKS uses Entra ID for authentication; users get an access token to call the Kubernetes API.
Horizontal Pod Autoscaler (HPA) - adjusts the number of pod replicas
Cluster Autoscaler - adjusts the number of node VMs in a node pool
KEDA - event-driven autoscaling (e.g. scale based on Service Bus queue length)
Use az aks update with --min-count and --max-count to configure node autoscaling
Node VMs - you pay for the underlying VMs in your node pools
Networking resources - load balancers, public IPs, egress bandwidth
Storage - persistent volumes (Azure Disks, Files, etc.)
Control plane is FREE on the standard tier
Workflow: build the container image locally → push to Azure Container Registry (docker push) → apply Kubernetes manifests (kubectl apply -f yaml-file).
There are multiple ways to deploy resources to Azure. The exam expects you to know which tool is best for which job.
| Tool | Format | Pros | Cons |
|---|---|---|---|
| ARM Templates | JSON | Native to Azure, supported everywhere | Verbose, hard to read |
| Bicep | DSL (compiles to ARM JSON) | Cleaner, modular, human-readable | Newer, learning curve |
| Section | Purpose |
|---|---|
| parameters | Configurable input values at deployment time |
| variables | Reusable values within the template |
| resources | Azure services to deploy |
| outputs | Values returned after deployment for use elsewhere |
Parameters in ARM templates are NOT fixed - they can be overridden at deployment time. If a question says 'parameters are always fixed', the answer is False. Parameters exist specifically to make templates reusable across environments (dev, test, prod).
Compact, human-readable syntax
Auto-detects resource dependencies (no need to manually declare dependsOn in most cases)
Modular - split into reusable modules referenced in a main template
Compiles down to ARM JSON, so deployment behavior is identical
Bicep does NOT replace JSON ARM templates entirely - it compiles TO JSON. It also does NOT replace Azure CLI or PowerShell (those run the deployment). It does NOT enforce policies (that is Azure Policy) and does NOT replace resource locks.
| Tool | Command style | Example |
|---|---|---|
| Azure CLI | az <noun> <verb> | az vm create -g RG1 -n VM1 ... |
| Azure PowerShell | <Verb>-Az<Noun> | New-AzVM -ResourceGroupName RG1 ... |
Azure CLI commands always start with 'az'. PowerShell uses verb-noun like New-AzVm, Get-AzVm, Set-AzVm. If you see 'az vm restart -g RG1 -n VM1' that is CLI. If you see 'Restart-AzVm' that is PowerShell.
| Mode | What it does |
|---|---|
| Incremental (default) | Adds and updates resources in the template; leaves untouched resources alone |
| Complete | Deletes any resources in the target RG that are NOT in the template |
Always use 'az deployment group what-if' before deploying in Complete mode. It shows you what will be created, deleted, or modified WITHOUT actually doing anything. This prevents accidentally deleting production resources.
az vm create - create a VM
az vm restart -g <rg> -n <name> - restart a VM
az vm start / az vm stop / az vm deallocate
az group create / az group delete
az deployment group create --template-file ...