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

Đáp án

C — Data de-identification (khử định danh dữ liệu).

Vì sao đúng

Đề mô tả đúng định nghĩa: biến đổi dữ liệu chứa PII (xoá hoặc che địa chỉ nhà) để dùng được cho phân tích mà không lộ thông tin nhạy cảm.

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

⚠ REDACTION (xoá bỏ)
    → bỏ hẳn trường địa chỉ

⚠ MASKING (che)
    → "123 Nguyễn Huệ, Q1" → "***"

⚠ TOKENIZATION / PSEUDONYMIZATION
    → ⚠ thay bằng mã giả,
      có thể ánh xạ ngược nếu
      giữ bảng tra

⚠ GENERALIZATION (khái quát hoá)
    → ⚠ địa chỉ đầy đủ → chỉ
      giữ QUẬN hoặc THÀNH PHỐ
    → vẫn phân tích được theo vùng

⚠ BUCKETING
    → tuổi 34 → nhóm "30–39"

⚠ DATE SHIFTING
    → dịch chuyển ngày một khoảng
      cố định theo từng người

⚠ Chọn kỹ thuật theo mục đích phân tích:

Muốn phân tích theo KHU VỰC
        ↓
    ⚠ Đừng xoá hẳn địa chỉ
    ⚠ Hãy KHÁI QUÁT HOÁ:
      giữ tỉnh/thành, bỏ số nhà
        ↓
    → vẫn dùng được, mà không
      xác định được cá nhân

⚠ Cảnh báo quan trọng:

"Khử định danh" ⚠ KHÔNG đồng nghĩa
với "không thể tái định danh"
        ↓
    ⚠ Kết hợp nhiều trường tưởng
      vô hại vẫn có thể chỉ ra
      một người
    ⚠ Ví dụ: ngày sinh + mã bưu chính
      + giới tính đã đủ nhận diện
      phần lớn dân số
        ↓
    → cần k-anonymity, l-diversity
      để đo mức rủi ro

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

• A (data deletion — xoá dữ liệu) — phương án gần nhất vì xoá cũng là một kỹ thuật trong khử định danh. Nhưng "xoá dữ liệu" nghĩa là bỏ hẳn, còn đề nói rõ dữ liệu vẫn phải dùng được cho phân tích.

• D (data generation — sinh dữ liệu) — tạo dữ liệu mới; (sinh dữ liệu tổng hợp là một kỹ thuật liên quan, nhưng không phải điều đề mô tả).

• B (data purchasing — mua dữ liệu) — không liên quan.

Ghi nhớ

⚠ Các khái niệm bảo vệ dữ liệu — bảng nên thuộc: | Khái niệm | Nghĩa | |---|---| | ⚠ De-identification | ⚠ biến đổi để không xác định được cá nhân | | Pseudonymization | ⚠ thay bằng mã giả — CÓ THỂ ánh xạ ngược | | Anonymization | ⚠ không thể ánh xạ ngược | | Masking | che một phần giá trị | | Tokenization | thay bằng token, giữ bảng tra riêng | | Encryption | ⚠ mã hoá — giải mã được nếu có khoá |

Từ khoá nhận diện:

"che PII nhưng vẫn phân tích được" → de-identification "tìm PII trong dữ liệu" → ⚠ Sensitive Data Protection "che cột trong BigQuery" → policy tag + dynamic data masking "dữ liệu phải nằm trong lãnh thổ" → data residency

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn PII nào sót không | ⚠ quét lại bằng Sensitive Data Protection | | Có tái định danh được không | đo k-anonymity | | Phân tích còn dùng được không | ⚠ hỏi chính người phân tích |

Và một cân bằng luôn phải giữ khi khử định danh: che càng nhiều thì càng an toàn nhưng càng ít giá trị phân tích. Xoá hẳn địa chỉ là an toàn tuyệt đối nhưng cũng khiến mọi phân tích theo khu vực trở nên bất khả thi — nên lựa chọn đúng thường là khái quát hoá, chứ không phải xoá bỏ.

Đáp án

D — Dùng Security Command Center để tìm các phát hiện (findings) liên quan tới chính sách IAM.

Vì sao đúng

Đề đòi rà soát TOÀN BỘ tổ chức một cách HIỆU QUẢ NHẤT — và đó là điểm mạnh của Security Command Center.

⚠ Vì sao SCC phù hợp:

⚠ Quét TOÀN BỘ tổ chức
    → mọi folder, mọi project
    → ⚠ kể cả project mới tạo

⚠ Phát hiện dựng sẵn cho IAM
    → quyền quá rộng
    → tài khoản dịch vụ có quyền
      Owner
    → thành viên ngoài miền công ty

⚠ Có bảng điều khiển tập trung
    → xem, lọc, xuất

⚠ Cập nhật liên tục
    → không phải rà thủ công
      từng lần

⚠ Vì sao rà thủ công không khả thi:

Tổ chức có hàng chục tới hàng trăm
project
        ↓
    ⚠ Mở từng trang IAM
        ↓
    ⚠ Tốn hàng giờ
    ⚠ Dễ bỏ sót
    ⚠ ⚠ Ngày mai có project mới
      thì phải làm lại từ đầu

⚠ Các công cụ khác cũng làm được phần này:

⚠ POLICY ANALYZER
    → truy vấn "ai có quyền gì
      trên tài nguyên nào"
    → rất mạnh cho câu hỏi cụ thể

⚠ ASSET INVENTORY
    → xuất toàn bộ chính sách IAM
      ra BigQuery rồi truy vấn SQL

⚠ gcloud + script
    → lặp qua các project
        ↓
    Nhưng đề hỏi "HIỆU QUẢ NHẤT"
    và SCC là công cụ dựng sẵn

Liên quan #13371 và #13404 (lô 141) về quyền tối thiểu và cấp quyền cho nhóm. Câu này về kiểm tra xem nguyên tắc đó có được tuân thủ không. Bổ sung cho nhau.

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

• B (mở thủ công trang IAM của từng project) — phương án gần nhất và về kỹ thuật thì làm được, nhưng không hiệu quả: tốn hàng giờ, dễ bỏ sót, và phải làm lại mỗi khi có project mới.

• A (xem báo cáo Cloud Billing của từng project) — báo cáo chi phí, không chứa thông tin về quyền.

• C (liên hệ Google Cloud support xin danh sách) — Google không cung cấp dịch vụ này; thông tin nằm trong chính tài khoản của bạn.

Ghi nhớ

⚠ Công cụ rà soát bảo mật — bảng nên thuộc: | Công cụ | Việc | |---|---| | ⚠ Security Command Center | ⚠ phát hiện rủi ro TOÀN TỔ CHỨC | | ⚠ Policy Analyzer | ⚠ ai có quyền gì trên tài nguyên nào | | IAM Recommender | gợi ý thu hẹp quyền theo mức dùng thật | | Asset Inventory | ⚠ xuất toàn bộ tài nguyên và chính sách ra BigQuery | | Cloud Audit Logs | ai đã đổi quyền, khi nào | | Organization Policy | đặt lằn ranh cứng |

Từ khoá nhận diện:

"rà toàn tổ chức, phát hiện rủi ro" → Security Command Center "ai có quyền gì trên tài nguyên nào" → Policy Analyzer "quyền nào không dùng tới" → IAM Recommender "ai đã đổi quyền" → Cloud Audit Logs

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu Owner trong tổ chức | ⚠ SCC hoặc Policy Analyzer | | Có ai ngoài miền công ty không | ⚠ phát hiện quan trọng nhất | | Quyền nào không dùng tới | IAM Recommender |

Và một phát hiện nên ưu tiên xử lý trước mọi thứ khác khi rà soát quyền: tài khoản không thuộc miền công ty. Một địa chỉ Gmail cá nhân có quyền Owner trên project sản xuất thường là dấu vết của một lần cấp quyền tạm thời nhiều tháng trước mà không ai nhớ gỡ.

Đáp án

B — VPC Firewall Rules.

Vì sao đúng

Đề đòi chặn lưu lượng ĐI RA Internet từ một nhóm máy ảo cụ thể, nhưng vẫn cho giao tiếp nội bộ trong VPC — đó chính xác là việc của luật tường lửa VPC.

⚠ Cấu hình đúng:

1. Gắn NETWORK TAG cho các VM đó
     ví dụ: `no-internet`

2. Tạo luật EGRESS DENY:
     - hướng: ⚠ EGRESS (đi ra)
     - đích: 0.0.0.0/0
     - hành động: ⚠ DENY
     - target tag: `no-internet`
     - ưu tiên: ví dụ 1000

3. Tạo luật EGRESS ALLOW cho nội bộ:
     - đích: dải IP của VPC
     - hành động: ALLOW
     - ⚠ ưu tiên CAO HƠN (số NHỎ hơn)
        ↓
    ⚠ Kết quả: VM nói chuyện được
      trong VPC, KHÔNG ra Internet

⚠ Hai điều dễ nhầm về firewall VPC:

⚠ ƯU TIÊN: SỐ CÀNG NHỎ CÀNG MẠNH
    → luật ưu tiên 100 thắng
      luật ưu tiên 1000

⚠ Luật mặc định:
    - EGRESS: ⚠ ALLOW tất cả
    - INGRESS: ⚠ DENY tất cả
        ↓
    → phải TẠO luật deny egress
      thì mới chặn được

⚠ Còn cần thêm gì để chặn triệt để:

⚠ GỠ IP CÔNG KHAI của VM
    → không có IP công khai thì
      không ra Internet trực tiếp

⚠ KHÔNG dùng Cloud NAT cho
   subnet đó
    → Cloud NAT là đường ra
      cho VM không có IP công khai

⚠ VPC SERVICE CONTROLS
    → ⚠ chặn dữ liệu chảy sang
      project hoặc dịch vụ ngoài
      vành đai
        ↓
    → firewall chặn MẠNG,
      VPC SC chặn DỮ LIỆU

Nhất quán với #13312 (lô 139) và #13434 (cùng lô) về giữ lưu lượng trong mạng riêng của Google. Câu này là biện pháp cụ thể ở tầng mạng. Nhất quán.

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

• C (IAM Roles) — phương án gần nhất về mặt "cũng là kiểm soát", nhưng IAM quản ai được gọi API nào, không kiểm soát lưu lượng mạng của máy ảo. Một VM có quyền IAM hẹp vẫn mở được kết nối TCP ra Internet.

• D (Cloud Load Balancing) — phân phối lưu lượng ĐẾN, không chặn lưu lượng đi ra.

• A (Cloud DNS) — dịch tên miền thành IP. (Có thể gây khó khăn cho việc phân giải tên, nhưng không phải cơ chế chặn.)

Ghi nhớ

⚠ Các lớp kiểm soát mạng — bảng phải thuộc: | Lớp | Việc | |---|---| | ⚠ VPC Firewall Rules | ⚠ cho phép/chặn lưu lượng theo IP, cổng, tag | | ⚠ VPC Service Controls | ⚠ vành đai chống RÒ RỈ DỮ LIỆU giữa project | | Cloud Armor | chống DDoS và WAF ở biên | | Private Google Access | gọi API Google không cần IP công khai | | Cloud NAT | ⚠ đường ra Internet cho VM không có IP công khai | | IAM | ai được gọi API nào |

Từ khoá nhận diện:

"chặn lưu lượng ra Internet" → VPC firewall egress deny "chặn dữ liệu chảy sang project khác" → ⚠ VPC Service Controls "chống DDoS và SQL injection" → Cloud Armor "VM không IP công khai vẫn gọi được API Google" → Private Google Access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật có chặn đúng không | ⚠ thử curl ra Internet từ trong VM | | Nội bộ còn thông không | thử kết nối tới VM khác cùng VPC | | Lưu lượng thật đi đâu | ⚠ VPC Flow Logs |

Và một điều rất dễ bị bỏ sót khi chặn Internet cho máy ảo xử lý dữ liệu nhạy cảm: firewall chặn mạng nhưng không chặn dữ liệu. Một VM bị cấm ra Internet vẫn có thể ghi toàn bộ hồ sơ bệnh nhân sang một bucket ở project khác qua API nội bộ của Google — và chỉ VPC Service Controls mới bịt được đường đó.

Đáp án

D — Đình chỉ hoặc xoá tài khoản người dùng để thu hồi ngay lập tức mọi quyền truy cập.

Vì sao đúng

Đề mô tả một rủi ro nội bộ ở mức cao nhất: kỹ sư DevOps cấp cao có quyền quản trị trên hệ thống sản xuất, CSDL khách hàng và tài khoản thanh toán.

⚠ Vì sao phải hành động ngay:

Nhân viên rời công ty
        ↓
    ⚠ Tài khoản vẫn hoạt động
        ↓
    ⚠ Vẫn đăng nhập được từ nhà
    ⚠ Vẫn có quyền trên production
    ⚠ Vẫn xem được dữ liệu khách hàng
    ⚠ Vẫn đụng được tài khoản
      thanh toán
        ↓
    → trả badge KHÔNG thu hồi
      quyền truy cập DIGITAL

⚠ Đình chỉ hay xoá — chọn cái nào:

⚠ SUSPEND (đình chỉ)
    → chặn đăng nhập NGAY
    → ⚠ GIỮ dữ liệu và quyền sở hữu
      tài liệu
    → ⚠ khôi phục được nếu cần
    → thường là bước ĐẦU TIÊN

DELETE (xoá)
    → xoá hẳn tài khoản
    → ⚠ cần chuyển quyền sở hữu
      dữ liệu TRƯỚC
    → làm sau khi đã bàn giao xong
        ↓
    ⚠ Thực hành: SUSPEND ngay,
      DELETE sau khi bàn giao

⚠ Vì sao ba phương án kia nguy hiểm:

"ĐỔI MẬT KHẨU nhưng GIỮ tài khoản
 hoạt động"
    → ⚠ khoá API, khoá SSH và
      TOKEN đã cấp VẪN dùng được
    → ⚠ không thu hồi được phiên
      đang mở

"GIỮ tài khoản phòng khi họ quay lại"
    → ⚠ rủi ro kéo dài vô thời hạn
    → tài khoản không ai dùng là
      mục tiêu lý tưởng cho kẻ tấn công

"Gán vai PROJECT OWNER"
    → ⚠ vô lý — TĂNG quyền cho
      người vừa nghỉ việc

Liên quan #13404 (lô 141) — câu đó nêu lợi ích của cấp quyền theo NHÓM: khi đó gỡ quyền chỉ là xoá khỏi vài nhóm. Bổ sung cho nhau.

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

• C (đổi mật khẩu nhưng giữ tài khoản hoạt động) — phương án gần nhất và có vẻ hợp lý, nhưng không đủ: khoá API, khoá SSH, token OAuth đã cấp vẫn dùng được, và phiên đăng nhập đang mở không bị ngắt.

• B (giữ tài khoản phòng khi họ quay lại) — kéo dài rủi ro vô thời hạn.

• A (gán vai Project Owner) — vô lý; tăng quyền cho người vừa nghỉ việc.

Ghi nhớ

⚠ Quy trình offboarding — bảng nên thuộc: | Bước | Việc | |---|---| | 1 | ⚠ ĐÌNH CHỈ tài khoản Cloud Identity — NGAY | | 2 | ⚠ Thu hồi mọi phiên và token OAuth | | 3 | ⚠ Vô hiệu hoá khoá API và service account key họ tạo | | 4 | Xoá khỏi mọi nhóm | | 5 | Chuyển quyền sở hữu tài liệu và tài nguyên | | 6 | ⚠ Đổi mật khẩu/khoá dùng chung mà họ biết | | 7 | Rà audit log — hoạt động bất thường trước khi nghỉ | | 8 | Xoá tài khoản sau khi bàn giao xong |

Từ khoá nhận diện:

"nhân viên nghỉ việc" → ⚠ đình chỉ tài khoản ngay "nhà thầu tạm thời" → ⚠ IAM Conditions có thời hạn "quản quyền cho nhiều người" → cấp cho nhóm "rà quyền toàn tổ chức" → Security Command Center

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài khoản còn đăng nhập được không | ⚠ thử ngay sau khi đình chỉ | | Còn khoá API nào của họ không | rà service account key | | Có hoạt động bất thường trước khi nghỉ không | ⚠ Cloud Audit Logs |

Và một bài học mà nhiều tổ chức chỉ học sau khi gặp sự cố: thu hồi quyền truy cập số phải diễn ra CÙNG LÚC với việc thu badge, không phải vài ngày sau. Cửa toà nhà và cửa hệ thống là hai thứ khác nhau — và cái thứ hai thường quan trọng hơn nhiều.

Đáp án

A — Dùng Folders để nhóm các project theo phòng ban hoặc theo đội.

Vì sao đúng

Đề đòi nhóm project lại để quản lý chính sách và kiểm soát truy cập tốt hơn — đó chính xác là lý do folder tồn tại.

⚠ Cấu trúc đúng:

        ORGANIZATION
              │
    ┌─────────┼─────────┐
 FOLDER    FOLDER    FOLDER
Marketing  Finance  Engineering
    │         │          │
 projects  projects   projects
        ↓
    ⚠ Chính sách đặt ở folder
      LAN XUỐNG mọi project bên trong
    ⚠ Project MỚI thêm vào folder
      TỰ ĐỘNG kế thừa

⚠ Đặt gì ở cấp folder:

⚠ VAI IAM
    → đội Marketing có quyền trên
      mọi project Marketing

⚠ ORGANIZATION POLICY
    → giới hạn vùng, cấm IP công khai,
      cấm chia sẻ ra ngoài miền

⚠ NGÂN SÁCH và CẢNH BÁO
    → theo phòng ban

⚠ LOG SINK
    → gom log về một chỗ

⚠ Vì sao ba phương án kia kém hơn:

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

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

"Cấu trúc PHẲNG, mọi project
 dưới Organization"
    → ⚠ phải cấp quyền và đặt
      chính sách cho TỪNG project
    → không mở rộng nổi

⚠ Gần trùng với #13279 và #13305 (lô 140) — cả ba đề đều là nhóm project theo phòng ban hoặc môi trường để áp chính sách chung, và cả ba cùng khoá Folders. Hoàn toàn nhất quán.

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

• D (cấu trúc phẳng dưới Organization) — phương án gần nhất về mặt "cũng là một cách tổ chức", nhưng nó buộc phải cấp quyền và đặt chính sách cho từng project một — không mở rộng nổi khi có hàng chục project.

• B (tài khoản thanh toán riêng cho mỗi project) — tách được chi phí nhưng không quản được chính sách, và tạo rất nhiều việc quản trị.

• 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 "tập quyền riêng" → vai IAM tuỳ biến "cấm hành vi ở mọi nơi" → Organization Policy

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 | | Chi phí theo phòng ban | billing report nhóm theo folder |

Và một quyết định nên làm cho tử tế ngay từ đầu: thiết kế cây folder trước khi tạo hàng loạt project. Chuyển project giữa các folder về sau là làm được, nhưng chính sách kế thừa sẽ đổi theo — và phát hiện ra điều đó khi hệ thống đã chạy thường không dễ chịu.

Đáp án

C — Error Budget (ngân sách lỗi).

Vì sao đúng

Đề định nghĩa thẳng khái niệm: phần được phép không sẵn sàng, tính từ SLO, và được dùng để cân bằng giữa độ tin cậy và tốc độ ra tính năng.

⚠ Công thức và ý nghĩa:

SLO = 99,9% trong 30 ngày
        ↓
    ⚠ Error budget = 100% − 99,9%
                   = 0,1%
        ↓
    0,1% × 30 ngày
    ≈ ⚠ 43 phút mỗi tháng
        ↓
    → đây là khoản ĐƯỢC PHÉP TIÊU

⚠ Cách dùng error budget:

CÒN ngân sách
    → ⚠ được phép TRIỂN KHAI
      tính năng mới
    → chạy canary, A/B test
    → ⚠ diễn tập sự cố (chaos)

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 TRƯỚC

⚠ Vì sao nó giải quyết mâu thuẫn tổ chức:

Đội sản phẩm muốn RA NHANH
Đội vận hành muốn ỔN ĐỊNH
        ↓
    ⚠ Không có error budget:
      cãi nhau bằng CẢM TÍNH
        ↓
    Có error budget:
    ⚠ cãi nhau bằng MỘT CON SỐ
      mà cả hai đã đồng ý TỪ TRƯỚC
        ↓
    → không còn ai phải "thắng"

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

SLI
    → ⚠ CHỈ SỐ được đo
      (tỉ lệ thành công, độ trễ)

SLA
    → ⚠ HỢP ĐỒNG với khách hàng,
      có bồi thường

DOWNTIME
    → ⚠ chỉ là "thời gian ngừng"
    → ⚠ không phải khái niệm SRE
      về khoản được phép tiêu

⚠ Gần trùng với #13309 (lô 139) — đề đó cũng về error budget và cùng khoá. Nhất quán.

Đối chiếu #13353 (lô 140, SLO) và #13442 (cùng lô, SLI) — ba câu tạo thành bộ đầy đủ: SLI là chỉ số, SLO là mục tiêu, error budget là phần dư của SLO.

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

• B (Downtime) — phương án gần nhất về mặt nghĩa đen: 43 phút đúng là thời gian ngừng. Nhưng "downtime" chỉ là hiện tượng, còn error budget là khái niệm QUẢN LÝ: một khoản được phép tiêu và được dùng để ra quyết định.

• A (SLI) — là chỉ số được đo, không phải khoản được phép hỏng.

• D (SLA) — là hợp đồng với khách hàng, không phải công cụ nội bộ.

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 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:

"khoản được phép không sẵn sàng" → error budget "mục tiêu 99,9%" → SLO "chỉ số được đo" → SLI "cam kết có bồi thường" → SLA

Ba việc kiểm chứng cho một đội: | Việc | Câu hỏi | |---|---| | Có SLO viết ra chưa | | | Còn bao nhiêu ngân sách lỗi | ⚠ có bảng theo dõi không | | Hết ngân sách thì làm gì | ⚠ đã thống nhất TRƯỚC chưa |

Và điều làm nên sức mạnh thật sự của error budget: nó phải được thoả thuận trước khi có sự cố. Một quy tắc "hết ngân sách thì dừng phát hành" chỉ có giá trị khi cả đội sản phẩm lẫn đội vận hành đã đồng ý từ lúc mọi thứ còn yên bình.

Đáp án

A — Nó cung cấp một nền tảng tập trung để tạo mô hình dữ liệu nhất quán (LookML), cho phép phân tích tự phục vụ đáng tin cậy cho người dùng nghiệp vụ.

Vì sao đúng

Đề mô tả đúng vấn đề mà LookML sinh ra để giải: các đội tính cùng một chỉ số theo những cách khác nhau.

⚠ Vấn đề trong đề:

Nhà phân tích, marketing, lãnh đạo
đều dựng báo cáo từ cùng một CSDL
        ↓
    ⚠ "Doanh thu tổng" mỗi đội
      tính một kiểu
    ⚠ "Giá trị vòng đời khách hàng"
      cũng vậy
        ↓
    ⚠ Báo cáo mâu thuẫn nhau
    ⚠ Họp hành cãi nhau về con số
      thay vì bàn hành động

⚠ LookML giải bằng cách nào:

Đội dữ liệu định nghĩa MỘT LẦN:
```lookml
measure: total_revenue {
  type: sum
  sql: ${TABLE}.net_amount ;;
  description: "Doanh thu thuần,
    đã trừ hoàn tiền và chiết khấu"
}

        ↓
    ⚠ MỌI báo cáo dùng CÙNG
      định nghĩa này
    ⚠ Sửa một chỗ → mọi dashboard
      đổi theo
        ↓
    → ⚠ MỘT NGUỒN SỰ THẬT

⚠ Hai giá trị đi cùng nhau:

⚠ NHẤT QUÁN
    → mọi người ra cùng một con số

⚠ TỰ PHỤC VỤ
    → người dùng nghiệp vụ tự
      kéo thả, không cần SQL
        ↓
    ⚠ Không có vế đầu thì vế sau
      chỉ tạo ra thêm hỗn loạn

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

"Công cụ cho KỸ SƯ DỮ LIỆU viết
 script ETL phức tạp"
    → ⚠ SAI: đó là Dataflow,
      Dataform, Data Fusion
    → Looker dành cho người dùng
      nghiệp vụ

"CHỈ kết nối được nguồn dữ liệu
 của Google Cloud"
    → ⚠ SAI: Looker kết nối
      hơn 50 CSDL, kể cả Snowflake,
      Redshift, PostgreSQL

"TỰ ĐỘNG làm sạch mọi dữ liệu thô"
    → ⚠ SAI: Looker mô hình hoá,
      không làm sạch
    → làm sạch là việc của
      Dataform, Dataflow, Dataprep

⚠ Gần trùng với #13261 (lô 138), #13343 (lô 140) và #13437 (cùng lô) — cả bốn đề đều về Looker cho BI tự phục vụ. Câu này nhấn vào giá trị của LookML: sự nhất quán. Hoàn toàn nhất quán.

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

• C (chỉ kết nối được nguồn dữ liệu Google Cloud) — phương án gần nhất về mặt "nghe như một đặc điểm thật", nhưng sai: Looker kết nối được hơn 50 loại CSDL, kể cả Snowflake, Redshift, Databricks.

• B (công cụ cho kỹ sư dữ liệu viết ETL) — đó là Dataflow, Dataform hoặc Data Fusion.

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

Ghi nhớ

⚠ Giá trị cốt lõi của Looker — bảng nên thuộc: | Giá trị | Nội dung | |---|---| | ⚠ LookML | ⚠ định nghĩa chỉ số TẬP TRUNG, quản bằng Git | | ⚠ Một nguồn sự thật | mọi báo cáo cùng định nghĩa | | Tự phục vụ | người dùng kéo thả, không cần SQL | | 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ị mạnh | access filter, Content Validator |

Từ khoá nhận diện:

"chỉ số tính không nhất quán giữa các đội" → ⚠ LookML / một nguồn sự thật "dashboard tự phục vụ" → Looker "báo cáo nhanh, miễn phí" → Looker Studio "làm sạch và biến đổi dữ liệu" → Dataform, Dataflow

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ba đội hỏi cùng câu có ra cùng số không | ⚠ phép thử của mô hình chung | | Mọi measure có mô tả chưa | | | Có nội dung nào hỏng không | Content Validator |

Và một điều làm nên khác biệt thật sự giữa Looker và một công cụ vẽ biểu đồ thông thường: nó bắt tổ chức phải thống nhất định nghĩa chỉ số trước khi có dashboard. Đó là phần khó nhất của dự án BI, và cũng là phần tạo ra gần như toàn bộ giá trị.

Đáp án

D — Cloud Translation API.

Vì sao đúng

Đề đòi hai việc, và cả hai đều là chức năng gốc của Translation API:

⚠ Hai việc ↔ Translation API:

1. ⚠ "PHÁT HIỆN ngôn ngữ GỐC
    của bài báo"
     → ⚠ `detect_language` —
       tính năng có sẵn

2. "DỊCH sang một ngôn ngữ
    được chỉ định"
     → `translate` với
       `target_language`
        ↓
    ⚠ Cả hai trong MỘT API

⚠ Gọi API:

from google.cloud import translate_v2 as translate
client = translate.Client()

# Phát hiện ngôn ngữ
kq = client.detect_language(van_ban)
print(kq["language"])   # "fr"

# Dịch (tự phát hiện nếu không khai nguồn)
kq = client.translate(van_ban,
                      target_language="vi")
print(kq["translatedText"])

        ↓
    ⚠ Hơn 100 ngôn ngữ
    ⚠ Không cần huấn luyện gì

⚠ Vì sao ba API kia sai hướng:

NATURAL LANGUAGE API
    → ⚠ phân tích thực thể, cảm xúc
    → ⚠ CÓ phát hiện ngôn ngữ,
      nhưng KHÔNG DỊCH

SPEECH-TO-TEXT API
    → ⚠ ÂM THANH → chữ
    → bài báo đã là văn bản

VISION AI API
    → ⚠ xử lý ẢNH

⚠ Gần trùng với #13259 (lô 138), #13324 (lô 140) và #13405 (lô 141) — cả bốn đề đều là nhu cầu dịch thuật cho đội không có chuyên môn ML, và cả bốn cùng khoá Cloud Translation API. Hoàn toàn nhất quán.

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

• A (Natural Language API) — phương án gần nhất vì nó cũng phát hiện được ngôn ngữ, nhưng nó không dịch. Nó phân tích thực thể, cảm xúc và cú pháp.

• B (Speech-to-Text API) — chuyển âm thanh thành chữ; bài báo đã là văn bản.

• C (Vision AI API) — xử lý ảnh.

Ghi nhớ

⚠ Các API AI dựng sẵn — bảng phải thuộc: | API | Việc | |---|---| | ⚠ Cloud Translation | ⚠ phát hiện ngôn ngữ + DỊCH | | Natural Language | thực thể, cảm xúc, phân loại | | Speech-to-Text | giọng nói → chữ | | Text-to-Speech | chữ → giọng nói | | Vision | ảnh | | Document AI | trích xuất từ tài liệu |

Từ khoá nhận diện:

"dịch, phát hiện ngôn ngữ" → Cloud Translation API "cảm xúc, thực thể trong văn bản" → Natural Language API "thuật ngữ ngành dịch sai" → ⚠ AutoML Translation hoặc glossary "dịch cả tệp PDF" → ⚠ Translation Advanced (v3)

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 bài | | 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 cân nhắc riêng cho lĩnh vực tin tức mà đề không nhắc tới: bản dịch máy nên được đánh dấu rõ và có người rà với những bài nhạy cảm. Một sai lệch nhỏ trong bản dịch một bài chính trị hay y tế có thể tạo ra hậu quả lớn hơn nhiều so với chi phí thuê người kiểm tra.

Đáp án

C — Thiết lập các chính sách và quy trình để duy trì chất lượng, tính sẵn có và bảo mật của dữ liệu.

Vì sao đúng

Đề liệt kê ba triệu chứng kinh điển của việc thiếu quản trị dữ liệu, và cả ba đều nằm trong phạm vi mà data governance giải quyết.

⚠ Ba triệu chứng ↔ ba trụ cột:

1. "định nghĩa chỉ số KHÔNG NHẤT QUÁN
    giữa các đội"
     → ⚠ vấn đề CHẤT LƯỢNG và
       tiêu chuẩn hoá

2. "dữ liệu LỖI THỜI hoặc TRÙNG LẶP"
     → ⚠ vấn đề CHẤT LƯỢNG

3. ⚠ "không rõ AI được truy cập
    dữ liệu gì và giữ BAO LÂU"
     → ⚠ vấn đề BẢO MẬT và
       VÒNG ĐỜI dữ liệu

⚠ Data governance gồm ba phần:

⚠ CON NGƯỜI
    → data owner, data steward
    → hội đồng quản trị dữ liệu

⚠ QUY TRÌNH
    → duyệt cấp quyền
    → quy trình xử lý sự cố dữ liệu
    → chu kỳ rà soát và lưu giữ

⚠ CÔNG NGHỆ
    → Dataplex, policy tag,
      IAM, audit log
        ↓
    ⚠ Thiếu con người và quy trình
      thì công cụ vô nghĩa

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

"Cho MỌI nhân viên quyền quản trị
 đầy đủ trên MỌI dữ liệu"
    → ⚠ NGƯỢC HOÀN TOÀN
    → đó là bỏ hết kiểm soát

"Đảm bảo dùng dịch vụ đám mây
 ĐẮT NHẤT"
    → ⚠ vô lý

"XOÁ mọi dữ liệu ngay khi được
 sinh ra"
    → ⚠ vô lý — dữ liệu là tài sản

⚠ Gần trùng với #13252 (lô 138) — đề đó cũng định nghĩa data governance qua tính sẵn có, khả dụng, toàn vẹn và bảo mật, và cùng khoá. Hoàn toàn nhất quán.

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

• A (cho mọi nhân viên quyền quản trị đầy đủ) — phương án gần nhất về mặt "cũng nói về truy cập dữ liệu", nhưng ngược hoàn toàn: đó là bỏ hết kiểm soát, chính là nguyên nhân của vấn đề trong đề.

• B (đảm bảo dùng dịch vụ đắt nhất) — vô lý.

• D (xoá mọi dữ liệu ngay khi sinh ra) — vô lý; dữ liệu là tài sản cần được quản lý, không phải tiêu huỷ.

Ghi nhớ

⚠ Bốn trụ cột của data governance — bảng phải thuộc: | Trụ cột | Nội dung | |---|---| | Availability | dữ liệu sẵn có khi cần | | Usability | ⚠ tìm được, hiểu được, dùng được | | Integrity | ⚠ chính xác và nhất quán | | Security | chỉ đúng người được xem | | Thêm | ⚠ tuân thủ và vòng đời lưu giữ |

Từ khoá nhận diện:

"chính sách, chất lượng, ai xem gì, giữ bao lâu" → data governance "tìm dữ liệu ở đâu trong tổ chức" → data catalog / Dataplex "cột này tính từ đâu ra" → data lineage "người dùng tự phân tích" → data democratization

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có biết dữ liệu nhạy cảm ở đâu không | Sensitive Data Protection | | Ba đội tính "doanh thu" có ra cùng số không | ⚠ phép thử của định nghĩa chung | | Mỗi tập dữ liệu có người sở hữu chưa | ⚠ thiếu chỗ này thì công cụ vô nghĩa |

Và lý do khiến phần lớn chương trình quản trị dữ liệu thất bại: chúng được triển khai như một dự án công nghệ. Công cụ dựng xong trong vài tuần, nhưng nếu không ai được chỉ định chịu trách nhiệm cho từng miền dữ liệu thì sáu tháng sau danh mục lại đầy những tập dữ liệu không ai biết dùng để làm gì.

Đáp án

A — Dùng Vertex AI Training với một script TensorFlow hoặc PyTorch tuỳ biến.

Vì sao đúng

Cụm từ quyết định trong đề là "TOÀN QUYỀN kiểm soát kiến trúc mô hình và quá trình huấn luyện, bằng một framework MÃ NGUỒN MỞ".

⚠ Ba manh mối ↔ custom training:

1. ⚠ "TOÀN QUYỀN kiểm soát
    KIẾN TRÚC mô hình"
     → ⚠ AutoML KHÔNG cho đổi
       kiến trúc

2. ⚠ "và quá trình HUẤN LUYỆN"
     → tự chọn optimizer, learning rate,
       augmentation

3. ⚠ "bằng FRAMEWORK MÃ NGUỒN MỞ"
     → ⚠ TensorFlow hoặc PyTorch
        ↓
    → Vertex AI Training với
      container tuỳ biến

⚠ Vertex AI Training cho gì:

Bạn viết script huấn luyện
        ↓
    Đóng gói thành container
    (hoặc dùng container dựng sẵn)
        ↓
    ⚠ Vertex AI lo:
      - cấp phát máy và GPU/TPU
      - huấn luyện phân tán
      - ⚠ hyperparameter tuning
      - ghi log và checkpoint
        ↓
    Mô hình vào Model Registry
        ↓
    Triển khai lên Endpoint

⚠ Vì sao ba phương án kia không khớp:

AUTOML VISION
    → ⚠ RẤT tốt cho phân loại ảnh
    → ⚠ nhưng KHÔNG cho kiểm soát
      kiến trúc — đó là điểm bán
      hàng của nó
    → đề nói rõ họ MUỐN kiểm soát

VISION AI API
    → ⚠ mô hình có sẵn của Google
    → không huấn luyện trên dữ liệu
      của họ

BIGQUERY ML "phân tích METADATA ảnh"
    → ⚠ metadata không phải nội dung ảnh
    → không phân biệt được mèo và chó

⚠ Đối chiếu #13273 (lô 139) — đề đó cũng là phân loại ảnh với dữ liệu riêng đã gán nhãn, nhưng đội muốn ĐẨY NHANH và KHÔNG viết mã mô hình từ đầu, nên khoá là AutoML Vision. Câu này đội muốn TOÀN QUYỀN kiểm soát kiến trúc, nên khoá là custom training. Hai câu KHÔNG mâu thuẫn — chúng khác nhau ở mức kiểm soát mà đội mong muốn.

Cách phân biệt khi làm bài: thấy "đẩy nhanh, không viết mã mô hình" → AutoML. Thấy "toàn quyền kiểm soát kiến trúc, framework mã nguồn mở" → custom training.

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

• D (AutoML Vision) — phương án gần nhất và hoàn toàn làm được bài toán này. Nhưng nó tự chọn kiến trúc, trái với yêu cầu "toàn quyền kiểm soát" mà đề nêu rõ.

• C (Vision AI API) — mô hình dựng sẵn của Google; không huấn luyện trên dữ liệu của họ.

• B (BigQuery ML phân tích metadata ảnh) — metadata (kích thước, ngày chụp) không chứa nội dung ảnh.

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Kiểm soát | Khi nào | |---|---|---| | API dựng sẵn | thấp nhất | nhãn phổ quát | | AutoML | trung bình | ⚠ nhãn riêng + không viết mã mô hình | | ⚠ Custom training | ⚠ cao nhất | ⚠ cần kiểm soát kiến trúc, có đội ML |

Từ khoá nhận diện:

"toàn quyền kiến trúc, TensorFlow/PyTorch" → Vertex AI Training "đẩy nhanh, 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ết SQL" → BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự tốt hơn AutoML không | ⚠ đo trên cùng tập kiểm tra | | Nút thắt nằm ở đâu | profiler | | Có tái lập được kết quả không | Vertex AI Metadata — lineage |

Và một bước nên làm trước mọi dự án custom training: dựng một mô hình AutoML làm đường cơ sở. Nó mất vài giờ, cho ngay một con số để so sánh — và không ít lần cho kết quả tốt tới mức cả dự án viết mô hình riêng trở nên không cần thiết.