Ngân hàng đề — Google Cloud Digital Leader

Đáp án

A — Một công ty khởi nghiệp có thể ra mắt ứng dụng mới với chi phí ban đầu tối thiểu, chỉ trả cho tài nguyên mà những người dùng đầu tiên tiêu thụ.

Vì sao đúng

Pay-as-you-go nghĩa là chi phí đi theo mức sử dụng thật: không đầu tư trước, không cam kết cứng, dùng bao nhiêu trả bấy nhiêu.

⚠ Vì sao điều này thay đổi cuộc chơi cho khởi nghiệp:

THỜI TRƯỚC
    → ⚠ phải MUA máy chủ trước
    → ⚠ phải gọi vốn TRƯỚC KHI
      biết sản phẩm có ai dùng không
    → ⚠ rào cản gia nhập rất cao

⚠ PAY-AS-YOU-GO
    → ⚠ ra mắt gần như KHÔNG tốn gì
    → 100 người dùng → trả cho
      100 người dùng
    → ⚠ thành công thì mở rộng,
      thất bại thì DỪNG, mất rất ít
        ↓
    ⚠ Chi phí THẤT BẠI giảm mạnh
      → thử được nhiều ý tưởng hơn

⚠ Vì sao ba phương án kia sai:

"Ký hợp đồng 5 NĂM cho một lượng
 năng lực CỐ ĐỊNH"
    → ⚠ đó là CAM KẾT, ngược với
      trả theo mức dùng

"Trả phí CỐ ĐỊNH hằng tháng cho
 máy chủ dù có dùng hay không"
    → ⚠ đúng mô hình mà đám mây
      thay thế

"Phải MUA đủ máy cho mùa cao điểm
 rồi để không cả năm"
    → ⚠ mô tả kinh điển của hạ tầng
      TẠI CHỖ

Nhất quán với #13512 (lô 143) về OpEx, và #13496 (lô 143) về elasticity. Ba khái niệm liên quan chặt: trả theo mức dùng là hệ quả tài chính của tính co giãn.

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

• D (mua đủ máy cho mùa cao điểm) — phương án gần nhất về mặt "cũng nói tới nhu cầu thay đổi theo mùa", nhưng nó mô tả đúng vấn đề của mô hình cũ, không phải lợi ích của trả theo mức dùng.

• B (hợp đồng 5 năm) và C (phí cố định hằng tháng) — đều là mô hình cam kết cố định.

Ghi nhớ

⚠ Ba mô hình chi phí — bảng phải thuộc: | Mô hình | Đặc điểm | |---|---| | ⚠ Pay-as-you-go | ⚠ trả theo mức dùng, không cam kết | | ⚠ Committed Use Discount | ⚠ cam kết 1–3 năm, giảm giá đáng kể | | ⚠ Spot / Preemptible | ⚠ rẻ nhất, có thể bị thu hồi | | Tại chỗ | ⚠ mua trước theo mức ĐỈNH |

Từ khoá nhận diện:

"chỉ trả cho thứ đã dùng" → ⚠ pay-as-you-go "tải ổn định, muốn rẻ hơn" → ⚠ CUD "chịu được gián đoạn" → Spot VM "chi phí định kỳ" → OpEx

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí xấu nhất có thể là bao nhiêu | ⚠ đặt quota và max instances rồi tính | | Có phần tải nào ổn định để cam kết không | ⚠ xem 3–6 tháng qua | | Ai nhận cảnh báo ngân sách | ⚠ phải là người hành động được |

Và mặt còn lại của sự linh hoạt này, đáng nhớ ngay từ ngày đầu: không có gì tự chặn chi tiêu. Trả theo mức dùng nghĩa là một cấu hình sai cũng được phục vụ tận tình như một lượng truy cập thật — nên hàng rào phải do bạn tự dựng bằng quota và cảnh báo.

Đáp án

A — Cloud SQL và Cloud Spanner.

Vì sao đúng

Chỉ hai dịch vụ này vừa quan hệ (bảng, khoá, SQL chuẩn, giao dịch ACID) vừa có quản lý hoàn toàn.

⚠ Hai lựa chọn quan hệ:

⚠ CLOUD SQL
    → MySQL, PostgreSQL, SQL Server
    → ⚠ mở rộng theo CHIỀU DỌC
      (máy to hơn) + read replica
    → ⚠ mặc định cho hầu hết
      ứng dụng

⚠ CLOUD SPANNER
    → ⚠ quan hệ + mở rộng NGANG
      không giới hạn
    → ⚠ nhất quán mạnh TOÀN CẦU
    → ⚠ đắt hơn nhiều — chỉ dùng
      khi thật sự cần quy mô đó

⚠ Vì sao ba phương án kia sai:

"Cloud Storage và Firestore"
    → ⚠ Storage: lưu ĐỐI TƯỢNG
    → ⚠ Firestore: NoSQL tài liệu

"BigQuery và Bigtable"
    → ⚠ BigQuery: kho PHÂN TÍCH
      (dùng SQL nhưng KHÔNG phải
       CSDL giao dịch)
    → ⚠ Bigtable: NoSQL cột rộng

"Cloud Functions và Cloud Run"
    → ⚠ dịch vụ TÍNH TOÁN

Nhất quán với #13495 (lô 143) về ranh giới OLTP/OLAP, và #13392 (lô 141) về Cloud SQL với BigQuery.

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

• C (BigQuery và Bigtable) — phương án gần nhất và là bẫy được thiết kế kỹ: BigQuery dùng SQL nên rất dễ tưởng là CSDL quan hệ. Nhưng nó là kho phân tích, không phục vụ tải giao dịch.

• B (Cloud Storage và Firestore) và D (Cloud Functions và Cloud Run) — không phải CSDL quan hệ.

Ghi nhớ

⚠ Bản đồ CSDL Google Cloud — bảng phải thuộc: | Dịch vụ | Loại | Dùng khi | |---|---|---| | ⚠ Cloud SQL | ⚠ quan hệ | ⚠ mặc định cho ứng dụng | | ⚠ Cloud Spanner | ⚠ quan hệ, ngang | ⚠ quy mô toàn cầu, nhất quán mạnh | | Firestore | ⚠ NoSQL tài liệu | ⚠ ứng dụng di động, web, đồng bộ thời gian thực | | Bigtable | ⚠ NoSQL cột rộng | ⚠ chuỗi thời gian, IoT, ghi rất lớn | | BigQuery | ⚠ kho PHÂN TÍCH | ⚠ báo cáo, không phải giao dịch | | Memorystore | ⚠ bộ nhớ đệm | Redis, Memcached | | AlloyDB | ⚠ PostgreSQL hiệu năng cao | tải nặng |

Từ khoá nhận diện:

"quan hệ, SQL chuẩn, giao dịch" → ⚠ Cloud SQL "toàn cầu, nhất quán mạnh, mở rộng ngang" → ⚠ Spanner "tài liệu, đồng bộ theo thời gian thực" → Firestore "hàng petabyte, độ trễ mili-giây, ghi lớn" → ⚠ Bigtable "phân tích, báo cáo" → BigQuery

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có cần giao dịch nhiều bảng không | có → quan hệ | | Một máy ghi có đủ không | có → ⚠ Cloud SQL | | Đây là tải giao dịch hay phân tích | ⚠ phân tích → BigQuery, tách khỏi hệ chính |

Và dấu hiệu cho thấy một hệ thống đang dùng sai loại cơ sở dữ liệu vẫn là dấu hiệu quen thuộc nhất: báo cáo cuối tháng làm chậm trang thanh toán. Cách chữa không phải nâng cấp máy, mà là tách tải phân tích sang BigQuery và để cơ sở dữ liệu giao dịch làm đúng việc của nó.

Đáp án

D — Platform as a Service (PaaS).

Vì sao đúng

Đội muốn chỉ viết mã, không quản hệ điều hành, cấu hình máy chủ hay chính sách co giãn. Đó chính là định nghĩa của PaaS.

⚠ Ba mô hình dịch vụ — bảng cốt lõi:

⚠ IaaS
    → nhà cung cấp lo phần cứng,
      ảo hoá, mạng
    → ⚠ BẠN lo OS, runtime,
      ứng dụng, co giãn
    → Compute Engine

⚠ PaaS
    → ⚠ nhà cung cấp lo TỚI runtime
      và co giãn
    → ⚠ BẠN chỉ lo MÃ và DỮ LIỆU
    → ⚠ App Engine, Cloud Run,
      Cloud Functions
    → ⚠ ĐỀ NÀY

⚠ SaaS
    → ⚠ dùng phần mềm hoàn chỉnh
    → Gmail, Google Workspace

⚠ Cách nhớ nhanh:

IaaS → ⚠ thuê MÁY
PaaS → ⚠ thuê NỀN TẢNG chạy mã
SaaS → ⚠ thuê PHẦN MỀM dùng luôn

⚠ Vì sao ba phương án kia sai:

"IaaS"
    → ⚠ vẫn phải quản OS và
      chính sách co giãn

"On-premises"
    → ⚠ quản MỌI THỨ

"Colocation"
    → ⚠ thuê CHỖ ĐẶT máy;
      máy vẫn là của bạn

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

• B (IaaS) — phương án gần nhất vì cũng là mô hình đám mây, nhưng đề nói rõ không muốn quản hệ điều hành và chính sách co giãn, mà đó đúng là phần việc của khách hàng trong IaaS.

• A (on-premises) và C (colocation) — mức tự quản còn cao hơn nữa.

Ghi nhớ

⚠ Ai lo gì — bảng phải thuộc: | | On-prem | IaaS | ⚠ PaaS | SaaS | |---|---|---|---|---| | Phần cứng | bạn | nhà cc | nhà cc | nhà cc | | OS | bạn | ⚠ BẠN | ⚠ nhà cc | nhà cc | | Runtime, co giãn | bạn | ⚠ BẠN | ⚠ nhà cc | nhà cc | | ⚠ Ứng dụng | bạn | bạn | ⚠ BẠN | nhà cc | | ⚠ Dữ liệu | bạn | bạn | ⚠ BẠN | ⚠ BẠN |

Từ khoá nhận diện:

"chỉ viết mã, không quản máy chủ" → ⚠ PaaS "cần toàn quyền trên OS" → IaaS "dùng phần mềm có sẵn" → SaaS "thuê chỗ đặt máy của mình" → ⚠ colocation

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có thật sự cần chạm vào OS không | không → ⚠ PaaS | | Ứng dụng có chạy trong container không | có → ⚠ Cloud Run | | Ai lo sao lưu dữ liệu | ⚠ luôn là bạn |

Và câu hỏi nên đặt trước khi một đội quyết định dựng máy ảo cho ứng dụng web mới: có việc gì bắt buộc phải làm ở tầng hệ điều hành không? Nếu câu trả lời là không — và với phần lớn ứng dụng web thì đúng là không — thì mọi giờ công dành cho việc vá lỗi và cấu hình máy chủ là chi phí có thể tránh được.

Đáp án

C — Vertex AI.

Vì sao đúng

Đề đòi một môi trường THỐNG NHẤT cho toàn bộ vòng đời: từ chuẩn bị dữ liệu, tạo đặc trưng, huấn luyện tới triển khai. Đó chính là định vị của Vertex AI — nền tảng MLOps đầu-cuối.

⚠ Vertex AI phủ toàn vòng đời:

⚠ CHUẨN BỊ DỮ LIỆU
    → Workbench, kết nối BigQuery

⚠ TẠO ĐẶC TRƯNG
    → Feature Store dùng chung
      giữa các đội

⚠ HUẤN LUYỆN
    → AutoML hoặc tuỳ biến,
      GPU/TPU có quản lý

⚠ ĐÁNH GIÁ và GIẢI THÍCH
    → Model Evaluation,
      Explainable AI

⚠ TRIỂN KHAI
    → endpoint trực tuyến,
      dự đoán theo lô

⚠ THEO DÕI và TỰ ĐỘNG HOÁ
    → Model Monitoring, Pipelines

⚠ Vì sao ba phương án kia sai:

"Dataflow"
    → ⚠ xử lý dữ liệu theo luồng
      và theo lô — MỘT BƯỚC thôi

"Dataproc"
    → ⚠ Spark/Hadoop có quản lý —
      cũng chỉ một phần

"Cloud Composer"
    → ⚠ điều phối luồng công việc
      (Airflow) — không phải nền tảng ML

⚠ Cả ba đều hữu ích trong đường ống dữ liệu, nhưng không cái nào phủ toàn vòng đời ML.

⚠ Gần trùng với #13535 (cùng lô) — đề đó hỏi riêng khâu phục vụ mô hình qua endpoint, đề này hỏi toàn vòng đời. Cùng khoá Vertex AI, bổ sung nhau, không mâu thuẫn.

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

• A (Dataflow) — phương án gần nhất vì nó thật sự nằm trong đường ống ML ở khâu xử lý dữ liệu, nhưng nó không huấn luyện hay phục vụ mô hình.

• B (Dataproc) và D (Cloud Composer) — cũng chỉ đảm nhiệm một mắt xích.

Ghi nhớ

⚠ Thành phần Vertex AI — bảng nên thuộc: | Thành phần | Việc | |---|---| | Workbench | ⚠ notebook có quản lý | | ⚠ Feature Store | ⚠ đặc trưng dùng chung, tránh lệch train/serve | | Training | ⚠ huấn luyện có quản lý, GPU/TPU | | AutoML | không cần viết mã | | ⚠ Model Registry | ⚠ quản phiên bản mô hình | | ⚠ Prediction | ⚠ endpoint và batch | | ⚠ Pipelines | ⚠ tự động hoá toàn quy trình | | Model Monitoring | ⚠ phát hiện drift, skew | | Explainable AI | feature attribution |

Từ khoá nhận diện:

"môi trường thống nhất, đầu-cuối, MLOps" → ⚠ Vertex AI "xử lý dữ liệu luồng và lô" → Dataflow "Spark, Hadoop" → Dataproc "điều phối luồng công việc, Airflow" → ⚠ Cloud Composer "dựng mô hình bằng SQL" → BigQuery ML

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Có tái lập được mô hình đang chạy không | ⚠ không → thiếu registry và pipeline | | Đặc trưng tính ở đâu | ⚠ hai nơi khác nhau là nguy cơ skew | | Ai biết khi mô hình xuống cấp | ⚠ bật Model Monitoring |

Và khoảng cách lớn nhất trong hầu hết dự án học máy không nằm giữa ý tưởng và mô hình, mà giữa mô hình chạy được trên notebook và mô hình chạy ổn định trong sản xuất. Đó chính là khoảng cách mà toàn bộ phần MLOps của Vertex AI sinh ra để lấp.

Đáp án

C — Một Zone (vùng khả dụng).

Vì sao đúng

Zone là vị trí triển khai cách ly vật lý NẰM TRONG một region. Triển khai VM sang hai zone trong us-east1 là cách chống sự cố ở một trung tâm dữ liệu.

⚠ Phân cấp hạ tầng vật lý:

⚠ MULTI-REGION
    → nhiều vùng địa lý

⚠ REGION (us-east1)
    → ⚠ một khu vực địa lý
    → ⚠ chứa NHIỀU zone

⚠ ZONE (us-east1-b)
    → ⚠ vị trí CÁCH LY trong vùng
    → ⚠ nguồn điện, làm mát,
      mạng riêng
    → ⚠ ĐỀ NÀY

⚠ Phân cấp TỔ CHỨC — khác hẳn:

⚠ ORGANIZATION
        ↓
⚠ FOLDER (thư mục)
        ↓
⚠ PROJECT (dự án)
        ↓
    tài nguyên

⚠ Vì sao ba phương án kia sai:

"Region"
    → ⚠ là cái CHỨA các zone;
      đề nói "trong us-east1"

"Folder" và "Project"
    → ⚠ thuộc phân cấp TỔ CHỨC,
      ⚠ không phải vị trí VẬT LÝ

Nhất quán với #13542 (cùng lô) về redundancy đa zone, và #13468 (lô 143). Đối chiếu #13493 (lô 143) — mất cả region thì cần đa vùng. Không mâu thuẫn — khác phạm vi sự cố.

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

• D (Region) — phương án gần nhất và là bẫy chính: đề đã nói rõ hai vị trí này nằm bên trong us-east1, nên chúng là zone.

• A (Folder) và B (Project) — thuộc cây tổ chức tài nguyên, không phải hạ tầng vật lý.

Ghi nhớ

⚠ Hai phân cấp — đừng lẫn, bảng phải thuộc: | Phân cấp VẬT LÝ | Phân cấp TỔ CHỨC | |---|---| | Multi-region | Organization | | ⚠ Region | ⚠ Folder | | ⚠ Zone | ⚠ Project | | Quyết định | ⚠ độ trễ, khả năng chịu lỗi, tuân thủ | | Quyết định | ⚠ quyền, ngân sách, chính sách |

Từ khoá nhận diện:

"vị trí cách ly trong một vùng" → ⚠ zone "khu vực địa lý chứa nhiều zone" → region "nhóm dự án để áp chính sách" → ⚠ folder "đơn vị tính tiền và phân quyền" → ⚠ project

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên nào đang chỉ ở một zone | ⚠ đĩa và VM đơn lẻ hay bị bỏ sót | | Bản sao lưu nằm ở đâu | ⚠ cùng zone thì mất zone là mất luôn | | Đã thử mất một zone chưa | ⚠ diễn tập, đừng chỉ giả định |

Và chi tiết hay bị bỏ quên nhất khi một hệ thống được thiết kế đa zone: bản sao lưu vẫn nằm trong đúng zone đang được bảo vệ. Kiến trúc thì chịu được sự cố, nhưng đường lùi cuối cùng thì không — và đó là thứ chỉ lộ ra đúng vào ngày cần dùng tới nó.

Đáp án

D — AutoML Vision.

Vì sao đúng

Ba dữ kiện dẫn thẳng tới AutoML: nhãn RIÊNG của công ty, đã có tập dữ liệu lớn ĐÃ GÁN NHÃN, đội ít kinh nghiệm ML.

⚠ Ba dữ kiện khớp:

"phân loại thành áo / quần / giày"
    → ⚠ nhãn RIÊNG theo danh mục
      sản phẩm của công ty
    → ⚠ Vision API dựng sẵn không
      biết danh mục của bạn

"tập ảnh LỚN, ĐÃ GÁN NHÃN"
    → ⚠ đúng thứ AutoML cần

"đội ÍT kinh nghiệm ML"
    → ⚠ loại bỏ huấn luyện tuỳ biến

⚠ Vì sao ba phương án kia sai:

"Vision AI API"
    → ⚠ nhận nhãn PHỔ QUÁT
      ("quần áo", "giày dép")
    → ⚠ nhưng KHÔNG học được
      danh mục riêng của bạn

"BigQuery ML"
    → ⚠ mạnh với dữ liệu BẢNG,
      không phải bài toán ảnh này

"Natural Language API"
    → ⚠ xử lý VĂN BẢN

Nhất quán với #13497 (lô 143) về AutoML là điểm cân bằng, và #13273 (lô 139) về AutoML Vision. Đối chiếu #13541/#13504 — API dựng sẵn cho tác vụ phổ quát. Không mâu thuẫn — phân biệt bằng nhãn phổ quát hay nhãn riêng.

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

• A (Vision AI API) — phương án gần nhất và là bẫy chính: nó cũng phân loại ảnh, nhưng chỉ theo nhãn phổ quát mà Google đã huấn luyện, không theo danh mục sản phẩm riêng.

• B (BigQuery ML) và C (Natural Language) — sai loại dữ liệu.

Ghi nhớ

⚠ Vision API hay AutoML Vision — câu hỏi quyết định: | Câu hỏi | Trả lời | |---|---| | Nhãn có PHỔ QUÁT không | ⚠ có → Vision API | | ⚠ Nhãn có RIÊNG của bạn không | ⚠ có → AutoML Vision | | Có dữ liệu đã gán nhãn không | ⚠ không → chỉ dùng được API dựng sẵn | | Cần kiểm soát kiến trúc mô hình | ⚠ có → Vertex AI custom |

Từ khoá nhận diện:

"phân loại theo danh mục riêng, có dữ liệu nhãn" → ⚠ AutoML "nhận diện vật thể, chữ, địa danh nói chung" → Vision API "đội có kỹ sư ML, cần toàn quyền" → custom training "dữ liệu bảng, biết SQL" → BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vision API có đủ chưa | ⚠ thử trên trang demo trước — có khi đủ dùng | | Nhãn có nhất quán không | ⚠ cho hai người gán cùng một tập, so kết quả | | Mô hình sai ở đâu | ⚠ xem ma trận nhầm lẫn, không chỉ nhìn độ chính xác |

Và việc đáng làm đầu tiên trước mọi dự án AutoML: thử vài chục ảnh thật qua API dựng sẵn. Nếu nhãn phổ quát đã đủ dùng, bạn tiết kiệm được toàn bộ công gán nhãn — còn nếu không đủ, chính kết quả đó cũng cho biết mô hình riêng cần phân biệt những gì.

Đáp án

A — Saturation (mức bão hoà).

Vì sao đúng

Saturation đo mức độ "đầy" của dịch vụ — tài nguyên khan hiếm nhất đang được dùng bao nhiêu phần. CPU tiến tới 100% là ví dụ điển hình.

⚠ Phân biệt Traffic và Saturation:

⚠ TRAFFIC
    → ⚠ NHU CẦU đến từ bên ngoài
    → request/giây
    → ⚠ bạn KHÔNG kiểm soát được

⚠ SATURATION
    → ⚠ HỆ THỐNG đang chịu tới đâu
    → % CPU, % bộ nhớ, % kết nối
    → ⚠ bạn KIỂM SOÁT được bằng
      cách thêm năng lực

⚠ Đề nêu cả hai: request rất cao (traffic) khiến CPU gần 100% (saturation). Câu hỏi hỏi cái mô tả trạng thái "đầy" → saturation.

⚠ Vì sao saturation là tín hiệu quý nhất:

Saturation tăng
        ↓
    ⚠ BÁO TRƯỚC vài phút
        ↓
    Latency bắt đầu tăng
        ↓
    Errors xuất hiện (timeout)
        ↓
    → ⚠ can thiệp ở saturation
      là kịp; tới errors đã muộn

Bộ ba với #13522 (tên gọi bốn tín hiệu) và #13527 (traffic) trong cùng lô này. Ba đề hỏi ba khía cạnh của cùng một khung, hoàn toàn nhất quán.

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

• D (Traffic) — phương án gần nhất và là bẫy chính: đề có nhắc tới số request rất cao. Nhưng traffic đo nhu cầu, còn câu hỏi hỏi cái mô tả mức đầy của hệ thống.

• B (Latency) và C (Errors) — là hệ quả xuất hiện sau khi bão hoà.

Ghi nhớ

⚠ Bốn tín hiệu vàng — bảng phải thuộc: | Tín hiệu | Đo gì | Thuộc về | |---|---|---| | Traffic | ⚠ nhu cầu | ⚠ bên ngoài | | ⚠ Saturation | ⚠ mức đầy | ⚠ hệ thống — đề này | | Latency | thời gian phục vụ | trải nghiệm | | Errors | tỉ lệ thất bại | trải nghiệm |

Từ khoá nhận diện:

"CPU gần 100%, hệ thống đầy" → ⚠ saturation "bao nhiêu request đang tới" → traffic "phục vụ mất bao lâu" → latency "bao nhiêu request hỏng" → errors

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên nào cạn trước | ⚠ thử tải tới điểm gãy để biết | | Autoscaler có kịp không | ⚠ đo thời gian từ tăng tải tới có máy mới | | Quota còn bao nhiêu | ⚠ kiểm trước mùa cao điểm |

Và sai lầm phổ biến khi theo dõi mức bão hoà: chỉ nhìn CPU. Rất nhiều hệ thống gãy vì cạn kết nối cơ sở dữ liệu hoặc chạm trần quota trong khi CPU vẫn nhàn nhã — và biểu đồ CPU đẹp đẽ lúc đó chỉ khiến việc chẩn đoán chậm thêm.

Đáp án

D — Cloud Run.

Vì sao đúng

Đề nhấn hai điều: nền tảng quản lý HOÀN TOÀN hạ tầng — cả control plane Kubernetes LẪN worker node, và muốn trải nghiệm ĐƠN GIẢN NHẤT có thể.

⚠ Thang trừu tượng cho container:

Compute Engine
    → ⚠ tự cài Kubernetes, tự quản
      MỌI THỨ

GKE Standard
    → ⚠ Google quản control plane
    → ⚠ BẠN vẫn quản NODE

GKE Autopilot
    → ⚠ Google quản cả node
    → ⚠ vẫn là cụm K8s để hiểu

⚠ CLOUD RUN
    → ⚠ KHÔNG có cụm nào cả
    → ⚠ chỉ cần image container
    → ⚠ ĐƠN GIẢN NHẤT — đề này

⚠ Vì sao ba phương án kia sai:

"GKE Standard"
    → ⚠ ĐỀ BÀI NÓI RÕ không muốn
      quản worker node

"Compute Engine"
    → ⚠ phải tự cài và tự vận hành
      mọi thứ

"Bare Metal Solution"
    → ⚠ máy chủ vật lý, xa nhất
      với "đơn giản nhất"

⚠ Đối chiếu #13528 và #13543 (cùng lô) — hai đề đó khoá GKE vì đề bài đòi GIỮ quyền tuỳ biến node. Đề này khoá Cloud Run vì đề bài đòi KHÔNG quản node. Không mâu thuẫn — đọc kỹ yêu cầu là phân biệt được ngay. Cùng nhóm với #13519 (cùng lô) và #13511/#13515 (lô 143).

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

• C (GKE Standard) — phương án gần nhất và là bẫy chính: nó quản control plane rất tốt, nhưng node vẫn thuộc về bạn — đúng thứ đề nói là không muốn.

• B (Compute Engine) và A (Bare Metal Solution) — mức tự quản còn cao hơn nữa.

Ghi nhớ

⚠ Chọn giữa Cloud Run và GKE — bảng phải thuộc: | Yêu cầu trong đề | Đáp án | |---|---| | ⚠ "không quản node", "đơn giản nhất" | ⚠ Cloud Run | | ⚠ "tuỳ biến node", "cấu hình cụm" | ⚠ GKE Standard | | "K8s nhưng không quản node" | ⚠ GKE Autopilot | | "trả tiền theo request" | ⚠ Cloud Run | | "cần GPU, network policy" | GKE |

Từ khoá nhận diện:

"đơn giản nhất, quản lý hoàn toàn" → ⚠ Cloud Run "tự cấu hình node pool" → GKE Standard "co về 0 khi không có request" → ⚠ Cloud Run "cụm luôn sẵn sàng" → GKE

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Đội có muốn cấu hình node không | không → ⚠ Cloud Run | | Có tiến trình nền sau khi trả lời không | có → ⚠ cấu hình CPU always allocated hoặc dùng GKE | | Chi phí xấu nhất | ⚠ đặt max instances rồi tính |

Và cách đọc nhanh nhất những đề bài rất giống nhau kiểu này: tìm câu nói về node. "Muốn tuỳ biến worker node" dẫn tới GKE; "không muốn quản node" hay "đơn giản nhất" dẫn tới Cloud Run — phần còn lại của đề thường chỉ là bối cảnh.

Đáp án

A — Vertex AI.

Vì sao đúng

Đề đòi một nền tảng thống nhất qua MỘT giao diện cho xây dựng, huấn luyện, triển khai và quản lý mô hình, kèm ba tính năng cụ thể: gán nhãn dữ liệu, huấn luyện, phục vụ dự đoán. Cả ba đều nằm trong Vertex AI.

⚠ Ba tính năng đề nêu nằm ở đâu:

"gán nhãn dữ liệu"
    → ⚠ Vertex AI Data Labeling
      và bộ dataset có quản lý

"huấn luyện mô hình"
    → ⚠ AutoML hoặc custom training,
      dùng GPU/TPU có quản lý

"phục vụ dự đoán"
    → ⚠ Endpoint trực tuyến và
      dự đoán theo lô
        ↓
    ⚠ Tất cả trong MỘT nền tảng

⚠ Vì sao ba phương án kia sai:

"Cloud Data Fusion"
    → ⚠ tích hợp dữ liệu ETL
      kéo-thả — một mắt xích

"Dataproc"
    → ⚠ Spark/Hadoop có quản lý

"Looker"
    → ⚠ công cụ BI, dashboard

⚠ Gần trùng với #13547 (cùng lô) — cùng hỏi nền tảng MLOps đầu-cuối, cùng khoá Vertex AI. Và #13535 (cùng lô) hỏi riêng khâu phục vụ mô hình. Ba đề bổ sung nhau, không mâu thuẫn.

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

• D (Dataproc) — phương án gần nhất vì Spark có thư viện học máy (MLlib) và thường xuất hiện trong đường ống dữ liệu, nhưng nó không cung cấp gán nhãn, registry hay endpoint phục vụ.

• B (Cloud Data Fusion) và C (Looker) — thuộc mảng dữ liệu và BI.

Ghi nhớ

⚠ Phân vai trong nền tảng dữ liệu — bảng nên thuộc: | Sản phẩm | Việc chính | |---|---| | ⚠ Vertex AI | ⚠ nền tảng ML/MLOps đầu-cuối | | Dataflow | ⚠ xử lý luồng và lô (Apache Beam) | | Dataproc | ⚠ Spark, Hadoop có quản lý | | Cloud Data Fusion | ⚠ tích hợp dữ liệu bằng giao diện kéo-thả | | Cloud Composer | ⚠ điều phối luồng công việc (Airflow) | | Dataform | ⚠ biến đổi trong BigQuery bằng SQL | | Looker | ⚠ BI và dashboard | | Dataplex | quản trị và danh mục |

Từ khoá nhận diện:

"nền tảng ML thống nhất, một giao diện" → ⚠ Vertex AI "kéo-thả để nối nguồn dữ liệu" → ⚠ Data Fusion "Spark có sẵn" → Dataproc "lịch chạy và phụ thuộc giữa các bước" → Composer

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Ai đang chịu trách nhiệm gán nhãn | ⚠ thường là nút thắt thật | | Có tái lập được mô hình đang chạy không | ⚠ cần registry và pipeline | | Endpoint nào đang sống mà không dùng | ⚠ kiểm hằng tháng |

Và điều đáng lưu ý khi lập kế hoạch cho một dự án học máy: phần khó nhất hiếm khi là chọn thuật toán. Nó nằm ở việc có được dữ liệu gán nhãn nhất quán, và ở việc giữ cho mô hình còn đúng sau khi thế giới bên ngoài đã thay đổi.

Đáp án

C — Một tệp âm thanh MP3 ghi cuộc gọi chăm sóc khách hàng.

Vì sao đúng

Tệp âm thanh không có mô hình dữ liệu định trước: không hàng, không cột, không trường. Đó là định nghĩa của dữ liệu phi cấu trúc.

⚠ Xếp loại bốn phương án:

"Bảng giao dịch trong CSDL quan hệ"
    → ⚠ CÓ CẤU TRÚC: hàng, cột,
      kiểu dữ liệu xác định

"Tệp JSON hồ sơ người dùng"
    → ⚠ BÁN CẤU TRÚC: có khoá và
      giá trị nhưng schema không cứng

"Danh sách tên và địa chỉ trong
 bảng tính"
    → ⚠ CÓ CẤU TRÚC: cột rõ ràng

⚠ "Tệp MP3 cuộc gọi"
    → ⚠ PHI CẤU TRÚC: chỉ là
      dòng byte âm thanh
    → ⚠ ĐÁP ÁN

⚠ Cách xử lý dữ liệu phi cấu trúc:

🎧 MP3 cuộc gọi
        ↓
    ⚠ Speech-to-Text
        ↓
    văn bản (bán cấu trúc)
        ↓
    ⚠ Natural Language: cảm xúc,
      thực thể, chủ đề
        ↓
    ⚠ Bảng trong BigQuery
      (có cấu trúc)
        ↓
    ⚠ phân tích được bằng SQL

Nhất quán với #13525 (cùng lô) về định nghĩa ba loại dữ liệu, và #13514 (lô 143) về data lake.

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

• B (tệp JSON) — phương án gần nhất và là bẫy tinh tế: JSON không phải bảng, nên dễ bị xếp nhầm vào phi cấu trúc. Nhưng nó có thẻ đánh dấu và khoá, nên là bán cấu trúc.

• A (bảng giao dịch) và D (bảng tính) — đều có cấu trúc rõ ràng.

Ghi nhớ

⚠ Ba loại dữ liệu — bảng phải thuộc: | Loại | Ví dụ | Lưu ở | |---|---|---| | Có cấu trúc | ⚠ bảng CSDL, CSV, bảng tính | Cloud SQL, BigQuery | | ⚠ Bán cấu trúc | ⚠ JSON, XML, log, YAML | ⚠ Firestore, BigQuery | | ⚠ Phi cấu trúc | ⚠ MP3, ảnh, video, PDF, email | ⚠ Cloud Storage |

Từ khoá nhận diện:

"âm thanh, ảnh, video, tài liệu tự do" → ⚠ phi cấu trúc "JSON, XML, log" → ⚠ bán cấu trúc "hàng và cột" → có cấu trúc "chứa mọi loại ở mọi quy mô" → data lake

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Dữ liệu có schema cố định không | không → ⚠ phi hoặc bán cấu trúc | | Có cần truy vấn bằng SQL không | ⚠ trích thành bảng trước | | Được phép lưu bao lâu | ⚠ quy định về dữ liệu cá nhân |

Và giá trị lớn nhất ẩn trong dữ liệu phi cấu trúc thường là thứ mà các bảng số liệu không bao giờ ghi lại: lý do khách hàng gọi đến. Một cuộc gọi được chuyển thành văn bản và phân tích chủ đề có thể giải thích được con số rời bỏ mà mọi dashboard chỉ mới nêu ra.