Ngân hàng đề — Google Cloud Professional Cloud Database Engineer

🧩 Giải thích nội dung câu hỏi

Câu hỏi tập trung vào việc di chuyển (migrate) cơ sở dữ liệu hiện có từ Microsoft SQL Server 2016 Standard Edition chạy trên Windows Server 2019 Datacenter Edition (một máy chủ vật lý on-premises) sang một instance Cloud SQL for SQL Server duy nhất trên Google Cloud.

Trong giai đoạn discovery (khám phá), bạn phát hiện máy chủ on-premises đạt đỉnh 25.000 read IOPS (Input/Output Operations Per Second đọc). Mục tiêu chính: Định cỡ (size) instance Cloud SQL sao cho tối ưu hóa hiệu suất đọc (maximize read performance), đảm bảo xử lý được tải read cao mà không bị nghẽn cổ chai (bottleneck) tại lưu trữ hoặc tài nguyên máy.

🛠️ Các yếu tố quan trọng cần xem xét (dựa trên tài liệu Cloud SQL for SQL Server mới nhất đến 2026):

• Machine types: Standard (cân bằng CPU/RAM, phù hợp workload nhẹ) vs. High Memory (ưu tiên RAM cao cho cache dữ liệu, lý tưởng cho DB read-heavy).
• Storage SSD: Read IOPS quy mô tuyến tính với kích thước lưu trữ provisioned. Theo docs GCP: Read IOPS ≈ 30 IOPS/GiB (capped ở 80.000 read IOPS tối đa cho SSD Regional SSD v2). Để đạt ≥25.000 read IOPS, cần ≥833 GiB (~900 GB) lưu trữ.
• Edition SQL Server: Cloud SQL hỗ trợ SQL Server 2019 Standard (tương thích migrate từ 2016 Standard). Enterprise hỗ trợ thêm features nhưng không bắt buộc.
• Tài nguyên vCPU/RAM: Phải đủ lớn để xử lý workload (16 vCPU/104 GB RAM là mức High Memory tiêu chuẩn cho tải cao).
• Không dùng read replicas (vì single instance), nên primary phải chịu toàn bộ read load.

📘 Tài liệu tham khảo:

• Cloud SQL for SQL Server: Machine resource types (cập nhật 2025: High Memory hỗ trợ max 96 TB storage).
• Cloud SQL storage performance (Read IOPS: 30/GiB, max 80k read IOPS).
• SQL Server editions in Cloud SQL.

✅ Đáp án đúng

Create a SQL Server 2019 Standard on High Memory machine type with 16 vCPUs, 104 GB of RAM, and 4 TB of SSD.

Lý do chọn:

• High Memory machine type (16 vCPU/104 GB RAM): Tối ưu cho workload DB với read cao nhờ RAM lớn giúp cache dữ liệu, giảm I/O disk. Standard type quá yếu (chỉ 4 vCPU/15 GB).
• 4 TB SSD (≈4.096 GiB): Cung cấp >120.000 read IOPS (4.096 × 30 > 25.000, vượt xa yêu cầu và capped ở 80k). Đảm bảo không bottleneck read.
• SQL Server 2019 Standard: Tương thích migrate từ 2016 Standard, chi phí hợp lý, hỗ trợ đầy đủ trên High Memory.
• Toàn diện: Đáp ứng peak load, scale performance tốt nhất cho single instance.

❌ Phân tích tất cả các phương án

• [SAI] Create a SQL Server 2019 Standard on Standard machine type with 4 vCPUs, 15 GB of RAM, and 800 GB of SSD.
  ❌ Standard machine type quá yếu: Chỉ 4 vCPU/15 GB RAM không đủ xử lý workload peak 25k read IOPS (dễ overload CPU/RAM, cache kém). 800 GB SSD cho ~24.000 read IOPS (800 × 30), sát nút nhưng không an toàn + machine type giới hạn performance tổng thể (max storage thấp hơn High Memory).

• [SAI] Create a SQL Server 2019 Standard on High Memory machine type with at least 16 vCPUs, 104 GB of RAM, and 200 GB of SSD.
  ❌ Storage quá nhỏ: 200 GB SSD chỉ ~6.000 read IOPS (200 × 30), không đạt 25k → bottleneck nghiêm trọng tại disk read. Dù High Memory tốt cho CPU/RAM, IOPS vẫn là vấn đề chính.

• [ĐÚNG] Create a SQL Server 2019 Standard on High Memory machine type with 16 vCPUs, 104 GB of RAM, and 4 TB of SSD.
  ✅ Hoàn hảo: High Memory + RAM/CPU mạnh + 4 TB SSD (>120k read IOPS) đảm bảo maximize read performance, dư thừa an toàn cho peak load.

• [SAI] Create a SQL Server 2019 Enterprise on High Memory machine type with 16 vCPUs, 104 GB of RAM, and 500 GB of SSD.
  ❌ Storage không đủ: 500 GB SSD chỉ ~15.000 read IOPS (500 × 30), thấp hơn 25k → không đáp ứng yêu cầu. Enterprise đắt hơn không cần thiết (Standard đủ cho migrate từ 2016 Standard), lãng phí chi phí.

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả tình huống bạn đang quản lý một instance Cloud SQL nhỏ (dịch vụ cơ sở dữ liệu quản lý của Google Cloud) dùng cho developers testing (lập trình viên kiểm thử). Instance này không quan trọng (not critical), có RPO (Recovery Point Objective) vài ngày nghĩa là chấp nhận mất dữ liệu tối đa vài ngày nếu có sự cố. Mục tiêu là giảm thiểu chi phí liên tục (minimize ongoing costs).

🛠️ Yêu cầu hành động: Chọn cách backup và quản lý transaction log (binary logs cho point-in-time recovery - PITR) sao cho an toàn dữ liệu cơ bản nhưng tiết kiệm nhất, vì RPO lớn nên không cần PITR chi tiết (chỉ cần backup hàng ngày là đủ).

📘 Kiến thức liên quan (cập nhật đến 2026):

• Cloud SQL automated backups chạy hàng ngày, lưu trữ 7 ngày mặc định, chi phí dựa trên storage (rẻ cho instance nhỏ).
• Transaction log retention (binary logs) chỉ cần cho PITR (phục hồi đến từng phút), nhưng tăng chi phí storage đáng kể (logs tích lũy nhanh).
• Không backup = rủi ro mất hết data. Manual backup tốn công quản lý và chi phí tương đương auto.
• Nguồn tham khảo:
  • Cloud SQL Backups Overview (Google Cloud Docs, phiên bản 2025-2026).
  • Backup Pricing (storage backup ~0.17 USD/GB/tháng, binary logs đắt hơn).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Turn on automated backup, and turn off transaction log retention.

Lý do 🧩:

• Automated backup đảm bảo backup hàng ngày tự động, phù hợp RPO vài ngày (mất tối đa 1 ngày data). Tiết kiệm chi phí vì không tốn công manual, storage chỉ cho backups (rẻ cho instance nhỏ/test).
• Turn off transaction log retention loại bỏ chi phí storage logs không cần thiết (không PITR vì instance không critical).
• Kết quả: An toàn cơ bản + chi phí thấp nhất ongoing (chỉ storage backup ~vài GB/tháng).

❌ Giải thích tất cả các phương án

• Take no backups, and turn off transaction log retention.
  ❌ Sai: Không backup gì cả dẫn đến rủi ro mất toàn bộ data nếu instance fail (delete, crash). Dù RPO lớn, vẫn cần backup cơ bản cho testing. Tiết kiệm storage nhưng không an toàn, vi phạm best practice Cloud SQL.

• Take one manual backup per day, and turn off transaction log retention.
  ❌ Sai: Manual backup hàng ngày tốn công quản lý (phải schedule thủ công), chi phí storage tương đương automated nhưng ít tiện lợi hơn (không tự động, dễ quên). Automated tốt hơn cho ongoing costs thấp.

• Turn on automated backup, and turn off transaction log retention.
  ✅ Đúng: Như giải thích trên – cân bằng hoàn hảo giữa an toàn (daily backup) và chi phí thấp (không logs). Phù hợp instance test/non-critical.

• Turn on automated backup, and turn on transaction log retention.
  ❌ Sai: Automated backup tốt, nhưng transaction log retention kích hoạt PITR gây tăng chi phí storage cao (logs > backups, tích lũy GB/ngày). Không cần cho RPO vài ngày, làm ongoing costs cao hơn không đáng.

🔍 Kết luận: Lựa chọn đúng giúp tối ưu chi phí ~50-70% so với full PITR cho test instance! Nếu cần config, dùng Console hoặc gcloud CLI: gcloud sql instances patch [INSTANCE] --backup-start-time=... --enable-bin-log=no.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi mô tả tình huống bạn đang quản lý một ứng dụng đặt lịch họp sử dụng Cloud SQL (dịch vụ cơ sở dữ liệu SQL quản lý trên Google Cloud). Trong một sự kiện ra mắt quan trọng, instance Cloud SQL đã trải qua sự kiện bảo trì (maintenance event) dẫn đến downtime hơn 5 phút, gây ảnh hưởng nghiêm trọng đến ứng dụng sản xuất (production).

📌 Vấn đề cốt lõi: Downtime này là không mong muốn và cần giải quyết ngay lập tức để tránh các sự cố không kế hoạch trong tương lai. Cloud SQL có các bảo trì định kỳ (như cập nhật phần mềm, vá lỗi bảo mật), thường diễn ra trong maintenance window mặc định (thường vào giờ thấp điểm UTC). Nếu window này trùng với giờ cao điểm kinh doanh, sẽ gây gián đoạn.

🛠️ Mục tiêu: Chọn hành động tức thì để giảm thiểu rủi ro downtime trong tương lai, dựa trên best practices của Google Cloud (cập nhật đến 2026: Cloud SQL hỗ trợ High Availability (HA) với failover tự động <60 giây, nhưng maintenance vẫn cần lập lịch thủ công).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Set your production instance's maintenance window to non-business hours.

Lý do chi tiết (🧩 Phân tích sâu):

• Cloud SQL cho phép tùy chỉnh maintenance window qua Console, gcloud CLI hoặc API, để đặt vào giờ không kinh doanh (ví dụ: 2-4 AM theo múi giờ địa phương). Điều này ngăn chặn ngay lập tức downtime trùng giờ cao điểm, vì maintenance chỉ diễn ra trong window đã chọn.
• Đây là giải pháp immediate và hiệu quả nhất, không yêu cầu migrate hay thay đổi kiến trúc, phù hợp với production. Theo tài liệu Google Cloud 2026, maintenance trên instance HA thường <5 phút với failover, nhưng đặt window đúng giờ đảm bảo 0 impact.
• Lợi ích: Giảm rủi ro 100% cho các maintenance kế hoạch, dễ triển khai trong <5 phút.

📘 Nguồn tham khảo:

• Cloud SQL Maintenance Windows (Google Cloud Docs, cập nhật 2026).
• Best Practices for Cloud SQL HA.

📋 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn một cách khách quan, dựa trên tính khả thi, tính immediate và best practices Google Cloud:

• Set your production instance's maintenance window to non-business hours.
  ✅ Đúng (Best choice). Như đã giải thích, đây là hành động trực tiếp, nhanh chóng và hiệu quả để tránh downtime trùng giờ kinh doanh. Không cần downtime thêm, chỉ cần cập nhật window qua Console (Apply immediately).

• Migrate the Cloud SQL instance to Cloud Spanner to avoid any future disruptions due to maintenance.
  ❌ Sai. Cloud Spanner là dịch vụ NoSQL phân tán toàn cầu với 99.999% uptime, không có maintenance downtime (zero-downtime upgrades). Tuy nhiên, migrate yêu cầu thay đổi schema lớn (Cloud SQL là relational SQL, Spanner hỗ trợ SQL nhưng khác biệt), tốn thời gian (tuần/tháng), chi phí cao (Spanner đắt hơn 5-10x), và không "immediate". Không phù hợp cho ứng dụng meeting booking đơn giản.

• Contact Support to understand why your Cloud SQL instance had a downtime of more than 5 minutes.
  ❌ Sai. Liên hệ Support (qua Cloud Console) hữu ích để root cause analysis (ví dụ: failover chậm do zone issue), nhưng không immediate giải quyết tương lai. Support chỉ giải thích sau (24-48h), không ngăn maintenance tiếp theo. Nên làm sau khi đã set window.

• Use Cloud Scheduler to schedule a maintenance window of no longer than 5 minutes.
  ❌ Sai. Cloud Scheduler dùng để trigger jobs định kỳ (như cron jobs), không kiểm soát maintenance window của Cloud SQL. Window do Google quản lý, bạn chỉ chọn thời gian/slots (tối thiểu 1-8 giờ, không customize độ dài <5 phút). Không khả thi, sẽ fail.

🛠️ Khuyến nghị bổ sung: Kết hợp enable HA (failover <60s) và read replicas để tối ưu. Test failover định kỳ qua gcloud sql instances patch. Nếu cần 99.99%+ uptime, xem AlloyDB (successor của Cloud SQL với maintenance tốt hơn, cập nhật 2024-2026).

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📘 Nội dung câu hỏi:
Câu hỏi yêu cầu thiết kế một instance Cloud SQL for PostgreSQL có tính sẵn sàng cao (HA - High Availability) để phục vụ cho 100 cơ sở dữ liệu (databases). Mỗi database chứa 80 bảng được migrate từ môi trường on-premises sang Google Cloud. Các ứng dụng sử dụng các database này nằm ở nhiều vùng (regions) khác nhau tại Mỹ (US), và cần đảm bảo thời gian phản hồi thấp (low latency) cho cả hoạt động đọc (read) và ghi (write).

✅ Yêu cầu chính cần giải quyết:

• HA: Đảm bảo tính sẵn sàng cao, tránh downtime bằng cơ chế failover tự động.
• Low latency read/write: Ứng dụng đa vùng (multi-region US) → Cần primary instance ở vùng trung tâm để xử lý write (write chỉ thực hiện trên primary), và read replicas ở các vùng gần ứng dụng để scale read traffic với độ trễ thấp.
• Quy mô: 100 databases, mỗi cái 80 tables → Không ảnh hưởng lớn đến lựa chọn kiến trúc, nhưng nhấn mạnh cần HA và multi-region replication.

🛠️ Kiến thức liên quan (cập nhật đến 2026):
Cloud SQL for PostgreSQL hỗ trợ HA configuration bằng cách deploy 2 instances (primary + standby/failover replica) trong cùng region để tự động failover trong <60 giây. Read replicas có thể cross-region (us-east1, us-west1) chỉ cho read-only traffic, giúp giảm latency read mà không ảnh hưởng write (write vẫn về primary). Không deploy thừa instances để tránh chi phí cao và phức tạp quản lý.

📚 Tài liệu tham khảo:

• Cloud SQL for PostgreSQL: High availability (HA) configurations (Google Cloud Docs, cập nhật 2025).
• Cloud SQL read replicas (Hỗ trợ cross-region replicas cho low-latency reads).
• Cloud SQL instance settings (Khuyến nghị 2 instances cho HA regional).

✅ Đáp án đúng: Deploy 2 Cloud SQL instances in the us-central1 region with HA enabled, and create read replicas in us-east1 and us-west1.

Lý do lựa chọn (chi tiết):
🟢 Đây là thiết kế tối ưu vì:

• 2 instances với HA enabled ở us-central1: Tạo primary + standby trong cùng region, đảm bảo HA với failover tự động, chịu được outage zone/region partial. Us-central1 là vùng trung tâm US, lý tưởng cho write latency thấp từ các apps US.
• Read replicas ở us-east1 và us-west1: Scale read traffic cross-region, giảm latency read cho apps ở East/West Coast (replication lag thấp ~giây). Write vẫn về primary central1.
• Phù hợp quy mô 100 DBs (có thể dùng separate instances hoặc multi-DB per instance). Tiết kiệm chi phí, dễ quản lý.

🔍 Giải thích tất cả các phương án (đúng/sai)

• ✅ [ĐÚNG] Deploy 2 Cloud SQL instances in the us-central1 region with HA enabled, and create read replicas in us-east1 and us-west1.
  🟢 Đúng vì: Như giải thích trên, chính xác match yêu cầu HA (2 instances) + low-latency multi-region reads. Không thừa instances, tối ưu chi phí/performance.

• ❌ [SAI] Deploy 2 Cloud SQL instances in the us-central1 region, and create read replicas in us-east1 and us-west1.
  🔴 Sai vì: Deploy 2 instances nhưng không enable HA → Chỉ là 2 standalone instances, không có failover tự động giữa chúng. Không đảm bảo HA thực sự (có thể manual failover, rủi ro downtime cao). Yêu cầu rõ "highly available (HA)" nên cần HA config chính thức.

• ❌ [SAI] Deploy 4 Cloud SQL instances in the us-central1 region with HA enabled, and create read replicas in us-central1, us-east1, and us-west1.
  🔴 Sai vì: Deploy 4 instances ở us-central1 với HA là thừa (HA chỉ cần 2 instances/primary group). Read replica ở us-central1 vô ích (latency không cải thiện, tăng chi phí replication loop). Phức tạp quản lý, vi phạm best practice "minimal instances for HA".

• ❌ [SAI] Deploy 4 Cloud SQL instances in the us-central1 region, and create read replicas in us-central1, us-east1 and us-west1.
  🔴 Sai vì: 4 instances không HA → Không có tính sẵn sàng cao, chỉ là multi-primary thủ công (khó sync, conflict data). Read replica ở us-central1 thừa như trên. Không low-latency HA đúng nghĩa, rủi ro cao cho production.

🎯 Kết luận: Lựa chọn đúng cân bằng hoàn hảo giữa HA, performance multi-region và chi phí. Nếu scale lớn hơn, có thể xem Private Service Connect cho kết nối low-latency!

🧩 Giải thích nội dung câu hỏi

Câu hỏi mô tả tình huống bạn làm việc trong bộ phận logistics, đội ngũ phân tích dữ liệu cần trích xuất dữ liệu hàng ngày từ Cloud SQL for MySQL dưới dạng CSV để huấn luyện mô hình machine learning tối ưu hóa tuyến đường ngày hôm sau. Bạn cần tuân thủ thực hành tốt nhất được Google khuyến nghị (Google-recommended practices).
📌 Yêu cầu chính: Export dữ liệu CSV từ Cloud SQL một cách tự động, đáng tin cậy, scalable và theo best practice của Google Cloud (dựa trên phiên bản mới nhất đến 2026, bao gồm Cloud SQL API v1 với các cải tiến export tích hợp SQL dump và CSV).

✅ Đáp án đúng

Use Cloud Scheduler to trigger a Cloud Function through Pub/Sub to call the cloudsql.instances.export API.

Lý do lựa chọn:
🛠️ Đây là best practice chính thức của Google cho việc export định kỳ từ Cloud SQL. Cloud Scheduler kích hoạt Pub/Sub topic, Pub/Sub trigger Cloud Function, và Function gọi API cloudsql.instances.export để export SQL dump (bao gồm CSV). Cách này decouple (tách rời) các thành phần, tránh timeout của Cloud Function (max 60 phút), xử lý export lớn/scalable, và hỗ trợ retry tự động. Không dùng direct trigger từ Scheduler đến Function vì có thể fail nếu export lâu. (Cập nhật 2025: API export hỗ trợ Cloud Storage bucket với encryption tự động).

📋 Giải thích tất cả các phương án

• ❌ [SAI] Use Cloud Scheduler to trigger a Cloud Function that will run a select * from table(s) query to call the cloudsql.instances.export API.
  Phân tích: Sai vì kết hợp query SELECT trực tiếp với API export không phải best practice. API cloudsql.instances.export dùng để export toàn bộ instance/database dưới dạng SQL dump/CSV vào Cloud Storage, không cần/không nên chạy SELECT thủ công (dễ lỗi, không scalable cho dữ liệu lớn, thiếu consistency). Direct trigger từ Scheduler đến Function có thể timeout nếu export lâu → Không recommended.

• ✅ [ĐÚNG] Use Cloud Scheduler to trigger a Cloud Function through Pub/Sub to call the cloudsql.instances.export API.
  Phân tích: Đúng hoàn toàn như giải thích ở trên. Pub/Sub làm trung gian đảm bảo asynchronous, reliable scheduling. Google docs nhấn mạnh pattern này cho ETL/export định kỳ (2026 update: Tích hợp IAM least-privilege cho export jobs).

• ❌ [SAI] Use Cloud Composer to orchestrate an export by calling the cloudsql.instances.export API.
  Phân tích: Sai vì Cloud Composer (Managed Apache Airflow) phù hợp cho workflow phức tạp/multi-step, nhưng quá nặng cho export đơn giản hàng ngày. Tăng chi phí, độ phức tạp không cần thiết. Best practice ưu tiên Cloud Scheduler + Function + Pub/Sub cho job lightweight → Composer chỉ dùng khi cần orchestration DAG phức tạp.

• ❌ [SAI] Use Cloud Composer to execute a select * from table(s) query and export results.
  Phân tích: Sai kép: (1) SELECT query thủ công không phải cách export chuẩn (mất atomicity, không hỗ trợ CSV native tốt, dễ fail với dữ liệu lớn). (2) Composer overkill cho task đơn giản, vi phạm nguyên tắc "use the simplest tool". Nên dùng API export trực tiếp vào Cloud Storage thay vì query + export manual.

📘 Tài liệu tham khảo

• 🆙 Cloud SQL Export Docs: cloud.google.com/sql/docs/mysql/export-import (Export API chi tiết, CSV support).
• 🆙 Scheduling Best Practices: cloud.google.com/scheduler/docs/scheduling-cloud-functions-pub-sub (Pattern Scheduler → Pub/Sub → Function).
• 🆙 Cloud SQL API Reference (2026): cloud.google.com/sql/docs/admin-api/export (v1beta4 với async export).
• 📊 Google Cloud Architecture Center: Tìm "Scheduled exports from Cloud SQL" cho case logistics/ML pipeline.

🧩 Giải thích nội dung câu hỏi

Câu hỏi yêu cầu chọn backend database phù hợp cho một ứng dụng mới, nơi ứng dụng sẽ ingest (thu nhận) dữ liệu từ các cảm biến IoT. Các yêu cầu chính bao gồm:

• Scale lên đến hàng triệu requests/giây (millions of requests per second) với độ trễ dưới 10ms (sub-10ms latency).
• Lưu trữ lịch sử lên đến 100 TB.

Đây là workload high-throughput, low-latency điển hình cho dữ liệu time-series từ IoT (như metrics sensor), cần database NoSQL scale horizontally, hỗ trợ petabyte-scale storage và real-time ingestion. Không phù hợp với relational DB hoặc in-memory cache thuần túy vì giới hạn scale và persistence. 📈

✅ Đáp án đúng

Use Bigtable, and add nodes as necessary to achieve the required throughput.

Lý do lựa chọn:

• Bigtable là wide-column NoSQL database được thiết kế cho massive scale (hàng tỷ rows, petabytes data), lý tưởng cho IoT workloads với millions RPS và sub-ms latency (dưới 10ms dễ đạt khi add nodes).
• Hỗ trợ horizontal scaling bằng cách thêm nodes (clusters), tự động sharding dữ liệu.
• Storage lên 100TB+ dễ dàng với SSD/HDD nodes, durable & persistent cho history data.
• Phù hợp real-time ingestion từ IoT (ví dụ: time-series data). Cập nhật 2026: Bigtable vẫn là top choice cho high-scale IoT, với c2a instances hỗ trợ >10M QPS/cluster. 🛠️

📋 Phân tích tất cả các phương án

• ❌ Use Cloud SQL with read replicas for throughput.
  Sai vì: Cloud SQL (MySQL/PostgreSQL managed) là relational DB, scale vertically/read replicas chỉ hỗ trợ ~10k-100k connections, không đạt millions RPS với sub-10ms (latency tăng do joins/queries complex). Không phù hợp IoT time-series lớn (100TB), giới hạn ~64TB/instance. Read replicas chỉ scale reads, không ingestion writes cao.

• ❌ Use Firestore, and rely on automatic serverless scaling.
  Sai vì: Firestore (document NoSQL serverless) scale tự động nhưng giới hạn ~1M writes/sec/database, latency trung bình 50-100ms ở high scale, không đảm bảo sub-10ms cho millions RPS. Storage 100TB khả thi nhưng không optimize cho IoT time-series (indexing kém hiệu quả), chi phí cao ở peak load.

• ❌ Use Memorystore for Memcached, and add nodes as necessary to achieve the required throughput.
  Sai vì: Memorystore for Memcached là in-memory key-value cache, siêu nhanh (sub-ms) và scale nodes tốt cho throughput, nhưng không persistent (dữ liệu mất khi restart), không lưu 100TB history. Chỉ phù hợp caching, không phải primary store cho IoT data lâu dài.

• ✅ Use Bigtable, and add nodes as necessary to achieve the required throughput.
  Đúng vì: Như giải thích trên, Bigtable excel ở extreme scale (millions RPS, sub-10ms P99 latency), storage unlimited, add nodes linear scale. Hoàn hảo cho IoT ingestion. 🚀

📘 Tài liệu tham khảo

• Google Cloud Bigtable Documentation (cập nhật 2025-2026: Bigtable cho IoT scale).
• Bigtable Performance Best Practices (QPS >10M, latency <10ms).
• Firestore Limits (xác nhận giới hạn writes).
• Cloud SQL Scaling (read replicas limits).

Hy vọng phân tích giúp bạn ôn thi hiệu quả! 🌟

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi yêu cầu thiết kế một ứng dụng xử lý thanh toán (payments processing application) trên Google Cloud, với các yêu cầu chính sau:

• Đảm bảo tính sẵn sàng cao (high availability): Ứng dụng phải tiếp tục phục vụ các request mà không bị gián đoạn (no user disruption) ngay cả khi xảy ra sự cố ở cấp region (regional failure). Điều này đòi hỏi cơ sở dữ liệu phải hỗ trợ multi-region replication hoặc global distribution với failover tự động và tính nhất quán mạnh (strong consistency).
• Mã hóa dữ liệu: Sử dụng AES-256 để mã hóa dữ liệu trong database (tất cả các dịch vụ Google Cloud database đều hỗ trợ AES-256 theo mặc định).
• Kiểm soát khóa mã hóa: Bạn muốn tự kiểm soát vị trí lưu trữ khóa mã hóa (control where you store the encryption key), nghĩa là sử dụng Customer-Managed Encryption Keys (CMEK) qua Cloud Key Management Service (Cloud KMS) thay vì khóa do Google quản lý.

Đây là tình huống điển hình cho ứng dụng tài chính cần tính sẵn sàng toàn cầu và tuân thủ bảo mật cao.

✅ Đáp án đúng: Use Cloud Spanner with a customer-managed encryption key (CMEK)

Lý do lựa chọn:

• Cloud Spanner là database globally distributed relational database hỗ trợ multi-region configurations (regional, multi-regional), đảm bảo zero-downtime và automatic failover nếu một region thất bại, phù hợp hoàn hảo với yêu cầu tránh gián đoạn.
• CMEK cho phép bạn tạo và quản lý khóa AES-256 trong Cloud KMS, kiểm soát hoàn toàn vị trí lưu trữ khóa (ví dụ: trong project riêng hoặc multi-region KMS).
• Hoàn thành tất cả yêu cầu: HA cross-region + mã hóa AES-256 + kiểm soát khóa.

📘 Tài liệu tham khảo:

• Cloud Spanner: Multi-region configurations (cập nhật 2024-2026).
• Cloud Spanner CMEK encryption (hỗ trợ AES-256 CMEK từ 2021, ổn định đến 2026).

🛠️ Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh:

• ✅ Use Cloud Spanner with a customer-managed encryption key (CMEK)
  Đúng vì: Cloud Spanner cung cấp horizontally scaled, strongly consistent database với multi-region replication tự động, chịu được regional failure mà không gián đoạn (RPO=0, RTO<60s). CMEK tích hợp Cloud KMS cho phép kiểm soát khóa AES-256. Đây là lựa chọn tối ưu cho payments app cần ACID transactions toàn cầu.

• ❌ Use Cloud Spanner with default encryption
  Sai vì: Mặc dù Cloud Spanner đáp ứng yêu cầu HA multi-region và AES-256, nhưng default encryption sử dụng Google-managed keys, bạn không kiểm soát vị trí lưu trữ khóa (Google quản lý hoàn toàn). Không đáp ứng yêu cầu "control where you store the encryption key".

• ❌ Use Cloud SQL with a customer-managed encryption key (CMEK)
  Sai vì: Cloud SQL (MySQL/PostgreSQL/SQL Server) hỗ trợ CMEK và high availability trong region (cross-zone failover), nhưng không hỗ trợ multi-region primary instance tự động (chỉ read replicas cross-region). Nếu regional failure, sẽ có gián đoạn lớn (downtime) khi promote replica, không đảm bảo "avoid any user disruption". Không phù hợp cho global HA.

• ❌ Use Bigtable with default encryption
  Sai vì: Bigtable là NoSQL wide-column store hỗ trợ multi-region replication, nhưng default encryption dùng Google-managed keys (không kiểm soát khóa). Hơn nữa, Bigtable thiếu strong consistency và full SQL support, kém phù hợp cho payments app cần transactions phức tạp (chỉ eventual consistency). Bigtable hỗ trợ CMEK nhưng lựa chọn này dùng default.

Kết luận nổi bật 🎯: Cloud Spanner + CMEK là giải pháp chuẩn enterprise cho workload tài chính trên Google Cloud, cân bằng giữa HA, bảo mật và hiệu suất. Nếu cần tư vấn thêm, hãy cung cấp chi tiết workload!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi mô tả tình huống bạn đang quản lý một môi trường Cloud SQL for MySQL trên Google Cloud. Bạn đã triển khai:

• Một primary instance (instance chính) ở Zone A.
• Một read replica instance (instance đọc phụ) ở Zone B, cùng trong một region (vùng địa lý).

Bạn nhận thông báo rằng read replica ở Zone B bị unavailable (không khả dụng) trong 10 phút. Nhiệm vụ là đảm bảo read replica instance vẫn đang hoạt động bình thường.

📌 Bối cảnh quan trọng:

• Cloud SQL hỗ trợ high availability (HA) và automatic failover/replacement cho các replica.
• Với read replicas (không phải failover replicas), Google Cloud tự động xử lý sự cố bằng cách tạo replica mới nếu instance bị lỗi, sử dụng backup mới nhất và binary logs để đồng bộ dữ liệu.
• Thời gian unavailable ngắn (10 phút) cho thấy đây là sự cố tạm thời, và hệ thống có cơ chế tự phục hồi.
• Kiến thức cập nhật đến năm 2026: Theo tài liệu Google Cloud mới nhất (phiên bản Cloud SQL 2024-2026), read replicas được tự động thay thế (automatic replacement) mà không cần can thiệp thủ công, miễn là tính năng HA được kích hoạt (mặc định cho replicas cross-zone).

Mục tiêu: Chọn hành động đúng để xác nhận replica vẫn hoạt động sau sự cố.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Verify that the new replica is created automatically.

🛠️ Lý do chi tiết:

• Trong Cloud SQL for MySQL, khi read replica bị unavailable (do lỗi zone, bảo trì, hoặc crash), Google Cloud tự động tạo một replica mới ở cùng zone (Zone B) để thay thế.
• Quá trình này sử dụng latest backup và binary logs từ primary để đồng bộ dữ liệu gần như real-time, đảm bảo replica lag tối thiểu.
• Bạn chỉ cần verify (kiểm tra) qua Console hoặc gcloud CLI (ví dụ: gcloud sql instances describe REPLICA_NAME) để xác nhận replica mới đã up và running.
• Không cần hành động thủ công vì hệ thống tự xử lý trong vài phút, phù hợp với thông báo 10 phút unavailable.
• Điều này đảm bảo high availability mà không downtime dài, theo best practice của Google Cloud.

📋 Giải thích tất cả các phương án (đúng/sai)

• ✅ [ĐÚNG] Verify that the new replica is created automatically.
  🟢 Giải thích đúng: Như đã phân tích, Cloud SQL tự động thay thế read replica bị lỗi bằng replica mới ở cùng zone. Chỉ cần kiểm tra trạng thái để xác nhận (không cần tạo thủ công). Đây là hành động đơn giản, hiệu quả nhất, tránh gián đoạn.

• ❌ [SAI] Use the Google Cloud Console or gcloud CLI to manually create a new clone database.
  🔴 Giải thích sai: Clone database dùng để tạo bản sao độc lập từ một thời điểm cụ thể (point-in-time), không phải để thay thế replica đang replicate real-time. Tạo clone thủ công sẽ không tự động đồng bộ với primary, gây mất tính nhất quán dữ liệu và tăng chi phí không cần thiết.

• ❌ [SAI] Use the Google Cloud Console or gcloud CLI to manually create a new failover replica from backup.
  🔴 Giải thích sai: Failover replica dành cho HA configuration của primary instance (không phải read replica), dùng để failover khi primary fail. Read replica không dùng failover replica; tạo thủ công từ backup sẽ không replicate liên tục, và đây không phải quy trình chuẩn cho read replica.

• ❌ [SAI] Start the original primary instance and resume replication.
  🔴 Giải thích sai: Primary instance ở Zone A vẫn đang hoạt động bình thường (chỉ replica fail). Không cần start primary hay resume replication thủ công vì primary không bị ảnh hưởng. Hành động này vô ích và có thể gây confusion.

📘 Tài liệu tham khảo

• Google Cloud SQL MySQL Replication Docs (Cập nhật 2024-2026: Automatic replacement for read replicas).
• Cloud SQL High Availability (Chi tiết về auto-recreate replicas).
• gcloud CLI Reference (Lệnh verify replica status).

Hy vọng phân tích này giúp bạn hiểu rõ! 🚀 Nếu cần demo gcloud commands, hãy hỏi thêm nhé!

🧩 Giải thích nội dung câu hỏi

Câu hỏi mô tả tình huống di chuyển ứng dụng từ on-premises lên Google Cloud, yêu cầu cơ sở dữ liệu PostgreSQL có high availability (HA) để hỗ trợ các chức năng kinh doanh quan trọng. Chiến lược disaster recovery (DR) của công ty đòi hỏi RTO (Recovery Time Objective) và RPO (Recovery Point Objective) trong vòng 30 phút khi xảy ra sự cố. Bạn cần sử dụng dịch vụ managed của Google Cloud và chọn giải pháp tối ưu hóa uptime cho ứng dụng.
📘 Yêu cầu chính: Đảm bảo HA trong region (chống mất zone), kết hợp DR cross-region với RTO/RPO thấp, không refactor lớn ứng dụng, ưu tiên Cloud SQL PostgreSQL managed.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng:
Deploy Cloud SQL for PostgreSQL in a regional configuration with HA enabled. Create a cross-region read replica, and promote the read replica as the primary node for disaster recovery.

Lý do:
🛠️ Giải pháp này kết hợp HA regional (tự động failover giữa các zone trong region, uptime >99.99%) với cross-region read replica (replication asynchronous, lag thấp ~giây đến phút). Khi DR, promote replica thành primary chỉ mất vài phút (RTO <30 phút), RPO cũng thấp nhờ replication liên tục (không dùng backup). Đây là cách tối ưu managed PostgreSQL cho yêu cầu, theo docs Cloud SQL mới nhất (2024-2026). Không cần refactor schema/app.
📘 Nguồn: Cloud SQL for PostgreSQL: High availability and disaster recovery & Cross-region replication.

📋 Phân tích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên tính năng Cloud SQL PostgreSQL (cập nhật 2026: hỗ trợ promote replica nhanh, replication lag <5 phút trung bình).

• ❌ Phương án SAI:
  Deploy Cloud SQL for PostgreSQL in a regional configuration. Create a read replica in a different zone in the same region and a read replica in another region for disaster recovery.
  Lý do sai: Read replica cùng region chỉ hỗ trợ HA intra-zone (không failover tự động như HA config thực thụ). Cross-region replica hỗ trợ DR nhưng không đề cập promote replica thành primary, dẫn đến RTO >30 phút (phải manual rebuild). Không tối ưu uptime so với HA enabled + promote. Lag cross-region có thể >30 phút nếu traffic cao.

• ❌ Phương án SAI:
  Deploy Cloud SQL for PostgreSQL in a regional configuration with HA enabled. Take periodic backups, and use this backup to restore to a new Cloud SQL for PostgreSQL instance in another region during a disaster recovery event.
  Lý do sai: Periodic backups (transaction log sao lưu mỗi 5-60 phút) chỉ đạt RPO ~giờ, không <30 phút. Restore từ backup mất 30 phút đến hàng giờ (RTO cao), không phù hợp DR nhanh. HA regional chỉ chống zone failure, không cross-region tự động. Không phải giải pháp managed tối ưu cho RTO/RPO yêu cầu.

• ✅ Phương án ĐÚNG (đã giải thích chi tiết ở trên):
  Deploy Cloud SQL for PostgreSQL in a regional configuration with HA enabled. Create a cross-region read replica, and promote the read replica as the primary node for disaster recovery.
  Tóm tắt lý do đúng: Đầy đủ HA + DR nhanh, RTO/RPO <30 phút, managed thuần túy. ✅

• ❌ Phương án SAI:
  Migrate the PostgreSQL database to multi-regional Cloud Spanner so that a single region outage will not affect your application. Update the schema to support Cloud Spanner data types, and refactor the application.
  Lý do sai: Cloud Spanner multi-regional cho uptime 99.999% và DR tự động (RTO/RPO thấp), nhưng KHÔNG phải PostgreSQL thuần – yêu cầu refactor schema (hỗ trợ Spanner types như ARRAY, JSON) và thay đổi ứng dụng (ACID giao dịch khác). Không dùng "Google Cloud managed service PostgreSQL" như yêu cầu, chi phí cao hơn, phức tạp không cần thiết.

🛠️ Khuyến nghị bổ sung: Test failover/promote qua console hoặc gcloud CLI để xác nhận RTO thực tế. Theo best practices 2026, kết hợp Cloud SQL Insights cho monitoring lag replica. 📘 Nguồn tổng hợp: Google Cloud SQL Best Practices & Disaster Recovery Guide.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi mô tả tình huống: Nhóm của bạn đang chạy một instance Cloud SQL for MySQL với cơ sở dữ liệu 5 TB, cần sẵn sàng 24/7. Yêu cầu là lưu backup cơ sở dữ liệu vào object storage (như Cloud Storage) với overhead vận hành tối thiểu và rủi ro thấp nhất cho workload sản xuất.

📌 Mục tiêu chính:

• Database lớn (5 TB) → Cần phương pháp backup hiệu quả, không làm gián đoạn.
• 24/7 availability → Không được ảnh hưởng performance hoặc downtime.
• Minimal operational overhead → Tự động hóa cao, ít can thiệp thủ công.
• Low risk to production → Không lock tables, không tải nặng CPU/IO trên primary instance.
• Lưu vào object storage → Tương thích với Cloud Storage (GCS).

🛠️ Bối cảnh Google Cloud (cập nhật đến 2026): Cloud SQL hỗ trợ các tính năng backup tiên tiến như automated backups, point-in-time recovery (PITR), và serverless exports – cho phép export dữ liệu lớn mà không cần quản lý server, không ảnh hưởng production (dựa trên phiên bản Cloud SQL mới nhất với export lên đến petabyte-scale).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Use Cloud SQL serverless exports.

Lý do 🏆:

• Serverless exports là tính năng chuyên dụng của Cloud SQL (ra mắt và cải tiến mạnh từ 2022-2026), cho phép export toàn bộ database hoặc schema sang Cloud Storage mà không lock tables, không tải IO/CPU trên primary instance → Minimal overhead và zero risk cho production 24/7.
• Hỗ trợ database lớn (5 TB+), parallel export, compression tự động (zstd/gzip), và resumable → Hoàn hảo cho scale lớn.
• Operational overhead thấp: Chỉ cần gcloud CLI hoặc Console, tự động hóa qua SQL Admin API.
• Không cần read replica/clone → Tiết kiệm chi phí và resource.

📋 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá với lý do chi tiết dựa trên best practices Cloud SQL (2026):

• ✅ Use Cloud SQL serverless exports.
  Đúng vì: Như đã giải thích ở trên. Đây là giải pháp serverless native, export trực tiếp sang GCS mà không ảnh hưởng primary instance. Hỗ trợ export logical (SQL dumps) hoặc binary, resumable cho 5TB+, và tích hợp IAM cho security. Zero downtime, minimal ops – lý tưởng cho production lớn.

• ❌ Create a read replica, and then use the mysqldump utility to export each table.
  Sai vì: Tạo read replica tốn chi phí (~50% primary) và resource (storage/replication lag cho 5TB). mysqldump trên replica vẫn gây heavy IO/CPU (table locks nếu không dùng --single-transaction), export từng table thủ công → Overhead cao, thời gian dài (ngày cho 5TB), rủi ro lag replica ảnh hưởng consistency. Không minimal ops.

• ❌ Clone the Cloud SQL instance, and then use the mysqldump utlity to export the data.
  Sai vì: Clone tạo snapshot đầy đủ (tốn storage gấp đôi tạm thời, downtime ngắn khi clone), sau đó mysqldump trên clone vẫn chậm (sequential dump cho 5TB), cần quản lý lifecycle clone → Overhead vận hành cao (delete clone sau), rủi ro resource contention nếu cluster nhỏ. Không serverless, không optimal cho backup định kỳ.

• ❌ Use the mysqldump utility on the primary database instance to export the backup.
  Sai vì: Chạy mysqldump trực tiếp trên primary gây table locks/read locks (ngay cả --single-transaction), heavy IO/CPU → Rủi ro cao cho production 24/7 (downtime/quay chậm). Với 5TB, thời gian export có thể hàng giờ/ngày, không resumable, và phải pipe thủ công sang GCS → Maximal overhead và risk.

📘 Tài liệu tham khảo (cập nhật 2026)

• Cloud SQL Documentation: Export and import data – Chi tiết serverless exports.
• Best Practices: Backup strategies for Cloud SQL – Khuyến nghị serverless cho large DB.
• GCP Release Notes: Serverless export hỗ trợ zstd compression và petabyte-scale từ 2024 (xem changelog).
• Console/CLI: gcloud sql export sql instance_name gs://bucket/export.sql.gz --database=dbname.

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm ví dụ code gcloud, hãy hỏi nhé!