This chapter covers Compute Engine snapshots and custom images, two critical features for disk backup, cloning, and image management in Google Cloud. For the ACE exam, questions on snapshots and images appear in roughly 10-15% of the Infrastructure domain (Objective 1.2), often testing snapshot creation, deletion, restoration, and image sharing across projects. Understanding the incremental snapshot mechanism, snapshot retention policies, and custom image creation from snapshots or instances is essential for passing. This chapter provides the precise technical details, default values, and common exam traps you need to master.
Jump to a section
Imagine you are writing a 500-page book on a cloud-based word processor. Each day, you make progress on new chapters. You want to save the state of your entire book at the end of each day so you can revert if you make a mistake later. However, saving a full copy of the entire book every day would consume enormous storage and take a long time. Instead, the word processor uses a technique: the first save stores the complete book (a full snapshot). On subsequent days, it only stores the pages that changed since the last save (incremental snapshots). When you need to restore the book to a specific day's state, the processor reads the full snapshot and then applies only the changes from each incremental snapshot up to that day. This is exactly how Compute Engine snapshots work: the first snapshot is a full disk copy, and subsequent snapshots are incremental, storing only changed blocks. Restoring a disk from a snapshot chain reads the base snapshot and applies all incremental changes in order. Deleting an older snapshot does not destroy the chain because Google Cloud consolidates data: it moves any unique blocks from the deleted snapshot into the next snapshot, ensuring no data loss. This mechanism allows fast, storage-efficient backups and restores, just like your book chapter marks.
What Are Compute Engine Snapshots?
A snapshot is a point-in-time backup of a persistent disk (PD) — either a standard PD, SSD PD, or even a boot disk. Snapshots are stored in Cloud Storage (though not directly accessible as objects) and are global resources, meaning you can use them to create disks in any region or zone. Snapshots are incremental: the first snapshot of a disk is a full copy of all used blocks (not the entire provisioned size), and subsequent snapshots store only blocks that have changed since the last snapshot. This dramatically reduces storage costs and backup time.
How Snapshots Work Internally
When you create a snapshot, Compute Engine performs the following steps: 1. Quiescing: If the disk is attached to a running instance, Google Cloud attempts to quiesce the file system (coordinate with the OS to flush pending writes) to ensure crash consistency. For Linux, it uses fsfreeze; for Windows, VSS. If quiescing fails (e.g., disk I/O overload), the snapshot may still be taken but could be inconsistent. The exam tests that you should stop the instance or at least ensure application-level consistency for critical data. 2. Block-level copy: The snapshot reads only allocated blocks (blocks that have been written to) from the disk. Unallocated blocks are not copied, which is why a 100 GB disk with only 20 GB used produces a ~20 GB snapshot. 3. Incremental delta: The next snapshot compares the current state of the disk with the last snapshot (not necessarily the most recent — it uses a chain). Only blocks that changed are stored as new deltas. The snapshot chain can be thought of as a tree rooted at the first full snapshot. 4. Storage: Snapshots are stored in the multi-regional or regional Cloud Storage bucket associated with the project (you cannot choose the bucket). They are replicated for durability (99.999999999% for multi-regional).
Snapshot Schedules and Retention Policies
You can create snapshot schedules (via the console or the gcloud compute resource-policies create snapshot-schedule command) to automate backups. Schedules can be daily, weekly, or custom intervals. The retention policy specifies how long to keep snapshots — either a maximum number of retained snapshots (e.g., keep the last 7) or a time-based retention (e.g., 30 days). When a snapshot expires, it is automatically deleted. However, deleting a snapshot does not break the chain; Google Cloud consolidates data by promoting unique blocks to the next snapshot in the chain.
Creating Snapshots
Snapshots can be created from:
A persistent disk (attached or unattached)
Another snapshot (creating a copy)
A custom image (but that would be unusual)
Command to create a snapshot:
gcloud compute snapshots create SNAPSHOT_NAME --source-disk=DISK_NAME --source-disk-zone=ZONETo create a snapshot from a disk in a different region (regional PD), you need to specify the region:
gcloud compute snapshots create SNAPSHOT_NAME --source-disk=DISK_NAME --source-disk-region=REGIONRestoring from Snapshots
To restore a snapshot to a new persistent disk, use:
gcloud compute disks create DISK_NAME --source-snapshot=SNAPSHOT_NAME --zone=ZONEYou cannot restore a snapshot to an existing disk directly — you must create a new disk and then attach it. The restored disk is a fully independent copy. You can also use snapshots to create instance templates or custom images.
Custom Images
A custom image is a bootable disk image that you create from a snapshot, an existing disk, or another image. Custom images are global resources and can be used to create instances in any zone. They are commonly used for golden image management: you create a base image with pre-installed software, patches, and configurations, then use it to create multiple instances.
Creating Custom Images
From a snapshot:
gcloud compute images create IMAGE_NAME --source-snapshot=SNAPSHOT_NAMEFrom a disk:
gcloud compute images create IMAGE_NAME --source-disk=DISK_NAME --source-disk-zone=ZONEFrom an existing image (with optional customizations):
gcloud compute images create IMAGE_NAME --source-image=SOURCE_IMAGE --source-image-project=SOURCE_PROJECTYou can also create an image from a virtual disk (VMDK, VHD) imported via Cloud Storage, but that involves the gcloud compute images import command (requires the --source-file flag).
Image Sharing Across Projects
Custom images can be shared across projects by granting the compute.imageUser role to a user or service account in the target project. The image must be in the same organization or you need to set it as public. To make an image public:
gcloud compute images add-iam-policy-binding IMAGE_NAME --member='allAuthenticatedUsers' --role='roles/compute.imageUser'Or for all users (including unauthenticated):
gcloud compute images add-iam-policy-binding IMAGE_NAME --member='allUsers' --role='roles/compute.imageUser'Deprecating and Deleting Images
You can deprecate an image to warn users that it will be deleted. Use:
gcloud compute images deprecate IMAGE_NAME --state=DEPRECATED --replacement=NEW_IMAGEWhen you delete an image, it does not affect instances already created from it. However, you cannot create new instances from a deleted image.
Key Defaults and Limits
Snapshot storage: Snapshots are stored in the same region as the source disk by default (for zonal disks). For regional PDs, snapshots are stored in the same region.
Snapshot chain: Max chain depth? There is no documented hard limit, but best practice is to keep fewer than 50 snapshots in a chain for performance.
Image size: Max 10 TB for a custom image (same as disk limit).
Image family: You can group images into families (e.g., my-webserver-image-family) and create instances from the latest non-deprecated image in the family using --image-family.
Snapshot schedule: Max 1 schedule per disk. You can attach a schedule to multiple disks.
Concurrent snapshots: Max 6 concurrent snapshot creations per project per region.
Interaction with Instance Templates and Managed Instance Groups (MIGs)
Custom images are often used with instance templates. When you update a MIG, you can create a new instance template with a new custom image (e.g., after patching) and perform a rolling update. Snapshots are not directly used with MIGs, but you can create a new image from a snapshot and then update the template.
Exam-Relevant Commands Summary
# List snapshots
gcloud compute snapshots list
# Describe a snapshot
gcloud compute snapshots describe SNAPSHOT_NAME
# Delete a snapshot
gcloud compute snapshots delete SNAPSHOT_NAME
# List images
gcloud compute images list
# Describe an image
gcloud compute images describe IMAGE_NAME
# Delete an image
gcloud compute images delete IMAGE_NAMEHow Snapshots and Images Interact
Snapshots are for backup and recovery; images are for creating bootable disks for new instances.
You can create an image from a snapshot (common for golden images).
You can create a snapshot from a disk that was created from an image.
Deleting a snapshot does not affect images created from it.
Deleting an image does not affect snapshots used to create it.
Storage Costs
Snapshot storage costs are based on the amount of data stored (used blocks) after compression and deduplication. Google Cloud does not charge for the first 10 GB of snapshot storage per project per month (free tier). After that, standard rates apply. Custom image storage is free for the first 10 GB per project (for images you create from your own disks). Public images (from Google, third-party) are free to use but incur egress costs if you export them.
Create a persistent disk
First, create a persistent disk that you want to back up. This disk can be a boot disk or data disk. Use `gcloud compute disks create DISK_NAME --size=100GB --zone=ZONE`. The disk must be in the same project and zone where you plan to attach it. For a boot disk, you typically create an instance with a public image, but you can also create an empty disk and attach it later. The disk size can be up to 257 TB (for standard PD) or 64 TB (for SSD PD). Snapshots only back up allocated blocks, so a large provisioned disk with little data costs less to snapshot.
Attach disk to an instance
Attach the disk to a running or stopped instance. Use `gcloud compute instances attach-disk INSTANCE_NAME --disk=DISK_NAME --zone=ZONE`. The disk can be attached as a boot disk (if it contains an OS) or as a data disk. For snapshots, the disk does not need to be attached; you can snapshot an unattached disk. However, if the disk is attached to a running instance, Compute Engine attempts to quiesce the file system for consistency. If the instance is stopped, the snapshot is consistent by definition. The exam often tests that stopping the instance guarantees crash consistency, while running snapshots may not.
Create the first snapshot
Run `gcloud compute snapshots create SNAPSHOT_NAME --source-disk=DISK_NAME --source-disk-zone=ZONE`. This creates a full snapshot of all used blocks. The snapshot is stored in the same region as the source disk. The command returns immediately, but the snapshot is in `CREATING` state until complete. You can check status with `gcloud compute snapshots describe SNAPSHOT_NAME`. The first snapshot may take a while depending on disk size and I/O. During creation, the disk can still be used, but performance may degrade. The snapshot is crash-consistent if the disk is quiesced; otherwise, it may be file-system-consistent but not application-consistent.
Create incremental snapshots
After the first snapshot, subsequent snapshots are incremental. Run the same command again: `gcloud compute snapshots create SNAPSHOT_NAME_2 --source-disk=DISK_NAME --source-disk-zone=ZONE`. This snapshot stores only blocks that changed since the last snapshot (not necessarily the previous one; it uses the chain). The time to create incremental snapshots is much faster because only deltas are copied. The snapshot chain is maintained automatically. You can have multiple snapshots in a chain; deleting an older snapshot does not break the chain because Google Cloud promotes unique blocks to the next snapshot. The exam may ask about the effect of deleting a snapshot: it does not affect the ability to restore from later snapshots.
Restore a disk from a snapshot
To restore, create a new disk from the snapshot: `gcloud compute disks create NEW_DISK --source-snapshot=SNAPSHOT_NAME --zone=ZONE`. The new disk is an independent copy of the snapshot's data. You can then attach it to an instance. If you want to restore to the same instance, you must detach the old disk, create a new one from the snapshot, and attach it. You cannot overwrite an existing disk with a snapshot. The restored disk has the same size as the source disk at the time of snapshot (provisioned size, not used size). If the snapshot was from a 100 GB disk, the new disk is also 100 GB (unless you specify a larger size). The exam tests that you must create a new disk; you cannot restore to an existing disk.
Create a custom image from a snapshot
To use a snapshot as a golden image, create a custom image: `gcloud compute images create IMAGE_NAME --source-snapshot=SNAPSHOT_NAME`. The image is global and can be used to create instances in any zone. You can also set an image family: `--family=my-family`. Instances can then be created using `--image-family=my-family` to always get the latest non-deprecated image in that family. This is useful for rolling updates. The exam may ask about image families and how they simplify instance creation. Note that images created from snapshots are bootable only if the snapshot was from a boot disk.
Enterprise Scenario 1: Automated Backup Compliance
A financial services company must retain daily backups of all production databases for 90 days to meet regulatory requirements. They attach a snapshot schedule to each persistent disk containing database files. The schedule is configured with a 90-day retention policy (time-based). Each day, a new incremental snapshot is created. After 90 days, the oldest snapshot is automatically deleted. The backup team uses Cloud Monitoring alerts to track snapshot creation failures. They also have a secondary process that exports critical snapshots to a different project for disaster recovery using gcloud compute snapshots export (though export is not a direct command; they use images or disk creation across projects). A common misconfiguration is setting the retention policy to a number of snapshots (e.g., keep last 90) instead of days, which could delete snapshots prematurely if the schedule is paused. In production, they use regional persistent disks for high availability and ensure snapshots are created in the same region to minimize latency. They also test restores quarterly by creating a new disk from a random snapshot and attaching it to a test instance. Performance consideration: during snapshot creation, disk I/O latency can increase by up to 20%, so they schedule snapshots during low-activity windows.
Enterprise Scenario 2: Golden Image Pipeline for CI/CD
A SaaS company uses a CI/CD pipeline to build custom machine images with the latest security patches and application code. Each build creates a new persistent disk from a base image, installs software, runs tests, and then creates a snapshot of the boot disk. The snapshot is then used to create a custom image with a family name like app-server-v1. The pipeline automatically deprecates the previous image in the family. The operations team uses instance templates referencing the image family, and managed instance groups perform rolling updates to deploy the new image. A common pitfall is forgetting to set the --source-disk-zone flag when creating the snapshot, leading to a zone mismatch error. Another issue is image size: if the base image is 50 GB, the custom image is also 50 GB, even if only 10 GB is used. They use the --licenses flag to attach license information for Windows images. The exam often tests that custom images are global, but you cannot create an instance in a different region if the image is stored in a multi-regional location (images are always global, so that's not a constraint). Instead, the constraint is that you must have the compute.imageUser role on the image's project.
Enterprise Scenario 3: Cross-Project Image Sharing for Multi-Tenant SaaS
A managed service provider (MSP) manages multiple Google Cloud projects for different clients. They maintain a single 'golden image' project where custom images are built and hardened. To allow client projects to create instances from these images, they grant the compute.imageUser role to the client project's service account. They also set up a Cloud Function that automatically shares new image versions with all client projects. A common mistake is making the image public to 'allUsers' instead of 'allAuthenticatedUsers', which could expose the image to unauthorized users. The MSP also uses image deprecation to phase out old versions: they set the state to DEPRECATED with a replacement image, and after 30 days, they delete the deprecated image. The exam may test that deprecation does not automatically delete the image; you must delete it separately. They also use the --force-create flag when creating a disk from a snapshot that is in a different project (though this flag is for other operations). In production, they monitor image usage with Cloud Audit Logs to detect unauthorized creation of instances from shared images.
The ACE exam (Objective 1.2) tests snapshots and images in several specific ways. First, you must know that snapshots are incremental and that the first snapshot is a full backup. A common question: 'You have a 100 GB disk with 20 GB used. You take a snapshot. A week later, 5 GB changed. You take another snapshot. How much storage does the second snapshot consume?' The answer is approximately 5 GB (the changed blocks), not 20 GB. Many candidates mistakenly think each snapshot is a full copy, but the incremental nature is key.
Second, the exam tests snapshot consistency. A typical question: 'You need a crash-consistent snapshot of a database disk. What should you do before creating the snapshot?' The correct answer is to stop the instance (or use a pre-snapshot script to freeze the database). The wrong answer often is 'Create the snapshot while the instance is running' — but that only guarantees file-system consistency if quiescing succeeds, not application consistency. The exam expects you to know that stopping the instance ensures crash consistency.
Third, custom image sharing: The exam asks how to allow another project to use your custom image. The correct answer is to grant the compute.imageUser role to the target project's service account. A common trap is granting compute.instanceAdmin or compute.viewer — those do not allow image usage. Also, you can make the image public to 'allAuthenticatedUsers' or 'allUsers', but the exam often tests the principle of least privilege.
Fourth, snapshot deletion and chain integrity: A question might say: 'You have snapshots S1, S2, S3 in a chain. You delete S2. Can you still create a disk from S3?' The answer is yes, because Google Cloud consolidates unique blocks from S2 into S3. Candidates often think the chain is broken, but it is not. However, if you delete S1 (the base snapshot), the chain is still intact because the base snapshot's data is promoted to S2. The only way to break the chain is to delete all snapshots.
Fifth, image families: The exam tests that you can create an instance using --image-family=my-family and that it will use the latest non-deprecated image in that family. A wrong answer might suggest that it uses the most recently created image (including deprecated ones), but deprecated images are excluded.
Sixth, snapshot schedules: The exam may ask about the maximum number of snapshots you can retain per schedule. The answer is 365 (for time-based) or 3650 (for count-based) depending on the schedule type, but the default is 7 for count-based. Know that you can set either a count or a duration, not both.
Finally, the exam tests commands: You should know the exact flags for creating snapshots and images. For example, --source-disk vs --source-snapshot vs --source-image. A common mistake is using --source-disk when creating an image from a snapshot (should be --source-snapshot). Also, know that --source-disk-zone is required if the disk is zonal, and --source-disk-region for regional disks.
To eliminate wrong answers, focus on the underlying mechanism: snapshots are block-level and incremental; images are bootable and global; sharing requires IAM roles; deletion of a snapshot does not break the chain. If an answer says 'snapshots are full copies' or 'deleting a snapshot invalidates later snapshots', eliminate it immediately.
Snapshots are incremental; only the first snapshot is a full copy.
To guarantee crash consistency, stop the instance before snapshotting.
You cannot restore a snapshot to an existing disk; create a new disk instead.
Deleting a snapshot does not break the chain; Google Cloud consolidates data.
Custom images are global and bootable; use them to create instances directly.
Share custom images across projects using the compute.imageUser IAM role.
Image families allow you to always use the latest non-deprecated image.
Snapshot schedules can be daily/weekly with count-based or time-based retention.
The default retention for a snapshot schedule is 7 snapshots (count-based).
Snapshots are stored in a Google-managed Cloud Storage bucket, not directly accessible.
These come up on the exam all the time. Here's how to tell them apart.
Snapshots
Incremental backups; first is full, later are deltas.
Used for backup and restore of persistent disks.
Cannot be used directly to create instances; you must create a disk first.
Stored in regional or multi-regional Cloud Storage (managed by Google).
Can be created from persistent disks or other snapshots.
Custom Images
Full bootable disk images (not incremental).
Used to create new instances directly (via --image).
Global resource; can create instances in any zone.
Stored as Compute Engine images (not directly in Cloud Storage).
Can be created from snapshots, disks, other images, or imported from VMDK/VHD.
Mistake
Each snapshot is a full copy of the disk, so taking many snapshots wastes storage.
Correct
Only the first snapshot is a full copy. Subsequent snapshots are incremental, storing only changed blocks. This saves significant storage space.
Mistake
You can restore a snapshot to an existing disk by overwriting it.
Correct
You cannot overwrite an existing disk with a snapshot. You must create a new disk from the snapshot and then attach it to the instance. The old disk can be detached and deleted if no longer needed.
Mistake
Deleting an older snapshot in a chain breaks all later snapshots.
Correct
Google Cloud automatically consolidates unique blocks from the deleted snapshot into the next snapshot in the chain. Later snapshots remain usable. The chain is only broken if you delete all snapshots.
Mistake
Snapshots are stored in a Cloud Storage bucket you can manage directly.
Correct
Snapshots are stored in Google-managed Cloud Storage buckets that are not directly accessible. You cannot view or download snapshot files via Cloud Storage console or gsutil. You interact with snapshots only through Compute Engine APIs.
Mistake
Custom images can only be created from snapshots.
Correct
Custom images can be created from snapshots, existing disks, other images, or imported from virtual disk files (VMDK, VHD) stored in Cloud Storage. Snapshots are just one source.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can take a snapshot of a disk attached to a running instance. Compute Engine will attempt to quiesce the file system to ensure crash consistency. However, for critical applications (like databases), you should stop the instance or use application-level freezing to guarantee consistency. The snapshot will be file-system-consistent but may not be application-consistent if the application has data in memory not yet flushed to disk.
Grant the `compute.imageUser` role to the target project's service account or user. For example: `gcloud compute images add-iam-policy-binding IMAGE_NAME --member='user:email@example.com' --role='roles/compute.imageUser'`. You can also make the image public to all authenticated users (`allAuthenticatedUsers`) or all users (`allUsers`), but the principle of least privilege recommends using specific IAM grants.
Google Cloud automatically consolidates any unique blocks from the deleted snapshot into the next snapshot in the chain. Later snapshots remain fully usable. The only way to break the chain is to delete all snapshots. This consolidation happens transparently and does not require any action from you.
Yes, you can create an image from any snapshot, but the resulting image will only be bootable if the snapshot was taken from a boot disk (one that contains an operating system). If you create an image from a data disk snapshot, the image will not be bootable and can only be used to create data disks.
A snapshot is a point-in-time backup of a persistent disk, used for backup and restore. It is incremental and stored in a Google-managed Cloud Storage bucket. A custom image is a bootable disk image that can be used to create new instances directly. Images are global and can be created from snapshots, disks, or other images. Snapshots cannot be used to directly create instances; you must first create a disk from the snapshot.
Create a snapshot schedule using `gcloud compute resource-policies create snapshot-schedule SCHEDULE_NAME --max-retention-days=30 --on-source-disk-delete=keep-auto-snapshots --daily-schedule --start-time=02:00`. Then attach it to a disk: `gcloud compute disks add-resource-policies DISK_NAME --resource-policies=SCHEDULE_NAME --zone=ZONE`. The retention policy can be based on number of snapshots (`--max-retention-count`) or days (`--max-retention-days`).
No, you cannot directly export a snapshot to a Cloud Storage bucket. Snapshots are stored in a Google-managed bucket that is not accessible. To export the data, you can create a disk from the snapshot, then attach it to an instance and copy the data to Cloud Storage using gsutil or other tools. Alternatively, you can create an image from the snapshot and export the image to Cloud Storage using `gcloud compute images export`.
You've just covered Compute Engine Snapshots and Custom Images — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?