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

Đáp án

C — Phần mềm có mã nguồn được công khai, ai cũng có thể tự do sử dụng, sửa đổi và chia sẻ.

Vì sao đúng

Đây là định nghĩa chuẩn của phần mềm mã nguồn mở: điểm mấu chốt là mã nguồn công khai và giấy phép cho phép dùng, sửa, chia sẻ.

⚠ Bốn quyền tự do cơ bản:

⚠ CHẠY chương trình cho mục đích nào
⚠ NGHIÊN CỨU cách nó hoạt động
   (cần mã nguồn công khai)
⚠ CHIA SẺ lại cho người khác
⚠ SỬA ĐỔI và phát hành bản đã sửa
        ↓
    ⚠ Được bảo đảm bằng GIẤY PHÉP,
      không phải bằng việc miễn phí

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

"LUÔN an toàn hơn phần mềm
 độc quyền"
    → ⚠ SAI: nhiều mắt nhìn CÓ THỂ
      giúp phát hiện lỗi, nhưng
      ⚠ KHÔNG đảm bảo
    → dự án ít người bảo trì
      có thể rất rủi ro

"Bán theo giấy phép RẤT HẠN CHẾ"
    → ⚠ ngược hẳn định nghĩa

"CHỈ chạy được trên nền tảng
 Google Cloud"
    → ⚠ ngược lại: chạy được
      MỌI NƠI chính là điểm mạnh

⚠ Mã nguồn mở ≠ miễn phí:

⚠ "Free" trong "free software"
  nghĩa là TỰ DO, không phải
  MIỄN PHÍ
        ↓
    Nhiều phần mềm mở có:
      - bản thương mại có hỗ trợ
      - dịch vụ có quản lý trả phí
        ↓
    Ví dụ: ⚠ Kubernetes miễn phí,
    nhưng GKE là dịch vụ TRẢ TIỀN

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

• A (luôn an toàn hơn phần mềm độc quyền) — phương án gần nhất về mặt "nghe như một ưu điểm thật": việc mã công khai có thể giúp phát hiện lỗi. Nhưng chữ "LUÔN" làm nó sai — một dự án ít người bảo trì có thể chứa lỗ hổng nhiều năm mà không ai để ý.

• B (bán theo giấy phép rất hạn chế) — ngược hẳn định nghĩa.

• D (chỉ chạy trên Google Cloud) — ngược lại; tính di động là điểm mạnh chính.

Ghi nhớ

⚠ Mã nguồn mở — bảng nên thuộc: | Điểm | Nội dung | |---|---| | Mã nguồn công khai | ⚠ ai cũng đọc được | | Giấy phép cho phép | ⚠ dùng, sửa, chia sẻ | | ⚠ Không đồng nghĩa MIỄN PHÍ | ⚠ "free" = tự do | | Không đồng nghĩa an toàn hơn | tuỳ dự án | | Chạy được nhiều nơi | ⚠ giảm khoá chân |

Từ khoá nhận diện:

"mã công khai, tự do dùng và sửa" → mã nguồn mở "tránh khoá chân nhờ chuẩn mở" → trụ cột Freedom "Kubernetes, TensorFlow" → công nghệ mở của Google "chạy được ở nhiều đám mây" → portability

Ba việc kiểm chứng khi dùng thư viện mở: | Việc | Cách | |---|---| | Dự án còn được bảo trì không | ⚠ xem commit gần nhất và số người đóng góp | | Giấy phép có phù hợp không | ⚠ GPL có thể ràng buộc mã của bạn | | Có lỗ hổng đã biết không | Artifact Analysis, SCA |

Và một hiểu lầm phổ biến đáng đính chính: mã nguồn mở không tự động an toàn hơn. "Nhiều mắt nhìn thì lỗi lộ ra" chỉ đúng khi thật sự có nhiều mắt nhìn — còn một thư viện quan trọng do một người duy trì trong lúc rảnh thì rủi ro không hề nhỏ hơn phần mềm thương mại.

Đáp án

D — Admin Activity Logs.

Vì sao đúng

Đề hỏi nhật ký của các thay đổi QUẢN TRỊ — tạo máy ảo, sửa luật tường lửa — và đó là đúng phạm vi của Admin Activity Logs.

⚠ Bốn loại audit log:

⚠ ADMIN ACTIVITY
    → ⚠ ghi mọi thay đổi CẤU HÌNH
      và QUYỀN
    → tạo/xoá VM, sửa firewall,
      đổi IAM
    → ⚠ LUÔN bật, MIỄN PHÍ,
      KHÔNG tắt được
    → ⚠ đề này

DATA ACCESS
    → ⚠ ghi lượt ĐỌC và GHI DỮ LIỆU
    → ⚠ phải BẬT, có phí

SYSTEM EVENT
    → hành động do HỆ THỐNG GOOGLE
      thực hiện (ví dụ live migration)

POLICY DENIED
    → truy cập bị chính sách từ chối

⚠ Phân biệt hai loại hay lẫn nhất:

⚠ ADMIN ACTIVITY
    → "AI đã TẠO cái bảng này?"
    → "AI đã đổi luật tường lửa?"
    → ⚠ thay đổi CẤU HÌNH

⚠ DATA ACCESS
    → "AI đã ĐỌC dữ liệu trong
      bảng này?"
    → ⚠ truy cập NỘI DUNG

⚠ Đối chiếu #13431 (lô 142) — đề đó về ghi lại truy cập DỮ LIỆU nhạy cảm trong BigQuery, và giải thích nhấn mạnh phải BẬT Data Access log. Câu này về thay đổi cấu hình, thuộc Admin Activity. Không mâu thuẫn — hai loại log khác nhau trong cùng một dịch vụ.

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

• B (Data Access Logs) — phương án gần nhất và là bẫy chính: nó ghi lượt đọc/ghi DỮ LIỆU, không phải thay đổi cấu hình. Ngoài ra nó không bật mặc định và có phí.

• A (System Event Logs) — ghi hành động do hệ thống Google thực hiện, không phải do quản trị viên.

• C (Policy Denied Logs) — ghi các lần truy cập bị chính sách từ chối.

Ghi nhớ

⚠ Bốn loại audit log — bảng phải thuộc: | Loại | Bật sẵn? | Ghi gì | |---|---|---| | ⚠ Admin Activity | ⚠ LUÔN bật, miễn phí | ⚠ thay đổi CẤU HÌNH và QUYỀN | | ⚠ Data Access | ⚠ PHẢI bật, có phí | ⚠ đọc và ghi DỮ LIỆU | | System Event | luôn bật | hành động của hệ thống Google | | Policy Denied | luôn bật | truy cập bị từ chối |

Từ khoá nhận diện:

"ai đã tạo/sửa/xoá tài nguyên" → ⚠ Admin Activity "ai đã đọc dữ liệu" → ⚠ Data Access "tìm lỗi ứng dụng" → application log trong Cloud Logging "biểu đồ và cảnh báo" → Cloud Monitoring

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đã đổi cấu hình gần đây | ⚠ Logs Explorer, lọc Admin Activity | | Data Access log đã bật chưa | IAM & Admin → Audit Logs | | Log có bị xoá được không | ⚠ kiểm quyền trên project chứa log |

Và một cảnh báo đáng đặt cho mọi tổ chức: thông báo mỗi khi có người được gán vai Owner hoặc Organization Admin. Đó là loại thay đổi hiếm khi xảy ra một cách bình thường, và một log-based metric trên Admin Activity là cách rẻ nhất để không bao giờ bỏ lỡ nó.

Đáp án

A — Thúc đẩy sự cộng tác và trách nhiệm chung giữa các đội.

Vì sao đúng

Đề mô tả đúng vấn đề silo mà DevOps sinh ra để giải, và nguyên tắc cốt lõi là hợp nhất các đội bằng cộng tác và trách nhiệm chung.

⚠ Vấn đề trong đề:

Đội phát triển, bảo mật, vận hành
làm việc TÁCH BIỆT
        ↓
    ⚠ Triển khai chậm
    ⚠ Xung đột giữa các bên
        ↓
    Gốc rễ: ⚠ ĐỘNG CƠ NGƯỢC NHAU
      dev thưởng vì ra nhanh
      ops thưởng vì ổn định
      security thưởng vì không sự cố

⚠ DevOps giải bằng gì:

⚠ CỘNG TÁC
    → làm việc cùng nhau từ đầu,
      không bàn giao qua tường

⚠ TRÁCH NHIỆM CHUNG
    → "you build it, you run it"
    → ⚠ đội viết mã cũng trực sự cố

⚠ TỰ ĐỘNG HOÁ
    → CI/CD, hạ tầng dưới dạng mã

⚠ VĂN HOÁ KHÔNG QUY TỘI
    → mổ xẻ sự cố để sửa hệ thống

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

"TĂNG số bước DUYỆT THỦ CÔNG"
    → ⚠ NGƯỢC: DevOps giảm bước
      thủ công bằng tự động hoá

"Giao TOÀN BỘ việc bảo mật cho
 đội PHÁT TRIỂN"
    → ⚠ đó không phải cộng tác,
      chỉ là ĐẨY việc sang đội khác
    → DevSecOps là CHIA SẺ trách nhiệm

"Mỗi đội dùng BỘ CÔNG CỤ RIÊNG"
    → ⚠ ngược với việc phá silo

⚠ Gần trùng với #13321 (lô 140) và #13439 (lô 142) — cả ba đề đều mô tả cảnh silo và cùng khoá DevOps. Và #13415 (lô 141) về năm mục tiêu của DevOps. Cả bốn nhất quán.

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

• C (giao toàn bộ việc bảo mật cho đội phát triển) — phương án gần nhất về mặt "nghe như DevSecOps", nhưng đẩy việc sang đội khác không phải cộng tác. DevSecOps là chia sẻ trách nhiệm với công cụ tự động hỗ trợ, không phải chuyển gánh nặng.

• B (tăng số bước duyệt thủ công) — ngược với mục tiêu tự động hoá.

• D (mỗi đội dùng bộ công cụ riêng) — ngược với việc phá bỏ silo.

Ghi nhớ

⚠ Năm mục tiêu của DevOps — bảng phải thuộc: | Mục tiêu | Nội dung | |---|---| | ⚠ Giảm silo | ⚠ cộng tác và trách nhiệm chung — đề này | | Chấp nhận thất bại là bình thường | blameless postmortem | | Thay đổi dần và thường xuyên | triển khai nhỏ, nhiều lần | | Tận dụng công cụ và tự động hoá | CI/CD, IaC | | Đo lường mọi thứ | chỉ số DORA |

Từ khoá nhận diện:

"cộng tác, trách nhiệm chung, phá silo" → DevOps "SLO, error budget, do Google khởi xướng" → SRE "bảo mật tự động trong CI/CD" → DevSecOps "không tin ai theo mặc định" → zero trust

Ba câu hỏi kiểm chứng cho một tổ chức: | Câu hỏi | Vì sao | |---|---| | Bao lâu triển khai một lần | ⚠ hằng quý là dấu hiệu xấu | | Ai bị gọi lúc 3 giờ sáng | ⚠ nếu chỉ đội vận hành thì bức tường vẫn còn | | Đội bảo mật tham gia từ lúc nào | ⚠ cuối dự án hay từ đầu |

Và một phép thử rất thẳng cho biết cộng tác đã thật hay chưa: hỏi xem đội bảo mật tham gia vào dự án từ giai đoạn nào. Nếu họ chỉ xuất hiện ở buổi rà soát cuối cùng trước khi phát hành, thì silo vẫn còn nguyên — chỉ là nó đã được đổi tên thành "quy trình duyệt".

Đáp án

B — Tạo hoặc tìm một vai có quyền TẠO instance nhưng KHÔNG có quyền XOÁ chúng.

Vì sao đúng

Đề đòi phân quyền ở mức thao tác: cho phép một hành động, cấm một hành động khác — đúng tinh thần quyền tối thiểu.

⚠ IAM hoạt động ở mức QUYỀN (permission):

Mỗi vai = một TẬP HỢP quyền
        ↓
    `compute.instances.create`
    `compute.instances.delete`
    `compute.instances.get`
    `compute.instances.list`
        ↓
    ⚠ Chọn vai có `create`
      nhưng KHÔNG có `delete`
        ↓
    → nếu không vai dựng sẵn nào
      khớp, tạo ⚠ VAI TUỲ BIẾN

⚠ Quy trình chọn vai đúng:

1. ⚠ Liệt kê chính xác việc
   người đó cần làm
        ↓
2. ⚠ Tìm VAI DỰNG SẴN gần nhất
        ↓
3. Nếu vẫn quá rộng
        ↓
4. ⚠ Tạo VAI TUỲ BIẾN với đúng
   danh sách quyền cần
        ↓
    ⚠ Google khuyên ưu tiên vai
      DỰNG SẴN vì Google tự cập nhật
      khi có quyền mới

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

"CẤP vai PROJECT OWNER"
    → ⚠ cho MỌI quyền, kể cả xoá
    → ⚠ và cấp quyền cho người khác
    → ngược hoàn toàn

"CẤP vai VIEWER"
    → ⚠ chỉ ĐỌC
    → ⚠ không TẠO được instance
    → quyền tối thiểu phải ĐỦ để
      làm việc

"TẠM VÔ HIỆU HOÁ tài khoản"
    → ⚠ chặn hết mọi thứ
    → không giải quyết yêu cầu

Nhất quán với #13268 và #13299 (lô 139), #13371 và #13404 (lô 141) — cả năm câu cùng một nguyên tắc: vai hẹp nhất ĐỦ để làm việc. Hoàn toàn nhất quán.

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

• D (cấp vai Viewer) — phương án gần nhất theo hướng "càng hẹp càng tốt", nhưng Viewer chỉ đọc: người dùng sẽ không tạo được instance nào. ⚠ Quyền tối thiểu vẫn phải ĐỦ để làm việc được giao.

• C (cấp vai Project Owner) — quá rộng: cho cả quyền xoá và quyền cấp quyền.

• A (tạm vô hiệu hoá tài khoản) — chặn hết mọi thứ, không đáp ứng yêu cầu.

Ghi nhớ

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

Từ khoá nhận diện:

"cho phép việc này, cấm việc kia" → ⚠ vai tuỳ biến hoặc vai dựng sẵn hẹp "chỉ xem" → Viewer "quyền có thời hạn" → ⚠ IAM Conditions "chặn tường minh dù có vai" → ⚠ IAM Deny policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vai đó có đúng quyền cần không | ⚠ đọc danh sách quyền trong tài liệu | | Người dùng có làm được việc không | ⚠ thử bằng chính tài khoản đó | | Có xoá được không | thử một thao tác xoá — phải bị từ chối |

Và một tính năng đơn giản mà nhiều người quên khi lo chuyện xoá nhầm máy ảo: cờ deletion protection ngay trên instance. Nó độc lập với IAM và chặn được cả những người thật sự có quyền xoá — hữu ích cho vài máy quan trọng nhất mà bạn không muốn ai lỡ tay.

Đáp án

A — Đảm bảo hệ thống AI DỄ HIỂU, CÔNG BẰNG và CÓ TRÁCH NHIỆM GIẢI TRÌNH, để tránh tạo ra hoặc củng cố thiên lệch bất công.

Vì sao đúng

Phương án này gộp ba nguyên tắc cốt lõi của AI có trách nhiệm: explainability, fairness và accountability.

⚠ Ba nguyên tắc trong một câu:

⚠ DỄ HIỂU (explainable)
    → giải thích được vì sao mô hình
      đưa ra quyết định đó

⚠ CÔNG BẰNG (fair)
    → ⚠ không phân biệt đối xử
      theo đặc điểm được bảo vệ

⚠ CÓ TRÁCH NHIỆM GIẢI TRÌNH
   (accountable)
    → ⚠ có NGƯỜI chịu trách nhiệm,
      có giám sát của con người
        ↓
    → tránh tạo ra hoặc KHUẾCH ĐẠI
      thiên lệch bất công

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

"Xây mô hình PHỨC TẠP tới mức
 KHÔNG GIẢI THÍCH ĐƯỢC"
    → ⚠ NGƯỢC với nguyên tắc
      explainability

"CHỈ dùng AI cho những ca
 SINH LỜI NHẤT"
    → ⚠ đó là quyết định kinh doanh,
      không phải nguyên tắc
      trách nhiệm

"Dùng CÀNG ÍT DỮ LIỆU CÀNG TỐT
 để tiết kiệm lưu trữ"
    → ⚠ dữ liệu ít và thiếu đại diện
      LÀM TĂNG thiên lệch
    → ⚠ tiết kiệm lưu trữ không
      phải nguyên tắc AI

⚠ Gần trùng với #13480 (cùng lô này) về công bằng trong cho vay, và #13433 (lô 142) về thiên lệch trong tuyển dụng. Cũng liên quan #13306 (lô 139) về explainability. Cả bốn nhất quán.

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

• D (dùng càng ít dữ liệu càng tốt để tiết kiệm lưu trữ) — phương án gần nhất về mặt "nghe như một nguyên tắc kỹ thuật", nhưng ngược lại: dữ liệu ít và thiếu tính đại diện làm tăng thiên lệch, nhất là với các nhóm ít người.

• B (xây mô hình phức tạp tới mức không giải thích được) — ngược với nguyên tắc explainability.

• C (chỉ dùng AI cho ca sinh lời nhất) — là quyết định kinh doanh, không phải nguyên tắc trách nhiệm.

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 | ⚠ fairness | | Được xây và kiểm thử an toàn | | | ⚠ Chịu trách nhiệm trước con người | ⚠ accountability, có 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ễ hiểu, công bằng, có trách nhiệm" → AI có trách nhiệm "phải nêu lý do cho quyết định" → explainability "không phân biệt đối xử" → fairness "có người xem lại" → human oversight

Ba câu hỏi kiểm chứng trước khi triển khai: | Câu hỏi | Vì sao | |---|---| | Dữ liệu có phản ánh định kiến quá khứ không | | | Mô hình hoạt động thế nào với từng nhóm | ⚠ quan trọng nhất | | Người bị ảnh hưởng có được giải thích không | |

Và một nguyên tắc thực dụng cho mọi ứng dụng AI ảnh hưởng tới con người: nếu bạn không giải thích được vì sao mô hình từ chối ai đó, thì bạn chưa sẵn sàng triển khai nó. Đó không chỉ là yêu cầu đạo đức mà ngày càng trở thành yêu cầu pháp lý ở nhiều quốc gia.

Đáp án

B — Cloud Run và Cloud Functions.

Vì sao đúng

Đề đòi hai dịch vụ tính toán co về 0, và trong bốn cặp được đưa ra chỉ cặp này có cả hai đều co về 0.

⚠ Nền tảng nào co về 0:

⚠ CLOUD RUN            → CÓ
⚠ CLOUD RUN FUNCTIONS  → CÓ
⚠ App Engine Standard  → CÓ
        ↓
⚠ Compute Engine       → KHÔNG
⚠ GKE                  → KHÔNG (cụm luôn chạy)
⚠ App Engine Flexible  → KHÔNG
⚠ Bare Metal Solution  → KHÔNG
⚠ Cloud SQL            → KHÔNG

⚠ Vì sao ba cặp kia trượt:

"Compute Engine và Bare Metal"
    → ⚠ CẢ HAI đều tính tiền
      liên tục

"App Engine Standard và Cloud SQL"
    → ⚠ App Engine Standard CÓ
      co về 0
    → ⚠ nhưng Cloud SQL thì KHÔNG
      (và nó là CSDL, không phải
       dịch vụ tính toán)

"GKE và Compute Engine"
    → ⚠ CẢ HAI đều không co về 0

⚠ Với ứng dụng web container trong đề:

"ứng dụng web ĐÓNG GÓI CONTAINER"
        ↓
    ⚠ CLOUD RUN là lựa chọn
      chính xác nhất
        ↓
    Cloud Functions hợp hơn cho
    ⚠ hàm nhỏ theo sự kiện
        ↓
    → nhưng cả hai đều co về 0,
      nên cặp B là đáp án

Nhất quán với #13281 (lô 139), #13316 và #13367 (lô 141) — các câu đó đều khoá Cloud Run cho container không trạng thái cần co về 0. Hoàn toàn nhất quán.

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

• C (App Engine Standard và Cloud SQL) — phương án gần nhất và là bẫy tinh vi: App Engine Standard THẬT SỰ co về 0. Nhưng Cloud SQL thì không — nó là cơ sở dữ liệu, tính tiền liên tục khi instance chạy.

• A (Compute Engine và Bare Metal Solution) — cả hai tính tiền liên tục.

• D (GKE và Compute Engine) — cụm GKE và máy ảo đều luôn chạy.

Ghi nhớ

⚠ Nền tảng tính toán và khả năng co về 0 — bảng phải thuộc: | Sản phẩm | Co về 0? | |---|---| | ⚠ Cloud Run | ⚠ CÓ | | ⚠ Cloud Run Functions | ⚠ CÓ | | App Engine Standard | CÓ | | App Engine Flexible | ⚠ KHÔNG | | GKE | ⚠ KHÔNG — cụm luôn chạy | | Compute Engine | KHÔNG | | Cloud SQL | ⚠ KHÔNG |

Từ khoá nhận diện:

"container + co về 0" → Cloud Run "hàm theo sự kiện + co về 0" → Cloud Run Functions "mã nguồn + co về 0" → App Engine Standard "nhiều container phụ thuộc nhau" → ⚠ GKE — không co về 0

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí lúc rảnh có bằng 0 không | billing report theo ngày | | Cold start ảnh hưởng bao nhiêu | đo p99 sau khoảng nghỉ | | Có bị mở rộng vô hạn không | ⚠ kiểm max-instances |

Và một bẫy tinh vi mà câu hỏi này khai thác rất tốt: một cặp có thể có một nửa đúng. App Engine Standard thật sự co về 0, nên phương án C rất dễ được chọn — cho tới khi bạn nhớ ra rằng Cloud SQL là cơ sở dữ liệu và luôn tính tiền.

Đáp án

D — Cloud External Key Manager (Cloud EKM).

Vì sao đúng

Đề nêu hai điều kiện tuyệt đối, và chỉ EKM đáp ứng cả hai:

⚠ Hai điều kiện ↔ Cloud EKM:

1. ⚠ "KHÔNG AI, kể cả quản trị viên
    Google, truy cập được dữ liệu
    mã hoá nếu KHÔNG có sự CHẤP THUẬN
    TƯỜNG MINH"
     → ⚠ bạn kiểm soát việc cấp khoá

2. ⚠ "quản khoá trong hệ thống
    BÊN THỨ BA, đặt NGOÀI hạ tầng
    của Google"
     → ⚠ đây là định nghĩa của EKM

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

Khoá nằm ở hệ thống NGOÀI
(Thales, Fortanix, Equinix, Entrust)
        ↓
    Google cần giải mã dữ liệu
        ↓
    ⚠ Cloud KMS GỌI RA hệ thống
      quản khoá của bạn
        ↓
    ⚠ Hệ thống đó QUYẾT ĐỊNH
      có cấp khoá hay không
        ↓
    ⚠ Khoá KHÔNG BAO GIỜ rời khỏi
      hệ thống của bạn
        ↓
    ⚠ Bạn NGẮT quyền → Google
      KHÔNG giải mã được nữa

⚠ Bốn mức quản lý khoá — phân biệt cho rõ:

GOOGLE-MANAGED (mặc định)
    → Google sinh, lưu và xoay khoá

CMEK
    → ⚠ khoá trong CLOUD KMS
    → bạn quản vòng đời
    → ⚠ nhưng khoá VẪN Ở TRONG
      hạ tầng Google

CSEK
    → bạn gửi khoá kèm MỖI REQUEST
    → Google dùng xong xoá khỏi
      bộ nhớ

⚠ CLOUD EKM
    → ⚠ khoá ở HỆ THỐNG NGOÀI
    → ⚠ Google GỌI RA mỗi lần cần
    → ⚠ mức kiểm soát bên ngoài
      cao nhất

⚠ Đối chiếu #13355 (lô 140) — đề đó mô tả doanh nghiệp dùng HSM tại chỗ và khoá đáp án là CSEK; giải thích ở đó đã ghi "Ghi nhớ về chất lượng câu hỏi" nêu rằng EKM mới là cơ chế cho khoá nằm ngoài hạ tầng Google. Câu này xác nhận điều đó. Hai khoá không mâu thuẫn vì đề diễn đạt khác nhau: #13355 nhấn "tự sinh và gửi khoá", câu này nhấn "khoá Ở NGOÀI, Google gọi ra".

Cách phân biệt: 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, thu hồi được" → ⚠ Cloud EKM.

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

• A (CMEK) — phương án gần nhất và cho nhiều quyền kiểm soát: bạn quản vòng đời khoá, xoay và huỷ được. Nhưng khoá vẫn nằm trong Cloud KMS, tức là trong hạ tầng Google — trái điều kiện thứ hai của đề.

• B (mã hoá mặc định do Google quản) — ngược hoàn toàn yêu cầu.

• C (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 kiểm soát | |---|---|---| | Google-managed | trong Google | Google | | CMEK | ⚠ Cloud KMS (TRONG Google) | bạn quản vòng đời | | CSEK | ⚠ 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, thu hồi được |

Từ khoá nhận diện:

"khoá ở hệ thống bên ngoài, Google gọi ra" → ⚠ Cloud EKM "gửi khoá kèm mỗi request" → CSEK "khoá trong Cloud KMS, tôi quản vòng đời" → CMEK "kiểm soát cả việc nhân viên Google truy cập" → ⚠ Access Approval + EKM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dịch vụ đang dùng có hỗ trợ EKM không | ⚠ kiểm danh sách hỗ trợ | | Hệ thống khoá ngoài có đủ tin cậy không | ⚠ nó thành điểm hỏng đơn | | Ai được phép cấp và thu hồi khoá | quyền này mạnh ngang quyền xoá dữ liệu |

Và một hệ quả cần cân nhắc rất kỹ trước khi chọn Cloud EKM: hệ thống quản khoá bên ngoài trở thành điểm hỏng đơn của bạn. Nếu nó ngừng hoạt động, dữ liệu trên Google Cloud vẫn còn nguyên nhưng không giải mã được — nên độ sẵn sàng của nó phải ít nhất bằng độ sẵn sàng bạn cam kết cho chính ứng dụng của mình.

Đáp án

A — Anomaly Detection (phát hiện bất thường).

Vì sao đúng

Cụm quyết định trong đề là "nhận ra những MẪU BẤT THƯỜNG khác biệt đáng kể so với hành vi BÌNH THƯỜNG".

⚠ Ba manh mối ↔ anomaly detection:

1. ⚠ "MẪU BẤT THƯỜNG"
     → tìm điểm lệch khỏi số đông

2. ⚠ "KHÁC BIỆT ĐÁNG KỂ so với
    hành vi BÌNH THƯỜNG"
     → ⚠ mô hình học "thế nào là
       bình thường" rồi báo cái lệch

3. Gian lận
     → ⚠ hiếm gặp, và mẫu LUÔN THAY ĐỔI

⚠ Vì sao gian lận hợp với anomaly detection:

Dữ liệu gian lận rất MẤT CÂN BẰNG
    → có khi chỉ 0,1% giao dịch
        ↓
    ⚠ Nhiều khi KHÔNG có đủ nhãn
      "gian lận" để huấn luyện
    ⚠ Kẻ gian LIÊN TỤC đổi cách
      → mẫu mới chưa từng thấy
        ↓
    Anomaly detection:
    ⚠ chỉ cần học "bình thường"
    ⚠ bắt được cả mẫu MỚI

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

⚠ ANOMALY DETECTION
    → ⚠ tìm điểm LỆCH khỏi bình thường
    → thường KHÔNG cần nhãn
    → đề này

CLASSIFICATION
    → ⚠ có NHÃN sẵn, dự đoán nhãn
    → "gian lận / không gian lận"

CLUSTERING
    → tự tìm nhóm tự nhiên

REGRESSION
    → dự đoán một SỐ

⚠ Đối chiếu #13380 (lô 141) — đề đó cũng về phát hiện gian lận nhưng nói rõ có "tập dữ liệu LỚN ĐÃ GÁN NHÃN", nên khoá là AutoML (bài toán phân loại có giám sát). Câu này nhấn "nhận ra mẫu bất thường so với bình thường", không nhắc nhãn. Không mâu thuẫn — khác nhau ở chỗ có nhãn hay không.

Cách phân biệt: thấy "đã gán nhãn gian lận / không gian lận" → classification. Thấy "tìm mẫu bất thường, khác với bình thường" → anomaly detection.

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

• B (Classification) — phương án gần nhất và đúng khi có nhãn sẵn. Nhưng đề mô tả việc học thế nào là bình thường rồi báo cái lệch, không nhắc tới nhãn gian lận có sẵn.

• C (Clustering) — tự tìm nhóm tự nhiên; (một số kỹ thuật phát hiện bất thường dùng clustering, nhưng mục tiêu nêu trong đề là tìm điểm lệch).

• D (Regression) — dự đoán một số; ở đây không có giá trị số nào cần dự đoán.

Ghi nhớ

⚠ Bốn loại bài toán ML — bảng phải thuộc: | Loại | Đầu ra | Cần nhãn? | |---|---|---| | ⚠ Anomaly detection | ⚠ bình thường / bất thường | ⚠ thường KHÔNG | | Classification | NHÃN rời rạc | CÓ | | Regression | SỐ liên tục | CÓ | | Clustering | nhóm tự tìm | KHÔNG |

Từ khoá nhận diện:

"mẫu bất thường, khác với bình thường" → anomaly detection "đã có nhãn, dự đoán nhãn" → classification "dự đoán một con số" → regression "tự tìm nhóm" → clustering

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có nhãn gian lận sẵn không | ⚠ quyết định loại bài toán | | Tỉ lệ báo nhầm bao nhiêu | ⚠ theo dõi khiếu nại của khách | | Có bắt được mẫu mới không | rà các vụ lọt lưới |

Và một lý do khiến phát hiện bất thường thường được dùng song song với phân loại trong thực tế: kẻ gian không lặp lại cách cũ. Mô hình phân loại giỏi bắt những gì đã thấy; phát hiện bất thường là lớp duy nhất có cơ hội bắt được thứ chưa ai từng gặp.

Đáp án

D — Cloud Data Loss Prevention (nay là Sensitive Data Protection).

Vì sao đúng

Đề đòi ba việc, và cả ba đều là chức năng cốt lõi của dịch vụ này:

⚠ Ba việc ↔ Sensitive Data Protection:

1. ⚠ PHÁT HIỆN (discover)
     → quét và tìm PII trong dữ liệu
     → hơn 150 loại thông tin dựng sẵn

2. ⚠ PHÂN LOẠI (classify)
     → gán nhãn theo loại và
       mức nhạy cảm

3. ⚠ KHỬ ĐỊNH DANH (de-identify)
     → che, thay thế, băm,
       khái quát hoá

⚠ Các kỹ thuật khử định danh:

⚠ REDACTION      → xoá hẳn
⚠ MASKING        → "0912345678" → "091*****"
⚠ TOKENIZATION   → thay bằng token,
                    ⚠ ánh xạ ngược được
                    nếu giữ khoá
⚠ HASHING        → băm một chiều
⚠ GENERALIZATION → ⚠ ngày sinh →
                    khoảng tuổi
⚠ DATE SHIFTING  → dịch ngày theo
                    từng người

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

BIGQUERY
    → ⚠ kho dữ liệu
    → ⚠ CÓ policy tag để che cột,
      nhưng KHÔNG tự PHÁT HIỆN
      và PHÂN LOẠI PII

CLOUD ARMOR
    → ⚠ chống DDoS và WAF ở biên

CLOUD IAM
    → ⚠ phân quyền
    → kiểm soát AI được xem,
      không biến đổi dữ liệu

Nhất quán với #13444 (lô 142) — câu đó về khái niệm de-identification, và cũng nêu Sensitive Data Protection là công cụ. Câu này hỏi dịch vụ nào. Hai câu bổ sung nhau.

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

• A (BigQuery) — phương án gần nhất vì dữ liệu thường nằm ở đó và BigQuery có policy tag để che cột. Nhưng nó không tự phát hiện và phân loại PII; việc đó cần Sensitive Data Protection quét trước.

• B (Cloud Armor) — chống tấn công ở biên mạng.

• C (Cloud IAM) — kiểm soát ai được truy cập, không biến đổi nội dung dữ liệu.

Ghi nhớ

⚠ Sensitive Data Protection — ba việc chính: | Việc | Nội dung | |---|---| | ⚠ Discovery | ⚠ quét và tìm PII — hơn 150 loại dựng sẵn | | ⚠ Classification | gán mức nhạy cảm | | ⚠ De-identification | che, thay thế, băm, khái quát hoá | | Đo rủi ro tái định danh | ⚠ k-anonymity, l-diversity | | Nguồn hỗ trợ | BigQuery, Cloud Storage, Datastore, dữ liệu truyền vào |

Từ khoá nhận diện:

"phát hiện, phân loại, che PII" → ⚠ Sensitive Data Protection (DLP) "che cột trong BigQuery" → policy tag + dynamic data masking "ai được xem dữ liệu" → IAM "chặn dữ liệu chảy ra ngoài" → VPC Service Controls

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn PII nào sót không | ⚠ quét lại sau khi xử lý | | Có tái định danh được không | đo k-anonymity | | Mô hình còn học được không | ⚠ hỏi chính đội khoa học dữ liệu |

Và một cân bằng luôn phải giữ khi khử định danh dữ liệu huấn luyện: che càng nhiều thì càng an toàn nhưng mô hình càng kém. Xoá hẳn địa chỉ là an toàn tuyệt đối nhưng cũng có thể lấy đi tín hiệu quan trọng — nên khái quát hoá thường là lựa chọn tốt hơn xoá bỏ.

Đáp án

B — Triển khai một bản song song của ứng dụng ở một vùng khác, ví dụ europe-west1.

Vì sao đúng

Đề nói rõ mục tiêu là sống sót khi MẤT HOÀN TOÀN vùng us-central1 — và chỉ có mặt ở một vùng khác mới đạt được.

⚠ Vì sao thêm zone không cứu được:

Đã có đa zone trong us-central1
        ↓
    ⚠ Chống được mất MỘT ZONE
        ↓
    Nhưng mất CẢ VÙNG us-central1
        ↓
    ⚠ MỌI zone trong đó cùng chết
    ⚠ Thêm zone nữa cũng vô ích
        ↓
    → phải có mặt ở VÙNG KHÁC

⚠ Vì sao sao lưu vào bucket CÙNG VÙNG cũng không đủ:

Bản sao lưu đặt trong bucket
ở us-central1
        ↓
    ⚠ Mất vùng → mất luôn
      bản sao lưu
        ↓
    → sao lưu phải ở
      ⚠ VÙNG KHÁC hoặc bucket
        ĐA VÙNG

⚠ Ba mô hình phục hồi thảm hoạ:

⚠ BACKUP & RESTORE
    → rẻ nhất, RTO hàng giờ
    → sao lưu ở vùng khác

⚠ WARM STANDBY (pilot light)
    → vùng hai chạy ở mức tối thiểu
    → RTO vài phút

⚠ HOT STANDBY / ACTIVE-ACTIVE
    → ⚠ đắt nhất, RTO gần bằng 0
    → cả hai vùng cùng phục vụ

Nhất quán với #13247 (lô 138) — đề đó cũng khoá đa vùng cho yêu cầu sống sót khi mất cả region. Đối chiếu #13468 (cùng lô) khoá đa zone cho mất một zone. Không mâu thuẫn — khác cấp độ sự cố.

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

• D (sao lưu đĩa VM vào bucket trong us-central1) — phương án gần nhất vì sao lưu là việc cần làm. Nhưng bucket đặt trong chính vùng bị mất thì bản sao lưu cũng mất theo.

• A (thêm VM vào nhiều zone hơn trong us-central1) — mọi zone đều nằm trong vùng đang bị mất.

• C (mua gói Premium Support) — hỗ trợ nhanh hơn nhưng không tạo ra khả năng chịu lỗi.

Ghi nhớ

⚠ Ba cấp triển khai — bảng phải thuộc: | Cấp | Chống được | Chi phí | |---|---|---| | Zonal | không gì cả | thấp nhất | | Regional (đa zone) | ⚠ mất MỘT ZONE | trung bình | | ⚠ Multi-region | ⚠ mất CẢ REGION | cao nhất |

Từ khoá nhận diện:

"mất cả vùng, thảm hoạ khu vực" → ⚠ triển khai đa vùng "mất một zone" → đa zone trong một vùng "lỗi con người, xoá nhầm" → ⚠ backup và PITR "phục hồi sau thảm hoạ" → DR plan với RPO/RTO

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản sao lưu có ở vùng khác không | ⚠ kiểm vị trí bucket | | Dữ liệu có ở cả hai vùng không | kiểm cấu hình sao chép từng dịch vụ | | Chuyển đổi mất bao lâu thật | ⚠ DIỄN TẬP — đừng chỉ ước lượng |

Và điều quan trọng nhất về mọi kế hoạch phục hồi thảm hoạ: nó chỉ có giá trị nếu đã được diễn tập. Một vùng dự phòng chưa bao giờ được kích hoạt thử là một giả thiết — và ngày thảm hoạ thật xảy ra là ngày tệ nhất để phát hiện ra rằng giả thiết ấy sai.