Ngân hàng đề — Google Cloud Associate Data Practitioner

Đáp án

D — Cấp BigQuery Data Viewer ở cấp project, rồi CHẶN quyền truy cập bảng nhạy cảm bằng IAM Deny policy.

Vì sao đúng

Yêu cầu là truy vấn được MỌI bảng trong project nhưng KHÔNG được đụng vào đúng MỘT bảng. IAM Deny policy sinh ra cho đúng kiểu ngoại lệ này.

⚠ Điểm mấu chốt — deny THẮNG allow, luôn luôn:

Cấp roles/bigquery.dataViewer ở cấp PROJECT
        ↓
    → đọc được mọi dataset, mọi bảng
        ↓
    + IAM DENY POLICY cho employee_salaries
        ↓
    ⚠ DENY LUÔN THẮNG ALLOW
    → dù có bao nhiêu vai trò cho phép,
      bảng đó vẫn bị chặn

⚠ Vì sao cách này "hiệu quả nhất":

Cấp từng dataset một (phương án A)
        ↓
    ⚠ Có dataset MỚI → phải nhớ cấp thêm
    ⚠ Quên một lần → nhà phân tích kêu
    ⚠ Danh sách phình theo thời gian

Deny policy
        ↓
    → cấp MỘT lần ở cấp project
    → chặn ĐÚNG một ngoại lệ
    → dataset mới TỰ ĐỘNG dùng được
    → ngoại lệ vẫn được giữ

⚠ Deny policy trông thế nào:

{
  "displayName": "chan-bang-luong",
  "rules": [{
    "denyRule": {
      "deniedPrincipals": ["principal://.../analyst@congty.com"],
      "deniedPermissions": ["bigquery.tables.getData"],
      "resource": ".../datasets/hr/tables/employee_salaries"
    }
  }]
}

Xem thêm câu #12963, #12965 và #12969 (cùng lô): cùng chủ đề kiểm soát truy cập BigQuery nhưng khác yêu cầu — chia sẻ kết quả cho bên ngoài → authorized view; chặn một CỘT → policy tag; chặn một số DÒNG → row-level security. Bốn khoá khác nhau vì bốn phạm vi khác nhau — hoàn toàn nhất quán.

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

• A (cấp Data Viewer trên từng dataset không nhạy cảm) — đây là phương án gần nhất và chạy được, nhưng phải bảo trì thủ công mãi mãi: mỗi dataset mới lại phải nhớ cấp thêm. Đó chính là điều Deny policy loại bỏ.

• C (đưa bảng nhạy cảm sang project riêng) — cũng là cách tách bạch tốt về mặt kiến trúc, nhưng đây là thay đổi lớn về tổ chức dữ liệu, và đề hỏi cách cấp quyền, không phải cách tái cấu trúc.

• B (cấp Metadata Viewer ở cấp project) — chỉ cho xem tên bảng và lược đồ, không đọc được dữ liệu — không đáp ứng yêu cầu truy vấn.

Ghi nhớ

⚠ Bốn cơ chế kiểm soát truy cập BigQuery — bảng phải thuộc: | Cần chặn | Cơ chế | |---|---| | Một BẢNG cụ thể, giữa quyền rộng | IAM Deny policy | | Một số CỘT | column-level security (policy tag) | | Một số DÒNG | row-level security | | Chỉ lộ kết quả, giấu bảng gốc | authorized view | | Che giá trị theo vai trò | dynamic data masking |

Từ khoá nhận diện:

"cho tất cả trừ một bảng" → IAM Deny policy "ẩn một cột" → policy tag / column-level security "chỉ thấy dòng của mình" → row-level security "chia sẻ kết quả, giấu nguồn" → authorized view "chia sẻ dataset ra ngoài có quản trị" → Analytics Hub

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Deny policy đang có gì | gcloud iam policies list --attachment-point=... --kind=denypolicies | | Người này truy cập được không | Policy Troubleshooter | | Có ai lách được không | Policy Analyzer trên bảng nhạy cảm |

Và một điều nên cân nhắc bên cạnh deny policy: bảng lương có thật sự nên nằm chung project với dữ liệu phân tích không? Deny policy giải quyết gọn tình huống hiện tại, nhưng dữ liệu nhân sự đặt trong một project riêng với vòng người truy cập rất hẹp là ranh giới dễ giải thích với kiểm toán hơn nhiều — và không phụ thuộc vào việc ai đó nhớ duy trì một quy tắc ngoại lệ.

Đáp án

D — ML.PREDICT

Vì sao đúng

Mô hình đã huấn luyện xong, và việc cần làm là sinh dự đoán cho dữ liệu MỚI. ML.PREDICT là hàm của BigQuery ML cho đúng việc đó.

⚠ Điểm mấu chốt — cú pháp:

SELECT *
FROM ML.PREDICT(
  MODEL `my_models.customer_churn_model`,
  (SELECT * FROM `du_an.new_customers`)
);

        ↓
    Tham số 1: MODEL — mô hình đã huấn luyện
    Tham số 2: một TRUY VẤN CON cấp dữ liệu vào
        ↓
    ⚠ Bảng vào phải có ĐÚNG các cột đặc trưng
      đã dùng khi huấn luyện

⚠ Kết quả trả về với mô hình phân loại:

Các cột gốc của new_customers
    +
predicted_<label>
    → nhãn dự đoán, ví dụ "churn" / "no_churn"
    +
predicted_<label>_probs
    → MẢNG xác suất cho từng lớp
        ↓
    Lấy xác suất của một lớp:
      (SELECT prob FROM UNNEST(predicted_churn_probs)
       WHERE label = 'churn')

⚠ Bốn hàm ML. — mỗi hàm một giai đoạn:

HUẤN LUYỆN
    → CREATE MODEL (KHÔNG phải ML.TRAIN)

ĐÁNH GIÁ
    → ML.EVALUATE — mô hình tốt tới đâu

TÌM HIỂU ĐẶC TRƯNG
    → ML.FEATURE_INFO — thống kê đầu vào

DỰ ĐOÁN                        ← đề này
    → ML.PREDICT

⚠ Với bài toán rời bỏ khách hàng, đừng dừng ở nhãn:

predicted_label chỉ cho "có / không"
        ↓
    XÁC SUẤT hữu ích hơn nhiều:
      - xếp hạng khách theo rủi ro
      - chọn ngưỡng theo NGÂN SÁCH
        giữ chân khách
        ↓
    Ngưỡng 0,5 chỉ là mặc định,
    không phải ngưỡng đúng

Xem thêm câu #12919, #12928 và #12929 (lô 133): cùng chủ đề BigQuery ML — chọn công cụ, chọn loại mô hình phân cụm, chọn loại mô hình hồi quy. Câu này là bước cuối: dùng mô hình đã có.

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

• C (ML.EVALUATE) — đây là phương án gần nhất và là hàm rất hay dùng, nhưng nó đánh giá chất lượng mô hình trên dữ liệu đã có nhãn, trả về accuracy, AUC, precision — không sinh dự đoán cho dữ liệu mới.

• A (ML.TRAIN) — không tồn tại; huấn luyện dùng CREATE MODEL.

• B (ML.FEATURE_INFO) — trả về thống kê về các đặc trưng đầu vào (min, max, trung bình, số giá trị null), không dự đoán.

Ghi nhớ

⚠ Các hàm BigQuery ML — bảng phải thuộc: | Hàm | Việc | |---|---| | CREATE MODEL | huấn luyện — không phải ML.TRAIN | | ML.PREDICT | sinh dự đoán cho dữ liệu mới | | ML.EVALUATE | đo chất lượng mô hình | | ML.EXPLAIN_PREDICT | giải thích từng dự đoán | | ML.FEATURE_IMPORTANCE | đặc trưng nào quan trọng | | ML.FEATURE_INFO | thống kê đặc trưng đầu vào | | ML.CONFUSION_MATRIX | ma trận nhầm lẫn | | ML.TRAINING_INFO | quá trình huấn luyện | | ML.CENTROIDS | tâm cụm — cho KMEANS |

Từ khoá nhận diện:

"dự đoán cho dữ liệu mới" → ML.PREDICT "mô hình chính xác tới đâu" → ML.EVALUATE "vì sao dự đoán như vậy" → ML.EXPLAIN_PREDICT "huấn luyện" → CREATE MODEL "ML.TRAIN" → KHÔNG TỒN TẠI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình cần cột nào | SELECT * FROM ML.FEATURE_INFO(MODEL ...) | | Dự đoán có hợp lý không | so phân phối dự đoán với tỉ lệ rời bỏ thực tế | | Mô hình còn tốt không | ML.EVALUATE trên dữ liệu gần đây |

Và một bước rất đáng làm ngay sau lần dự đoán đầu tiên: so tỉ lệ dự đoán "sẽ rời bỏ" với tỉ lệ rời bỏ thực tế trong quá khứ. Nếu mô hình gắn cờ 40% khách hàng trong khi lịch sử chỉ có 5% rời bỏ, vấn đề nằm ở ngưỡng hoặc ở dữ liệu huấn luyện mất cân bằng — và phát hiện điều đó trước khi đội marketing gọi điện cho 40% khách hàng sẽ tiết kiệm rất nhiều.

Đáp án

C — Lưu kết quả truy vấn vào bảng mới, tạo Authorized View trên bảng đó, và chỉ cấp quyền cho tư vấn viên trên view.

Vì sao đúng

Yêu cầu tách rất rõ: tư vấn viên bên ngoài truy vấn được KẾT QUẢ TỔNG HỢP, nhưng tuyệt đối không chạm được vào bảng financials gốc. Authorized view là cơ chế của BigQuery cho đúng việc đó.

⚠ Điểm mấu chốt — authorized view phá vỡ chuỗi quyền thông thường:

BÌNH THƯỜNG
        ↓
    Muốn truy vấn một view
    → phải có quyền trên BẢNG GỐC
        ↓
    ⚠ tức là vẫn thấy được dữ liệu nhạy cảm

AUTHORIZED VIEW
        ↓
    View được UỶ QUYỀN trên dataset chứa
    bảng gốc
        ↓
    → người dùng chỉ cần quyền TRÊN VIEW
    → KHÔNG cần và KHÔNG có quyền
      trên bảng gốc
        ↓
    ⚠ Đây chính là điều đề yêu cầu

⚠ Ba bước triển khai:

1. Lưu kết quả tổng hợp
   CREATE TABLE ket_qua.tong_hop AS
   SELECT ... FROM financials GROUP BY ...

2. Tạo view ở DATASET KHÁC
   CREATE VIEW chia_se.bao_cao AS
   SELECT * FROM ket_qua.tong_hop;

3. UỶ QUYỀN cho view trên dataset nguồn
   → console: dataset ket_qua → Sharing
     → Authorize views → chọn chia_se.bao_cao

4. Cấp cho tư vấn viên:
   roles/bigquery.dataViewer trên dataset chia_se
   roles/bigquery.jobUser trên project của họ

⚠ Vì sao xuất ra Google Sheet lại kém an toàn:

Xuất sang Sheet
        ↓
    ⚠ Tạo một BẢN SAO — không thu hồi được
    ⚠ Tải xuống, chuyển tiếp thoải mái
    ⚠ Không cập nhật khi dữ liệu đổi
    ⚠ Không truy vấn được như bảng
    ⚠ Không có audit log truy cập
        ↓
    Đề nói "truy vấn được" và "an toàn nhất"

Xem thêm câu #12961, #12965 và #12969 (cùng lô): cùng họ kiểm soát truy cập BigQuery — chặn một BẢNG → deny policy; ẩn một CỘT → policy tag; lọc DÒNG → row-level security. Bốn khoá khác nhau vì bốn phạm vi khác nhau, nhất quán với nhau.

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

• B (xuất sang Google Sheet) — đây là phương án gần nhất về mặt "chia sẻ nhanh", nhưng nó tạo bản sao không thu hồi được, không truy vấn được như bảng, và không có nhật ký truy cập.

• A (cấp Data Viewer trên bảng financials) — cho phép truy cập thẳng bảng nhạy cảm — đúng điều đề cấm.

• D (dùng Analytics Hub cho bảng financials) — Analytics Hub là công cụ chia sẻ tốt, nhưng tạo listing cho chính bảng nhạy cảm là chia sẻ nguyên bảng gốc. (Chia sẻ một view qua Analytics Hub thì lại hợp lý.)

Ghi nhớ

⚠ Bốn cơ chế kiểm soát truy cập BigQuery — bảng phải thuộc: | Cần | Cơ chế | |---|---| | Chỉ lộ KẾT QUẢ, giấu bảng gốc | authorized view | | Chặn một BẢNG giữa quyền rộng | IAM Deny policy | | Ẩn một số CỘT | column-level security (policy tag) | | Lọc DÒNG theo người dùng | row-level security | | Chia sẻ dataset ra ngoài có quản trị | Analytics Hub |

Từ khoá nhận diện:

"chia sẻ kết quả, không cho thấy nguồn" → authorized view "tất cả trừ một bảng" → deny policy "ẩn cột lương" → policy tag "mỗi chi nhánh chỉ thấy dòng của mình" → row-level security "xuất ra Sheet/CSV rồi gửi" → hầu như luôn là phương án SAI về bảo mật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | View đã được uỷ quyền chưa | bq show --format=prettyjson <dataset nguồn> → access.view | | Tư vấn viên có đọc được bảng gốc không | Policy Troubleshooter trên bảng financials | | Họ đã truy vấn gì | Data Access audit log |

Và một rủi ro cần kiểm tra kỹ trước khi chia sẻ dữ liệu tài chính đã tổng hợp: nhóm quá nhỏ vẫn có thể lộ thông tin cá nhân. Một dòng "doanh thu theo chi nhánh" mà chi nhánh đó chỉ có một khách hàng thì thực chất đang tiết lộ đúng con số của khách hàng ấy — thêm ngưỡng số lượng tối thiểu vào chính view là cách phòng ngừa rẻ và hiệu quả.

Đáp án

B — Chọn một Region của Đức (ví dụ europe-west3) làm vị trí cho CẢ bucket và dataset.

Vì sao đúng

Chính sách yêu cầu dữ liệu PII được lưu và xử lý CHỈ TRONG nước Đức. Vị trí thực tế của tài nguyên là thứ duy nhất quyết định điều đó.

⚠ Điểm mấu chốt — vị trí là thuộc tính cố định, chọn lúc tạo:

BigQuery dataset
  bq mk --location=europe-west3 du_an:phan_tich

Cloud Storage bucket
  gcloud storage buckets create gs://du-lieu-tho \
    --location=europe-west3
        ↓
    ⚠ VỊ TRÍ KHÔNG ĐỔI ĐƯỢC sau khi tạo
    → sai thì phải tạo mới và chép lại

⚠ Vì sao "Europe" là chưa đủ:

Multi-region EU
        ↓
    Dữ liệu nằm trong LÃNH THỔ CHÂU ÂU,
    nhưng có thể ở Bỉ, Hà Lan, Phần Lan...
        ↓
    ⚠ Chính sách nói CHỈ TRONG NƯỚC ĐỨC
        ↓
    → phải là REGION CỤ THỂ của Đức:
        europe-west3 (Frankfurt)
        europe-west10 (Berlin)

⚠ "Xử lý" cũng phải trong Đức, không chỉ "lưu":

Dữ liệu ở europe-west3
        ↓
    Nhưng job Dataflow chạy ở us-central1
        ↓
    ⚠ Dữ liệu ĐI RA khỏi Đức để xử lý
        ↓
    → MỌI dịch vụ xử lý cũng phải
      đặt ở europe-west3:
      Dataflow, Dataproc, Cloud Run,
      Composer, và cả job BigQuery
        ↓
    ⚠ BigQuery job chạy ở CHÍNH Region
      của dataset — điểm này thì tự động

Xem thêm câu #12921 (lô 133): cũng chọn vị trí bucket theo người dùng, ở đó là Úc vì lý do độ trễ. Câu này chọn theo chủ quyền dữ liệu. Cùng một quyết định kỹ thuật, hai lý do khác nhau — cả hai đều dẫn tới region cụ thể.

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

• A (Organization Policy giới hạn vị trí ở Europe) — đây là phương án gần nhất và là một biện pháp CƯỠNG CHẾ rất tốt nên có thêm, nhưng "Europe" rộng hơn nước Đức, và bản thân chính sách không tạo ra tài nguyên ở đúng chỗ — bạn vẫn phải chọn vị trí khi tạo. (Chính sách nên đặt là danh sách Region của Đức.)

• D (bật CMEK với khoá từ key ring ở Đức) — kiểm soát khoá mã hoá, nhưng dữ liệu vẫn có thể nằm ở Region khác.

• C (gắn nhãn location:germany) — nhãn không cưỡng chế gì cả, chỉ để phân loại và tính chi phí.

Ghi nhớ

⚠ Chủ quyền dữ liệu — bốn lớp, dùng cùng nhau: | Lớp | Việc | |---|---| | Chọn REGION cụ thể khi tạo | quyết định dữ liệu nằm ở đâu | | Organization Policy gcp.resourceLocations | CHẶN tạo tài nguyên ngoài vùng cho phép | | CMEK với key ring cùng Region | kiểm soát khoá | | VPC Service Controls | chống dữ liệu bị chuyển ra ngoài | | Assured Workloads | gói tuân thủ có sẵn cho một số khu vực |

Từ khoá nhận diện:

"dữ liệu phải ở trong nước X" → chọn REGION cụ thể của nước đó "ngăn người khác tạo tài nguyên sai chỗ" → Organization Policy resourceLocations "tự quản khoá mã hoá" → CMEK "chống rò rỉ ra ngoài vành đai" → VPC Service Controls "nhãn để tuân thủ" → nhãn KHÔNG cưỡng chế gì

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dataset ở đâu | bq show --format=prettyjson <dataset> → location | | Bucket ở đâu | gcloud storage buckets describe gs://b --format="value(location)" | | Có tài nguyên nào sai chỗ không | Cloud Asset Inventory, lọc theo vị trí |

Và một chi tiết rất hay bị bỏ sót trong dự án có yêu cầu chủ quyền dữ liệu: vị trí của log bucket trong Cloud Logging. Dữ liệu chính nằm đúng chỗ, nhưng audit log và log ứng dụng — vốn có thể chứa cả PII trong thông báo lỗi — lại mặc định đi về vị trí global. Đặt log bucket theo đúng Region là bước nên làm cùng lúc với việc tạo dataset.

Đáp án

A — Định nghĩa policy tag (ví dụ Confidential) trong Data Catalog, gắn vào cột salary trong lược đồ, và cấu hình IAM sao cho nhà phân tích KHÔNG có vai trò Fine-Grained Reader.

Vì sao đúng

Đề yêu cầu rõ ba điều: chặn truy cập MỘT CỘT, theo quyền tối thiểu, và bằng cách CÓ THỂ MỞ RỘNG và QUẢN TRỊ ĐƯỢC. Column-level security bằng policy tag là cơ chế duy nhất thoả cả ba.

⚠ Điểm mấu chốt — bảo vệ gắn vào CỘT, không gắn vào truy vấn:

Tạo taxonomy trong Data Catalog / Dataplex
        ↓
    Policy tag: "Confidential"
        ↓
    Gắn vào cột `salary` trong LƯỢC ĐỒ bảng
        ↓
    Ai muốn đọc cột đó phải có
      roles/datacatalog.categoryFineGrainedReader
      trên policy tag ấy
        ↓
    ⚠ Nhà phân tích KHÔNG có vai trò đó
    → SELECT * cũng KHÔNG trả về cột salary
    → truy vấn đích danh salary thì BỊ TỪ CHỐI

⚠ Vì sao cách này "mở rộng và quản trị được":

Cùng một policy tag dùng cho
    NHIỀU CỘT, ở NHIỀU BẢNG,
    trong NHIỀU DATASET
        ↓
    Cấp hay thu hồi quyền MỘT LẦN
    trên chính policy tag
        ↓
    → mọi cột mang tag đó đổi theo
        ↓
    So với authorized view:
      mỗi bảng lại phải tạo và bảo trì
      một view riêng

⚠ Vì sao authorized view kém hơn TRONG TÌNH HUỐNG NÀY:

CREATE VIEW ... AS SELECT * EXCEPT(salary)
        ↓
    ⚠ Hoạt động được, nhưng:
      - bảng thêm cột nhạy cảm mới
        → phải nhớ sửa view
      - có N bảng → N view phải bảo trì
      - bảo vệ nằm ở VIEW, không nằm ở CỘT
        → ai có quyền bảng gốc vẫn thấy hết
        ↓
    Với column-level security:
      bảo vệ đi THEO CỘT ở mọi nơi

Xem thêm câu #12961, #12963 và #12969 (cùng lô): cùng họ kiểm soát truy cập — chặn một BẢNG → deny policy; chia sẻ kết quả ra ngoài → authorized view; lọc DÒNG → row-level security. Bốn khoá khác nhau theo phạm vi cần chặn, hoàn toàn nhất quán.

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

• B (authorized view với SELECT * EXCEPT(salary)) — đây là phương án gần nhất và thực sự chạy được, nhưng phải bảo trì thủ công theo từng bảng, và bảo vệ gắn vào view chứ không gắn vào cột. Đề nhấn mạnh "mở rộng và quản trị được".

• D (dynamic data masking trả về NULL) — cũng là tính năng thật và hữu ích, nhưng nó che GIÁ TRỊ chứ không CHẶN truy cập; đề nói "phải bị ngăn truy cập cột lương trong mọi hoàn cảnh", và cách chặt chẽ hơn là column-level security. (Masking thường dùng khi vẫn muốn truy vấn chạy được bình thường.)

• C (cấp dataViewer rồi tin tưởng người dùng) — không phải biện pháp kỹ thuật nào cả, vi phạm hoàn toàn nguyên tắc quyền tối thiểu.

Ghi nhớ

⚠ Column-level security — bảng phải thuộc: | Thành phần | Việc | |---|---| | Taxonomy | cây phân loại mức nhạy cảm | | Policy tag | nhãn gắn vào CỘT, ví dụ Confidential, PII | | roles/datacatalog.categoryFineGrainedReader | vai trò cho phép ĐỌC cột mang tag | | Không có vai trò | cột bị chặn, kể cả với SELECT * | | Phạm vi | một tag dùng cho nhiều cột, nhiều bảng | | Quản lý ở | Dataplex Universal Catalog (trước là Data Catalog) |

Từ khoá nhận diện:

"chặn một CỘT, có thể mở rộng, quản trị được" → policy tag / column-level security "che giá trị nhưng vẫn truy vấn được" → dynamic data masking "chỉ thấy một số DÒNG" → row-level security "chia sẻ kết quả, giấu bảng gốc" → authorized view "chặn cả một bảng" → IAM Deny policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột nào mang tag gì | bq show --schema --format=prettyjson <bảng> | | Ai đọc được cột nhạy cảm | gcloud data-catalog taxonomies policy-tags get-iam-policy | | Cưỡng chế đã bật chưa | trạng thái Data Policy trong Dataplex |

Và một bước nên làm trước khi gắn tag thủ công cho từng cột: chạy Sensitive Data Protection quét toàn bộ dataset. Nó tìm ra những cột chứa PII mà không ai nhớ tới — số điện thoại lẫn trong trường ghi chú, email trong cột mô tả — và danh sách đó thường dài hơn đáng kể so với những gì đội dữ liệu tự liệt kê được.

Đáp án

C — Dead-letter queue (hàng đợi thư chết).

Vì sao đúng

Mẫu thiết kế được mô tả trong đề — tách bản ghi HỎNG ra một đường riêng thay vì để chúng làm chết cả pipeline — được gọi là dead-letter pattern.

⚠ Điểm mấu chốt — chia luồng thành hai nhánh:

Đọc CSV
        ↓
    Kiểm tra customer_id:
      khác NULL và là số nguyên dương?
        ↓
    ┌──── HỢP LỆ ────→ bảng "clean"
    │
    └──── KHÔNG HỢP LỆ ──→ bảng "error"
                            (dead-letter)
        ↓
    ⚠ Pipeline KHÔNG DỪNG vì vài dòng hỏng
    ⚠ Dòng hỏng KHÔNG bị mất

⚠ Trong Apache Beam, cơ chế là TupleTag và output phụ:

HOP_LE = TupleTag('hop_le')
HONG    = TupleTag('hong')

class KiemTra(beam.DoFn):
    def process(self, dong):
        if dong.get('customer_id') and dong['customer_id'] > 0:
            yield beam.pvalue.TaggedOutput('hop_le', dong)
        else:
            yield beam.pvalue.TaggedOutput(
                'hong', {'dong': str(dong),
                         'ly_do': 'customer_id khong hop le'})

        ↓
    ⚠ Bản ghi hỏng nên kèm LÝ DO,
      dấu thời gian, và nội dung GỐC

⚠ Vì sao mẫu này quan trọng đến vậy:

KHÔNG có dead-letter
        ↓
    Lựa chọn 1: pipeline CHẾT vì một dòng xấu
        → dữ liệu tốt cũng không vào được
    Lựa chọn 2: âm thầm BỎ QUA dòng xấu
        → mất dữ liệu, không ai biết
        ↓
    CÓ dead-letter
        ↓
    → dữ liệu tốt vẫn chảy
    → dữ liệu xấu được GIỮ LẠI để điều tra
    → đếm được, cảnh báo được

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

• A (fan-out) — đây là phương án gần nhất về mặt "chia thành nhiều nhánh", nhưng fan-out là gửi CÙNG một dữ liệu tới NHIỀU đích; ở đây dữ liệu được phân loại rồi đi hai đường khác nhau.

• B (side input) — cơ chế của Beam để đưa thêm một tập dữ liệu phụ vào phép biến đổi (bảng tra cứu), không liên quan tới xử lý bản ghi hỏng.

• D (windowing) — nhóm dữ liệu theo thời gian trong pipeline luồng.

Ghi nhớ

⚠ Các mẫu thiết kế trong pipeline dữ liệu — bảng phải thuộc: | Mẫu | Việc | |---|---| | Dead-letter queue | tách bản ghi HỎNG ra đường riêng | | Fan-out | một nguồn → NHIỀU đích cùng dữ liệu | | Fan-in | nhiều nguồn gộp về một | | Side input | đưa tập dữ liệu phụ vào phép biến đổi | | Windowing | nhóm theo thời gian trong luồng | | Idempotency | xử lý lại không sinh sai lệch |

Từ khoá nhận diện:

"tách dữ liệu tốt và xấu" → dead-letter "cùng dữ liệu tới nhiều hệ thống" → fan-out (Pub/Sub nhiều subscription) "bảng tra cứu nhỏ dùng trong xử lý" → side input "tổng hợp mỗi 5 phút" → windowing "thông điệp thất bại nhiều lần" → dead-letter topic của Pub/Sub

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ lỗi bao nhiêu | SELECT COUNT(*) FROM error_table so với bảng clean | | Lý do nào phổ biến nhất | GROUP BY ly_do ORDER BY COUNT(*) DESC | | Lỗi có tăng đột biến không | cảnh báo dựa trên chỉ số tuỳ chỉnh của Dataflow |

Và điều quyết định một dead-letter queue có ích hay không: có ai thật sự nhìn vào nó hay không. Rất nhiều pipeline có bảng lỗi được ghi đều đặn suốt nhiều tháng mà không ai mở ra, cho tới khi một báo cáo thiếu số liệu — hãy đặt một cảnh báo theo tỉ lệ lỗi ngay khi tạo bảng, chứ không để sau.

Đáp án

C — Một bucket multi-region kết hợp với Cloud CDN.

Vì sao đúng

Đề có ba ràng buộc: người dùng ở CẢ Bắc Mỹ và châu Âu, độ trễ thấp cho cả hai, và MỘT giải pháp duy nhất kèm sẵn sàng cao mặc định. Chỉ phương án kết hợp mới thoả cả ba.

⚠ Điểm mấu chốt — mỗi thành phần giải một phần của bài toán:

MULTI-REGION BUCKET
        ↓
    Dữ liệu nhân bản qua nhiều Region
        ↓
    → SẴN SÀNG CAO mặc định
    → một bucket duy nhất, một giải pháp

CLOUD CDN
        ↓
    Đệm nội dung ở HÀNG TRĂM ĐIỂM BIÊN
    trên toàn thế giới
        ↓
    → độ trễ thấp cho CẢ HAI châu lục
    → ảnh phục vụ từ điểm gần người dùng nhất

⚠ Vì sao chỉ multi-region là chưa đủ:

Multi-region US
        ↓
    Dữ liệu nhân bản trong nước Mỹ
        ↓
    ⚠ Người dùng châu Âu vẫn phải
      vượt Đại Tây Dương cho MỖI ảnh
        ↓
    Multi-region không phải CDN:
      nó lo ĐỘ BỀN và SẴN SÀNG,
      không lo ĐỘ TRỄ toàn cầu

⚠ Vì sao ảnh hồ sơ là trường hợp lý tưởng cho CDN:

Ảnh hồ sơ người dùng
        ↓
    - ĐỌC rất nhiều lần, ghi rất ít
    - Nội dung TĨNH, không đổi
    - Cùng một ảnh phục vụ nhiều người
        ↓
    → tỉ lệ trúng cache rất cao
    → giảm cả ĐỘ TRỄ lẫn CHI PHÍ EGRESS
        ↓
    Đặt Cache-Control hợp lý:
      Cache-Control: public, max-age=86400

⚠ Cách nối CDN vào bucket:

Global external Application Load Balancer
        ↓
    Backend bucket trỏ tới bucket GCS
        ↓
    Bật Cloud CDN trên backend đó
        ↓
    → một địa chỉ IP toàn cầu
    → anycast tự chọn điểm gần nhất

Xem thêm câu #12921 (lô 133): cũng hỏi vị trí bucket cho ứng dụng ảnh, nhưng ở đó người dùng CHỈ ở Úc → khoá là một Region cụ thể. Hai khoá khác nhau vì phạm vi người dùng khác nhau — không mâu thuẫn. Quy tắc: một khu vực → region; nhiều châu lục → multi-region + CDN.

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

• A (multi-region US) và B (multi-region EU) — mỗi phương án chỉ phục vụ tốt MỘT châu lục; bên còn lại chịu độ trễ xuyên đại dương. Đề yêu cầu tốt cho cả hai.

• D (dual-region us-central1 và us-east1) — cả hai Region đều ở Mỹ, nên không giúp gì cho người dùng châu Âu.

Ghi nhớ

⚠ Chọn vị trí bucket theo phạm vi người dùng — bảng phải thuộc: | Người dùng ở | Chọn | |---|---| | Một khu vực | region cụ thể — rẻ nhất, độ trễ thấp nhất tại chỗ | | Hai Region cụ thể | dual-region | | Một châu lục | multi-region (US, EU, ASIA) | | NHIỀU CHÂU LỤC | multi-region + Cloud CDN | | Ghi nhớ | CDN giải bài toán ĐỘ TRỄ; multi-region giải bài toán SẴN SÀNG |

Từ khoá nhận diện:

"nhiều châu lục, độ trễ thấp, một giải pháp" → multi-region + Cloud CDN "người dùng một nước" → region cụ thể "chịu lỗi Region nhưng vẫn gần người dùng" → dual-region "nội dung động, không cache được" → CDN ít giúp; cân nhắc nhiều Region "dữ liệu phải ở trong nước" → region cụ thể + Organization Policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ trúng cache | Monitoring → chỉ số của Cloud CDN | | Ảnh có được cache không | xem header Age và Cache-Control trong phản hồi | | Độ trễ thực tế | đo từ máy khách ở cả hai châu lục |

Và một quy ước rất đáng áp dụng ngay từ đầu với nội dung phục vụ qua CDN: đặt tên tệp có phiên bản và đừng bao giờ ghi đè. Khi người dùng đổi ảnh đại diện, tải lên một tên mới thay vì ghi đè tên cũ — cách đó cho phép đặt thời gian cache rất dài mà vẫn cập nhật tức thì, và tránh hoàn toàn việc phải dùng cơ chế vô hiệu hoá cache vốn chậm và bị giới hạn.

Đáp án

C — Tạm khoá câu SELECT cuối và thay bằng SELECT * FROM bang_trung_gian;

Vì sao đúng

Mệnh đề WITH (CTE — common table expression) tạo ra các tập kết quả có tên, và bạn hoàn toàn truy vấn được trực tiếp bất kỳ CTE nào bằng cách đổi câu SELECT cuối cùng.

⚠ Điểm mấu chốt — CTE có tên nên gọi thẳng được:

WITH
  don_hang_loc AS (
    SELECT * FROM `du_an.don_hang` WHERE nam = 2026
  ),
  tong_theo_khach AS (
    SELECT khach_id, SUM(tien) AS tong
    FROM don_hang_loc GROUP BY khach_id
  )

-- SELECT ... phần tính toán phức tạp và tốn kém
SELECT * FROM tong_theo_khach LIMIT 100;

        ↓
    ⚠ Chỉ đổi DÒNG CUỐI
    → thấy ngay kết quả của bước giữa
    → phần sau chưa chạy, chưa tốn tiền

⚠ Vì sao cách này còn RẺ HƠN:

BigQuery chỉ tính tiền cho
    dữ liệu THỰC SỰ QUÉT
        ↓
    Dừng ở CTE trung gian
        ↓
    → các bước sau KHÔNG chạy
    → JOIN nặng phía sau KHÔNG chạy
        ↓
    ⚠ Thêm LIMIT không giảm byte quét,
      nhưng CẮT BỚT CÁC BƯỚC thì có

⚠ Hai cách khác cũng rất hữu ích:

1. --dry_run
   bq query --dry_run --use_legacy_sql=false '...'
       → biết TRƯỚC sẽ quét bao nhiêu byte,
         KHÔNG tốn tiền

2. Bảng tạm hoặc materialize từng bước
   CREATE TEMP TABLE buoc_1 AS (...);
   SELECT * FROM buoc_1;
       → giữ kết quả để dùng lại nhiều lần

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

• B (không xem được CTE trung gian, phải chạy cả truy vấn) — đây là phương án dễ tin nhất nếu chưa thử, nhưng sai: CTE có tên và truy vấn thẳng được.

• D (chạy cả truy vấn rồi lọc kết quả cuối) — tốn đúng cái mà đề muốn tránh: chạy hết truy vấn đắt tiền.

• A (dùng ML.PREDICT để lấy mẫu) — ML.PREDICT là hàm dự đoán của BigQuery ML, không liên quan gì tới việc xem kết quả trung gian.

Ghi nhớ

⚠ Gỡ lỗi truy vấn phức tạp — bảng phải thuộc: | Cách | Việc | |---|---| | Đổi SELECT cuối thành SELECT * FROM <cte> | xem kết quả bước giữa | | --dry_run | biết trước số byte quét, MIỄN PHÍ | | CREATE TEMP TABLE | giữ kết quả bước giữa để dùng lại | | maximum_bytes_billed | trần an toàn | | Execution details | xem bước nào tốn nhất | | Query validator trong UI | ước tính byte ngay khi gõ |

Từ khoá nhận diện:

"xem kết quả CTE trung gian" → đổi SELECT cuối "biết trước truy vấn tốn bao nhiêu" → --dry_run "đặt trần chi phí" → maximum_bytes_billed "bước nào chậm" → Execution details "lưu kết quả trung gian để dùng lại" → CREATE TEMP TABLE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước giữa cho ra gì | đổi SELECT cuối rồi chạy | | Truy vấn sẽ tốn bao nhiêu | --dry_run | | Bước nào chậm nhất | Execution details |

Và một thói quen tiết kiệm rất nhiều tiền khi làm việc với bảng lớn: --dry_run trước mỗi truy vấn mới. Nó không tốn gì, trả lời trong một giây, và cho biết chính xác truy vấn sắp chạy sẽ quét bao nhiêu byte — đủ để bạn kịp nhận ra một điều kiện lọc bị viết sai trước khi nó quét vài chục terabyte.

Đáp án

C — Row-level security (bảo mật ở cấp DÒNG).

Vì sao đúng

Yêu cầu là service account chỉ nhìn thấy các DÒNG có customer_id thuộc phạm vi được giao. Đó chính là định nghĩa của row-level security.

⚠ Điểm mấu chốt — bộ lọc gắn vào chính BẢNG:

CREATE ROW ACCESS POLICY loc_theo_khach
ON `du_an.giao_dich`
GRANT TO ('serviceAccount:sa-a@du-an.iam.gserviceaccount.com')
FILTER USING (customer_id IN ('KH001','KH002','KH003'));

        ↓
    Service account chạy:
      SELECT * FROM giao_dich
        ↓
    ⚠ BigQuery TỰ THÊM điều kiện lọc
    → chỉ trả về ba khách hàng đó
    → dòng khác coi như KHÔNG TỒN TẠI
        ↓
    ⚠ Kể cả COUNT(*) cũng chỉ đếm
      phần được phép thấy

⚠ Cách viết bộ lọc động theo người truy cập:

CREATE ROW ACCESS POLICY loc_theo_nguoi_dung
ON `du_an.giao_dich`
GRANT TO ('group:doi-ban-hang@congty.com')
FILTER USING (
  nguoi_phu_trach = SESSION_USER()
);

        ↓
    SESSION_USER() trả về danh tính
    của người đang chạy truy vấn
        ↓
    → MỘT chính sách phục vụ CẢ ĐỘI
    → mỗi người tự thấy phần của mình
        ↓
    Hoặc JOIN với bảng ánh xạ
    người dùng ↔ khách hàng

⚠ Ba cơ chế bảo mật chi tiết của BigQuery — phân biệt dứt điểm:

ROW-LEVEL SECURITY
    → lọc DÒNG                    ← đề này

COLUMN-LEVEL SECURITY (policy tag)
    → ẩn CỘT

DYNAMIC DATA MASKING
    → che GIÁ TRỊ của cột
        ↓
    Dùng được ĐỒNG THỜI cả ba

Xem thêm câu #12961, #12963 và #12965 (cùng lô): cùng họ kiểm soát truy cập — chặn một BẢNG → deny policy; chia sẻ kết quả → authorized view; ẩn một CỘT → policy tag. Bốn khoá khác nhau theo phạm vi cần chặn — hoàn toàn nhất quán.

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

• B (Authorized View) — đây là phương án gần nhất và cũng lọc dòng được bằng WHERE trong view, nhưng phải tạo và bảo trì MỘT VIEW cho MỖI nhóm quyền. Với nhiều service account phụ trách các tập khách hàng khác nhau, cách đó không mở rộng nổi.

• D (Column-level security) — ẩn CỘT, không lọc dòng.

• A (Authorized Datasets) — cơ chế uỷ quyền cả một dataset truy cập dataset khác; không phải cơ chế lọc dòng.

Ghi nhớ

⚠ Ba cơ chế bảo mật chi tiết của BigQuery — bảng phải thuộc: | Cơ chế | Ẩn gì | Cấu hình bằng | |---|---|---| | Row-level security | DÒNG | CREATE ROW ACCESS POLICY | | Column-level security | CỘT | policy tag trong lược đồ | | Dynamic data masking | GIÁ TRỊ của cột | data policy trên policy tag | | Dùng chung được | có, cả ba cùng lúc |

Từ khoá nhận diện:

"chỉ thấy dòng của mình / của khách hàng được giao" → row-level security "ẩn cột lương" → column-level security "vẫn truy vấn được nhưng giá trị bị che" → dynamic data masking "chia sẻ kết quả, giấu bảng gốc" → authorized view "tất cả trừ một bảng" → IAM Deny policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có chính sách nào | INFORMATION_SCHEMA.ROW_ACCESS_POLICIES | | Service account thấy bao nhiêu dòng | chạy COUNT(*) dưới danh nghĩa tài khoản đó | | Có ai lách được không | Policy Analyzer và Data Access log |

Và một điều cần dặn trước với đội phân tích khi bật row-level security: cùng một truy vấn sẽ cho ra những con số khác nhau tuỳ người chạy. Đó là hành vi đúng và mong muốn, nhưng nếu không nói rõ, hai người so kết quả với nhau sẽ kết luận rằng dữ liệu bị lỗi — và đi tìm một vấn đề không hề tồn tại.

Đáp án

C — Một công cụ ĐIỀU PHỐI (orchestration tool).

Vì sao đúng

Đề mô tả nhiều bước qua nhiều dịch vụ khác nhau, với ràng buộc bước sau chỉ chạy khi bước trước THÀNH CÔNG. Quản lý thứ tự và phụ thuộc giữa các bước chính là định nghĩa của điều phối.

⚠ Điểm mấu chốt — điều phối ↔ xử lý, hai việc khác nhau:

CÔNG CỤ XỬ LÝ (processing engine)
        ↓
    BIẾN ĐỔI dữ liệu
    → Dataproc, Dataflow, BigQuery
    → "làm việc"

CÔNG CỤ ĐIỀU PHỐI (orchestration)
        ↓
    QUYẾT ĐỊNH việc nào chạy, khi nào,
    theo thứ tự nào, hỏng thì làm gì
    → Cloud Composer, Workflows
    → "chỉ huy"
        ↓
    ⚠ Điều phối KHÔNG tự xử lý dữ liệu

⚠ Ba đặc điểm bắt buộc phải có điều phối:

1. NHIỀU bước qua NHIỀU dịch vụ
2. PHỤ THUỘC: A xong mới tới B
3. Cần THỬ LẠI, theo dõi, cảnh báo
        ↓
    Có đủ ba → cần orchestration tool

⚠ Trên Google Cloud, "công cụ điều phối" là những gì:

CLOUD COMPOSER (Apache Airflow)
    → DAG phức tạp, nhiều phụ thuộc,
      backfill, hàng trăm operator

WORKFLOWS
    → luồng nhẹ, khai bằng YAML,
      trả tiền theo bước

CLOUD SCHEDULER
    → chỉ kích hoạt theo giờ,
      KHÔNG quản lý phụ thuộc

DATAFORM
    → điều phối các bước SQL
      trong BigQuery

Xem thêm câu #12948 (cùng lô): mô tả gần như cùng một tình huống nhưng hỏi DỊCH VỤ NÀO → khoá là Cloud Composer. Câu này hỏi LOẠI công cụ → orchestration. Hai khoá khác nhau vì mức độ câu hỏi khác nhau, hoàn toàn nhất quán.

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

• B (công cụ xử lý dữ liệu) — đây là phương án gần nhất vì luồng có chứa job Dataproc và truy vấn BigQuery, nhưng đó là các bước BÊN TRONG luồng. Thứ cần thêm là công cụ quản lý thứ tự và phụ thuộc giữa chúng.

• A (dịch vụ lưu trữ dữ liệu) — nơi chứa dữ liệu, không điều khiển luồng công việc.

• D (nền tảng BI) — trực quan hoá và báo cáo, ở cuối chuỗi chứ không điều phối.

Ghi nhớ

⚠ Bốn phạm trù công cụ dữ liệu — bảng phải thuộc: | Phạm trù | Việc | Ví dụ | |---|---|---| | Lưu trữ | chứa dữ liệu | Cloud Storage, BigQuery, Cloud SQL | | Xử lý | biến đổi dữ liệu | Dataflow, Dataproc, Data Fusion | | Điều phối | quản lý thứ tự và phụ thuộc | Cloud Composer, Workflows | | BI / trực quan hoá | hiển thị cho người dùng | Looker, Looker Studio | | Một pipeline hoàn chỉnh | thường có cả bốn |

Từ khoá nhận diện:

"bước sau chạy khi bước trước thành công" → điều phối "biến đổi, tổng hợp dữ liệu" → xử lý "nơi chứa" → lưu trữ "biểu đồ, dashboard" → BI "chạy đúng giờ, một việc" → lập lịch — nhẹ hơn điều phối

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước nào hỏng | giao diện của công cụ điều phối | | Luồng có chậm dần không | so thời lượng theo ngày | | Có bước nào chạy trùng không | kiểm tra khoá chống chạy chồng |

Và một ranh giới đáng giữ nghiêm khi thiết kế: bộ điều phối ra lệnh, engine làm việc. Khi một tác vụ Airflow bắt đầu tự đọc và biến đổi vài triệu dòng dữ liệu, đó là dấu hiệu ranh giới đã bị vượt — và hệ quả thường là môi trường điều phối trở thành nút thắt cho toàn bộ hệ thống dữ liệu.