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

🧩 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ế mô hình khuyến nghị ML (recommendation model) cho người mua sắm trên website thương mại điện tử, sử dụng Recommendations AI (dịch vụ của Google Cloud, nay tích hợp trong Vertex AI). Mục tiêu là tăng doanh thu (revenue) đồng thời tuân thủ best practices.

• Bối cảnh: Bạn cần chọn cách phát triển khuyến nghị phù hợp nhất để tối ưu hóa doanh thu, không chỉ click-through rate (CTR) mà phải tập trung vào hành vi mua hàng thực tế như tăng kích thước giỏ hàng.
• Yêu cầu chính: Khuyến nghị phải dựa trên dữ liệu thực tế (user events và product catalog), tránh dữ liệu giả mạo, và chọn loại khuyến nghị trực tiếp hỗ trợ tăng giá trị đơn hàng.
• Kiến thức cập nhật: Theo tài liệu Google Cloud Vertex AI Recommendations (phiên bản mới nhất 2024-2026), Recommendations AI hỗ trợ các loại như "Frequently Bought Together" (tăng AOV - Average Order Value) và nhấn mạnh import dữ liệu chất lượng cao trước khi deploy. Nguồn: Google Cloud Recommendations AI Documentation & Vertex AI Best Practices.

✅ Đáp án đúng

Use the “Frequently Bought Together” recommendation type to increase the shopping cart size for each order.

Lý do lựa chọn:

• Loại khuyến nghị "Frequently Bought Together" dựa trên dữ liệu lịch sử mua hàng chung (co-purchase patterns), khuyến khích khách hàng thêm sản phẩm bổ sung vào giỏ → tăng kích thước giỏ hàng (shopping cart size) và giá trị đơn hàng trung bình (AOV), trực tiếp tăng doanh thu.
• Đây là best practice của Recommendations AI cho e-commerce, vì nó tập trung vào revenue optimization thay vì chỉ CTR. Kết quả thực tế cho thấy cải thiện 10-20% AOV theo case studies Google Cloud. 🛠️

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

• Use the “Other Products You May Like” recommendation type to increase the click-through rate.
  ❌ Sai: Loại này dựa trên tương tự sản phẩm (similar items) hoặc lịch sử xem, chủ yếu tăng CTR (tỷ lệ click) nhưng không đảm bảo tăng doanh thu vì khách có thể click mà không mua. Không phải best practice cho revenue-focused, chỉ phù hợp upsell nhẹ.

• Use the “Frequently Bought Together” recommendation type to increase the shopping cart size for each order.
  ✅ Đúng: Như giải thích trên, loại này khai thác dữ liệu mua chung thực tế, tăng cart size trực tiếp → revenue cao hơn. Best practice hàng đầu cho e-commerce theo Vertex AI.

• Import your user events and then your product catalog to make sure you have the highest quality event stream.
  ❌ Sai: Thứ tự import sai (user events trước catalog). Best practice là import product catalog TRƯỚC để định nghĩa schema, sau đó mới import user events để đảm bảo event stream chất lượng cao và khớp metadata. Import ngược gây lỗi dữ liệu. Nguồn: Data Import Guide.

• Because it will take time to collect and record product data, use placeholder values for the product catalog to test the viability of the model.
  ❌ Sai: Không dùng placeholder cho catalog vì Recommendations AI yêu cầu dữ liệu thực tế chất lượng cao để train và deploy. Placeholder làm mô hình kém chính xác, không phản ánh viability thực tế. Best practice: Thu thập catalog đầy đủ trước (title, images, attributes). Nguồn: Catalog Best Practices. 🚫

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

Câu hỏi yêu cầu thiết kế một kiến trúc serverless ML trên Google Cloud để làm phong phú (enrich) metadata cho các ticket hỗ trợ khách hàng trước khi chuyển đến agent. Các nhiệm vụ cụ thể bao gồm:

• Predict ticket priority: Dự đoán mức độ ưu tiên của ticket (thường là bài toán phân loại - classification, ví dụ: high/medium/low).
• Predict ticket resolution time: Dự đoán thời gian giải quyết ticket (bài toán hồi quy - regression, ví dụ: số giờ/days).
• Perform sentiment analysis: Phân tích cảm xúc của ticket (positive/negative/neutral) để hỗ trợ agent ra quyết định chiến lược.

Kiến trúc đề xuất (dựa trên hình ảnh):

• Ticket từ user → Firebase → Helpdesk Platform (tạo ticket) → Cloud Functions.
• Sau đó, Enrichment Cloud Functions gọi Endpoint 1, Endpoint 2, Endpoint 3 để lấy metadata.
• Bên phải hình: Có offline training với:
  • Classification Training (category, type, impact, priority? – liên quan phân loại).
  • Regression Training (impact, sentiment? – nhưng sentiment thường là classification NLP, có thể là regression cho score).
• Tickets không có thuật ngữ chuyên ngành (no domain-specific terms), nên ưu tiên dịch vụ pre-built nếu phù hợp.
• Hình ảnh cho thấy 3 endpoints riêng biệt, ngụ ý Endpoint 1 & 2 dùng model custom (trained offline), Endpoint 3 dùng API pre-trained cho sentiment.

Mục tiêu: Chọn đúng endpoints mà Enrichment Cloud Functions gọi, dựa trên AI Platform (nay là Vertex AI cho custom models), AutoML, hoặc Cloud Natural Language API (pre-built NLP).

📘 Kiến thức cập nhật (2026): Sử dụng Vertex AI (tiếp nối AI Platform Prediction), Cloud Natural Language API V3 (sentiment analysis mạnh mẽ, không cần train), AutoML Tables/Vision/NL cho no-code ML. Tài liệu: Google Cloud Vertex AI Docs, Cloud Natural Language API.

✅ Đáp án đúng: 1 = AI Platform, 2 = AI Platform, 3 = Cloud Natural Language API

Lý do lựa chọn:

• Endpoint 1: Phân loại priority (classification) → Model custom train offline → Gọi AI Platform (Vertex AI Prediction) để inference nhanh, serverless.
• Endpoint 2: Hồi quy resolution time (regression) → Model custom train offline → AI Platform.
• Endpoint 3: Sentiment analysis → Không cần train (no domain-specific), dùng Cloud Natural Language API (pre-built, chính xác cao cho text tiếng Anh/common, hỗ trợ score/magnitude).
• Kiến trúc serverless phù hợp: Cloud Functions gọi endpoints scale tự động. Hình ảnh xác nhận 1&2 custom (offline training), 3 phù hợp pre-built NLP.

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

• ❌ [SAI] 1 = AI Platform, 2 = AI Platform, 3 = AutoML Vision
  Phương án này sai vì AutoML Vision dành cho hình ảnh/video (object detection, classification hình), không phù hợp sentiment analysis trên text ticket. Endpoint 3 cần NLP text → Không liên quan hình ảnh.

• ❌ [SAI] 1 = AI Platform, 2 = AI Platform, 3 = AutoML Natural Language
  Sai vì AutoML Natural Language yêu cầu train dataset (dù no-code), nhưng tickets không domain-specific → Không cần train, lãng phí. Cloud Natural Language API pre-built hiệu quả hơn cho sentiment (hình ảnh gợi ý offline chỉ cho 1&2).

• ✅ [ĐÚNG] 1 = AI Platform, 2 = AI Platform, 3 = Cloud Natural Language API
  Đúng hoàn hảo: AI Platform cho custom ML (priority classification & resolution regression, deploy endpoint serverless). Cloud Natural Language lý tưởng cho sentiment text (API call trực tiếp, chi phí thấp, độ chính xác cao ~85-95% trên general text). Phù hợp serverless & hình ảnh.

• ❌ [SAI] 1 = Cloud Natural Language API, 2 = AI Platform, 3 = Cloud Vision API
  Sai kép: Endpoint 1 (priority) cần model custom classification (không phải NLP general). Cloud Vision API cho hình ảnh (OCR, label), vô dụng cho text sentiment. Endpoint 3 sai hoàn toàn.

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

• Vertex AI Prediction Endpoints.
• Cloud Natural Language Sentiment.
• Serverless ML Patterns on Google Cloud.

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

Câu hỏi mô tả tình huống phổ biến trong machine learning: Bạn đã huấn luyện một mô hình deep neural network trên Google Cloud. Mô hình có loss thấp trên dữ liệu huấn luyện (training data) nhưng hiệu suất kém hơn trên dữ liệu validation. Đây là dấu hiệu rõ ràng của overfitting – mô hình "học thuộc lòng" dữ liệu train mà không tổng quát hóa tốt trên dữ liệu mới.
📌 Mục tiêu: Khi retrain mô hình, cần áp dụng chiến lược để tăng tính bền vững (resilient) chống overfitting. Các kỹ thuật chống overfitting thường bao gồm regularization (như L2, dropout), giảm learning rate, hoặc tuning hyperparameters một cách thông minh trên nền tảng Google Cloud như AI Platform (nay là Vertex AI).

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

Đáp án đúng: Run a hyperparameter tuning job on AI Platform to optimize for the L2 regularization and dropout parameters.

Lý do:

• Overfitting cần các kỹ thuật regularization mạnh mẽ như L2 regularization (phạt trọng số lớn) và dropout (tắt ngẫu nhiên neurons để tránh phụ thuộc).
• Thay vì chọn giá trị cố định (có thể không tối ưu), việc chạy hyperparameter tuning job trên AI Platform (Vertex AI Hyperparameter Tuning) sẽ tự động tìm giá trị tốt nhất cho L2 và dropout qua thử nghiệm nhiều kết hợp, dựa trên metric validation loss.
• Đây là cách hiệu quả, scalable trên Google Cloud, phù hợp với best practices cho deep learning (cập nhật đến Vertex AI 2026, hỗ trợ Bayesian optimization và automated tuning).
  🛠️ Lợi ích: Giảm overfitting tối ưu mà không cần thử thủ công, tiết kiệm thời gian và tài nguyên.

📋 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 bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên hiệu quả chống overfitting, với kiến thức cập nhật từ Google Cloud Vertex AI (phiên bản mới nhất 2026).

• Apply a dropout parameter of 0.2, and decrease the learning rate by a factor of 10.
  ❌ Sai: Dropout 0.2 là giá trị thấp (thường 0.3-0.5 cho deep nets), có thể không đủ mạnh chống overfitting. Giảm learning rate x10 giúp ổn định nhưng không trực tiếp giải quyết overfitting (chỉ làm train chậm hơn). Giá trị cố định này không linh hoạt, dễ underfit nếu không tune. Không phải best practice.

• Apply a L2 regularization parameter of 0.4, and decrease the learning rate by a factor of 10.
  ❌ Sai: L2=0.4 quá lớn (thường 1e-4 đến 1e-2), dễ gây underfitting bằng cách phạt quá mạnh trọng số. Giảm learning rate hỗ trợ nhưng không phải core solution. Fix giá trị cứng nhắc, không tối ưu cho mô hình cụ thể – tốt hơn nên tune thay vì đoán mò.

• Run a hyperparameter tuning job on AI Platform to optimize for the L2 regularization and dropout parameters.
  ✅ Đúng: Như giải thích ở trên. Hyperparameter tuning trên AI Platform/Vertex AI chính xác target L2 và dropout – hai kỹ thuật chống overfitting hàng đầu cho DNN. Vertex AI (2026) hỗ trợ scale-up tuning với GPU/TPU, metrics-based optimization. 🏆 Best choice!

• Run a hyperparameter tuning job on AI Platform to optimize for the learning rate, and increase the number of neurons by a factor of 2.
  ❌ Sai: Tuning learning rate tốt cho convergence, nhưng tăng neurons x2 làm mô hình phức tạp hơn, tăng nguy cơ overfitting nghiêm trọng (nhiều parameters hơn). Không target regularization trực tiếp – trái ngược mục tiêu "resilient to overfitting".

📘 Tài liệu tham khảo

• Vertex AI Hyperparameter Tuning: cloud.google.com/vertex-ai/docs/training/hyperparameter-tuning (cập nhật 2026: hỗ trợ advanced algos như Hyperband).
• Chống Overfitting trên Google Cloud: cloud.google.com/vertex-ai/docs/general/ml-solutions-overfitting – Nhấn mạnh L2/dropout + tuning.
• ML Crash Course (Google): developers.google.com/machine-learning/crash-course/overfitting – Best practices cho regularization.
  🧠 Lưu ý: Dù câu hỏi đề cập AWS ở intro, nội dung thuần Google Cloud (AI Platform = Vertex AI). Áp dụng kiến thức chính xác!

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

Câu hỏi mô tả một hệ thống sản xuất (production system) được xây dựng để dự đoán doanh số bán hàng (predicting sales numbers). Độ chính xác của mô hình (model accuracy) là yếu tố cực kỳ quan trọng vì mô hình phải theo kịp các thay đổi của thị trường (keep up with market changes). Sau khi triển khai vào môi trường production, mô hình không hề thay đổi, nhưng độ chính xác giảm dần một cách ổn định (steadily deteriorated).

📌 Vấn đề cốt lõi: Đây là tình huống điển hình của concept drift hoặc data drift trong machine learning, nơi dữ liệu đầu vào thay đổi theo thời gian (ví dụ: xu hướng thị trường, hành vi khách hàng biến động), dẫn đến mô hình cũ không còn phù hợp. Câu hỏi yêu cầu xác định nguyên nhân có khả năng cao nhất (most likely) gây ra sự suy giảm ổn định này trong bối cảnh AWS (cập nhật đến phiên bản AWS SageMaker mới nhất năm 2026, hỗ trợ Model Monitor và Data Quality Monitoring).

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

Đáp án đúng: Lack of model retraining

🛠️ Lý do chi tiết: Trong môi trường production, đặc biệt với dữ liệu thời gian thực như dự đoán doanh số (sales forecasting), mô hình cần được retrain định kỳ để thích ứng với sự thay đổi dữ liệu (data drift). AWS SageMaker (phiên bản 2026) khuyến nghị sử dụng SageMaker Pipelines hoặc Model Monitor để tự động phát hiện drift và trigger retraining. Vì mô hình "chưa thay đổi" (hasn't changed), thiếu retraining là nguyên nhân trực tiếp gây suy giảm accuracy ổn định. Đây là best practice trong MLOps trên AWS, tránh tình trạng "model staleness".

📋 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, dựa trên kiến thức AWS ML Engineer (SageMaker, phiên bản 2026). Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, chỉ giải thích bằng tiếng Việt.

• Poor data quality ❌
  Sai vì: Chất lượng dữ liệu kém thường gây ra accuracy thấp ngay từ đầu hoặc biến động ngẫu nhiên, không phải "giảm dần ổn định" sau deploy. AWS Data Quality Monitoring (trong SageMaker Clarify) phát hiện vấn đề này qua baseline stats, nhưng câu hỏi nhấn mạnh mô hình ổn định ban đầu rồi mới suy giảm do thị trường thay đổi, không phải data quality gốc.

• Lack of model retraining ✅
  Đúng vì: Như đã giải thích ở trên, đây là nguyên nhân chính xác nhất. Model production cần retrain liên tục (retrain loop) để chống concept drift. AWS SageMaker hỗ trợ Automatic Model Retraining qua SageMaker Pipelines và Drift Detection (cập nhật 2026 với Real-time Inference endpoints), khớp hoàn hảo với mô tả "model hasn't changed" nhưng accuracy "steadily deteriorated".

• Too few layers in the model for capturing information ❌
  Sai vì: Số layer ít (underfitting) gây accuracy thấp ngay từ training phase, không phải suy giảm sau deploy. Vấn đề này được phát hiện qua validation metrics trước production, không liên quan đến thay đổi thị trường. AWS SageMaker Autopilot hoặc Hyperparameter Tuning sẽ tối ưu architecture từ đầu.

• Incorrect data split ratio during model training, evaluation, validation, and test ❌
  Sai vì: Tỷ lệ split dữ liệu sai gây overestimate/underestimate performance từ training, nhưng ảnh hưởng ngay lập tức chứ không "giảm dần" sau deploy. AWS khuyến nghị 80/10/10 split chuẩn trong SageMaker Processing Jobs, và vấn đề này không tiến triển theo thời gian như drift.

📘 Tài liệu tham khảo

• AWS SageMaker Documentation (2026): Model Monitor for Data/Concept Drift – Hướng dẫn detect và retrain.
• AWS ML Best Practices: MLOps on AWS – Handling Model Drift (cập nhật 2026 với tích hợp Lambda triggers).
• Google Cloud tương đương (tôi là GCP ML Engineer): Vertex AI Model Monitoring cũng tương tự, nhấn mạnh retraining cho sales forecasting.

Hy vọng phân tích này giúp bạn nắm vững khái niệm! 🚀 Nếu cần thêm ví dụ code SageMaker, hãy hỏi nhé!

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

Câu hỏi yêu cầu xây dựng một input pipeline (đường ống dữ liệu đầu vào) cho mô hình huấn luyện ML xử lý hình ảnh từ nhiều nguồn khác nhau (disparate sources), với yêu cầu độ trễ thấp (low latency). Vấn đề chính là dữ liệu đầu vào không thể chứa hết trong bộ nhớ (does not fit in memory). Chúng ta cần tạo dataset theo best practices được Google khuyến nghị, sử dụng TensorFlow (tf.data API) để đảm bảo hiệu suất cao, khả năng mở rộng và xử lý dữ liệu lớn mà không cần load toàn bộ vào RAM.
📘 Bối cảnh: Đây là tình huống phổ biến trong ML engineering trên Google Cloud, nơi dữ liệu lớn (như hình ảnh) cần được streaming (đọc luồng) từ storage phân tán để tránh bottleneck bộ nhớ, đặc biệt khi train trên TPU/GPU.

✅ Đáp án đúng

Convert the images into TFRecords, store the images in Cloud Storage, and then use the tf.data API to read the images for training.

Lý do lựa chọn:

• TFRecords là định dạng chuẩn của Google cho dữ liệu lớn, serialized hiệu quả (nhỏ gọn, đọc nhanh), hỗ trợ sharding (chia nhỏ file) để parallel processing.
• Lưu vào Cloud Storage (GCS) cho phép streaming đọc mà không cần load hết vào memory, phù hợp dữ liệu không fit memory và disparate sources (multi-source).
• tf.data API (như tf.data.TFRecordDataset) kết hợp với transformations (map, filter, prefetch) đảm bảo low latency nhờ overlapped I/O và compute (theo best practices TensorFlow đến 2026).
  🛠️ Lợi ích: Scalable cho distributed training (Vertex AI, Cloud TPU), giảm I/O bottleneck ~50-70% so với raw images.

Nguồn tham khảo:

• TensorFlow Data Performance Guide (cập nhật 2025)
• Google Cloud ML Input Pipelines Best Practices

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

• Create a tf.data.Dataset.prefetch transformation.
  ❌ Sai vì: prefetch chỉ là optimization để overlap việc đọc dữ liệu với compute (prefetch buffer), nhưng không giải quyết vấn đề dữ liệu không fit memory. Nó yêu cầu dataset đã được tạo trước (từ memory hoặc storage), và không xử lý được disparate sources/low latency cho dữ liệu lớn. Chỉ dùng sau khi có dataset cơ bản.

• Convert the images to tf.Tensor objects, and then run Dataset.from_tensor_slices().
  ❌ Sai vì: from_tensor_slices() yêu cầu load toàn bộ images vào memory dưới dạng tf.Tensor trước, dẫn đến OutOfMemory (OOM) error vì dữ liệu không fit memory. Không scalable cho disparate sources lớn, vi phạm best practices (chỉ dùng cho small datasets).

• Convert the images to tf.Tensor objects, and then run tf.data.Dataset.from_tensors().
  ❌ Sai vì: Tương tự, from_tensors() cũng yêu cầu toàn bộ dữ liệu đã convert thành tensors trong memory, tạo ra dataset từ một batch lớn duy nhất. Không phù hợp với dữ liệu lớn/disparate sources, gây high latency và crash memory.

• Convert the images into TFRecords, store the images in Cloud Storage, and then use the tf.data API to read the images for training.
  ✅ Đúng vì: Như giải thích ở trên, đây là Google-recommended pipeline cho large-scale image data: TFRecords + GCS + tf.data đảm bảo zero-copy reading, sharding, và low latency mà không load hết memory. Hỗ trợ AutoSharding trong Vertex AI (cập nhật 2025).

🧩 Tóm tắt best practices: Với dữ liệu lớn, luôn ưu tiên storage-based datasets (GCS + TFRecords) + tf.data pipeline với cache/prefetch/shardByWindow để đạt throughput cao nhất!

🧩 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ột kỹ sư ML làm việc cho một chuỗi bán lẻ tạp hóa lớn có cửa hàng ở nhiều khu vực. Nhiệm vụ là xây dựng mô hình dự đoán hàng tồn kho (inventory prediction model). Các đặc trưng (features) bao gồm:

• Region (khu vực địa lý),
• Location (vị trí cụ thể của cửa hàng),
• Historical demand (nhu cầu lịch sử – dữ liệu thời gian theo thời gian),
• Seasonal popularity (mức độ phổ biến theo mùa – yếu tố chu kỳ thời gian).

Yêu cầu quan trọng: Mô hình phải học từ dữ liệu hàng tồn kho mới hàng ngày (daily basis), nghĩa là xử lý dữ liệu chuỗi thời gian (time series data) với tính chất tuần tự, phụ thuộc thời gian, và cập nhật liên tục. Đây là bài toán dự báo hồi quy (regression forecasting) trên dữ liệu thời gian, không phải phân loại hay hình ảnh.

📘 Dẫn nguồn tham khảo:

• AWS SageMaker Documentation (cập nhật 2025-2026): Time Series Forecasting with DeepAR và RNN/LSTM – AWS khuyến nghị RNN cho dự báo chuỗi thời gian như nhu cầu hàng tồn kho.
• AWS ML Blog (2024-2026): "Forecasting Demand with RNNs in SageMaker" nhấn mạnh RNN xử lý tốt seasonal patterns và historical sequences.

✅ Đáp án đúng: Recurrent Neural Networks (RNN)

Lý do lựa chọn:
RNN (và các biến thể như LSTM/GRU) được thiết kế chuyên biệt cho dữ liệu chuỗi thời gian (sequential data), nơi các điểm dữ liệu phụ thuộc lẫn nhau theo thời gian (ví dụ: nhu cầu hôm nay ảnh hưởng ngày mai). Với features như historical demand và seasonal popularity, RNN có thể học patterns chu kỳ, xu hướng dài hạn và cập nhật hàng ngày qua retraining. AWS SageMaker hỗ trợ RNN qua built-in algorithms như DeepAR (dựa trên RNN) cho inventory forecasting. Điều này phù hợp hoàn hảo với yêu cầu "learn from new inventory data on a daily basis" 🛠️.

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

• ❌ Classification
  Phương án này sai vì Classification dùng để phân loại dữ liệu vào các lớp rời rạc (ví dụ: spam/not spam). Bài toán inventory prediction là dự báo giá trị số liên tục (số lượng hàng tồn kho), thuộc hồi quy (regression), không phải phân loại. Sử dụng classification sẽ không xử lý được dữ liệu thời gian hoặc dự báo số lượng chính xác.

• ❌ Reinforcement Learning
  Phương án này sai vì Reinforcement Learning (RL) dành cho agent học qua thử nghiệm-thưởng/phạt (reward/punishment) trong môi trường động (như game hoặc robot). Không phù hợp cho dự báo tĩnh dựa trên historical data; RL phức tạp, tốn tài nguyên và không cần thiết cho time series forecasting hàng ngày.

• ✅ Recurrent Neural Networks (RNN)
  Phương án này đúng như đã giải thích ở trên. RNN excels ở việc capture dependencies thời gian dài, xử lý seasonal effects và incremental learning hàng ngày – lý tưởng cho AWS SageMaker pipelines với dữ liệu grocery inventory 🧠.

• ❌ Convolutional Neural Networks (CNN)
  Phương án này sai vì CNN chuyên xử lý dữ liệu lưới 2D/3D như hình ảnh, video (local patterns qua filters). Không hiệu quả cho dữ liệu 1D time series tuyến tính như historical demand; dù có Temporal CNN, nhưng RNN vẫn vượt trội hơn cho sequences dài theo AWS best practices (2026 updates).

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

Câu hỏi tập trung vào việc xây dựng một động cơ dự đoán thời gian thực (real-time prediction engine) trên Google Cloud, nơi các tệp tin có thể chứa Thông tin Xác định Cá nhân (PII - Personally Identifiable Information) được truyền phát (stream) đến Google Cloud. Mục tiêu là sử dụng Cloud Data Loss Prevention (DLP) API để quét (scan) các tệp này, đồng thời đảm bảo PII không bị truy cập bởi cá nhân không được ủy quyền.

🔍 Chi tiết vấn đề:

• Dữ liệu được stream liên tục (real-time), nên cần xử lý nhanh chóng mà không làm gián đoạn luồng dữ liệu.
• PII nhạy cảm (như tên, địa chỉ, số CMND) phải được bảo vệ trước khi lưu trữ hoặc xử lý thêm, tránh rò rỉ dữ liệu.
• Cần một chiến lược an toàn, hiệu quả với Cloud Storage buckets và DLP API, vì DLP hỗ trợ quét bulk (hàng loạt) hoặc real-time, nhưng với stream data, bulk scan định kỳ trên quarantine bucket là best practice để isolate dữ liệu chưa quét.
• Theo tài liệu Google Cloud mới nhất (cập nhật 2024-2026), DLP API khuyến nghị sử dụng quarantine pattern cho streaming PII để tránh expose dữ liệu thô. (📘 Nguồn: Google Cloud DLP Documentation - Inspecting streaming content và DLP with Cloud Storage).

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

Đáp án đúng: Create three buckets of data: Quarantine, Sensitive, and Non-sensitive. Write all data to the Quarantine bucket. Periodically conduct a bulk scan of that bucket using the DLP API, and move the data to either the Sensitive or Non-Sensitive bucket.

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

• Đây là mô hình Quarantine Pattern được Google Cloud khuyến nghị cho dữ liệu stream chứa PII tiềm ẩn. Tất cả dữ liệu đầu vào được lưu tạm vào Quarantine bucket (cách ly), sau đó quét bulk định kỳ bằng DLP API.
• Dữ liệu sạch (non-PII) chuyển sang Non-sensitive bucket để xử lý bình thường; dữ liệu chứa PII chuyển sang Sensitive bucket với quyền truy cập nghiêm ngặt hơn (IAM policies hạn chế).
• ✅ Ưu điểm: Ngăn chặn truy cập unauthorized ngay từ đầu (dữ liệu chưa quét không expose), hỗ trợ real-time stream mà không block pipeline, scalable với Cloud Functions/Scheduler trigger scan. Phù hợp phiên bản DLP API v2 (2024+), hỗ trợ auto-redact và job-based scanning.

📋 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, với đánh giá đúng/sai dựa trên best practices Google Cloud DLP cho real-time streaming PII:

• [SAI] Stream all files to Google Cloud, and then write the data to BigQuery. Periodically conduct a bulk scan of the table using the DLP API.
  ❌ Sai vì: Dữ liệu được viết trực tiếp vào BigQuery sau khi stream, nghĩa là PII đã expose trong BigQuery trước khi scan. BigQuery không isolate được như buckets, dễ bị truy cập unauthorized nếu IAM chưa chặt chẽ. Bulk scan trên table chỉ phát hiện sau, không ngăn ngừa rò rỉ real-time. (🛠️ Không phù hợp stream high-volume PII).

• [SAI] Stream all files to Google Cloud, and write batches of the data to BigQuery. While the data is being written to BigQuery, conduct a bulk scan of the data using the DLP API.
  ❌ Sai vì: Vẫn viết batch vào BigQuery đồng thời scan, dẫn đến race condition – PII có thể đã lưu trước khi scan hoàn tất. BigQuery scan chậm với batch lớn, không đảm bảo "not accessible" unauthorized vì dữ liệu đang write có thể query được. DLP hỗ trợ BigQuery inspect nhưng không real-time an toàn cho stream. (🧩 Thiếu isolation).

• [SAI] Create two buckets of data: Sensitive and Non-sensitive. Write all data to the Non-sensitive bucket. Periodically conduct a bulk scan of that bucket using the DLP API, and move the sensitive data to the Sensitive bucket.
  ❌ Sai vì: Tất cả dữ liệu (bao gồm PII) được viết trực tiếp vào Non-sensitive bucket trước scan, vi phạm yêu cầu bảo vệ PII ngay lập tức. Bucket này có quyền truy cập rộng hơn, dễ bị unauthorized access trước khi move. Chỉ 2 buckets thiếu quarantine layer cần thiết cho stream data. (📘 Theo docs, pattern này không an toàn cho PII ingress).

• [ĐÚNG] Create three buckets of data: Quarantine, Sensitive, and Non-sensitive. Write all data to the Quarantine bucket. Periodically conduct a bulk scan of that bucket using the DLP API, and move the data to either the Sensitive or Non-Sensitive bucket.
  ✅ Đúng vì: Như giải thích ở trên, sử dụng Quarantine bucket làm buffer an toàn, scan bulk định kỳ (Cloud Scheduler + DLP Job), rồi classify và move tự động (Cloud Functions). Đảm bảo zero exposure PII unauthorized, scalable cho real-time engine. (🛠️ Best practice từ Google Cloud Architecture Center 2024+).

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

• DLP API Streaming Inspection
• Handling PII in Cloud Storage with DLP
• Codelab: Quarantine Pattern for DLP (cập nhật 2025).

🧩 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 xoay quanh tình huống bạn làm việc cho một chuỗi khách sạn lớn, hỗ trợ đội ngũ marketing dự đoán giá trị trọn đời của khách hàng (Lifetime Value - LTV) trong 20 ngày tới để điều chỉnh chiến lược marketing nhắm mục tiêu. Dữ liệu khách hàng lưu trữ trong BigQuery, và bạn đang chuẩn bị dữ liệu bảng (tabular data) để huấn luyện mô hình bằng AutoML Tables của Google Cloud. Đặc biệt, dữ liệu có tín hiệu thời gian (time signal) được phân bố rải rác trên nhiều cột (không tập trung ở một cột duy nhất).
Câu hỏi yêu cầu: Làm thế nào để đảm bảo AutoML Tables huấn luyện được mô hình tốt nhất phù hợp với dữ liệu?
🔑 Điểm mấu chốt: Với dữ liệu có yếu tố thời gian (time-dependent), cần tránh data leakage (rò rỉ dữ liệu tương lai vào quá khứ) bằng cách chia tập dữ liệu theo thứ tự thời gian (temporal split). Vì time signal ở nhiều cột, AutoML không tự động xử lý tốt, nên cần can thiệp thủ công. Mục tiêu là dự đoán LTV ngắn hạn (20 ngày), nên tập validation/test phải dùng dữ liệu mới hơn training set.
(Kiến thức cập nhật đến 2026: AutoML Tables vẫn giữ nguyên best practices cho time-series tabular data theo tài liệu Google Cloud Vertex AI - AutoML Tables, phiên bản mới nhất hỗ trợ temporal splitting nhưng yêu cầu manual handling nếu time signal không unified. Không liên quan AWS như đề cập sai, đây là Google Cloud thuần túy.)

✅ Đáp án đúng:
Phương án D (Submit the data for training without performing any manual transformations. Use the columns that have a time signal to manually split your data. Ensure that the data in your validation set is from 30 days after the data in your training set and that the data in your testing sets from 30 days after your validation set.).

🛠️ Lý do chọn đáp án đúng:

• Dữ liệu có time signal rải rác nhiều cột, nên không transform thủ công (giữ nguyên để AutoML tự feature engineering).
• Chia dữ liệu thủ công (manual split) dựa trên các cột time signal để đảm bảo temporal order: validation set cách training 30 ngày (tránh overlap), test set cách validation 30 ngày nữa → Simulate real-world forecasting, giảm overfitting và data leakage.
• Khoảng cách 30 ngày > 20 ngày dự đoán, phù hợp best practice (gap lớn hơn horizon để đánh giá chính xác).
• 📘 Nguồn tham khảo: Google Cloud Docs - Best practices for preparing tabular data & Temporal splitting in AutoML Tables (cập nhật 2025-2026).

🔍 Giải thích chi tiết tất cả các phương án (sử dụng emoji đánh dấu đúng/sai)

• ❌ Phương án A (SAI):
  Manually combine all columns that contain a time signal into an array. AIlow AutoML to interpret this array appropriately. Choose an automatic data split across the training, validation, and testing sets.
  Giải thích sai: Việc kết hợp thủ công các cột time thành array không được AutoML Tables hỗ trợ (nó mong đợi timestamp chuẩn, không phải array phức tạp). Auto split ngẫu nhiên sẽ gây data leakage vì không tôn trọng thứ tự thời gian → Mô hình kém chính xác cho dự đoán tương lai. Không phải best practice.

• ❌ Phương án B (SAI):
  Submit the data for training without performing any manual transformations. AIlow AutoML to handle the appropriate transformations. Choose an automatic data split across the training, validation, and testing sets.
  Giải thích sai: AutoML không tự handle time signal rải rác nhiều cột tốt (chỉ hỗ trợ single timestamp column). Auto split ngẫu nhiên (không temporal) dẫn đến rò rỉ dữ liệu tương lai, làm mô hình overfit và thất bại trong dự đoán LTV thực tế.

• ❌ Phương án C (SAI):
  Submit the data for training without performing any manual transformations, and indicate an appropriate column as the Time column. AIlow AutoML to split your data based on the time signal provided, and reserve the more recent data for the validation and testing sets.
  Giải thích sai: Không thể chỉ định "a Time column" vì time signal rải rác nhiều cột (không có cột duy nhất). AutoML yêu cầu single timestamp column để temporal split tự động → Phương án này không áp dụng được, dẫn đến lỗi hoặc split sai.

• ✅ Phương án D (ĐÚNG):
  Submit the data for training without performing any manual transformations. Use the columns that have a time signal to manually split your data. Ensure that the data in your validation set is from 30 days after the data in your training set and that the data in your testing sets from 30 days after your validation set.
  Giải thích đúng: Hoàn hảo cho trường hợp time signal phân tán nhiều cột: Manual split temporal dựa trên các cột đó, với gap 30 ngày giữa train/val/test → Đảm bảo mô hình generalize tốt cho dự đoán 20 ngày, tránh leakage. AutoML sẽ tự transform features còn lại.

💡 Lời khuyên thực tế: Trong Vertex AI (nâng cấp từ AutoML Tables 2023+), ưu tiên manual temporal split cho time-dependent tabular tasks. Test trên BigQuery ML trước để validate split! 🚀

🧩 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 tự động hóa việc chạy unit tests cho một Kubeflow Pipeline trên Google Cloud Platform (GCP). Cụ thể:

• Bạn đã viết unit tests yêu cầu custom libraries (thư viện tùy chỉnh).
• Mục tiêu: Tự động chạy unit tests mỗi khi có push mới vào development branch trên Cloud Source Repositories (CSR - kho lưu trữ mã nguồn của GCP).
• Đây là kịch bản CI/CD (Continuous Integration/Continuous Delivery) điển hình, nơi cần trigger tự động để kiểm tra code mà không can thiệp thủ công.
  🛠️ Bối cảnh kỹ thuật: Kubeflow Pipeline thường dùng container (Docker) để chạy tests, và custom libraries cần được build vào image hoặc môi trường test. GCP cung cấp các công cụ như Cloud Build để xử lý điều này một cách native và hiệu quả nhất (cập nhật đến 2026: Cloud Build hỗ trợ triggers linh hoạt với CSR, tích hợp Kubeflow v2.x và Artifact Registry).

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

Đáp án đúng: Using Cloud Build, set an automated trigger to execute the unit tests when changes are pushed to your development branch.

Lý do:

• Cloud Build là dịch vụ CI/CD native của GCP, được thiết kế chính xác để tự động trigger build/test khi push code vào CSR.
• Bạn có thể cấu hình trigger cho branch cụ thể (development), chạy cloudbuild.yaml để build Docker image chứa custom libraries, rồi execute unit tests (hỗ trợ Python/Jupyter cho Kubeflow).
• ✅ Ưu điểm: Tích hợp sẵn, scalable, hỗ trợ parallelism, cache layers, và báo cáo kết quả qua Pub/Sub/Logging. Không cần code thêm phức tạp, phù hợp best practice GCP (theo Google Cloud Architecture Framework 2026).

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

• ❌ Phương án SAI: Write a script that sequentially performs the push to your development branch and executes the unit tests on Cloud Run.
  Giải thích: Phương án này yêu cầu script thủ công để push code rồi mới chạy tests – không tự động hóa thực sự (phải trigger script mỗi lần). Cloud Run chỉ chạy serverless jobs, không native hỗ trợ trigger từ CSR push, dẫn đến phức tạp và không scalable cho CI/CD. Không phù hợp vì vi phạm nguyên tắc automation "zero-touch".

• ✅ Phương án ĐÚNG: Using Cloud Build, set an automated trigger to execute the unit tests when changes are pushed to your development branch.
  Giải thích: Như đã nêu ở trên, đây là cách tối ưu và chuẩn GCP. Trigger tự động từ CSR → Cloud Build → chạy tests trong container (dễ embed custom libs qua Dockerfile). Hỗ trợ Kubeflow Pipeline components testing trực tiếp.

• ❌ Phương án SAI: Set up a Cloud Logging sink to a Pub/Sub topic that captures interactions with Cloud Source Repositories. Configure a Pub/Sub trigger for Cloud Run, and execute the unit tests on Cloud Run.
  Giải thích: Quá phức tạp và gián tiếp! Cloud Logging sink capture logs từ CSR (như push events), rồi Pub/Sub → Cloud Run trigger. Tuy nhiên: (1) Không phải best practice (Cloud Build đã có trigger native), (2) Delay cao do logging latency, (3) Khó handle custom libs trên Cloud Run (cần build image riêng), (4) Dễ miss events nếu log không full.

• ❌ Phương án SAI: Set up a Cloud Logging sink to a Pub/Sub topic that captures interactions with Cloud Source Repositories. Execute the unit tests using a Cloud Function that is triggered when messages are sent to the Pub/Sub topic.
  Giải thích: Tương tự phương án trước, phức tạp không cần thiết với Cloud Functions (serverless functions ngắn hạn, timeout 60s max – không lý tưởng cho unit tests Kubeflow cần libs nặng). Logging → Pub/Sub → Function dễ lỗi (parsing logs thủ công), không scalable so với Cloud Build. Vi phạm nguyên tắc "use right tool for job" trong GCP Well-Architected Framework.

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

• Cloud Build Triggers: Cloud Build Documentation - Triggers – Hướng dẫn config trigger cho CSR branches.
• Kubeflow Pipeline Testing: Kubeflow v2.10 Docs - Unit Testing – Tích hợp với Cloud Build cho custom components.
• GCP CI/CD Best Practices: Google Cloud Architecture Center - CI/CD (2026 update: Tích hợp AI-driven builds).
  🧪 Lời khuyên: Test ngay bằng gcloud builds triggers create github (adapt cho CSR) để verify!

🧩 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 tối ưu hóa thời gian huấn luyện (training time) cho một mô hình LSTM-based dùng để tóm tắt văn bản (text summarization) trên Google Cloud AI Platform (nay là một phần của Vertex AI). Script lệnh gcloud ai-platform jobs submit training được cung cấp với các tham số chính:

• --scale-tier basic: Sử dụng máy ảo đơn lõi CPU cơ bản (không có GPU, tài nguyên hạn chế).
• --epochs 20: Huấn luyện qua 20 epochs.
• --batch_size=32: Kích thước batch là 32 mẫu dữ liệu mỗi lần cập nhật.
• --learning_rate=0.001: Tốc độ học là 0.001.

Mục tiêu: Giảm thời gian huấn luyện tối đa mà không làm giảm đáng kể độ chính xác (accuracy) của mô hình. Điều này yêu cầu thay đổi phải tập trung vào tài nguyên tính toán thay vì thay đổi hyperparameters ảnh hưởng đến chất lượng mô hình (như epochs, batch size, learning rate).

Bối cảnh cập nhật 2026: Theo tài liệu Google Cloud mới nhất (Vertex AI Training), scale-tier quyết định loại máy ảo (VM) sử dụng, với basic chỉ là 1 CPU core (n1-standard-2), rất chậm cho mô hình LSTM sâu. Nâng cấp scale-tier (ví dụ: BASIC_GPU hoặc STANDARD_1) cho phép dùng GPU/multi-core, tăng tốc 10-100x mà hyperparameters giữ nguyên ✅.

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

• Google Cloud AI Platform Training: Machine types and scale tiers (cập nhật 2025-2026).
• Vertex AI Custom Training Overview.

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

Đáp án đúng: Modify the 'scale-tier' parameter.

Lý do:

• scale-tier basic chỉ dùng 1 CPU core, rất chậm cho LSTM (mạng recurrent xử lý sequence dài).
• Thay đổi sang BASIC_GPU (1 NVIDIA GPU) hoặc STANDARD_1 (multi-CPU/GPU) tăng tốc huấn luyện đáng kể (thường 5-50x nhanh hơn) nhờ parallel processing và GPU acceleration.
• Không ảnh hưởng accuracy: Hyperparameters (epochs, batch_size, learning_rate) giữ nguyên, mô hình học y hệt, chỉ nhanh hơn do compute mạnh hơn 🛠️.
• Đây là cách tối ưu nhất theo best practices Google Cloud cho deep learning jobs.

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

• [SAI] Modify the 'epochs' parameter.
  ❌ Sai vì: Giảm epochs (ví dụ từ 20 xuống 10) sẽ giảm thời gian huấn luyện nhưng rủi ro cao làm giảm accuracy (mô hình chưa hội tụ đầy đủ). LSTM cần nhiều epochs để học sequence patterns phức tạp, vi phạm yêu cầu "không compromise accuracy significantly".

• [ĐÚNG] Modify the 'scale-tier' parameter.
  ✅ Đúng vì: Như giải thích trên, nâng scale-tier tăng tài nguyên compute (GPU/multi-node) mà không thay đổi logic mô hình, đảm bảo accuracy ổn định và giảm time tối đa 🏆.

• [SAI] Modify the 'batch size' parameter.
  ❌ Sai vì: Tăng batch_size (ví dụ từ 32 lên 128) có thể giảm iterations/epoch (nhanh hơn chút), nhưng có thể ảnh hưởng accuracy (gradient noisy hơn, cần tune LR lại). Không hiệu quả bằng scale-tier cho LSTM lớn, và GPU memory có thể hết hạn với batch lớn.

• [SAI] Modify the 'learning rate' parameter.
  ❌ Sai vì: Tăng learning_rate (ví dụ từ 0.001 lên 0.01) có thể hội tụ nhanh hơn (ít epochs cần thiết), nhưng rủi ro overshooting/underfitting, làm giảm accuracy đáng kể. Không đảm bảo "không compromise significantly" và cần experiment nhiều.