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

Đáp án

A — Vận hành bằng năng lượng không carbon 24/7 tại mọi trung tâm dữ liệu và văn phòng vào năm 2030.

Vì sao đúng

Đây là cam kết bền vững được nêu rõ nhất của Google, và nó khác hẳn — khó hơn nhiều — so với mục tiêu "100% năng lượng tái tạo" mà Google đã đạt từ 2017.

⚠ Ba cột mốc, phân biệt cho rõ:

2007 — TRUNG HOÀ CARBON
    → mua tín chỉ bù đắp phát thải

2017 — ⚠ KHỚP 100% ĐIỆN TIÊU THỤ
       VỚI NĂNG LƯỢNG TÁI TẠO
    → mua đủ lượng điện tái tạo
      TRONG CẢ NĂM
    → ⚠ nhưng theo TỔNG NĂM,
      không theo từng giờ

2030 (mục tiêu) — ⚠ NĂNG LƯỢNG
       KHÔNG CARBON 24/7
    → ⚠ MỌI GIỜ, MỌI NGÀY,
      TẠI MỌI TRUNG TÂM DỮ LIỆU

⚠ Vì sao "24/7" khó hơn nhiều:

KHỚP THEO NĂM
    Ban ngày: điện mặt trời dư
    Ban đêm:  ⚠ lấy từ lưới (có than)
        ↓
    Tổng cả năm vẫn "100% tái tạo"
    nhờ phần dư ban ngày bù lại

⚠ KHÔNG CARBON 24/7
    → ⚠ TỪNG GIỜ đều phải sạch
    → cần lưu trữ năng lượng,
      điện gió, thuỷ điện, hạt nhân,
      địa nhiệt
    → ⚠ cần lưới điện địa phương
      cũng phải sạch
        ↓
    → mục tiêu tham vọng hơn
      rất nhiều

⚠ Vì sao ba phương án kia không phải mục tiêu bền vững:

"Mạng nhanh nhất giữa các
 trung tâm dữ liệu"
    → mục tiêu KỸ THUẬT

"Đảm bảo 100% uptime"
    → ⚠ không nhà cung cấp nào
      hứa 100%

"Giá thấp nhất có thể"
    → mục tiêu THƯƠNG MẠI

Nhất quán với #13262 (lô 138), #13271 và #13277 (lô 139) — các câu đó về trụ cột Sustainability, công cụ Carbon Footprint và huy hiệu vùng phát thải thấp. Câu này nêu mục tiêu tổng thể. Cả bốn nhất quán.

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

• C (đảm bảo 100% uptime) — phương án gần nhất về mặt "nghe như cam kết lớn", nhưng không nhà cung cấp nào cam kết 100%; SLA cao nhất cũng chỉ tới 99,999%. Và đây là mục tiêu độ tin cậy, không phải bền vững.

• B (mạng nhanh nhất) — mục tiêu kỹ thuật.

• D (giá thấp nhất) — mục tiêu thương mại.

Ghi nhớ

⚠ Các cột mốc bền vững của Google — bảng nên thuộc: | Năm | Cột mốc | |---|---| | 2007 | trung hoà carbon | | 2017 | ⚠ khớp 100% điện tiêu thụ với năng lượng tái tạo | | 2030 (mục tiêu) | ⚠ năng lượng KHÔNG CARBON 24/7 | | Ngoài ra | trung tâm dữ liệu hiệu quả năng lượng hàng đầu ngành (PUE thấp) |

Từ khoá nhận diện:

"24/7 không carbon, 2030" → mục tiêu bền vững của Google "đo phát thải của mình" → Carbon Footprint "chọn vùng sạch" → huy hiệu lá cây / Region Picker "trụ cột chuyển đổi" → Sustainability

Ba việc kiểm chứng cho một tổ chức: | Việc | Cách | |---|---| | Đang phát thải bao nhiêu | báo cáo Carbon Footprint | | Vùng đang dùng sạch tới đâu | CFE% trong Region Picker | | Có bao nhiêu tài nguyên lãng phí | Recommender — Idle resources |

Và một cách hiểu giúp nhớ đúng mục tiêu 2030: khác biệt nằm ở chữ "mỗi giờ". Mua đủ điện tái tạo cho cả năm là một bài toán tài chính; đảm bảo rằng vào 3 giờ sáng một ngày lặng gió, điện chạy máy chủ vẫn không phát thải carbon lại là một bài toán kỹ thuật hoàn toàn khác.

Đáp án

A — Customer-Supplied Encryption Keys (CSEK).

Vì sao đúng

Điều kiện quyết định trong đề là: khoá KHÔNG BAO GIỜ được lưu hay quản lý bởi nhà cung cấp đám mây. Trong ba mức mã hoá của Google Cloud, chỉ CSEK thoả điều kiện đó theo nghĩa chặt nhất.

⚠ Ba mức mã hoá — phân biệt cho rõ:

GOOGLE-MANAGED (mặc định)
    → ⚠ Google sinh, lưu và
      xoay khoá
    → không phải làm gì

CMEK — Customer-Managed
    → ⚠ khoá nằm TRONG Cloud KMS
    → bạn quản vòng đời: xoay,
      tắt, huỷ
    → ⚠ nhưng khoá VẪN Ở TRONG
      hạ tầng Google

⚠ CSEK — Customer-Supplied
    → ⚠ bạn TỰ SINH khoá bên ngoài
    → ⚠ GỬI KÈM trong MỖI request
    → ⚠ Google dùng xong thì
      XOÁ KHỎI BỘ NHỚ, KHÔNG LƯU
        ↓
    → đúng yêu cầu của đề

⚠ CSEK hoạt động thế nào:

Ghi đối tượng
    → gửi kèm header chứa khoá AES-256
        ↓
    Google mã hoá rồi ⚠ QUÊN khoá
        ↓
Đọc đối tượng
    → ⚠ phải gửi LẠI đúng khoá đó
        ↓
    Không có khoá
        ↓
    ⚠ DỮ LIỆU MẤT VĨNH VIỄN —
      Google KHÔNG khôi phục được

Ghi nhớ về chất lượng câu hỏi

Đề nhắc tới HSM tại chỗ của chính doanh nghiệp, và trong thực tế ngày nay tình huống đó thường được giải bằng Cloud External Key Manager (Cloud EKM) — phương án B — chứ không phải CSEK.

Phân biệt hai cơ chế:

• CSEK — bạn gửi khoá thô kèm mỗi request. Google dùng xong xoá khỏi bộ nhớ, không lưu. Ứng dụng phải tự quản việc truyền khoá. Chỉ hỗ trợ một số dịch vụ (Cloud Storage, Compute Engine).
• Cloud EKM — khoá nằm lại trong hệ thống quản khoá bên ngoài (Thales, Fortanix, Equinix…). Google gọi ra ngoài mỗi lần cần dùng. Khoá không bao giờ rời khỏi hệ thống của bạn, và bạn thu hồi quyền truy cập bất cứ lúc nào.

Vì sao khoá vẫn là CSEK: đề nhấn mạnh doanh nghiệp "tự sinh và tự quản khoá" và "nhà cung cấp không bao giờ lưu hay quản khoá" — mô tả kinh điển của CSEK trong tài liệu đào tạo. Khoá đáp án giữ nguyên là A.

Khi làm bài: thấy "gửi khoá kèm mỗi request, Google không lưu" → CSEK. Thấy "khoá ở lại hệ thống quản khoá bên ngoài, Google gọi ra" → Cloud EKM.

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

• B (Cloud EKM) — phương án gần nhất, và như đã nói ở trên, trong thực tế nó thường là lựa chọn hợp lý hơn cho HSM tại chỗ. Nhưng cơ chế của nó là Google gọi ra hệ thống ngoài, không phải "bạn tự cung cấp khoá cho từng thao tác".

• C (khoá do Google quản lý) — ngược hoàn toàn yêu cầu của đề.

• D (mã hoá khi truyền) — bảo vệ dữ liệu trên đường đi, không liên quan tới quản lý khoá lưu trữ.

Ghi nhớ

⚠ Bốn mức quản lý khoá — bảng phải thuộc: | Mức | Khoá ở đâu | Ai quản | |---|---|---| | Google-managed | trong Google | Google | | CMEK | ⚠ Cloud KMS (trong Google) | bạn quản vòng đời | | CSEK | ⚠ bên ngoài, gửi kèm mỗi request | hoàn toàn của bạn | | Cloud EKM | ⚠ hệ thống quản khoá NGOÀI | hoàn toàn của bạn |

Từ khoá nhận diện:

"gửi khoá kèm mỗi request, Google không lưu" → CSEK "khoá ở HSM/hệ thống ngoài, Google gọi ra" → Cloud EKM "khoá trong Cloud KMS, tôi quản vòng đời" → CMEK "không phải làm gì" → Google-managed

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền dùng khoá | ⚠ Cloud Audit Logs của KMS | | Mất khoá thì sao | có quy trình sao lưu và phục hồi khoá chưa | | Dịch vụ đang dùng có hỗ trợ cơ chế đó không | kiểm danh sách hỗ trợ |

Và một câu hỏi bắt buộc phải trả lời trước khi chọn CSEK hay EKM: ai chịu trách nhiệm nếu khoá mất? Với các cơ chế này, quyền kiểm soát tuyệt đối đi kèm rủi ro tuyệt đối — Google không có bản sao nào để cứu bạn, và đó chính là điều làm chúng đáp ứng được yêu cầu tuân thủ.

Đáp án

B — Archive Storage.

Vì sao đúng

Đề cho bốn manh mối, và tất cả đều chỉ vào lớp Archive cho chín năm còn lại:

⚠ Bốn manh mối:

1. GIỮ 10 NĂM (năm đầu nóng,
   9 năm sau nguội)
     → ⚠ vượt xa mức tối thiểu
       365 ngày của Archive

2. "HIẾM KHI truy cập — chỉ khi
   kiểm toán, yêu cầu pháp lý,
   hoặc bệnh nhân quay lại sau
   nhiều năm"
     → ⚠ đúng hồ sơ của Archive

3. "TỐI THIỂU HOÁ CHI PHÍ LƯU TRỮ"
     → ⚠ Archive rẻ nhất

4. "VẪN TRUY CẬP ĐƯỢC NGAY khi cần"
     → ⚠ Archive vẫn trả về
       trong MILI-GIÂY

⚠ Hiểu lầm phổ biến nhất phải xoá bỏ:

"Archive giống băng từ,
 phải chờ hàng giờ mới lấy được"
        ↓
    ⚠ SAI HOÀN TOÀN
        ↓
    ⚠ Cả bốn lớp của Cloud Storage
      đều có độ trễ MILI-GIÂY
        ↓
    Khác biệt nằm ở GIÁ:
      lưu càng rẻ → truy xuất càng đắt
        ↓
    → đó là lý do phương án B
      thoả cả "rẻ nhất" lẫn
      "truy cập được ngay"

⚠ Giải pháp đầy đủ — vòng đời tự động:

{"rule": [
  {"action": {"type": "SetStorageClass",
              "storageClass": "ARCHIVE"},
   "condition": {"age": 365}},
  {"action": {"type": "Delete"},
   "condition": {"age": 3650}}
]}

    Năm 1:  Standard (bác sĩ đọc thường xuyên)
    Năm 2–10: ⚠ Archive (rẻ nhất)
    Sau 10 năm: xoá tự động
        ↓
    ⚠ Nên thêm Bucket Lock để
      không ai xoá sớm được

Nhất quán với #13249 (lô 138) — đề đó cũng là bệnh viện lưu sao lưu 7 năm, hiếm khi đọc, và cùng khoá Archive. Hoàn toàn nhất quán.

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

• C (Nearline) — phương án gần nhất trong các lớp nguội, nhưng Nearline dành cho dữ liệu đọc khoảng một lần mỗi tháng. Với chín năm gần như không đọc, nó đắt hơn Archive đáng kể về lưu trữ.

• A (Standard) — cho dữ liệu truy cập thường xuyên, giá lưu trữ cao nhất. Đúng cho năm đầu tiên, sai cho chín năm sau.

• D (Multi-Regional) — đây là vị trí, không phải lớp lưu trữ, và đa vùng đắt hơn một vùng.

Ghi nhớ

⚠ Bốn lớp lưu trữ — bảng phải thuộc: | Lớp | Tối thiểu | Tần suất đọc | |---|---|---| | Standard | không | thường xuyên | | Nearline | 30 ngày | ~1 lần/tháng | | Coldline | 90 ngày | ~1 lần/quý | | Archive | ⚠ 365 ngày | ⚠ ~1 lần/năm hoặc ít hơn | | ⚠ Chung | cùng độ bền, cùng API, cùng độ trễ mili-giây |

Từ khoá nhận diện:

"lưu trữ tuân thủ nhiều năm, gần như không đọc" → Archive "sao lưu hằng tháng còn dùng" → Nearline "tự chuyển lớp theo tuổi" → Object Lifecycle Management "không đoán được kiểu truy cập" → Autoclass "không ai được xoá trong N năm" → ⚠ Bucket Lock

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy tắc vòng đời đã áp chưa | gcloud storage buckets describe | | Có bị tính phí truy xuất bất ngờ không | billing report, lọc SKU retrieval | | Chính sách giữ đã khoá chưa | ⚠ kiểm retentionPolicy và isLocked |

Và một cảnh báo cần đọc kỹ trước khi bấm Bucket Lock cho hồ sơ y tế: nó không thể gỡ được, kể cả bởi bạn hay bởi Google. Đó chính là điều làm nó có giá trị trước cơ quan quản lý — và cũng là lý do phải chắc chắn tuyệt đối về con số mười năm trước khi khoá lại.

Đáp án

B — Vision AI API với tính năng SafeSearch detection.

Vì sao đúng

Đề nêu ba điều kiện, và Vision API là công cụ có sẵn đúng tính năng cần:

⚠ Ba điều kiện ↔ Vision API SafeSearch:

1. "TỰ ĐỘNG KIỂM DUYỆT ẢNH
    người dùng tải lên"
     → xử lý ảnh, quy mô lớn

2. "PHÁT HIỆN và ĐÁNH DẤU
    NỘI DUNG KHÔNG PHÙ HỢP"
     → ⚠ đây chính là SafeSearch

3. ⚠ "CẦN RẤT ÍT CHUYÊN MÔN
    HỌC MÁY"
     → API dựng sẵn, gọi là xong

⚠ SafeSearch trả về gì:

Gửi ảnh → nhận về 5 hạng mục,
mỗi hạng mục có 5 mức khả năng:

  adult     — nội dung người lớn
  violence  — bạo lực
  racy      — hở hang, khiêu gợi
  medical   — nội dung y khoa
  spoof     — ảnh chế, meme
        ↓
Mức: VERY_UNLIKELY → UNLIKELY
     → POSSIBLE → LIKELY
     → VERY_LIKELY
        ↓
    ⚠ Bạn tự đặt NGƯỠNG hành động

⚠ Quy trình kiểm duyệt thực tế:

Ảnh tải lên → Cloud Storage
        ↓
Cloud Run Function
        ↓
Vision API — SafeSearch
        ↓
  ┌─────────┼─────────┐
VERY_LIKELY  POSSIBLE  UNLIKELY
   ↓           ↓          ↓
⚠ CHẶN     ⚠ ĐƯA CHO   CHO QUA
tự động     NGƯỜI DUYỆT
        ↓
    ⚠ Ba mức xử lý, không phải
      chỉ đúng/sai

Nhất quán với #13325 (cùng lô này) — đề đó cũng khoá Vision API cho nhu cầu nhận diện ảnh không cần chuyên môn ML. Câu này dùng đúng một tính năng cụ thể của cùng API. Hoàn toàn nhất quán.

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

• A (huấn luyện mô hình tuỳ biến trên Vertex AI) — phương án gần nhất về mặt "cũng làm được", nhưng đề nói rõ cần RẤT ÍT chuyên môn ML. Tự huấn luyện bộ phân loại nội dung nhạy cảm cần dữ liệu gán nhãn — mà việc gán nhãn loại dữ liệu này lại rất khó khăn về mặt con người.

• C (Speech-to-Text API) — xử lý âm thanh, không phải ảnh.

• D (Cloud Translation API) — dịch ngôn ngữ, không liên quan.

Ghi nhớ

⚠ Các tính năng của Cloud Vision API — bảng nên thuộc: | Tính năng | Việc | |---|---| | ⚠ SafeSearch | ⚠ phát hiện nội dung nhạy cảm — đề này | | Label detection | nhãn mô tả nội dung | | Object localization | vị trí vật thể | | OCR / Text detection | đọc chữ, cả chữ viết tay | | Face detection | ⚠ phát hiện khuôn mặt — KHÔNG nhận dạng danh tính | | Landmark / Logo detection | địa danh, thương hiệu | | Web detection | tìm ảnh tương tự trên web |

Từ khoá nhận diện:

"kiểm duyệt nội dung ảnh" → Vision API SafeSearch "kiểm duyệt VIDEO" → ⚠ Video Intelligence API — cũng có SafeSearch "kiểm duyệt VĂN BẢN" → Natural Language API hoặc Gemini "danh mục riêng của nghiệp vụ" → AutoML Vision

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ chặn nhầm là bao nhiêu | ⚠ theo dõi khiếu nại của người dùng | | Có lọt nội dung xấu không | rà soát mẫu ngẫu nhiên | | Ngưỡng có phù hợp không | điều chỉnh dần theo dữ liệu thật |

Và một phần của hệ thống kiểm duyệt mà đề thi không hỏi nhưng thực tế luôn cần: quy trình khiếu nại. Mọi bộ lọc tự động đều chặn nhầm ở một tỉ lệ nào đó, và nếu người dùng bị chặn không có cách nào để phản hồi, bạn đã biến một lỗi kỹ thuật nhỏ thành một vấn đề về niềm tin.

Đáp án

D — Trong mô hình tại chỗ, doanh nghiệp chịu trách nhiệm mua sắm phần cứng, bảo trì và an ninh vật lý.

Vì sao đúng

Đây là khác biệt căn bản nhất giữa hai mô hình: ai sở hữu và vận hành phần cứng.

⚠ Ai lo gì:

TẠI CHỖ (on-premises)
    ⚠ Mua sắm phần cứng
    ⚠ Lắp đặt và cấu hình
    ⚠ Bảo trì và thay thế
    ⚠ An ninh vật lý phòng máy
    ⚠ Điện, làm mát, dự phòng UPS
    ⚠ Mạng và thiết bị mạng
        + toàn bộ tầng phần mềm

GOOGLE CLOUD
    ⚠ Google lo TOÀN BỘ
      phần cứng và cơ sở vật chất
        ↓
    Bạn lo từ tầng dịch vụ trở lên
    (tuỳ IaaS, PaaS hay SaaS)

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

"Tại chỗ trả phí HÀNG THÁNG,
 đám mây phải MUA phần cứng"
    → ⚠ ĐẢO NGƯỢC hoàn toàn
    → tại chỗ là CapEx (mua),
      đám mây là OpEx (thuê)

"Đám mây cho ÍT kiểm soát hơn
 với tầng phần mềm"
    → ⚠ SAI: với IaaS bạn có
      quyền root, kiểm soát
      tầng phần mềm y như tại chỗ
    → (đúng nếu nói về tầng
      PHẦN CỨNG, không phải phần mềm)

"Tại chỗ VỐN DĨ mở rộng tốt hơn
 đám mây"
    → ⚠ NGƯỢC LẠI hoàn toàn
    → tại chỗ mở rộng mất hàng tuần

⚠ An ninh vật lý — khoản hay bị quên nhất:

Trung tâm dữ liệu riêng cần:
    kiểm soát ra vào, camera,
    sinh trắc học, bảo vệ,
    chống cháy, chống nước
        ↓
Trung tâm dữ liệu của Google:
    ⚠ nhiều lớp kiểm soát,
      sinh trắc học, phát hiện xâm nhập
    ⚠ và bạn KHÔNG phải trả riêng
      cho từng thứ đó

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

• B (đám mây cho ít kiểm soát hơn với tầng PHẦN MỀM) — phương án gần nhất và chứa một nửa sự thật: đám mây thật sự cho ít kiểm soát hơn ở tầng PHẦN CỨNG. Nhưng với IaaS, bạn có quyền root và toàn quyền với tầng phần mềm, y hệt tại chỗ.

• A (tại chỗ trả phí tháng, đám mây mua phần cứng) — đảo ngược hoàn toàn mô hình chi phí.

• C (tại chỗ vốn dĩ mở rộng tốt hơn) — ngược lại; mở rộng là ưu điểm lớn nhất của đám mây.

Ghi nhớ

⚠ Tại chỗ và đám mây — bảng phải thuộc: | | Tại chỗ | Đám mây | |---|---|---| | Phần cứng | ⚠ bạn mua và bảo trì | Google lo | | An ninh vật lý | ⚠ bạn lo | Google lo | | Chi phí | ⚠ CapEx — trả trước | ⚠ OpEx — theo mức dùng | | Mở rộng | ⚠ hàng tuần tới hàng tháng | ⚠ vài phút | | Kiểm soát phần cứng | tối đa | không có | | Kiểm soát phần mềm | tối đa | ⚠ tối đa với IaaS |

Từ khoá nhận diện:

"mua phần cứng, bảo trì, an ninh vật lý" → trách nhiệm của tại chỗ "trả theo mức dùng" → đám mây, OpEx "mở rộng trong vài phút" → đám mây "cần kiểm soát phần cứng vật lý" → ⚠ tại chỗ hoặc sole-tenant node

Ba câu hỏi kiểm chứng khi so sánh: | Câu hỏi | Vì sao | |---|---| | TCO hiện tại gồm những gì | ⚠ nhớ tính điện, mặt bằng, nhân sự | | Tỉ lệ sử dụng máy chủ là bao nhiêu | thường rất thấp | | Mở rộng hiện mất bao lâu | ⚠ so với vài phút trên đám mây |

Và một khoản chi phí của mô hình tại chỗ mà bảng tính hiếm khi thể hiện: thời gian của đội kỹ thuật. Những giờ dành cho thay ổ cứng hỏng, cập nhật firmware và trực phòng máy là những giờ không dành cho việc xây sản phẩm — và với phần lớn doanh nghiệp, đó mới là chi phí đắt nhất.

Đáp án

A — Autoscaling (tự động mở rộng).

Vì sao đúng

Đề mô tả đúng cơ chế autoscaling dựa trên chỉ số: thêm instance khi vượt ngưỡng trên, bớt instance khi xuống dưới ngưỡng dưới.

⚠ Cơ chế trong đề:

CPU trung bình của nhóm
        ↓
    Vượt 80%
        ↓
    ⚠ THÊM instance (scale out)
        ↓
    Xuống dưới 30%
        ↓
    ⚠ BỚT instance (scale in)
        ↓
    → năng lực bám theo tải thật

⚠ Hai chiều của autoscaling:

SCALE OUT (mở rộng ra)
    → thêm máy
    → ⚠ chống quá tải

SCALE IN (thu hẹp vào)
    → bớt máy
    → ⚠ TIẾT KIỆM CHI PHÍ
        ↓
    ⚠ Nhiều người chỉ nhớ vế đầu,
      nhưng vế sau mới là chỗ
      tiết kiệm tiền

⚠ Phân biệt với ba khái niệm kia:

LOAD BALANCING
    → ⚠ CHIA lưu lượng giữa các máy
    → KHÔNG thêm bớt máy
    → đi cùng autoscaling nhưng
      là việc khác

REPLATFORMING
    → chiến lược DI CƯ:
      đổi sang dịch vụ có quản lý

OBJECT LIFECYCLE MANAGEMENT
    → ⚠ quy tắc chuyển lớp và xoá
      đối tượng trong Cloud Storage
    → hoàn toàn khác lĩnh vực

Bổ sung cho #13339 (cùng lô này) — câu đó ghép autoscaling và load balancing thành một cặp. Câu này chỉ hỏi riêng autoscaling. Hai câu nhất quán.

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

• D (load balancing) — phương án gần nhất và luôn đi cùng autoscaling trong thực tế, nhưng nó phân phối lưu lượng giữa các instance đã có, không thêm hay bớt instance nào.

• B (replatforming) — chiến lược di cư lên đám mây, không liên quan tới mở rộng theo tải.

• C (Object Lifecycle Management) — quy tắc quản lý vòng đời đối tượng trong Cloud Storage, khác hẳn lĩnh vực.

Ghi nhớ

⚠ Bốn khái niệm hay bị lẫn — bảng phải thuộc: | Khái niệm | Việc | |---|---| | Autoscaling | ⚠ THÊM/BỚT tài nguyên theo tải | | Load balancing | ⚠ CHIA lưu lượng giữa các tài nguyên | | High availability | chịu được hỏng một thành phần | | Object Lifecycle Management | ⚠ chuyển lớp và xoá đối tượng Cloud Storage |

Từ khoá nhận diện:

"thêm/bớt máy theo CPU" → autoscaling "chia lưu lượng" → load balancing "chuyển ảnh cũ sang Coldline" → Object Lifecycle Management "đổi CSDL tự quản sang Cloud SQL" → replatforming

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có mở rộng kịp không | ⚠ thử tải mô phỏng đỉnh | | Có thu hẹp lại không | xem số instance ban đêm | | Quota có đủ không | kiểm và xin nâng trước |

Và một nửa của autoscaling thường bị bỏ quên trong lúc cấu hình: chiều thu hẹp. Rất nhiều hệ thống mở rộng rất tốt trong ngày cao điểm rồi giữ nguyên số máy đó suốt nhiều tuần sau, đơn giản vì không ai kiểm tra xem chúng có thật sự giảm xuống hay không.

Đáp án

C — Một tập hợp cụ thể các ứng dụng, chương trình hoặc dữ liệu cần tài nguyên tính toán để chạy.

Vì sao đúng

Đề đang định nghĩa thuật ngữ "workload" (tải công việc) — đơn vị mà mọi kế hoạch di cư đều lấy làm cơ sở.

⚠ Workload là gì:

Không phải một máy chủ
Không phải một dòng mã
        ↓
    ⚠ Là MỘT HỆ THỐNG HOÀN CHỈNH
      phục vụ một mục đích nghiệp vụ
        ↓
    Ví dụ trong đề:
      - hệ thống CRM
      - nền tảng thương mại điện tử
      - ứng dụng quản lý tồn kho
        ↓
    ⚠ Mỗi cái là MỘT workload,
      cần kế hoạch di cư riêng

⚠ Vì sao di cư phải tính theo workload:

Không thể "chuyển cả trung tâm
dữ liệu" trong một lần
        ↓
    ⚠ Chia thành từng workload
        ↓
    Mỗi workload có:
      - độ phức tạp riêng
      - phụ thuộc riêng
      - mức rủi ro riêng
      - giá trị nghiệp vụ riêng
        ↓
    → xếp thứ tự ưu tiên và
      chuyển từng cái một

⚠ Xếp thứ tự ưu tiên thế nào:

Trục 1: ⚠ GIÁ TRỊ NGHIỆP VỤ
        (chuyển đi thì được gì)
Trục 2: ⚠ ĐỘ PHỨC TẠP / RỦI RO
        ↓
    Giá trị cao + phức tạp thấp
        → ⚠ LÀM TRƯỚC
    Giá trị thấp + phức tạp cao
        → ⚠ LÀM SAU hoặc bỏ
        ↓
    Thực tế: bắt đầu bằng workload
    ⚠ ÍT RỦI RO để đội học nghề

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

• A (một máy ảo) — phương án gần nhất về mặt "cũng là đơn vị kỹ thuật", nhưng quá hẹp: một workload có thể gồm nhiều máy ảo, một cơ sở dữ liệu, một bộ cân bằng tải và nhiều thành phần khác.

• B (lượng điện một máy chủ tiêu thụ) — không liên quan tới thuật ngữ đang hỏi.

• D (lương của quản trị viên CNTT) — cũng không liên quan.

Ghi nhớ

⚠ Các thuật ngữ di cư — bảng nên thuộc: | Thuật ngữ | Nghĩa | |---|---| | Workload | ⚠ tập ứng dụng/dữ liệu cần tài nguyên để chạy | | Assessment | kiểm kê và đánh giá workload hiện có | | Dependency mapping | ⚠ workload nào phụ thuộc workload nào | | Wave / batch | nhóm workload chuyển cùng đợt | | Landing zone | môi trường đích đã dựng sẵn | | Cutover | thời điểm chuyển sang dùng thật |

Từ khoá nhận diện:

"hệ thống cần di cư, đơn vị lập kế hoạch" → workload "kiểm kê xem có những gì" → assessment "cái nào phụ thuộc cái nào" → dependency mapping "chiến lược chuyển từng workload" → 6 R: rehost, replatform…

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã kiểm kê hết workload chưa | ⚠ Migration Center + hỏi từng phòng ban | | Có workload nào không ai nhận là của mình không | ⚠ ứng viên để retire | | Phụ thuộc đã vẽ ra chưa | công cụ khảo sát mạng |

Và một phát hiện gần như luôn xảy ra ở bước kiểm kê: có những hệ thống vẫn đang chạy mà không ai nhớ vì sao. Chúng là ứng viên hàng đầu cho bước "retire", và loại bỏ chúng thường tiết kiệm nhiều công sức hơn mọi tối ưu kỹ thuật cộng lại.

Đáp án

A — Natural Language AI.

Vì sao đúng

Đề nêu ba điều kiện, và cả ba đều dẫn tới API ngôn ngữ dựng sẵn:

⚠ Ba điều kiện ↔ Natural Language API:

1. "PHÂN TÍCH CẢM XÚC nhận xét
    khách hàng (tích cực, tiêu cực,
    trung tính)"
     → ⚠ đúng tính năng
       sentiment analysis

2. "KHÔNG có chuyên gia học máy"
     → API dựng sẵn, dùng ngay

3. "chỉ cần MỘT LỜI GỌI API đơn giản"
     → không huấn luyện, không
       triển khai mô hình

⚠ API trả về hai con số:

Nhận xét: "Giao hàng nhanh nhưng
           đóng gói cẩu thả."
        ↓
  score:     ⚠ từ −1,0 tới +1,0
             → chiều của cảm xúc
  magnitude: ⚠ từ 0 tới vô hạn
             → ĐỘ MẠNH của cảm xúc
        ↓
    ⚠ Phải đọc CẢ HAI:
      score ≈ 0 + magnitude CAO
      → ⚠ cảm xúc LẪN LỘN,
        không phải trung tính

⚠ Entity sentiment — tính năng đắt giá hơn:

Thay vì chỉ biết "nhận xét này tiêu cực"
        ↓
    ⚠ Biết TIÊU CỰC VỀ CÁI GÌ:
      "giao hàng"  → +0,8
      "đóng gói"   → −0,7
        ↓
    → biết chính xác phải sửa gì

Nhất quán với #13318 (cùng lô này) — đề đó cũng khoá Natural Language API cho việc trích xuất thực thể. Câu này dùng một tính năng khác của cùng API. Hoàn toàn nhất quán.

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

• B (BigQuery ML) — phương án gần nhất nếu dữ liệu đã ở BigQuery, nhưng nó dùng để huấn luyện mô hình trên dữ liệu bảng biểu bằng SQL; phân tích cảm xúc văn bản không phải thế mạnh của nó. (Có thể gọi Gemini từ BigQuery qua ML.GENERATE_TEXT, nhưng đó không phải "một lời gọi API đơn giản" như đề mô tả.)

• C (AutoML Tables) — cho dữ liệu bảng biểu, không phải văn bản tự do.

• D (Vision AI) — xử lý ảnh, không phải văn bản.

Ghi nhớ

⚠ Các API AI dựng sẵn — bảng phải thuộc: | API | Việc | |---|---| | Natural Language | ⚠ cảm xúc, thực thể, cú pháp, phân loại nội dung | | Vision | ảnh: nhãn, OCR, SafeSearch | | Speech-to-Text / Text-to-Speech | giọng nói | | Translation | dịch | | Video Intelligence | video | | Document AI | ⚠ trích xuất trường từ hoá đơn, hợp đồng |

Từ khoá nhận diện:

"khách hài lòng hay không, cảm xúc" → Natural Language API "tìm người, tổ chức, địa điểm" → cùng API, tính năng entity "nhãn riêng của ngành" → AutoML hoặc Gemini "dữ liệu bảng biểu" → BigQuery ML / AutoML Tables

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Điểm có khớp cảm nhận người đọc không | ⚠ lấy 50 nhận xét đối chiếu | | Có nhận xét mỉa mai bị hiểu sai không | rà soát các ca lệch nhiều nhất | | Chi phí bao nhiêu | số ký tự × đơn giá |

Và một giá trị lớn hơn điểm số trung bình mà nhiều đội bỏ lỡ: phân tích cảm xúc theo từng thực thể. Biết rằng điểm hài lòng đang là 0,3 thì ít hữu ích; biết rằng khách khen sản phẩm nhưng chê khâu giao hàng thì lại chỉ thẳng ra việc cần làm tuần tới.

Đáp án

C — Zones (vùng khả dụng).

Vì sao đúng

Đề mô tả các vị trí tách biệt bên trong cùng một khu vực địa lý — đó chính là định nghĩa của zone trong thuật ngữ Google Cloud.

⚠ Phân cấp địa lý của Google Cloud:

    MULTI-REGION (ví dụ EU)
        │
    REGION (ví dụ europe-west1, Bỉ)
        ├── ZONE europe-west1-b
        ├── ZONE europe-west1-c
        └── ZONE europe-west1-d
        ↓
    ⚠ Mỗi ZONE có nguồn điện,
      làm mát và mạng RIÊNG
    ⚠ Nhưng cùng nằm trong một
      khu vực địa lý

⚠ Đọc đề thấy đúng đặc điểm của zone:

"nhiều vị trí TÁCH BIỆT"
        ↓
    ⚠ hạ tầng độc lập

"trong CÙNG MỘT khu vực địa lý
 (ví dụ Tây Âu)"
        ↓
    ⚠ cùng một REGION

"bảo vệ khỏi hỏng hóc của MỘT
 TRUNG TÂM DỮ LIỆU"
        ↓
    ⚠ đúng mức bảo vệ mà đa zone
      đem lại
        ↓
    → ZONE

⚠ Ba khái niệm kia là gì:

REGION
    → ⚠ khu vực địa lý CHỨA nhiều zone
    → "Tây Âu" trong đề là REGION

PROJECT
    → ⚠ ranh giới TỔ CHỨC và TÍNH TIỀN
    → không phải vị trí địa lý

SUBNET
    → ⚠ dải địa chỉ IP trong VPC
    → gắn với một vùng, nhưng là
      khái niệm MẠNG

⚠ Đối chiếu #13282 (lô 139) và #13247 (lô 138) — hai câu đó hỏi chọn chiến lược nào (đa zone hay đa vùng); câu này hỏi tên của đơn vị. Cả ba nhất quán: đa zone chống mất một trung tâm dữ liệu, đa vùng chống mất cả một khu vực.

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

• B (regions) — phương án gần nhất và là bẫy chính: region chính là "khu vực địa lý" mà đề nhắc tới, còn thứ đề hỏi là các vị trí tách biệt BÊN TRONG nó — tức là zone.

• A (projects) — ranh giới tổ chức, tính tiền và hạn ngạch, không phải vị trí địa lý.

• D (subnets) — dải địa chỉ IP trong VPC; là khái niệm mạng.

Ghi nhớ

⚠ Phân cấp địa lý — bảng phải thuộc: | Cấp | Nghĩa | |---|---| | Zone | ⚠ một hoặc vài trung tâm dữ liệu, hạ tầng độc lập | | Region | ⚠ nhóm zone trong cùng khu vực địa lý (thường 3+) | | Multi-region | nhiều region trong một lục địa | | ⚠ Lưu ý | project và subnet KHÔNG phải cấp địa lý |

Từ khoá nhận diện:

"vị trí tách biệt trong cùng khu vực" → zone "khu vực địa lý chứa nhiều zone" → region "chịu được mất một trung tâm dữ liệu" → đa zone "chịu được mất cả một khu vực" → đa vùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thành phần nào chỉ ở một zone không | ⚠ rà từng tài nguyên | | MIG là regional hay zonal | gcloud compute instance-groups list | | Có chịu được mất zone thật không | ⚠ diễn tập tắt một zone |

Và một điều đáng nhớ về cách Google đặt tên zone: europe-west1-b không nhất thiết là cùng một trung tâm dữ liệu vật lý với europe-west1-b của một dự án khác. Google ánh xạ tên zone khác nhau cho từng project để cân bằng tải — nên đừng giả định hai project cùng tên zone thì cùng chung số phận.

Đáp án

B — Control vs. Ease of Use (Kiểm soát đổi lấy sự dễ dùng).

Vì sao đúng

Đây là trục đánh đổi cơ bản giữa IaaS và PaaS, và Compute Engine với App Engine nằm ở hai đầu của trục đó.

⚠ Hai đầu của trục:

COMPUTE ENGINE (IaaS)
    ✔ ⚠ TOÀN QUYỀN kiểm soát:
      chọn OS, quyền root, kernel,
      phần mềm bất kỳ
        ↓
    ⚠ Đổi lại:
      tự cài, tự vá, tự cấu hình
      mở rộng, tự lo cân bằng tải

APP ENGINE (PaaS)
    ✔ ⚠ RẤT DỄ DÙNG:
      `gcloud app deploy` là xong,
      tự mở rộng, tự HTTPS
        ↓
    ⚠ Đổi lại:
      chỉ runtime được hỗ trợ,
      không chọn OS, không SSH

⚠ Trục này áp cho mọi lựa chọn tính toán:

KIỂM SOÁT NHIỀU ←──────────→ DỄ DÙNG
Compute Engine
      GKE
          Cloud Run
              App Engine
                  Cloud Run Functions
                       SaaS
        ↓
    ⚠ Đi sang phải: ít việc phải làm,
      ít quyền kiểm soát, khoá chân nhiều hơn

⚠ Vì sao ba phương án kia không phải trục chính:

"BẢO MẬT vs MỞ RỘNG"
    → ⚠ cả hai đều bảo mật tốt
    → cả hai đều mở rộng được

"CHI PHÍ vs HIỆU NĂNG"
    → ⚠ tuỳ tải, không có quy luật
      chung; App Engine Standard
      có khi RẺ HƠN nhiều

"LƯU TRỮ vs MẠNG"
    → ⚠ không phải trục phân biệt
      giữa hai sản phẩm này

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

• C (chi phí vs hiệu năng) — phương án gần nhất về mặt "nghe như đánh đổi thật", nhưng không có quy luật chung: App Engine Standard co về 0 nên với tải thất thường lại rẻ hơn, còn Compute Engine với cam kết dài hạn lại rẻ hơn cho tải ổn định.

• A (bảo mật vs mở rộng) — cả hai đều bảo mật và đều mở rộng được; đây không phải đánh đổi.

• D (lưu trữ vs mạng) — không phải trục phân biệt giữa hai nền tảng tính toán.

Ghi nhớ

⚠ Trục kiểm soát – dễ dùng — bảng phải thuộc: | Sản phẩm | Kiểm soát | Việc phải làm | |---|---|---| | Compute Engine | ⚠ tối đa | ⚠ nhiều nhất: OS, vá, mở rộng | | GKE | cao | quản cụm | | Cloud Run | vừa | chỉ lo container | | App Engine | thấp | ⚠ chỉ lo mã | | SaaS | không có | không gì cả |

Từ khoá nhận diện:

"cần kiểm soát OS, phần mềm cũ" → Compute Engine "chỉ muốn viết mã" → App Engine / Cloud Run "nhiều container phụ thuộc nhau" → GKE "đánh đổi giữa IaaS và PaaS" → ⚠ kiểm soát vs dễ dùng

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có yêu cầu gì đặc biệt ở tầng OS không | có → Compute Engine | | Ai trong đội muốn vá hệ điều hành | không ai → App Engine | | Tải có ổn định không | ổn định cao → cân nhắc VM + CUD |

Và một cách chọn thực dụng khi phân vân giữa hai bên: bắt đầu từ mức dễ dùng nhất giải quyết được bài toán, và chỉ đi xuống khi gặp rào cản thật. Chuyển từ App Engine sang Compute Engine khi cần là việc làm được; còn thời gian đội bạn tiêu vào việc vá máy chủ ngay từ đầu thì không lấy lại được.