{"id":3969,"date":"2026-10-11T18:43:42","date_gmt":"2026-10-11T18:43:42","guid":{"rendered":"https:\/\/www.examtopics.info\/blog\/az-104-vm-sizing-disks-moves\/"},"modified":"2026-10-11T18:47:59","modified_gmt":"2026-10-11T18:47:59","slug":"az-104-vm-sizing-disks-moves","status":"publish","type":"post","link":"https:\/\/www.examtopics.info\/blog\/az-104-vm-sizing-disks-moves\/","title":{"rendered":"Azure VM Disks and Sizes for AZ-104"},"content":{"rendered":"

An Azure virtual machine might look underpowered because of CPU, memory, disk latency or network throughput. Changing the VM size before identifying which resource is constrained can make the monthly bill larger without making the application faster. AZ-104<\/a> asks administrators to deploy and manage VMs as complete operating systems hosted on Azure, including images, sizes, operating-system and data disks, availability, access, backup<\/a> and lifecycle operations.<\/p>\n

The administrator’s job is to connect the workload symptom to a supported Azure configuration and then execute the change safely. That often means looking past the first portal metric and considering the performance and protection characteristics of every attached component.<\/p>\n

Select a VM family by the dominant constraint<\/h2>\n

Azure VM sizes vary in vCPUs, RAM, local storage options, network capacity and supported accelerated networking or disk throughput. General-purpose instances suit many balanced workloads; memory-oriented or compute-oriented families solve different constraints. The exact list of available sizes is regional and can depend on subscription quota or zonal capacity, so never assume a published SKU can be deployed in every region.<\/p>\n

For a line-of-business application with sustained high CPU and comfortable memory headroom, a compute-focused option might help. A caching server that constantly swaps memory needs a different change. Collect guest OS metrics, CPU trends, memory pressure, disk latency and application transaction times before choosing a SKU. Budget for OS licensing, storage, outbound traffic and backups in addition to VM compute.<\/p>\n

A VM with sustained low CPU but long disk queues does not automatically need more vCPUs. Compare CPU utilization, memory pressure, disk IOPS\/throughput, application latency and network demand before choosing a size family. A memory-intensive cache, burstable test server and transaction database may need different resources at the same nominal number of cores. Check the actual regional and zonal SKU availability<\/a>, operating-system support and quota. A performance investigation should produce a specific bottleneck hypothesis and measurable expected outcome; resizing at random can increase cost without changing the limiting resource.<\/p>\n

Understand the OS disk and managed data disks<\/h2>\n

The operating-system disk contains the boot environment; additional managed data disks store application content according to the chosen architecture. Managed disk types have different performance guarantees and provisioning behavior. The disk’s provisioned performance and the VM size’s aggregate limits can both matter, so an expensive disk attached to a constrained VM may fail to deliver the expected throughput.<\/p>\n

Applications should not assume that the temporary\/local disk is durable long-term storage. Contents can be lost in particular host lifecycle events. Place persistent data on supported managed disks or higher-level storage services and validate recovery paths. Keep a record of how disks are mapped in the guest OS; a newly attached disk is not necessarily ready for use until initialized, formatted and mounted appropriately.<\/p>\n

The OS disk holds the guest operating system and configuration; managed data disks can hold application files or databases with their own performance and recovery choices. A temporary\/local disk is not a place to keep irreplaceable data because its persistence guarantees differ from managed durable storage. When a team says ‘we resized and lost files,’ first identify which disk held them and which lifecycle operation occurred. Record disk resource IDs, mount points, encryption settings, caching mode, backup coverage and any host-level ephemeral storage use before performing a move or rebuild. Drive letters alone are weak evidence of durable placement.<\/p>\n

Choose caching and performance settings deliberately<\/h2>\n

Disk caching can reduce latency for suitable workloads but the right setting depends on access patterns and application consistency requirements. A read-heavy workload may benefit from caching; write-sensitive database data may have strict guidance on which cache modes are supported. Do not copy caching settings from a demo VM without considering durability and the application vendor’s advice.<\/p>\n

When troubleshooting disk bottlenecks, compare provisioned IOPS, bandwidth, queue depth and observed latency. A high disk queue with low CPU utilization points toward a different solution from CPU saturation. After adjusting a disk SKU or VM size, repeat the same performance test, at similar load, and verify the workload-level outcome rather than interpreting a new portal value as success.<\/p>\n

Caching changes the performance and consistency tradeoff seen by the guest. Before enabling ReadWrite caching, verify that the application’s write pattern and the disk’s current Azure support matrix permit it. A database with its own ordering assumptions should follow the database and Microsoft disk guidance rather than a generic ‘enable cache for speed’ recommendation. Benchmark with repeatable data and a safe rollback plan, recording latency percentiles and error counts. An IOPS improvement that introduces a data-integrity risk or a failure after restart is not a successful optimization. Treat disk throughput caps at both VM and disk level as separate possible bottlenecks.<\/p>\n

Plan a resize with downtime and capacity in mind<\/h2>\n

Some VM resizes require deallocation, and moving to a new size can depend on whether the underlying cluster supports that option. A stopped-but-allocated VM can still reserve capacity and incur compute charges, whereas a deallocated VM typically stops the compute charge while persistent resources continue to be billed. Distinguish stop within the guest from deallocation in Azure.<\/p>\n

Before resizing a critical VM, check the selected zone, compatible sizes, disk and NIC constraints, subscription vCPU quota and maintenance window. Document backup or snapshot policy and an acceptable fallback size. If capacity is unavailable, blindly repeating the resize may not help; evaluate another supported size or planned relocation after assessing operational impact.<\/p>\n

A proposed resize should document expected service interruption, chosen alternative SKU, quota, cost and rollback. Suppose the preferred size is unavailable in one availability zone during a maintenance window. Check compatible VM families and the capacity reality before moving it; a different zone could change availability objectives, network latency or disk placement requirements. Deallocation can release compute billing but does not erase managed disks, public IP allocations, snapshots or backup storage charges. Demonstrate that difference in a disposable resource group so an operator does not accidentally promise that ‘stopped’ means ‘free’.<\/p>\n

Keep identity and inbound access separate from compute<\/h2>\n

A VM’s ability to reach Key Vault with a managed identity<\/a> is an identity and authorization problem, while an administrator’s SSH or RDP path involves networking, host firewall, identity and security settings. Changing the machine size will not repair an NSG denial or missing data-plane role. Prefer controlled access such as Azure Bastion<\/a> and appropriate identity mechanisms rather than leaving broad public management ports open.<\/p>\n

Make network assumptions explicit when building a new VM: subnet, IP addressing, DNS, security-group rules and outbound connectivity requirements. A VM can be healthy according to the Azure platform while the application is unreachable because its DNS name resolves to an obsolete endpoint. Reproduce connectivity from the actual consumer network before changing security rules.<\/p>\n

Use VM extensions and run commands with control<\/h2>\n

VM extensions and platform run-command features can help configure or diagnose guests, but they execute with powerful privileges and rely on guest-agent health and connectivity to supporting services. A failed extension does not always mean the underlying VM is unavailable; investigate extension status, installation logs and the exact script behavior. Avoid placing secrets in plain text extension settings or support tickets.<\/p>\n

An administrator should be able to rerun a desired-state configuration safely. If an extension partially installs software and then fails, running it again should not create a second conflicting service or overwrite evidence. Define expected outputs and a supported cleanup path. The goal of automation is repeatable administration, not executing arbitrary opaque code from the portal.<\/p>\n

Handle lifecycle operations without losing data<\/h2>\n

Moving a VM between resource groups or subscriptions, where supported, requires checking dependencies and resource-provider constraints. A move may involve disks, NICs and availability-related resources that must be coordinated, and it does not by itself migrate a workload to another geographic region. Some properties cannot be changed in place and call for redeployment or migration.<\/p>\n

For a retirement, stop application traffic, preserve required logs and backups, release DNS and monitoring dependencies and explicitly decide which disks or snapshots to retain. Deleting the VM resource without understanding attached persistent storage can leave unexpected costs or destroy data. Inventory the entire application boundary rather than treating the VM’s resource name as the business service.<\/p>\n

Resource moves and regional migrations are distinct operations. Moving a VM’s Azure resource group membership does not relocate its disks to a second region. Regional migration usually requires a separate supported replication, redeployment or migration design with cutover and data validation. Confirm which dependent objects must be moved together and which cannot move in the same operation. For a VM serving an API, inventory NICs, private IPs, NSG associations, disks, managed identities, DNS records and monitoring before promising a transparent move. A deployment can succeed while clients still reach an old address or role assignment.<\/p>\n

Prove the change with an AZ-104 performance case<\/h2>\n

Start a disposable VM with a supported size and data disk. Capture CPU, available memory, disk operations, latency and guest-level behavior under a repeatable workload. Verify the disk’s type, intended cache mode, backup coverage and OS mount before changing anything. Then resize within a safe allowed configuration and measure whether the application-level response time improved.<\/p>\n

Introduce one deliberate failure, such as a denied management port, a quota limit or a missing data-disk mount, and troubleshoot it using the relevant system layer. A strong AZ-104 administrator can explain why each action addressed the symptom, how the change can be reversed, and what remains billable when the VM is stopped or deallocated.<\/p>\n

Test with a VM whose workload can be recreated. Measure a small file read\/write benchmark and response time, attach a managed disk and verify the guest sees it, then compare a resize change with the original measurements. Use a separate nonproduction deployment for a storage\/cache modification if it would require risky remounting. Capture the actual Azure resource size, guest memory, disk SKU and effective network restrictions. When results are inconclusive, retain the original configuration rather than claiming an improvement based on one noisy sample. The exercise is about evidence-based administration and safe rollback, not producing a larger machine.<\/p>\n","protected":false},"excerpt":{"rendered":"

Choose Azure VM sizes and managed disks, handle resize\/redeployment and diagnose quotas, capacity, caching and storage performance.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,11],"tags":[],"class_list":["post-3969","post","type-post","status-publish","format-standard","hentry","category-certifications","category-cloud-computing"],"_links":{"self":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3969","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/comments?post=3969"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3969\/revisions"}],"predecessor-version":[{"id":3995,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3969\/revisions\/3995"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/media?parent=3969"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/categories?post=3969"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/tags?post=3969"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}