Choosing a Deployment Model Under Data-Residency and Burst Constraints
A regional hospital network runs its patient-records system on 6 physical servers in its own data center. Regulatory rules require that identifiable patient data never leave the country, but the rules permit encrypted backups to be stored abroad. The records system has a steady baseline of 40% CPU utilization and spikes to 95% for 3 hours each weekday during clinic intake. The IT team has 4 engineers, none with container orchestration experience. Leadership wants to reduce capital spend on hardware refresh (due in 14 months) and asks you to recommend a cloud adoption model. They also want a disaster-recovery target of 4-hour RTO and 15-minute RPO.
1. Recommend a cloud deployment model (public, private, hybrid, or community) and justify it against the residency rule, the backup exception, and the team's skill constraints.
Read the worked answer
Recommendation: hybrid.
Reasoning chain:
- Residency rule forbids identifiable patient data from leaving the country, so the system of record must stay in a controlled environment. A fully public deployment of the records database fails this unless the provider offers an in-country region with contractual guarantees - and even then the team must prove data does not replicate out.
- Backup exception explicitly permits encrypted backups abroad. That is the seam where public cloud adds value: cheap, durable object storage for off-site copies satisfies the 15-minute RPO far more reliably than a second on-prem site the hospital cannot afford.
- Burst profile (40% baseline, 95% for 3 hours) means the on-prem hardware is sized for peak and idle most of the day. Moving the stateless front-end and reporting tier to elastic public compute absorbs the spike without buying peak capacity.
- Skill constraint: 4 engineers with no orchestration experience rules out a private-cloud build on Kubernetes. A hybrid that uses managed services (managed database in-country, managed object storage for backups, autoscaling VMs for the web tier) keeps operational burden low.
A private cloud alone does not solve the capital-refresh problem or the burst economics. A community cloud is plausible for shared health-sector services but does not address this system's specific residency boundary. So: keep the database in-country, burst the web tier, and send encrypted backups to public object storage.
2. The team proposes meeting the 4-hour RTO by restoring from the encrypted off-site backups. Evaluate whether this satisfies the RTO and identify what else is required.
Read the worked answer
It probably does not satisfy the 4-hour RTO on its own.
Restore time is not the same as backup frequency. A 15-minute RPO says how much data you can lose; the 4-hour RTO says how fast you must be running again. Restoring a multi-terabyte database from object storage involves: retrieving the objects (network throughput bound), decrypting, replaying transaction logs to the recovery point, re-pointing application configuration, and validating integrity before clinicians can use it. Each step has to be measured, not assumed.
What is required beyond backups:
- A tested restore runbook with measured timings. If a full restore takes 9 hours, the RTO is missed regardless of backup quality.
- Warm standby or pilot-light for the database in a second in-country location, with continuous log shipping, so failover is minutes of promotion rather than hours of bulk restore. This preserves the residency rule because the standby is also in-country.
- DNS/traffic cutover prepared in advance so clients fail over without manual reconfiguration.
- Periodic DR drills - an untested RTO is a hope, not a control.
The exam point: RPO is a backup-design question, RTO is an architecture question. Backups alone rarely meet a tight RTO for a stateful system.