When a Managed Instance Group needs to roll out a new instance template, you have to decide whether existing VMs get touched or whether the change only affects future instances. That decision is the update policy, and on the Professional Cloud Architect exam it usually shows up as a multiple choice between opportunistic and proactive mode.
Both modes exist to minimize risk during software or configuration updates on a MIG. They just take opposite approaches to currently running workloads.
Opportunistic mode applies the new instance template only to new instances. Existing VMs are not restarted, replaced, or modified in any way. If the MIG is running five VMs on Version 1 and you switch the instance template to Version 2 with opportunistic mode, all five Version 1 VMs keep running. The new template kicks in only when the MIG creates a new instance, typically because the autoscaler scaled out, an instance got auto-healed, or you manually resized the group.
The end state of an opportunistic update is usually a mix. You might have four Version 1 VMs and one Version 2 VM running side by side until autoscaling churn eventually replaces the rest. The original instances stay on the old template indefinitely if nothing triggers their replacement.
This makes opportunistic mode the safe choice when you do not want to disturb running workloads. It is non-disruptive by design.
Proactive mode applies the new instance template to existing instances, usually one at a time. Once you change the instance template and select proactive, the MIG actively rolls the update out across the group rather than waiting for new instance creation events.
Two settings control how aggressive the rollout is.
maxSurge is the maximum number of new instances that can be created beyond the current size of the group during the update. maxUnavailable is the maximum number of instances that can be unavailable at any time during the update.
The standard gradual rollout pattern sets maxSurge=1 and maxUnavailable=0. That means one new Version 2 instance gets added to the group without any Version 1 instance being taken offline first. Once the new instance is healthy, an old Version 1 instance is removed. The process repeats one VM at a time until the entire group is on Version 2.
Proactive mode has two subtypes that differ in how they apply the new template to a given VM.
Rolling restart reuses the existing instance and restarts it with the new configuration. The VM keeps its identity but comes back up running the updated template.
Rolling replace deletes the existing instance and creates a new one in its place using the updated template. The replacement VM is a fresh instance.
Both subtypes walk the MIG one (or more) VMs at a time according to maxSurge and maxUnavailable. The difference is whether the update reuses the underlying VM or recreates it from scratch.
The Professional Cloud Architect exam tests this distinction by describing a deployment scenario and asking which update mode satisfies the requirement.
If the prompt says you cannot disrupt running instances, or that existing workloads must keep running unchanged, the answer is opportunistic.
If the prompt says you need to roll the update out across the group with zero downtime, gradually, one instance at a time, the answer is proactive with maxSurge=1 and maxUnavailable=0.
If the question specifies that VMs should be recreated rather than restarted in place, that points to rolling replace. If the prompt says VMs should be reused with their identity intact, that is rolling restart.
My Professional Cloud Architect course covers MIG update modes alongside the rest of the compute material.
