Managed instance groups in GCP - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
We want to understand how the time to manage instances changes as the number of instances grows.
Specifically, how does adding or updating instances affect the total operations needed?
Analyze the time complexity of creating and updating a managed instance group.
// Create a managed instance group with N instances
resource "google_compute_instance_group_manager" "mig" {
name = "example-mig"
base_instance_name = "example-instance"
instance_template = google_compute_instance_template.template.self_link
target_size = var.instance_count
zone = var.zone
}
// Update the target size to scale instances
resource "google_compute_instance_group_manager" "mig" {
name = "example-mig"
base_instance_name = "example-instance"
instance_template = google_compute_instance_template.template.self_link
target_size = var.new_instance_count
zone = var.zone
}
This sequence creates a group with a set number of instances and later updates the size.
Look at what happens repeatedly when managing instances.
- Primary operation: Creating or deleting individual VM instances.
- How many times: Once per instance in the group (equal to the target size).
Each instance requires a separate create or delete operation, so more instances mean more operations.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | About 10 create/delete calls |
| 100 | About 100 create/delete calls |
| 1000 | About 1000 create/delete calls |
Pattern observation: The number of operations grows directly with the number of instances.
Time Complexity: O(n)
This means the time to manage the group grows linearly with the number of instances.
[X] Wrong: "Adding more instances only takes a fixed amount of time because the group is managed as one unit."
[OK] Correct: Each instance is created or deleted separately, so more instances mean more work and time.
Understanding how instance groups scale helps you design systems that grow smoothly and predict costs.
"What if the managed instance group used autoscaling instead of fixed target size? How would the time complexity change when scaling up or down?"
Practice
Solution
Step 1: Understand the role of Managed Instance Groups
Managed Instance Groups run many copies of the same VM to keep applications reliable and available.Step 2: Compare options with this role
Options describing storage, single VM creation, and permissions are other cloud services, not MIGs.Final Answer:
To run multiple copies of the same virtual machine for reliability -> Option BQuick Check:
MIGs = multiple VM copies for reliability [OK]
- Confusing MIGs with storage services
- Thinking MIGs manage single VMs only
- Mixing up MIGs with user permission management
web-group with 3 instances using the instance template web-template?Solution
Step 1: Identify correct gcloud syntax for managed instance group creation
The correct command uses 'gcloud compute instance-groups managed create' with '--template' and '--size' flags.Step 2: Check each option for syntax correctness
gcloud compute instance-groups managed create web-group --template=web-template --size=3 matches the correct syntax exactly. The other options have incorrect flags or command structure.Final Answer:
gcloud compute instance-groups managed create web-group --template=web-template --size=3 -> Option AQuick Check:
Correct command syntax = gcloud compute instance-groups managed create web-group --template=web-template --size=3 [OK]
- Using 'count' instead of 'size'
- Omitting 'managed' keyword
- Wrong command order or flags
autoscaling:
minNumReplicas: 2
maxNumReplicas: 5
cpuUtilization:
targetUtilization: 0.6What happens when CPU usage rises to 80%?
Solution
Step 1: Understand autoscaling triggers
The target CPU utilization is 60%. When actual CPU usage is 80%, it is above the target.Step 2: Determine autoscaling behavior
Since CPU usage is higher than target, autoscaler adds instances up to maxNumReplicas (5) to reduce load.Final Answer:
The group scales up by adding more instances, up to 5 -> Option CQuick Check:
CPU > target -> scale up [OK]
- Thinking it scales down when CPU is high
- Assuming no change happens
- Confusing min and max replica counts
Solution
Step 1: Identify common update errors
Updating a MIG requires a valid instance template name; missing or wrong name causes errors.Step 2: Evaluate other options
Rolling update policy is optional, zero instances or autoscaling off do not cause update errors.Final Answer:
The instance template name is missing or incorrect -> Option DQuick Check:
Invalid template name -> update error [OK]
- Assuming rolling update policy is mandatory
- Ignoring template name correctness
- Confusing autoscaling with update errors
Solution
Step 1: Understand zero downtime update methods
Rolling updates replace instances gradually, keeping most instances running to avoid downtime.Step 2: Evaluate other options for downtime risk
Deleting all instances or manual stop/start causes downtime; turning off autoscaling is unrelated.Final Answer:
Perform a rolling update with a minimal number of instances unavailable at once -> Option AQuick Check:
Rolling update = zero downtime [OK]
- Deleting all instances at once
- Manual updates causing downtime
- Misunderstanding autoscaling role in updates
