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

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

Câu hỏi mô tả một ứng dụng đang xây dựng để lưu trữ và phân tích dữ liệu chuỗi thời gian (time series) tài chính theo luồng (streaming). Các yêu cầu chính bao gồm:

• Thực hiện quét dựa trên time series với độ trễ dưới 1 giây (sub-second latency): Cần truy vấn nhanh chóng theo thời gian, phù hợp với dữ liệu tài chính thời gian thực.
• Mở rộng quy mô lên hàng trăm terabyte (hundreds of terabytes): Hỗ trợ dữ liệu lớn.
• Ghi lên đến 10.000 bản ghi/giây (10k records per second) và đọc lên đến 200 MB/giây (200 MB per second): Yêu cầu throughput cao cho write/read real-time. 📘 Bối cảnh: Đây là bài toán điển hình cho dữ liệu time series lớn như giá cổ phiếu, giao dịch tài chính, nơi Bigtable (Google Cloud) được thiết kế chuyên biệt với tính năng Time Series Insights (cập nhật đến 2026, hỗ trợ tự động phân vùng theo thời gian và nén dữ liệu hiệu quả).

✅ Đáp án đúng: Use Bigtable

Lý do lựa chọn:

• Bigtable là cơ sở dữ liệu NoSQL wide-column store được tối ưu hóa cho dữ liệu time series lớn với độ trễ thấp (sub-second), scale tự động lên petabyte mà không gián đoạn.
• Hỗ trợ throughput cao: Dễ dàng đạt 10k writes/s và 200 MB/s reads nhờ kiến trúc phân tán (hàng triệu QPS).
• Tích hợp Time Series model (phiên bản mới nhất 2026): Tự động sắp xếp row key theo timestamp, hỗ trợ scans nhanh (ví dụ: range scans theo thời gian).
• Phù hợp streaming financial data, được sử dụng bởi các công ty như Google Finance hay Citadel. 🛠️ Nguồn tham khảo:
• Bigtable Documentation - Time Series (Google Cloud, cập nhật 2025-2026).
• Bigtable Performance Benchmarks (đạt >10k ops/s dễ dàng).

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

• [SAI] Use Firestore.
  ❌ Sai vì: Firestore là document database (NoSQL) phù hợp ứng dụng web/mobile nhỏ lẻ, nhưng không scale tốt cho time series lớn (giới hạn 1M writes/s toàn cầu, nhưng latency cao hơn sub-second cho scans lớn). Không hỗ trợ native time series scans hiệu quả, dễ gặp bottleneck ở hundreds TB và 200 MB/s reads. Phù hợp hơn cho user data, không phải high-throughput streaming.

• [ĐÚNG] Use Bigtable.
  ✅ Đúng vì: Như giải thích trên, Bigtable vượt trội với low-latency time series scans, scale ngang vô hạn (hundreds TB+), và throughput chính xác khớp yêu cầu (10k writes/s, 200 MB/s reads). Tích hợp Dataflow cho streaming ingestion.

• [SAI] Use BigQuery.
  ❌ Sai vì: BigQuery là data warehouse cho batch analytics (SQL queries trên petabyte data), không phải real-time database. Latency scans thường giây đến phút (không sub-second), write throughput thấp cho streaming (dùng Streaming Inserts giới hạn 1MB/s/table). Phù hợp phân tích lịch sử, không phải live financial time series.

• [SAI] Use Cloud Spanner.
  ❌ Sai vì: Spanner là relational database globally distributed, hỗ trợ SQL ACID, nhưng không tối ưu time series (thiếu native row-key time-based như Bigtable). Latency ổn định nhưng đắt đỏ hơn (chi phí cao cho high-throughput), scale tốt nhưng overkill và kém hiệu quả cho pure time series scans so với Bigtable.

🧩 Kết luận: Bigtable là lựa chọn lý tưởng cho workload này theo best practices Google Cloud (2026). Nếu cần hybrid, kết hợp Bigtable + BigQuery cho storage + analytics! 🚀

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

Câu hỏi mô tả tình huống thiết kế một ứng dụng game mới trên Google Cloud, sử dụng cơ sở dữ liệu quan hệ (relational database) có tính giao dịch cao (highly transactional) để lưu trữ dữ liệu xác thực người chơi (player authentication) và dữ liệu kho đồ (inventory data). Ứng dụng cần triển khai ở nhiều vùng (multiple regions) để đảm bảo tính sẵn sàng cao, độ trễ thấp và khả năng mở rộng toàn cầu.

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

• Dữ liệu quan hệ: Hỗ trợ SQL chuẩn, schema cố định, quan hệ giữa các bảng (ví dụ: bảng user liên kết với inventory).
• Highly transactional: Đảm bảo tính ACID (Atomicity, Consistency, Isolation, Durability), đặc biệt cho các hoạt động như đăng nhập, cập nhật item – tránh mất dữ liệu hoặc xung đột.
• Multi-region: Hỗ trợ ghi/đọc mạnh mẽ nhất quán (strong consistency) ở nhiều vùng địa lý, không chỉ đọc replica mà còn ghi phân tán.

🛠️ Bối cảnh cập nhật đến 2026: Theo tài liệu Google Cloud mới nhất (Google Cloud Next 2025 và docs cập nhật 2026), Cloud Spanner là giải pháp globally distributed relational DB duy nhất hỗ trợ multi-region với giao dịch ACID thực thụ.

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

• Cloud Spanner Overview – Xác nhận multi-region, ACID transactions.
• Choosing a Google Cloud SQL database – So sánh với Cloud SQL.
• Database options in Google Cloud – Hướng dẫn chọn DB cho workloads transactional/multi-region.

✅ Đáp án đúng: Use Cloud Spanner to deploy the database

Lý do lựa chọn:

• Cloud Spanner là cơ sở dữ liệu quan hệ phân tán toàn cầu (globally distributed) duy nhất trên Google Cloud, hỗ trợ giao dịch ACID mạnh mẽ ở quy mô lớn, phù hợp hoàn hảo cho ứng dụng game cần multi-region với độ trễ thấp (<10ms) và tính sẵn sàng 99.999% (five 9s).
• Nó sử dụng TrueTime để đồng bộ thời gian toàn cầu, đảm bảo strong consistency cho cả đọc/ghi ở nhiều vùng (ví dụ: us-central1 + europe-west1).
• Hoàn hảo cho dữ liệu authentication/inventory: Hỗ trợ SQL chuẩn (ANSI 2011+), secondary indexes, và scale horizontally lên petabyte mà không shard thủ công.
• Không có giải pháp nào khác trong Google Cloud đáp ứng đầy đủ relational + highly transactional + multi-region native.

📋 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 một, với lý do đúng/sai dựa trên đặc tính kỹ thuật:

• ✅ Use Cloud Spanner to deploy the database
  Giải thích: Như đã nêu ở trên, đây là lựa chọn hoàn hảo vì đáp ứng 100% yêu cầu: relational SQL, ACID transactions toàn cầu, multi-region native với strong consistency. Không cần cấu hình phức tạp, tự động scale và chịu lỗi vùng (regional multi-site config). ✅

• ❌ Use Bigtable with clusters in multiple regions to deploy the database
  Giải thích: Bigtable là NoSQL wide-column store, KHÔNG hỗ trợ relational schema hoặc giao dịch ACID phức tạp (chỉ eventual consistency hoặc single-row transactions). Dù có multi-region replication, nó phù hợp cho analytics/big data (như leaderboards), KHÔNG phù hợp cho transactional OLTP như authentication/inventory – dễ mất tính nhất quán dữ liệu. ❌

• ❌ Use BigQuery to deploy the database
  Giải thích: BigQuery là data warehouse cho phân tích (OLAP), KHÔNG phải OLTP transactional. Nó immutable (append-only), không hỗ trợ updates/deletes real-time ACID, và KHÔNG dành cho multi-region writes. Phù hợp báo cáo game metrics, nhưng thất bại hoàn toàn với authentication/inventory cần giao dịch nhanh. ❌

• ❌ Use Cloud SQL with a regional read replica to deploy the database
  Giải thích: Cloud SQL (MySQL/PostgreSQL) là regional relational DB, read replica chỉ scale reads trong một vùng, không hỗ trợ multi-region writes ACID. Cross-region replicas có eventual consistency, dễ data loss nếu primary fail. Không đạt yêu cầu launch ở multiple regions với strong consistency. (Cập nhật 2026: Vẫn chưa có global transactional như Spanner). ❌

🧩 Kết luận: Cloud Spanner là giải pháp tối ưu cho workload gaming transactional multi-region trên Google Cloud! Nếu cần thiết kế sâu hơn, hãy cung cấp thêm chi tiết về workload. 🚀

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

Câu hỏi tập trung vào việc thiết kế chiến lược cơ sở dữ liệu cho một ứng dụng web mới triển khai trong một vùng (one region) duy nhất. Mục tiêu chính là giảm thiểu độ trễ ghi (write latency) – tức là làm cho các hoạt động ghi dữ liệu (như INSERT, UPDATE, DELETE) diễn ra nhanh nhất có thể.

📌 Chi tiết quan trọng:

• Ứng dụng chỉ ở một region, nên không cần tính sẵn sàng cao qua nhiều region.
• Write latency bị ảnh hưởng bởi các yếu tố như: đồng bộ hóa dữ liệu (synchronous replication), vị trí instance (zonal hay multi-zone), và cấu hình sao lưu/HA (High Availability).
• Trong Google Cloud, Cloud SQL là dịch vụ managed MySQL/PostgreSQL/SQL Server, còn Cloud Spanner là distributed SQL với khả năng scale toàn cầu.
• Kiến thức cập nhật đến 2026: Cloud SQL hỗ trợ zonal instances (single-zone) với write latency thấp nhất (~1-5ms intra-zone), trong khi HA/multi-zone tăng latency do synchronous replication (có thể +10-50ms tùy khoảng cách zone). Cloud Spanner regional config yêu cầu ít nhất 3 zones/replicas, tăng latency ghi lên đáng kể.

✅ Đáp án đúng: Use zonal Cloud SQL without high availability (HA)

Lý do chọn 🛠️:
Phương án này cung cấp độ trễ ghi thấp nhất vì instance Cloud SQL chỉ nằm trong một zone duy nhất, không có đồng bộ hóa synchronous sang zone khác. Tất cả writes đều xử lý cục bộ trên primary instance, giảm thiểu overhead network và replication. Phù hợp hoàn hảo cho app single-region, ưu tiên performance ghi hơn tính sẵn sàng cao (HA chỉ cần cho downtime tolerance). Theo tài liệu Google Cloud 2024-2026, zonal non-HA là lựa chọn tối ưu cho low-latency writes trong cùng zone.

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

• ❌ Use Cloud SQL with cross-region replicas:
  Phương án này sai vì cross-region replicas là asynchronous read replicas ở region khác, nhưng writes vẫn phải commit đến primary (có thể ở region khác nếu config), dẫn đến write latency cao hơn do network cross-region (latency 50-200ms+). Không phù hợp single-region và không minimize writes.

• ❌ Use high availability (HA) Cloud SQL with multiple zones:
  Phương án này sai vì HA Cloud SQL sử dụng synchronous replication sang standby instance ở zone khác cùng region, buộc mỗi write phải chờ xác nhận từ cả hai zone. Điều này tăng write latency (thêm 10-50ms do intra-region network), trái ngược mục tiêu minimize latency. HA ưu tiên failover (99.99% uptime) hơn speed.

• ✅ Use zonal Cloud SQL without high availability (HA):
  (Như đã giải thích ở trên) – Đúng vì single-zone, no replication overhead, writes cục bộ siêu nhanh. Lý tưởng cho workloads write-heavy trong one zone/region.

• ❌ Use Cloud Spanner in a regional configuration:
  Phương án này sai vì Cloud Spanner regional config yêu cầu ít nhất 3 replicas ở 3 zones khác nhau với synchronous replication toàn cầu, dẫn đến write latency cao (20-100ms+ do multi-zone quorum). Spanner mạnh về consistency/scale, không phải low-latency writes cho single-region app.

📘 Tài liệu tham khảo

• Cloud SQL HA & Replication Overview (Google Cloud Docs, cập nhật 2025): Xác nhận HA tăng write latency do sync replication.
• Cloud SQL Instance Configurations (2026): Zonal non-HA cho minimal latency.
• Cloud Spanner Topology (2025): Regional cần multi-zone, không tối ưu writes.
• Best Practices: Google Cloud Architecture Center – "Optimizing Latency for Regional Apps" (2024+).

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần thêm chi tiết, hãy hỏi nhé!

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

Câu hỏi mô tả một ứng dụng lớn, có giao dịch cao (highly transactional) đang chạy trên Oracle Real Application Cluster (RAC), là môi trường multi-tenant (nhiều tenant chia sẻ tài nguyên) và sử dụng shared storage (lưu trữ chia sẻ). Yêu cầu giải pháp phải đảm bảo:

• High-performance throughput (thông lượng hiệu suất cao).
• Low-latency connection (kết nối độ trễ thấp) giữa ứng dụng và cơ sở dữ liệu.
• Hỗ trợ các tính năng Oracle hiện có (như RAC, multi-tenant).
• Dễ dàng migrate sang Google Cloud (di chuyển mượt mà mà không thay đổi lớn về kiến trúc).

🛠️ Mục tiêu chính: Tìm giải pháp trên Google Cloud giữ nguyên hiệu suất on-premises của Oracle RAC, tránh virtualization overhead để đảm bảo low-latency và high-throughput, đồng thời hỗ trợ migration dễ dàng.

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

Đáp án đúng: Migrate to Bare Metal Solution for Oracle.

Lý do:

• Bare Metal Solution for Oracle cung cấp máy chủ bare metal (không ảo hóa) được chứng nhận bởi Oracle, hỗ trợ đầy đủ Oracle RAC, multi-tenant và shared storage (như Oracle Exadata hoặc tương đương).
• Đảm bảo high-performance throughput và low-latency nhờ kết nối trực tiếp (bare metal) giữa ứng dụng và DB, không có overhead từ hypervisor.
• Hỗ trợ tất cả tính năng Oracle hiện có (RAC clustering, Grid Infrastructure) và dễ migrate vì Google Cloud cung cấp công cụ lift-and-shift, shared storage NFS, và tích hợp với Oracle Validated Designs (OVD).
• Phù hợp với workload lớn, transactional cao trên Google Cloud (cập nhật đến 2026: Hỗ trợ Oracle 19c/21c, Alloy clusters cho RAC scale-out).

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

• ❌ Migrate to Compute Engine.
  Sai vì Compute Engine là VM ảo hóa (KVM), gây overhead hiệu suất (latency cao hơn bare metal), không hỗ trợ native Oracle RAC clustering hoặc shared storage mà không cần cấu hình phức tạp. Migration khó khăn do cần refactor RAC trên VM, không đảm bảo high-throughput cho transactional lớn.

• ✅ Migrate to Bare Metal Solution for Oracle.
  Đúng như đã giải thích ở trên: Bare metal chuyên biệt cho Oracle, zero virtualization overhead, hỗ trợ đầy đủ RAC/multi-tenant/shared storage, low-latency qua RDMA/NVMe, và migration dễ dàng với Oracle tools (Data Pump, GoldenGate). Lý tưởng cho workload hiện tại.

• ❌ Migrate to Google Kubernetes Engine (GKE).
  Sai vì GKE là container orchestration, không phù hợp cho Oracle RAC (RAC yêu cầu bare metal/shared block storage, không phải container ephemeral). Sẽ mất hiệu suất cao (container overhead), không hỗ trợ Oracle features native, và migration phức tạp (cần containerize Oracle – không khuyến khích cho RAC transactional).

• ❌ Migrate to Google Cloud VMware Engine.
  Sai vì VMware Engine là private cloud VMware (vSphere/ESXi), hỗ trợ VM nhưng không tối ưu cho Oracle RAC bare metal. Latency cao hơn do virtualization layer, shared storage cần cấu hình riêng (vSAN), và migration Oracle RAC sang VMware đòi hỏi redesign clustering – không đảm bảo low-latency/high-throughput như bare metal.

📘 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• Google Cloud Bare Metal Solution for Oracle: cloud.google.com/bare-metal/docs/oracle/overview – Chi tiết RAC support, Alloy DB clusters, Exadata-like configs.
• Oracle Validated Designs on Google Cloud: cloud.google.com/solutions/oracle – Hướng dẫn migration RAC với low-downtime.
• AWS so sánh (nếu liên quan): Không áp dụng trực tiếp (câu hỏi Google Cloud), nhưng tương đương AWS có Oracle on EC2 Bare Metal – tuy nhiên, ưu tiên Bare Metal Solution GCP cho ease-of-migration.
• Cập nhật 2024-2026: Bare Metal hỗ trợ Oracle 23ai Free, AI Vector Search integration (GA 2025).

🧠 Kết luận: Bare Metal Solution là lựa chọn tối ưu nhất cho lift-and-shift Oracle RAC sang Google Cloud mà giữ nguyên performance! 🚀

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

Câu hỏi này tập trung vào việc chọn backend cơ sở dữ liệu mới cho một ứng dụng hiện có đang chạy PostgreSQL trên máy ảo on-premises (VM cục bộ), được quản lý bởi đội ngũ DBA (quản trị viên cơ sở dữ liệu) và operations (vận hành). Dữ liệu của ứng dụng là dạng quan hệ (relational), với lưu lượng truy cập nhẹ (light traffic). Mục tiêu chính là giảm thiểu chi phí (minimize costs) và nỗ lực di chuyển (migration effort).

🛠️ Yêu cầu chính:

• Giữ nguyên tính tương thích với PostgreSQL (relational DB).
• Dễ dàng migrate từ on-premises mà không cần thay đổi lớn code ứng dụng.
• Managed service để giảm gánh nặng quản lý (không cần DBA/ops can thiệp nhiều).
• Phù hợp light traffic: Không cần scale cao, ưu tiên low-cost.
• Đây là tình huống điển hình khi migrate từ on-prem sang Google Cloud Platform (GCP), tận dụng các dịch vụ managed để tiết kiệm chi phí vận hành (như backup, patching, scaling tự động).

📘 Kiến thức cập nhật (tính đến 2026): Theo tài liệu GCP mới nhất (Cloud SQL v2024+), Cloud SQL hỗ trợ PostgreSQL 16+, với Database Migration Service (DMS) giúp migrate zero-downtime từ on-prem PostgreSQL. Chi phí thấp cho light traffic (~$0.02/giờ cho micro instance).

✅ Đáp án đúng: Migrate the existing database to Cloud SQL for PostgreSQL

Lý do lựa chọn:

• Tương thích hoàn hảo: Cloud SQL là dịch vụ fully managed PostgreSQL, hỗ trợ 100% syntax và features của PostgreSQL on-premises, không cần thay đổi schema hoặc query.
• Migration effort thấp: Sử dụng Database Migration Service (DMS) hoặc pg_dump/pg_restore để migrate nhanh chóng, hỗ trợ continuous replication (zero-downtime).
• Minimize costs: Với light traffic, dùng Cloud SQL Shared Core hoặc dedicated core nhỏ (từ 1 vCPU, 3.75GB RAM), chi phí chỉ ~$10-20/tháng + storage. Tự động scale, backup, high availability mà không cần DBA.
• Managed service: Google lo patching, monitoring, failover – giảm gánh nặng ops team so với on-prem.
• Phù hợp light traffic: Không overprovision, pay-per-use.

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

• ✅ [ĐÚNG] Migrate the existing database to Cloud SQL for PostgreSQL
  Như đã phân tích ở trên: Managed PostgreSQL lý tưởng cho relational data, low migration effort (DMS), low cost cho light traffic. Hoàn hảo match yêu cầu! 🏆

• ❌ [SAI] Migrate the existing database to Firestore
  Firestore là NoSQL document DB (dựa trên JSON), không hỗ trợ relational schema (không có JOIN, foreign keys chuẩn). Migration từ PostgreSQL sẽ yêu cầu refactor toàn bộ ứng dụng (schema redesign), effort cao và không minimize costs vì Firestore tính phí theo read/write operations – không phù hợp light relational traffic.

• ❌ [SAI] Migrate the existing database to Cloud Spanner
  Cloud Spanner là globally distributed relational DB với horizontal scale mạnh, nhưng overkill và đắt đỏ cho light traffic (minimum ~$0.90/giờ/node + storage cao). Migration cần schema adjustments cho Spanner SQL (khác PostgreSQL), effort lớn. Không minimize costs (dành cho high-scale enterprise).

• ❌ [SAI] Migrate the existing database to PostgreSQL running on Compute Engine
  Đây chỉ là self-managed PostgreSQL trên VM cloud (tương tự on-prem), vẫn cần DBA/ops team tự install, patch, backup, monitor. Không giảm migration effort (gần như copy VM), chi phí VM + storage cao hơn managed service, không tận dụng managed benefits. Vi phạm mục tiêu minimize costs và ops effort.

📚 Tài liệu tham khảo

• Cloud SQL for PostgreSQL docs: cloud.google.com/sql/docs/postgres (cập nhật 2026: PostgreSQL 17 support).
• Database Migration Service: cloud.google.com/database-migration – Hướng dẫn migrate from on-prem PostgreSQL.
• Pricing calculator: cloud.google.com/products/calculator – Xác nhận low cost cho light traffic (~$15/tháng Shared Core).
• GCP Certification Guide (Professional Cloud Database Engineer): Khuyến nghị Cloud SQL cho PostgreSQL workloads tương tự.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần ví dụ migrate cụ thể, hỏi thêm nhé! 😊

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

Câu hỏi mô tả tình huống: Tổ chức của bạn đang cập nhật một ứng dụng doanh nghiệp hiện có chạy trên một public cloud khác (không phải Google Cloud, ví dụ AWS hoặc Azure) để truy cập các dịch vụ managed database trên Google Cloud. Ứng dụng sẽ vẫn giữ nguyên ở public cloud kia, chỉ migrate database sang Google Cloud. Yêu cầu tuân thủ best practices khuyến nghị từ Google cho authentication, đồng thời giảm thiểu gián đoạn cho người dùng (minimize user disruption) trong quá trình migration.

🛠️ Vấn đề cốt lõi: Cần thiết lập xác thực an toàn giữa ứng dụng ở cloud ngoài và database ở Google Cloud, tránh sử dụng key files dễ bị lộ (như service account key), ưu tiên phương pháp không gián đoạn và bảo mật cao theo hướng dẫn Google (cross-cloud authentication).

📘 Kiến thức cập nhật đến 2026: Theo tài liệu AWS/GCP hybrid mới nhất (GCP IAM Workload Identity Federation v2, hỗ trợ OIDC tokens từ AWS STS), Google ưu tiên Workload Identity Federation cho các workload multi-cloud để impersonate service account mà không cần long-lived credentials. (Nguồn: Google Cloud IAM Workload Identity Federation, Best practices for migrating to Google Cloud databases).

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

Đáp án đúng: Use workload identity federation to impersonate a service account.
🧩 Lý do: Đây là best practice chính thức của Google cho authentication cross-cloud (ứng dụng ở AWS/Azure truy cập GCP resources như Cloud SQL, AlloyDB). Phương pháp này cho phép workload từ cloud ngoài exchange OIDC token (từ AWS STS hoặc tương tự) để impersonate GCP service account tạm thời, không cần tạo/share service account key (giảm rủi ro lộ key). Không gián đoạn người dùng vì ứng dụng chỉ cần config IAM policy federation mapping (pool/provider), không thay đổi code lớn. Hỗ trợ database services như Cloud SQL với private IP hoặc authorized networks. ✅ Hoàn hảo cho hybrid setup!

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

• ✅ Use workload identity federation to impersonate a service account.
  🛠️ Đúng vì: Cho phép ứng dụng ở cloud ngoài (workload) sử dụng identity provider OIDC (như AWS) để federate và impersonate GCP service account, cấp quyền truy cập database (ví dụ IAM roles như Cloud SQL Client). An toàn (short-lived tokens), không cần migrate app, zero disruption. Google khuyến nghị cho multi-cloud migration từ 2021-2026. (Nguồn: GCP Docs - Configure federation).

• ❌ Ask existing users to set their Google password to match their corporate password.
  🛠️ Sai vì: Đây không phải best practice authentication cho ứng dụng/workload, mà dành cho user login cá nhân (không liên quan đến app-to-DB). Yêu cầu user thay đổi password gây gián đoạn lớn (disruption cao), không an toàn (password sync dễ bị brute-force), và không hỗ trợ service accounts. Google cấm khuyến khích password matching cho enterprise.

• ❌ Migrate the application to Google Cloud, and use Identity and Access Management (IAM).
  🛠️ Sai vì: Câu hỏi rõ ràng yêu cầu ứng dụng vẫn ở public cloud khác ("The application will remain in the other public cloud"), nên migrate app vi phạm yêu cầu. IAM chỉ hiệu quả full trong GCP; cross-cloud cần federation. Gây disruption cao do refactor/migrate app lớn.

• ❌ Use Google Workspace Password Sync to replicate passwords into Google Cloud.
  🛠️ Sai vì: Google Workspace Password Sync chỉ sync user passwords từ Active Directory cho SSO user login (Workspace/GSuite), không dành cho application workload hoặc DB access. Không hỗ trợ service auth cross-cloud, vẫn cần credentials riêng, và không minimize disruption (phải config Workspace enterprise-wide). Không phải recommended cho DB migration. (Nguồn: Google Workspace Password Sync Docs).

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

Câu hỏi tập trung vào việc cấu hình mạng cho một instance Cloud SQL trên Google Cloud Platform (GCP). Tình huống cụ thể:

• Chỉ có một ứng dụng duy nhất kết nối đến database này, và ứng dụng nằm trên Compute Engine VM cùng project với Cloud SQL.
• Cả VM và Cloud SQL đều sử dụng cùng một VPC network.
• Cả hai đều có external (public) IP và internal (private) IP.
• Mục tiêu: Cải thiện bảo mật mạng (network security) bằng cách giảm thiểu rủi ro tiếp xúc với internet.

🛠️ Vấn đề cốt lõi: Public IP của Cloud SQL cho phép kết nối từ bất kỳ đâu qua internet (nếu được authorize), dễ bị tấn công. Vì kết nối chỉ từ VM nội bộ (cùng VPC), nên ưu tiên sử dụng private IP để hạn chế truy cập từ bên ngoài, tăng cường bảo mật mà không ảnh hưởng đến ứng dụng.

📘 Kiến thức cập nhật (đến 2026): Theo tài liệu GCP mới nhất (Cloud SQL for PostgreSQL/MySQL/SQL Server phiên bản 2024-2026), kết nối private qua VPC native networking được khuyến nghị cho các trường hợp nội bộ. Không cần Private Service Connect trừ khi cross-project/VPC.

Nguồn tham khảo:

• Cloud SQL Networking Best Practices (Google Cloud Docs, cập nhật 2025).
• Private IP for Cloud SQL.

✅ Đáp án đúng

Disable and remove the external IP address assignment.

Lý do lựa chọn:

• 🛡️ Việc loại bỏ public IP trên Cloud SQL ngăn chặn hoàn toàn kết nối từ internet, chỉ cho phép kết nối qua private IP nội bộ trong cùng VPC.
• VM có thể kết nối trực tiếp qua private IP của Cloud SQL (không cần public IP trên VM).
• Đây là cách tối ưu bảo mật nhất theo nguyên tắc least privilege: Giảm bề mặt tấn công mà không làm gián đoạn ứng dụng.
• Không ảnh hưởng đến hiệu suất, vì private IP có latency thấp hơn public IP trong cùng region/VPC.

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

• [SAI] Disable and remove the internal IP address assignment.
  ❌ Sai vì: Loại bỏ private IP sẽ khiến Cloud SQL không thể kết nối nội bộ từ VM (cùng VPC). VM chỉ còn cách dùng public IP (nếu có), làm giảm bảo mật thay vì cải thiện. Private IP là bắt buộc cho kết nối an toàn nội bộ.

• [SAI] Disable both the external IP address and the internal IP address, and instead rely on Private Google Access.
  ❌ Sai vì: Private Google Access chỉ cho phép VM private IP truy cập Google APIs/services qua private network (như cloudsql.googleapis.com), không thay thế private IP trực tiếp trên Cloud SQL instance. Cloud SQL cần private IP để expose endpoint nội bộ; nếu tắt cả hai, instance sẽ không accessible từ VM.

• [SAI] Specify an authorized network with the CIDR range of the VM.
  ❌ Sai vì: Authorized networks chỉ áp dụng cho kết nối public IP (whitelist CIDR để cho phép kết nối từ internet). Nó không ngăn chặn public access từ các nguồn khác và vẫn expose Cloud SQL ra internet – trái ngược mục tiêu bảo mật. Nên dùng private IP thay vì authorized networks.

• [ĐÚNG] Disable and remove the external IP address assignment.
  ✅ Đúng như đã giải thích ở trên: Tập trung loại bỏ public exposure, tận dụng private IP sẵn có cho kết nối nội bộ an toàn.

🧩 Lời khuyên thực hành: Sau khi apply, test kết nối từ VM bằng private IP (ví dụ: psql -h <private-ip> -U user dbname). Nếu cần cross-region, xem xét Private Service Connect (cập nhật 2025).

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

Câu hỏi mô tả tình huống quản lý hai ứng dụng khác nhau: Order Management (quản lý đơn hàng) và Sales Reporting (báo cáo bán hàng). Cả hai đều tương tác với cùng một cơ sở dữ liệu Cloud SQL for MySQL trên Google Cloud.

• Order Management: Thực hiện đọc (read) và ghi (write) liên tục 24/7, đòi hỏi hiệu suất cao và ổn định.
• Sales Reporting: Chỉ đọc (read-only), cần dữ liệu mới nhất (latest data).
• Yêu cầu chính: Đảm bảo hiệu suất của Order Management không bị ảnh hưởng bởi Sales Reporting (tránh tình trạng read traffic từ báo cáo làm chậm primary instance).

🛠️ Mục tiêu: Tối ưu hóa read traffic bằng cách tách biệt workload read-only khỏi primary instance, mà vẫn giữ dữ liệu đồng bộ gần thời gian thực (real-time replication). Đây là best practice trong Cloud SQL để scale reads mà không ảnh hưởng writes.

📘 Nguồn tham khảo:

• Cloud SQL for MySQL: Read replicas documentation (cập nhật đến 2024, hỗ trợ high availability và low-latency replication <1 giây).
• Google Cloud Architecture Framework: Scaling Databases (2023-2026 updates emphasize read replicas for read-heavy workloads).

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

Đáp án đúng: Create a read replica for the Sales Reporting application.

🧩 Lý do chi tiết:

• Cloud SQL for MySQL hỗ trợ read replicas (bản sao chỉ đọc), tự động replicate dữ liệu từ primary instance với độ trễ thấp (thường <1 giây, gần real-time).
• Sales Reporting kết nối đến read replica để đọc dữ liệu mới nhất, offload toàn bộ read traffic khỏi primary → Order Management (read/write 24/7) không bị ảnh hưởng hiệu suất.
• Dễ triển khai: Tạo replica qua Console/CLI/gcloud, hỗ trợ multi-zone/multi-region cho HA và low latency.
• Chi phí tối ưu: Chỉ tính phí storage + compute cho replica, không double writes.

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

• ✅ Create a read replica for the Sales Reporting application.
  (Đúng, như giải thích ở trên): Đây là giải pháp chuẩn của Cloud SQL, scale reads hiệu quả mà giữ latest data và không impact primary performance. ✅ Hoàn hảo cho workload read-only 24/7.

• ❌ Create two separate databases in the instance, and perform dual writes from the Order Management application.
  (Sai): Tạo hai DB riêng trong cùng instance vẫn chia sẻ tài nguyên compute/storage → read traffic từ Sales Reporting vẫn ảnh hưởng Order Management. Dual writes (ghi đồng thời vào hai DB) phức tạp, dễ lỗi consistency, tăng latency writes và không đảm bảo latest data realtime. Không scale tốt, vi phạm nguyên tắc single source of truth. 🚫 Không khuyến nghị theo best practices Cloud SQL.

• ❌ Use a Cloud SQL federated query for the Sales Reporting application.
  (Sai): Federated query (query liên kết giữa các DB/instance) dùng cho cross-DB queries, nhưng overhead cao (network latency, query complexity), không offload read traffic thực sự khỏi primary. Sales Reporting vẫn query trực tiếp primary → vẫn ảnh hưởng performance Order Management. Không phù hợp read-only heavy load, và không đảm bảo low-latency latest data. 🕳️ Overhead lớn, chỉ dùng cho ad-hoc queries hiếm.

• ❌ Queue up all the requested reports in PubSub, and execute the reports at night.
  (Sai): Sử dụng Pub/Sub để queue reports rồi chạy batch vào ban đêm → dữ liệu KHÔNG latest (delay hàng giờ/ngày), vi phạm yêu cầu "both applications need the latest data". Không giải quyết read traffic realtime, Order Management vẫn bị ảnh hưởng nếu queue quá tải. Chỉ phù hợp non-real-time analytics, không phải reporting cần fresh data. 🌙 Delay quá lớn, không scale 24/7.

🛠️ Kết luận: Read replica là lựa chọn tối ưu nhất theo kiến thức Cloud SQL cập nhật 2026 (với cải tiến async replication và Prometheus metrics cho monitoring replica lag). Nếu cần scale hơn, có thể dùng multi-replicas hoặc AlloyDB cho enterprise workloads! 🚀

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

Câu hỏi mô tả tình huống bạn là DBA của một ứng dụng học trực tuyến chạy trên Cloud SQL for PostgreSQL (dịch vụ cơ sở dữ liệu PostgreSQL được quản lý bởi Google Cloud). Bạn đang kiểm tra cấu hình cross-regional failover (chuyển đổi dự phòng liên vùng).

• Cơ sở dữ liệu ở vùng R1 chuyển đổi thành công sang vùng R2, và ứng dụng có thể truy cập để xử lý dữ liệu.
• Một số kịch bản ứng dụng hoạt động bình thường ở R2, nhưng một vài kịch bản thất bại với lỗi cơ sở dữ liệu.
• Các truy vấn SQL từ ứng dụng, khi chạy riêng lẻ trực tiếp trên Cloud SQL ở R2, lại hoạt động bình thường.
• Khi chuyển ngược về R1, ứng dụng hoạt động hoàn hảo.

Mục tiêu: Xác định nguyên nhân lỗi cơ sở dữ liệu ở R2.

🛠️ Ngữ cảnh kỹ thuật (dựa trên tài liệu Google Cloud cập nhật đến 2024-2026): Cloud SQL hỗ trợ cross-region disaster recovery cho PostgreSQL qua read replicas (bản sao đọc) với độ trễ replication thấp (near-real-time, thường <1 giây). Khi failover, secondary (R2) trở thành primary, nhưng không phải bản sao exact 100% do có thể tồn tại replication lag (dữ liệu chưa đồng bộ kịp). Điều này gây lỗi nếu ứng dụng thực hiện chuỗi truy vấn phụ thuộc lẫn nhau (ví dụ: insert rồi select ngay lập tức), trong khi truy vấn đơn lẻ OK.

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

• Cloud SQL for PostgreSQL: Disaster recovery (xác nhận replication là asynchronous với low RPO/RTO).
• Cloud SQL high availability and disaster recovery (giải thích failover cross-region sử dụng read replicas, có lag tiềm ẩn).

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

Đáp án đúng: Determine whether Cloud SQL for PostgreSQL in region R2 is a near-real-time copy of region R1 but not an exact copy.

Lý do 🧩:

• Trong cấu hình cross-regional failover, R2 là read replica của R1 với replication near-real-time (không exact copy do lag nhỏ). Khi failover, một số giao dịch chưa replicate hoàn toàn có thể gây lỗi ở chuỗi truy vấn ứng dụng (app-dependent), nhưng truy vấn đơn lẻ OK vì dữ liệu đã sync phần lớn.
• Failback về R1 OK vì R1 là nguồn gốc exact. Đây là nguyên nhân chính, phù hợp triệu chứng: một số scenarios fail, queries isolate OK.
• Phiên bản mới nhất (2026): Cloud SQL vẫn giữ mô hình này, không hỗ trợ zero-lag cross-region (khuyến nghị dùng AlloyDB cho strict consistency nếu cần).

📋 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 tiếng Anh:

• Determine whether the versions of Cloud SQL for PostgreSQL in regions R1 and R2 are different.
  ❌ Sai: Cloud SQL tự động đảm bảo cùng phiên bản PostgreSQL giữa primary và read replicas cross-region (theo policy Google Cloud). Không có sự khác biệt version gây lỗi sau failover thành công. Triệu chứng không khớp (queries isolate OK ở R2).

• Determine whether the database patches of Cloud SQI for PostgreSQL in regions R1 and R2 are different.
  ❌ Sai: "Cloud SQI" có lẽ là lỗi đánh máy của "Cloud SQL". Patches (bản vá) được áp dụng đồng bộ qua Cloud SQL maintenance windows, không khác biệt giữa regions. Failover thành công và app partial OK loại trừ vấn đề này.

• Determine whether the failover of Cloud SQL for PostgreSQL from region R1 to region R2 is in progress or has completed successfully.
  ❌ Sai: Câu hỏi đã nêu rõ "fails over successfully" và "database becomes available", nên failover đã hoàn tất. Nếu đang progress, toàn bộ app sẽ fail, không phải chỉ vài scenarios.

• Determine whether Cloud SQL for PostgreSQL in region R2 is a near-real-time copy of region R1 but not an exact copy.
  ✅ Đúng: Như giải thích trên, đây chính là đặc trưng của read replica cross-region (low-latency async replication). Lag nhỏ gây inconsistency ở app workflows phức tạp, khớp hoàn hảo với triệu chứng. Kiểm tra bằng pg_stat_replication hoặc Cloud SQL insights để confirm lag.

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

Câu hỏi tập trung vào việc di chuyển (migrate) các cơ sở dữ liệu on-premises bao gồm MySQL, PostgreSQL và Microsoft SQL Server lên Google Cloud. Yêu cầu chính là:

• Near-zero downtime (thời gian ngừng hoạt động gần như bằng không, tức là migration liên tục mà không làm gián đoạn ứng dụng).
• Không cần thay đổi ứng dụng (no application changes).
• Hỗ trợ Change Data Capture (CDC) – cơ chế ghi nhận và đồng bộ các thay đổi dữ liệu thời gian thực từ nguồn sang đích.

📘 Mục tiêu: Tìm giải pháp tích hợp sẵn của Google Cloud phù hợp nhất cho migration database đa nền tảng (MySQL, PostgreSQL, SQL Server) từ on-prem lên Cloud SQL hoặc AlloyDB, đảm bảo tính liên tục kinh doanh cao. Đây là kịch bản phổ biến trong chứng chỉ Professional Cloud Database Engineer, nhấn mạnh vào Database Migration Service (DMS).

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

Đáp án đúng: Use Database Migration Service.
🛠️ Lý do:
Google Cloud Database Migration Service (DMS) là dịch vụ chuyên dụng cho migration database với hỗ trợ đầy đủ CDC, cho phép continuous migration (di chuyển liên tục) từ on-premises MySQL, PostgreSQL, SQL Server sang Cloud SQL hoặc AlloyDB. Nó đảm bảo near-zero downtime bằng cách replicate dữ liệu ban đầu (one-time migration) rồi chuyển sang CDC để đồng bộ thay đổi realtime, không yêu cầu thay đổi code ứng dụng. DMS tự động xử lý schema conversion, data validation và hỗ trợ các engine này theo tài liệu cập nhật 2024-2026 (phiên bản mới nhất hỗ trợ SQL Server 2022 và PostgreSQL 16).
Nguồn tham khảo: Google Cloud DMS Documentation và Migration Guide for SQL Server.

📋 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 một cách chi tiết, với giữ nguyên văn bản gốc và đánh dấu ✅/❌ rõ ràng:

• ❌ Use the native export and import functionality of the source database.
  🧨 Sai vì: Phương pháp export/import gốc (như mysqldump cho MySQL, pg_dump cho PostgreSQL, hoặc BCP cho SQL Server) chỉ hỗ trợ batch migration một lần (one-time dump), dẫn đến downtime cao (phải dừng ứng dụng để export dữ liệu lớn). Không hỗ trợ CDC realtime, không đảm bảo near-zero downtime, và có thể yêu cầu thay đổi ứng dụng để xử lý schema khác biệt. Không phù hợp cho production migration quy mô lớn.

• ❌ Create a database on Google Cloud, and use database links to perform the migration.
  🧨 Sai vì: Database links (như Oracle DB links hoặc federated links trong PostgreSQL/MySQL) chỉ dùng để query liên kết giữa các DB, không phải công cụ migration chuyên dụng. Nó không hỗ trợ CDC, downtime cao (phải sync thủ công), và không tự động replicate dữ liệu lớn hoặc xử lý schema conversion. Trong Google Cloud, không có tính năng native "database links" cho migration đa engine này, dễ gây lỗi và không scalable.

• ❌ Create a database on Google Cloud, and use Dataflow for database migration.
  🧨 Sai vì: Apache Beam/Dataflow là dịch vụ ETL/batch/streaming cho dữ liệu lớn, không chuyên cho database migration. Nó yêu cầu viết custom pipeline (thay đổi code ứng dụng), không hỗ trợ CDC native cho MySQL/PostgreSQL/SQL Server, và downtime cao do xử lý batch. Dataflow phù hợp hơn cho analytics, không phải homogeneous/heterogeneous DB migration với near-zero downtime.

• ✅ Use Database Migration Service.
  🛠️ Đúng vì: Như đã giải thích ở trên, DMS là giải pháp tối ưu nhất của Google Cloud (cập nhật 2026), hỗ trợ tất cả yêu cầu: CDC qua Debezium engine, one-time + continuous replication, zero app changes, và validate dữ liệu tự động. Hỗ trợ đầy đủ MySQL 8+, PostgreSQL 16+, SQL Server 2022 từ on-prem/VPN/Direct Connect.
  Nguồn: DMS CDC Overview.

Kết luận 🎯: DMS là lựa chọn chuẩn xác 100% cho kịch bản này, giúp doanh nghiệp migrate an toàn và nhanh chóng lên Google Cloud! Nếu cần lab thực hành, tham khảo Qwiklabs Google Cloud Skills Boost.