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

Đáp án

D — Tốc độ và sự dễ dùng, đổi lấy tính đặc thù và độc đáo.

Vì sao đúng

Đây là trục đánh đổi cơ bản giữa hai lựa chọn, và nó quyết định mọi quyết định về AI trên đám mây.

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

MÔ HÌNH DỰNG SẴN (pre-trained)
    ✔ ⚠ 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 chung
      một mô hình đó
    ⚠ không tuỳ biến được
    ⚠ ⚠ KHÔNG tạo khác biệt
      cạnh tranh

MÔ HÌNH TUỲ BIẾN (custom)
    ⚠ mất hàng tuần tới hàng tháng
    ⚠ cần dữ liệu và 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 ĐÁO — đối thủ không
      sao chép được

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

"Hỗ trợ PYTHON vs hỗ trợ JAVA"
    → ⚠ không phải trục phân biệt

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

"CHI PHÍ vs BẢO MẬT"
    → ⚠ cả hai đều bảo mật như nhau
      trên Google Cloud
    → bảo mật KHÔNG phải thứ
      phải hi sinh

⚠ Gần trùng với #13270 (lô 139) — đề đó cũng hỏi đánh đổi giữa API dựng sẵn và mô hình tuỳ biến, và cùng khoá "tốc độ/dễ dùng vs độc đáo/kiểm soát". Hoàn toàn nhất quán.

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

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

• A (hỗ trợ Python vs Java) — không phải trục phân biệt.

• B (toàn cầu vs theo vùng) — cả hai đều triển khai được ở nhiều vùng.

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Công sức | Độc đáo | 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 | | Tuỳ biến | ⚠ cao nhất | ⚠ cao nhất | Vertex AI custom training |

Từ khoá nhận diện:

"nhanh, phổ quát, không chuyên gia" → API dựng sẵn "dữ liệu riêng, không viết mã mô hình" → AutoML "độc đáo, lợi thế cạnh tranh, kiểm soát kiến trúc" → tuỳ biến "dữ liệu bảng, biết SQL" → BigQuery ML

Ba câu hỏi kiểm chứng: | Câu hỏi | Nếu... | |---|---| | API sẵn đã đủ tốt chưa | ⚠ thử và ĐO trước khi tự xây | | Có đủ dữ liệu chất lượng không | không → chưa nên tuỳ biến | | Ai nuôi mô hình sau khi ra mắt | không có ai → đừ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: đổ công sức lớn nhất vào phần không ai quan tâm ai làm tốt hơn. Không khách hàng nào chọn nhà cung cấp vì bản dịch của họ mượt hơn — nhưng họ sẽ rời đi nếu hệ thống lõi hoạt động kém, và đó mới là chỗ đáng đầu tư một mô hình riêng.

Đáp án

D — Nó biến dữ liệu phức tạp thành biểu đồ và bảng điều khiển dễ hiểu, giúp ra quyết định nhanh hơn và hiệu quả hơn.

Vì sao đúng

Giá trị kinh doanh của một công cụ BI nằm ở việc rút ngắn khoảng cách giữa dữ liệu và quyết định.

⚠ Chuỗi giá trị:

Dữ liệu thô trong BigQuery
        ↓
    ⚠ Hàng tỉ dòng, cần SQL
      mới đọc được
        ↓
LOOKER
    ⚠ mô hình hoá bằng LookML
    ⚠ người dùng kéo thả
    ⚠ biểu đồ và dashboard
        ↓
    ⚠ Lãnh đạo NHÌN là hiểu
        ↓
    → quyết định NHANH HƠN

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

"TỰ ĐỘNG SỬA mọi lỗi trong
 dữ liệu nguồn"
    → ⚠ Looker mô hình hoá,
      KHÔNG làm sạch
    → làm sạch là việc của
      Dataform, Dataflow, Dataprep

"THAY THẾ nhu cầu có kho dữ liệu
 như BigQuery"
    → ⚠ NGƯỢC LẠI: Looker CẦN
      BigQuery
    → nó không lưu dữ liệu

"Làm dữ liệu thô AN TOÀN HƠN"
    → ⚠ bảo mật là việc của IAM,
      policy tag, VPC SC
    → (Looker CÓ access filter,
       nhưng đó không phải giá trị
       chính)

⚠ Gần trùng với #13450, #13437 (lô 142) và #13261 (lô 138) — cả bốn đề đều về Looker cho BI tự phục vụ. Câu này hỏi giá trị kinh doanh. Hoàn toàn nhất quán.

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

• C (làm dữ liệu thô an toàn hơn) — phương án gần nhất về mặt "cũng là lợi ích có phần đúng": Looker có access filter và phân quyền. Nhưng bảo mật dữ liệu là việc của IAM, policy tag, VPC Service Controls, không phải giá trị chính của công cụ BI.

• A (tự động sửa mọi lỗi trong dữ liệu) — Looker mô hình hoá, không làm sạch.

• B (thay thế nhu cầu có BigQuery) — ngược lại: Looker truy vấn thẳng trên BigQuery và cần nó.

Ghi nhớ

⚠ Giá trị của Looker — bảng nên thuộc: | Giá trị | Nội dung | |---|---| | ⚠ Trực quan hoá | ⚠ biến dữ liệu phức tạp thành biểu đồ dễ hiểu | | ⚠ Tự phục vụ | người dùng nghiệp vụ tự làm, không cần SQL | | ⚠ Một nguồn sự thật | ⚠ LookML — định nghĩa chỉ số tập trung | | Không sao chép dữ liệu | truy vấn thẳng trên kho | | Nhúng được | đưa dashboard vào sản phẩm | | Quản trị | access filter, Content Validator |

Từ khoá nhận diện:

"biểu đồ dễ hiểu, ra quyết định nhanh" → giá trị của Looker "chỉ số tính không nhất quán" → ⚠ LookML / một nguồn sự thật "làm sạch dữ liệu" → Dataform, Dataflow, Dataprep "bảo mật dữ liệu" → IAM, policy tag

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lãnh đạo có tự dùng được không | ⚠ quan sát một người trong 15 phút đầu | | Ba đội hỏi cùng câu có ra cùng số không | phép thử của mô hình chung | | Chi phí truy vấn bao nhiêu | BigQuery job history |

Và một điều quyết định giá trị thật của mọi dashboard: có ai ra quyết định khác đi nhờ nó không. Một bảng điều khiển đẹp mà không ai thay đổi hành động sau khi xem chỉ là một báo cáo tự động hoá — giá trị kinh doanh nằm ở quyết định, không ở biểu đồ.

Đáp án

C — Bằng cách cho phép doanh nghiệp trả tiền cho tài nguyên tính toán như một tiện ích theo mức tiêu dùng, định kỳ, thay vì mua phần cứng trả trước.

Vì sao đúng

Đề hỏi cơ chế của việc chuyển CapEx sang OpEx, và đáp án mô tả đúng: trả theo mức dùng thay vì mua tài sản.

⚠ Cơ chế chuyển đổi:

CapEx (mua phần cứng)
    → ⚠ trả trước một cục
    → ghi nhận là TÀI SẢN
    → khấu hao 3–5 năm
        ↓
OpEx (thuê theo mức dùng)
    → ⚠ trả định kỳ theo lượng dùng
    → ghi nhận là CHI PHÍ trong kỳ
    → ⚠ như hoá đơn điện nước

⚠ Ví von "tiện ích" rất sát:

Điện nước
    → ⚠ không mua nhà máy điện
    → dùng bao nhiêu trả bấy nhiêu
    → có công tơ đo
        ↓
Đám mây
    → ⚠ không mua máy chủ
    → dùng bao nhiêu giờ CPU,
      bao nhiêu GB lưu trữ
      thì trả bấy nhiêu
    → ⚠ có billing report làm công tơ

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

"Bắt mua TẤT CẢ máy chủ vào
 đầu năm"
    → ⚠ đó chính là mô hình CapEx cũ

"Thu phí MỘT LẦN cho quyền dùng
 TRỌN ĐỜI mọi dịch vụ"
    → ⚠ không đám mây nào bán
      kiểu đó

"Làm mọi tài nguyên CNTT
 MIỄN PHÍ"
    → ⚠ vô lý

⚠ Gần trùng với #13471 (cùng lô này) — cùng chủ đề CapEx → OpEx. Câu kia hỏi thay đổi là gì, câu này hỏi bằng cách nào. Hoàn toàn nhất quán.

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

• A (bắt mua tất cả máy chủ vào đầu năm) — phương án gần nhất về mặt "cũng nói về mua sắm", nhưng đó chính là mô hình CapEx cũ mà đám mây thay thế.

• B (thu phí một lần cho quyền dùng trọn đời) — không có mô hình nào như vậy.

• D (làm mọi tài nguyên miễn phí) — vô lý.

Ghi nhớ

⚠ CapEx và OpEx — bảng phải thuộc: | | CapEx | OpEx | |---|---|---| | Nghĩa | chi phí VỐN | chi phí VẬN HÀNH | | Ví dụ | mua máy chủ, xây trung tâm dữ liệu | ⚠ hoá đơn đám mây hằng tháng | | Trả tiền | trước, một cục | ⚠ theo mức tiêu dùng | | Kế toán | tài sản, khấu hao | chi phí trong kỳ | | ⚠ Lên đám mây | CapEx → OpEx |

Từ khoá nhận diện:

"trả theo mức dùng như tiện ích" → OpEx "mua phần cứng trả trước" → CapEx "tổng chi phí sở hữu" → TCO "cam kết dài hạn để giảm giá" → CUD

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí có bám theo mức dùng không | billing report theo ngày | | Có tài nguyên nào chạy mà không ai dùng không | Recommender | | Có nên mua CUD chưa | ⚠ chỉ khi tải đã ổn định vài tháng |

Và một điều nên làm ngay khi chuyển sang mô hình tiêu dùng: đặt ngân sách và cảnh báo trước khi tạo tài nguyên đầu tiên. Mô hình "dùng bao nhiêu trả bấy nhiêu" rất công bằng, nhưng nó cũng có nghĩa là không có trần tự nhiên nào — và trần duy nhất là thứ bạn tự đặt ra.

Đáp án

C — Nhu cầu tăng tính linh hoạt để đáp ứng kỳ vọng thay đổi của khách hàng và các mối đe doạ cạnh tranh.

Vì sao đúng

Đây là hai lực đẩy chính của chuyển đổi số, và cả hai đều nằm ngoài tầm kiểm soát của doanh nghiệp.

⚠ Hai lực đẩy:

⚠ KỲ VỌNG KHÁCH HÀNG THAY ĐỔI
    → khách so trải nghiệm của bạn
      với MỌI dịch vụ họ dùng
    → ⚠ chuẩn mực đã dời đi

⚠ ĐỐI THỦ NHANH NHẸN
    → startup cloud-native ra
      tính năng hằng tuần
    → ⚠ không chờ ai
        ↓
    → cần TÍNH LINH HOẠT (agility)

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

"Mong muốn TĂNG chi tiêu cho
 phần cứng và bảo trì trung tâm
 dữ liệu"
    → ⚠ NGƯỢC — đó là thứ chuyển
      đổi số muốn giảm

"GIỮ NGUYÊN vị thế thị trường,
 không thay đổi gì"
    → ⚠ ngược với khái niệm
      chuyển đổi

"GIẢM số lượng tương tác với
 khách hàng"
    → ⚠ ngược lại: chuyển đổi số
      thường TĂNG số điểm chạm
      với khách

⚠ Gần trùng với #13398 (lô 141) — đề đó cũng hỏi động lực chuyển đổi số và cùng khoá "áp lực từ đối thủ và kỳ vọng khách hàng". Hoàn toàn nhất quán. Cũng liên quan #13382 và #13414 (lô 141) về rủi ro và thay đổi tư duy.

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

• B (giữ nguyên vị thế thị trường, không thay đổi gì) — phương án gần nhất về mặt "cũng là một mục tiêu kinh doanh", nhưng nó ngược hẳn với khái niệm chuyển đổi.

• A (tăng chi tiêu cho phần cứng) — chuyển đổi số thường giảm khoản này.

• D (giảm số lượng tương tác với khách hàng) — ngược lại; thường tăng số điểm chạm số.

Ghi nhớ

⚠ Các động lực của chuyển đổi số — bảng nên thuộc: | Động lực | Nội dung | |---|---| | ⚠ Áp lực cạnh tranh | đối thủ cloud-native nhanh hơn | | ⚠ Kỳ vọng khách hàng | ⚠ so với trải nghiệm số tốt nhất họ từng dùng | | Áp lực chi phí | hạ tầng cũ đắt và kém hiệu quả | | Quy định mới | báo cáo, bảo mật, dữ liệu | | Cơ hội từ dữ liệu và AI | mô hình kinh doanh mới | | Thu hút nhân tài | ⚠ kỹ sư muốn làm công nghệ hiện đại |

Từ khoá nhận diện:

"đối thủ nhanh hơn, khách kỳ vọng cao hơn" → động lực chuyển đổi "mất thị phần vì chậm" → rủi ro của việc không chuyển đổi "ra tính năng nhanh, thử nghiệm rẻ" → agility "coi công nghệ là đòn bẩy chiến lược" → thay đổi tư duy căn bản

Ba câu hỏi kiểm chứng cho một tổ chức: | Câu hỏi | Vì sao | |---|---| | Khách mất bao lâu để làm việc họ cần | ⚠ thước đo thật của trải nghiệm | | Đối thủ làm việc đó trong bao lâu | | | Bao nhiêu bước trong quy trình còn thủ công | |

Và một điều đáng nhớ về áp lực mà mọi tổ chức truyền thống đang chịu: khách hàng không so sánh bạn với đối thủ cùng ngành. Họ so trải nghiệm với lần gần nhất họ đặt xe hay chuyển khoản — và chuẩn mực đó không bao giờ quay lại mức cũ.

Đáp án

C — Đội đã vi phạm SLO và giờ phải ưu tiên cải thiện độ tin cậy và ổn định.

Vì sao đúng

SLO là 99,9% nhưng thực tế chỉ đạt 99,8% — nghĩa là ngân sách lỗi đã cạn và vượt mức.

⚠ Phép tính:

SLO         = 99,9%
Thực tế     = 99,8%
        ↓
    ⚠ THẤP HƠN mục tiêu
        ↓
    Ngân sách lỗi cho phép: 0,1%
    Thực tế đã tiêu:        0,2%
        ↓
    ⚠ TIÊU GẤP ĐÔI ngân sách
        ↓
    → ĐÓNG BĂNG tính năng,
      tập trung vào độ tin cậy

⚠ Chênh lệch 0,1% nghe nhỏ nhưng:

99,9%  → ⚠ ~43 phút ngừng/tháng
99,8%  → ⚠ ~87 phút ngừng/tháng
        ↓
    ⚠ GẤP ĐÔI thời gian ngừng
        ↓
    → "chỉ lệch 0,1%" là cách
      hiểu sai nguy hiểm

⚠ Quy tắc error budget:

CÒN ngân sách
    → ⚠ được phép triển khai
      tính năng mới

⚠ HẾT ngân sách
    → ⚠ ĐÓNG BĂNG tính năng
    → cả đội chuyển sang làm
      độ tin cậy
        ↓
    ⚠ Quy tắc này phải được
      thống nhất TỪ TRƯỚC

⚠ Vì sao KHÔNG nên hạ SLO xuống 99,8%:

"Đạt không nổi thì hạ mục tiêu"
        ↓
    ⚠ Đây là phản ứng sai
    ⚠ SLO phải dựa trên NHU CẦU
      NGƯỜI DÙNG, không dựa trên
      năng lực hiện tại
        ↓
    ⚠ Chỉ hạ SLO khi có bằng chứng
      người dùng KHÔNG cần mức đó

Liên quan #13449 (lô 142) về error budget, và #13353 (lô 140) về SLO. Câu này là tình huống áp dụng quy tắc. Cả ba nhất quán.

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

• D (hạ SLO xuống 99,8%) — phương án gần nhất về mặt "cũng là một hành động có thể làm", và đôi khi hợp lý nếu có bằng chứng. Nhưng hạ mục tiêu chỉ vì không đạt được là né tránh vấn đề, không phải giải pháp.

• B (đã đạt SLO thành công) — sai về số học: 99,8% thấp hơn 99,9%.

• A (tập trung ra tính năng mới vì dịch vụ đủ tin cậy) — ngược lại: hết ngân sách lỗi thì phải dừng tính năng.

Ghi nhớ

⚠ Bốn khái niệm SRE — bảng phải thuộc: | Khái niệm | Là gì | |---|---| | SLI | CHỈ SỐ đo được | | SLO | ⚠ MỤC TIÊU nội bộ | | 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:

"không đạt SLO" → ⚠ đóng băng tính năng, ưu tiên độ tin cậy "còn nhiều ngân sách lỗi" → ⚠ được phép mạo hiểm hơn "cam kết có bồi thường" → SLA "chỉ số được đo" → SLI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bao nhiêu ngân sách lỗi | ⚠ Cloud Monitoring SLO dashboard | | Nguyên nhân tiêu ngân sách là gì | rà sự cố trong tháng | | Quy tắc đóng băng có được tôn trọng không | ⚠ phép thử của cam kết tổ chức |

Và điều khó nhất khi áp dụng error budget không phải là tính toán mà là kỷ luật thực hiện. Quy tắc "hết ngân sách thì dừng phát hành" chỉ có giá trị nếu đội sản phẩm thật sự dừng lại — và đó là lúc cam kết được thoả thuận từ trước phải chứng minh mình có thật.

Đáp án

D — Service Level Agreement (SLA).

Vì sao đúng

Cụm quyết định trong đề là "thoả thuận CHÍNH THỨC" kèm "CHẾ TÀI nếu không đạt" — đó chính là SLA.

⚠ Ba khái niệm, ba vai:

SLI — Service Level Indicator
    → ⚠ CHỈ SỐ được đo

SLO — Service Level Objective
    → ⚠ MỤC TIÊU NỘI BỘ
    → ⚠ KHÔNG có chế tài

⚠ SLA — Service Level Agreement
    → ⚠ HỢP ĐỒNG chính thức
    → ⚠ CÓ CHẾ TÀI / bồi thường
    → đề này

⚠ Hai dấu hiệu nhận diện SLA:

1. ⚠ "THOẢ THUẬN CHÍNH THỨC
    với bên nghiệp vụ"
     → là hợp đồng, không phải
       mục tiêu nội bộ

2. ⚠ "chịu CHẾ TÀI nếu không đạt"
     → ⚠ chỉ SLA mới có hậu quả
       ràng buộc

⚠ SLO luôn chặt hơn SLA:

SLA với bên nghiệp vụ: 99,95%
SLO nội bộ:            ⚠ 99,99%
        ↓
    ⚠ Chừa BIÊN AN TOÀN
        ↓
    Vi phạm SLO → ⚠ đội biết trước
      và có thời gian xử lý
    Vi phạm SLA → ⚠ chịu chế tài
        ↓
    → SLO là hệ thống cảnh báo sớm
      cho SLA

⚠ Đối chiếu #13353 (lô 140) khoá SLO (mục tiêu nội bộ), #13442 (lô 142) khoá SLI (chỉ số đo), #13449 (lô 142) khoá error budget. Câu này khoá SLA. Bốn câu tạo thành bộ đầy đủ, không mâu thuẫn.

Cách phân biệt: thấy "chế tài, bồi thường, hợp đồng" → SLA. Thấy "mục tiêu nội bộ" → SLO. Thấy "chỉ số được đo" → SLI.

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

• B (SLO) — phương án gần nhất và là bẫy chính: SLO cũng là một mức dịch vụ mục tiêu, nhưng nó là cam kết NỘI BỘ và không có chế tài. Đề nói rõ có hình phạt.

• C (SLI) — là chỉ số được đo, không phải thoả thuận.

• A (Error budget) — là phần được phép hỏng, tính từ SLO; không phải thoả thuận có chế tài.

Ghi nhớ

⚠ Bốn khái niệm SRE — bảng phải thuộc: | Khái niệm | Là gì | Có chế tài? | |---|---|---| | SLI | ⚠ CHỈ SỐ đo được | không | | SLO | ⚠ MỤC TIÊU nội bộ | ⚠ KHÔNG | | ⚠ SLA | ⚠ HỢP ĐỒNG chính thức | ⚠ CÓ — bồi thường/chế tài | | Error budget | 100% − SLO | không |

Từ khoá nhận diện:

"hợp đồng, chế tài, bồi thường" → ⚠ SLA "mục tiêu nội bộ" → SLO "chỉ số được đo" → SLI "phần được phép hỏng" → error budget

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SLA có thấp hơn SLO không | ⚠ nếu bằng nhau thì không có biên an toàn | | SLA có cao hơn SLA của Google không | ⚠ nếu có thì bất khả thi | | Cách đo đã ghi rõ trong hợp đồng chưa | tránh tranh cãi sau này |

Và một sai lầm rất tốn kém khi ký SLA: hứa mức cao hơn thứ hạ tầng bên dưới đảm bảo. Nếu ứng dụng của bạn phụ thuộc vào ba dịch vụ mỗi dịch vụ cam kết 99,95%, thì mức khả thi tối đa của bạn đã thấp hơn con số đó — và không nỗ lực vận hành nào bù được phép nhân xác suất.

Đáp án

B — Đảm bảo mô hình CÔNG BẰNG và KHÔNG phân biệt đối xử với người nộp hồ sơ dựa trên các đặc điểm được bảo vệ.

Vì sao đúng

Duyệt hồ sơ vay là quyết định ảnh hưởng trực tiếp tới cơ hội của con người, nên công bằng là khía cạnh quan trọng nhất của AI có trách nhiệm ở đây.

⚠ Vì sao rủi ro thiên lệch rất cao:

Dữ liệu cho vay quá khứ
        ↓
    ⚠ Phản ánh cả những quyết định
      thiếu công bằng trong quá khứ
        ↓
    Mô hình học: "hồ sơ như thế này
    thường bị từ chối"
        ↓
    ⚠ Học luôn cả ĐỊNH KIẾN
        ↓
    ⚠ Áp dụng ở QUY MÔ LỚN,
      NHẤT QUÁN, TỰ ĐỘNG
        ↓
    → thiên lệch được KHUẾCH ĐẠI

⚠ Vì sao "bỏ cột nhạy cảm" KHÔNG đủ:

Xoá giới tính, dân tộc khỏi dữ liệu
        ↓
    ⚠ Mô hình vẫn suy ra được từ
      ĐẶC TRƯNG ĐẠI DIỆN (proxy):
      - mã bưu chính
      - trường học
      - tên riêng
      - lịch sử việc làm
        ↓
    → phải KIỂM TRA KẾT QUẢ
      theo từng nhóm

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

"Duyệt CÀNG NHIỀU hồ sơ CÀNG TỐT
 để tối đa doanh thu"
    → ⚠ vô trách nhiệm về tín dụng
    → tăng rủi ro nợ xấu

"Dùng thuật toán PHỨC TẠP NHẤT
 kể cả khi KHÔNG GIẢI THÍCH ĐƯỢC"
    → ⚠ NGƯỢC với AI có trách nhiệm
    → ⚠ cho vay là ngành BẮT BUỘC
      phải giải thích được quyết định

"Huấn luyện chỉ trên dữ liệu của
 MỘT NHÓM NHÂN KHẨU"
    → ⚠ đây chính là cách TẠO RA
      thiên lệch

⚠ Gần trùng với #13433 (lô 142) — đề đó về mô hình sàng lọc hồ sơ tuyển dụng học từ dữ liệu có định kiến, và cùng khoá "khuếch đại thiên lệch". Và #13306 (lô 139) về explainability trong cho vay. Cả ba nhất quán.

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

• C (dùng thuật toán phức tạp nhất kể cả không giải thích được) — phương án gần nhất về mặt "cũng nói về chất lượng mô hình", nhưng ngược hẳn với AI có trách nhiệm: ngành cho vay bắt buộc phải giải thích được lý do từ chối.

• A (duyệt càng nhiều càng tốt) — vô trách nhiệm về mặt tín dụng và tăng rủi ro nợ xấu.

• D (huấn luyện chỉ trên một nhóm nhân khẩu) — chính là cách tạo ra thiên lệch.

Ghi nhớ

⚠ Bảy nguyên tắc AI của Google — bảng nên thuộc: | Nguyên tắc | Nội dung | |---|---| | Có lợi cho xã hội | | | ⚠ Tránh tạo hoặc củng cố THIÊN LỆCH bất công | ⚠ đề này | | Được xây và kiểm thử an toàn | | | ⚠ Chịu trách nhiệm trước con người | ⚠ có người giám sát | | Tôn trọng quyền riêng tư | | | Giữ chuẩn mực khoa học cao | | | Chỉ dùng cho mục đích phù hợp | |

Từ khoá nhận diện:

"dữ liệu lịch sử có định kiến" → rủi ro thiên lệch, công bằng "phải nêu lý do cho quyết định" → explainability "dữ liệu bẩn" → dự đoán không đáng tin "có người xem lại" → human oversight

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số theo từng nhóm ra sao | ⚠ không chỉ nhìn accuracy tổng | | Có đặc trưng đại diện nào không | rà mã bưu chính, tên trường | | Giải thích được quyết định không | ⚠ thử với một hồ sơ bị từ chối thật |

Và một nguyên tắc đáng giữ với mọi mô hình ảnh hưởng tới cơ hội của con người: mô hình học từ quá khứ, còn công bằng là điều bạn phải chủ động thiết kế vào hiện tại. Không thuật toán nào tự sửa được một tập dữ liệu ghi lại những quyết định thiếu công bằng của nhiều năm trước.

Đáp án

B — Đặt các project phát triển và kiểm thử vào một Folder "Non-Production".

Vì sao đúng

Đề đòi áp một bộ chính sách chung cho nhiều project CÙNG LÚC — đó chính xác là lý do folder tồn tại.

⚠ Cấu trúc đúng:

        ORGANIZATION
              │
    ┌─────────┴─────────┐
 FOLDER              FOLDER
Non-Production      Production
    │                    │
 ┌──┴──┐              projects
dev   test
        ↓
    ⚠ Chính sách đặt ở folder
      LAN XUỐNG mọi project bên trong
    ⚠ Project dev MỚI tự động
      kế thừa

⚠ Đặt gì ở folder Non-Production:

⚠ VAI IAM
    → lập trình viên có quyền
      rộng hơn ở đây

⚠ ORGANIZATION POLICY
    → thoáng hơn prod
    → nhưng vẫn cấm những thứ
      nguy hiểm

⚠ QUOTA thấp
    → chặn tiêu hoang

⚠ NGÂN SÁCH riêng
    → biết dev tốn bao nhiêu

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

"Cho MỌI lập trình viên vai
 PROJECT OWNER trên MỌI project"
    → ⚠ vi phạm nghiêm trọng
      quyền tối thiểu
    → ⚠ Owner cấp quyền được
      cho người khác

"Dùng NETWORK TAG để liên kết
 project"
    → ⚠ network tag áp cho MÁY ẢO
      trong luật tường lửa
    → ⚠ KHÔNG nhóm project được

"Tạo TÀI KHOẢN THANH TOÁN RIÊNG
 cho MỖI project"
    → ⚠ tách được chi phí nhưng
      KHÔNG áp được chính sách
    → thêm rất nhiều việc quản trị

⚠ Gần trùng với #13448 (lô 142), #13305 (lô 140) và #13279 (lô 140) — cả bốn đề đều là nhóm project để áp chính sách chung, và cả bốn cùng khoá Folders. Hoàn toàn nhất quán.

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

• D (tạo tài khoản thanh toán riêng cho mỗi project) — phương án gần nhất về mặt "cũng là một cách tách biệt", nhưng nó tách chi phí chứ không áp được chính sách IAM, và tạo rất nhiều việc quản trị.

• A (cho mọi lập trình viên vai Project Owner) — vi phạm nghiêm trọng nguyên tắc quyền tối thiểu.

• C (dùng network tag) — network tag dùng cho luật tường lửa trên máy ảo, không nhóm project.

Ghi nhớ

⚠ Phân cấp tài nguyên — bảng phải thuộc: | Cấp | Vai trò | |---|---| | Organization | gốc, chính sách toàn công ty | | ⚠ Folder | ⚠ nhóm project, áp IAM và Policy chung, LỒNG được | | Project | ⚠ ranh giới TÍNH TIỀN, quota, API | | Resource | VM, bucket, dataset | | ⚠ Quy tắc | chính sách LAN XUỐNG, không lan lên |

Từ khoá nhận diện:

"nhóm project, áp chính sách chung" → Folder "bóc tách chi phí theo đội" → ⚠ Label "cấm hành vi ở mọi nơi" → Organization Policy "chặn cứng số tài nguyên" → Quota

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cây tổ chức hiện ra sao | trang Manage resources | | Chính sách nào áp cho từng folder | tab Organization Policies | | Project mới có kế thừa đúng không | ⚠ tạo thử một project |

Và một ranh giới nên thiết lập trước khi hệ thống lớn lên: dev và prod phải nằm ở hai folder khác nhau, với hai bộ chính sách khác nhau. Nó cho phép đội phát triển làm việc thoải mái ở một bên mà không nới lỏng bất cứ điều gì ở bên còn lại.

Đáp án

D — Batch processing (xử lý theo lô).

Vì sao đúng

Đề mô tả đúng đặc trưng của xử lý theo lô: chạy một tập tính toán trên một tập dữ liệu HỮU HẠN, song song trên cụm máy, để lấy kết quả nhanh hơn.

⚠ Ba manh mối ↔ batch:

1. ⚠ "một TẬP DỮ LIỆU LỚN"
     → ⚠ dữ liệu HỮU HẠN, biết trước
       điểm đầu và điểm cuối

2. "chạy SONG SONG trên một CỤM MÁY"
     → chia nhỏ, xử lý đồng thời

3. "để lấy kết quả NHANH HƠN"
     → ⚠ mục tiêu là THÔNG LƯỢNG,
       không phải độ trễ tức thời

⚠ Batch và streaming:

XỬ LÝ THEO LÔ (batch)
    → ⚠ dữ liệu HỮU HẠN
    → chạy khi được kích hoạt
      hoặc theo lịch
    → ⚠ độ trễ: phút tới giờ
    → ⚠ đề này

XỬ LÝ LUỒNG (streaming)
    → ⚠ dữ liệu VÔ HẠN
    → xử lý ngay khi đến
    → độ trễ: giây

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

TRANSACTIONAL PROCESSING (OLTP)
    → ⚠ nhiều thao tác NHỎ,
      độ trễ mili-giây
    → đặt hàng, thanh toán

STREAMING PROCESSING
    → ⚠ dữ liệu đến LIÊN TỤC,
      vô hạn
    → đề nói "một tập dữ liệu lớn"
      → hữu hạn

MANUAL PROCESSING
    → ⚠ không phải khái niệm
      kỹ thuật, và đề nói rõ là
      chạy SCRIPT tự động

⚠ Đối chiếu #13379 (lô 141) — đề đó hỏi khác biệt giữa lô và luồng và nhấn rằng luồng xử lý liên tục còn lô xử lý theo khối rời rạc. Hoàn toàn nhất quán.

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

• B (streaming processing) — phương án gần nhất và là bẫy chính: cả hai đều xử lý dữ liệu quy mô lớn. Nhưng streaming làm việc với luồng VÔ HẠN đến liên tục, còn đề nói rõ là một tập dữ liệu lớn — hữu hạn.

• A (transactional processing) — nhiều thao tác nhỏ với độ trễ mili-giây; sai hoàn toàn loại.

• C (manual processing) — không phải khái niệm kỹ thuật, và đề nói rõ là chạy script tự động.

Ghi nhớ

⚠ Lô và luồng — bảng phải thuộc: | | Batch | Streaming | |---|---|---| | Dữ liệu | ⚠ HỮU HẠN | ⚠ VÔ HẠN | | Thời điểm | theo lịch hoặc kích hoạt | liên tục | | Độ trễ | phút tới giờ | giây | | Chi phí | ⚠ thường RẺ HƠN | cao hơn | | Hợp với | ⚠ báo cáo, ETL đêm, tính toán lớn | cảnh báo, IoT, gian lận |

Từ khoá nhận diện:

"tập dữ liệu lớn, chạy song song, kết quả nhanh hơn" → batch "liên tục, thời gian thực, vô hạn" → streaming "đặt hàng, thanh toán" → OLTP / transactional "xử lý cả lô lẫn luồng bằng một mã" → ⚠ Dataflow (Apache Beam)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần thời gian thực không | ⚠ nếu không → batch rẻ hơn | | Cụm có nhàn rỗi không | ⚠ so thời gian cụm sống với thời gian chạy job | | Có dùng Spot VM chưa | job lô rất hợp |

Và một câu hỏi nên đặt trước khi dựng bất kỳ pipeline thời gian thực nào: "kết quả chậm một giờ thì có ai bị ảnh hưởng không?". Nếu câu trả lời là không, thì xử lý theo lô đơn giản hơn, rẻ hơn và dễ chạy lại hơn — và đó là lựa chọn đúng cho phần lớn bài toán phân tích.

Đáp án

A — Tự do tránh bị khoá chân nhà cung cấp nhờ dùng các công nghệ mã nguồn mở như Kubernetes.

Vì sao đúng

Freedom là một trong các trụ cột chuyển đổi mà Google Cloud nêu ra, và nội dung của nó là tính di động và quyền lựa chọn.

⚠ Vì sao mã nguồn mở đem lại tự do:

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

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

"Tự do TIÊU KHÔNG GIỚI HẠN"
    → ⚠ không phải lợi ích,
      và là điều cần KIỂM SOÁT

"Tự do khỏi MỌI trách nhiệm
 bảo mật"
    → ⚠ SAI: mô hình trách nhiệm
      CHUNG — khách vẫn lo dữ liệu,
      IAM và cấu hình

"Tự do BỎ QUA mọi quy định
 tuân thủ"
    → ⚠ SAI và nguy hiểm

⚠ Gần trùng với #13267 (lô 139) và #13374 (lô 141) — cả ba đề đều về chuẩn mở giúp tránh khoá chân, và cả ba cùng khoá. Hoàn toàn nhất quán.

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

• C (tự do khỏi mọi trách nhiệm bảo mật) — phương án gần nhất về mặt "nghe như lợi ích của đám mây", nhưng sai hoàn toàn: theo mô hình trách nhiệm chung, khách hàng vẫn lo dữ liệu, IAM và cấu hình.

• B (tiêu không giới hạn) — không phải lợi ích; chi phí là thứ cần kiểm soát.

• D (bỏ qua quy định tuân thủ) — sai và nguy hiểm.

Ghi nhớ

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

Từ khoá nhận diện:

"chuẩn mở, tránh khoá chân" → Freedom "dữ liệu và AI" → Intelligence "bảo mật và tuân thủ" → Trust "cộng tác, họp" → People connections

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao | |---|---| | Nếu phải rời đi, mất bao lâu | ⚠ ước lượng thật | | 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: mục tiêu không phải tránh nó hoàn toàn mà là biết mình đang trả giá bao nhiêu. Dùng BigQuery gắn bạn với Google Cloud, nhưng nếu nó giúp đội bạn phân tích nhanh gấp năm lần thì đó thường là đổi chác xứng đáng — miễn là quyết định ấy được đưa ra một cách tỉnh táo.