6.2 Managed Instance Groups, Instance Templates & Autoscaling

Google Cloud Associate Cloud Engineer ACE

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the GCP Associate Cloud Engineer Exam 1.2 How to Use This Study Guide & Build a Study Plan

2 Chapter 2: Resource Hierarchy, IAM Basics & Cloud Identity

2.1 The GCP Resource Hierarchy: Organizations, Folders & Projects 2.2 Organization Policies & Granting IAM Roles 2.3 Cloud Identity: Managing Users and Groups

3 Chapter 3: APIs, Quotas & Billing Configuration

3.1 Enabling APIs and Provisioning Cloud Operations Suite 3.2 Assessing and Requesting Quota Increases 3.3 Billing Accounts, Project Linking & Billing Exports 3.4 Billing Budgets and Alerts

4 Chapter 4: Planning Compute & Storage Resources

4.1 Choosing the Right Compute Option: GCE vs. GKE vs. Cloud Run vs. Cloud Functions 4.2 Spot VMs, Custom Machine Types & Cost-Optimized Compute Planning 4.3 Choosing a Data Storage Product: Cloud SQL, BigQuery, Firestore, Spanner & Bigtable 4.4 Cloud Storage Classes & Persistent Disk Types

5 Chapter 5: Planning Network Resources

5.1 Load Balancing Options and Use Cases 5.2 Regional Resource Placement & High Availability Planning 5.3 Network Service Tiers: Premium vs. Standard

6 Chapter 6: Deploying Compute Engine Workloads

6.1 Launching Compute Engine Instances: Disks, SSH Keys & Availability Policies 6.2 Managed Instance Groups, Instance Templates & Autoscaling 6.3 OS Login and VM Manager for Fleet Configuration

7 Chapter 7: Deploying Google Kubernetes Engine Workloads

7.1 Installing and Configuring kubectl 7.2 Deploying GKE Clusters: Autopilot, Regional, Private & GKE Enterprise 7.3 Deploying Containerized Applications to GKE

8 Chapter 8: Deploying Serverless & Event-Driven Applications

8.1 Deploying Applications to Cloud Run and Cloud Functions 8.2 Event-Driven Architectures: Pub/Sub, Cloud Storage Triggers & Eventarc

9 Chapter 9: Deploying Data Solutions

9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB 9.2 Deploying Pub/Sub, Dataflow & Loading Data into Google Cloud

10 Chapter 10: Deploying Networking Resources & Infrastructure as Code

10.1 Creating VPCs, Subnets & Shared VPC 10.2 Firewall Rules, Cloud VPN & VPC Network Peering 10.3 Infrastructure as Code: Terraform, Config Connector, Cloud Foundation Toolkit & Helm

11 Chapter 11: Managing Compute Engine & GKE in Production

11.1 Connecting to and Managing Running Compute Engine Instances 11.2 Working with Snapshots and Custom Images 11.3 Managing GKE Clusters: Node Pools, Workloads & Artifact Registry Access 11.4 Horizontal and Vertical Pod Autoscaling in GKE

12 Chapter 12: Managing Cloud Run, Storage & Database Operations

12.1 Managing Cloud Run Revisions, Traffic Splitting & Scaling 12.2 Managing and Securing Cloud Storage Objects & Lifecycle Policies 12.3 Querying, Estimating Costs, Backup & Job Monitoring for Databases (Cloud SQL, BigQuery, Spanner, Dataflow)

13 Chapter 13: Networking Operations, Monitoring & Logging

13.1 Networking Operations: Subnets, Static IPs, Cloud DNS & Cloud NAT 13.2 Cloud Monitoring: Alerts, Custom Metrics & Dashboards 13.3 Cloud Logging: Buckets, Log Analytics, Routers & Filtering 13.4 Diagnostics, Ops Agent, Managed Service for Prometheus & Audit Logs

14 Chapter 14: IAM Policies & Role Types

14.1 IAM Policies: Structure, Bindings & Policy Hierarchy 14.2 IAM Role Types: Basic, Predefined & Custom Roles

15 Chapter 15: Service Accounts & Security Configuration

15.1 Creating Service Accounts & Assigning Least-Privilege Permissions 15.2 Assigning Service Accounts to Resources & Managing SA IAM Policies 15.3 Service Account Impersonation & Short-Lived Credentials

16 Chapter 16: Exam Readiness — Scenarios & Test-Day Strategy

16.1 Common ACE Exam Scenarios & Decision Frameworks 16.2 Test-Day Logistics, Time Management & Final Review Checklist

6.2 Managed Instance Groups, Instance Templates & Autoscaling

Key Takeaways Explain This Topic AI

Instance templates are immutable -- changing a VM's configuration requires a new template version and a rolling update

Regional MIGs spread instances across zones and survive a single-zone outage; zonal MIGs do not

Autoscaling signals include CPU utilization, load-balancing serving capacity, Cloud Monitoring metrics, schedules, and Pub/Sub queue depth (zonal MIGs only)

When multiple autoscaling signals are configured, the group scales to the largest recommended size across all signals

Predictive autoscaling needs 3 days of CPU history, works only with CPU utilization, and cannot combine with load-balancing signals

Last updated: July 2026

Why This Topic Matters

The exam guide's second Compute Engine bullet is explicit: "Creating an autoscaled managed instance group by using an instance template." This is the standard pattern for running a resilient, horizontally scalable fleet of identical VMs on Google Cloud, and it shows up constantly in ACE scenarios about web tiers, worker fleets, and anything described as needing to "automatically handle traffic spikes" or "survive a zone failure."

Instance Templates: The Blueprint

An instance template is an immutable configuration object that defines everything needed to create a VM: machine type, boot disk image, additional disks, network tags, labels, metadata (including startup scripts), and the service account the instance runs as. Templates can be global (usable by MIGs in any region) or regional (restricted to one region, useful when you reference region-specific resources like a regional disk). Because templates are immutable , you cannot edit one in place -- to change the VM configuration, you create a new template version and roll it out to the group.

Managed Instance Groups (MIGs)

A managed instance group uses an instance template to create and maintain a set of identical VM instances, and is the mechanism GCP uses for both horizontal scaling and self-healing fleets.

MIG Type Scope Resilience Typical Use
Zonal MIG Single zone Fails with the zone Dev/test, workloads tolerant of a zone outage
Regional MIG Spread across zones in a region Survives a single-zone outage Production web/app tiers

For production traffic, regional MIGs are the default recommended choice -- an entire zone can go down and the group keeps serving from the other zones. Within a MIG, instances are normally stateless (any instance can be destroyed and replaced without consequence), but a stateful MIG preserves per-instance configuration -- attached stateful disks, hostname, and specific metadata -- across recreation, which is appropriate for singleton or quasi-stateful services (e.g., a licensed application tied to a specific hostname) that still benefit from autohealing.

Autoscaling Signals

An autoscaling policy can combine multiple signals; when more than one is configured, Compute Engine calculates a recommended group size for each signal and scales to the largest of those recommendations.

Signal How It Works Notes
CPU utilization Default signal added automatically; target is a float in (0, 1] Simplest, works everywhere

Load balancing serving capacity Scales based on how full the backend is relative to the load balancer's configured balancing mode Only for external/internal Application Load Balancers

Cloud Monitoring metric Scales on any custom or built-in metric (e.g., queue depth, requests/sec) Most flexible signal

Schedule-based Scale up/down at specific times; multiple schedules can overlap Good for predictable daily/weekly patterns

Queue-based (Pub/Sub) Scales a zonal MIG based on subscription backlog Zonal MIGs only -- not available on regional MIGs

Predictive autoscaling Forecasts CPU-based load using historical patterns CPU-only signal; requires 3 days of history before it can predict

Predictive autoscaling deserves special attention: it works only with the CPU utilization signal, needs a minimum of 3 days of CPU-based autoscaling history before Compute Engine can generate forecasts, and uses an initialization period (e.g., 300 seconds) to tell the autoscaler how far in advance to scale out so new instances are warm before predicted load arrives. It cannot be combined with the load-balancing-capacity signal.

Health Checks and Autohealing

A MIG can attach a health check so that Compute Engine automatically recreates instances that fail it -- this is autohealing , distinct from the load balancer's own health check (which just routes traffic away from unhealthy backends). An initial delay setting gives a newly created instance time to boot and start serving before autohealing starts evaluating it, preventing a slow-starting app from being caught in a destroy-recreate loop.

Rolling Updates

Because instance templates are immutable, deploying a new application version means creating a new template version and triggering a rolling update on the MIG, controlled by max surge (how many extra instances can be created above the target size during the rollout) and max unavailable (how many instances can be offline at once). Updates can be proactive (Compute Engine actively replaces instances right away) or opportunistic (only replaced when Compute Engine would recreate them anyway, e.g., due to autoscaling or autohealing) -- opportunistic is the lower-risk choice when you want a change to roll out gradually as natural churn happens rather than all at once. The replacement method also matters: RECREATE deletes and recreates the instance (a new VM, new boot disk from the template), while RESTART only reboots existing instances in place, which is only valid when the underlying template change does not require a new VM (for example, a metadata-only change). A MIG can also run a canary update by applying a new template version to only a percentage of the group first, verifying health, and then rolling the rest forward -- the standard answer whenever a scenario asks for a low-risk way to validate a new version before a full fleet rollout.

Cooldown Period

Every autoscaled MIG has a configurable cooldown period (default 60 seconds) during which the autoscaler ignores a newly created instance's metrics -- giving the instance time to initialize and start serving real traffic before it factors into the next scaling decision. Setting the cooldown too short can cause the autoscaler to over-scale in response to a warm-up spike; setting it far longer than the application's actual startup time delays legitimate scale-out reactions.

Worked Scenario

An e-commerce site expects a predictable traffic surge every day at noon and unpredictable spikes during flash sales. The right design: a regional MIG (survives a zone outage) built from an instance template with the current app version baked into the boot disk, an autoscaling policy combining a schedule-based signal for the predictable noon surge and a load-balancing-capacity signal for the unpredictable flash-sale spikes, plus a health check for autohealing. When the team ships a new app version, they publish a new template and run a rolling update with a modest max-surge so capacity never dips during the rollout.