Compute Engine gives you three additional storage options to attach to a VM beyond the boot disk: Persistent Disks, Local SSD, and Filestore. Each one trades durability, performance, and lifecycle differently, and the Professional Cloud Architect exam loves to test whether you can pick the right one from a short scenario. I want to walk through what each of these actually is, where they overlap, and the keyword cues that should fire in your head on exam day.
Persistent Disks are network-attached block storage. The disk types are the same set you can pick for a boot disk, just used here as additional storage for a different purpose.
There are four tiers. Standard is the most cost-effective and fits backups or data with infrequent access. Balanced sits in the middle on performance and cost, and it is the default choice for general workloads like web apps and dev VMs. SSD delivers high performance and low latency, which is what you want for analytics, databases, and high-volume transactions. Extreme is the highest performance tier and is targeted at high-end databases and enterprise workloads where maximum throughput is non-negotiable.
All four types are resizable between 10 GB and 65,536 GB, and resizing does not require detaching the disk or stopping the VM.
On Linux you cannot just expand the disk in the Console and walk away. Resizing the underlying block storage is only the first step. The file system on top of that block storage does not automatically know there is more space available.
The flow is:
gcloud.lsblk on the VM to verify the OS sees the new size.resize2fs to extend the file system into the new space.Skip the third step and the extra capacity sits there unusable. This applies to Linux distributions like Debian.
Once you have picked a disk type, you also choose where it lives. By default, a Persistent Disk is created in the same zone as the VM it is attached to. Same zone, same region, lowest latency, and the cheapest option.
A Zonal Persistent Disk can also be created in a zone that is different from the VM's zone. This is useful if you are pre-staging a disk for a VM in another zone or planning a manual failover. It does not give you automatic failover.
A Regional Persistent Disk is replicated across two zones in the same region. If one zone goes down, the replica in the other zone keeps your data accessible. You pay more for that replication, but you get cross-zone durability and the ability to fail a VM over to the replica.
Zonal disks are the cost-effective default. Regional disks are the answer whenever the workload genuinely needs cross-zone resilience.
Boot disks and attached Persistent Disks have opposite defaults when you delete a VM, and the exam can test whether you know which is which.
Boot disks are deleted by default when the VM is deleted. The auto-delete flag is on. If you want to keep the boot disk around after the VM is gone, you disable auto-delete on it.
Attached Persistent Disks are retained by default. The auto-delete flag is off. If you want them to disappear with the VM, you enable auto-delete on the attached disk.
The defaults make sense once you say them out loud. Boot disks usually carry just the OS, so killing them with the VM is fine. Attached disks usually carry application data, so retaining them by default protects that data.
Local SSD is a different beast from Persistent Disk. It is physically attached to the host machine that runs the VM, not network-attached. That gives you ultra-low latency and high I/O, which is why Local SSD is the right pick for caching layers, scratch space for analytics, or any workload where speed matters and persistence does not.
The catch: Local SSD is ephemeral. The data is tied to the VM's lifecycle. If the VM stops or terminates, the data on the Local SSD is gone. There is no auto-delete toggle because the disk cannot outlive the VM in the first place. There is also no zonal or regional option because Local SSD is bolted to the same host as the VM.
Use it for high-speed temporary storage. Do not use it as the system of record for anything you cannot afford to lose.
This is the pattern that shows up over and over again on the Professional Cloud Architect exam.
If a Compute Engine scenario uses words like high availability, durability, zero downtime, or failover, your reflex should be Regional Persistent Disk.
If the scenario uses words like low latency, high throughput, fast I/O, or high efficiency, your reflex should be SSD. Whether that is SSD Persistent Disk or Local SSD depends on the rest of the scenario, particularly whether the data needs to survive the VM. If the VM already has an SSD attached and the question is about going faster, the answer is usually to increase the size of the existing SSD rather than swap to a new disk type.
That two-bucket mapping resolves a meaningful chunk of the storage questions on this exam.
Filestore is the third additional storage option, and it is structurally different from the other two. It is a managed network file system, POSIX-compliant, that multiple VMs can mount at the same time and read and write to concurrently.
POSIX compliance matters because it means Filestore behaves like a traditional file system. File locking, directories, permissions, and the rest. Applications that expect a normal file system can mount a Filestore share and treat it as if it were local. You do not need to rewrite anything to integrate it.
The use cases are workloads that need shared access across multiple VMs with high I/O, high throughput, and low latency. Collaborative environments, content repositories, and high-performance computing setups all fit. The higher Filestore tiers are tuned for the intensive end of that range.
Filestore is technically network-attached rather than a disk you attach to a single VM, but Google groups it under additional storage for Compute Engine because it is the answer when the requirement is shared file storage across multiple instances.
Persistent Disk is the durable, flexible default. Pick the tier based on cost vs performance, and pick zonal vs regional based on availability requirements.
Local SSD is the speed play when you can tolerate losing the data.
Filestore is the shared-access play when multiple VMs need to read and write the same data through a normal file system interface.
On the Professional Cloud Architect exam, the storage question almost always turns on a single phrase in the scenario. Train yourself to spot that phrase and the answer falls out quickly.
My Professional Cloud Architect course covers Persistent Disks, Local SSD, and Filestore alongside the rest of the compute material.
