# Managed instance group

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/managed-instance-group

## Quick definition

A managed instance group is a way to run multiple copies of the same virtual machine at once. If one machine fails, the group automatically creates a new one to take its place. It also can automatically add more machines when traffic increases and remove them when traffic decreases. This helps keep applications running smoothly without manual work.

## Simple meaning

Imagine you run a food truck that sells tacos. On a normal day, one truck is enough to serve all your customers. But on festival days, the line gets long and people get frustrated. You could hire more trucks, but that takes time and money, and you might end up with too many trucks after the festival ends. A managed instance group is like having a smart fleet of food trucks that automatically adds more trucks when the crowd grows and sends trucks back to the garage when the crowd leaves. If one truck breaks down, another truck immediately drives out to replace it so your customers never have to wait. Each truck is identical, so no matter which truck serves a customer, they get the same menu and quality. The smart system also checks that each truck is healthy, and if a truck stops working, it is replaced without any human calling the repair shop. In the cloud world, these trucks are virtual machines called instances. They are all created from the same template so they are identical. The group keeps track of how many are needed based on rules you set, like CPU usage or the number of visitors. This automation saves your IT team from manually starting and stopping machines, reduces downtime, and makes sure your application can handle sudden spikes in traffic without crashing.

## Technical definition

A managed instance group (MIG) in Google Cloud Platform is a service that manages a collection of Compute Engine virtual machine instances as a single logical unit. MIGs provide autoscaling, autohealing, regional distribution, and rolling updates. They are built on top of the Compute Engine API and use instance templates to define the configuration for each VM, including machine type, boot disk image, network settings, and startup scripts. When you create a MIG, you specify the instance template, the target size (number of VMs), and optionally an autoscaling policy, health check, and update strategy. The MIG controller, a regional or zonal GCP service, continuously monitors the current number of running instances and compares it with the desired state. If a VM fails a health check (for example, a TCP or HTTP health check probe fails), the controller automatically terminates the unhealthy VM and creates a new one from the template. This autohealing mechanism ensures that the group maintains the target number of healthy instances. Autoscaling works by using metrics such as CPU utilization, HTTP request rate, or Stackdriver Monitoring metrics. The autoscaler calculates the desired size based on a target utilization level and adjusts the group size accordingly. MIGs can be zonal (within a single zone) or regional (spanning multiple zones). Regional MIGs distribute instances across multiple zones to protect against zone failure. Rolling updates allow you to update the instance template without downtime, by gradually replacing instances according to a strategy such as proactive or canary updates. The MIG also integrates with load balancers, so new instances automatically receive traffic from the load balancer's backend. In real IT implementation, MIGs are used to run stateless applications like web servers, APIs, or compute workers that can scale horizontally. They are not designed for stateful workloads like databases unless you attach persistent disks and manage rebooting carefully. The key protocols involved are the Compute Engine API for create/delete operations, health check probes over TCP or HTTP, and monitoring APIs for autoscaling metrics. Key components include the instance template, autoscaler, health check, and the MIG controller itself.

## Real-life example

Think of a managed instance group like a team of bicycle delivery riders for a food delivery app. Each rider has the same uniform, the same insulated bag, and the same route instructions. When the lunch rush begins, orders pile up. Instead of having a manager manually call each rider to come to work, the app's system automatically sends a signal to more riders to start their shift. As the rush ends and orders slow down, the system tells some riders to go home. If a rider gets a flat tire and can't deliver, the system immediately calls a backup rider from the depot to take over the deliveries, so the customer never notices a delay. The riders are all interchangeable, so any order can be assigned to any rider. The system also checks each rider's progress, for example, if a rider hasn't moved in ten minutes, it assumes they are broken down and replaces them. This is exactly how a managed instance group works. The riders are your virtual machines. The app system is the autoscaler and health check. The depot is the instance template that defines how each rider is equipped. The manager never has to think about individual riders, only about the performance of the whole team. And if a whole zone, like a city neighborhood, becomes unavailable due to a power outage, a regional MIG can still serve customers from riders in other neighborhoods. This automatic management of identical resources is the core idea behind managed instance groups.

## Why it matters

In practical IT, managed instance groups matter because they solve the fundamental challenge of keeping applications available and responsive without manual intervention. Imagine you run an e-commerce site. On Black Friday, traffic might spike to 10 times normal. Without a managed instance group, your team would have to manually provision new virtual machines, configure them, attach them to the load balancer, and then later tear them down. This is slow, error-prone, and expensive if you forget to shut them down. A MIG automates this entire cycle, scaling up and down based on real-time demand. This directly reduces operational overhead and the risk of human error. Autohealing means your application stays up even if individual VMs crash due to software bugs or memory leaks. Instead of a pager alert waking your administrator at 3 AM to log in and fix a single server, the MIG handles it silently in seconds. For IT professionals, MIGs also enable rolling updates without downtime. You can deploy a new version of your application by updating the instance template, and the MIG will gradually replace old instances with new ones, checking health after each replacement. This means you can update production software safely and quickly. Regional MIGs provide disaster recovery across zones. If an entire data center goes offline, your application continues running from other zones. This meets high availability requirements without complex manual failover scripts. For cost management, autoscaling ensures you are not paying for idle resources during off-peak hours. The combination of automation, resilience, and cost efficiency makes MIGs a core building block for modern cloud-native applications in production environments.

## Why it matters in exams

Managed instance groups appear in multiple cloud certification exams, especially Google Cloud certifications like Associate Cloud Engineer, Professional Cloud Architect, and Professional DevOps Engineer. For the Associate Cloud Engineer exam, you are expected to understand how to create and manage MIGs, configure autoscaling based on CPU or HTTP load, set up health checks, and perform rolling updates. Typical objective areas include Compute Engine, autoscaling, and load balancing. Questions may ask you to choose the correct autoscaling metric, identify the behavior of a MIG when a VM fails a health check, or select the right instance template configuration. On the Professional Cloud Architect exam, MIGs appear in design scenarios where you need to design a highly available and scalable architecture. You might be asked to compare zonal vs regional MIGs, choose the best update strategy for zero downtime, or integrate MIGs with Cloud Load Balancing and Cloud CDN. Professional DevOps Engineer exam focuses more on CI/CD pipelines and rolling updates, so you might see questions about canary deployments using MIGs, how to monitor autohealing events, or how to roll back a bad deployment. The Google Cloud Digital Leader exam may touch MIGs at a higher level, focusing on the business benefits of autoscaling and high availability. For other IT certifications like AWS Solutions Architect, the equivalent concept is Auto Scaling Groups, and the GCP MIG knowledge helps in comparative questions. In all cases, exam questions often test your understanding of the difference between managed and unmanaged instance groups, the role of instance templates, and the fact that MIGs are for stateless applications. You should also know that you cannot manually add an instance to a managed group, because the group manages its own instances. Expect scenario-based questions where you are given a business requirement (high traffic, fault tolerance, no downtime) and you must choose the MIG configuration that meets it.

## How it appears in exam questions

Managed instance group questions commonly appear in three patterns: scenario selection, configuration details, and troubleshooting scenarios. In scenario selection questions, you are given a business requirement and asked which GCP service to use. For example, a company runs a web application that experiences variable traffic and needs to automatically adjust the number of servers while maintaining high availability. The correct answer is a managed instance group with autoscaling. Distractors might include unmanaged instance groups (which do not autoscale or autoheal), a single VM, or Cloud Functions (which are serverless, not VM based). Configuration detail questions test your knowledge of specific parameters. For instance, you might be asked what happens when a VM in a MIG fails a health check. The correct answer is that the MIG terminates the VM and creates a new one. A common distractor is that the VM is restarted, but autohealing replaces, not restarts. Another configuration question might ask which metric cannot be used for autoscaling. CPU utilization and HTTP request rate are valid, but memory usage is not directly supported by the default autoscaler (though you can use custom metrics). Troubleshooting questions present a situation where a MIG is not scaling properly. For example, an autoscaler is set to target 80% CPU utilization, but even when traffic increases, the CPU never goes above 50%. The reason might be that the application is not CPU-bound, or that the health check is failing so new instances are not receiving traffic. In another troubleshooting scenario, a rolling update causes downtime because the MIG replaces too many instances at once. The fix is to use a more conservative update strategy, like a canary rollout with a small max surge or max unavailable setting. Some questions test regional MIGs and ask what happens if one zone goes down. The answer is that the regional MIG automatically redistributes instances to the other zones to maintain desired size. You might also see comparison questions between zonal and regional MIGs, where you choose the one that provides zone fault tolerance.

## Example scenario

Imagine you work for a company called Petflix that streams videos of cats and dogs. Petflix uses a web server application that runs on Google Cloud. During weekdays, traffic is moderate, with about 10,000 concurrent users. On weekends, traffic jumps to 50,000 concurrent users because people binge-watch pet videos. Petflix has a managed instance group. They create an instance template that specifies a machine type of n1-standard-2, a boot disk with the Ubuntu image, and a startup script that installs the web server and loads the Petflix app. They create a regional managed instance group with a target size of 5 instances spread across three zones in us-central1. They set up an HTTP health check that pings the /health endpoint on port 80. They also configure an autoscaler that targets 70% CPU utilization. During low traffic, the system uses only 3 instances, but the autoscaler keeps it at 5. Actually, they set min size 3, max size 20. On Saturday morning, traffic rises. CPU crosses 70%, so the autoscaler adds more instances, up to 15. Later, an instance in us-central1-a has a software bug that causes it to crash. The health check fails three times, and the MIG controller terminates that instance and creates a new one in the same zone. A user never sees an error because the load balancer only sends traffic to healthy instances. On Monday, traffic drops, and the autoscaler reduces the number of instances back to 3. The entire operation is hands-off for the IT team. They only need to monitor the dashboard to ensure everything is working. This scenario shows how MIGs manage scaling, health, and recovery automatically.

## Common mistakes

- **Mistake:** Thinking a managed instance group can contain VMs with different configurations.
  - Why it is wrong: All instances in a MIG must be created from the same instance template. The whole point is that they are identical and interchangeable. Mixing configurations would break autohealing because a replacement would not match the original.
  - Fix: Always use a single instance template per MIG. If you need different configurations, create separate MIGs for each template.
- **Mistake:** Believing that the autoscaler can scale down to zero instances.
  - Why it is wrong: The autoscaler will not scale a MIG to zero unless you explicitly set a minimum size of zero and your application can handle being completely shut down. By default, the minimum size is 1 or whatever you set. Scaling to zero can cause the application to be unreachable.
  - Fix: Set a minimum size that meets the minimum workload requirement. For most production apps, set minimum to at least 1.
- **Mistake:** Assuming that a managed instance group automatically distributes traffic among instances.
  - Why it is wrong: A MIG does not include a load balancer. It only manages the lifecycle of VMs. You must separately create a load balancer and attach the MIG as a backend.
  - Fix: After creating the MIG, create a load balancer (HTTP or TCP) and set the MIG as the backend service. Traffic will then be distributed.
- **Mistake:** Trying to manually resize a MIG that has autoscaling enabled.
  - Why it is wrong: When autoscaling is enabled, the autoscaler controls the target size. Manually setting a size will be overridden by the autoscaler's next evaluation, causing confusion and potential instability.
  - Fix: Disable autoscaling before manually resizing, or adjust the autoscaling policy parameters (like target CPU) instead.
- **Mistake:** Thinking that autohealing restarts the failed VM.
  - Why it is wrong: Autohealing does not restart the VM. It terminates the unhealthy instance and creates a brand new VM from the instance template. This ensures a clean state rather than potentially repeating the same failure.
  - Fix: Understand that autohealing = replace, not restart. This is a key exam point.

## Exam trap

{"trap":"The exam presents a scenario where a VM in a managed instance group is misconfigured and the health check passes, but the application does not work. The trap answer says to fix the instance template and the MIG will automatically update the existing instances.","why_learners_choose_it":"Learners think that updating the instance template will cause a rolling update, but they forget that the MIG only uses the template for new instances, not existing ones, unless you manually trigger an update.","how_to_avoid_it":"Remember that changing the instance template does not affect running instances. To apply the new template, you must perform a rolling update or a canary update. The MIG will then gradually replace old instances with new ones built from the updated template."}

## Commonly confused with

- **Managed instance group vs Unmanaged instance group:** An unmanaged instance group is a collection of VMs you individually manage. You can add and remove any VMs, even with different configurations. It does not support autoscaling or autohealing. A managed instance group automates everything with identical instances from a template. (Example: If you have a set of VMs with different applications, use an unmanaged group. If you need identical web servers that scale, use a managed group.)
- **Managed instance group vs Instance template:** An instance template is a configuration blueprint that defines the properties of a VM, such as machine type, disk image, and network. A managed instance group uses an instance template to create all its VMs. The template is not the group itself, it is the recipe. (Example: An instance template is like a recipe for a cake. The managed instance group is the bakery that bakes many identical cakes from that recipe.)
- **Managed instance group vs Load balancer:** A load balancer distributes incoming traffic across multiple VMs. A managed instance group does not do this by itself. You must attach a MIG as a backend to a load balancer. The load balancer handles traffic distribution, while the MIG manages the VMs themselves. (Example: Think of the MIG as the team of checkout cashiers, and the load balancer as the line manager who directs customers to the shortest checkout line.)
- **Managed instance group vs Autoscaler:** An autoscaler is a separate resource that attaches to a MIG and adjusts the number of VMs based on metrics. The MIG itself is the group of VMs. The autoscaler is the policy that decides when to grow or shrink the group. (Example: The MIG is the fleet of cars. The autoscaler is the dispatcher who decides how many cars should be on the road based on ride requests.)

## Step-by-step breakdown

1. **Create an instance template** — You define the VM configuration: machine type, boot image, startup script, network tags, and service accounts. This template will be used for every instance in the group, ensuring consistency. If you need to update the application, you create a new template.
2. **Define a health check** — You create a health check probe that checks if the application is working. For web servers, this is often an HTTP GET to a specific endpoint like /health. The health check determines if a VM is considered healthy. If it fails repeatedly, the MIG will replace the VM.
3. **Create the managed instance group** — You specify the instance template, target size (initial number of VMs), and optionally an autoscaling policy and health check. You also choose whether the MIG is zonal (one zone) or regional (multiple zones). The MIG controller immediately starts creating VMs to meet the target size.
4. **Attach a load balancer (optional but recommended)** — To distribute traffic, you create a load balancer and add the MIG as a backend service. The load balancer monitors the health check and only sends traffic to healthy VMs. This step is critical for production applications.
5. **Configure autoscaling (optional)** — You set autoscaling policy such as target CPU utilization, HTTP load balancing utilization, or custom Stackdriver metrics. The autoscaler adjusts the number of VMs to maintain the target. You also set minimum and maximum instance counts to control cost and availability.
6. **Perform rolling updates (as needed)** — When you update the instance template (e.g., to deploy a new application version), you can perform a rolling update. The MIG gradually replaces old instances with new ones. You can control the maximum number of instances that are unavailable during the update to avoid downtime.
7. **Monitor and test** — Use Cloud Monitoring to track instance count, autoscaling events, and health check failures. Test the system by simulating a VM failure or traffic spike. The MIG should autonomously recover and scale as configured.

## Practical mini-lesson

Managed instance groups are a cornerstone of scalable cloud infrastructure, and professionals need to understand several practical aspects. First, you must decide whether to use a zonal or regional MIG. A zonal MIG is simpler and cheaper because it does not worry about multi-zone distribution, but it is vulnerable to a single zone failure. A regional MIG distributes instances across multiple zones, so if one zone goes down, your application still runs. However, regional MIGs may have slightly higher cost due to cross-zone networking. For production systems, always prefer regional MIGs for high availability. Second, your instance template should include a startup script that installs software and configures the application. This ensures that every new VM is ready to serve traffic as soon as it boots. If your application requires persistent state, like a database, MIGs are not ideal because autohealing replaces VMs and you lose local data. In that case, use managed instance groups with stateful disks, but that is an advanced topic. In practice, MIGs are best for stateless applications where any instance can handle any request. Third, autoscaling policies need careful tuning. Setting CPU utilization target too high (e.g., 90%) may cause the system to react too slowly, leading to performance degradation during spikes. Setting it too low (e.g., 30%) may overprovision instances and waste money. A typical starting point is 60-70% CPU for web applications. You should also set cooldown periods to prevent rapid scaling oscillations. Fourth, health check design matters. A health check that only checks that the VM is running (TCP ping) will miss application-level failures. Use an HTTP health check that hits a specific endpoint on your application. That endpoint should verify that the application can actually serve requests, not just that the process is alive. Fifth, rolling updates require planning. The max surge parameter controls how many new instances are created before old ones are deleted. The max unavailable parameter controls how many old instances can be stopped at once. For zero-downtime deployments, set max surge to at least 1 and max unavailable to 0, so old instances are kept until new ones are healthy. Finally, professionals must be aware of MIG limitations: a MIG cannot contain VMs that were created outside the group, and you cannot change the instance template of a running MIG without triggering an update. Also, MIGs do not provide DNS names or static IPs for individual instances; you use the load balancer's IP address for traffic. Common problems include autoscaler not scaling because the health check is misconfigured and all instances are marked unhealthy, causing the autoscaler to think more capacity is not available. Another problem is that the instance template has a startup script that depends on external resources that are not available, causing new instances to fail initialization. Debugging these issues requires checking logs in Cloud Logging and Cloud Monitoring dashboards.

## Memory tip

Managed = M.A.G.I.C: M for MIG, A for Autoscaling, G for Group, I for Identical templates, C for Continuous autohealing.

## FAQ

**Can I add an existing VM to a managed instance group?**

No, you cannot add an existing VM to a managed instance group. The group creates and manages its own VMs from the instance template. If you want a VM to be part of the group, the group must create it.

**What happens if the autoscaler determines more instances are needed but the project has run out of compute quota?**

The autoscaler will attempt to create new instances, but the creation will fail due to quota limits. The group will remain at its current size until quota becomes available or you manually reduce the target size.

**Can I use a managed instance group for a stateful application like a database?**

Generally, no, because autohealing replaces VMs and any local state is lost. However, you can use stateful MIGs that preserve specific disks, but this is an advanced feature and not suitable for most databases that require complex consistency.

**How do I update the application running in a managed instance group?**

Update the instance template with a new boot image or startup script, then perform a rolling update on the MIG. The MIG will gradually replace old instances with new ones using the new template.

**What is the difference between a zonal and regional managed instance group?**

A zonal MIG runs all instances in a single zone within a region. A regional MIG distributes instances across multiple zones in the same region, providing protection against a single zone failure.

**Does a managed instance group include a load balancer?**

No, a MIG does not include a load balancer. You must create a separate load balancer and add the MIG as a backend service to distribute traffic to the instances.

**Can I manually stop an instance in a managed instance group?**

You can stop an instance, but the MIG will detect that the instance is not running and may restart it or replace it, depending on the group configuration. It is better to set the target size lower to reduce the group instead of stopping individual instances.

## Summary

A managed instance group is a powerful Google Cloud service that automates the management of a fleet of identical virtual machines. It handles autoscaling based on load, automatically replaces unhealthy instances through health checks, and supports rolling updates with zero downtime. The core concept is simplicity: define a single instance template, and the group ensures that all VMs are identical and always at the desired count. This makes MIGs ideal for stateless applications like web servers, APIs, and background workers that need to scale up and down with demand. For IT certification exams, particularly Google Cloud exams, MIGs are a central topic. You need to understand the difference between managed and unmanaged groups, the role of instance templates, the autoscaling metrics, and how to configure health checks. Common exam traps include confusing autohealing with restarting, forgetting that a load balancer must be attached separately, and assuming that changing the template updates existing instances. In practice, MIGs save time and reduce errors, but they require careful planning for instance templates, autoscaling policies, and update strategies. The key takeaway for learners is to recognize that managed instance groups are about automation and consistency. Once configured correctly, they provide resilient infrastructure that can handle traffic spikes and recover from failures without human intervention. This is a core principle of cloud-native architecture and a critical skill for infrastructure engineers and cloud architects.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/managed-instance-group