Disaster recovery for Compute Engine is one of those topics where the Professional Cloud Architect exam wants you to understand three things at once: snapshot schedules, regional persistent disks, and geographic redundancy. These are not competing options. They are layers of protection, and the exam often tests whether you know how to combine them rather than which single one is correct.
I want to walk through each of the three, and then explain why you almost always want them working together.
A snapshot schedule policy defines how often snapshots of a persistent disk are taken and how long they are retained. You attach the policy to a disk, and Google Cloud handles the rest. You can manage these policies through the console or with gcloud commands.
This is your primary backup mechanism on Compute Engine. Snapshots are incremental and stored in Cloud Storage, which means they are durable and cost-efficient relative to keeping full disk copies around.
One detail worth remembering for the Professional Cloud Architect exam: custom images cannot be automated through a schedule policy in the same way disk snapshots can. If you need an automated, recurring backup, snapshot schedules are the answer. Images are useful for capturing a known-good state to clone instances from, but they are not the right tool for routine backups.
Regional persistent disks replicate data synchronously across two zones in the same region. If one zone fails, the disk is still available from the other zone, and you can force-attach it to an instance running in the surviving zone.
This gives you high availability and zone-level failover without any application-level work. The replication is handled by the disk itself.
Regional persistent disks are not a backup. If you delete data on the disk, that deletion replicates to both zones immediately. They protect against zone outages, not against data corruption or accidental deletion. That distinction matters on the exam.
The third strategy is to deploy instances themselves across multiple zones or regions. A managed instance group spread across zones in a region protects against zone failure. An application deployed in multiple regions, fronted by a global load balancer, protects against regional failure.
This is where you push beyond zone-level resilience into regional and multi-regional resilience. The disks and snapshots underneath those instances still need their own strategy, but the instances themselves are now distributed.
None of these strategies replace the others. Snapshot schedules give you point-in-time recovery. Regional persistent disks give you zone-level data availability. Geographic redundancy gives you instance availability across zones or regions.
A realistic production architecture uses all three. You schedule snapshots so you can restore to a known-good point if data is corrupted or deleted. You use regional persistent disks for workloads that need to survive a zone outage without manual intervention. You spread your instances across zones or regions so that a single failure does not take the whole application down.
On the Professional Cloud Architect exam, when a scenario asks how to design for disaster recovery on Compute Engine, the answer usually involves more than one of these. If a question lists snapshots alone as a complete DR strategy, that is almost always wrong. Snapshots cover the data, but they do not give you a running instance in another zone or region.
Three things to keep clear in your head:
Snapshot schedules are for automated, retained backups of persistent disks. Images are not.
Regional persistent disks replicate across two zones in one region and are for availability, not backup.
Geographic redundancy of instances is what keeps the application running when a zone or region fails, and it sits on top of the disk strategy you choose.
If you can match those three to the right scenario in a question, you will handle Compute Engine disaster recovery items on the exam without much trouble.
My Professional Cloud Architect course covers Compute Engine disaster recovery alongside the rest of the compute material.
