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 yêu cầu một giải pháp di chuyển (migrate) các cơ sở dữ liệu quan hệ (relational databases) từ Oracle, MySQL, Microsoft SQL Server và PostgreSQL sang Google Cloud. Yêu cầu chính là sử dụng giải pháp cơ sở dữ liệu hoàn toàn được quản lý (fully managed) và linh hoạt (flexible) khi có thể.

📌 Bối cảnh chính:

• Công ty muốn di chuyển tất cả các loại DB này một cách tối ưu.
• Fully managed nghĩa là Google Cloud sẽ xử lý việc quản lý hạ tầng, backup, scaling, patching... để giảm gánh nặng vận hành.
• Flexible ám chỉ khả năng hỗ trợ đa dạng engine DB mà không cần tự quản lý VM.
• Cập nhật kiến thức mới nhất (đến 2026): Cloud SQL hỗ trợ đầy đủ MySQL, PostgreSQL, SQL Server (với các phiên bản enterprise mới nhất). Oracle không được hỗ trợ native trên Cloud SQL, mà dùng Bare Metal Solution (BMS) chuyên biệt cho Oracle workloads lớn, đảm bảo license compliance và performance cao.

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

Đáp án đúng: Migrate the MySQL, Microsoft SQL Server, and PostgreSQL databases to Cloud SQL, and migrate the Oracle databases to Bare Metal Solution for Oracle.

Lý do chọn đáp án này 🛠️:

• Cloud SQL là dịch vụ fully managed, flexible hỗ trợ chính xác MySQL, SQL Server và PostgreSQL (bao gồm high availability, auto-scaling, read replicas). Đây là lựa chọn tối ưu cho 3 loại DB này.
• Oracle không được hỗ trợ trên Cloud SQL, nên dùng Bare Metal Solution for Oracle – giải pháp chuyên dụng cho Oracle, chạy trên phần cứng bare metal vật lý trong Google Cloud, hỗ trợ license BYOL (Bring Your Own License), migration không downtime, và tích hợp với Google Cloud networking.
• Giải pháp này tối ưu hóa fully managed khi có thể (cho 3/4 DB), đồng thời linh hoạt cho Oracle. Phù hợp với best practices Google Cloud cho enterprise migration.

📋 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á dựa trên tính fully managed, hỗ trợ engine DB và tối ưu hóa:

• ❌ [SAI] Migrate all the databases to Cloud SQL.
  Giải thích sai: Cloud SQL không hỗ trợ Oracle (chỉ hỗ trợ MySQL, PostgreSQL, SQL Server). Việc migrate toàn bộ sẽ thất bại với Oracle, vi phạm yêu cầu fully managed và linh hoạt. Không phải giải pháp khả thi.

• ❌ [SAI] Migrate the Oracle, MySQL, and Microsoft SQL Server databases to Cloud SQL, and migrate the PostgreSQL databases to Compute Engine.
  Giải thích sai: Cloud SQL không hỗ trợ Oracle, nên Oracle sẽ không migrate được. PostgreSQL được hỗ trợ đầy đủ trên Cloud SQL (fully managed), không cần dùng Compute Engine (self-managed VM, tốn công quản lý). Giải pháp này thiếu fully managed cho Postgres và không khả thi cho Oracle.

• ❌ [SAI] Migrate the MySQL, Microsoft SQL Server, and PostgreSQL databases to Compute Engine, and migrate the Oracle databases to Bare Metal Solution for Oracle.
  Giải thích sai: Compute Engine là self-managed VM, không phải fully managed như yêu cầu ("fully managed when possible"). MySQL, SQL Server, PostgreSQL nên dùng Cloud SQL để tận dụng quản lý tự động, scaling linh hoạt. Phần Oracle đúng nhưng tổng thể không tối ưu, tăng chi phí vận hành.

• ✅ [ĐÚNG] Migrate the MySQL, Microsoft SQL Server, and PostgreSQL databases to Cloud SQL, and migrate the Oracle databases to Bare Metal Solution for Oracle.
  Giải thích đúng: Hoàn hảo khớp yêu cầu! Cloud SQL fully managed cho 3 DB (MySQL/SQL Server/PostgreSQL), Bare Metal Solution lý tưởng cho Oracle (performance cao, license Oracle certified). Đảm bảo linh hoạt và giảm thiểu tự quản lý.

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

• Cloud SQL Documentation: Cloud SQL Overview – Xác nhận hỗ trợ MySQL 8.x, PostgreSQL 16+, SQL Server 2022.
• Bare Metal Solution for Oracle: Bare Metal Solution for Oracle – Hướng dẫn migration Oracle RAC/Exadata.
• Database Migration Service: Database Migration – Công cụ hỗ trợ migrate từ on-prem sang Cloud SQL/BMS.
• Google Cloud Skills Boost: Professional Cloud Database Engineer certification guide (phiên bản 2024-2026).

Giải pháp này giúp migration an toàn, scalable và cost-effective! 🚀 Nếu cần chi tiết migration plan, hãy hỏi thêm nhé!

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

Câu hỏi tập trung vào việc quản lý tính sẵn sàng cao (High Availability - HA) của một instance Cloud SQL for PostgreSQL trên Google Cloud Platform (GCP). Cụ thể, bạn cần thử nghiệm failover (chuyển đổi dự phòng) để kiểm tra khả năng chuyển tiếp tự động hoặc thủ công sang replica khi primary instance gặp sự cố. Yêu cầu sử dụng lệnh gcloud (Google Cloud CLI) để thực hiện failover.

Mục tiêu chính: Failover trong Cloud SQL là quá trình tự động hoặc thủ công thăng cấp một read replica thành primary mới, đảm bảo ứng dụng không bị gián đoạn (downtime chỉ vài giây). Đây là tính năng cốt lõi của HA configuration, nơi primary và secondary replica được đồng bộ hóa liên tục. ✅ Phiên bản cập nhật mới nhất (2026): Cloud SQL hỗ trợ failover qua gcloud CLI phiên bản 4.x+, với cải tiến như failover nhanh hơn (dưới 60 giây) và hỗ trợ multi-zone/regional replicas.

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

Đáp án đúng: Use gcloud sql instances failover <PrimaryInstanceName>.

Lý do:

• Lệnh gcloud sql instances failover <PrimaryInstanceName> chính xác kích hoạt failover trên primary instance. Cloud SQL sẽ tự động chọn một read replica phù hợp (regional hoặc zonal) để thăng cấp thành primary mới, đồng thời giáng cấp primary cũ thành replica.
• Đây là cách chuẩn và được khuyến nghị để test HA theo tài liệu chính thức của Google Cloud. 🛠️ Không cần chỉ định replica cụ thể vì hệ thống tự xử lý.
• Ví dụ lệnh thực tế: gcloud sql instances failover my-primary-instance --project=my-project.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Tôi đánh dấu ✅ cho đúng và ❌ cho sai, kèm giải thích rõ ràng:

• ✅ Use gcloud sql instances failover <PrimaryInstanceName>.
  Đúng vì: Như đã giải thích ở trên, lệnh này nhắm đến primary instance để khởi tạo failover, đảm bảo HA hoạt động mượt mà. Đây là cú pháp chuẩn từ docs GCP. 🏆

• ❌ Use gcloud sql instances failover <ReplicaInstanceName>.
  Sai vì: Lệnh failover KHÔNG chấp nhận tên replica làm tham số. Nếu chạy với replica name, gcloud sẽ báo lỗi (ví dụ: "INVALID_ARGUMENT: Instance must be primary"). Phải dùng primary name để hệ thống tự chọn replica. 🚫

• ❌ Use gcloud sql instances promote-replica <PrimaryInstanceName>.
  Sai vì: Lệnh promote-replica dùng để thăng cấp replica thành standalone instance độc lập, không phải failover. Nếu dùng primary name, lệnh sẽ thất bại vì primary không phải replica. Điều này phá vỡ HA config thay vì test nó. 🔄

• ❌ Use gcloud sql instances promote-replica <ReplicaInstanceName>.
  Sai vì: Mặc dù cú pháp đúng cho promote-replica (thăng cấp một replica cụ thể thành primary độc lập), nhưng KHÔNG phù hợp để test failover HA. Nó tạo instance mới không đồng bộ, không giữ cấu hình HA gốc, và không mô phỏng chuyển đổi dự phòng thực tế. 💥

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

• Google Cloud SQL Docs - High Availability: https://cloud.google.com/sql/docs/postgres/high-availability#failover – Hướng dẫn chi tiết lệnh failover.
• gcloud CLI Reference: https://cloud.google.com/sdk/gcloud/reference/sql/instances/failover – Cú pháp chính thức.
• Cloud SQL Best Practices: https://cloud.google.com/sql/docs/postgres/best-practices – Test HA với failover (phiên bản 2026 hỗ trợ AI-driven failover predictions).

Hy vọng phân tích này giúp bạn nắm vững! Nếu cần demo lệnh thực tế, hãy cho biết thêm chi tiết instance. 🚀

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

Câu hỏi mô tả tình huống: Bạn đang sử dụng các script Python để tạo báo cáo SQL hàng tuần, nhằm đánh giá tình trạng cơ sở dữ liệu (databases), quyết định có cần tái tổ chức bảng (reorganize tables) hoặc chạy thống kê (run statistics) hay không. Mục tiêu là tự động hóa quy trình này nhưng phải giảm thiểu chi phí vận hành (operational costs) và gánh nặng quản lý (overhead).

🛠️ Yêu cầu chính: Cần một giải pháp serverless hoặc nhẹ nhàng, chạy theo lịch định kỳ (hàng tuần), chỉ tính phí khi thực thi, tránh các tài nguyên luôn chạy như VM hoặc các công cụ phức tạp không cần thiết. Điều này phù hợp với các dịch vụ Google Cloud hiện đại (cập nhật đến 2026), ưu tiên tính kinh tế và dễ quản lý.

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

Đáp án đúng: Create a Cloud Function, and call the Cloud Function using Cloud Scheduler.

Lý do:

• Cloud Functions là dịch vụ serverless, chỉ tính phí theo thời gian thực thi (pay-per-use), lý tưởng cho script Python chạy hàng tuần mà không cần máy chủ luôn bật.
• Cloud Scheduler kích hoạt hàm theo lịch cron (ví dụ: hàng tuần), tự động và đáng tin cậy, với overhead gần như bằng 0.
• Giải pháp này tối ưu chi phí nhất (chỉ vài cent mỗi lần chạy) và không yêu cầu quản lý infrastructure, phù hợp hoàn hảo với yêu cầu minimize costs/overhead. 📈 (Theo tài liệu GCP 2026, Cloud Scheduler hỗ trợ lên đến 1000 job miễn phí/tháng).

📋 Giải thích chi tiết 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. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể:

• ❌ [SAI] Create a VM in Compute Engine, and run a cron job.
  Giải thích sai: Tạo VM trong Compute Engine yêu cầu máy ảo luôn chạy (hoặc dùng preemptible nhưng vẫn overhead cao), cron job chỉ là scheduler cơ bản. Chi phí VM liên tục (kể cả idle) cao hơn nhiều so với serverless, vi phạm yêu cầu minimize costs/overhead. Không hiệu quả cho task nhẹ hàng tuần. 🤑 (Overkill!)

• ❌ [SAI] Create a Cloud Composer instance, and create a directed acyclic graph (DAG).
  Giải thích sai: Cloud Composer (dựa trên Apache Airflow) dành cho orchestration workflow phức tạp với nhiều DAG. Đối với script đơn giản hàng tuần, đây là giải pháp nặng nề, chi phí cao (instance luôn chạy ~$0.5/giờ + lưu trữ), overhead quản lý lớn (scaling, monitoring). Không cần thiết và đắt đỏ hơn serverless. 🔄 (Too complex!)

• ✅ [ĐÚNG] Create a Cloud Function, and call the Cloud Function using Cloud Function using Cloud Scheduler.
  Giải thích đúng: Như đã phân tích ở trên, kết hợp serverless (Cloud Functions cho Python script) + scheduler cron (Cloud Scheduler) là lựa chọn tối ưu. Chạy cold-start nhanh (<1s), tích hợp SQL queries dễ dàng, chi phí thấp nhất (~$0.0000025/ invocation). Hoàn hảo cho automation periodic với zero overhead. 🚀 (Best practice!)

• ❌ [SAI] Create a Cloud Function, and call the Cloud Function from a Cloud Tasks queue.
  Giải thích sai: Cloud Tasks dùng cho queueing tasks bất đồng bộ (async processing, retries), không phải scheduler định kỳ. Bạn vẫn cần trigger queue thủ công hoặc từ nguồn khác để chạy hàng tuần, dẫn đến overhead thêm và không tự động như cron. Không giải quyết scheduling trực tiếp, kém hiệu quả hơn Cloud Scheduler. ⏳ (Not for scheduling!)

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

• Cloud Scheduler Documentation – Hướng dẫn trigger Cloud Functions theo lịch.
• Cloud Functions Overview – Pay-per-use cho scripts Python/SQL.
• Best Practices for Scheduling – So sánh Scheduler vs Composer/Tasks.
• GCP Pricing Calculator 2026 – Xác nhận chi phí thấp cho Scheduler + Functions.

Giải pháp này đảm bảo scalability và tuân thủ nguyên tắc Well-Architected Framework của Google Cloud! 🌟

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

Câu hỏi tập trung vào tình huống một công ty đang sử dụng Cloud SQL for MySQL với địa chỉ IP nội bộ (private IP), và cần replicate (sao chép) một số bảng từ cơ sở dữ liệu này sang BigQuery theo thời gian gần thực tế (near-real time) để phục vụ phân tích dữ liệu và machine learning. Yêu cầu chính là đảm bảo quá trình replication nhanh chóng, đáng tin cậy và sử dụng dịch vụ được Google quản lý hoàn toàn (Google-managed services).

🔍 Các yếu tố quan trọng cần lưu ý:

• Cloud SQL có private IP nên không thể truy cập công khai từ bên ngoài mà không qua VPC hoặc các dịch vụ nội bộ.
• Near-real time nghĩa là độ trễ thấp (thường vài giây đến phút), không phải batch processing chậm.
• Phải dùng dịch vụ managed để tránh tự phát triển, đảm bảo scalability và reliability.
• Giải pháp phải hỗ trợ Change Data Capture (CDC) để capture thay đổi liên tục từ MySQL.

Dựa trên kiến thức Google Cloud cập nhật đến năm 2026 (phiên bản mới nhất của Datastream và Dataflow hỗ trợ CDC từ Cloud SQL for MySQL với private IP qua VPC peering), đây là bài kiểm tra về các công cụ replication managed cho analytics pipeline.

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

Đáp án đúng: Use Datastream to capture changes, and use Dataflow to write those changes to BigQuery.

Lý do chi tiết 📘:

• Datastream là dịch vụ CDC managed của Google, chuyên capture thay đổi log-based (như binlog của MySQL) từ Cloud SQL (hỗ trợ private IP qua VPC) với độ trễ near-real time (thường <1 phút).
• Kết hợp Dataflow (Apache Beam managed) để stream changes từ Datastream sink vào BigQuery, đảm bảo exactly-once delivery, schema evolution, và backfill dữ liệu lịch sử.
• Toàn bộ là Google-managed, scalable, reliable (SLA 99.9%), hỗ trợ MySQL 5.7/8.0, và tích hợp native với BigQuery cho ML/analytics.
• Đây là best practice theo Google Cloud architecture blueprint cho real-time analytics từ OLTP databases (Cloud SQL) sang data warehouse (BigQuery).

Nguồn tham khảo:

• Datastream documentation (cập nhật 2026: hỗ trợ Cloud SQL private IP với Serverless VPC Access).
• Dataflow templates for Datastream to BigQuery.
• Google Cloud Architecture Center: "Streaming data from Cloud SQL to BigQuery".

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

• ❌ [SAI] Develop a custom data replication service to send data into BigQuery.
  Phương án này yêu cầu tự phát triển service (ví dụ dùng Debezium + Kafka + custom sink), không phải Google-managed. Nó phức tạp, tốn kém maintain, dễ lỗi scalability/reliability, và không đảm bảo near-real time với private IP mà không config VPC phức tạp. Không phù hợp yêu cầu "Google-managed services".

• ❌ [SAI] Use Cloud SQL federated queries.
  Federated queries cho phép BigQuery query trực tiếp vào Cloud SQL qua external connection (hỗ trợ private IP), nhưng không replicate dữ liệu mà chỉ query on-the-fly. Độ trễ cao (query time), không lưu trữ dữ liệu vào BigQuery cho analytics/ML nhanh, và không hỗ trợ CDC changes. Không đáp ứng "replicate into BigQuery".

• ❌ [SAI] Use Database Migration Service to replicate tables into BigQuery.
  Database Migration Service (DMS) chủ yếu dùng cho one-time migration hoặc continuous migration sang Cloud SQL/AlloyDB/Spanner, không hỗ trợ trực tiếp BigQuery làm sink (BigQuery không phải RDBMS). DMS hỗ trợ CDC nhưng chỉ cho database-to-database, không phải database-to-data-warehouse như BigQuery. Không near-real time optimized cho analytics.

• ✅ [ĐÚNG] Use Datastream to capture changes, and use Dataflow to write those changes to BigQuery.
  Như đã giải thích ở trên: Datastream capture CDC managed + Dataflow stream sink vào BigQuery. Hoàn hảo cho near-real time, private IP, và fully managed. Hỗ trợ backfill, schema changes, dead letter queue cho reliability.

Tóm tắt khuyến nghị 🚀: Triển khai Datastream profile cho Cloud SQL MySQL, chọn Dataflow template làm sink, config VPC connector cho private IP. Test với small tables trước khi scale!

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

Câu hỏi mô tả việc thiết kế một ứng dụng physician portal app (cổng thông tin cho bác sĩ) được xây dựng bằng Node.js, sử dụng trong bệnh viện và phòng khám có thể gặp tình trạng kết nối internet gián đoạn. Khi mất kết nối, ứng dụng phải có khả năng truy vấn dữ liệu đã được cache (dữ liệu lưu cục bộ). Ngoài ra, ứng dụng cần đảm bảo các yêu cầu sau:

• Scalability (khả năng mở rộng tự động).
• Strong consistency (tính nhất quán mạnh, dữ liệu luôn đồng bộ chính xác).
• Multi-region replication (sao chép dữ liệu đa vùng để tăng độ tin cậy và giảm độ trễ).

📌 Mục tiêu chính: Chọn giải pháp database phù hợp cho Google Cloud, hỗ trợ offline caching (lưu trữ cục bộ khi offline), đồng thời đáp ứng các đặc tính scalability, strong consistency và multi-region.

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

Đáp án đúng: Use Firestore and ensure that the PersistenceEnabled option is set to true.

Lý do 🛠️:

• Firestore là NoSQL database serverless của Google Cloud, tự động scale theo nhu cầu, hỗ trợ strong consistency (đọc/ghi nhất quán mạnh) và multi-region replication (có thể cấu hình multi-region cho độ sẵn sàng cao).
• PersistenceEnabled = true kích hoạt offline persistence, cho phép ứng dụng (qua Firebase SDK cho Node.js) cache dữ liệu cục bộ trên thiết bị. Khi mất kết nối, app vẫn query cached data mượt mà, và dữ liệu sẽ sync lại khi online.
• Hoàn hảo cho app y tế cần độ tin cậy cao ở môi trường kết nối kém. Đây là tính năng chính thức của Firestore (cập nhật đến 2026, vẫn là best practice).

📋 Giải thí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 văn bản gốc tiếng Anh. Tôi đánh dấu ✅ cho đúng và ❌ cho sai, kèm lý do cụ thể:

• ✅ [ĐÚNG] Use Firestore and ensure that the PersistenceEnabled option is set to true.
  🧩 Đúng vì: Như đã giải thích ở trên, Firestore đáp ứng toàn bộ yêu cầu (offline cache qua persistence, scalability tự động, strong consistency, multi-region). Tính năng persistence được hỗ trợ đầy đủ trong Firebase SDK v10+ (2026), lý tưởng cho Node.js app.

• ❌ [SAI] Use Memorystore for Memcached.
  🛠️ Sai vì: Memorystore for Memcached chỉ là in-memory cache (không persistent), không hỗ trợ strong consistency hay multi-region replication cho dữ liệu chính. Nó chỉ cache tạm thời, mất dữ liệu khi restart hoặc mất kết nối, không query được khi offline thực sự. Không phù hợp làm primary database cho app y tế.

• ❌ [SAI] Use Pub/Sub to synchronize the changes from the application to Cloud Spanner.
  📘 Sai vì: Pub/Sub là messaging service để đồng bộ thay đổi, không cung cấp offline caching hay query cục bộ. Cloud Spanner tuy có strong consistency và multi-region, nhưng cách này phức tạp, không tự động cache, và không giải quyết vấn đề intermittent connectivity trực tiếp.

• ❌ [SAI] Use Table.read with the exactStaleness option to perform a read of rows in Cloud Spanner.
  🔍 Sai vì: Cloud Spanner hỗ trợ exactStaleness=0 cho strong consistent reads, scalability và multi-region, nhưng không có cơ chế offline persistence/cache cục bộ như Firestore. App không thể query khi mất kết nối internet, vi phạm yêu cầu chính của câu hỏi.

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

• Firestore Offline Persistence: Firebase Docs - Access data offline (v10.15+, hỗ trợ Node.js).
• Firestore Features: Cloud Firestore Documentation - Quotas & Scalability và Multi-region configs.
• So sánh với Spanner/Memorystore: Google Cloud Database Comparison.
• Node.js SDK: Firestore Node.js SDK.

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 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ả tình huống bạn đang quản lý một cơ sở dữ liệu MySQL sản xuất chạy trên Cloud SQL (dịch vụ của Google Cloud Platform - GCP) tại một công ty bán lẻ. Bạn thường thực hiện bảo trì định kỳ (routine maintenance) vào Chủ Nhật lúc nửa đêm (midnight) khi lưu lượng truy cập thấp. Tuy nhiên, bạn muốn bỏ qua (skip) các lần bảo trì này trong mùa mua sắm cuối năm (year-end holiday shopping season) để đảm bảo hệ thống sản xuất luôn có sẵn 24/7 trong kỳ nghỉ lễ.
📌 Yêu cầu chính: Cấu hình để bảo trì chỉ diễn ra vào cửa sổ Chủ Nhật 12 AM - 1 AM thông thường, nhưng từ chối (deny) bảo trì trong khoảng thời gian cụ thể từ đầu tháng 11 đến giữa tháng 1 (mùa lễ hội). Điều này liên quan đến tính năng maintenance policy của Cloud SQL, giúp kiểm soát lịch bảo trì tự động mà không làm gián đoạn dịch vụ cao điểm.
🛠️ Bối cảnh kỹ thuật: Cloud SQL tự động xử lý bảo trì (như cập nhật bản vá, nâng cấp phiên bản), nhưng admin có thể tùy chỉnh maintenance window (cửa sổ ưu tiên) và denied maintenance periods (khoảng thời gian cấm bảo trì) theo tài liệu GCP mới nhất (cập nhật đến 2026).

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

Đáp án đúng: Define a maintenance window on Sundays between 12 AM and 1 AM, and deny maintenance periods between November 1 and January 15.
Lý do:

• Phương án này chính xác khớp với tính năng maintenance policy của Cloud SQL (ra mắt từ 2021 và cập nhật ổn định đến 2026). Bạn định nghĩa preferred maintenance window (cửa sổ bảo trì ưu tiên: Chủ Nhật 12 AM - 1 AM, khớp với lịch routine hiện tại). Đồng thời, sử dụng denied maintenance periods (khoảng cấm: Nov 1 - Jan 15) để skip hoàn toàn bảo trì trong mùa lễ hội, đảm bảo high availability 24/7.
• Không cần công cụ bên ngoài, chỉ dùng console/GCLI/Cloud SQL Admin API. Đây là cách tối ưu, tự động và không downtime ngoài cửa sổ định sẵn.
  📘 Nguồn tham khảo:
• Cloud SQL Maintenance Windows (GCP Docs, cập nhật 2025).
• Define Denied Maintenance Periods (hướng dẫn chính thức).

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

Dưới đây là phân tích từng phương án một cách chi tiết. Tôi giữ nguyên nội dung văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với emoji nổi bật:

• Define a maintenance window on Sundays between 12 AM and 1 AM, and deny maintenance periods between November 1 and January 15.
  ✅ ĐÚNG 🏆: Như đã giải thích ở trên, đây là cách chuẩn xác sử dụng maintenance window (ưu tiên Chủ Nhật 12 AM - 1 AM) và deny periods (Nov 1 - Jan 15, phù hợp mùa lễ hội Mỹ: Black Friday đến sau Giáng sinh). Đảm bảo skip bảo trì tự động mà không cần can thiệp thủ công, khớp hoàn hảo yêu cầu 24/7 availability.

• Define a maintenance window on Sundays between 12 AM and 5 AM, and deny maintenance periods between November 1 and February 15.
  ❌ SAI 🚫: Mặc dù dùng đúng tính năng maintenance policy, nhưng cửa sổ quá dài (12 AM - 5 AM thay vì 1 giờ ngắn gọn như routine hiện tại, tăng rủi ro downtime). Khoảng deny quá rộng (đến Feb 15, vượt mùa lễ hội cần thiết). Không khớp chính xác lịch yêu cầu, có thể gây gián đoạn không mong muốn.

• Build a Cloud Composer job to start a maintenance window on Sundays between 12 AM and 1AM, and deny maintenance periods between November 1 and January 15.
  ❌ SAI ⚠️: Cloud Composer (dịch vụ orchestration dựa Apache Airflow trên GCP) không dùng để khởi động hoặc kiểm soát maintenance window của Cloud SQL. Tính năng này là native của Cloud SQL, không cần workflow phức tạp. Sử dụng Composer sẽ tốn kém, phức tạp và không đáng tin cậy (có thể fail job), vi phạm nguyên tắc đơn giản hóa.

• Create a Cloud Scheduler job to start maintenance at 12 AM on Sundays. Pause the Cloud Scheduler job between November 1 and January 15.
  ❌ SAI 🔧: Cloud Scheduler chỉ dùng để trigger job (như cron job), không thể khởi động maintenance của Cloud SQL (bảo trì là tự động, không "start" thủ công). Việc pause chỉ dừng scheduler chứ không skip maintenance tự động của GCP. Sai cơ bản về kiến trúc, dẫn đến bảo trì vẫn xảy ra ngoài ý muốn.

🧠 Kết luận nổi bật: Chọn phương án đúng giúp tối ưu hóa HA cho Cloud SQL mà không cần tool ngoài. Nếu áp dụng thực tế, dùng GCP Console > Cloud SQL > Edit Maintenance Policy để cấu hình ngay! 🚀

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

Câu hỏi tập trung vào việc di chuyển (migrate) một cơ sở dữ liệu Microsoft SQL Server dung lượng 100 TB từ on-premises sang Google Cloud qua kết nối mạng 1 Gbps, với thời gian downtime cho phép chỉ 48 giờ.
📊 Tính toán thời gian truyền dữ liệu để hiểu vấn đề:

• 100 TB = 100 × 1.024^4 bytes ≈ 1,1 × 10^14 bytes.
• 1 Gbps = 125 MB/s (1 Gbit/s = 10^9 bit/s ÷ 8 = 125 × 10^6 bytes/s).
• Thời gian truyền với 1 Gbps: ≈ 800.000 giây ≈ 9,3 ngày (vượt quá 48 giờ).
  Mục tiêu là chọn hai hành động phù hợp để hoàn thành migration trong thời hạn, sử dụng các chiến lược như offline migration (dịch chuyển toàn bộ dữ liệu một lần, downtime lớn) hoặc CDC (change data capture - theo dõi và đồng bộ thay đổi dữ liệu để giảm downtime).
  🛠️ Bối cảnh Google Cloud: Sử dụng Database Migration Service (DMS) hỗ trợ CDC cho SQL Server, kết hợp Transfer Appliance hoặc Storage Transfer Service cho dữ liệu lớn, và khuyến nghị tăng băng thông mạng (Dedicated Interconnect hoặc Partner Interconnect lên 10 Gbps) cho migration nhanh.

✅ Đáp án đúng (Chọn hai):

1. Use a change data capture (CDC) migration strategy.
2. Increase the network bandwidth to 10 Gbps, and then perform an offline data migration.

Lý do lựa chọn:

• Với 48 giờ downtime hạn chế và dữ liệu 100 TB, CDC (qua Google Cloud DMS) cho phép migration online/half-downtime: Truyền dữ liệu ban đầu + theo dõi thay đổi liên tục, chỉ cutover cuối cùng (downtime ngắn). Phù hợp SQL Server on-prem sang Cloud SQL hoặc AlloyDB.
• Tăng lên 10 Gbps offline: Thời gian truyền ≈ 22 giờ (<48 giờ), khả thi với Interconnect 10 Gbps. Kết hợp hai cách để linh hoạt (CDC cho continuous sync, 10 Gbps cho full load nhanh).
  ✅ Hai lựa chọn này đảm bảo migration thành công theo best practices Google Cloud đến 2026 (DMS hỗ trợ CDC cải tiến cho large-scale DB).

📘 Giải thích tất cả các phương án (Đúng/Sai)

• ✅ Use a change data capture (CDC) migration strategy.
  Đúng: CDC là chiến lược migration online lý tưởng cho DB lớn như 100 TB SQL Server. DMS capture thay đổi từ transaction log, replicate realtime sang target (Cloud SQL/AlloyDB), giảm downtime chỉ còn cutover (vài phút). Không phụ thuộc hoàn toàn băng thông 1 Gbps, phù hợp 48 giờ. (Cập nhật DMS 2024-2026 hỗ trợ SQL Server CDC full-fidelity).

• ❌ Move the physical database servers from on-premises to Google Cloud.
  Sai: Không khả thi vì Google Cloud là cloud-native, không hỗ trợ di chuyển vật lý server (physical lift-and-shift). Phải dùng ảo hóa (VMware Engine) hoặc native services (Cloud SQL), không giải quyết vấn đề mạng/downtime.

• ❌ Keep the network bandwidth at 1 Gbps, and then perform an offline data migration.
  Sai: Với 1 Gbps, offline migration mất ~9,3 ngày > 48 giờ, vi phạm downtime limit. Không tối ưu, dễ timeout và rủi ro dữ liệu cũ.

• ❌ Increase the network bandwidth to 2 Gbps, and then perform an offline data migration.
  Sai: 2 Gbps chỉ giảm thời gian còn ~4,6 ngày vẫn > 48 giờ. Không đủ nhanh cho 100 TB, lãng phí chi phí tăng băng thông mà không đạt yêu cầu.

• ✅ Increase the network bandwidth to 10 Gbps, and then perform an offline data migration.
  Đúng: 10 Gbps (qua Cloud Interconnect) truyền 100 TB trong ~22 giờ < 48 giờ. Offline đơn giản, dùng gsutil/Transfer Service cho full dump SQL Server, phù hợp nếu kết hợp CDC cho validation.

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

• Google Cloud Database Migration Service (CDC cho SQL Server).
• Migrate large databases overview (Tính toán băng thông & 100 TB cases).
• Cloud Interconnect bandwidth (Hỗ trợ 10 Gbps+).
• AWS không liên quan trực tiếp (có lẽ nhầm lẫn chủ đề), nhưng tương đương AWS DMS/SCT cho tham chiếu cross-cloud.
  🛡️ Lưu ý: Luôn test pilot migration trước production!

🧩 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 mô tả tình huống bạn cần triển khai hàng trăm instance Cloud SQL for MySQL cho nhiều đội ngũ dự án trong vòng một tuần. Yêu cầu chính là đảm bảo tất cả các instance tuân thủ các tiêu chuẩn công ty, bao gồm:

• Quy ước đặt tên instance (naming conventions).
• Cấu hình database flags (các tham số cấu hình cơ sở dữ liệu).
• Tags (nhãn để quản lý và phân loại tài nguyên).

Mục tiêu là tìm cách tự động hóa việc tạo instance một cách hiệu quả, nhất quán và có khả năng mở rộng để xử lý số lượng lớn trong thời gian ngắn, tránh lỗi thủ công và đảm bảo tuân thủ tiêu chuẩn. Đây là bài toán điển hình về Infrastructure as Code (IaC) trong Google Cloud, đặc biệt với Cloud SQL (dịch vụ quản lý MySQL/PostgreSQL/SQL Server).

✅ Đáp án đúng: Automate instance creation by setting up Terraform scripts.

Lý do lựa chọn (chi tiết):
Terraform là công cụ IaC (Infrastructure as Code) được Google Cloud chính thức hỗ trợ, cho phép định nghĩa toàn bộ cấu hình instance Cloud SQL dưới dạng code (file .tf). Bạn có thể:

• Tự động hóa tạo hàng trăm instance qua script, lặp lại với biến (variables) để tùy chỉnh naming, flags, tags theo tiêu chuẩn công ty.
• Đảm bảo tính nhất quán 100%: Mọi instance đều giống hệt vì dựa trên cùng template code, dễ audit và version control (qua Git).
• Mở rộng nhanh: Chạy terraform apply với loop/for_each để tạo batch lớn trong vài giờ, phù hợp timeline 1 tuần.
• Tích hợp tốt với GCP: Module Terraform chính thức cho Cloud SQL hỗ trợ đầy đủ flags, tags, networking (VPC, private IP), backup policies (cập nhật đến 2026 với Terraform Provider v5.x+).
  Terraform vượt trội hơn các cách thủ công hoặc không phù hợp khác, giúp giảm thời gian từ hàng tuần xuống hàng giờ.

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

• ❌ Automate instance creation by writing a Dataflow job.
  Sai vì: Dataflow là dịch vụ xử lý dữ liệu lớn theo batch/streaming (dựa trên Apache Beam), không dùng để tạo/provision tài nguyên hạ tầng như Cloud SQL instance. Dataflow phù hợp cho ETL/analyze data, không hỗ trợ API tạo instance hay quản lý naming/flags/tags. Sử dụng sẽ phức tạp, không hiệu quả và vi phạm best practice GCP (không có module Dataflow cho IaC Cloud SQL).

• ✅ Automate instance creation by setting up Terraform scripts.
  Đúng vì: Như giải thích ở trên, Terraform là lựa chọn tối ưu cho IaC, hỗ trợ đầy đủ tùy chỉnh standards (naming via variables, flags qua settings.flags, tags qua resource_tags). Dễ scale cho hundreds instances với modules chính thức, tích hợp CI/CD (Cloud Build). Phù hợp nhất cho scenario lớn và tuân thủ.

• ❌ Create the instances using the Google Cloud Console UI.
  Sai vì: Console UI là cách thủ công, không tự động, chỉ phù hợp tạo vài instance. Với hàng trăm instance, sẽ mất hàng tuần, dễ lỗi (quên flags/tags), không đảm bảo nhất quán naming/standards giữa teams. Không scale được, vi phạm nguyên tắc automation trong GCP best practices.

• ❌ Create clones from a template Cloud SQL instance.
  Sai vì: Cloning Cloud SQL chỉ copy dữ liệu và cấu hình cơ bản từ instance gốc, nhưng giới hạn: Không dễ tùy chỉnh naming (clone giữ tên tương tự), tags/flags cần chỉnh thủ công sau, và quota cloning thấp (max 50 clones/instance/ngày đến 2026). Không phù hợp multiple projects/teams với standards khác nhau, dễ vượt quota và không automate batch lớn.

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

• Terraform cho Cloud SQL: cloud.google.com/sql/docs/mysql/terraform (Provider google v6.x+, hỗ trợ Cloud SQL Enterprise Plus 2026).
• Cloud SQL Best Practices: cloud.google.com/sql/docs/mysql/best-practices – Nhấn mạnh IaC với Terraform/Deployment Manager.
• GCP IaC Guide: cloud.google.com/architecture/framework/operational-excellence/using-terraform – Khuyến nghị Terraform cho provisioning lớn.
• Quay quota cloning: cloud.google.com/sql/quotas (cập nhật 2025-2026).

💡 Lời khuyên: Sử dụng Terraform modules từ Terraform Registry (google-cloud-sql-database) kết hợp variables cho teams để tối ưu! Nếu cần script mẫu, tôi có thể hỗ trợ thêm. 🚀

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

Câu hỏi tập trung vào việc thiết kế kiến trúc cost-effective (tiết kiệm chi phí) cho việc di chuyển 50 TB cơ sở dữ liệu Oracle sang Bare Metal Solution for Oracle trên Google Cloud (không phải AWS, mặc dù đề cập nhưng nội dung chính xác là GCP). Yêu cầu chính bao gồm:

• Backup phải sẵn sàng cho quick restore (khôi phục nhanh).
• Lưu trữ backup ít nhất 5 năm (long-term retention).
• Đáp ứng RTO ≤ 2 giờ (thời gian khôi phục hệ thống tối đa 2 giờ) và RPO ≤ 15 phút (mất dữ liệu tối đa 15 phút).
• Sử dụng kiến thức cập nhật đến 2026: Bare Metal Solution hỗ trợ flash storage (hiệu suất cao, đắt đỏ) cho database chính, standard storage (rẻ hơn) cho backup local gần đây, và Actifio OnVault (giải pháp backup tích hợp của GCP cho Bare Metal Oracle, hỗ trợ deduplication, quick restore từ snapshot, và retention dài hạn lên đến 5+ năm với chi phí thấp).

Mục tiêu là cân bằng hiệu suất cao (RTO/RPO nghiêm ngặt) và chi phí thấp bằng cách phân tầng storage: nhanh cho dữ liệu active, rẻ cho backup lâu dài. 📘 Tài liệu tham khảo: Google Cloud Bare Metal Solution for Oracle, Actifio OnVault Integration, cập nhật 2024-2026 (Actifio hỗ trợ SLA restore <2h, RPO 15p qua continuous data protection).

✅ Đáp án đúng

Lựa chọn thứ 2 là đáp án chính xác!
Lý do lựa chọn:

• Database chạy trên flash storage đảm bảo hiệu suất cao cho workload Oracle lớn (50TB), hỗ trợ RPO 15 phút qua incremental backup nhanh.
• Local backup gần đây trên standard storage (rẻ hơn flash ~50-70%) đáp ứng quick restore (RTO 2h) mà vẫn cost-effective, vì backup recent chỉ cần tốc độ trung bình.
• Actifio OnVault cho backup >1 ngày: Tích hợp native với Bare Metal, hỗ trợ deduplication/compression (giảm chi phí lưu 5 năm xuống <20% so với raw storage), quick restore toàn bộ DB <2h, và retention dài hạn. Không cần chuyển sang Cloud Storage (không optimal cho Oracle Bare Metal). 🛠️ Đây là best practice từ GCP blueprint cho Oracle migration.

📋 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 văn bản gốc tiếng Anh). Mỗi phương án được đánh giá đúng/sai dựa trên yêu cầu RTO/RPO, cost-effective, và tích hợp Bare Metal Oracle (2026 updates: Actifio ưu tiên hơn RMAN-to-Cloud Storage do latency thấp hơn 50%).

• Phương án 1:
  1 Create the database on a Bare Metal Solution server with the database running on flash storage.
  2. Keep a local backup copy on all flash storage.
  3. Keep backups older than one day stored in Actifio OnVault storage.
  ❌ SAI: Local backup trên flash storage quá đắt (chi phí gấp 3-5x standard), không cost-effective cho 50TB backup recent (dù RTO/RPO OK). Actifio tốt nhưng lãng phí tổng thể. 🤑

• Phương án 2 (Đúng - như trên):
  1 Create the database on a Bare Metal Solution server with the database running on flash storage.
  2. Keep a local backup copy on standard storage.
  3. Keep backups older than one day stored in Actifio OnVault storage.
  ✅ ĐÚNG: Cân bằng hoàn hảo: Flash cho perf DB, standard cho backup local rẻ + nhanh restore, Actifio cho long-term (5 năm, dedupe >90%). Đáp ứng đầy đủ RTO 2h/RPO 15p. 🎯

• Phương án 3:

  1. Create the database on a Bare Metal Solution server with the database running on flash storage.
  2. Keep a local backup copy on standard storage.
  3. Use the Oracle Recovery Manager (RMAN) backup utility to move backups older than one day to a Coldline Storage bucket.
     ❌ SAI: RMAN to Coldline bucket không tích hợp tốt với Bare Metal (latency cao >1h restore, không đạt RTO 2h cho 50TB). Coldline rẻ nhưng thiếu dedupe native Oracle/Bare Metal, kém Actifio cho retention 5 năm. 🚫

• Phương án 4:

  1. Create the database on a Bare Metal Solution server with the database running on flash storage.
  2. Keep a local backup copy on all flash storage.
  3. Use the Oracle Recovery Manager (RMAN) backup utility to move backups older than one day to an Archive Storage bucket.
     ❌ SAI: Kết hợp flash local backup (đắt đỏ) + RMAN to Archive bucket (restore chậm >4-6h cho large DB, không đạt RTO; Archive chỉ cho infrequent access). Không cost-effective và vi phạm SLA. ⏳

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

Câu hỏi này xoay quanh việc quản lý quyền truy cập (privileges) trên một instance Cloud Spanner của Google Cloud. Bạn là DBA quản lý một instance Cloud Spanner có nhiều database. Nhiệm vụ là cấp quyền cho toàn bộ thành viên đội ngũ phát triển ứng dụng (application development team) trên một database cụ thể với các yêu cầu sau:

• 📖 Có thể đọc (read) tables, views và DDL (Data Definition Language - tức schema/metadata như cấu trúc bảng).
• ✏️ Có thể ghi (write) rows vào các tables (thêm/sửa/xóa dữ liệu).
• 🛠️ Có thể thêm columns và indexes (sửa đổi schema ở mức độ hạn chế).
• 🚫 KHÔNG thể drop (xóa) database.

Mục tiêu là chọn role IAM phù hợp nhất để đáp ứng chính xác các quyền này mà không cấp thừa (least privilege principle). Đây là kiến thức IAM roles cho Cloud Spanner theo tài liệu Google Cloud cập nhật mới nhất (tính đến 2026, dựa trên IAM roles v1.2+).
📘 Nguồn tham khảo:

• Cloud Spanner IAM roles (Google Cloud Documentation).
• Cloud Spanner access control (cập nhật 2025+).

✅ Đáp án đúng: Assign the Cloud Spanner Database User role

Lý do chọn đáp án này:
Role Cloud Spanner Database User (tương ứng roles/spanner.databaseUser) là lựa chọn hoàn hảo vì nó cấp chính xác các quyền cần thiết ở mức database cụ thể:

• Cho phép read data, metadata/DDL (tables, views, schema).
• Cho phép write/modify data (insert/update/delete rows).
• Cho phép modify schema hạn chế như add/alter/drop tables/indexes/columns.
• Không cho phép drop database hoặc quản lý instance-level (như backup/restore).
  Điều này tuân thủ nguyên tắc least privilege, tránh cấp quyền thừa. Bạn có thể assign role này trực tiếp cho database bằng lệnh gcloud spanner databases add-iam-policy-binding hoặc IAM console.

📋 Giải thích chi tiết 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. Mỗi phương án được đánh giá dựa trên quyền IAM của Cloud Spanner (cập nhật 2026):

• Assign the Cloud Spanner Database Reader and Cloud Spanner Backup Writer roles.
  ❌ Sai: Role Database Reader (roles/spanner.databaseReader) chỉ cho phép read data và metadata (tables/views/DDL), không write rows hay add columns/indexes. Role Backup Writer chỉ liên quan backup/restore, không bổ sung quyền write/schema. Kết hợp vẫn thiếu quyền write và schema modify, không đáp ứng yêu cầu.

• Assign the Cloud Spanner Database Admin role.
  ❌ Sai: Role Database Admin (roles/spanner.databaseAdmin) cấp quá nhiều quyền: read/write data, full schema management (add columns/indexes), VÀ drop database, backup/restore. Điều này vi phạm yêu cầu "Cannot drop the database" và vi phạm least privilege (cấp quyền admin thừa).

• Assign the Cloud Spanner Database User role.
  ✅ Đúng: Như đã giải thích ở trên, role này khớp 100% yêu cầu: read/write data, modify schema (add columns/indexes), không drop database. Hoàn hảo cho dev team trên database cụ thể.

• Assign the Cloud Spanner Admin role.
  ❌ Sai: Role Spanner Admin (roles/spanner.admin) là quyền instance-level cao nhất: quản lý toàn bộ instance (tạo/drop databases, backup, scaling). Quá rộng, cho phép drop database và vượt xa nhu cầu, dẫn đến rủi ro bảo mật cao. Không dành cho một database cụ thể.