# Update domain

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/update-domain

## Quick definition

An update domain is like a group of servers that get updated at the same time. Cloud platforms use update domains to apply patches and updates gradually, so your application stays running while updates happen. This prevents all your servers from going down at once.

## Simple meaning

Imagine you live in a large apartment building with many floors. The building manager needs to repaint the hallways, but if they close all the hallways at once, nobody can get in or out of their apartments. Instead, the manager decides to repaint one floor at a time. While one floor is being painted, residents on that floor have to use the stairs, but everyone else can use the elevators normally. This is exactly how update domains work in the cloud.

In cloud computing, your application runs on many virtual machines or servers. When the cloud provider needs to install security updates or patches, they don't want to reboot all your servers at the same time, because that would make your application unavailable. Instead, they group your servers into update domains. Each update domain is a set of servers that will be updated and rebooted together. The platform updates one update domain at a time, waiting for the servers to come back online and become healthy before moving to the next domain.

The beauty of update domains is that they let you keep your application running even during maintenance. If you have three update domains, at least two of them are always serving traffic while the third is being patched. This is a core part of high availability and fault tolerance in cloud architecture. Without update domains, a routine patch cycle could bring down your entire service, leading to angry users and lost revenue. Understanding update domains helps you design applications that survive maintenance events without breaking a sweat.

## Technical definition

An update domain represents a logical unit of update sequencing within a cloud availability set or fault domain group. In platforms like Microsoft Azure, an availability set contains multiple fault domains and update domains. The update domain concept is explicitly designed to ensure that during planned maintenance events, such as operating system patching or host-level firmware updates, not all virtual machines in a single availability set are rebooted simultaneously.

When you deploy virtual machines into an availability set, Azure automatically assigns each VM to an update domain based on placement logic. By default, an availability set can have up to 20 update domains, though the exact number depends on the deployment region and VM SKU. During a planned maintenance event, the platform reboots VMs one update domain at a time. It waits for the VMs in the first update domain to complete their reboot and report back as healthy before proceeding to the next update domain. This sequential process minimizes application downtime.

In AWS, the equivalent concept is the placement group with a partition strategy, but the functional analogy is seen in Auto Scaling groups and rolling updates. AWS Elastic Load Balancing works with health checks to ensure that instances being updated are taken out of rotation, updated, and then returned to service. However, AWS does not have a direct update domain construct like Azure; instead, it relies on deployment strategies such as rolling updates, blue/green deployments, and canary releases.

In Google Cloud Platform, managed instance groups support rolling updates with a maxSurge and maxUnavailable parameter that effectively implements the same idea: only a certain number of instances are updated at a time. The update domain concept is most formalized in Azure and is a critical exam topic for Azure-specific certifications. The purpose of update domains is to guarantee that the application remains available during platform maintenance. They work in conjunction with fault domains (which protect against hardware failures) to provide comprehensive resilience. Applications must be designed to handle the temporary removal of one update domain without data loss or degraded functionality.

## Real-life example

Think about a car wash with multiple washing lanes. The car wash needs to install new brushes on one of the machines, but if they close down every lane at once, customers will have to wait hours or go to a competitor. So the manager decides to close only one lane at a time for maintenance. While lane 1 is getting new brushes, lanes 2, 3, and 4 are still open for business. Customers wait a little longer, but no one is turned away. Once lane 1 is done and tested, lane 2 is closed for its upgrade, and so on.

Now map this to your cloud application. Each lane is an update domain. The car wash remains open (your application stays up) because at least one lane (domain) is always running. Customers might experience a slight delay as the remaining lanes handle more cars, but they never see a closed sign. Similarly, when an update domain is being patched, your application might be slower because fewer servers are available, but it never goes completely offline.

The car wash also has fire extinguishers and first aid kits for emergencies, just like fault domains protect you from hardware failures. But update domains are specifically for planned maintenance. The smart car wash owner schedules closed-lane maintenance during off-peak hours and only works on one lane at a time. The cloud provider does the same: it performs updates during low-traffic periods and moves through update domains slowly enough to keep your service steady.

## Why it matters

Update domains matter because they keep your application running when the cloud provider needs to perform necessary maintenance. In the real world, operating systems and hypervisors need security patches, firmware updates, and sometimes complete host replacements. Without update domains, every routine patch cycle would force a full application outage. For any business running mission-critical services online, downtime equals lost revenue, damaged reputation, and potential SLA breaches.

In a typical enterprise IT environment, applications must meet stringent uptime requirements-often 99.99% or higher. Update domains are a foundational building block to achieving that high availability. They allow you to patch your infrastructure incrementally without taking the whole thing down. For IT professionals, understanding update domains is essential for designing resilient architectures. If you deploy three virtual machines running a web application all in the same availability set but accidentally assign them all to the same update domain, a single update cycle will reboot all three at once, and your site goes dark.

update domains affect how you plan your deployment. If you have a stateful application that requires all instances to be available during updates, you might need to use a deployment strategy that explicitly handles this, like using separate availability sets or grouping instances differently. Knowing the limits (e.g., maximum 20 update domains in Azure) helps you architect accordingly. For cloud architects and sysadmins, update domains are not just theory; they directly influence how you write deployment scripts, configure load balancers, and test resilience. They are part of the shared responsibility model where the cloud provider ensures the host is patched, but you are responsible for ensuring your application survives the patching.

## Why it matters in exams

Update domains are a core exam objective for Microsoft Azure certifications, particularly the AZ-900 (Azure Fundamentals), AZ-104 (Azure Administrator), and AZ-305 (Azure Solutions Architect). In these exams, questions often test your understanding of availability sets, fault domains, and update domains and how they combine to provide high availability. You might be asked: 'How many update domains are available by default in an Azure availability set?' The answer is 20. Or you might get a scenario: 'You deploy three VMs in an availability set. The platform performs maintenance that updates one update domain at a time. How many VMs will be rebooted at once?' It depends on how they are assigned, but usually one domain at a time.

AWS certifications like the AWS Certified Solutions Architect – Associate also cover this concept under the topic of high availability and fault tolerance, but not using the term 'update domain' explicitly. AWS uses the concept of Availability Zones and Auto Scaling with rolling updates. You might see questions about how to update instances without downtime. The correct answer often involves using an Auto Scaling group with a rolling update policy or a launch configuration that replaces instances gradually.

For CompTIA Cloud+ and Cloud Essentials exams, update domains appear in the context of cloud deployment models and high availability. You might be asked to recommend a configuration that ensures an application remains available during planned maintenance. The correct answer will involve placing resources in different update domains or availability zones. The exam trap is that learners confuse update domains with fault domains. Fault domains protect against hardware failures (like a rack losing power), while update domains protect against planned maintenance. Questions sometimes combine both concepts, and you must distinguish which scenario maps to which concept.

In general IT certification exams that cover cloud concepts, the exam objectives often include 'Describe high availability and fault tolerance' and 'Explain the difference between fault domains and update domains.' The most common question pattern is a multiple-choice scenario where you must choose the best deployment configuration to ensure uptime during a patch cycle. Knowing that update domains allow sequential updates and that you need at least two update domains to avoid downtime is critical.

## How it appears in exam questions

Exam questions on update domains typically fall into three categories: scenario-based, configuration-based, and troubleshooting-based.

Scenario-based questions describe a company that deploys multiple virtual machines in an availability set and asks what happens during planned maintenance. For example: 'A company deploys five VMs in a single availability set. The cloud provider initiates a planned maintenance update. Which of the following best describes the impact on the application?' The correct answer is that VMs are updated one update domain at a time, so the application remains available, albeit with reduced capacity during the update window. A wrong answer might say all VMs are updated simultaneously, or that only one VM is ever updated.

Configuration-based questions ask you to determine the correct number of update domains or fault domains for a given high-availability requirement. For instance: 'You need to deploy a three-tier web application on Azure. You want to ensure that during platform updates, at least two tiers remain fully functional. How many update domains should you configure?' The learner must know that more update domains provide finer granularity, but the default maximum of 20 is more than enough for most scenarios. They might also need to know that update domains are automatically assigned when VMs are placed in an availability set.

Troubleshooting-based questions present an issue: 'After a planned maintenance event, users report that the application was completely unavailable for 10 minutes. The application was deployed with three VMs in one availability set. What is the most likely cause?' The answer is that all VMs were assigned to the same update domain, causing them to reboot simultaneously. The solution is to redeploy the VMs ensuring they are distributed across multiple update domains.

Some questions test the distinction between update domains and fault domains. For example: 'Which type of domain protects against a failure in a shared power source?' That is a fault domain. 'Which type of domain ensures that only a subset of VMs is taken offline during patching?' That is an update domain. Also, questions might combine both: 'An availability set has two fault domains and five update domains. How many VMs can be deployed while maintaining high availability?' The answer is up to 10 VMs, with each fault domain hosting one VM from each update domain.

## Example scenario

A retail company runs an e-commerce website on Azure using four virtual machines. All four VMs host the same web application and are behind a load balancer. The company wants to ensure the website stays up during monthly patching. They deploy all four VMs into a single availability set. Within that availability set, Azure automatically assigns the VMs to two fault domains and five update domains. The first two VMs land in update domain 0, and the other two land in update domain 1.

When the cloud provider performs planned host maintenance, it begins with update domain 0. The two VMs in that domain are rebooted one after the other. The load balancer detects that these two VMs are unhealthy and stops sending traffic to them. The remaining two VMs in update domain 1 handle the full traffic load. The website becomes slower because only half the capacity is available, but it does not go offline. After the two VMs in update domain 0 complete their updates and become healthy again, the load balancer resumes sending traffic to them. Then the platform updates update domain 1, repeating the process.

Had the company deployed all four VMs in the same update domain (which Azure tries to avoid but can happen if not careful), all four would have been rebooted simultaneously, and the website would have been unavailable for the entire duration of the reboot. This example shows why distributing VMs across update domains is crucial for high availability.

## Common mistakes

- **Mistake:** Thinking update domains and fault domains are the same thing.
  - Why it is wrong: Fault domains protect against hardware failures like rack or power failures, while update domains protect against planned maintenance events like patching. They serve different purposes and have different assignments.
  - Fix: Remember: fault domains are for unexpected hardware failures; update domains are for expected software updates.
- **Mistake:** Believing that placing VMs in an availability set automatically guarantees high availability during updates.
  - Why it is wrong: If all VMs end up in the same update domain (which can happen if you deploy them in a single batch and the platform assigns them the same domain), you gain no protection during updates.
  - Fix: Always verify the update domain distribution after deployment. Use multiple deployment batches or configure the placement explicitly if possible.
- **Mistake:** Assuming that update domains are configurable per VM in all cloud platforms.
  - Why it is wrong: Update domains are automatically assigned by Azure when you add VMs to an availability set. You cannot manually assign a VM to a specific update domain in Azure; it is done by the platform based on placement logic.
  - Fix: Understand that you control the distribution indirectly by deploying VMs at different times or using different availability zones.
- **Mistake:** Thinking you need as many update domains as the number of VMs for full protection.
  - Why it is wrong: You only need at least two update domains to ensure that at least one VM stays online during an update. More update domains provide better granularity but are not always necessary.
  - Fix: Design for a minimum of two update domains. More domains reduce the capacity hit during updates, but the application must be stateless or handle the loss of one domain gracefully.

## Exam trap

{"trap":"An exam question describes a scenario where an application experiences downtime during a planned maintenance event. The answer choices include 'fault domain misconfiguration' and 'update domain misconfiguration.'","why_learners_choose_it":"Learners often confuse the two terms and think any downtime is due to fault domain issues. They may not read the question carefully to see that the event is planned maintenance, not a hardware failure.","how_to_avoid_it":"Read the question carefully. If the event is described as 'planned maintenance,' 'patching,' or 'update,' the issue is related to update domains, not fault domains. If the event is described as 'hardware failure,' 'power outage,' or 'rack failure,' then fault domains are relevant."}

## Commonly confused with

- **Update domain vs Fault domain:** Fault domains protect against hardware failures by grouping VMs that share the same power source and network switch. Update domains protect against planned maintenance by grouping VMs that are updated together. Fault domains are about unexpected outages; update domains are about expected maintenance. (Example: If a power cable fails, VMs in the same fault domain all go down. If a patch is applied, VMs in the same update domain all reboot together.)
- **Update domain vs Availability zone:** An availability zone is a physically separate datacenter within an Azure region, offering protection against entire datacenter failures. Update domains operate within a single datacenter. Availability zones provide higher-level resilience but come with higher cost and latency. (Example: Using two availability zones protects you if one datacenter is destroyed. Using two update domains protects you if one rack is patched.)
- **Update domain vs Placement group (AWS):** AWS placement groups with partition strategy are similar to fault domains, not update domains. AWS uses rolling updates in Auto Scaling groups to achieve the same effect as update domains-gradual instance replacement. (Example: In AWS, you set up a rolling update policy to update instances one at a time. That is functionally equivalent to update domains but is not called the same name.)

## Step-by-step breakdown

1. **Create an availability set in Azure** — When you create an availability set, you specify the number of fault domains and update domains. By default, Azure provides 2 fault domains and 5 update domains, but you can configure up to 3 fault domains and 20 update domains.
2. **Deploy virtual machines into the availability set** — As you create new VMs, you assign them to the availability set. Azure's fabric controller automatically distributes the VMs across the available fault and update domains based on placement algorithms. You have no direct control over which update domain a VM gets assigned to.
3. **Azure schedules a planned maintenance event** — The platform's maintenance orchestrator determines that the underlying host hardware needs an update, such as a security patch. It selects one update domain to update first. The orchestrator sends a signal to the VMs in that domain to prepare for a reboot.
4. **VMs in the selected update domain are rebooted** — The VMs in the first update domain are gracefully shut down or rebooted. The load balancer detects that these VMs are no longer responding to health probes and stops sending new traffic to them. Traffic is redirected to VMs in other update domains.
5. **The VMs come back online and are verified healthy** — After the host update is complete, the VMs restart and run through their startup sequence. Once the health probes succeed, the load balancer resumes sending traffic to these VMs. Then the platform moves to the next update domain and repeats the process.

## Practical mini-lesson

For IT professionals, update domains are not just a configuration checkbox; they influence the entire deployment strategy. When you design a production application on Azure, you will typically use availability sets or availability zones. If you choose an availability set, you must think about how many VMs you need and how they will be distributed across update domains.

A common best practice is to deploy at least two VMs per tier in an availability set. If you have only one VM, it will always be rebooted during a maintenance event regardless of update domains. If you have two VMs, there is a risk they could be placed in the same update domain if you create them at the same time. To avoid this, you can stagger the creation of VMs-create one, wait a bit, then create the second. This increases the chance they land in different update domains. Alternatively, you can use managed availability sets in newer Azure Resource Manager deployments, which handle distribution better.

In practice, you also need to consider your application's state. If your application stores session data locally on each VM, a reboot will cause users to lose their sessions. You should use an external session store like Azure Redis Cache or SQL Server to make the application stateless. This way, when one update domain is rebooted, users are redirected to VMs in other domains without data loss.

Another practical consideration is the timing of updates. Azure schedules maintenance events and sends notifications to the Azure portal and via Azure Service Health. You can configure maintenance notifications to be sent to your operations team, allowing you to prepare. For critical applications, you might use Azure Site Recovery to replicate to another region and perform a planned failover before the maintenance window.

What can go wrong? If you deploy a stateful application that cannot handle the temporary loss of a VM, users will experience errors. Also, if your application has long-running transactions, the reboot may abort them. You need to implement retry logic and idempotency in your code. Finally, if you exceed the number of VMs per update domain, performance degradation may become unacceptable because too few VMs remain to handle the load. Always test your application under reduced capacity conditions.

## Memory tip

Update domains are like a rotating schedule: one group updates while the others keep working. Fault domains are like separate tables: each table has its own power and network so a single failure doesn't affect the whole room.

## FAQ

**Can I choose which update domain my VM goes into?**

No, Azure automatically assigns VMs to update domains when you add them to an availability set. The platform distributes them to maximize availability.

**How many update domains are available in an Azure availability set?**

By default, Azure uses 5 update domains, but you can configure up to 20 update domains when creating the availability set.

**Do update domains cost extra?**

No, using availability sets and update domains is free in Azure. You only pay for the virtual machines themselves.

**What happens if all my VMs are in the same update domain?**

During a planned maintenance event, all your VMs will be rebooted simultaneously, causing your application to go down completely.

**Are update domains used in AWS?**

AWS does not have a direct 'update domain' concept. It achieves the same effect through rolling updates in Auto Scaling groups and deployment strategies.

**Can I use update domains with availability zones?**

Yes, you can combine them. Availability zones provide resilience across datacenters, while update domains provide resilience within a zone. Azure allows you to create an availability set within a zone.

## Summary

Update domains are a fundamental concept in cloud high availability. They are logical groups of virtual machines that are updated together during planned maintenance events, ensuring that not all resources go offline at the same time. In Azure, update domains are automatically assigned when you deploy VMs into an availability set, and you can have up to 20 update domains. The key benefit is that your application remains available even when the cloud provider needs to patch the underlying host.

For IT certification exams, understanding the difference between update domains and fault domains is critical. Fault domains protect against hardware failures, while update domains protect against planned maintenance. Questions on Azure fundamentals, Azure administration, and AWS solutions architect often test this distinction. The most common mistake is confusing the two, or assuming that deploying multiple VMs in an availability set alone is enough-you must ensure they are distributed across different update domains.

In practice, update domains influence how you architect your application. You need to design for statelessness, implement health probes, and test under reduced capacity. They are a free but powerful tool that, when used correctly, help you meet stringent uptime SLAs. As you prepare for your certification, remember the memory tip: update domains are a rotating schedule, while fault domains are separate tables. This simple analogy will serve you well in the exam and in real-world cloud management.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/update-domain