Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
Operational resilience and resource constraints describe how recovery mandates and cloud limits shape database strategy. Recovery time objective (RTO) is the maximum allowed time before the database is running again after a disaster, while recovery point objective (RPO) is the maximum allowed data loss. Together with quotas and cost policies, RTO and RPO decide whether a design uses regional high availability, multi-region disaster recovery (opens in a new tab), frequent backups, or low-cost standby.
Corporate RTO and RPO mandates are policy requirements that set maximum downtime and data loss for each application tier. Tier 1 applications such as real-time payments often require zero RTO and zero RPO for zone and region outages, while Tier 2 applications such as CRM may allow 15 minutes in a zone and one hour in a region. Tier 3 departmental applications may allow one hour in a zone and 12 hours in a region. Smaller RTO and RPO values increase cost and complexity because they require more replication, more standby capacity, and more frequent backups.
Business-critical recovery must depend only on data plane components that keep processing reads and writes during an outage. The data plane carries live traffic during an outage, while the management plane manages configuration state and pushes configuration to the control plane and data plane. A design that needs a VM-creation API or an IAM permission update during failover will miss its RTO because those management operations may be unavailable. A complete disaster recovery planning (opens in a new tab) design explicitly answers:
High availability (HA) and disaster recovery (DR) are different strategies for different outage scopes and replication models. HA handles a zone outage inside one region with automatic failover, while DR handles a region outage that affects multiple zones with planned failover steps. Spanner and other managed multi-regional services can provide active-active topologies, while regional and zonal resources require customer-designed failover.
| Strategy | Outage scope | Replication model | Recovery expectation |
|---|---|---|---|
| High availability (HA) | Zone outage within one region | Synchronous replication between zones in the same region | Zero or near-zero RTO and RPO with automatic failover |
| Disaster recovery (DR) | Region outage affecting multiple zones | Typically asynchronous replication between regions or to multi-regional storage | Higher RTO and RPO with manual or semi-automated failover |
HA relies on regional resources that automatically serve from another zone when one backing zone is interrupted. DR across regions requires an explicit replication strategy when regional resources are used, including replication to a secondary region, to Cloud Storage, or to a hybrid option. Multi-regional resources resist region outages but trade off latency, consistency, and cost, because synchronous replication avoids data loss with higher latency while asynchronous replication lowers latency with risk of data loss.
Aggregate availability further limits resilience because chained tiers multiply. The aggregate availability of a chained stack equals tier1_availability × tier2_availability × tierN_availability, so four tiers at 99.9% yield only about 99.6%. Parallel services follow 1 − (1 − A) × (1 − B), so two 99% services in parallel yield 99.99%. Dependencies should therefore exceed the application target, and parallelization should be preferred over chaining where feasible. This focus on reliability (opens in a new tab) explains why extra nines require both design and budget.
Exam tip: HA supports zero or near-zero RTO and RPO with synchronous replication inside one region, while DR across regions typically uses asynchronous replication and requires planned failover with higher RTO and RPO.
Backup lifecycle management is the control of backup frequency and retention to meet RPO within storage and transfer budgets. Backup frequency sets the data-loss window, because a 24-hour interval can lose almost 24 hours of updates if failure occurs just before the next backup. Backup retention sets how far back recovery can go, which protects against logical errors such as corruption or bad writes by allowing restore to a point before the error.
Cloud Storage tiering, Compute Engine snapshots, and managed database features implement this lifecycle with different cost tradeoffs. Transfer jobs and snapshot schedules must run at least as often as the RPO requires, such as daily transfers for a one-day RPO, and retention policies automatically delete backups after a set time. Frequent backups increase data-transfer cost, while long retention increases storage cost, although Compute Engine snapshots store only incremental block changes after the first full snapshot. Nearline, Coldline, and Archive classes lower storage cost for rarely accessed backups but add retrieval costs and minimum storage durations.
Readiness at the recovery site determines RTO. A hot standby system with pre-deployed infrastructure and replicated data gives the lowest RTO at the highest cost, while a stopped pre-configured VM or a VM built at recovery time from a template and custom image lowers cost but lengthens recovery. Persistent Disk Asynchronous Replication provides low-RPO and low-RTO block replication for cross-region active-passive recovery, and point-in-time recovery (PITR) allows restore to a specific time up to 7 days in the past. Every plan must be tested regularly with the test system isolated from primary users to prevent conflicts or split-brain operation.
Resource quotas and cost-control policies are organizational limits that decide whether a resilient design can be deployed and afforded. Google Cloud uses quotas to restrict shared resources, with some quotas applying globally and others per region or per zone. Most Compute Engine quotas, such as number of virtual machines, are regional, so a failover region must have sufficient quota for recovery VMs, disks, and high-CPU or high-memory machine types before an outage occurs.
Cost control forces tradeoffs between availability, latency, complexity, and spend. A service designed for 99.99% availability can still have nearly an hour of downtime per year, and 99.9% allows about 86 seconds per day compared with about 864 seconds for 99%. Higher nines generally cost more but may be required by regulation, while data-sovereignty rules may limit the failover region to approved locations. Efficient navigation of these constraints follows related practices:
When quotas, sovereignty, and budget are evaluated together, the database strategy selects only services whose SLAs, regions, export formats, and exit options satisfy governance while still meeting mandated RTO and RPO.
Regulatory compliance and data sovereignty requirements are legal and corporate rules that dictate where database data can live, who can access it, and how it must be protected. For Google Cloud databases, these rules directly control the choice of Google Cloud region, whether a multi-region configuration is allowed, and which encryption and audit controls must be applied. The customer remains responsible for placing data in compliant regions and configuring services correctly, while Google provides inherited controls and authorization boundaries.
Industry-specific regulations are frameworks that define required security controls for sensitive data under shared responsibility (opens in a new tab) between Google Cloud and the customer. The Payment Card Industry Data Security Standard (PCI DSS) governs payment processing through a shared responsibility matrix, while the Health Insurance Portability and Accountability Act (HIPAA) sets standards for electronic personal health information (PHI) in the United States. Other sectors such as finance and manufacturing have similar rules on gathering, processing, and storing data, documented in the Compliance resource center.
The database strategy must answer three shared questions for each framework: which controls are the customer's responsibility, which controls are available in the cloud offering, and which default controls are inherited. Inherited controls include default encryption and infrastructure controls that can be presented as audit evidence. Because misconfiguration is a common cause of breaches, the database deployment depends on the customer correctly applying access policies and region choices on top of those inherited controls.
| Regulation | Scope | Database implication |
|---|---|---|
| PCI DSS | Payment card processing | Database handling card data inherits platform encryption and infrastructure controls, customer manages access per shared matrix |
| HIPAA | Electronic PHI in the United States | Database storing PHI uses HIPAA-aligned services, customer controls access policies and stored data |
| General Data Protection Regulation (GDPR) | Personal data of EU residents | Database data collected in the EU must remain in Google Cloud regions in the EU |
| Federal Risk and Authorization Management Program (FedRAMP) High | U.S. federal protected data | Database workloads must run inside the Data Boundary for FedRAMP High to enforce residency under control SA-9(5) |
Geographic data residency policies are location-based rules that require customer data to be processed and stored within specific countries or regions. Under GDPR, a business serving EU residents may be obligated to keep that customer data in the EU, so the customer is responsible for keeping collected data in Google Cloud regions in the EU. The database deployment therefore depends on the selected Google Cloud region for legal adherence, and any replica or backup must stay inside the same compliant boundary.
Region choice also affects corporate policy beyond a single law because offices, customers, and stored data can sit in different jurisdictions. Google publishes regional Compliance offerings to show which certifications apply in each area, and complex cases may require review with sales or partner teams. The rule is consistent for databases: the policy applies to the project containing the database, and data flows from the application to the database instance must not leave approved regions through replication, export, or support tooling.
FedRAMP authorization is the U.S. federal process that allows a cloud solution to handle government data, with the current path being Rev. 5 Agency Authorization to Operate (ATO). Google Cloud maintains a comprehensive FedRAMP High provisional ATO covering more than 150 cloud services, which lets customers inherit platform controls and pursue their own ATO with a third-party assessment organization (3PAO) and Google. The FedRAMP Moderate baseline is a subset of the FedRAMP High baseline, so a Moderate ATO can use any FedRAMP High authorized service inside its boundary with fewer controls to assess.
To meet FedRAMP High obligations including residency under control SA-9(5), the customer must use Assured Workloads with the Data Boundary for FedRAMP High as described in FedRAMP implementation guidance (opens in a new tab). The Data Boundary creates an enforcement perimeter around selected Google Cloud services so protected database data stays within the authorized boundary. Google supports the ATO with a Customer Responsibility Matrix (CRM) for NIST SP 800-53 controls, a System Security Plan (SSP) describing the boundary and Google implementations, plus service-specific mapping and implementation guides for required configuration.
Exam tip: FedRAMP High workloads on Google Cloud must use the Data Boundary for FedRAMP High, while a FedRAMP Moderate ATO can use any FedRAMP High authorized service without requiring that same boundary.
Encryption and logging standards are the technical controls that prove a database meets mandates for confidentiality and oversight. Google Cloud provides default encryption and infrastructure security (opens in a new tab) controls as inherited controls across the network and physical infrastructure. The customer always remains responsible for its own access policies and stored data, including selecting customer-managed encryption when corporate policy requires stronger key control than default encryption.
Audit evidence connects the database to both Google controls and customer operations through logs and reviews. Cloud Audit Logs expose customer-visible data access for customer review, Access Transparency exposes logs showing Google administrator actions, and internal deployment integrity logs are monitored by a central security team for unreviewed code in privileged environments. Together, inherited encryption, region-constrained deployment, and complete access logging let the database team demonstrate that residency, protection, and monitoring requirements are met.
Security policies and identity governance apply organizational, regulatory, and security mandates to how database services are selected, deployed, and managed on Google Cloud. Security is shared responsibility where Google secures underlying infrastructure and the customer controls who can access data, how data is encrypted, and where data can move. Three controls carry most of this work: Identity and Access Management (IAM) for least-privilege access, Customer-Managed Encryption Keys (CMEK) for encryption at rest, and VPC Service Controls for perimeter protection.
Organizational governance sets the guardrails that database design must operate inside, enforced through organization policy constraints and shared controls. Google provides infrastructure protections such as default encryption in transit, distributed traffic routing, and physical security, while the customer configures identities, key management, network perimeters, and audit logging. Two predefined organization policies are directly relevant to databases: Restrict Resource Service Usage (constraints/gcp.restrictServiceUsage), which limits which services can be used, and Resource Location Restriction (constraints/gcp.resourceLocations), which limits regions where resources and data can be stored.
Together these policies determine which database services can be chosen and in which regions data may reside. A database instance cannot be created with a disallowed service or in a disallowed region, so governance decisions flow directly into region selection, multi-region design, and sovereignty compliance. The customer must therefore check both constraints before committing to a database architecture.
Identity and Access Management (IAM) is the system for verifying identity through authentication and then granting only needed permissions through authorization. Users authenticate with accounts managed by Cloud Identity, Google Workspace, or an external provider federated with Cloud Identity or Google Workspace, and workloads authenticate with service accounts, which are non-interactive accounts used by applications. When an API such as a database API is enabled, Google Cloud creates service agents that act on the customer's behalf to access customer resources.
Least privilege in IAM means granting only required roles at the smallest scope, where scope can be organization, folder, or project level. Project-level grants apply to all instances, clusters, or databases in that project, while organization-level grants are used when principals need visibility across all database resources. To apply least privilege at scale, create functional groups for each role, such as database administrators, developers, or auditors, and grant roles to the group rather than to individuals, because individual assignments increase management and auditing complexity.
Strong identity governance combines group-based authorization with hardened authentication and key hygiene:
constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload constraints, because key material copied into CLI files, local files, or code repositories can be stolen and reused.Customer-Managed Encryption Keys (CMEK) give the organization control over keys that protect database and related data stored in Google Cloud. By default, stored data is encrypted with Google-owned and Google-managed keys, and only the service instances that own the data can access it. With CMEK, keys are stored in Cloud Key Management Service (Cloud KMS) as software-protected keys or hardware-protected keys with Cloud HSM, but the keys are managed by the customer, who controls rotation, disabling, and access.
CMEK is applied to sensitive stored content such as database configuration, staged and published context, conversation state, and user-provided data. To make provisioning consistent, Cloud KMS Autokey can provision keys on demand that match developer intent and follow industry-standard practices, which reduces cost, latency, and complexity of separate encryption pipelines. Choose default encryption when Google-managed protection is sufficient, and choose CMEK when compliance requires customer ownership, centralized control in Cloud KMS, or hardware-backed protection.
| Encryption option | Key ownership and storage | Choose when |
|---|---|---|
| Default encryption | Google-owned and Google-managed keys | Standard protection is sufficient and no customer key control is required |
| CMEK with Cloud KMS | Customer-managed keys in Cloud KMS, with software or Cloud HSM protection, optionally provisioned by Autokey | Compliance requires customer control of rotation, disabling, and access to data-at-rest keys |
The dependency flows from the database service to Cloud KMS: the database service depends on Cloud KMS to unwrap the data encryption key on each access, so if the CMEK is disabled or its IAM permission is removed, access to protected data stops.
VPC Service Controls (opens in a new tab) is a resource-centric perimeter control that limits where Google Cloud resources can communicate and mitigates data exfiltration. A service perimeter defines a trusted boundary around selected projects, and policies inside the perimeter prevent access to Google-managed services outside the perimeter and block access from untrusted locations. The control applies to all user and service account identities reaching protected resources, with traffic flowing from developer workstations or workloads through the Google Front End (GFE) to protected APIs inside the perimeter.
Configuring VPC Service Controls for a database environment such as Database Center follows an ordered workflow. First, select the Database Center project that the perimeter will protect. Then, create the service perimeter and include the protected projects in it. Next, add existing Database Center instances to the perimeter so their data falls inside the trusted boundary. Finally, restrict APIs as restricted services, including the Database Center API, Compute Engine API, Cloud Storage API, Container Registry API, Certificate Authority Service API, and Cloud KMS API, to prevent data from being copied out through supporting services.
Access levels provide a controlled exception for requests coming from outside the perimeter, for example from an approved network or device. Access levels apply only to outside-to-inside requests for protected resources and cannot grant protected resources or virtual machines permission to access data outside the perimeter.
Exam tip: Access levels allow approved outside callers in, but they do not allow protected resources inside the perimeter to send data out.
Last updated