Azure VM Sizing, Disks and Encryption
A VM size is picked from a family, and the family letters tell you what the machine is built for: B for burstable machines that bank credits while idle, D for general purpose, E for memory optimised, F for compute optimised, L for storage optimised and N for GPU workloads. Resizing an existing VM is limited by the hardware cluster it currently sits on, so a size outside that cluster requires the VM to be stopped and deallocated first, which moves it to hardware that supports the target size. Every VM has an OS disk and a temporary disk, and the temporary disk is the trap: it is local to the host, it is not persistent, and its contents are lost on deallocation or host maintenance, so nothing of value belongs on D: in Windows or /dev/sdb1 in Linux. Data disks are managed disks attached separately, and their type sets the performance profile: Standard HDD for backup and infrequent access, Standard SSD for light production, Premium SSD for production workloads, Premium SSD v2 where IOPS and throughput need to be tuned independently of size, and Ultra Disk for the highest demands. Encryption comes in layers. Server-side encryption with platform-managed keys is on by default for every managed disk. A disk encryption set lets you swap in a customer-managed key from Key Vault. Encryption at host encrypts the temporary disk and the caches as well, which ordinary disk encryption leaves untouched. Azure Disk Encryption is the guest-level option using BitLocker or dm-crypt inside the operating system.
Exam tip. Deallocated is not the same as stopped from inside the guest. Shutting a VM down from the operating system leaves it allocated and still billing for compute. Only stopping it in Azure deallocates it, and only deallocation frees the size constraint and stops compute charges.
VM Availability: Sets, Zones and the SLA That Follows
Azure gives you two mechanisms for keeping virtual machines up, and the exam tests the difference through the service level agreement each one earns. An availability set spreads VMs across fault domains and update domains inside a single datacentre. A fault domain is a group of hardware sharing a power source and network switch, so spreading across fault domains survives a rack failure. An update domain is a group that is rebooted together during planned platform maintenance, so spreading across update domains means maintenance never takes every instance at once. Availability zones go further: each zone is a physically separate datacentre inside the region with independent power, cooling and networking, so placing VMs in different zones survives the loss of an entire building. The SLA follows directly. Two or more VMs across availability zones is 99.99 percent. Two or more VMs in an availability set is 99.95 percent. A single VM using premium SSD or ultra disk for all its disks gets 99.9 percent, and a single VM with standard SSD gets 99.5 percent. An availability set must be chosen at VM creation and cannot be added afterward, and a VM cannot be in both an availability set and an availability zone.
Exam tip. Any scenario that mentions surviving a datacentre outage rules out availability sets no matter how many fault domains are configured, because every fault domain is inside the same datacentre.
Virtual Machine Scale Sets and Autoscale
A Virtual Machine Scale Set manages a group of identical VMs as one object, handling creation, patching of the model and scaling. Orchestration mode is the first decision and it cannot be changed later. Uniform orchestration treats instances as interchangeable copies of a single VM model and is optimised for large stateless workloads. Flexible orchestration manages VMs that are individually addressable, can mix sizes, and lets you attach existing standalone VMs, which is why it is now the default choice for most scenarios. Scaling comes in two forms. Manual scaling sets an instance count you change yourself. Autoscale runs rules: a scale out rule watches a metric such as average CPU over a time grain, and when the threshold is breached for the duration you specify it increases the count by an amount, then waits out a cool down period before evaluating again. A matching scale in rule reverses it, and the profile carries a minimum, maximum and default instance count. Scheduled profiles handle predictable load, such as business hours, without waiting for a metric to react. Upgrade policy controls how instances pick up a new model: automatic replaces them without regard for availability, rolling replaces them in batches, and manual leaves it to you.
Exam tip. Autoscale acts on the aggregate of the metric across instances over the duration you set, so a spike shorter than the duration will not trigger anything. If a question says scaling did not happen despite high CPU, look at the duration and the cool down before anything else.
Images, Compute Gallery, ARM Templates and Bicep
Repeatable compute in Azure comes from two directions: standard images and declarative templates. To turn a configured VM into an image you first generalize it, which means running sysprep on Windows or waagent -deprovision+user on Linux to strip machine-specific identity, then capture it. Skipping generalization gives you an image that produces VMs with duplicate identifiers. A standalone managed image is a single object in one region; an Azure Compute Gallery adds versioning, replication to multiple regions, replica counts for scale and sharing across subscriptions and tenants, which is why it is the answer whenever an image must be used by more than one team or region. Templates cover the rest of the estate. An ARM template is JSON with a fixed set of top-level sections: schema, contentVersion, parameters, variables, functions, resources and outputs. Deployment mode decides what happens to resources not in the template: Incremental, the default, leaves them alone, while Complete deletes anything in the resource group that the template does not declare. The what-if operation previews those changes before you commit. Bicep is a cleaner domain specific language that transpiles to exactly the same ARM JSON, supports modules, and can be decompiled from existing templates.
Exam tip. Complete mode deleting resources is a favourite scenario. If a question describes resources vanishing after a template deployment that did not mention them, the cause is Complete mode, and what-if would have shown it in advance.
App Service Plans, Slots and Container Options
An App Service plan is the compute behind one or more web apps: it fixes the region, the operating system, the instance size and the number of instances, and every app on the plan shares that capacity. Scaling up means moving to a larger tier or size; scaling out means more instances of the same size, either manually or with autoscale, which requires Standard or higher. Deployment slots are live staging environments on the same plan, available from Standard upward, and swapping is the point of them: the swap warms the staging instance and then exchanges the routes, giving a deployment with no cold start. What travels in a swap and what stays behind is the detail that gets tested. Content and most app settings travel; publishing endpoints, custom domain names, TLS bindings, scale settings, always on, and any app setting or connection string marked as a deployment slot setting stay with the slot. For containers, Azure Container Instances runs a container group with no orchestration and is the answer for short, simple, isolated workloads, with restart policies of Always, OnFailure or Never. Azure Container Apps adds scaling to zero, revisions and ingress for microservices without exposing Kubernetes. Azure Kubernetes Service gives full Kubernetes, where the system node pool runs the cluster's own components and must use Linux, and user node pools run your workloads and can scale to zero.
Exam tip. When a swap is described as breaking something, look for a setting that should have been marked as a deployment slot setting. Connection strings pointing at a test database are the usual culprit, because unmarked settings follow the content into production.