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.2Connectivity, access, and choosing databases
Understand network connectivity, key management, encryption, and security for databases, using session poolers, auditing policies, and choosing the right database solution by managed/unmanaged, SQL/NoSQL/vector, cost, regulation, and generative AI/LLM support.
Databases must be connected securely and chosen to best fit the use case. Cover connectivity/access design and choosing the database solution.
1.2.1Connectivity, access, and security
Apps connect securely via Cloud SQL Auth Proxy (IAM auth/encryption) or private IP without exposing a public IP. Manage keys with Cloud KMS (CMEK), encrypting at rest/in transit. Reuse many connections with session poolers (connection pools) to avoid exhaustion. Track who-did-what with audit logs. Map "avoid public IP, secure connect = Auth Proxy/private IP" and "anti-exhaustion = session poolers."
1.2.2Choosing database solutions
| Requirement | Choice |
|---|---|
| Typical business RDB | Cloud SQL |
| High-perf PostgreSQL, vector/gen AI | AlloyDB |
| Global strong-consistency RDB | Spanner |
| Huge-scale low-latency NoSQL | Bigtable |
| Document NoSQL | Firestore |
Choose databases by requirements: structured/semi/unstructured/vector, SQL vs NoSQL, cost, regulation/compliance, and generative AI/LLM support (vector search, embeddings). Decide managed (Google-run) vs unmanaged (self/bare metal). For high-performance PostgreSQL with vector/gen AI, AlloyDB; global strong consistency = Spanner; huge-scale low-latency = Bigtable. Map "PostgreSQL with vector/gen AI = AlloyDB" and "managed reduces operational burden."
Common: requirement → DB. E.g., "secure connect without public IP" = Cloud SQL Auth Proxy/private IP; "prevent connection exhaustion" = session poolers; "manage keys yourself" = CMEK (Cloud KMS); "global strong consistency" = Spanner; "high-perf PostgreSQL with vector/gen AI" = AlloyDB; "huge-scale low-latency" = Bigtable; "reduce ops burden" = managed.
Watch the mix-ups: (1) Do not confuse Cloud SQL (typical RDB)/AlloyDB (high-perf PostgreSQL, vector)/Spanner (global strong)/Bigtable (low-latency NoSQL). (2) Connect via Auth Proxy/private IP, avoiding public IP. (3) Use session poolers to avoid exhaustion under many connections.
1.2.3Section summary
- Secure connect = Cloud SQL Auth Proxy/private IP, CMEK; session poolers prevent exhaustion
- DB choice = Cloud SQL/AlloyDB (vector/gen AI)/Spanner/Bigtable/Firestore by requirements
- Decide by managed/unmanaged, SQL/NoSQL/vector, cost/regulation
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You need a globally distributed, strongly consistent relational DB. Which is best?
Q2. For high-performance PostgreSQL-compatible with vector search/gen-AI use, which is best?
Q3. To connect to Cloud SQL securely with IAM auth/encryption without exposing a public IP, what do you use?
Q4. To prevent connection exhaustion under many app connections, what do you use?
Q5. For huge-scale, low-latency time series/IoT data, which is best?
Q6. To manage database encryption keys yourself, what do you use?
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.