Persistent Disk Study Notes
Persistent Disk is Google Cloud's durable block storage service for Compute Engine virtual machines, providing boot and data disks that persist independently of the VM lifecycle. Disks can be zonal or regional, use different performance media, and be snapshotted for backup and cloning. Understanding disk types and attachment rules is essential for designing resilient VM deployments.
Key facts
- Persistent Disk volumes are network block devices that remain available if a VM is stopped or deleted, unlike Local SSDs which are physically attached and lose data when the instance stops.
- Disk types include Balanced Persistent Disk, SSD Persistent Disk, Standard Persistent Disk backed by HDD, and Extreme Persistent Disk, trading cost against IOPS and throughput performance.
- Zonal disks reside in a single zone, while regional persistent disks synchronously replicate between two zones in the same region and can be force-attached to a standby VM during a zonal outage.
- Snapshots are incremental, global resources that capture a point-in-time copy of a disk and can be used to create new disks in other zones or regions for migration and backup.
- A boot disk is created automatically with each VM from an image, and additional data disks can be attached, resized online, and detached without deleting the underlying data.
- By default a disk can be attached in read-write mode to only one VM, but multi-writer mode and read-only attachment to multiple VMs are available for specific shared-disk use cases.
- Performance scales with disk size for many types, so increasing provisioned size can raise IOPS and throughput limits even if you do not need the extra capacity immediately.
- Google encrypts persistent disks at rest by default, with options for customer-managed keys through Cloud KMS and customer-supplied keys for additional control.
- Images created from disks or snapshots provide a reusable template for creating many identical VMs, which is different from a snapshot that is primarily a backup artifact.
What the exam expects you to know
- Distinguish Persistent Disk from Local SSD by durability: exam scenarios requiring data to survive VM termination always point to Persistent Disk, not ephemeral local storage.
- Select regional persistent disks when the scenario describes zonal failure tolerance for a single VM workload that maintains a standby instance in another zone.
- Use snapshots for backup, disaster recovery, and moving a disk across zones, and use custom images when repeatedly provisioning identical boot environments.
- Know that disks can be resized while attached and running, but shrinking a persistent disk is not supported, so initial sizing and monitoring matter.
- Recognize shared disk limitations and that most clustered file system needs are better served by Filestore or other managed services rather than multi-writer disks.
- Match performance requirements to disk type, choosing SSD or Extreme for IOPS-sensitive databases and Standard or Balanced for cost-sensitive general workloads.
Persistent Disk vs Local SSD: when to use which
Use Persistent Disk when data must be durable, independently managed, snapshotted, and survive VM deletion or zone maintenance, such as boot disks and database data files. Use Local SSD when you need extremely low latency and very high IOPS for temporary data like caches, scratch space, or replicated workloads where the application itself handles redundancy. The key exam criterion is persistence: if the scenario says data cannot be lost when the instance stops, Local SSD is wrong. If it emphasizes raw local performance and data can be rebuilt, Local SSD becomes the intended answer. See also the Local SSD notes.
Useful gcloud commands
gcloud compute disks create my-disk --size=100GB --zone=us-central1-a --type=pd-balanced
gcloud compute instances attach-disk my-vm --disk=my-disk --zone=us-central1-a
gcloud compute disks snapshot my-disk --snapshot-names=my-snapshot --zone=us-central1-a
gcloud compute disks resize my-disk --size=200GB --zone=us-central1-aCommon exam traps
- Local SSD data is lost when a VM stops, while Persistent Disk data is retained; confusing these two is one of the most common storage traps on the exam.
- You cannot shrink a persistent disk, only increase its size, so exam options proposing an in-place shrink operation should be eliminated immediately.
- A regional disk does not automatically fail over the VM; you still need a standby VM and a force-attach operation during a zonal outage.
- Snapshots are not the same as images, even though both derive from disks; snapshots are incremental backups, images are bootable templates for new instances.
Frequently asked questions
What is the difference between a snapshot and an image?
A snapshot is an incremental, point-in-time backup of a specific persistent disk used for recovery or cloning that disk. An image is a bootable template containing an operating system and configuration used to create new VM boot disks repeatedly. Exams test this distinction when scenarios involve disaster recovery versus standardized provisioning at scale.
When should I use a regional persistent disk?
Use a regional persistent disk when a workload needs protection against a single zone failure and you have a standby VM in another zone in the same region. Data is replicated synchronously between zones, so the standby can force-attach the disk if the primary zone fails. It costs more than a zonal disk but avoids data loss in that scenario.
Can I attach one persistent disk to multiple VMs?
By default a persistent disk in read-write mode attaches to only one VM at a time. You can attach a disk read-only to multiple VMs for shared reference data, and multi-writer mode exists for specialized clustered cases with supported file systems. For general shared file access, the exam usually expects Filestore instead of shared block disks.
Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.