Question 989 of 955
Multi-Region GKE Disaster Recovery: Meeting RPO and RTO Requirements
Your company runs a critical application on Google Kubernetes Engine (GKE) in us-central1. The application consists of a frontend deployment with 3 replicas and a backend statefulset with 5 replicas using persistent volumes (SSD). Recently, the team noticed that during a regional outage in us-central1, the application became completely unavailable. They want to design a multi-region architecture that can survive a regional failure with RPO of 1 hour and RTO of 30 minutes. The application is stateless on the frontend but the backend stores critical data on persistent disks. The backend can operate in a read-only mode from a secondary region if needed. They have a limited budget and want to minimize ongoing costs. Which approach should they take?
Quick Answer
The answer is to deploy the frontend and backend in a regional GKE cluster and use a CronJob to take hourly snapshots of persistent volumes, copying them to a secondary region for disaster recovery. This approach meets the RPO of 1 hour by scheduling incremental snapshots every 60 minutes, while the RTO of 30 minutes is achievable by automating the restoration of those snapshots into a new GKE cluster in the secondary region during a failure. On the Google Professional Cloud Architect exam, this scenario tests your understanding of balancing cost against recovery objectives for stateful workloads, often appearing as a trap where candidates over-engineer with synchronous replication or always-on standby clusters. The key insight is that the backend’s read-only mode in the secondary region allows you to avoid paying for a hot standby, using cheap snapshot storage instead. Memory tip: think “Snap and Ship” — snapshot hourly to hit RPO, ship to secondary for quick restore to hit RTO.
⚠ Common exam trap
Google Cloud often tests the distinction between zonal, regional, and multi-region resilience; the trap here is that candidates may choose regional persistent disks (Option B) thinking they provide multi-region protection, when in fact they only replicate across zones within a single region.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Deploy the frontend and backend in a regional GKE cluster across us-central1, and use a CronJob to take snapshots of persistent volumes every hour and copy them to a secondary region. In disaster, restore the snapshots to a new cluster in the secondary region.
Meets the RPO of 1 hour by using a CronJob to take hourly snapshots of PersistentVolume data and copy them to a secondary region. In a disaster, you restore those snapshots to a new GKE cluster in the secondary region, achieving an RTO of 30 minutes by automating the restore process. This approach minimizes ongoing costs because snapshots are incremental and you only pay for storage in the secondary region when needed, while the frontend remains stateless and can be redeployed quickly.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Migrate the backend to Cloud SQL for MySQL with cross-region replication, and keep the frontend on GKE with multi-region ingress.
Why it's wrong here
The backend is a statefulset, not a relational database; migrating to Cloud SQL would require significant application changes and may not be compatible.
- ✗
Deploy the frontend and backend in a regional GKE cluster and use regional persistent disks for the statefulset, replicating data synchronously across zones.
Why it's wrong here
Regional persistent disks replicate within a region, not across regions; cannot survive a regional outage.
- ✗
Deploy the frontend and backend in a single zonal cluster in us-central1-a, and use scheduled snapshots of persistent disks to a different region.
Why it's wrong here
A single zonal cluster cannot survive a regional failure; the cluster itself is down.
- ✓
Deploy the frontend and backend in a regional GKE cluster across us-central1, and use a CronJob to take snapshots of persistent volumes every hour and copy them to a secondary region. In disaster, restore the snapshots to a new cluster in the secondary region.
Why this is correct
Regional cluster survives zonal failure; snapshots provide cross-region backup with RPO 1 hour and RTO within 30 minutes if restore is automated.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on PCA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Your organization is moving a legacy monolithic application to Google Kubernetes Engine (GKE). The application currently runs on a single virtual machine with a local MySQL database. You need to design a cloud-native architecture that improves scalability and reliability. Which two actions should you take? (Choose TWO.)
medium- A.Deploy the entire application in a single container with a large custom machine type to handle load.
- ✓ B.Refactor the application into microservices and deploy each as a separate deployment in GKE.
- C.Expose the application using a simple Service of type LoadBalancer with round-robin distribution.
- ✓ D.Use Cloud SQL for MySQL instead of running the database in the same cluster.
- E.Use a single Pod with multiple containers that communicate via localhost to reduce latency.
Why B: Refactoring the monolithic application into microservices and deploying each as a separate Deployment in GKE aligns with cloud-native principles, enabling independent scaling, fault isolation, and easier updates. This approach improves scalability and reliability by allowing each microservice to scale horizontally based on demand, and failures in one service do not cascade to others.
Last reviewed: Jun 30, 2026
This PCA practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCA exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.