Compute Engine instance

A virtual machine (VM) running on Google Cloud's infrastructure. You configure its machine type, disks, network, service account, metadata, and more.

A predefined or custom combination of vCPUs and memory for a Compute Engine instance, such as e2-medium or n2-standard-4.

Boot disk vs data disk

The boot disk holds the operating system and is required for the VM to start. Data disks are additional persistent disks used to store application and user data.

A point-in-time, incremental backup of a persistent disk that can be used to create or restore disks in any region.

A disk template, usually containing an operating system and optional software, used to create boot disks for new instances or instance templates.

A disk template, typically containing an operating system and software, used to create boot disks for new instances or instance templates.

A Compute Engine virtual machine resource that runs workloads, configured with machine type, disks, network, metadata, and identity.

Key–value configuration data associated with a project or instance, accessible to VMs via the metadata server.

Deploying and Managing Compute Engine Virtual Machines — Google Cloud Associate Cloud Engineer: Complete Exam-Ready Masterclass

Q: Your team wants to back up a VM's data disk nightly and be able to quickly create new disks from these backups in any region. What is the most appropriate feature to use?

Take daily snapshots of the data disk. Snapshots are designed as point-in-time, incremental backups of persistent disks and can be used to create new disks in any region. Custom images are more commonly used for boot disks and templates; resizing boot disks or creating new regional disks nightly is inefficient and not the intended backup mechanism.

Compute Engine Fundamentals in Context

Where Compute Engine Fits

Compute Engine is Google Cloud's flagship IaaS service. An instance is a VM running on Google infrastructure, with choices for machine type, disks, network, and more.

Core Building Blocks

Key parts of a VM: the instance itself, a machine type (vCPU+RAM), a boot disk with an image (OS), optional data disks, and placement in a specific zone and region.

Networking and Identity

Each VM attaches to a VPC network and subnet and usually runs with a service account to access other Google Cloud resources securely.

Exam Connection

These concepts show up under planning, deploying, and operating a cloud solution. You must be comfortable creating and managing VMs in different ways.

Creating a Compute Engine VM in the Console

Naming and Location

In the console: Compute Engine → VM instances → Create. Give a DNS-style name like `web-server-1`, then pick a region and zone that match your subnet and latency needs.

Machine and Boot Disk

Choose a machine family and type (for example, `e2-medium`) then pick a boot disk image and size. Disk type defaults to balanced persistent disk for good general performance.

Identity and Firewall

Attach a service account to let the VM call Google APIs. Optionally tick Allow HTTP/HTTPS to auto-create firewall rules on the VPC for those ports.

Advanced Options

Use advanced settings for metadata and startup scripts, additional disks, networking tweaks, and management options. Then click Create to launch the VM.

Creating VMs with gcloud CLI

For the exam, you must be able to read and reason about `gcloud` commands, even if you do not memorize every flag. Here is a canonical example of creating a simple VM with the CLI.

Key ideas:

`gcloud compute instances create` is the base command.
You specify the zone, machine type, image, network/subnet, and tags.
Startup scripts can be passed with `--metadata-from-file` or `--metadata`.

Study this example and try to visualize each flag as a console field.

```bash

Create a simple web server VM in us-central1-a

PROJECT_ID="my-project"

ZONE="us-central1-a"

gcloud config set project "$PROJECT_ID"

gcloud compute instances create web-server-1 \

--zone="$ZONE" \

--machine-type=e2-medium \

--image-family=debian-12 \

--image-project=debian-cloud \

--boot-disk-size=20GB \

--boot-disk-type=pd-balanced \

--network=default \

--subnet=default \

--tags=http-server \

--metadata=startup-script='#! /bin/bash

apt-get update

apt-get install -y apache2

systemctl enable apache2

systemctl start apache2'

```

Notice how:

`--image-family` and `--image-project` ensure you always get the latest Debian 12 image.
The startup script installs and starts Apache at boot.
The `http-server` tag can be used by firewall rules to allow TCP 80.

In exam scenarios, read each flag and connect it back to the requirement: region/zone, OS, disk size, startup behavior, and network placement.

Disks, Snapshots, and Images

Disk Types Overview

Persistent disks come in standard (HDD), balanced, SSD, and extreme SSD. Default balanced works for most apps; SSD and extreme are for high I/O; standard is cheaper but slower.

Boot vs Data Disks

Every VM has one boot disk and can have multiple data disks. Boot disks hold the OS; data disks hold app data. You can choose whether disks auto-delete with the VM.

Snapshots

Snapshots are point-in-time, incremental backups of disks. They can be used to recreate or clone disks in any region and are stored durably.

Images

Images are templates for boot disks. You can build custom images from a disk or snapshot and reuse them in manual instance creation or instance templates.

Instance Templates and Managed Instance Groups (MIGs)

What Is an Instance Template?

An instance template is a blueprint for VMs: machine type, disks, image, metadata, tags. It is immutable and does not include per-VM details like name or zone.

What Is a Managed Instance Group?

A managed instance group (MIG) creates and manages identical VMs from a template, supporting autoscaling, autohealing, and integration with load balancing.

Zonal vs Regional MIGs

Zonal MIGs live in one zone. Regional MIGs spread instances across zones in a region for higher availability and are preferred for production web tiers.

Exam Clues

If a scenario mentions automatic scaling, replacing unhealthy VMs, or rolling out new versions, think MIGs plus updated instance templates.

Configuring a Regional MIG for Autoscaling and Load Balancing

Step 1: Instance Template

Create a template with Debian, `e2-medium`, 20 GB balanced disk, and a startup script that installs Nginx and deploys your app. Tag instances with `web-mig`.

Step 2: Regional MIG

Create a regional managed instance group using the template. Choose multiple zones, set autoscaling (min 2, max 10, 60% CPU target), and enable autohealing with a health check.

Step 3: HTTP(S) Load Balancer

Configure an external HTTP(S) load balancer with your MIG as the backend and a public frontend IP. Health checks ensure only healthy instances receive traffic.

Reading Exam Scenarios

Phrases like "multi-zone", "automatic scaling", and "single public endpoint" usually point to a regional MIG behind an HTTP(S) load balancer using an instance template.

Startup Scripts and Instance Metadata

Metadata Basics

Each VM can read metadata from a special server. Metadata can be project-wide or per-instance and stores key–value pairs like `env=prod` or config hints.

Startup Scripts

Startup scripts are special metadata keys that run at boot. On Linux, `startup-script` holds a shell script that installs packages or configures the app.

How to Set Scripts

You can set startup scripts in the console, via gcloud metadata flags, or inside an instance template so all MIG VMs run the same boot logic.

Images vs Scripts

Custom images bake changes into the disk for fast boot. Startup scripts apply changes at boot for flexibility. Exams often ask which approach fits speed vs flexibility.

Design Choices: Thought Exercise

Work through these short design prompts. Pause after each and decide what you would use. Then compare with the suggested answer.

You need 50 identical stateless web servers that scale up and down based on CPU load. You want to minimize manual effort.

Your choice?
Suggested: Use a regional managed instance group with an instance template and CPU-based autoscaling, behind an HTTP(S) load balancer.

You have a single legacy app that cannot be horizontally scaled and needs very high disk IOPS for its database.

Your choice?
Suggested: A single Compute Engine instance with a larger SSD or extreme persistent disk. Optionally use a regional disk for higher availability, plus regular snapshots.

You want every VM in a project to know which environment it is in (dev, test, prod), without setting that value on each instance.

Your choice?
Suggested: Set a project-wide metadata key like `environment=dev`. All VMs can read this from the metadata server.

You must ensure that when an instance is deleted, its data disk is preserved, but the boot disk can be discarded.

Your choice?
Suggested: Attach a separate data disk and configure the boot disk to auto-delete with the instance, while disabling auto-delete on the data disk.

You need to roll out a new app version to 100 instances with minimal downtime and the ability to roll back.

Your choice?
Suggested: Create a new instance template with the updated image or startup script and perform a rolling update on the MIG.

Quiz: Core Compute Engine Concepts

Test your understanding of basic VM, disk, and template concepts.

You need to deploy 10 identical web server VMs now and expect to scale to 100 later. You want a repeatable configuration that the autoscaler can use. What should you create first?

A custom image from a running VM and then 10 unmanaged instance groups
An instance template that defines the VM configuration, then a managed instance group
A snapshot of a boot disk and then 10 single VMs created manually from the snapshot
A VPC network with 10 subnets, one for each VM

Show Answer

Answer: B) An instance template that defines the VM configuration, then a managed instance group

A managed instance group requires an instance template that defines machine type, image, metadata, and disks. The MIG can then autoscale from that template. Unmanaged groups do not support autoscaling; snapshots and manual VMs do not give centralized management; multiple subnets are unrelated to scaling identical VMs.

Quiz: Disks, Snapshots, and Startup Scripts

Check your understanding of storage and boot-time configuration.

Your team wants to back up a VM's data disk nightly and be able to quickly create new disks from these backups in any region. What is the most appropriate feature to use?

Create a custom image from the data disk each night
Use instance templates with a larger boot disk
Take daily snapshots of the data disk
Create a new regional persistent disk every night and copy the data