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

Đáp án

C — Site Reliability Engineering (SRE).

Vì sao đúng

Đề nói ba điều, và cả ba đều là dấu hiệu nhận diện của SRE: do Google khởi xướng, dùng nguyên lý kỹ thuật phần mềm để tự động hoá vận hành, và hướng tới một mục tiêu SLO cụ thể.

⚠ Định nghĩa gốc của Google:

"SRE là những gì xảy ra khi bạn
 yêu cầu một KỸ SƯ PHẦN MỀM
 thiết kế công việc VẬN HÀNH."
        ↓
    Vấn đề vận hành được xử lý
    bằng MÃ, không bằng thao tác tay

⚠ Ba khái niệm cốt lõi — phải thuộc:

SLI  Service Level Indicator
       → CHỈ SỐ đo được
         ví dụ: % request thành công

SLO  Service Level Objective
       → ⚠ MỤC TIÊU nội bộ
         ví dụ: 99,9% — như đề bài

SLA  Service Level Agreement
       → ⚠ CAM KẾT với KHÁCH HÀNG,
         có bồi thường nếu vi phạm
        ↓
    ⚠ SLO luôn CHẶT HƠN SLA
      → có biên an toàn

⚠ Error budget — ý tưởng đắt giá nhất của SRE:

SLO 99,9% trong 30 ngày
        ↓
    Cho phép hỏng: 0,1%
    ≈ 43 phút mỗi tháng
        ↓
    ⚠ Đó là NGÂN SÁCH LỖI
        ↓
    Còn ngân sách → ⚠ CỨ TRIỂN KHAI
                      tính năng mới
    Hết ngân sách → ⚠ DỪNG tính năng,
                      tập trung vào
                      độ tin cậy
        ↓
    → Giải quyết mâu thuẫn muôn thuở
      giữa đội phát triển (muốn nhanh)
      và đội vận hành (muốn ổn định)
      bằng MỘT CON SỐ

⚠ Toil — thứ SRE tìm cách xoá bỏ:

TOIL = việc tay, lặp đi lặp lại,
       tự động hoá được,
       không tạo giá trị lâu dài
        ↓
    ⚠ SRE giới hạn toil dưới 50%
      thời gian
        ↓
    Nửa còn lại: viết mã để
    xoá bỏ chính công việc đó

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

• A (DevOps) — phương án gần nhất và rất gần về tinh thần: DevOps là triết lý xoá bỏ rào cản giữa phát triển và vận hành. SRE thường được mô tả là một cách cài đặt cụ thể của DevOps, với SLO, error budget và giới hạn toil. Đề nhấn mạnh "do Google khởi xướng" và "mục tiêu SLO" — đó là SRE.

• B (ITIL) — khung quản lý dịch vụ CNTT truyền thống, thiên về quy trình và thủ tục, không phải về tự động hoá bằng kỹ thuật phần mềm.

• D (Agile) — phương pháp phát triển phần mềm theo vòng lặp ngắn. Không nói về vận hành hạ tầng hay độ tin cậy.

Ghi nhớ

⚠ SLI, SLO, SLA — bảng phải thuộc: | Khái niệm | Nghĩa | |---|---| | SLI | chỉ số ĐO ĐƯỢC — độ sẵn sàng, độ trễ, tỉ lệ lỗi | | SLO | MỤC TIÊU nội bộ dựa trên SLI | | SLA | HỢP ĐỒNG với khách, có bồi thường | | Error budget | 100% − SLO — phần được phép hỏng |

Từ khoá nhận diện:

"SLO, error budget, do Google khởi xướng" → SRE "xoá rào cản dev và ops, văn hoá" → DevOps "quy trình quản lý dịch vụ, ITSM" → ITIL "sprint, backlog, lặp ngắn" → Agile

Ba việc kiểm chứng cho một đội: | Việc | Câu hỏi | |---|---| | Có SLO viết ra không | hay chỉ nói miệng "phải luôn chạy" | | Còn bao nhiêu error budget | có bảng theo dõi chưa | | Toil chiếm bao nhiêu thời gian | ⚠ trên 50% là dấu hiệu cần tự động hoá gấp |

Và một điều rất đáng suy nghĩ về SRE, dù nó ít khi được hỏi trực tiếp: giá trị lớn nhất của error budget không phải kỹ thuật mà là tổ chức. Nó biến cuộc tranh cãi bất tận giữa "ra tính năng nhanh lên" và "đừng làm sập hệ thống" thành một con số mà cả hai bên đều nhìn thấy và cùng chấp nhận trước.

Đáp án

B — Đám mây lai (Hybrid cloud).

Vì sao đúng

Đề mô tả đúng định nghĩa của đám mây lai: kết hợp hạ tầng tại chỗ với đám mây công cộng, hai bên phối hợp làm việc.

⚠ Bức tranh trong đề:

TẠI BỆNH VIỆN (on-premises)
    Hồ sơ bệnh nhân nhạy cảm
    ⚠ ở lại vì quy định
      về vị trí dữ liệu
              │
              │ dữ liệu ĐÃ ẨN DANH
              ▼
GOOGLE CLOUD (public cloud)
    BigQuery phân tích cho nghiên cứu
        ↓
    ⚠ Hai môi trường, một chiến lược
    → ĐÁM MÂY LAI

⚠ Bốn mô hình triển khai — phân biệt cho rõ:

PUBLIC CLOUD
    → toàn bộ trên hạ tầng dùng chung
      của nhà cung cấp

PRIVATE CLOUD
    → hạ tầng ảo hoá RIÊNG,
      chỉ một tổ chức dùng
      (thường đặt tại chỗ)

HYBRID CLOUD
    → ⚠ TẠI CHỖ + CÔNG CỘNG
      phối hợp — đề này

MULTI-CLOUD
    → ⚠ NHIỀU NHÀ CUNG CẤP
      đám mây công cộng
      (ví dụ Google + AWS)

⚠ Vì sao bệnh viện chọn mô hình này:

Giữ hồ sơ bệnh nhân tại chỗ
    → ⚠ tuân thủ quy định
      về vị trí dữ liệu
    → tận dụng hạ tầng đã đầu tư
        +
Đưa dữ liệu ẩn danh lên BigQuery
    → ⚠ có sức tính toán mà bệnh viện
      không thể tự dựng
    → trả tiền theo mức dùng
        ↓
    → Vừa tuân thủ, vừa hiện đại

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

• D (đa đám mây — multi-cloud) — phương án gần nhất và hay bị nhầm nhất. Đa đám mây nghĩa là dùng nhiều nhà cung cấp đám mây công cộng. Ở đây chỉ có một nhà cung cấp (Google) cộng với hạ tầng tại chỗ — đó là lai, không phải đa đám mây.

• A (đám mây công cộng) — sẽ đúng nếu mọi thứ chạy trên Google Cloud. Nhưng hồ sơ bệnh nhân ở lại bệnh viện.

• C (đám mây riêng) — sẽ đúng nếu mọi thứ nằm trên hạ tầng riêng. Nhưng họ có dùng BigQuery.

Ghi nhớ

⚠ Bốn mô hình triển khai — bảng phải thuộc: | Mô hình | Nghĩa | |---|---| | Public cloud | toàn bộ trên hạ tầng dùng chung của nhà cung cấp | | Private cloud | hạ tầng riêng cho một tổ chức | | Hybrid cloud | ⚠ TẠI CHỖ + CÔNG CỘNG | | Multi-cloud | ⚠ NHIỀU nhà cung cấp công cộng |

Từ khoá nhận diện:

"giữ một phần tại chỗ, dùng đám mây phần còn lại" → hybrid "dùng cả Google Cloud và AWS" → multi-cloud "tất cả trên đám mây" → public "trung tâm dữ liệu riêng đã ảo hoá" → private

Ba việc kiểm chứng: | Việc | Câu hỏi | |---|---| | Vì sao phần này phải ở lại tại chỗ | quy định, độ trễ, hay chỉ là thói quen | | Dữ liệu đưa lên đã ẩn danh thật chưa | quét bằng Sensitive Data Protection | | Kết nối có đủ băng thông và an toàn không | Interconnect hay VPN |

Và một câu hỏi đáng đặt lại định kỳ cho mọi kiến trúc lai: lý do giữ phần này ở lại tại chỗ có còn đúng không? Rất nhiều hệ thống ở lại trung tâm dữ liệu riêng vì một quy định đã thay đổi, hoặc vì một giả định chưa ai kiểm tra lại từ nhiều năm trước.

Đáp án

B — Cloud Storage.

Vì sao đúng

Đề nêu bốn đặc điểm, và chúng cùng chỉ về lưu trữ đối tượng:

⚠ Bốn đặc điểm ↔ Cloud Storage:

1. HÀNG PETABYTE ẢNH VÀ VIDEO
     → ⚠ dữ liệu PHI CẤU TRÚC
     → đúng định nghĩa "object storage"

2. ĐỘ BỀN RẤT CAO
     → ⚠ 11 số chín (99,999999999%)
       độ bền hằng năm

3. SẴN SÀNG TOÀN CẦU
     → bucket đa vùng, phục vụ
       qua mạng biên của Google

4. HIẾM KHI TRUY CẬP
     → ⚠ chọn lớp Nearline / Coldline
       / Archive cho rẻ

⚠ Ba kiểu lưu trữ — phân biệt cho rõ:

OBJECT STORAGE (Cloud Storage)
    → ⚠ TỆP nguyên khối + metadata
    → truy cập qua API/HTTP theo tên
    → không sửa một phần tệp
    → ⚠ ảnh, video, sao lưu, dữ liệu thô

BLOCK STORAGE (Persistent Disk)
    → đĩa gắn vào máy ảo

FILE STORAGE (Filestore)
    → hệ thống tệp NFS chia sẻ

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

CLOUD SQL / SPANNER
    → ⚠ CSDL QUAN HỆ — lưu HÀNG và CỘT
    → nhét video vào cột BLOB là
      cực kỳ đắt và chậm

BIGQUERY
    → kho PHÂN TÍCH cho dữ liệu
      có cấu trúc
    → ⚠ không phải nơi lưu tệp media
        ↓
    Mẫu đúng: LƯU TỆP ở Cloud Storage,
    lưu ĐƯỜNG DẪN trong CSDL

Xem thêm #13249 và #13140 (cùng lô này) — về chọn lớp lưu trữ và quy tắc vòng đời. Với "hàng petabyte, hiếm khi truy cập" của đề này, câu trả lời đầy đủ là Cloud Storage + lớp Nearline/Coldline + quy tắc vòng đời.

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

• D (BigQuery) — phương án gần nhất về mặt "quy mô petabyte", nhưng BigQuery là kho phân tích cho dữ liệu có cấu trúc. Nó phân tích metadata của video rất tốt, nhưng không phải nơi lưu chính các tệp video.

• A (Cloud SQL) — CSDL quan hệ, có trần dung lượng và không thiết kế để lưu tệp lớn.

• C (Cloud Spanner) — CSDL quan hệ toàn cầu, rất đắt và hoàn toàn sai mục đích cho việc lưu media.

Ghi nhớ

⚠ Ba kiểu lưu trữ — bảng phải thuộc: | Kiểu | Sản phẩm | Dùng cho | |---|---|---| | Object | Cloud Storage | ảnh, video, sao lưu, dữ liệu thô | | Block | Persistent Disk, Hyperdisk | đĩa của máy ảo | | File | Filestore | NFS chia sẻ giữa nhiều máy |

Từ khoá nhận diện:

"ảnh, video, tệp, phi cấu trúc, petabyte" → Cloud Storage "đĩa gắn vào VM" → Persistent Disk "nhiều máy cùng đọc một thư mục" → Filestore "phân tích dữ liệu có cấu trúc" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bucket nào đang công khai không | ⚠ Security Command Center hoặc kiểm IAM | | Dữ liệu đang ở lớp nào | Storage Insights | | Chi phí đi ra bao nhiêu | billing report — SKU network egress |

Và một khoản chi phí thường gây bất ngờ nhất với nội dung media: phí truyền dữ liệu đi ra, chứ không phải phí lưu trữ. Hàng petabyte ảnh và video nằm yên thì rẻ, nhưng mỗi lần chúng được tải về từ khắp nơi trên thế giới lại là một dòng trong hoá đơn — và đó chính là lý do Cloud CDN gần như luôn nên đứng phía trước.

Đáp án

B — Tăng tính linh hoạt và giảm rủi ro bị khoá chân vào một nhà cung cấp (vendor lock-in).

Vì sao đúng

Kubernetes là ví dụ điển hình: Google phát triển rồi mở mã nguồn, và chính điều đó tạo ra lợi ích kinh doanh mà đề hỏi.

⚠ Vì sao chuẩn mở đem lại tự do:

Ứng dụng đóng gói theo chuẩn
Kubernetes / container
        ↓
    Chạy được trên:
      - GKE (Google Cloud)
      - EKS (AWS)
      - AKS (Azure)
      - cụm tự dựng TẠI CHỖ
        ↓
    ⚠ Cùng một tệp cấu hình
    ⚠ Cùng một kỹ năng của đội
        ↓
    → Chuyển đi được nếu cần
    → ⚠ Và chính vì CHUYỂN ĐƯỢC,
      vị thế đàm phán của bạn mạnh hơn

⚠ Khoá chân nhà cung cấp là gì:

Dùng dịch vụ ĐỘC QUYỀN
sâu tới mức không rời đi được
        ↓
    ⚠ Chi phí chuyển đổi quá lớn
    ⚠ Phải viết lại ứng dụng
    ⚠ Phải đào tạo lại cả đội
        ↓
    → Mất quyền thương lượng giá
    → Phụ thuộc vào lộ trình sản phẩm
      của một công ty

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

"ĐẢM BẢO chi phí thấp nhất"
    → ⚠ chuẩn mở KHÔNG hứa gì về giá
    → có khi còn tốn hơn vì phải
      tự vận hành nhiều thứ

"ĐẢM BẢO công nghệ không bao giờ
 bị ngừng hỗ trợ"
    → ⚠ dự án mã nguồn mở
      VẪN có thể chết
    → chỉ khác là bạn có thể fork

"Truy cập VẬT LÝ vào phần cứng"
    → ⚠ không liên quan gì tới
      chuẩn mở, và trong đám mây
      công cộng thì không ai có

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

• A (đảm bảo chi phí thấp nhất) — phương án gần nhất về mặt "nghe như lợi ích kinh doanh", nhưng chuẩn mở không hứa hẹn gì về giá. Nó cho lựa chọn, và lựa chọn có thể dẫn tới giá tốt hơn — đó là hệ quả gián tiếp, không phải bảo đảm.

• C (công nghệ không bao giờ bị ngừng hỗ trợ) — không có gì bảo đảm điều đó. Rất nhiều dự án mã nguồn mở đã bị bỏ rơi; ưu điểm thật là mã nguồn vẫn còn đó để cộng đồng tiếp quản.

• D (truy cập vật lý vào phần cứng) — không liên quan, và trái với bản chất đám mây công cộng.

Ghi nhớ

⚠ Năm trụ cột chuyển đổi của Google Cloud — bảng nên thuộc: | Trụ cột | Nội dung | |---|---| | Freedom (tự do) | ⚠ mã nguồn mở, đa đám mây, không bị khoá chân | | Sustainability | năng lượng tái tạo, báo cáo carbon | | Intelligence | dữ liệu và AI | | Collaboration | Workspace | | Trust / Security | bảo mật nhiều lớp |

Từ khoá nhận diện:

"chuẩn mở, Kubernetes, tránh khoá chân" → Freedom / tính linh hoạt "chạy được ở nhiều nhà cung cấp" → portability "dùng nhiều đám mây cùng lúc" → multi-cloud "tại chỗ + đám mây" → hybrid cloud

Ba câu hỏi kiểm chứng cho một tổ chức: | Câu hỏi | Vì sao | |---|---| | Nếu phải rời đi, mất bao lâu? | ước lượng thật, không phỏng đoán | | Dữ liệu có ở định dạng mở không? | | | Đội có kỹ năng chuyển đi được không? | Kubernetes, SQL, Python |

Và một cách nhìn cân bằng về khoá chân đáng mang theo: mục tiêu không phải là tránh nó hoàn toàn, mà là biết mình đang trả giá bao nhiêu cho nó. Một dịch vụ độc quyền giúp đội bạn ra sản phẩm nhanh gấp đôi thường là một đổi chác xứng đáng — miễn là quyết định ấy được đưa ra một cách có ý thức chứ không phải phát hiện ra sau ba năm.

Đáp án

D — Cấp cho kiểm toán viên vai "Viewer" dựng sẵn của IAM.

Vì sao đúng

Đề mô tả đúng bài toán mà nguyên tắc quyền tối thiểu (least privilege) và các vai dựng sẵn của IAM giải quyết: xem được mọi cấu hình, không sửa được gì.

⚠ Ba vai cơ bản của IAM:

VIEWER   → ⚠ CHỈ ĐỌC
             xem tài nguyên và cấu hình
             KHÔNG sửa, KHÔNG xoá
                  ← đúng đề này

EDITOR   → xem + SỬA + tạo + xoá
             ⚠ quá rộng cho kiểm toán

OWNER    → mọi quyền của Editor
             + ⚠ QUẢN LÝ QUYỀN
             + quản lý thanh toán
             ⚠ tuyệt đối không cấp
               cho người ngoài

⚠ Nguyên tắc quyền tối thiểu:

Chỉ cấp ĐÚNG quyền cần thiết
để làm ĐÚNG việc được giao
        ↓
    Kiểm toán viên cần XEM
        ↓
    → cấp quyền XEM
    → ⚠ không cấp thêm một chút nào
        ↓
    Lợi ích:
    ⚠ tài khoản bị chiếm cũng
      không gây hại được nhiều
    ⚠ không có nguy cơ sửa nhầm

⚠ Còn chặt hơn nữa nếu muốn:

Viewer là vai CƠ BẢN — khá rộng
        ↓
    Chặt hơn: dùng VAI DỰNG SẴN
    hẹp theo dịch vụ, ví dụ
      roles/iam.securityReviewer
      roles/logging.viewer
        ↓
    Hoặc VAI TUỲ BIẾN
    liệt kê đúng từng quyền
        ↓
    ⚠ Google khuyến nghị dùng vai
      DỰNG SẴN hơn là ba vai cơ bản

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

• C (cấp vai Project Owner) — phương án "tiện nhất" và là bẫy chính: kiểm toán viên sẽ xem được mọi thứ, nhưng cũng sửa và xoá được mọi thứ, kể cả cấp quyền cho người khác. Vi phạm nghiêm trọng nguyên tắc quyền tối thiểu.

• A (đưa bản sao hoá đơn hằng tháng) — hoá đơn không phải cấu hình tài nguyên. Không đáp ứng yêu cầu.

• B (đặt tài khoản kiểm toán viên vào một máy ảo) — câu này không có nghĩa về mặt kỹ thuật; IAM không hoạt động như vậy.

Ghi nhớ

⚠ Ba loại vai của IAM — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | Vai cơ bản (basic) | Owner / Editor / Viewer — rất rộng, ⚠ Google khuyên hạn chế dùng | | Vai dựng sẵn (predefined) | ⚠ theo từng dịch vụ, hẹp hơn — NÊN dùng | | Vai tuỳ biến (custom) | tự chọn từng quyền — hẹp nhất, tốn công bảo trì |

Từ khoá nhận diện:

"chỉ xem, không sửa" → Viewer "quyền tối thiểu" → vai dựng sẵn hẹp nhất đủ dùng "kiểm toán, tuân thủ" → Security Reviewer, Logs Viewer "ai đã làm gì" → Cloud Audit Logs

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang có quyền gì | trang IAM, hoặc gcloud projects get-iam-policy | | Có ai quyền quá rộng không | IAM Recommender | | Người ngoài đã xem những gì | Cloud Audit Logs — Data Access |

Và một việc rất nên đặt lịch nhắc ngay khi cấp quyền cho người ngoài: ngày gỡ quyền. Quyền được cấp cho một cuộc kiểm toán kéo dài hai tuần rất hay ở lại vĩnh viễn, đơn giản vì không ai chịu trách nhiệm nhớ ra rằng công việc đó đã kết thúc.

Đáp án

D — Apigee API Management.

Vì sao đúng

Đề nêu bốn yêu cầu, và cả bốn đều là chức năng lõi của một nền tảng quản lý API đầy đủ như Apigee.

⚠ Bốn yêu cầu ↔ Apigee:

1. MỞ dịch vụ nội bộ ra cho ĐỐI TÁC
     → Apigee làm lớp mặt tiền,
       che kiến trúc bên trong

2. QUẢN LÝ TRUY CẬP an toàn
     → API key, OAuth 2.0, JWT
     → mỗi đối tác một danh tính

3. ÁP HẠN NGẠCH sử dụng
     → ⚠ quota theo từng đối tác,
       theo gói dịch vụ

4. PHÂN TÍCH cách API được dùng
     → ⚠ bảng điều khiển: ai gọi,
       gọi bao nhiêu, lỗi ra sao

⚠ Apigee đứng ở đâu:

Đối tác (đại lý du lịch, khách sạn)
              ↓
        ⚠ APIGEE
   ┌──────────────────────┐
   │ xác thực             │
   │ hạn ngạch, rate limit│
   │ biến đổi dữ liệu     │
   │ ghi nhận, phân tích  │
   │ phiên bản API        │
   └──────────────────────┘
              ↓
Dịch vụ nội bộ (chuyến bay, đặt chỗ,
                khách hàng thân thiết)
        ↓
    ⚠ Dịch vụ nội bộ KHÔNG cần biết
      gì về đối tác

⚠ Vì sao mục tiêu "tạo doanh thu" quan trọng ở đây:

Đề nói: "tạo nguồn doanh thu mới"
        ↓
    → API trở thành SẢN PHẨM
        ↓
    Cần: cổng cho lập trình viên,
         gói dịch vụ, hạn ngạch theo gói,
         số liệu để tính tiền
        ↓
    ⚠ Đây chính là "API là sản phẩm"
      — thế mạnh riêng của Apigee

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

• C (Cloud Endpoints) — phương án gần nhất: nó cũng quản lý API, có xác thực và hạn ngạch cơ bản. Nhưng nó nhẹ hơn nhiều, hướng tới API nội bộ hoặc dự án nhỏ; nó không có cổng lập trình viên, không có gói sản phẩm API, không có phân tích thương mại như Apigee.

• A (Cloud Load Balancing) — phân phối lưu lượng, không quản lý API: không xác thực đối tác, không hạn ngạch, không phân tích cách API được dùng.

• B (GKE) — nơi chạy các dịch vụ. Không phải lớp quản lý API đứng trước chúng.

Ghi nhớ

⚠ Ba lựa chọn quản lý API trên Google Cloud — bảng phải thuộc: | Sản phẩm | Dùng khi | |---|---| | Apigee | ⚠ API là SẢN PHẨM — đối tác bên ngoài, kiếm tiền, phân tích sâu | | API Gateway | API serverless, nhẹ, cho Cloud Run / Functions | | Cloud Endpoints | API nội bộ, nhẹ, gắn với ESP | | Cloud Load Balancing | chỉ phân phối lưu lượng |

Từ khoá nhận diện:

"đối tác bên ngoài, hạn ngạch, doanh thu, phân tích" → Apigee "API nội bộ đơn giản, serverless" → API Gateway "chống DDoS, WAF" → Cloud Armor "chỉ chia lưu lượng tới backend" → Load Balancing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tác nào gọi nhiều nhất | bảng phân tích của Apigee | | Có ai vượt hạn ngạch không | báo cáo quota | | Backend có chịu nổi không | ⚠ đặt rate limit TRƯỚC khi mở cho đối tác |

Và một lời khuyên về sản phẩm nhiều hơn về kỹ thuật: hãy thiết kế API như thiết kế một sản phẩm cho người dùng. Đối tác sẽ đánh giá bạn qua chất lượng tài liệu, sự ổn định của phiên bản và thời gian cần để gọi thành công lần đầu — chứ không qua kiến trúc microservice phía sau mà họ không bao giờ nhìn thấy.

Đáp án

A — Tốc độ và sự dễ dùng, đổi lấy tính độc đáo và mức kiểm soát.

Vì sao đúng

Đây là đánh đổi cơ bản nhất khi chọn giải pháp AI, và đề mô tả đúng hai đầu của trục: từ dịch văn bản đơn giản tới hệ phát hiện gian lận độc quyền phức tạp.

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

API DỰNG SẴN
    ✔ dùng được trong VÀI GIỜ
    ✔ không cần dữ liệu huấn luyện
    ✔ không cần chuyên gia ML
    ✔ không phải vận hành mô hình
        ↓
    ⚠ nhưng: ai cũng dùng được
      cùng một mô hình đó
    ⚠ không tuỳ biến được
    ⚠ KHÔNG tạo ra khác biệt cạnh tranh

MÔ HÌNH TUỲ BIẾN
    ⚠ mất hàng tháng
    ⚠ cần dữ liệu, cần chuyên gia
    ⚠ phải tự vận hành, giám sát
        ↓
    ✔ nhưng: học trên dữ liệu
      RIÊNG của bạn
    ✔ toàn quyền chọn kiến trúc
    ✔ ⚠ ĐỘC QUYỀN — đối thủ
      không sao chép được

⚠ Áp vào hai ví dụ của đề:

DỊCH VĂN BẢN cho ứng dụng di động
    → việc phổ quát
    → không ai thắng cuộc nhờ
      dịch tốt hơn một chút
    → ⚠ API dựng sẵn

PHÁT HIỆN GIAN LẬN ĐỘC QUYỀN
    → mẫu gian lận riêng của
      chính doanh nghiệp này
    → ⚠ đây LÀ lợi thế cạnh tranh
    → mô hình tuỳ biến

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

"CHI PHÍ vs BẢO MẬT"
    → ⚠ cả hai lựa chọn đều
      bảo mật như nhau trên Google Cloud
    → không phải trục quyết định

"TOÀN CẦU vs THEO VÙNG"
    → cả hai đều triển khai
      ở nhiều vùng được

"DỮ LIỆU CÓ CẤU TRÚC vs PHI CẤU TRÚC"
    → ⚠ cả API sẵn lẫn mô hình tuỳ biến
      đều làm việc được với cả hai

Nhất quán với #13251 và #13259 (lô 138) — cùng nói về ba mức giải pháp AI. Câu này hỏi bản chất của đánh đổi, hai câu kia hỏi chọn mức nào cho tình huống cụ thể.

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

• B (chi phí vs bảo mật) — phương án gần nhất về mặt "nghe như đánh đổi", nhưng bảo mật không là thứ bạn phải hi sinh khi chọn API dựng sẵn; cả hai đều chạy trên cùng hạ tầng bảo mật.

• C (sẵn sàng toàn cầu vs theo vùng) — không phải trục phân biệt giữa hai lựa chọn.

• D (dữ liệu có cấu trúc vs phi cấu trúc) — cả hai hướng đều xử lý được cả hai loại dữ liệu.

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Công sức | Kiểm soát | Ví dụ | |---|---|---|---| | API dựng sẵn | thấp nhất | thấp nhất | Translation, Vision, Speech | | AutoML | trung bình | trung bình | Vertex AI AutoML | | Mô hình tuỳ biến | cao nhất | cao nhất | Vertex AI custom training |

Từ khoá nhận diện:

"nhanh, dễ, không cần chuyên gia" → API dựng sẵn "dữ liệu riêng nhưng không viết mã" → AutoML "độc quyền, khác biệt cạnh tranh, kiểm soát kiến trúc" → tuỳ biến "sinh nội dung, chatbot" → Gemini / mô hình nền

Ba câu hỏi kiểm chứng: | Câu hỏi | Nếu... | |---|---| | API sẵn đã đủ tốt chưa | thử trước, đo trước | | Có đủ dữ liệu chất lượng không | không → chưa nên tuỳ biến | | Có người nuôi mô hình lâu dài không | không → đừng bắt đầu |

Và một sai lầm rất tốn kém mà nhiều tổ chức mắc phải: xây mô hình riêng cho những việc chẳng ai quan tâm ai làm tốt hơn. Không khách hàng nào chọn hãng hàng không vì bản dịch tiếng Anh của họ mượt hơn — nhưng họ sẽ rời đi nếu hệ phát hiện gian lận để lọt giao dịch giả, và đó mới là chỗ đáng đổ công sức vào.

Đáp án

A — Google Cloud Carbon Footprint.

Vì sao đúng

Đề phân biệt rất rõ hai chuyện: chạy trên đám mây sạch (điều Google đã lo) và ĐO ĐƯỢC phát thải của chính mình (điều doanh nghiệp cần công cụ). Carbon Footprint là công cụ cho vế thứ hai.

⚠ Carbon Footprint cho ra cái gì:

Phát thải carbon gộp (gross emissions)
gắn với mức dùng Google Cloud của bạn
        ↓
    Bóc tách theo:
      - PROJECT
      - DỊCH VỤ (Compute, BigQuery...)
      - VÙNG
      - THÁNG
        ↓
    ⚠ Xuất được sang BigQuery
    ⚠ Đưa thẳng vào báo cáo ESG
    ⚠ MIỄN PHÍ

⚠ Vì sao "đo được" mới là điều họ cần:

Google đã khớp 100% điện tiêu thụ
với năng lượng tái tạo từ 2017
        ↓
    ⚠ Nhưng doanh nghiệp vẫn phải
      TỰ BÁO CÁO con số của mình
        ↓
    Cam kết công khai đòi:
      - số liệu định lượng
      - theo dõi được xu hướng
      - kiểm chứng được
        ↓
    → cần một CÔNG CỤ ĐO,
      không chỉ cần một lời hứa
      của nhà cung cấp

⚠ Ba phương án kia làm việc khác:

ACTIVE ASSIST
    → ⚠ GỢI Ý tối ưu: máy nằm không,
      quyền quá rộng
    → giúp GIẢM gián tiếp,
      nhưng KHÔNG ĐO carbon

RESOURCE HIERARCHY
    → tổ chức → thư mục → project
    → cấu trúc quản trị, không đo gì

CLOUD BILLING REPORTS
    → ⚠ đo TIỀN, không đo CARBON
    → hai con số liên quan nhưng
      KHÔNG thay thế nhau

Bổ sung cho câu #13262 (lô 138) — câu đó hỏi lợi ích chuyển đổi nào phù hợp (Sustainability); câu này hỏi sản phẩm nào thực hiện việc đo. Hai câu nhất quán và ghép thành một câu trả lời đầy đủ.

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

• D (Cloud Billing Reports) — phương án gần nhất: chi phí và phát thải có tương quan, và giảm cái này thường giảm cái kia. Nhưng báo cáo thanh toán đo tiền, không đo khí thải — hai vùng có cùng giá nhưng phát thải rất khác nhau.

• B (Active Assist) — đưa gợi ý tối ưu hoá, giúp giảm lãng phí. Hữu ích nhưng không phải công cụ đo và báo cáo phát thải.

• C (phân cấp tài nguyên) — cách tổ chức tài nguyên. Nó giúp bóc tách số liệu theo đơn vị, nhưng bản thân không tạo ra số liệu carbon nào.

Ghi nhớ

⚠ Công cụ bền vững của Google Cloud — bảng phải thuộc: | Công cụ | Việc | |---|---| | Carbon Footprint | ⚠ ĐO và BÁO CÁO phát thải theo project/dịch vụ/vùng | | Huy hiệu vùng phát thải thấp | ⚠ hiện ngay khi chọn vùng | | Active Assist / Recommender | tìm tài nguyên lãng phí | | Region Picker | cân nhắc giá, độ trễ và carbon | | Billing export | phân tích chi phí, ghép với carbon |

Từ khoá nhận diện:

"đo và báo cáo phát thải của mình" → Carbon Footprint "chọn vùng sạch hơn" → huy hiệu lá cây / Region Picker "tìm tài nguyên nằm không" → Active Assist "lợi ích chuyển đổi nào" → Sustainability

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang phát thải bao nhiêu | báo cáo Carbon Footprint theo tháng | | Dự án nào phát thải nhiều nhất | bóc tách theo project | | Xu hướng đi lên hay xuống | xuất sang BigQuery, vẽ theo thời gian |

Và một điểm đáng lưu ý về con số mà Carbon Footprint đưa ra: nó là phát thải gộp (gross), chưa trừ phần bù đắp bằng năng lượng tái tạo mà Google mua. Đó là cách trình bày trung thực và cũng là con số mà các khung báo cáo ESG yêu cầu — nên đừng ngạc nhiên khi thấy nó khác với thông điệp "100% năng lượng tái tạo".

Đáp án

A — Platform as a Service (PaaS).

Vì sao đúng

Đề mô tả chính xác lằn ranh của PaaS: bạn lo mã, nhà cung cấp lo mọi thứ bên dưới.

⚠ Ai lo gì — ba mô hình:

             IaaS      PaaS      SaaS
Ứng dụng      BẠN      BẠN       nhà c.cấp
Dữ liệu       BẠN      BẠN       nhà c.cấp
Runtime       BẠN     n.c.cấp    n.c.cấp
Middleware    BẠN     n.c.cấp    n.c.cấp
Hệ điều hành  BẠN     n.c.cấp    n.c.cấp
Ảo hoá       n.c.cấp  n.c.cấp    n.c.cấp
Máy chủ      n.c.cấp  n.c.cấp    n.c.cấp
Mạng, lưu trữ n.c.cấp n.c.cấp    n.c.cấp
        ↓
    ⚠ Đề nói: không muốn quản
      HỆ ĐIỀU HÀNH, BẢN VÁ, RUNTIME
      → đúng ranh giới PaaS

⚠ Ba yêu cầu của đề ↔ PaaS:

1. "TRIỂN KHAI NHANH NHẤT CÓ THỂ"
     → đẩy mã lên là chạy

2. "ĐỘI NHỎ, KHÔNG CÓ CHUYÊN MÔN
    quản hệ điều hành và bản vá"
     → ⚠ PaaS lo toàn bộ tầng đó

3. "CHỈ MUỐN TẬP TRUNG VIẾT MÃ"
     → ⚠ đây là câu định nghĩa PaaS

⚠ Vì sao IaaS không hợp:

IaaS (Compute Engine)
    → bạn nhận một MÁY ẢO TRỐNG
        ↓
    ⚠ Tự cài hệ điều hành
    ⚠ Tự vá bảo mật hằng tháng
    ⚠ Tự cài runtime, web server
    ⚠ Tự cấu hình tự mở rộng
        ↓
    → đúng những việc đội này
      nói là KHÔNG muốn làm

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

• B (IaaS) — phương án gần nhất và là bẫy chính: nó linh hoạt nhất, nhưng để đổi lại, bạn phải quản hệ điều hành và bản vá — đúng thứ đề nói họ không muốn.

• D (SaaS) — bạn dùng phần mềm có sẵn (Gmail, Salesforce), không viết mã ứng dụng của riêng mình. Nhưng đề nói họ đang XÂY một ứng dụng web mới.

• C (tại chỗ — on-premises) — phải tự lo mọi thứ, kể cả phần cứng. Trái ngược hoàn toàn.

Ghi nhớ

⚠ Ba mô hình dịch vụ đám mây — bảng phải thuộc: | Mô hình | Bạn quản | Ví dụ Google Cloud | |---|---|---| | IaaS | hệ điều hành trở lên | Compute Engine | | PaaS | ⚠ CHỈ mã và dữ liệu | App Engine, Cloud Run | | SaaS | ⚠ không gì cả — chỉ dùng | Google Workspace |

Từ khoá nhận diện:

"chỉ muốn viết mã, không quản máy chủ" → PaaS "cần kiểm soát hệ điều hành, phần mềm cũ" → IaaS "dùng phần mềm có sẵn" → SaaS "không quản máy chủ VÀ co về 0" → serverless

Ba câu hỏi kiểm chứng: | Câu hỏi | Nếu... | |---|---| | Có ai trong đội muốn vá hệ điều hành không? | không → PaaS | | Ứng dụng có đòi hỏi gì đặc biệt ở tầng OS không? | không → PaaS | | Có cần chạy liên tục không? | không → serverless, co về 0 |

Và một quan sát thực tế đáng nhớ với các đội nhỏ: công việc vận hành hạ tầng không bao giờ giảm đi theo thời gian. Máy chủ tự quản cần vá bảo mật mỗi tháng, cần theo dõi, cần người trực — và với một đội năm người, đó là phần thời gian đáng lẽ dành cho việc làm sản phẩm khác biệt với đối thủ.

Đáp án

C — Dùng AutoML Vision.

Vì sao đúng

Đề đặt nhóm này đúng vào giữa thang giải pháp AI: họ có dữ liệu riêng đã gán nhãn, có đội dữ liệu giỏi, nhưng không muốn viết mã mô hình từ đầu.

⚠ Bốn manh mối ↔ AutoML:

1. "DỮ LIỆU ẢNH RIÊNG, đã gán nhãn
    theo danh mục cụ thể"
     → ⚠ nhãn riêng: "bốt leo núi nam",
       "sandal dạ hội nữ"
     → mô hình chung của Google
       KHÔNG có những nhãn này

2. "TỐI ƯU CHO DANH MỤC SẢN PHẨM
    ĐỘC ĐÁO của họ"
     → cần huấn luyện trên dữ liệu của họ

3. "ĐẨY NHANH quá trình phát triển"
     → không đủ thời gian làm từ đầu

4. ⚠ "KHÔNG viết mã mô hình từ đầu"
     → loại thẳng phương án TensorFlow

⚠ AutoML Vision làm gì cho họ:

Tải ảnh đã gán nhãn lên
        ↓
    AutoML tự:
      - chọn kiến trúc mạng
      - tìm siêu tham số tối ưu
      - chia train / validation / test
      - áp dụng transfer learning
        ↓
    ⚠ Đội dữ liệu vẫn kiểm soát:
      chất lượng nhãn, tập dữ liệu,
      đọc chỉ số đánh giá,
      quyết định triển khai
        ↓
    → nhanh hơn nhiều, mà vẫn
      là mô hình RIÊNG của họ

⚠ Vì sao Vision API dựng sẵn không đủ:

Vision API trả về nhãn CHUNG:
    "shoe", "footwear", "boot"
        ↓
    ⚠ KHÔNG phân biệt được
      "bốt leo núi nam" với
      "bốt thời trang nam"
        ↓
    Danh mục thương mại là
    thứ riêng của từng doanh nghiệp
        ↓
    → phải huấn luyện trên
      dữ liệu của chính họ

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

• A (viết mô hình tuỳ biến từ đầu bằng TensorFlow) — phương án gần nhất về mặt "mô hình riêng", và họ có đội đủ giỏi để làm. Nhưng đề nói rõ họ muốn đẩy nhanh và KHÔNG viết mã mô hình từ đầu — chính lời văn của phương án này mâu thuẫn với yêu cầu.

• D (Vision API dựng sẵn) — không huấn luyện trên danh mục riêng được, chỉ trả nhãn chung.

• B (BigQuery ML) — dùng SQL để huấn luyện mô hình trên dữ liệu bảng biểu. Không phải công cụ cho phân loại ảnh.

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 | nhãn PHỔ QUÁT, không cần dữ liệu riêng | | AutoML | ⚠ nhãn RIÊNG + không muốn viết mã mô hình | | Tuỳ biến | cần kiểm soát kiến trúc, là khác biệt cạnh tranh |

Từ khoá nhận diện:

"danh mục riêng, nhãn riêng, không viết mã mô hình" → AutoML "nhận diện vật thể thông thường" → Vision API "dữ liệu bảng biểu + SQL" → BigQuery ML "tự chọn kiến trúc mạng" → TensorFlow / custom training

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình có tốt hơn Vision API không | ⚠ đo trên cùng tập kiểm tra | | Nhãn nào yếu nhất | ma trận nhầm lẫn | | Có đủ dữ liệu chưa | thử tăng dữ liệu xem chỉ số có cải thiện |

Và một điều rất đáng làm trước khi bắt đầu bất kỳ dự án AutoML nào: thử API dựng sẵn trước và đo kết quả. Đôi khi mô hình chung đã đủ tốt cho phần lớn ảnh, và bạn chỉ cần AutoML cho một nhóm danh mục khó — biết được điều đó sớm sẽ tiết kiệm rất nhiều công gán nhãn.