Managed Instance Groups have a location dimension, and the Professional Cloud Architect exam will test whether you can match that location to the workload. There are two configurations Compute Engine supports directly, zonal and regional, plus a multi-regional pattern you have to assemble yourself.
A zonal MIG operates within a single zone. Every VM the group manages lives in that one location. When you create the MIG, you specify a single zone and you are done.
The trade-off is obvious. If that zone goes down, the MIG goes with it. So zonal MIGs are for workloads that do not need high availability or zonal redundancy. Think low-cost, non-critical applications, test environments, batch jobs that can be re-run, internal tooling.
On the exam, if a question describes a workload as non-critical or cost-sensitive and there is no mention of needing to survive a zone failure, a zonal MIG is the right answer.
A regional MIG distributes its instances across multiple zones within a single region. You can let GCP spread instances across all zones in the region, or you can specify which zones you want. Either way, the group keeps running if one zone fails because the other zones still have instances.
This is the configuration for critical applications where downtime is not acceptable. You get high availability and zonal redundancy out of the box, without having to wire anything together yourself.
For PCA scenarios that mention production traffic, fault tolerance, or surviving a zone outage, regional MIG is the answer. The single region piece matters too. A regional MIG gives you zonal redundancy, not regional redundancy. If the entire region fails, the MIG is unavailable.
Compute Engine does not have a native multi-regional MIG. You cannot create one MIG that spans regions. If a question presents that as an option, it is wrong.
The pattern instead is to deploy separate regional MIGs, one per region you want to cover, and put a global HTTPS load balancer in front of them. The load balancer takes incoming traffic from users worldwide and routes each request to the closest or best-suited regional MIG. Each regional MIG handles its own pool of VMs and gives you zonal redundancy within its region. The global load balancer adds the cross-region piece on top.
This setup fits applications with a geographically dispersed user base that need low latency and high performance. It also gives you regional fault tolerance, because if one region goes down, the load balancer keeps routing to the others.
The decision tree is short. If the workload is non-critical and zone-failure tolerant only because nothing important is running on it, zonal MIG. If the workload is critical and needs to survive a zone failure within one region, regional MIG. If users are spread across the globe or you need to survive a regional failure, separate regional MIGs behind a global HTTPS load balancer.
Watch for distractors that try to hide a regional MIG behind multi-regional language, or that claim Compute Engine has a built-in multi-regional MIG. It does not.
My Professional Cloud Architect course covers MIG location options alongside the rest of the compute material.
