Disasters happen in production environments. VMs crash, disks get corrupted, someone runs the wrong command, an application bug overwrites critical data. Having a backup strategy means the difference between a recoverable incident and a catastrophic data loss. In Compute Engine, the primary backup mechanism for VM disks is snapshots. For the Associate Cloud Engineer exam, you need to understand what snapshots are, how they work, how to automate them, and how they fit into a broader disaster recovery strategy.
A snapshot is a point-in-time copy of a persistent disk attached to a Compute Engine VM. When you take a snapshot, Google Cloud captures the state of the disk at that moment - all the data blocks that make up the disk - and stores the snapshot in Cloud Storage, distributed across multiple locations for durability.
The first snapshot of a disk is a full copy. Every subsequent snapshot is incremental: only the blocks that have changed since the last snapshot are stored. This makes regular snapshots much cheaper in storage costs than maintaining full copies each time. When you need to restore from a snapshot, Google Cloud reassembles the full disk from the most recent incremental snapshot and any prior snapshots it depends on, but from your perspective you are just working with a single snapshot that represents the full disk at that point in time.
You can create a snapshot manually from the Cloud Console or with gcloud:
gcloud compute disks snapshot my-disk --snapshot-names my-disk-backup-$(date +%Y%m%d) --zone us-central1-aManual snapshots are useful for one-off backups before a risky change, but for ongoing backup protection you want automated snapshots on a schedule. Cloud Console lets you create snapshot schedule policies that define how frequently snapshots are taken and how long they are retained.
A snapshot schedule policy specifies a cadence - hourly, daily, or weekly - and a retention period. For example, you might take a daily snapshot and keep the last 14 daily snapshots. After 14 days, older snapshots are automatically deleted. This keeps your backup window at two weeks without the storage cost growing unboundedly.
You attach a snapshot schedule to a disk, not to a VM. This is an important distinction for exam purposes: the schedule applies to the disk resource. If you have a VM with two attached disks, each disk can have its own snapshot schedule.
Restoring from a snapshot means creating a new persistent disk from the snapshot. You do not restore in-place to an existing disk. The recovery process is: create a new disk from the snapshot, then either attach it to the existing VM (replacing the original disk) or create a new VM that uses the new disk.
gcloud compute disks create restored-disk --source-snapshot my-disk-backup-20260501 --zone us-central1-aOnce the restored disk exists, you can attach it to a VM and boot from it. The VM will be in the state it was when the snapshot was taken, which means any data written after the snapshot was taken will not be present on the restored disk.
Snapshots and images are related but different concepts in Compute Engine. A snapshot captures the state of a disk for backup purposes - it is tied to a specific disk's data at a specific time. An image is a broader concept: it is a copy of a disk intended to be used as the base for creating new VMs. Images are typically created from a clean OS installation, customized with your required software, and then used as the operating system image for an instance template.
You can create an image from a snapshot, and you can create a snapshot from a disk that you intend to turn into an image. But they serve different purposes. Snapshots are for backup and recovery. Images are for provisioning new instances with a standard configuration.
By default, snapshots are stored in a multi-regional location that covers the region where the disk lives. For disaster recovery planning, you can store snapshots in a different region to protect against a regional outage. If your VMs run in us-central1 and that region becomes unavailable, having snapshots stored in us-east1 means you can restore your VMs in that region using those snapshots.
This is the key snapshot-related disaster recovery pattern: regular snapshots stored in a different region than the running workload. Recovery point objective (RPO) - how much data you can afford to lose - determines how frequently you need to take snapshots. A daily snapshot gives you an RPO of up to 24 hours of data loss. Hourly snapshots reduce that to an hour.
The Associate Cloud Engineer exam presents snapshot scenarios in backup and recovery contexts. A common scenario: a company needs to back up their Compute Engine VMs automatically and ensure recovery is possible if a disk is corrupted. The correct answer involves creating a snapshot schedule policy and attaching it to the VM's disks.
Another scenario type tests the difference between snapshots and images. A scenario will describe creating a base VM configuration to use as a template for future VMs - this maps to creating a custom image, not a snapshot. If the scenario describes backing up data in a running VM before an OS upgrade, that maps to a snapshot.
The exam also tests the recovery process. If a question asks what you create to restore a VM from a snapshot, the answer is a new persistent disk created from the snapshot, not an in-place restore operation.
My Associate Cloud Engineer course covers Compute Engine backup strategies including snapshot schedules, custom images, and disaster recovery patterns that appear on the Associate Cloud Engineer exam.
