A bootable disk image you create from an existing disk, snapshot, or image, typically used as a golden base with preinstalled software.

A point-in-time, incremental backup of a disk used for backup and recovery, which can be restored into a new disk.

A resource that stores VM configuration (machine type, disks, image, metadata, tags, service account) and is used by managed instance groups.

Managed instance group (MIG)

A group of identical VMs created from an instance template that supports autoscaling, autohealing, and rolling updates.

A point-in-time, incremental backup of a disk used for backup and recovery, which can be restored into a new disk.

A managed instance group where all instances run in a single zone.

What is Custom image?

A bootable disk image you create from an existing disk, snapshot, or image, typically used as a golden base with preinstalled software.

Deploying Compute Engine: Instances, Images, and Instance Groups — Google Cloud Associate Cloud Engineer: Complete Exam-Ready Masterclass

Overview: From Design to Deployed Compute Engine

From Design to Deployment

You now move from cost and network design to actually running VMs on Compute Engine. This module shows how to turn designs into working instances and groups.

What You Will Learn

You will create and configure VMs, build custom images and snapshots, use instance templates and managed instance groups, and automate setup with startup scripts and metadata.

Core Building Blocks

Key terms: instances (VMs), custom images, snapshots, instance templates, and managed instance groups (MIGs). Together, they let you deploy consistent, scalable compute.

Exam Perspective

Associate Cloud Engineer questions often combine cost, networking, and deployment. Expect scenarios like deploying a scalable web tier with autoscaling and load balancing.

Creating Compute Engine Instances (Console and gcloud)

What Is a Compute Engine Instance?

A Compute Engine instance is a VM with CPU, memory, and disks. You choose region, zone, machine type, disks, network, and service account when you create it.

Key Configuration Choices

Decide on region/zone, machine family and type, boot disk image and size, VPC and subnet, external IP, and which service account and IAM roles the VM will use.

Console Creation Flow

In the Console, click Compute Engine → VM instances → Create. Fill in name, location, machine type, boot disk, network, service account, metadata, then click Create.

gcloud Creation Flow

With gcloud, set project and zone, then run `gcloud compute instances create`. Pass flags for machine type, image family, boot disk size, and tags to match your design.

Hands-On: Deploy a Simple Web Server VM

Scenario: Simple Web VM

You will deploy a small Debian VM in us-central1-a, install Apache, and expose port 80. This mirrors a basic web tier used in many exam scenarios.

Console Walkthrough

Create `web-demo-1`, choose E2 micro, Debian 12, and check Allow HTTP traffic. Keep an external IP, create the VM, SSH in, and install Apache with apt.

gcloud Equivalent

Use `gcloud compute instances create web-demo-2` with Debian 12 and `--tags=http-server`. Then add a firewall rule allowing tcp:80 for that tag and install Apache.

What to Observe

Notice how tags link to firewall rules, how image families simplify OS selection, and how Console and gcloud achieve the same result with different workflows.

Custom Images vs Snapshots vs Machine Types

Why Standardize?

To deploy many VMs consistently and recover quickly, you must understand how custom images, snapshots, and machine types differ and when to use each.

Custom Images

Custom images are bootable templates with OS and preinstalled software. They are ideal for golden images that enforce consistent configuration across VMs.

Snapshots

Snapshots are incremental backups of disks. Use them for backup and recovery, not as your long-term golden image strategy for standardized deployments.

Machine Types

Machine types define CPU and RAM only. They do not include OS or software. Choose them to balance performance and cost for your workloads.

Creating Custom Images and Snapshots with gcloud

Use these commands to practice creating snapshots and custom images, then launching VMs from them.

Instance Templates and Managed Instance Groups (MIGs)

What Is an Instance Template?

An instance template is a stored VM configuration: machine type, disks, image, metadata, tags, and service account. It is a blueprint, not a running VM.

What Is a Managed Instance Group?

A MIG is a group of identical VMs created from a template. It supports autoscaling, autohealing, and rolling updates, and can be zonal or regional.

Typical Workflow

Create a golden image, then an instance template, then a MIG from that template. Finally, connect it to a load balancer and configure autoscaling.

Common Exam Traps

Identical VMs with self-healing? Use a managed instance group. Need multi-zone within a region? Use a regional MIG and update it via new templates.

Hands-On: Build a Zonal MIG from a Template

Goal: Zonal Web MIG

You will create an instance template from your golden image, then a zonal managed instance group with three web servers and simple CPU-based autoscaling.

Create the Template

Use `gcloud compute instance-templates create` with your image family, tags, and a startup script that ensures Apache runs when each instance boots.

Create the MIG and Autoscaler

Run `gcloud compute instance-groups managed create` for three instances, then `set-autoscaling` to scale between 2 and 6 VMs at about 60% CPU utilization.

Key Behaviors

The MIG maintains its target size and recreates deleted or unhealthy VMs. You update configuration by creating new templates and rolling out changes.

Startup Scripts and Instance Metadata

What Is Metadata?

Metadata is key-value data for VMs or projects. It can include configuration flags, environment info, and startup scripts that VMs read via the metadata server.

Startup Scripts

Startup scripts are shell scripts that run each time a VM boots. You set them via metadata and use them to install software or configure services automatically.

Precedence and Scope

Project metadata applies to all VMs. Instance metadata overrides project values when keys conflict, letting you customize specific VMs when needed.

Security Notes

Avoid putting secrets in metadata. Use Secret Manager and service accounts for secure access. Treat startup scripts as code that must be maintained and reviewed.

Design Exercise: Choosing Images, Templates, and MIGs

Work through these thought questions before checking the explanations mentally.

Golden image vs startup script

You have a web app that needs Nginx, a specific version of Node.js, and a monitoring agent. Should you bake everything into a custom image, or use a plain OS image plus a long startup script? What trade‑offs do you see for boot time, maintainability, and rollback?

Snapshots vs images for recovery

Your database VM has a 500 GB disk. You want to protect against accidental data deletion and regional disasters. How would you combine snapshots and possibly images? What would you restore from in each scenario?

Zonal vs regional MIG

You are deploying a stateless API behind a global HTTP(S) load balancer. The SLA requires that losing a single zone must not impact availability. Which type of MIG do you choose, and how do you distribute instances?

Autoscaling policy

Your web tier experiences traffic spikes around lunch hour. CPU jumps from 20% to 80% for 20 minutes, then drops. What autoscaling signal and min/max size would you configure? Would you enable a cooldown period?

Metadata strategy

You have 50 VMs in a MIG that all need the same logging configuration, plus 5 special VMs that need extra debug logging. How would you use project metadata, instance metadata, and startup scripts to achieve this without manually editing every VM?

Check Understanding: Instances, Images, and MIG Basics

Answer the question, then read the explanation.

You need to deploy 20 identical stateless web servers that must automatically recreate if an instance becomes unhealthy. Configuration must be consistent and easy to roll out across all servers. Which combination is the BEST fit?

Create 20 individual instances from a public Debian image and manage them with SSH and scripts.
Create a custom image, then a managed instance group based on an instance template that uses this image.
Create a snapshot of one configured instance and manually restore it into new disks for 19 more instances.
Use an unmanaged instance group with instances created from a public image and a long startup script.

Show Answer

Answer: B) Create a custom image, then a managed instance group based on an instance template that uses this image.

A managed instance group plus an instance template using a custom image gives you identical, self-healing VMs and easy rollout of changes. Option A lacks self-healing and consistency management. Option C is manual and error-prone. Option D uses an unmanaged group, which does not support autohealing or autoscaling.

Check Understanding: Snapshots, Metadata, and Autoscaling

Try this scenario-style question.

A team wants to apply the same startup script to all new VMs in a project, but one specific VM needs a different script for testing. What is the simplest solution?

Set the test script in project metadata and the standard script in instance metadata for all other VMs.
Set the standard script in project metadata and the test script in instance metadata for that one VM.
Use only instance metadata and manually copy the standard script to every VM.
Create separate projects: one with the standard script, one with the test script.