What's changed: Created Professional Cloud Database Engineer Chapter 1 (Domain 1 "Design": capacity and HA/DR = workload metrics/perf-cost/zonal-regional-multi-regional/maintenance windows/RTO-RPO-PITR; connectivity/access and DB choice = Cloud SQL Auth Proxy/private IP/CMEK/session poolers/audit, Cloud SQL/AlloyDB (vector/gen AI)/Spanner/Bigtable/Firestore, managed/SQL/NoSQL/vector).
1.1Capacity planning and HA/DR design
Understand database capacity/usage planning from current workload metrics and future requirements, performance/cost tradeoffs, multi-regional/regional/zonal deployment strategies, maintenance windows, and designing high availability and disaster recovery to meet RTO/RPO/PITR.
A Professional Cloud Database Engineer translates business/technical requirements into scalable, resilient, cost-effective databases. Design starts with capacity planning and availability/disaster recovery.
1.1.1Capacity planning and performance/cost
Capacity planning sizes database compute and storage from current workload metrics (CPU/memory/IOPS/connections) and future requirements. Evaluate the performance/cost tradeoff (machine type, storage type) to avoid over- or under-provisioning. Map "size from current + future" and "balance performance against cost."
1.1.2High availability and DR (RTO/RPO/PITR)
Availability comes from placement: zonal (single zone, weak) → regional (multi-zone, tolerates zone failure) → multi-regional (tolerates regional failure). Design DR by RTO (recovery time) and RPO (acceptable data loss), with PITR (point-in-time recovery) to roll back to a specific moment. Set maintenance windows to match availability requirements. Map "tolerate zone failure = regional (HA)" and "recover to a point in time = PITR."
Common: requirement → design. E.g., "DB tolerant to zone failure" = regional (HA); "tolerate regional failure" = multi-regional; "roll back to before a bad change" = PITR; "acceptable data loss/recovery time" = RPO/RTO; "size from current + future" = capacity planning from workload metrics; "fit downtime to availability" = maintenance windows.
Watch the mix-ups: (1) Do not confuse RTO (time), RPO (data loss), and PITR (point-in-time recovery). (2) Availability comes from placement spread (zonal is weak). (3) Size capacity for future requirements, not just current.
1.1.3Section summary
- Capacity planning = size compute/storage from current metrics + future; evaluate performance/cost
- Availability = zonal < regional (HA) < multi-regional
- Design DR by RTO/RPO with PITR; fit maintenance windows to availability
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To make a database resilient to zone failure, which placement best fits?
Q2. To roll back a database to a specific point before a bad change/corruption, which feature?
Q3. Which correctly contrasts RTO and RPO?
Q4. What is the best approach to database capacity planning?
Q5. You need the highest availability tolerating a whole-region failure. Which placement?
Q6. To control planned downtime to match app availability requirements, what do you set?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.