11.2 Working with Snapshots and Custom Images

Why This Topic Matters

Exam Domain 4 explicitly lists "working with snapshots" and "working with images" as tested sub-topics under managing Compute Engine resources. These two artifacts look similar (both are stored disk data) but serve very different operational purposes, and the exam frequently tests whether you know which one to reach for: backup/recovery of an existing disk's data (snapshot) versus standing up new, identically configured VMs at scale (image). Confusing the two is one of the most common wrong answers on ACE practice exams.

Snapshots: Point-in-Time Disk Backups

A snapshot is an incremental, point-in-time backup of a persistent disk (PD) — zonal or regional. Key properties:

• You can snapshot a disk while it is still attached to a running instance; Compute Engine handles this safely, though for applications sensitive to write-consistency it's best practice to briefly quiesce writes first.
• Snapshots are incremental after the first one: the first snapshot in a chain is a full copy of the disk's blocks; every snapshot after that stores only the blocks that changed since the previous snapshot. This keeps both storage cost and snapshot creation time down for large disks that change slowly.
• Despite being incremental, each snapshot is independently restorable — Compute Engine tracks the underlying block dependency chain for you, so deleting an older snapshot in the middle of a chain does not corrupt or invalidate newer snapshots. This is a frequently-tested trap: candidates assume deleting snapshot #1 breaks snapshot #3's ability to restore, but it does not.
• Two snapshot types exist: standard snapshots (for regular backup/DR) and archive snapshots (cheaper, intended for long-term, infrequently-accessed retention).
• Storage scope can be regional or multi-regional; a regional snapshot (still labeled Preview in some contexts) restricts storage to a specific region for data-residency or cost reasons, while the default multi-region scope maximizes durability and availability.

Creating and Scheduling Snapshots

gcloud compute snapshots create my-snapshot \
  --source-disk=my-disk --source-disk-zone=us-central1-a \
  --snapshot-type=STANDARD

For production workloads, ACE expects you to know that ad hoc gcloud compute snapshots create calls are not the recommended pattern — snapshot schedules (a type of resource policy) are:

gcloud compute resource-policies create snapshot-schedule my-daily-schedule \
  --region=us-central1 \
  --daily-schedule --start-time=03:00 \
  --max-retention-days=14

gcloud compute disks add-resource-policies my-disk \
  --resource-policies=my-daily-schedule --zone=us-central1-a

This attaches a recurring backup cadence directly to the disk, with automatic retention/expiry — the ACE-correct answer whenever a scenario says "automate nightly backups with a defined retention window."

Custom Images: Reusable VM Templates

A custom image is a bootable template used to create new VM instances with a pre-configured OS, patches, and application software already baked in — the "golden image" pattern. Two source paths:

1. From a disk — gcloud compute images create my-image --source-disk=my-disk --source-disk-zone=us-central1-a. Best practice is to stop the source VM first (or at minimum run sudo sync and pause writes) to guarantee a consistent image.
2. From a snapshot — gcloud compute images create my-image --source-snapshot=my-snapshot. This is the common enterprise pattern: take a snapshot as the durable backup artifact, then build a versioned image from it whenever a new golden image release is needed, without touching the running source VM at all.

Image Families and Deprecation States

Google groups related image versions into an image family (e.g., debian-12), so that instance templates can reference --image-family=my-app-image and always resolve to the latest non-deprecated image in that family — a critical pattern for rolling out patched images without editing every template. Each image carries one of four lifecycle states:

Snapshot vs. Image: The Core Distinction

Realistic Exam Scenario

A platform team patches a base OS image monthly and needs every new VM created by an autoscaling managed instance group (MIG) to automatically pick up the latest patched image without editing the instance template each month, while old instances remain untouched. The ACE-correct pattern: publish each monthly build into the same image family, mark the previous month's image DEPRECATED (not OBSOLETE, since already-running instances still reference it), and point the instance template at --image-family=patched-base rather than a specific image version. Combine this with a nightly snapshot schedule on any stateful data disks for independent disaster-recovery coverage — the image protects the VM template, the snapshot protects the data.