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

🧩 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 làm việc cho một công ty quảng cáo, đã phát triển mô hình Spark ML để dự đoán tỷ lệ click-through (CTR) tại các khối quảng cáo. Toàn bộ phát triển đang diễn ra tại trung tâm dữ liệu on-premises (trên máy chủ nội bộ), và công ty đang di chuyển nhanh chóng (lift-and-shift migration) sang Google Cloud vì trung tâm dữ liệu sắp đóng cửa. Dữ liệu huấn luyện sẽ được migrate sang BigQuery. Bạn cần di chuyển các pipeline huấn luyện Spark ML hiện có một cách nhanh chóng, vì mô hình được retrain định kỳ.

Yêu cầu chính:

• Giữ nguyên Spark ML models (không rewrite).
• Đọc dữ liệu từ BigQuery (dữ liệu mới).
• Ưu tiên tốc độ migration nhanh (lift-and-shift), không thay đổi lớn code.

Mục tiêu là chọn giải pháp managed, scalable, hỗ trợ Spark native trên Google Cloud, tích hợp trực tiếp với BigQuery. 📘 (Dựa trên kiến thức Google Cloud cập nhật đến 2026: Dataproc Serverless và BigQuery connector vẫn là best practice cho Spark workloads).

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

Đáp án đúng: Use Dataproc for training existing Spark ML models, but start reading data directly from BigQuery.

Lý do:

• Dataproc là dịch vụ managed Spark/Hadoop trên Google Cloud, hỗ trợ Spark MLlib (Spark Machine Learning library) native mà không cần thay đổi code. Điều này phù hợp hoàn hảo với lift-and-shift migration nhanh 🛠️.
• Có BigQuery connector tích hợp sẵn (qua spark-bigquery-connector), cho phép đọc dữ liệu trực tiếp từ BigQuery mà không cần export, giảm latency và chi phí.
• Hỗ trợ periodic retraining qua workflows (Dataproc Workflows hoặc Composer), autoscaling, và serverless mode (từ 2022, cập nhật 2026 vẫn mạnh mẽ).
• Tiết kiệm thời gian: Không rewrite model, chỉ thay đổi source data từ on-prem sang BigQuery. ✅

📋 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 khả thi, tốc độ migration, và phù hợp với yêu cầu lift-and-shift.

• Use Vertex AI for training existing Spark ML models ❌
  Sai vì: Vertex AI (trước là AI Platform) tập trung vào TensorFlow, PyTorch, XGBoost, scikit-learn, không hỗ trợ Spark MLlib native. Bạn phải customize pipelines phức tạp (qua custom containers), dẫn đến tốn thời gian refactor code – trái với yêu cầu migration nhanh. Không phải lift-and-shift thuần túy.

• Rewrite your models on TensorFlow, and start using Vertex AI ❌
  Sai vì: Yêu cầu rewrite toàn bộ model từ Spark ML sang TensorFlow, rất tốn công sức và thời gian (có thể mất tuần/tháng), không phù hợp với data center closing soon và lift-and-shift. Vertex AI mạnh cho deep learning, nhưng làm chậm migration. 🕒

• Use Dataproc for training existing Spark ML models, but start reading data directly from BigQuery ✅
  Đúng vì: Như đã giải thích ở trên. Dataproc giữ nguyên Spark code, BigQuery connector (phiên bản 1.5+ đến 2026) cho phép query trực tiếp: spark.read.format("bigquery").load("project.dataset.table"). Managed service, autoscaling, tích hợp Cloud Storage cho checkpoints. Hoàn hảo cho periodic jobs! 🚀

• Spin up a Spark cluster on Compute Engine, and train Spark ML models on the data exported from BigQuery ❌
  Sai vì: Tự spin up Spark trên Compute Engine (VMs) là không managed, bạn phải tự quản lý cluster (scaling, patching, networking) – tốn kém và phức tạp hơn Dataproc. Export dữ liệu từ BigQuery (sang GCS/CSV) thêm bước thừa, tăng latency/cost so với đọc trực tiếp. Không phải best practice lift-and-shift. 💸

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

• Dataproc & BigQuery: Google Cloud Dataproc Documentation – Connector guide.
• Spark ML on Dataproc: Run Spark ML workloads.
• Vertex AI limitations: Vertex AI supported frameworks – Không liệt kê Spark MLlib native.
• Lift-and-shift best practices: Migrate Spark to Google Cloud.

Hy vọng phân tích này giúp bạn ôn thi Google Cloud Professional Data Engineer! 🌟 Nếu cần ví dụ code, hỏi thêm nhé!

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

Câu hỏi mô tả một công ty vận tải biển toàn cầu cần huấn luyện mô hình (train a model) trên 40 TB dữ liệu để dự đoán tàu nào ở từng khu vực địa lý có khả năng gây chậm trễ giao hàng hàng ngày. Mô hình dựa trên nhiều thuộc tính từ nhiều nguồn, bao gồm dữ liệu telemetry (vị trí GeoJSON) được kéo từ mỗi tàu mỗi giờ. Yêu cầu chính là bảng điều khiển (dashboard) hiển thị số lượng và tàu cụ thể có nguy cơ chậm trễ trong khu vực, sử dụng storage solution có tính năng native cho prediction (dự đoán) và geospatial processing (xử lý không gian địa lý).

🛠️ Yêu cầu cốt lõi:

• Xử lý dữ liệu lớn (40 TB).
• Hỗ trợ tải dữ liệu định kỳ (hourly).
• Native prediction (ML integration).
• Native geospatial (xử lý GeoJSON, vùng địa lý).
• Phù hợp cho analytics và dashboard (như với Looker hoặc BigQuery console).

📘 Kiến thức cập nhật (GCP 2026): BigQuery (với BigQuery ML và GIS extensions) là lựa chọn tối ưu cho petabyte-scale analytics, ML inference, geospatial queries (ST_GEOGFROMGEOJSON, etc.), và streaming inserts hourly.

✅ Đáp án đúng: BigQuery

Lý do chọn BigQuery 🏆:
BigQuery là data warehouse serverless được thiết kế cho dữ liệu lớn (hàng PB), hỗ trợ streaming inserts mỗi giờ cho telemetry data. Nó có native BigQuery ML để train/inference mô hình dự đoán (prediction) trực tiếp trên dữ liệu mà không cần export (hỗ trợ AutoML Tables, logistic regression, etc. cho delay prediction). Geospatial native qua GIS functions (ST_GEOGFROMGEOJSON, ST_INTERSECTS cho region-based queries). Dashboard dễ build với BigQuery + Looker/Data Studio, query real-time ships at risk. Hoàn hảo cho 40 TB multi-source data.

Nguồn tham khảo:

• BigQuery ML Documentation (cập nhật 2025: Enhanced Vertex AI integration).
• BigQuery GIS Overview (hỗ trợ GeoJSON native từ 2023+).

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

• BigQuery ✅ Đúng: Như phân tích trên, native prediction (BigQuery ML cho train/deploy models trên 40 TB), geospatial (GIS functions xử lý GeoJSON, region queries như ST_WITHIN), streaming loads hourly, dashboard-ready. Scale tự động cho global shipping data.

• Cloud Bigtable ❌ Sai: Đây là NoSQL wide-column store cho high-throughput/low-latency (IoT telemetry tốt), nhưng không có native prediction/ML (cần export sang Vertex AI) và không hỗ trợ geospatial native (chỉ basic indexing, không GeoJSON/GIS). Không phù hợp analytics 40 TB hay dashboard complex.

• Cloud Datastore ❌ Sai: NoSQL document DB (Firestore mode) cho app data, hỗ trợ basic geospatial queries (GeoPoint), nhưng không native prediction/ML, scale kém cho 40 TB analytics (query limits), không streaming hourly optimized. Không phải data warehouse cho train model/dashboard.

• Cloud SQL for PostgreSQL ❌ Sai: Relational DB với PostGIS extension cho geospatial tốt (GeoJSON support), nhưng không native prediction (cần pgml extension hoặc export ML), khó scale 40 TB (vertical limits, costly), không serverless streaming như BigQuery. Phù hợp transactional, không big data ML.

🧠 Tóm tắt so sánh: BigQuery vượt trội ở fully managed analytics + ML + GIS cho use case này, các option khác thiếu ít nhất 1-2 tính năng native yêu cầu!

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

Câu hỏi mô tả một pipeline IoT sử dụng Apache Kafka nhận khoảng 5000 tin nhắn/giây (messages per second). Yêu cầu là sử dụng Google Cloud Platform (GCP) để tạo cảnh báo (alert) ngay khi trung bình di động (moving average) trong vòng 1 giờ giảm xuống dưới 4000 tin nhắn/giây.

📌 Điểm chính cần chú ý:

• Đây là xử lý dữ liệu streaming thời gian thực từ Kafka.
• Moving average over 1 hour đòi hỏi tính toán trung bình trên cửa sổ thời gian liên tục trượt (sliding), không phải cửa sổ cố định.
• Cần alert ngay lập tức khi điều kiện vi phạm, nên ưu tiên stream processing với Dataflow (Apache Beam trên GCP).
• Không dùng batch processing chậm trễ hoặc scheduler định kỳ.

✅ Đáp án đúng

Consume the stream of data in Dataflow using Kafka IO. Set a sliding time window of 1 hour every 5 minutes. Compute the average when the window closes, and send an alert if the average is less than 4000 messages.

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

• Dataflow với Kafka IO là cách chuẩn để tiêu thụ stream từ Kafka thời gian thực trên GCP (hỗ trợ từ Beam SDK 2.x trở lên, cập nhật đến 2026 vẫn là best practice).
• Sliding time window 1 giờ, slide mỗi 5 phút: Hoàn hảo cho moving average, vì cửa sổ trượt chồng lấp (overlap), tính trung bình liên tục mỗi 5 phút trên dữ liệu 1 giờ gần nhất → phát hiện sớm khi avg < 4000 msg/s.
• Compute average khi window closes và send alert (qua Pub/Sub + Cloud Monitoring hoặc Alerting Policy) đảm bảo real-time alerting.
• Hiệu quả, scalable cho 5000 msg/s.

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

• ✅ Consume the stream of data in Dataflow using Kafka IO. Set a sliding time window of 1 hour every 5 minutes. Compute the average when the window closes, and send an alert if the average is less than 4000 messages.
  Đúng 🏆: Như giải thích trên, sliding window lý tưởng cho moving average, xử lý stream real-time, độ trễ thấp (5 phút).

• ❌ Consume the stream of data in Dataflow using Kafka IO. Set a fixed time window of 1 hour. Compute the average when the window closes, and send an alert if the average is less than 4000 messages.
  Sai 🚫: Fixed window không trượt (non-overlapping), chỉ tính avg mỗi giờ một lần (ví dụ: 0h-1h, 1h-2h). Không phải moving average liên tục, bỏ lỡ phát hiện giữa giờ (ví dụ: drop ở phút 30).

• ❌ Use Kafka Connect to link your Kafka message queue to Pub/Sub. Use a Dataflow template to write your messages from Pub/Sub to Bigtable. Use Cloud Scheduler to run a script every hour that counts the number of rows created in Bigtable in the last hour. If that number falls below 4000, send an alert.
  Sai ⏳:

  • Chuyển sang Pub/Sub + Bigtable là batch-like, không stream processing.
  • Cloud Scheduler hourly gây trễ (chỉ check mỗi giờ), không real-time.
  • Count rows không chính xác msg/s (Bigtable không tối ưu cho time-series avg), và <4000 rows/giờ ≠ 4000 msg/s (thiếu rate tính toán).

• ❌ Use Kafka Connect to link your Kafka message queue to Pub/Sub. Use a Dataflow template to write your messages from Pub/Sub to BigQuery. Use Cloud Scheduler to run a script every five minutes that counts the number of rows created in BigQuery in the last hour. If that number falls below 4000, send an alert.
  Sai 📊:

  • Tương tự, Pub/Sub + BigQuery là storage batch, BigQuery streaming insert có độ trễ ~1-2 phút.
  • Scheduler 5 phút vẫn không phải stream real-time, query last hour tốn kém (chi phí scan lớn).
  • Count rows <4000 sai logic: 1 giờ = 3600s, 4000 msg/s = 14.4M rows/giờ, nhưng không tính avg chính xác và bỏ lỡ window di động.

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

• Dataflow Windows: Apache Beam Sliding Windows & GCP Dataflow Kafka IO.
• Kafka on GCP: Connect Kafka to Dataflow (Beam 2.58+ hỗ trợ native Kafka IO).
• Alerting: Cloud Monitoring with Dataflow metrics.
• Official Exam Guide: GCP Professional Data Engineer sample questions (Google Cloud Skills Boost, 2024-2026 cert updates).

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

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

Câu hỏi tập trung vào việc triển khai Cloud SQL với engine MySQL trên Google Cloud Platform (GCP) để đảm bảo high availability (HA) trong trường hợp zone failure (lỗi ở một availability zone).

• Mục tiêu chính: Đảm bảo dịch vụ không bị gián đoạn khi một zone gặp sự cố, bằng cách sử dụng cơ chế replication phù hợp để failover tự động.
• Bối cảnh: Cloud SQL hỗ trợ HA bằng cách tạo primary instance và replica trong các zone khác nhau trong cùng một region (regional HA), giúp tự động chuyển đổi (failover) trong vòng vài phút nếu primary zone thất bại.
• Lưu ý: Đây là tính năng chuẩn của Cloud SQL MySQL (cập nhật đến 2026, không thay đổi cơ bản từ phiên bản hiện tại). Không liên quan đến cross-region (chỉ cho disaster recovery, không phải HA zone-level).

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

Đáp án đúng: Create a Cloud SQL instance in one zone, and create a failover replica in another zone within the same region.

Lý do:
🛠️ Phương án này kích hoạt High Availability (HA) configuration chính thức của Cloud SQL. Primary instance nằm ở một zone, failover replica (sync replication) ở zone khác cùng region. Khi zone primary fail, GCP tự động promote replica thành primary (failover < 60 giây), đảm bảo zero-downtime cho zone failure. Đây là cách chuẩn để chống zone outage theo docs GCP.

📋 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). Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích rõ ràng:

• ✅ Create a Cloud SQL instance in one zone, and create a failover replica in another zone within the same region.
  🟢 Đúng: Đây là cấu hình HA tiêu chuẩn. Failover replica hỗ trợ automatic failover, replication synchronous (1-way), chỉ trong cùng region để latency thấp và HA zone-level. Phù hợp hoàn hảo với yêu cầu chống zone failure.

• ❌ Create a Cloud SQL instance in one zone, and create a read replica in another zone within the same region.
  🔴 Sai: Read replica chỉ dùng cho read scaling (read-only), không hỗ trợ automatic failover. Nếu primary zone fail, read replica không tự promote, dẫn đến downtime. Phải manual intervention, không đảm bảo HA.

• ❌ Create a Cloud SQL instance in one zone, and configure an external read replica in a zone in a different region.
  🔴 Sai: External read replica (cross-region) dùng cho disaster recovery hoặc global read scaling, nhưng không phải HA (latency cao, async replication). Không tự failover cho zone failure trong region, và cross-region không khuyến khích cho HA zone-level.

• ❌ Create a Cloud SQL instance in a region, and configure automatic backup to a Cloud Storage bucket in the same region.
  🔴 Sai: Backup chỉ dùng cho recovery (point-in-time restore), không phải HA realtime. Không có replication live, phải manual restore từ bucket (downtime hàng giờ), không chống zone failure ngay lập tức.

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

• Google Cloud SQL MySQL High Availability: cloud.google.com/sql/docs/mysql/high-availability – Chi tiết HA config với failover replica.
• Cloud SQL Replication Options: cloud.google.com/sql/docs/mysql/replication – So sánh failover vs read replica.
• Best Practices for HA: cloud.google.com/sql/docs/mysql/best-practices – Khuyến nghị regional HA cho zone failure (không thay đổi đến 2026).

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ụ thực hành, hãy hỏi nhé.

🧩 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 hệ thống trung tâm hóa việc thu thập (ingestion) và phân phối (delivery) dữ liệu, sử dụng các hệ thống messaging và tích hợp dữ liệu. Các yêu cầu chính bao gồm:

• Khả năng seek (tìm kiếm) đến một offset cụ thể trong topic, thậm chí quay về đầu của toàn bộ dữ liệu đã capture từ trước đến nay (tức là hỗ trợ replay dữ liệu lịch sử).
• Hỗ trợ mô hình publish/subscribe (pub/sub) trên hàng trăm topics.
• Giữ nguyên thứ tự theo key (per-key ordering) – hình ảnh minh họa cho thấy dữ liệu được sắp xếp theo key trong partitions để đảm bảo thứ tự.

📘 Bối cảnh: Đây là câu hỏi điển hình trong kỳ thi Google Cloud Professional Data Engineer, liên quan đến các dịch vụ streaming dữ liệu mạnh mẽ. Kiến thức dựa trên phiên bản mới nhất của Google Cloud Platform (GCP) và Apache Kafka đến năm 2026, nơi Kafka được tích hợp chặt chẽ qua Cloud Pub/Sub hoặc Confluent Cloud on GCP, hỗ trợ retention không giới hạn và partitioning theo key.

✅ Đáp án đúng: Apache Kafka

Lý do lựa chọn:
Apache Kafka là hệ thống messaging phân tán lý tưởng cho các yêu cầu này. Nó cho phép seek chính xác đến offset (qua consumer API với seekToBeginning() hoặc offset tùy chỉnh), hỗ trợ pub/sub trên hàng trăm topics với scalability cao, và giữ per-key ordering nhờ partitioning theo key (dữ liệu cùng key luôn ở cùng partition, đảm bảo thứ tự FIFO). Retention có thể cấu hình vô hạn (infinite retention) để replay toàn bộ lịch sử dữ liệu. Trong GCP, Kafka có thể deploy qua GKE hoặc Confluent Platform, phù hợp với kiến trúc data lakehouse hiện đại (2026).
🛠️ Ưu điểm nổi bật: Xử lý hàng triệu messages/giây, fault-tolerant với replication.

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

• Apache Kafka
  ✅ Đúng. Như đã giải thích ở trên, Kafka hoàn hảo khớp tất cả yêu cầu: seek offset linh hoạt (từ đầu topic), pub/sub đa topics, và per-key ordering qua partitions. Không có lựa chọn nào khác hỗ trợ đầy đủ như vậy.
  Tham khảo: Apache Kafka Documentation - Consumer Seek & GCP Confluent Kafka Integration.

• Cloud Storage
  ❌ Sai. Cloud Storage là dịch vụ lưu trữ object (blob storage) dùng cho data lake, không phải hệ thống messaging. Nó không hỗ trợ topics, pub/sub semantics, offset seeking, hay per-key ordering động. Chỉ phù hợp lưu trữ tĩnh, không cho ingestion/delivery real-time.
  Tham khảo: GCP Cloud Storage Docs.

• Dataflow
  ❌ Sai. Dataflow là dịch vụ xử lý batch/streaming dựa trên Apache Beam, dùng để transform và process dữ liệu, không phải hệ thống ingestion/delivery cốt lõi. Nó không có topics native, offset seeking trực tiếp, hay pub/sub semantics; chỉ đọc từ sources như Pub/Sub rồi process. Không giữ per-key ordering tự động mà cần code thủ công.
  Tham khảo: GCP Dataflow Documentation.

• Firebase Cloud Messaging
  ❌ Sai. Firebase Cloud Messaging (FCM) là dịch vụ gửi push notifications cho app/mobile, chỉ hỗ trợ one-way messaging đơn giản, không có topics phức tạp (hàng trăm), offset seeking, hay per-key ordering. Không dùng cho data ingestion quy mô lớn hoặc replay lịch sử.
  Tham khảo: Firebase Cloud Messaging Docs.

Kết luận 💡: Apache Kafka là lựa chọn tối ưu cho streaming data cao tải, đặc biệt trong hệ sinh thái GCP 2026 với tích hợp AI/ML pipelines. Nếu triển khai trên GCP, khuyến nghị dùng Pub/Sub for Kafka để dễ quản lý hơn!

🧩 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) hệ thống Apache Hadoop đang chạy on-premises lên cloud, với các yêu cầu chính:

• Fault-tolerant (chịu lỗi cao): Hệ thống phải ổn định, có khả năng chịu lỗi tốt cho các long-running batch jobs (các công việc xử lý hàng loạt kéo dài).
• Cost-effective (tiết kiệm chi phí): Tối ưu hóa chi phí vận hành lâu dài.
• Sử dụng managed service (dịch vụ quản lý): Không tự quản lý hạ tầng, mà dùng dịch vụ tự động hóa từ cloud provider (ở đây là Google Cloud Platform - GCP).

🛠️ Bối cảnh kỹ thuật: Apache Hadoop thường dùng HDFS cho lưu trữ và YARN cho quản lý tài nguyên. Khi migrate lên cloud, cần thay thế HDFS bằng lưu trữ object storage (như Cloud Storage) để scalable và durable hơn, đồng thời tận dụng worker nodes giá rẻ nhưng vẫn đảm bảo tính sẵn sàng. Dataproc là dịch vụ managed Hadoop/Spark của GCP, lý tưởng cho kịch bản này (cập nhật đến 2026, Dataproc hỗ trợ phiên bản Hadoop 3.x và tích hợp sâu với Cloud Storage qua connector gs://).

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

Đáp án đúng: Deploy a Dataproc cluster. Use a standard persistent disk and 50% preemptible workers. Store data in Cloud Storage, and change references in scripts from hdfs:// to gs://

Lý do chi tiết:

• Managed service: Dataproc tự động quản lý cluster Hadoop/Spark, scale up/down, chịu lỗi (auto-restart jobs nếu node fail), phù hợp long-running batch.
• Standard persistent disk: Rẻ hơn SSD (khoảng 1/4 giá), đủ cho batch jobs không yêu cầu I/O cao tốc độ.
• 50% preemptible workers: Giảm chi phí ~80% so với on-demand, nhưng chỉ 50% để tránh rủi ro job bị gián đoạn hoàn toàn (preemptible VM có thể bị thu hồi sau 24h, nhưng Dataproc hỗ trợ graceful preemption cho batch jobs).
• Cloud Storage + gs://: Durable (11 9's), infinite scale, rẻ hơn HDFS, tích hợp native với Dataproc (không cần HDFS).
  🧩 Kết hợp này tối ưu fault-tolerance (primary workers stable + multi-zone) và cost-effective nhất cho batch jobs dài hạn.

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

• [ĐÚNG] Deploy a Dataproc cluster. Use a standard persistent disk and 50% preemptible workers. Store data in Cloud Storage, and change references in scripts from hdfs:// to gs://
  ✅ Đúng hoàn toàn: Như giải thích trên, đây là best practice của GCP cho migrate Hadoop (Dataproc docs khuyến nghị 30-70% preemptible cho batch để balance cost/reliability). Standard PD tiết kiệm chi phí mà vẫn fault-tolerant.

• [SAI] Deploy a Dataproc cluster. Use an SSD persistent disk and 50% preemptible workers. Store data in Cloud Storage, and change references in scripts from hdfs:// to gs://
  ❌ Sai: SSD persistent disk đắt hơn standard PD gấp 4 lần, không cần thiết cho batch jobs (I/O thấp). Lãng phí chi phí, vi phạm yêu cầu "cost-effective". (Preemptible và Cloud Storage vẫn tốt, nhưng SSD làm tổng chi phí cao hơn).

• [SAI] Install Hadoop and Spark on a 10-node Compute Engine instance group with standard instances. Install the Cloud Storage connector, and store the data in Cloud Storage. Change references in scripts from hdfs:// to gs://
  ❌ Sai: Không dùng managed service (phải tự install/maintain Hadoop/Spark trên GCE MIG - Managed Instance Group). Tốn công quản lý patching, scaling, fault-tolerance kém hơn Dataproc (không auto-healing). Fixed 10-node không linh hoạt cho long-running jobs.

• [SAI] Install Hadoop and Spark on a 10-node Compute Engine instance group with preemptible instances. Store data in HDFS. Change references in scripts from hdfs:// to gs://
  ❌ Sai kép: (1) Không managed service, tự quản lý trên GCE. (2) Preemptible instances + HDFS = rủi ro cao (HDFS cần stable nodes để tránh data loss/corruption khi VM bị preempt). gs:// chỉ thay reference nhưng vẫn dùng HDFS → không tận dụng Cloud Storage fully, kém durable/cost-effective.

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

• Dataproc Best Practices: GCP Dataproc Cluster Configuration - Khuyến nghị 50% preemptible + standard PD cho batch.
• Migrate Hadoop to Dataproc: GCP Hadoop Migration Guide - Chuyển hdfs:// → gs://, dùng Cloud Storage FUSE.
• Pricing Comparison: GCP Pricing Calculator - Standard PD ~$0.04/GB/th, SSD ~$0.17; Preemptible tiết kiệm 80%.
• Release Notes 2026: Dataproc 2.0+ hỗ trợ autoscaling preemptible với zero-downtime cho batch jobs.

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/script migrate, hãy hỏi nhé!

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

Câu hỏi này xoay quanh một vấn đề phân loại nhị phân (binary classification) trong machine learning. Đội ngũ đã huấn luyện một mô hình Support Vector Machine (SVM) với các tham số mặc định, đạt AUC (Area Under the ROC Curve) là 0.87 trên tập validation. Mục tiêu là tăng AUC của mô hình.

AUC là chỉ số đo lường khả năng phân biệt giữa hai lớp (cao hơn 0.5 là tốt hơn random, 0.87 đã khá tốt nhưng có thể cải thiện). SVM là thuật toán cổ điển mạnh mẽ cho phân loại, nhưng hiệu suất phụ thuộc lớn vào hyperparameters như kernel (linear/RBF), C (regularization), gamma (cho RBF kernel). Câu hỏi yêu cầu hành động cụ thể để cải thiện, dựa trên best practices ML cập nhật đến 2026 (theo AWS SageMaker và các framework như scikit-learn/XGBoost trong SageMaker).

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

• AWS SageMaker Hyperparameter Tuning Guide (2024-2026 updates): https://docs.aws.amazon.com/sagemaker/latest/dg/automatic-model-tuning.html
• Google Cloud Vertex AI Tuning (tương đương): https://cloud.google.com/vertex-ai/docs/training/hyperparameter-tuning-overview

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

Đáp án đúng: Perform hyperparameter tuning
Lý do: SVM rất nhạy cảm với hyperparameters (ví dụ: C kiểm soát trade-off giữa margin và misclassification, gamma ảnh hưởng đến độ phức tạp của decision boundary). Với tham số mặc định, mô hình chưa tối ưu → Hyperparameter tuning (sử dụng grid search, random search hoặc Bayesian optimization như trong AWS SageMaker Automatic Model Tuning) có thể tăng AUC đáng kể (thường 5-20% tùy dataset). Đây là bước đầu tiên, hiệu quả và chuẩn best practice ML. 🛠️

📋 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 một cách đầy đủ, giữ nguyên văn bản gốc tiếng Anh. Tôi đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do dựa trên kiến thức ML cập nhật:

• Perform hyperparameter tuning ✅
  Giải thích: Đây là lựa chọn tối ưu nhất. Hyperparameter tuning giúp khám phá không gian tham số tốt hơn, đặc biệt với SVM (ví dụ: tune C từ 0.1-100, gamma từ 0.001-1). Theo AWS SageMaker (phiên bản 2026), công cụ Automatic Tuning hỗ trợ SVM qua scikit-learn estimator, thường mang lại AUC cao hơn mà không cần thay đổi mô hình. Không rủi ro overfitting nếu dùng early stopping và validation đúng cách.

• Train a classifier with deep neural networks, because neural networks would always beat SVMs ❌
  Giải thích: Sai vì neural networks KHÔNG LUÔN vượt trội SVM. SVM xuất sắc với dataset nhỏ/tabular data (ít features), trong khi DNN cần data lớn, compute cao và dễ overfitting nếu không tune kỹ. AUC 0.87 của SVM đã tốt → Chuyển DNN có thể tệ hơn (theo benchmark MLPerf 2025). Best practice: Bắt đầu tune SVM trước khi thử DNN trên AWS SageMaker.

• Deploy the model and measure the real-world AUC; it's always higher because of generalization ❌
  Giải thích: Hoàn toàn sai. Real-world AUC thường THẤP HỚN validation AUC do distribution shift, unseen data hoặc concept drift (theo AWS SageMaker Model Monitor 2026). Generalization nghĩa là performance ổn định từ train sang test, nhưng deploy không tự động cải thiện AUC mà cần monitoring/retraining. Hành động này liều lĩnh, có thể dẫn đến model kém chất lượng production.

• Scale predictions you get out of the model (tune a scaling factor as a hyperparameter) in order to get the highest AUC ❌
  Giải thích: Sai vì scaling predictions (nhân hệ số tuyến tính) KHÔNG thay đổi AUC. AUC dựa trên ranking scores (ROC curve invariant dưới monotonic transformation). Scaling chỉ ảnh hưởng threshold nhưng không cải thiện thứ hạng → Vô ích cho AUC (xác nhận qua scikit-learn ROC docs và AWS SageMaker clarifications 2024). Nếu cần calibrate probability, dùng Platt scaling hoặc Isotonic regression, nhưng không phải "scaling factor đơn giản".

🧠 Kết luận: Hyperparameter tuning là bước logic, tiết kiệm nhất để boost AUC SVM. Trong thực tế AWS/Google Cloud, tích hợp sẵn tools như SageMaker Tuning hoặc Vertex AI HyperparameterTuningJob để automate! 🚀

🧩 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 triển khai các dependencies bổ sung (các gói phần mềm hoặc tài nguyên cần thiết) lên tất cả các node (master, worker) của một Cloud Dataproc cluster ngay từ lúc khởi tạo, sử dụng initialization action (hành động khởi tạo) đã có sẵn.

🔒 Ràng buộc bảo mật quan trọng: Chính sách công ty yêu cầu các node của Cloud Dataproc không được truy cập Internet, do đó các initialization action công khai (public) không thể tải tài nguyên từ bên ngoài (như GitHub hoặc các nguồn public).

🛠️ Mục tiêu: Tìm cách lưu trữ và phân phối dependencies nội bộ, an toàn, không phụ thuộc Internet, phù hợp với VPC Service Controls (perimeter bảo mật VPC) theo kiến thức GCP cập nhật đến 2026 (Dataproc 2.0+ hỗ trợ init actions từ GCS với metadata server internal).

📘 Nguồn tham khảo:

• Cloud Dataproc Initialization Actions
• VPC Service Controls
• [Dataproc Security Best Practices](https://cloud.google.com/dataproc/docs/guides iam-best-practices) (cập nhật 2024-2026).

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

Đáp án đúng: Copy all dependencies to a Cloud Storage bucket within your VPC security perimeter

Lý do:

• Initialization actions của Cloud Dataproc hỗ trợ script từ Cloud Storage (GCS) bucket nội bộ.
• Khi nodes không có Internet, chúng vẫn có thể truy cập GCS qua private endpoint trong VPC Service Controls perimeter (không route qua public IP).
• ✅ Điều này đảm bảo dependencies được copy an toàn lên tất cả nodes lúc startup, tuân thủ chính sách no-Internet, và tận dụng quyền IAM của service account Dataproc (Storage Object Viewer).
• Đây là best practice chính thức từ Google Cloud (2026), tránh rủi ro leak data ra ngoài perimeter.

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

• ❌ Deploy the Cloud SQL Proxy on the Cloud Dataproc master
  Phương án này sai vì Cloud SQL Proxy dùng để kết nối private với Cloud SQL database, không liên quan đến việc deploy dependencies cho init action. Nó chỉ hỗ trợ DB access, không giải quyết việc fetch resources cho tất cả nodes (chỉ master), và vẫn không thay thế Internet cho public fetches.

• ❌ Use an SSH tunnel to give the Cloud Dataproc cluster access to the Internet
  Phương án này sai vì vi phạm trực tiếp chính sách bảo mật "nodes do not have access to the Internet". SSH tunnel tạo backdoor truy cập Internet, tăng rủi ro bảo mật (man-in-the-middle), không phải giải pháp scalable cho init actions trên tất cả nodes.

• ✅ Copy all dependencies to a Cloud Storage bucket within your VPC security perimeter
  Phương án này đúng như đã giải thích ở trên: Sử dụng GCS bucket trong VPC perimeter làm nguồn internal cho init script, nodes fetch qua private network (no public IP), deploy dependencies tự động lên mọi node lúc startup. Hoàn hảo cho môi trường air-gapped/high-security.

• ❌ Use Resource Manager to add the service account used by the Cloud Dataproc cluster to the Network User role
  Phương án này sai vì Network User role (IAM) chỉ cho phép quản lý VPC networks/resources, không cấp quyền truy cập Internet hay fetch dependencies. Nó không giải quyết vấn đề init action thiếu nguồn public, và Resource Manager không liên quan trực tiếp đến Dataproc startup.

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

Câu hỏi yêu cầu chọn một cơ sở dữ liệu (database) phù hợp cho dự án mới với 5 yêu cầu chính sau:

• Fully managed 🛡️: Dịch vụ được quản lý hoàn toàn bởi nhà cung cấp (không cần quản lý server, backup, scaling thủ công).
• Able to automatically scale up ⚡: Tự động mở rộng quy mô theo chiều dọc (scale up) khi tải tăng, không cần can thiệp thủ công.
• Transactionally consistent 🔒: Đảm bảo tính nhất quán giao dịch (transactional consistency), hỗ trợ ACID transactions với strong consistency.
• Able to scale up to 6 TB 📈: Có khả năng mở rộng lên ít nhất 6 TB dung lượng lưu trữ.
• Able to be queried using SQL 💻: Hỗ trợ truy vấn bằng ngôn ngữ SQL chuẩn.

Câu hỏi tập trung vào các dịch vụ Google Cloud Platform (GCP), đòi hỏi database phải đáp ứng tất cả các tiêu chí trên đồng thời. Đây là câu hỏi kiểm tra kiến thức về khả năng scaling toàn cầu, consistency và SQL support của các database managed trên GCP (cập nhật đến phiên bản mới nhất năm 2026, theo tài liệu GCP).

✅ Đáp án đúng: Cloud Spanner

Lý do lựa chọn:
Cloud Spanner là database fully managed duy nhất trên GCP đáp ứng hoàn hảo tất cả 5 yêu cầu:

• ✅ Fully managed: Google quản lý toàn bộ infrastructure, replication, backup.
• ✅ Automatically scale up: Tự động scale horizontally (thêm nodes) và vertically (tăng CPU/RAM), hỗ trợ global scale với TrueTime cho low-latency.
• ✅ Transactionally consistent: Hỗ trợ strong consistency toàn cầu với ACID transactions, multi-row transactions.
• ✅ Scale up to 6 TB: Dễ dàng scale lên petabyte (1 PB = 1024 TB), vượt xa 6 TB (hỗ trợ node configs lên đến hàng nghìn nodes).
• ✅ SQL queried: Sử dụng Spanner SQL (dựa trên ANSI SQL 2011+, với extensions cho distributed data).
  Nguồn tham khảo: Cloud Spanner Documentation & Capabilities Overview (2026 update).

📋 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 chi tiết, chỉ rõ lý do đúng/sai dựa trên đặc tính thực tế của từng dịch vụ GCP (phiên bản mới nhất 2026):

• Cloud SQL ❌ SAI
  Cloud SQL là relational database managed (MySQL/PostgreSQL/SQL Server), fully managed và SQL support tốt, transactionally consistent (ACID). Tuy nhiên:
  ❌ Không automatically scale up toàn diện (chỉ vertical scaling thủ công qua machine types, giới hạn ~64 TB/instance nhưng cần downtime hoặc read replicas). Không scale tự động như distributed DB.
  ❌ Không đạt scale to 6 TB dễ dàng cho workload lớn mà không phức tạp.
  Phù hợp: Workload nhỏ/trung bình, không global distributed.

• Cloud Bigtable ❌ SAI
  Cloud Bigtable là NoSQL wide-column store fully managed, automatically scales (horizontal đến PB, tự động theo throughput), scale to 6 TB dễ dàng. Tuy nhiên:
  ❌ Không transactionally consistent (eventual consistency mặc định, không hỗ trợ full ACID/multi-row transactions mạnh mẽ).
  ❌ Không SQL: Chỉ dùng API/HBASE shell, không native SQL (cần BigQuery integration gián tiếp).
  Phù hợp: Big Data analytics, time-series (như IoT), không phải transactional SQL.

• Cloud Spanner ✅ ĐÚNG
  (Đã giải thích chi tiết ở phần đáp án đúng ở trên). Hoàn hảo match tất cả yêu cầu! 🚀

• Cloud Datastore (nay là Firestore in Datastore mode) ❌ SAI
  Firestore/Datastore là NoSQL document DB fully managed, automatically scales (horizontal, serverless), scale to 6 TB (vượt xa). Tuy nhiên:
  ❌ Không transactionally consistent mạnh (strong consistency chỉ trong single entity group; multi-document eventual hoặc limited transactions).
  ❌ Không native SQL: Dùng proprietary query language (no joins, aggregation hạn chế; cần export sang BigQuery).
  Phù hợp: App development scalable, không cần complex SQL/transactions.
  Nguồn: Firestore Capabilities.

🛠️ Kết luận & Lời khuyên

Cloud Spanner là lựa chọn tối ưu cho workload global, SQL-based, high-consistency với scale lớn. Nếu dự án cần chi phí thấp hơn, xem xét hybrid với BigQuery cho analytics. Tài liệu chính thức GCP 2026: Database Comparison để verify! 💡

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

Câu hỏi mô tả một doanh nghiệp cỡ trung (mid-sized enterprise) cần di chuyển dữ liệu giao dịch hệ thống hoạt động (operational system transaction data) từ cơ sở dữ liệu on-premises (khoảng 20TB) sang Google Cloud Platform (GCP).
🔍 Chi tiết chính cần chú ý:

• Dữ liệu là transactional (giao dịch, thường thuộc OLTP - Online Transaction Processing), yêu cầu tính nhất quán cao, hỗ trợ SQL relational, và khả năng migrate dễ dàng từ on-premises (có thể là MySQL, PostgreSQL, SQL Server).
• Kích thước 20TB là lớn nhưng vẫn phù hợp với các dịch vụ managed DB của GCP (không phải Big Data cực lớn như petabyte).
• Mục tiêu: Chọn database phù hợp nhất cho workload operational/transactional, không phải analytics hay NoSQL.
  🛠️ Bối cảnh GCP (cập nhật đến 2026): GCP cung cấp nhiều dịch vụ DB managed, nhưng lựa chọn dựa trên workload: relational cho transactional, NoSQL cho scale horizontal lớn hoặc unstructured data.

✅ Đáp án đúng: Cloud SQL

Lý do chọn:
Cloud SQL là dịch vụ managed relational database (hỗ trợ MySQL, PostgreSQL, SQL Server) lý tưởng cho operational transactional workloads từ on-premises. Nó hỗ trợ Database Migration Service (DMS) để migrate trực tiếp 20TB dữ liệu một cách seamless, với high availability, automatic backups, và scaling vertical/horizontal. Với kích thước 20TB, Cloud SQL hoàn toàn xử lý được (storage lên đến hàng PB theo docs 2025), chi phí hợp lý cho mid-sized enterprise. Không cần globally distributed phức tạp.
📘 Nguồn: GCP Cloud SQL Documentation & Database Migration Guide (cập nhật 2025).

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

• Cloud SQL
  ✅ Đúng. Phù hợp hoàn hảo cho dữ liệu transactional relational từ on-premises. Hỗ trợ full SQL, ACID transactions, và migrate dễ dàng qua DMS/Cloud SQL Insights. Scaling storage lên 64TB+ per instance (2025), HA multi-zone.

• Cloud Bigtable
  ❌ Sai. Đây là NoSQL wide-column store dành cho high-throughput analytics (OLAP) hoặc time-series data (như logs, IoT). Không hỗ trợ SQL đầy đủ, thiếu ACID transactions mạnh cho operational OLTP, và migrate từ relational DB rất phức tạp (cần schema redesign). Không phù hợp 20TB transactional data.
  📘 Nguồn: Bigtable Overview (2025).

• Cloud Spanner
  ❌ Sai. Là globally distributed relational DB với horizontal scale mạnh (true SQL + ACID global), nhưng quá mức cần thiết và đắt đỏ cho mid-sized enterprise (chi phí ~10x Cloud SQL). Chỉ dùng khi cần multi-region consistency cao (như finance global). 20TB transactional đơn giản không yêu cầu.
  📘 Nguồn: Spanner Best Practices (2026 preview).

• Cloud Datastore (nay là Firestore in Native mode)
  ❌ Sai. Là NoSQL document database cho app development (web/mobile), ưu tiên scalability và queries linh hoạt, nhưng không hỗ trợ relational joins/SQL phức tạp hay ACID transactions đầy đủ cho operational systems. Migrate từ relational 20TB sẽ mất schema và performance kém.
  📘 Nguồn: Firestore Documentation (2025).

🧠 Tóm tắt lựa chọn: Với workload transactional 20TB từ on-premises, ưu tiên managed relational DB đơn giản, chi phí thấp → Cloud SQL là optimal! Nếu cần tư vấn migrate cụ thể, dùng DMS hoặc Contact Google Cloud Support. 🚀