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

Đáp án

B — Đặt các cột liên quan vào cùng một column family.

Vì sao đúng

⚠ Cấu trúc lưu trữ của Bigtable:

⚠ Row key
   ├── ⚠ Column family "thong-tin"
   │      ├── cột: ten, tuoi, dia-chi
   └── ⚠ Column family "giao-dich"
          ├── cột: so-tien, ngay
        ↓
⚠ Mỗi column family được lưu
   GẦN NHAU trên đĩa
        ↓
⚠ Đọc một family = ⚠ đọc ÍT dữ liệu hơn
   ⚠ nhanh hơn

⚠ Đọc được theo từng column family — ⚠ nhóm cột hay dùng chung vào một family thì ⚠ mỗi lần đọc không phải kéo theo cột không cần.

Vì sao các phương án khác sai

• C (tạo secondary index cho mỗi nhóm cột) — ⚠ Bigtable KHÔNG có secondary index: ⚠ chỉ truy vấn bằng row key hoặc quét khoảng row key.

• D (mỗi nhóm cột một bảng riêng) — ⚠ phá vỡ tính nguyên tử: ⚠ Bigtable chỉ đảm bảo nguyên tử trong một dòng; ⚠ tách bảng là mất điều đó và ⚠ phải đọc nhiều lần.

• A (mỗi nhóm một row key riêng) — ⚠ nhân bản dữ liệu và làm hỏng thiết kế khoá: ⚠ row key là nền tảng của mọi truy vấn Bigtable.

Ghi nhớ

⚠ Bigtable — khái niệm phải thuộc: | Khái niệm | Nội dung | |---|---| | ⚠ Row key | ⚠ cách DUY NHẤT để truy vấn — thiết kế quan trọng nhất | | ⚠ Column family | ⚠ nhóm cột lưu gần nhau, khai TRƯỚC | | ⚠ Column qualifier | ⚠ tên cột, tạo động, không cần khai | | ⚠ Cell | ⚠ giá trị + dấu thời gian, có nhiều phiên bản | | ⚠ Số column family | ⚠ nên ÍT — dưới 100, lý tưởng là vài cái |

Từ khoá nhận diện:

"nhóm cột hay dùng chung" → ⚠ column family "truy vấn theo cột không phải khoá" → ⚠ Bigtable KHÔNG làm được — cần thiết kế lại row key "điểm nóng khi ghi" → ⚠ row key tuần tự — cần salting hoặc đảo trường

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Row key có gây điểm nóng không | ⚠ Key Visualizer cho thấy ngay | | Số column family có quá nhiều không | | | Có đang cố truy vấn theo cột không phải khoá không | ⚠ dấu hiệu chọn nhầm CSDL |

Và điều quyết định thành bại của một hệ thống Bigtable: thiết kế row key. Nó phải được quyết ngay từ đầu dựa trên cách bạn sẽ đọc dữ liệu, và sửa nó về sau nghĩa là chép lại toàn bộ bảng.

Đáp án

C — Bạn đã chọn loại UUID sinh ra chuỗi có thứ tự tuần tự.

Vì sao đúng

⚠ Không phải UUID nào cũng ngẫu nhiên.

⚠ UUID tuần tự làm tiền tố row key
        ↓
⚠ Các khoá liên tiếp GẦN NHAU
        ↓
⚠ Cùng rơi vào MỘT tablet
        ↓
⚠ ĐIỂM NÓNG vẫn xảy ra
   ⚠ dù đã "dùng UUID"

⚠ Cách sửa: ⚠ dùng UUID v4, ⚠ hoặc băm (hash) tiền tố để rải đều.

Vì sao các phương án khác sai

• B (secondary index làm chậm việc ghi) — ⚠ Bigtable KHÔNG có secondary index: ⚠ phương án bịa.

• D (cấu hình column family sai) — ⚠ column family ảnh hưởng hiệu năng ĐỌC: ⚠ không gây điểm nóng khi ghi.

• A (tên cột row key quá dài) — ⚠ row key không có "tên cột": ⚠ độ dài khoá ảnh hưởng dung lượng, ⚠ không phải phân bố.

Ghi nhớ

⚠ Điểm nóng (hotspotting) trong Bigtable — bảng phải thuộc: | Nguyên nhân | Ví dụ | |---|---| | ⚠ Dấu thời gian ở ĐẦU khoá | ⚠ mọi ghi mới đổ vào một tablet | | ⚠ ID tăng dần | ⚠ auto-increment | | ⚠ UUID tuần tự (v1, v7) | ⚠ đề này | | ⚠ Giá trị lệch nặng | ⚠ 90% dữ liệu cùng một tiền tố |

Từ khoá nhận diện:

"điểm nóng khi ghi" → ⚠ row key tuần tự "đã dùng UUID mà vẫn nóng" → ⚠ UUID loại có thứ tự "xem phân bố tải theo khoá" → ⚠ Key Visualizer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Row key thật sự phân bố thế nào | ⚠ Key Visualizer | | UUID đang dùng là phiên bản mấy | ⚠ v4 mới ngẫu nhiên | | Có cần quét theo khoảng không | ⚠ quyết định được phép băm hay không |

Và bài học đắt nhất từ câu này: "dùng UUID" không phải một giải pháp, mà là một câu chưa đầy đủ. Phiên bản của UUID mới là thứ quyết định dữ liệu có rải đều hay không.

Đáp án

B — Chính sách autoscaling đang thu nhỏ cụm, và dữ liệu shuffle bị mất khi một node bị gỡ khỏi cụm.

Vì sao đúng

⚠ Shuffle là gì và vì sao nó dễ vỡ:

⚠ Spark chạy một stage
        ↓
⚠ Ghi dữ liệu SHUFFLE ra ĐĨA CỤC BỘ
   của từng worker
        ↓
⚠ Stage sau ĐỌC dữ liệu shuffle đó
   từ các worker khác
        ↓ ⚠ Autoscaling GỠ một worker
⚠ Dữ liệu shuffle trên node đó BIẾN MẤT
        ↓
⚠ FetchFailedException

⚠ Đúng đặc điểm "không thường xuyên" (intermittently) trong đề — ⚠ chỉ xảy ra khi cụm co lại đúng lúc có shuffle đang dở.

Vì sao các phương án khác sai

• C (autoscaling thêm node quá nhanh làm mất dữ liệu) — ⚠ THÊM node không làm mất gì: ⚠ node mới chỉ nhận việc mới.

• A (bucket GCS phân quyền sai) — ⚠ sẽ gây lỗi quyền truy cập, ⚠ không phải FetchFailedException, ⚠ và ⚠ sẽ xảy ra nhất quán chứ không lúc có lúc không.

• D (dùng Cloud Storage thay vì lưu trữ cục bộ) — ⚠ dùng GCS là THỰC HÀNH TỐT cho Dataproc: ⚠ nó không gây lỗi này; ⚠ shuffle vẫn dùng đĩa cục bộ dù dữ liệu nằm ở GCS.

Ghi nhớ

⚠ Autoscaling Dataproc — bảng phải thuộc: | Thiết lập | Ý nghĩa | |---|---| | ⚠ gracefulDecommissionTimeout | ⚠ chờ node hoàn thành việc trước khi gỡ — THUỐC CHỮA chính | | ⚠ scaleDownFactor | ⚠ thu nhỏ nhanh hay chậm — đặt thấp hoặc 0 | | ⚠ cooldownPeriod | ⚠ khoảng nghỉ giữa hai lần co giãn | | ⚠ Secondary worker (preemptible) | ⚠ chỉ tính toán, KHÔNG lưu HDFS — an toàn hơn khi gỡ |

Từ khoá nhận diện:

"FetchFailedException lúc có lúc không" → ⚠ autoscaling thu nhỏ trong lúc shuffle "job chết khi dùng preemptible" → ⚠ VM bị thu hồi giữa chừng "tránh mất dữ liệu shuffle" → ⚠ Enhanced Flexibility Mode (EFM)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi xảy ra có trùng lúc cụm co lại không | ⚠ đối chiếu log autoscaling | | EFM đã bật chưa | | | gracefulDecommissionTimeout đặt bao nhiêu | ⚠ 0 nghĩa là gỡ ngay lập tức |

Và nguồn gốc của cả lớp lỗi này: Spark giả định worker còn sống cho tới hết job, còn autoscaling thì giả định gỡ một worker rảnh là vô hại. Hai giả định đó gặp nhau đúng lúc shuffle đang dở dang.

Đáp án

D — Bigtable.

Vì sao đúng

⚠ Ba manh mối trong đề, cả ba đều chỉ về Bigtable: | Manh mối | Vì sao là Bigtable | |---|---| | ⚠ Từng dùng Hadoop HBase | ⚠ Bigtable dùng CHÍNH API của HBase | | ⚠ Ghi khối lượng lớn, độ trễ thấp | ⚠ đúng thế mạnh của Bigtable | | ⚠ IoT, dữ liệu cảm biến | ⚠ ca dùng kinh điển — chuỗi thời gian |

⚠ Điểm quyết định: ⚠ Bigtable tương thích API HBase — ⚠ mã HBase hiện có ⚠ di trú với thay đổi tối thiểu.

Vì sao các phương án khác sai

• A (Cloud Firestore) — ⚠ CSDL tài liệu cho ứng dụng web/di động: ⚠ không thiết kế cho thông lượng ghi cực cao của IoT.

• B (Cloud Spanner) — ⚠ CSDL quan hệ toàn cầu, nhất quán mạnh: ⚠ mạnh nhưng ⚠ đắt hơn nhiều và ⚠ không cần thiết cho dữ liệu cảm biến.

• C (BigQuery) — ⚠ kho PHÂN TÍCH, không phải CSDL vận hành: ⚠ độ trễ truy vấn tính bằng giây, ⚠ không hợp với ghi từng bản ghi độ trễ thấp; ⚠ nhưng ⚠ thường là đích cuối để phân tích sau khi dữ liệu qua Bigtable.

Ghi nhớ

⚠ Ánh xạ hệ sinh thái Hadoop sang Google Cloud — bảng phải thuộc: | Hadoop | Google Cloud | |---|---| | ⚠ HBase | ⚠ Bigtable | | ⚠ HDFS | ⚠ Cloud Storage | | ⚠ Hive | ⚠ BigQuery | | ⚠ Spark, MapReduce | ⚠ Dataproc hoặc Dataflow | | ⚠ Kafka | ⚠ Pub/Sub | | ⚠ Oozie / Airflow | ⚠ Cloud Composer |

Từ khoá nhận diện:

"di trú từ HBase" → ⚠ Bigtable "di trú Hive" → ⚠ BigQuery "di trú Kafka" → ⚠ Pub/Sub "giữ nguyên cụm Spark/Hadoop" → ⚠ Dataproc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu có thật sự trên 1 TB không | ⚠ dưới ngưỡng có lựa chọn rẻ hơn | | Mọi truy vấn có đi qua row key được không | | | Cụm có bị rảnh nhiều không | ⚠ vẫn tính tiền theo node |

Và điều khiến việc di trú từ HBase sang Bigtable dễ hơn mọi lựa chọn khác: cùng một API. Phần khó không nằm ở mã, mà ở chỗ thiết kế row key cũ có còn hợp với cách Bigtable chia tablet hay không.

Đáp án

D — Sliding window (còn gọi là hopping window).

Vì sao đúng

⚠ Yêu cầu của đề: ⚠ phân tích nhiệt độ của MỘT GIỜ VỪA QUA, ⚠ liên tục, ⚠ để phát cảnh báo.

⚠ Sliding window: cửa sổ dài 1 giờ
   ⚠ trượt mỗi 1 phút
        ↓
09:00–10:00  → ⚠ tính trung bình, độ lệch chuẩn
09:01–10:01  → ⚠ tính lại
09:02–10:02  → ⚠ tính lại
        ↓
⚠ LUÔN có kết quả cho "một giờ qua"

⚠ Nếu dùng fixed window thì sao: | Vấn đề | Hậu quả | |---|---| | ⚠ Cửa sổ 09:00–10:00 rồi 10:00–11:00 | ⚠ không chồng lấn | | ⚠ Lúc 10:05 chỉ có 5 phút dữ liệu | ⚠ không phải "một giờ qua" | | ⚠ Cảnh báo chỉ đến mỗi giờ một lần | ⚠ quá chậm |

Vì sao các phương án khác sai

• A (fixed / tumbling window) — ⚠ các cửa sổ KHÔNG chồng lấn: ⚠ hợp cho báo cáo theo giờ, ⚠ không hợp cho "một giờ trượt vừa qua".

• B (session window) — ⚠ nhóm sự kiện theo khoảng NGHỈ giữa chúng: ⚠ dùng cho hành vi người dùng (phiên truy cập), ⚠ không phải chuỗi cảm biến liên tục.

• C (concurrent window) — ⚠ KHÔNG tồn tại trong Apache Beam: ⚠ phương án bịa.

Ghi nhớ

⚠ Các loại cửa sổ trong Apache Beam — bảng phải thuộc: | Loại | Đặc điểm | Dùng cho | |---|---|---| | ⚠ Fixed (tumbling) | ⚠ không chồng lấn, độ dài cố định | ⚠ báo cáo theo giờ/ngày | | ⚠ Sliding (hopping) | ⚠ CHỒNG LẤN, có độ dài và bước trượt | ⚠ trung bình trượt, cảnh báo — đề này | | ⚠ Session | ⚠ theo khoảng nghỉ, độ dài thay đổi | ⚠ phiên người dùng | | ⚠ Global | ⚠ một cửa sổ duy nhất | ⚠ batch, hoặc dùng với trigger tuỳ chỉnh |

Từ khoá nhận diện:

"N phút/giờ VỪA QUA, cập nhật liên tục" → ⚠ sliding window "tổng theo từng giờ" → ⚠ fixed window "gom hoạt động của một người dùng" → ⚠ session window "dữ liệu tới muộn" → ⚠ watermark và trigger, không phải loại cửa sổ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước trượt có quá nhỏ không | ⚠ tốn tài nguyên theo cấp số | | Dữ liệu cảm biến tới muộn bao nhiêu | ⚠ quyết định allowed lateness | | Dùng event time hay processing time | ⚠ với IoT gần như luôn là event time |

Và điều khiến xử lý luồng khó hơn xử lý theo lô: dữ liệu không đến theo thứ tự nó xảy ra. Mọi khái niệm cửa sổ, watermark và trigger đều sinh ra để trả lời một câu hỏi duy nhất — chờ đến bao giờ thì coi là đủ.

Đáp án

D — Vertex AI custom training (huấn luyện tuỳ chỉnh).

Vì sao đúng

⚠ Đề có hai yêu cầu tưởng như mâu thuẫn: | Yêu cầu | Cách giải | |---|---| | ⚠ Muốn dùng dịch vụ ĐƯỢC QUẢN | ⚠ Vertex AI lo hạ tầng, co giãn, theo dõi | | ⚠ Muốn TỰ tinh chỉnh siêu tham số | ⚠ custom training cho toàn quyền với mã huấn luyện |

⚠ Bạn viết mã huấn luyện
   (⚠ TensorFlow, PyTorch, scikit-learn)
        ↓
⚠ Vertex AI chạy trên hạ tầng được quản
        ↓
⚠ BẠN quyết siêu tham số
   ⚠ hoặc dùng Vertex AI Vizier
     để dò tự động

Vì sao các phương án khác sai

• A (Vertex AI AutoML) — ⚠ bẫy gần nhất, khác đúng điểm đề nhấn: ⚠ AutoML tự chọn kiến trúc và siêu tham số; ⚠ đó chính là thứ ⚠ đội này KHÔNG muốn — họ muốn tự tinh chỉnh.

• C (BigQuery ML) — ⚠ rất tiện nhưng ít tuỳ biến: ⚠ huấn luyện bằng SQL, ⚠ chỉ chỉnh được một số tuỳ chọn giới hạn.

• B (Cloud TPU) — ⚠ là PHẦN CỨNG, không phải dịch vụ ML được quản: ⚠ dùng TPU vẫn phải có nơi chạy mã.

Ghi nhớ

⚠ Thang tuỳ biến của các dịch vụ ML Google Cloud — bảng phải thuộc: | Dịch vụ | Tuỳ biến | Công sức | |---|---|---| | ⚠ API dựng sẵn (Vision, NL, Speech) | ⚠ không có | ⚠ thấp nhất | | ⚠ AutoML | ⚠ chỉ chọn dữ liệu và mục tiêu | ⚠ thấp | | ⚠ BigQuery ML | ⚠ vừa phải, SQL | ⚠ thấp | | ⚠ Vertex AI custom training | ⚠ TOÀN QUYỀN — đề này | ⚠ cao | | ⚠ Tự dựng trên GKE/GCE | ⚠ toàn quyền tuyệt đối | ⚠ cao nhất |

Từ khoá nhận diện:

"tự tinh chỉnh siêu tham số" → ⚠ Vertex AI custom training "không có chuyên gia ML, muốn nhanh" → ⚠ AutoML "nhà phân tích biết SQL, dữ liệu đã ở BigQuery" → ⚠ BigQuery ML "bài toán phổ biến, không cần huấn luyện" → ⚠ API dựng sẵn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội có thật sự cần tuỳ biến sâu không | ⚠ AutoML thường đủ tốt và rẻ hơn nhiều | | Đã đo baseline bằng AutoML chưa | ⚠ để biết mô hình tự viết có hơn không | | Có kế hoạch theo dõi mô hình sau khi triển khai không | |

Và bước hay bị bỏ qua nhất trong dự án ML: dựng một baseline đơn giản trước. Nếu AutoML đạt 92% trong một buổi chiều, thì mô hình tự viết mất ba tuần cần phải đạt hơn thế mới đáng.

Đáp án

D — gcloud functions deploy.

Vì sao đúng

⚠ Đề hỏi lệnh để TRIỂN KHAI hàm — ⚠ không phải lệnh để gửi hay đọc tin nhắn.

gcloud functions deploy TEN_HAM \
  --trigger-topic=TEN_TOPIC \
  --runtime=python312 \
  --entry-point=ham_xu_ly

⚠ Phân biệt rõ ba nhóm lệnh: | Việc | Lệnh | |---|---| | ⚠ Triển khai hàm | ⚠ gcloud functions deploy — đề này | | ⚠ Gửi tin nhắn | ⚠ gcloud pubsub topics publish | | ⚠ Đọc tin nhắn | ⚠ gcloud pubsub subscriptions pull |

Vì sao các phương án khác sai

• B (gcloud pubsub topics publish) — ⚠ GỬI một tin nhắn vào topic: ⚠ dùng để thử, ⚠ không triển khai gì.

• C (gcloud pubsub topics pull) — ⚠ sai cấp tài nguyên: ⚠ pull thuộc về subscriptions, không phải topics.

• A (gcloud pubsub subscription publish) — ⚠ sai cả hai vế: ⚠ publish là của topic, ⚠ và ⚠ nhóm lệnh viết đúng là subscriptions (số nhiều).

Ghi nhớ

⚠ Cấu trúc lệnh gcloud — quy tắc phải thuộc:

gcloud <NHÓM> <TÀI NGUYÊN số nhiều> <ĐỘNG TỪ>
   ↓
gcloud pubsub topics create
gcloud pubsub subscriptions pull
gcloud functions deploy
gcloud dataproc clusters create

⚠ Tài nguyên gần như luôn ở dạng SỐ NHIỀU.

Từ khoá nhận diện:

"triển khai hàm" → ⚠ gcloud functions deploy "gửi tin nhắn thử" → ⚠ gcloud pubsub topics publish "đọc tin nhắn thử" → ⚠ gcloud pubsub subscriptions pull "xem log của hàm" → ⚠ gcloud functions logs read

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có chịu được tin nhắn lặp không | | | Đã cấu hình dead-letter topic chưa | | | Timeout của hàm có đủ cho xử lý chậm nhất không | |

Và lỗi phổ biến nhất khi nối Cloud Functions với Pub/Sub: quên rằng tin nhắn có thể tới hai lần. Một hàm ghi thêm dòng vào cơ sở dữ liệu mà không kiểm tra trùng sẽ âm thầm nhân đôi dữ liệu, và không có lỗi nào hiện ra.

Đáp án

C — gcloud dataproc clusters create.

Vì sao đúng

⚠ Quy tắc đặt tên lệnh gcloud:

gcloud <DỊCH VỤ> <TÀI NGUYÊN> <ĐỘNG TỪ>
   ↓
gcloud dataproc clusters create
   ⚠ dịch vụ:   dataproc
   ⚠ tài nguyên: clusters (SỐ NHIỀU)
   ⚠ động từ:   create

⚠ Lệnh đầy đủ với CMEK:

gcloud dataproc clusters create ten-cum \
  --region=asia-southeast1 \
  --gce-pd-kms-key=projects/P/locations/L/keyRings/R/cryptoKeys/K

Vì sao các phương án khác sai

• A (gcloud clusters dataproc create) — ⚠ đảo ngược thứ tự: ⚠ dịch vụ phải đứng trước tài nguyên.

• B (gcloud clusters dataproc kms) — ⚠ sai thứ tự VÀ sai động từ: ⚠ kms không phải động từ.

• D (gcloud dataproc clusters kms) — ⚠ thứ tự đúng nhưng động từ sai: ⚠ KMS được khai bằng cờ --gce-pd-kms-key, ⚠ không phải một lệnh con.

Ghi nhớ

⚠ Mẫu lệnh gcloud — bảng phải thuộc: | Lệnh | Việc | |---|---| | ⚠ gcloud dataproc clusters create | ⚠ tạo cụm Dataproc | | ⚠ gcloud dataproc jobs submit spark | ⚠ gửi job Spark | | ⚠ gcloud compute instances create | ⚠ tạo VM | | ⚠ gcloud kms keys create | ⚠ tạo khoá | | ⚠ Quy luật chung | ⚠ dịch vụ → tài nguyên số nhiều → động từ |

Từ khoá nhận diện:

"tạo cụm Dataproc với CMEK" → ⚠ --gce-pd-kms-key "tạo cụm với sole-tenant" → ⚠ --node-group "cụm tự xoá sau khi rảnh" → ⚠ --max-idle

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Service agent đã có quyền dùng khoá chưa | | | Cụm có bật --max-idle không | ⚠ cụm quên xoá là khoản lãng phí lớn nhất | | Khoá có cùng vùng với cụm không | |

Và khoản chi phí lãng phí phổ biến nhất với Dataproc: cụm được tạo ra để chạy một job rồi không ai xoá. Một cờ --max-idle duy nhất giải quyết được cả vấn đề đó.

Đáp án

A — Dùng Cloud EKM (External Key Manager) để quản lý khoá bên ngoài.

Vì sao đúng

⚠ Yêu cầu của đề: ⚠ khoá phải nằm trong hệ thống quản khoá TRIỂN KHAI NGOÀI đám mây công cộng, ⚠ mà vẫn giảm gánh nặng quản trị.

⚠ Cloud EKM
        ↓
⚠ Khoá nằm ở nhà cung cấp BÊN NGOÀI
   (⚠ Thales, Fortanix, Equinix…)
        ↓
⚠ BigQuery gọi qua Cloud KMS
   → ⚠ EKM → ⚠ hệ thống ngoài
        ↓
⚠ Google KHÔNG BAO GIỜ thấy
   khoá gốc
        ↓
⚠ Vẫn dùng BigQuery như bình thường

⚠ Vì sao "giảm gánh nặng quản trị": ⚠ EKM tích hợp sẵn với các dịch vụ Google Cloud; ⚠ không phải tự dựng lớp mã hoá nào.

Vì sao các phương án khác sai

• B (dùng external data source và tự mã hoá bên ngoài Google Cloud) — ⚠ gánh nặng quản trị RẤT LỚN: ⚠ phải tự mã hoá, tự giải mã, ⚠ và ⚠ mất hầu hết khả năng truy vấn của BigQuery.

• C (dùng Data Catalog để quản khoá) — ⚠ Data Catalog là công cụ SIÊU DỮ LIỆU: ⚠ mô tả dữ liệu ở đâu, nghĩa là gì; ⚠ không quản khoá.

• D (dùng Dataproc để quản khoá) — ⚠ Dataproc là dịch vụ xử lý Spark/Hadoop: ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Bốn mức kiểm soát khoá — bảng phải thuộc: | Mức | Khoá nằm ở | |---|---| | ⚠ Google-managed (mặc định) | ⚠ Google, tự động, miễn phí | | ⚠ CMEK | ⚠ Cloud KMS, khách quản | | ⚠ Cloud HSM | ⚠ phần cứng chuyên dụng của Google, FIPS 140-2 Level 3 | | ⚠ Cloud EKM | ⚠ NGOÀI Google Cloud hoàn toàn — đề này |

Từ khoá nhận diện:

"khoá phải ở ngoài đám mây công cộng" → ⚠ Cloud EKM "khoá trong phần cứng đạt FIPS" → ⚠ Cloud HSM "khách tự quản khoá trong Google Cloud" → ⚠ CMEK "Google không được truy cập dữ liệu khi đang xử lý" → ⚠ Confidential Computing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy định có thật sự đòi khoá ngoài không | ⚠ hay CMEK là đủ | | Hệ thống EKM có SLA sẵn sàng bao nhiêu | ⚠ nó thành điểm hỏng đơn của bạn | | Có kế hoạch cho tình huống EKM không phản hồi không | |

Và điều cần nói rõ với bất kỳ ai đề xuất EKM: bạn đang đánh đổi độ sẵn sàng lấy quyền kiểm soát. Khi hệ thống khoá bên ngoài ngừng trả lời, dữ liệu của bạn vẫn nằm nguyên đó — chỉ là không ai đọc được nữa.

Đáp án

A và C — Cài driver GPU, và dùng Deep Learning VM image.

Vì sao đúng

⚠ Gắn GPU vào VM chưa đủ — phần mềm phải biết cách dùng nó:

⚠ GPU đã gắn vào VM
        ↓ ⚠ nhưng THIẾU
⚠ Driver NVIDIA
⚠ Bộ công cụ CUDA
⚠ Thư viện cuDNN
        ↓
⚠ TensorFlow không thấy GPU
   → ⚠ âm thầm chạy bằng CPU

Vì sao các phương án khác sai

• B (dùng PyTorch thay TensorFlow) — ⚠ không liên quan: ⚠ PyTorch cũng cần driver GPU; ⚠ đổi framework không giải quyết gì.

• D (cấp vai trò Owner cho service account của VM) — ⚠ IAM không liên quan tới phần cứng: ⚠ và ⚠ cấp Owner là vi phạm quyền tối thiểu nghiêm trọng.

• E (cập nhật Python 3 trên VM) — ⚠ phiên bản Python không quyết định việc thấy GPU.

Ghi nhớ

⚠ Chồng phần mềm cần cho GPU — bảng phải thuộc: | Lớp | Vai trò | |---|---| | ⚠ Driver NVIDIA | ⚠ hệ điều hành nhận ra GPU | | ⚠ CUDA Toolkit | ⚠ nền tảng tính toán song song | | ⚠ cuDNN | ⚠ thư viện tối ưu cho mạng nơ-ron | | ⚠ Framework (TF/PyTorch) bản GPU | ⚠ phải là bản hỗ trợ GPU | | ⚠ Thiếu bất kỳ lớp nào | ⚠ chạy bằng CPU mà KHÔNG báo lỗi |

Từ khoá nhận diện:

"GPU đã gắn nhưng không được dùng" → ⚠ thiếu driver / dùng Deep Learning VM image "không muốn tự cài đặt gì" → ⚠ Deep Learning VM image hoặc Vertex AI Workbench "huấn luyện quy mô lớn, được quản" → ⚠ Vertex AI custom training

Ba việc kiểm chứng: | Việc | Cách | |---|---| | nvidia-smi có thấy GPU không | | | Framework có liệt kê thiết bị GPU không | | | VM có bị để chạy khi không huấn luyện không | ⚠ khoản lãng phí lớn |

Và điều nguy hiểm nhất ở lỗi này: nó không phải là lỗi. Mã vẫn chạy, kết quả vẫn ra, chỉ là chậm hơn hai mươi lần — và bạn trả tiền GPU suốt thời gian đó.