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

Đáp án

D — Nó đơn giản hoá việc quản trị và tăng tính nhất quán; quyền được quản bằng cách đổi thành viên nhóm thay vì sửa hàng loạt chính sách của từng người.

Vì sao đúng

Đề mô tả đúng nỗi đau của mô hình cấp quyền theo cá nhân ở quy mô 200 nhân viên và hàng chục project.

⚠ Vấn đề với cấp quyền theo cá nhân:

Người MỚI vào
    → ⚠ phải nhớ cấp đủ quyền
      trên hàng chục project

Người ĐỔI bộ phận
    → ⚠ phải nhớ GỠ quyền cũ
      và cấp quyền mới
    → ⚠ quyền cũ hay bị SÓT LẠI

Người NGHỈ việc
    → ⚠ phải rà từng project
    → ⚠ sót một chỗ = lỗ hổng
        ↓
    → không mở rộng nổi

⚠ Mô hình theo nhóm:

Nhóm `engineering@congty.com`
    ← được cấp vai trên các project
      liên quan MỘT LẦN
        ↓
    Người mới → ⚠ THÊM vào nhóm
    Đổi bộ phận → ⚠ CHUYỂN nhóm
    Nghỉ việc → ⚠ XOÁ khỏi nhóm
        ↓
    ⚠ Một thao tác, mọi quyền
      cập nhật theo

⚠ Lợi ích thứ hai — tính nhất quán:

Cấp theo cá nhân
    → ⚠ mỗi lập trình viên có
      một bộ quyền hơi khác nhau
    → ⚠ không ai biết "chuẩn"
      là gì
        ↓
Cấp theo nhóm
    → ⚠ MỌI người trong nhóm có
      CÙNG một bộ quyền
    → rà soát dễ: xem nhóm nào
      có vai gì

⚠ Gần trùng với #13371 (cùng lô này) — đề đó cũng khoá phương án "cấp cho nhóm + vai dựng sẵn cụ thể". Câu này đào sâu vào vì sao nhóm tốt hơn cá nhân. Hoàn toàn nhất quán.

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

• A (nhóm kém an toàn hơn tài khoản cá nhân) — phương án gần nhất về mặt "nghe như có đánh đổi bảo mật", nhưng sai: nhóm giúp quản lý nhất quán hơn, do đó an toàn hơn.

• C (không thể cấp vai cho tài khoản cá nhân) — sai về kỹ thuật: Google Cloud cho phép cấp cho cá nhân, chỉ là không nên ở quy mô lớn.

• B (cấp cho cá nhân đắt hơn) — IAM không tính tiền theo cách cấp quyền.

Ghi nhớ

⚠ Thực hành tốt về IAM — bảng phải thuộc: | Thực hành | Nội dung | |---|---| | ⚠ Cấp cho NHÓM | ⚠ dễ quản khi người vào ra | | Vai dựng sẵn hẹp nhất | thay cho vai cơ bản | | Cấp ở cấp thấp nhất đủ dùng | | | IAM Recommender | ⚠ gợi ý thu hẹp theo mức dùng thật | | IAM Conditions | quyền có thời hạn | | Rà soát định kỳ | | | Bật audit log | |

Từ khoá nhận diện:

"nhiều người, nhiều project, người vào ra liên tục" → cấp cho nhóm "quyền tối thiểu" → vai dựng sẵn hẹp nhất "người ngoài, tạm thời" → ⚠ IAM Conditions có thời hạn "cấm hành vi ở mọi nơi" → Organization Policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người nghỉ việc mất quyền chưa | ⚠ kiểm sau khi xoá khỏi nhóm | | Quyền cấp cho cá nhân hay nhóm | rà chính sách IAM | | Có nhóm nào quyền quá rộng không | IAM Recommender |

Và một phép thử nhanh cho biết mô hình phân quyền đã đủ trưởng thành chưa: hỏi xem cần bao nhiêu thao tác để gỡ hết quyền của một người vừa nghỉ việc. Nếu câu trả lời là "xoá khỏi vài nhóm" thì tốt; nếu là "đi rà từng project" thì đó chính là bài toán mà công ty trong đề đang gặp.

Đáp án

D — Dùng Cloud Translation API đã huấn luyện sẵn.

Vì sao đúng

Đề nêu ba điều kiện, và cả ba đều đẩy về phía API dựng sẵn:

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

1. "dịch văn bản người dùng nhập
    và mục thực đơn, ⚠ TỨC THÌ"
     → ⚠ ngôn ngữ đời thường,
       bài toán PHỔ QUÁT

2. ⚠ "đội KHÔNG có chuyên môn ML
    và KHÔNG có nguồn lực để
    huấn luyện mô hình riêng"
     → loại mọi phương án tự làm

3. "GIẢI PHÁP HIỆU QUẢ NHẤT"
     → gọi API là xong

⚠ Toàn bộ việc phải làm:

from google.cloud import translate_v2 as translate

client = translate.Client()
kq = client.translate("Where is the museum?",
                      target_language="vi")
print(kq["translatedText"])
# → "Bảo tàng ở đâu?"

        ↓
    ⚠ Hơn 100 ngôn ngữ
    ⚠ TỰ NHẬN DIỆN ngôn ngữ nguồn
    ⚠ Không dữ liệu huấn luyện
    ⚠ Không endpoint tính tiền
      thường trực

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

HUẤN LUYỆN MÔ HÌNH DỊCH RIÊNG
TRÊN VERTEX AI
    → ⚠ cần dữ liệu song ngữ
      khổng lồ và chuyên gia ML
    → đề nói rõ họ KHÔNG có

XÂY ỨNG DỤNG DỊCH TỪ ĐẦU
TRÊN COMPUTE ENGINE
    → ⚠ vô lý về mặt nguồn lực

LƯU BẢN DỊCH TRONG BẢNG BIGQUERY
    → ⚠ chỉ dùng được cho câu
      ĐÃ BIẾT TRƯỚC
    → ⚠ người dùng nhập văn bản
      TỰ DO — không tra bảng được

⚠ Gần trùng với #13259 (lô 138) và #13324 (lô 140) — cả ba đề đều là nhu cầu dịch thuật cho đội không có chuyên môn ML, và cả ba cùng khoá API dựng sẵn. Hoàn toàn nhất quán. Mẫu đề lặp: dịch thuật + không chuyên gia ML → luôn là Cloud Translation API.

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

• C (lưu bản dịch trong bảng BigQuery) — phương án gần nhất về mặt "cũng cho ra bản dịch", và có thể dùng cho mục thực đơn cố định. Nhưng đề nói rõ phải dịch văn bản người dùng NHẬP VÀO — không thể biết trước để lưu sẵn.

• A (huấn luyện mô hình dịch riêng trên Vertex AI) — cần chuyên gia và dữ liệu song ngữ lớn mà đề nói họ không có.

• B (xây ứng dụng dịch từ đầu trên Compute Engine) — không khả thi về nguồn lực.

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Khi nào | |---|---| | ⚠ API dựng sẵn | ⚠ việc phổ quát, không chuyên gia, cần nhanh | | AutoML | dữ liệu riêng, thuật ngữ riêng, không viết mã | | Mô hình tuỳ biến | lợi thế cạnh tranh, có đội ML |

Từ khoá nhận diện:

"dịch thuật, không chuyên gia ML" → Cloud Translation API "thuật ngữ ngành mô hình chung dịch sai" → AutoML Translation "giữ nguyên tên thương hiệu khi dịch" → ⚠ glossary — không cần huấn luyện lại "dịch cả tài liệu PDF" → Translation Advanced

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chất lượng dịch có ổn không | ⚠ nhờ người bản ngữ đọc 50 mẫu | | Tên riêng có bị dịch sai không | → thêm glossary | | Chi phí bao nhiêu | số ký tự × đơn giá, trừ phần đã đệm |

Và một tối ưu nên làm ngay từ phiên bản đầu của ứng dụng: đệm bản dịch của những nội dung lặp lại. Một thực đơn nhà hàng được hàng nghìn khách du lịch xem nhưng chỉ cần dịch đúng một lần — bỏ qua bước này là cách nhanh nhất biến một tính năng rẻ tiền thành khoản chi đều đặn không cần thiết.

Đáp án

A — Regression (hồi quy).

Vì sao đúng

Đề đã nói thẳng manh mối quyết định: đầu ra là một GIÁ TRỊ SỐ LIÊN TỤC (giá nhà). Đó là định nghĩa của bài toán hồi quy.

⚠ Phân biệt bốn loại bài toán:

⚠ REGRESSION (hồi quy)
    → ⚠ dự đoán một SỐ LIÊN TỤC
    → giá nhà, doanh thu, nhiệt độ
    → đề này

CLASSIFICATION (phân loại)
    → ⚠ dự đoán một NHÃN RỜI RẠC
    → spam / không spam,
      khách rời bỏ / ở lại

CLUSTERING (phân cụm)
    → ⚠ KHÔNG có nhãn
    → tự tìm nhóm tự nhiên
    → phân khúc khách hàng

ANOMALY DETECTION
    → ⚠ tìm điểm BẤT THƯỜNG
    → phát hiện gian lận, lỗi máy

⚠ Phép thử nhanh:

Câu hỏi: "Đầu ra là gì?"
        ↓
    Một SỐ có thể là bất kỳ giá trị nào
    trong một khoảng
        ↓
    ⚠ → REGRESSION

    Một trong vài LỰA CHỌN cho sẵn
        ↓
    ⚠ → CLASSIFICATION

    Không có đầu ra định trước,
    chỉ muốn tìm nhóm
        ↓
    ⚠ → CLUSTERING

⚠ Cẩn thận với ranh giới mờ:

"Dự đoán GIÁ NHÀ" (2,3 tỉ, 4,7 tỉ…)
    → ⚠ REGRESSION

"Dự đoán nhà thuộc phân khúc
 RẺ / TRUNG BÌNH / CAO CẤP"
    → ⚠ CLASSIFICATION
        ↓
    ⚠ Cùng một dữ liệu, khác cách
      đặt câu hỏi → khác loại bài toán

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

• B (Classification) — phương án gần nhất và là bẫy chính: nếu đề hỏi "nhà này thuộc nhóm giá nào" thì đúng là phân loại. Nhưng đề nói rõ đầu ra là giá trị số liên tục.

• D (Clustering) — không có nhãn, chỉ tìm nhóm tự nhiên. Ở đây có dữ liệu giá thật để học.

• C (Anomaly Detection) — tìm điểm bất thường, không dự đoán giá trị.

Ghi nhớ

⚠ Bốn loại bài toán ML — bảng phải thuộc: | Loại | Đầu ra | Ví dụ | |---|---|---| | ⚠ Regression | ⚠ SỐ liên tục | giá nhà, doanh thu, thời gian giao hàng | | Classification | ⚠ NHÃN rời rạc | spam, khách rời bỏ, loại sản phẩm | | Clustering | nhóm tự tìm ra | phân khúc khách hàng | | Anomaly detection | bình thường / bất thường | gian lận, lỗi máy móc | | Recommendation | danh sách gợi ý | sản phẩm nên mua | | Forecasting | ⚠ số liên tục theo THỜI GIAN | dự báo doanh số |

Từ khoá nhận diện:

"dự đoán một con số" → regression "thuộc nhóm nào, có hay không" → classification "tự tìm nhóm, không có nhãn" → clustering "dự báo theo thời gian" → ⚠ forecasting — dạng đặc biệt của regression

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đầu ra là số hay nhãn | ⚠ quyết định loại bài toán | | Mô hình có tốt hơn đoán trung bình không | so R² và MAE với đường cơ sở | | Sai số bao nhiêu là chấp nhận được | ⚠ hỏi bên nghiệp vụ, không tự quyết |

Và một câu hỏi nên đặt cùng lúc với việc chọn loại bài toán: sai số bao nhiêu thì mô hình còn hữu ích? Dự đoán giá nhà lệch 5% có thể chấp nhận được với một trang tham khảo, nhưng lệch 5% trong một hệ thống định giá tự động lại là con số rất lớn tính bằng tiền thật.

Đáp án

D — Công ty đang giảm tác động môi trường của chính mình bằng cách chạy trên một đám mây trung hoà carbon.

Vì sao đúng

Câu hỏi là bền vững nghĩa là gì với một tổ chức khách hàng, và câu trả lời nằm ở việc giảm phát thải của chính họ.

⚠ Vì sao chạy trên đám mây giảm phát thải:

TRUNG TÂM DỮ LIỆU RIÊNG
    ⚠ tỉ lệ sử dụng máy thường
      dưới 20%
    ⚠ hiệu suất làm mát kém
      (PUE ~1,5–2,0)
    ⚠ điện từ lưới địa phương

GOOGLE CLOUD
    ⚠ PUE ~1,1 — hiệu quả hàng đầu
    ⚠ máy dùng chung, tỉ lệ
      sử dụng cao
    ⚠ mua năng lượng tái tạo
      quy mô lớn
        ↓
    → CÙNG khối lượng công việc,
      phát thải THẤP HƠN NHIỀU

⚠ Và khách hàng còn tự giảm thêm được:

⚠ CHỌN VÙNG CÓ CFE% CAO
   → tác động lớn nhất, làm được ngay
⚠ XOÁ TÀI NGUYÊN NẰM KHÔNG
   → giảm cả tiền lẫn carbon
⚠ DÙNG SERVERLESS CO VỀ 0
⚠ ĐẶT VÒNG ĐỜI cho dữ liệu cũ
        ↓
    Và ĐO bằng ⚠ Carbon Footprint

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

"Tự động tuân thủ MỌI quy định
 của ngành"
    → ⚠ SAI: tuân thủ là
      TRÁCH NHIỆM CHUNG

"Workload chạy NHANH HƠN mọi
 đám mây khác"
    → ⚠ không liên quan tới
      bền vững, và không đảm bảo được

"Trả BẰNG KHÔNG cho tài nguyên
 đám mây"
    → ⚠ vô lý

Nhất quán với #13354 (lô 140) về mục tiêu 24/7 không carbon vào 2030, và với #13271, #13277 (lô 139) về Carbon Footprint và chọn vùng sạch. Cả bốn cùng một trụ cột.

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

• A (tự động tuân thủ mọi quy định của ngành) — phương án gần nhất về mặt "cũng là lợi ích nghe hay", nhưng sai hoàn toàn: tuân thủ là trách nhiệm chung, và Google chỉ cung cấp nền tảng đủ điều kiện.

• B (chạy nhanh hơn mọi đám mây khác) — không liên quan tới bền vững.

• C (trả bằng không cho tài nguyên) — không đúng ở bất kỳ nghĩa nào.

Ghi nhớ

⚠ Ba khái niệm carbon dễ lẫn — bảng phải thuộc: | Khái niệm | Nghĩa | |---|---| | Carbon neutral | ⚠ BÙ ĐẮP phát thải bằng tín chỉ | | 100% renewable matching | mua đủ điện tái tạo theo NĂM (Google đạt từ 2017) | | ⚠ 24/7 carbon-free | ⚠ MỖI GIỜ đều dùng điện sạch — mục tiêu 2030 |

Từ khoá nhận diện:

"giảm tác động môi trường của mình" → lợi ích bền vững "đo phát thải của mình" → Carbon Footprint "chọn vùng sạch" → CFE% / huy hiệu lá cây "mục tiêu 2030" → 24/7 năng lượng không carbon

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 tin tốt cho các đội vừa phải giảm chi phí vừa phải báo cáo ESG: hai mục tiêu này gần như luôn đi cùng hướng. Mỗi máy ảo nằm không mà bạn tắt đi đều xuất hiện ở cả hai bảng — bảng chi phí và bảng phát thải — nên không cần chọn giữa chúng.

Đáp án

D — Artifact Registry.

Vì sao đúng

Artifact Registry là kho lưu trữ artifact chính thức của Google Cloud, và image container là loại artifact chính mà nó phục vụ.

⚠ Vị trí trong đường ống CI/CD:

Mã nguồn (Cloud Source Repositories,
          GitHub, GitLab)
        ↓
CLOUD BUILD — dựng và kiểm thử
        ↓
    ⚠ ARTIFACT REGISTRY
      lưu image container
        ↓
    ⚠ Artifact Analysis quét lỗ hổng
        ↓
    ⚠ Binary Authorization kiểm chữ ký
        ↓
CLOUD RUN / GKE — triển khai

⚠ Artifact Registry lưu được gì:

⚠ Container image (Docker, OCI)
⚠ Helm chart
Gói Maven và Gradle (Java)
Gói npm (Node.js)
Gói Python
Gói Go
Gói APT và YUM
        ↓
    ⚠ MỘT kho cho MỌI loại artifact
    → thay thế Container Registry cũ

⚠ Vì sao không dùng Cloud Storage:

Cloud Storage LƯU ĐƯỢC tệp image
        ↓
    ⚠ Nhưng KHÔNG có:
      - giao thức Docker registry
      - quản lý thẻ và phiên bản
      - quét lỗ hổng tự động
      - tích hợp IAM theo repository
      - dọn image cũ theo chính sách
        ↓
    → `docker push` không dùng
      được với nó

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

• A (Cloud Source Repositories) — phương án gần nhất về mặt "cũng là kho": nó lưu MÃ NGUỒN (Git), không phải image đã dựng. Nó đứng trước Cloud Build trong đường ống.

• C (Cloud Storage) — lưu tệp nói chung, nhưng không phải registry: không hỗ trợ giao thức Docker, không quản thẻ, không quét lỗ hổng.

• B (BigQuery) — kho phân tích dữ liệu, sai hoàn toàn lĩnh vực.

Ghi nhớ

⚠ Các thành phần đường ống CI/CD trên Google Cloud — bảng phải thuộc: | Thành phần | Việc | |---|---| | Cloud Source Repositories | ⚠ kho MÃ NGUỒN (Git) | | Cloud Build | dựng, kiểm thử, đóng gói | | ⚠ Artifact Registry | ⚠ kho IMAGE và GÓI | | Artifact Analysis | ⚠ quét lỗ hổng trong image | | Binary Authorization | ⚠ chỉ image ĐÃ KÝ mới được triển khai | | Cloud Deploy | triển khai theo giai đoạn | | Cloud Run / GKE | nơi chạy |

Từ khoá nhận diện:

"lưu image container" → Artifact Registry "lưu mã nguồn" → Cloud Source Repositories / GitHub "dựng và kiểm thử tự động" → Cloud Build "chặn image chưa ký" → Binary Authorization

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Image có lỗ hổng nào không | Artifact Analysis | | Có ai dùng latest trong production không | ⚠ rà cấu hình triển khai | | Kho có phình ra không | chính sách dọn image cũ |

Và một cấu hình nên đặt sớm cho mọi repository: chính sách tự dọn image cũ. Một đường ống CI/CD chạy vài chục lần mỗi ngày sẽ tích lại hàng nghìn image trong vài tháng, và phần lớn trong số đó chưa bao giờ được triển khai lần nào.

Đáp án

B — Nó cho khả năng nhìn thấy hiệu năng của ứng dụng, giúp đội CHỦ ĐỘNG phát hiện và xử lý vấn đề TRƯỚC khi chúng ảnh hưởng tới người dùng.

Vì sao đúng

Giá trị kinh doanh của giám sát nằm ở hai chữ: chủ động — biết trước thay vì biết khi khách hàng gọi điện phàn nàn.

⚠ Ba chỉ số trong đề nói lên điều gì:

ĐỘ TRỄ (latency)
    → ⚠ tăng dần là dấu hiệu sớm
      của quá tải hoặc rò rỉ tài nguyên

TỈ LỆ LỖI (error rate)
    → ⚠ nhích lên từ 0,1% lên 2%
      trước khi thành sự cố lớn

CPU
    → ⚠ tiến dần tới ngưỡng
        ↓
    → thấy được XU HƯỚNG,
      không chỉ trạng thái hiện tại

⚠ Bị động và chủ động:

KHÔNG CÓ GIÁM SÁT
    Khách hàng gọi điện phàn nàn
        ↓
    ⚠ Mới bắt đầu điều tra
    ⚠ Không biết bắt đầu từ đâu
    ⚠ Thiệt hại đã xảy ra

CÓ GIÁM SÁT
    ⚠ Thấy độ trễ tăng từ 200ms
      lên 400ms trong ba ngày
        ↓
    Xử lý trước khi chạm ngưỡng
        ↓
    ⚠ Người dùng không hề biết
      có chuyện gì

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

"ĐẢM BẢO chi phí đám mây sẽ giảm"
    → ⚠ giám sát có thể GIÚP tối ưu
    → nhưng KHÔNG đảm bảo

"THAY THẾ nhu cầu có đội phát triển"
    → ⚠ vô lý

"TỰ ĐỘNG ngăn chặn MỌI vi phạm
 bảo mật"
    → ⚠ giám sát PHÁT HIỆN,
      không NGĂN CHẶN
    → và không có gì "mọi"

Nhất quán với #13403 (cùng lô này) — câu đó về công cụ (dashboard trong Cloud Monitoring). Câu này về giá trị kinh doanh của việc dùng nó. Hai câu bổ sung nhau.

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

• A (đảm bảo chi phí đám mây sẽ giảm) — phương án gần nhất về mặt "cũng là lợi ích thật": giám sát giúp phát hiện tài nguyên lãng phí. Nhưng chữ "đảm bảo" làm nó sai, và đó không phải giá trị chính của việc theo dõi độ trễ và tỉ lệ lỗi.

• D (tự động ngăn mọi vi phạm bảo mật) — giám sát phát hiện, không ngăn chặn; và không có gì tuyệt đối.

• C (thay thế nhu cầu có đội phát triển) — không liên quan.

Ghi nhớ

⚠ Bốn tín hiệu vàng — bảng phải thuộc: | Tín hiệu | Đo gì | |---|---| | Latency | ⚠ độ trễ — đo p50, p95, p99 | | Traffic | lưu lượng | | Errors | tỉ lệ lỗi | | Saturation | ⚠ mức bão hoà tài nguyên — CPU, bộ nhớ | | Đề này | nêu đúng ba trong bốn |

Từ khoá nhận diện:

"nhìn thấy trước, xử lý trước khi ảnh hưởng" → giá trị của giám sát "báo cho tôi khi vượt ngưỡng" → alerting policy "xem tổng quan" → dashboard "tìm nguyên nhân cụ thể" → ⚠ Cloud Logging

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao | |---|---| | Ai phát hiện sự cố trước — hệ thống hay khách hàng | ⚠ thước đo thật của giám sát | | Có bao nhiêu cảnh báo bị bỏ qua | dấu hiệu ngưỡng sai | | Cảnh báo bắn xong thì làm gì | ⚠ có runbook chưa |

Và một thước đo rất thẳng thắn cho chất lượng hệ thống giám sát: ai là người phát hiện ra sự cố trước. Nếu câu trả lời thường là khách hàng, thì dashboard dù đẹp đến đâu cũng chưa làm được việc của nó.

Đáp án

D — Để khiến dữ liệu trở nên không đọc được và vô dụng với kẻ tấn công nếu họ chạm được vào phương tiện lưu trữ vật lý.

Vì sao đúng

Đề nêu đúng kịch bản mà mã hoá khi lưu (encryption at rest) sinh ra để chống: kẻ tấn công có ổ đĩa vật lý trong tay.

⚠ Mã hoá khi lưu bảo vệ điều gì:

Kẻ tấn công lấy được ổ đĩa
hoặc băng sao lưu
        ↓
    KHÔNG mã hoá
        ↓
    ⚠ Cắm vào máy khác → ĐỌC ĐƯỢC
      toàn bộ hồ sơ bệnh nhân

    CÓ mã hoá
        ↓
    ⚠ Chỉ thấy dãy byte vô nghĩa
    ⚠ Khoá nằm ở HỆ THỐNG KHÁC
        ↓
    → dữ liệu vô dụng với họ

⚠ Ba trạng thái dữ liệu — mỗi trạng thái một biện pháp:

⚠ KHI LƯU (at rest)
    → ⚠ chống lấy cắp phương tiện
      vật lý — ĐỀ NÀY
    → mã hoá đĩa

KHI TRUYỀN (in transit)
    → ⚠ chống nghe lén trên mạng
    → TLS

KHI XỬ LÝ (in use)
    → chống đọc bộ nhớ
    → Confidential Computing

⚠ Trên Google Cloud, mã hoá khi lưu là MẶC ĐỊNH:

Mọi dữ liệu trong Cloud Storage,
BigQuery, Persistent Disk…
        ↓
    ⚠ ĐƯỢC MÃ HOÁ TỰ ĐỘNG
    ⚠ KHÔNG tắt được
    ⚠ KHÔNG tốn thêm tiền
        ↓
    Dữ liệu còn được ⚠ CHIA NHỎ
    và phân tán trên nhiều ổ đĩa
        ↓
    → một ổ đĩa đơn lẻ không chứa
      một tệp hoàn chỉnh

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

"Tăng tốc độ truy xuất dữ liệu"
    → ⚠ mã hoá không làm nhanh hơn

"Đảm bảo chỉ người có thẩm quyền
 truy cập được MÁY CHỦ VẬT LÝ"
    → ⚠ đó là AN NINH VẬT LÝ,
      không phải mã hoá

"Bảo vệ dữ liệu khi ĐANG DI CHUYỂN
 trên Internet"
    → ⚠ đó là mã hoá KHI TRUYỀN

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

• C (bảo vệ dữ liệu khi đang di chuyển trên Internet) — phương án gần nhất và là bẫy chính: đó là mã hoá KHI TRUYỀN (in transit), một biện pháp khác cho một mối đe doạ khác. Đề nói rõ về ổ đĩa vật lý và băng sao lưu.

• B (đảm bảo chỉ người có thẩm quyền truy cập máy chủ vật lý) — đó là an ninh vật lý, việc của trung tâm dữ liệu.

• A (tăng tốc độ truy xuất) — không liên quan; mã hoá không cải thiện tốc độ.

Ghi nhớ

⚠ Ba trạng thái dữ liệu — bảng phải thuộc: | Trạng thái | Chống gì | Biện pháp | |---|---|---| | ⚠ Khi lưu (at rest) | ⚠ lấy cắp ổ đĩa, băng sao lưu | mã hoá đĩa — MẶC ĐỊNH | | Khi truyền (in transit) | nghe lén trên mạng | TLS | | Khi xử lý (in use) | đọc bộ nhớ | Confidential Computing |

Từ khoá nhận diện:

"ổ đĩa bị lấy, băng sao lưu bị mất" → mã hoá khi lưu "nghe lén trên đường truyền" → mã hoá khi truyền, TLS "bảo vệ trong lúc CPU xử lý" → Confidential Computing "ai được vào phòng máy" → an ninh vật lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu có được mã hoá không | ⚠ mặc định CÓ — không cần làm gì | | Có cần CMEK không | tuỳ yêu cầu tuân thủ | | Ai đọc được dữ liệu | ⚠ kiểm IAM — quan trọng hơn mã hoá |

Và một điều rất đáng nhớ khi bàn về mã hoá: nó chống được kẻ trộm ổ đĩa nhưng không chống được quyền cấp sai. Một hồ sơ bệnh nhân được mã hoá bằng AES-256 vẫn hiện ra hoàn toàn bình thường trước một tài khoản có quyền đọc — nên IAM mới là lớp bảo vệ mà bạn phải chăm chút nhất.

Đáp án

D — Nó đem lại khả năng dự đoán và kiểm soát chi phí đám mây bằng cách gắn chi tiêu công nghệ với giá trị nghiệp vụ.

Vì sao đúng

Đề mô tả đúng ba triệu chứng mà FinOps sinh ra để chữa, và cả ba đều là vấn đề về khả năng nhìn thấy và trách nhiệm giải trình, không phải về giá.

⚠ Ba triệu chứng trong đề:

1. "Kỹ sư TỰ DO tạo tài nguyên"
     → ⚠ không có ranh giới,
       không ai chịu trách nhiệm

2. "Tài chính KHÔNG NHÌN THẤY
    sản phẩm nào tốn tiền"
     → ⚠ thiếu bóc tách chi phí

3. "Lãnh đạo KHÔNG DỰ ĐOÁN ĐƯỢC
    chi tiêu để lập ngân sách"
     → ⚠ thiếu tính dự đoán
        ↓
    → chi phí tăng 3,6 lần trong
      ba tháng mà doanh thu không theo

⚠ FinOps giải bằng gì:

⚠ NHÌN THẤY (visibility)
    → nhãn bắt buộc, billing export
      sang BigQuery, dashboard
      theo đội và sản phẩm

⚠ TRÁCH NHIỆM (accountability)
    → mỗi đội thấy chi phí của mình
    → có ngân sách và cảnh báo riêng

⚠ TỐI ƯU (optimization)
    → rightsizing, CUD, dọn tài
      nguyên nằm không

⚠ GẮN VỚI GIÁ TRỊ
    → ⚠ "chi phí trên mỗi khách hàng",
      "chi phí trên mỗi giao dịch"

⚠ Vì sao "gắn với giá trị nghiệp vụ" mới là điểm mấu chốt:

Chi phí tăng 3,6 lần
        ↓
    ⚠ Chưa chắc là XẤU
        ↓
    Nếu số khách hàng cũng tăng 4 lần
        → ⚠ chi phí trên mỗi khách
          THỰC RA đã GIẢM
        ↓
    Nếu khách không tăng
        → ⚠ đây là lãng phí thật
        ↓
    → FinOps trả lời được câu hỏi đó

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

"Chỉ tập trung tìm dịch vụ RẺ NHẤT
 bất kể hiệu năng"
    → ⚠ FinOps KHÔNG phải cắt giảm
      mù quáng
    → mà là chi ĐÚNG CHỖ

"Đảm bảo lập trình viên dùng
 BẤT KỲ dịch vụ nào không hạn chế"
    → ⚠ ngược với mục tiêu kiểm soát

"Loại bỏ nhu cầu có bộ phận
 tài chính"
    → ⚠ FinOps là SỰ HỢP TÁC giữa
      kỹ thuật, tài chính và kinh doanh

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

• A (chỉ tìm dịch vụ rẻ nhất bất kể hiệu năng) — phương án gần nhất về mặt "cũng nói về tiết kiệm", nhưng FinOps không phải cắt giảm bằng mọi giá: mục tiêu là chi đúng chỗ để tạo giá trị, đôi khi là chi nhiều hơn.

• B (đảm bảo lập trình viên dùng gì cũng được) — trái với mục tiêu kiểm soát của đề.

• C (loại bỏ nhu cầu có bộ phận tài chính) — FinOps là hợp tác giữa kỹ thuật và tài chính, không thay thế bên nào.

Ghi nhớ

⚠ Ba giai đoạn của FinOps — bảng nên thuộc: | Giai đoạn | Nội dung | |---|---| | ⚠ Inform (nhìn thấy) | ⚠ nhãn, bóc tách chi phí, dashboard, dự báo | | ⚠ Optimize (tối ưu) | rightsizing, CUD, dọn lãng phí, kiến trúc rẻ hơn | | ⚠ Operate (vận hành) | quy trình liên tục, mục tiêu, trách nhiệm | | ⚠ Nguyên tắc | đây là VÒNG LẶP, không phải dự án một lần |

Từ khoá nhận diện:

"kiểm soát và dự đoán chi phí, gắn với giá trị" → FinOps "báo cho tôi khi tới X%" → budget alert "xem chi phí đi đâu" → billing reports "chặn cứng số tài nguyên" → quota

Ba việc kiểm chứng cho tổ chức trong đề: | Việc | Cách | |---|---| | Bao nhiêu % tài nguyên có nhãn | ⚠ làm việc này TRƯỚC mọi thứ khác | | Chi phí trên mỗi khách hàng ra sao | so với ba tháng trước | | Có bao nhiêu tài nguyên nằm không | Recommender |

Và bước đầu tiên gần như luôn giống nhau với mọi tổ chức gặp cảnh này: bắt buộc gắn nhãn cho mọi tài nguyên. Không có nhãn thì mọi cuộc thảo luận về chi phí đều dừng ở câu "khoản này của đội nào?" — và chừng nào chưa trả lời được câu đó thì chưa ai có thể chịu trách nhiệm về nó.

Đáp án

D — Vertex AI Workbench.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều là mô tả của Workbench:

⚠ Ba yêu cầu ↔ Vertex AI Workbench:

1. ⚠ "THƯ VIỆN PYTHON TUỲ BIẾN
    của riêng họ"
     → ⚠ cần môi trường cài được
       gói tuỳ ý → notebook

2. "MÔI TRƯỜNG NOTEBOOK
    CÓ QUẢN LÝ HOÀN TOÀN"
     → JupyterLab do Google vận hành

3. "TÍCH HỢP với bảo mật và công cụ
    xử lý dữ liệu của Google Cloud"
     → ⚠ IAM, VPC, BigQuery,
       Dataproc, Cloud Storage

⚠ Workbench cho gì mà notebook tự dựng không có:

⚠ Tích hợp IAM và VPC Service Controls
⚠ Truy cập BigQuery và Cloud Storage
   không cần khoá tệp
   (dùng service account)
⚠ Kết nối Dataproc cho Spark
⚠ Idle shutdown — ⚠ tự tắt khi
   không dùng, tiết kiệm chi phí
⚠ GPU gắn thêm khi cần
⚠ Lưu notebook và môi trường
   giữa các phiên

⚠ Vì sao ba phương án kia không phải:

BIGQUERY ML
    → ⚠ huấn luyện bằng SQL
    → ⚠ KHÔNG chạy được thư viện
      Python tuỳ biến

NATURAL LANGUAGE API
    → ⚠ MỘT API dựng sẵn
    → không phải môi trường phát triển

APP ENGINE
    → ⚠ nền tảng chạy ỨNG DỤNG WEB
    → không phải notebook

Nhất quán với #13307 (lô 139) — câu đó về Vertex AI là nền tảng MLOps hợp nhất. Workbench là thành phần notebook trong nền tảng đó. Hai câu bổ sung nhau.

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

• B (BigQuery ML) — phương án gần nhất trong các công cụ ML: nó rất mạnh nhưng làm việc bằng SQL trong kho dữ liệu. Đội này cần chạy thư viện Python riêng, điều BigQuery ML không hỗ trợ.

• A (Natural Language API) — một API dựng sẵn, không phải môi trường phát triển.

• C (App Engine) — nền tảng chạy ứng dụng web, không phải notebook.

Ghi nhớ

⚠ Chọn công cụ ML theo nhu cầu — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | ⚠ Notebook Python, thư viện tuỳ biến | ⚠ Vertex AI Workbench | | Huấn luyện bằng SQL trong kho | BigQuery ML | | Không viết mã, dữ liệu riêng | AutoML | | Việc phổ quát | API dựng sẵn | | Huấn luyện quy mô lớn có mã riêng | Vertex AI Training |

Từ khoá nhận diện:

"notebook, thư viện Python riêng" → Vertex AI Workbench "SQL trong kho dữ liệu" → BigQuery ML "không viết mã" → AutoML "nền tảng MLOps hợp nhất" → Vertex AI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bật idle shutdown chưa | ⚠ khoản lãng phí phổ biến nhất | | Notebook có IP công khai không | nên tắt | | Có tái lập được kết quả không | ⚠ notebook lộn xộn thì không |

Và một thói quen phân biệt đội dữ liệu trưởng thành với đội mới: notebook là nơi khám phá, pipeline là nơi sản xuất. Một mô hình quan trọng mà mỗi tháng phải có người mở notebook lên bấm chạy lại là một quy trình chưa hoàn thành, dù kết quả có tốt đến đâu.

Đáp án

D — Chi phí điện năng để chạy và làm mát máy chủ.

Vì sao đúng

Đề hỏi một chi phí GIÁN TIẾP của hạ tầng tại chỗ, hay bị bỏ sót, và được loại bỏ khi lên đám mây — cả ba điều kiện đều đúng với điện và làm mát.

⚠ Ba điều kiện của đáp án:

1. ⚠ GIÁN TIẾP
     → không nằm trong hoá đơn
       mua máy chủ

2. ⚠ HAY BỊ BỎ SÓT
     → bảng tính TCO thường chỉ
       có giá phần cứng

3. ⚠ ĐƯỢC LOẠI BỎ khi lên đám mây
     → Google trả tiền điện,
       không phải bạn

⚠ Điện và làm mát lớn tới mức nào:

Máy chủ tiêu thụ điện
        ↓
    ⚠ Toả nhiệt
        ↓
    ⚠ Phải làm mát → TỐN THÊM ĐIỆN
        ↓
    ⚠ Tổng điện cho làm mát thường
      xấp xỉ điện cho chính máy chủ
        ↓
    Chỉ số PUE:
      ⚠ trung tâm dữ liệu thường
        ~1,5–2,0
      ⚠ Google ~1,1
        ↓
    → cùng khối lượng tính toán,
      Google tốn ít điện hơn nhiều

⚠ Vì sao ba phương án kia không thoả:

"GIẤY PHÉP hệ điều hành"
    → ⚠ là chi phí TRỰC TIẾP,
      dễ thấy trong hoá đơn
    → ⚠ và KHÔNG biến mất trên
      đám mây (vẫn trả cho Windows)

"LƯƠNG đội PHÁT TRIỂN ứng dụng"
    → ⚠ vẫn cần dù ở đâu
    → không phải chi phí hạ tầng

"Chi phí máy ảo Google Cloud
 hằng tháng"
    → ⚠ đó là chi phí PHÍA ĐÁM MÂY,
      không phải chi phí tại chỗ

⚠ Gần trùng với #13351 (lô 140) — đề đó cũng hỏi những khoản ngoài giá máy chủ trong TCO, và cùng khoá "mặt bằng, làm mát, điện, nhân sự". Hoàn toàn nhất quán.

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

• A (giấy phép hệ điều hành) — phương án gần nhất về mặt "cũng là chi phí thật", nhưng nó trực tiếp và dễ thấy, và không biến mất khi lên đám mây (bạn vẫn trả tiền giấy phép Windows Server, dù có thể theo cách khác).

• B (lương đội phát triển ứng dụng) — vẫn cần dù chạy ở đâu; không phải chi phí hạ tầng.

• C (chi phí máy ảo Google Cloud hằng tháng) — đó là chi phí phía đám mây, không phải chi phí tại chỗ được loại bỏ.

Ghi nhớ

⚠ TCO của hạ tầng tại chỗ — bảng nên thuộc: | Nhóm | Khoản | |---|---| | Trực tiếp | phần cứng, giấy phép, hợp đồng bảo trì | | ⚠ Gián tiếp | ⚠ mặt bằng, ĐIỆN, LÀM MÁT, UPS, máy phát | | ⚠ Nhân sự | ⚠ lương vận hành, trực đêm, đào tạo | | Rủi ro | ⚠ chi phí của thời gian ngừng dịch vụ | | Cơ hội | ⚠ thời gian đội không dành cho sản phẩm | | Năng lực dư | ⚠ mua cho đỉnh, dùng ở mức thấp |

Từ khoá nhận diện:

"gián tiếp, hay bị bỏ sót" → điện, làm mát, mặt bằng, nhân sự "tổng chi phí sở hữu" → TCO "chuyển từ mua sang thuê" → CapEx → OpEx "lợi tức đầu tư" → ROI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | TCO hiện tại thật sự là bao nhiêu | ⚠ hỏi cả bộ phận cơ sở vật chất | | Tỉ lệ sử dụng máy chủ | ⚠ thường dưới 20% | | Có phần cứng nào chưa khấu hao xong | ảnh hưởng thời điểm di cư |

Và một con số đáng đi tìm trước mọi cuộc so sánh TCO: hoá đơn tiền điện của phòng máy. Nó nằm ở bộ phận cơ sở vật chất chứ không nằm ở bộ phận CNTT, nên hầu như không bao giờ xuất hiện trong bảng tính so sánh — dù thường chiếm một phần đáng kể tổng chi phí thật.