{"id":3970,"date":"2026-10-11T18:43:46","date_gmt":"2026-10-11T18:43:46","guid":{"rendered":"https:\/\/www.examtopics.info\/blog\/az-104-availability-zones-vmss\/"},"modified":"2026-10-11T18:47:59","modified_gmt":"2026-10-11T18:47:59","slug":"az-104-availability-zones-vmss","status":"publish","type":"post","link":"https:\/\/www.examtopics.info\/blog\/az-104-availability-zones-vmss\/","title":{"rendered":"AZ-104: Availability Zones, Sets, and VMSS"},"content":{"rendered":"

A VM<\/a> can be fully patched, monitored and backed up but remain unavailable when the host or datacenter it depends on fails. Azure gives administrators several availability tools, and the names can be deceptively similar. An availability set reduces correlated host maintenance and hardware exposure inside a location; an availability zone is a distinct fault-isolated part of a region; Virtual Machine Scale Sets (VMSS) manage fleets of VMs and support scaling and various placement options.<\/p>\n

The AZ-104 exam<\/a> asks more than which box sounds resilient. You need to choose an appropriate topology, understand application dependencies and keep the deployment operable during patches, traffic spikes and a genuine outage. No placement feature makes a single-instance application automatically highly available.<\/p>\n

Map the actual failure the workload must survive<\/h2>\n

Start by asking whether the business requirement concerns one VM’s failure, a rack or hardware incident, a datacenter\/zone outage, or an entire regional disruption. These are different events. A server deployed alone in one zone remains vulnerable to a failure of that zone, even though the region supports zones. A VM in an availability set does not gain zonal isolation automatically.<\/p>\n

For a customer portal requiring continuous service during host updates, multiple instances behind an appropriate traffic distributor are likely more important than a label on one VM. For a financial application requiring survival of a region outage, a multiregion disaster-recovery design goes beyond the ordinary AZ-104 zone\/set choice. Clarify recovery-time and data-loss limits before selecting the availability feature.<\/p>\n

A two-VM web service can survive one machine failing yet remain unavailable during a zonal power event if both machines live in the same zone. State the desired failure boundary first: one host, one rack\/fault domain, one availability zone or an entire region. The choice determines whether an availability set, zone-distributed VMs, zone-aware managed service or cross-region design is relevant. Even three zonal web servers cannot maintain the application if their only database is tied to a failed zone. Inspect the dependencies as well as the compute distribution, and document whether automatic traffic redistribution is actually configured.<\/p>\n

Understand availability sets and fault domains<\/h2>\n

An availability set groups VMs in a way intended to reduce correlated host\/platform failures through fault and update domains. Fault domains represent shared hardware groups; update domains help spread certain maintenance operations. The design is relevant when you control several individual VMs that form one application tier. Azure’s availability guidance increasingly emphasizes flexible scale sets for many new deployments, so recognize the legacy and supported scenarios rather than prescribing sets automatically.<\/p>\n

An availability set does not span separate availability zones<\/a> and does not load-balance traffic on its own. Two web servers can be placed more sensibly yet remain useless if the DNS record still points at only the failed server. Include a suitable frontend, independent disks and health checks. Test removing one instance and verify that the end-user transaction still succeeds.<\/p>\n

Availability sets distribute supported VMs across fault and update domains within a region according to the deployment model. They are useful when a workload needs protection from particular infrastructure maintenance and failures but cannot or need not span zones. They do not promise regional disaster recovery, and placing two VMs in one set is not the same as placing them in two zones. In a legacy environment that already uses an availability set, migrating to zonal deployment can involve rebuilding or changing resource topology. Plan the migration and validation separately from routine VM patching so an availability improvement doesn’t become an unplanned outage.<\/p>\n

Distinguish zonal VMs from zone-spanning services<\/h2>\n

Availability zones are physically separate locations within a supported Azure region, with independent power, networking and cooling boundaries. A zonal VM is pinned to a selected zone. A resilient application might have instances in multiple zones, a compatible zone-aware frontend and replicated state. Not every resource supports every zone or SKU; check regional availability and the architecture of dependent storage and data services.<\/p>\n

For example, placing two application VMs in different zones while using a single-zone database or nonredundant application state can preserve the frontends but still lose the service. Build a dependency map rather than counting VMs. Also account for inter-zone traffic costs and latency where relevant; the right availability choice balances resilience with how the application uses the network.<\/p>\n

Zone support is resource-specific. Before claiming that an application spans zones, check the compute SKUs, storage SKUs, load balancer<\/a> frontend behavior, availability of dependencies and the region’s actual supported zone set. A VM pinned to Zone 1 still fails with that zone; two independently placed VMs can survive a zone loss only if the request path and stateful services are resilient. Availability also has a cost and latency profile. A service that writes synchronously across zones must understand its consistency requirements rather than assume that cross-zone networking has the same characteristics as in-VM memory.<\/p>\n

Use VM scale sets for managed fleets<\/h2>\n

A Virtual Machine Scale Set groups VMs that share an operational model. Administrators can define instance count, image and size, scaling rules, placement and update processes. Different orchestration modes\u2014Flexible and Uniform\u2014have important feature and operational differences. Do not assume that a setup from an older tutorial is the recommended default in the current portal or that all features behave identically across modes.<\/p>\n

When a ticket asks for an additional four identical web workers, hand-creating four VMs is a poor maintenance model. A scale set can make the desired instance count explicit and coordinate management. But images, extensions, network configuration and secrets must still be managed. Centralized deployment can scale a bad configuration just as efficiently as a good one.<\/p>\n

A virtual machine scale set manages a fleet of similarly configured instances, but the application must be capable of running on a changing set of hosts. Put necessary configuration in a reliable deployment mechanism, store durable state outside disposable instances and make health checks meaningful. If one instance is removed, sessions, background work and local temporary files should not silently become unavailable. During a scale-out event, image download, extension execution, network rules and backend registration may delay readiness; a configured minimum instance count does not automatically translate to healthy application capacity.<\/p>\n

Define autoscale from the service, not just CPU<\/h2>\n

Autoscaling rules react to metrics, schedules or supported signals. CPU utilization is useful for some workloads but may not describe queue length, requests in flight or external bottlenecks. Determine the metric that predicts degraded user experience and the minimum\/maximum instance bounds the business can afford. Configure cooldown and safe scaling rates to avoid oscillation when traffic alternates around a threshold.<\/p>\n

A service behind a load balancer also needs reliable health probes. Adding instances that are not yet ready can create a burst of failures, so distinguish instance creation from application readiness. If a scale-out process needs minutes to install dependencies, a scheduled pre-scale or prepared image may be more appropriate than a threshold that triggers only after the service is already saturated.<\/p>\n

Plan rolling updates and drain behavior<\/h2>\n

Updating an image, guest configuration or extension across a fleet creates the same risk as patching every server at once if the release method is careless. Understand the chosen VMSS upgrade policy and orchestrate health-based rollout where supported. For stateful applications, decide how a worker drains ongoing sessions, uploads local changes and announces it is ready to leave the pool.<\/p>\n

A rollback plan should specify a known-good image or deployment state and the signals that would stop rollout. One blue\/green-looking screen does not prove application recovery when the underlying database schema also changed. Capture deployment revision, instance health and application error rate before, during and after maintenance so a rollback decision is based on evidence.<\/p>\n

Consider a security patch that must reach every VMSS instance while maintaining a minimum of two serving backends. A safe process defines upgrade policy, batch size, health checks and an acceptable rollback or replacement path. If the old image stays in a local manual state, newly scaled-out nodes may run different code than existing nodes. Versioned images and documented extension versions make rollouts reproducible. Monitor the load balancer’s actual healthy endpoints while instances change; seeing the scale-set desired count match the actual count does not prove the application can serve requests.<\/p>\n

Diagnose quota, capacity and placement failures<\/h2>\n

A scale set can be correctly defined but fail to reach the requested instance count due to regional vCPU quotas, unsupported sizes, insufficient zonal capacity, image compatibility or networking limits. First identify whether Azure accepted the desired configuration and which instance-level operation failed. Check the actual subscription, region and zone, rather than assuming that an SKU in a blog example exists everywhere.<\/p>\n

If one availability zone lacks capacity, replacing the placement model may require a deliberate design change. Don’t repeatedly retry at production scale without understanding cost and failure consequences. Compare quota-related errors with capacity-related errors and record the fallback that maintains the application\u2019s stated resilience requirement.<\/p>\n

Prove resilience in a controlled AZ-104 lab<\/h2>\n

Deploy a small two-instance application tier using an appropriate availability configuration. Introduce a planned instance stop and confirm that traffic still reaches a healthy instance. Examine load-balancer probes, routing, instance status and the telemetry available during the event. If budget permits, try a scale-set test with a safe instance-count change and watch readiness before declaring scale-out finished.<\/p>\n

Write down what the lab did not prove: a stopped VM is not the same as the loss of a zone, and an application that serves the homepage may fail when writing to shared state. Those limits make the test more credible. AZ-104 rewards recognizing the necessary relationship between placement, traffic distribution, state, operations and recovery.<\/p>\n

A low-cost resilience exercise can use an example topology on paper or a short-lived disposable scale set. Explain which VM disappears when an availability-zone failure is simulated and what frontend or stateful dependency must redirect service. For live labs, induce a reversible failure in one backend and observe the load balancer health probe, traffic distribution and instance replacement without deliberately disabling an entire production zone. Record restoration time and any failed user requests. The result should demonstrate the failure being contained, not just that a VM template listed multiple zones.<\/p>\n","protected":false},"excerpt":{"rendered":"

Understand the failure boundaries, scaling behavior and operational differences among Azure availability zones, sets and VM scale sets.<\/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-3970","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\/3970","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=3970"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3970\/revisions"}],"predecessor-version":[{"id":3996,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3970\/revisions\/3996"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/media?parent=3970"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/categories?post=3970"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/tags?post=3970"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}