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

Đáp án

A — Định nghĩa row-level security policy trên bảng BigQuery, với biểu thức lọc cho từng vùng.

Vì sao đúng

Đề nêu ba yêu cầu: một bảng duy nhất, mỗi nhà phân tích chỉ thấy dòng của vùng mình, cưỡng chế NGAY LÚC TRUY VẤN và KHÔNG tạo bản sao. Row-level security của BigQuery làm đúng cả ba.

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

CREATE ROW ACCESS POLICY loc_mien_bac
ON `du_an.ban_hang`
GRANT TO ('group:phan-tich-mien-bac@congty.com')
FILTER USING (khu_vuc = 'Mien Bac');

CREATE ROW ACCESS POLICY loc_mien_nam
ON `du_an.ban_hang`
GRANT TO ('group:phan-tich-mien-nam@congty.com')
FILTER USING (khu_vuc = 'Mien Nam');

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

⚠ Vì sao "authorized view cho từng vùng" kém hơn:

Tạo một view cho mỗi vùng
        ↓
    ⚠ Có N vùng → N view phải bảo trì
    ⚠ Thêm vùng mới → tạo view mới,
      cấp quyền mới
    ⚠ Đổi cấu trúc bảng → sửa N view
    ⚠ Người dùng phải biết trỏ vào view nào
        ↓
    Row-level security
        ↓
    → MỘT bảng, MỘT tên, N chính sách
    → thêm vùng chỉ là thêm một policy

⚠ Bộ lọc động — mở rộng tốt hơn nữa:

CREATE ROW ACCESS POLICY loc_theo_nguoi_dung
ON `du_an.ban_hang`
GRANT TO ('group:phan-tich@congty.com')
FILTER USING (
  khu_vuc IN (
    SELECT khu_vuc FROM `du_an.anh_xa_nguoi_dung`
    WHERE email = SESSION_USER()
  )
);

        ↓
    ⚠ Thêm người mới chỉ cần THÊM DÒNG
      vào bảng ánh xạ
    → không sửa chính sách

Xem thêm câu #12969 (lô 134): cùng khoá row-level security cho service account chỉ thấy một số khách hàng. Hai câu hoàn toàn nhất quán. Và #13035/#13046 (lô 136): cùng bài toán nhưng ở tầng LOOKER với access_filter — khác TẦNG áp dụng, không mâu thuẫn.

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

• C (tạo authorized view riêng cho từng vùng) — đây là phương án gần nhất và cho kết quả đúng, nhưng không mở rộng được: mỗi vùng một view phải tạo và bảo trì, và người dùng phải biết trỏ vào view nào.

• B (phân vùng theo khu vực và hạn chế quyền ở cấp dataset) — phân vùng là cơ chế TỐI ƯU CHI PHÍ, không phải bảo mật; và quyền ở cấp dataset áp cho cả bảng, không lọc được theo dòng.

• D (column-level security với policy tag trên cột khu_vuc) — ẩn CỘT, không lọc DÒNG; người dùng vẫn thấy toàn bộ dòng, chỉ mất một cột.

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ả ba cùng lúc | | Khác | authorized view — chỉ lộ kết quả của view |

Từ khoá nhận diện:

"mỗi người chỉ thấy dòng của vùng mình, một bảng" → 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 "phân vùng để bảo mật" → SAI — phân vùng là tối ưu chi phí

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 | | Người này 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 nên thông báo 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 nhà phân tích so kết quả với nhau sẽ kết luận rằng dữ liệu bị lỗi — và mất cả buổi đi tìm một vấn đề không hề tồn tại.

Đáp án

C — Data Catalog (nay là Dataplex Universal Catalog) cho từ điển thuật ngữ nghiệp vụ, và policy tag của BigQuery cho việc che dữ liệu.

Vì sao đúng

Đề nêu hai nhu cầu tách biệt, và mỗi nhu cầu có một tính năng riêng — nhưng cả hai đều nằm trong cùng một hệ thống quản trị dữ liệu.

⚠ Điểm mấu chốt — hai nhu cầu, hai tính năng, một nền tảng:

"tìm dataset bằng THUẬT NGỮ NGHIỆP VỤ
 như 'Net Revenue'"
        ↓
    → BUSINESS GLOSSARY của Data Catalog
    → gắn thuật ngữ vào bảng và cột
    → nhà phân tích gõ tiếng nghiệp vụ,
      tìm ra bảng kỹ thuật

"tự động CHE cột PII khi truy vấn"
        ↓
    → POLICY TAG gắn vào cột trong lược đồ
    → cưỡng chế NGAY TRONG BigQuery
        ↓
    ⚠ Hai tính năng này CÙNG THUỘC
      Dataplex Universal Catalog

⚠ Cách hai thứ nối với nhau:

Trong Dataplex Catalog:
    TAXONOMY "Mức nhạy cảm"
        ↓
      POLICY TAG "PII"
        ↓
    Gắn tag vào cột email, so_dien_thoai
        ↓
    DATA POLICY khai quy tắc CHE
        ↓
    Cấp vai trò cho từng nhóm:
      maskedReader     → thấy bản CHE
      FineGrainedReader → thấy ĐẦY ĐỦ
      không có gì      → BỊ TỪ CHỐI

⚠ Vì sao IAM một mình không đủ:

IAM
        ↓
    Kiểm soát AI vào được DATASET/BẢNG
        ↓
    ⚠ KHÔNG che được TỪNG CỘT
    ⚠ KHÔNG có từ điển thuật ngữ
        ↓
    → policy tag là lớp bổ sung
      NGAY TRÊN IAM

Xem thêm câu #13109 (lô 137): khoá Dataplex Universal Catalog cho nhu cầu phát hiện, dòng dõi, chất lượng, từ điển. Và #12965 (lô 134): khoá policy tag để chặn cột lương. Ba câu nhất quán — cùng một hệ thống nhìn từ ba góc.

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

• D (Analytics Hub để tìm kiếm, IAM để che) — đây là phương án gần nhất vì cả hai đều là dịch vụ thật, nhưng Analytics Hub dùng để CHIA SẺ dataset, không phải công cụ tìm kiếm bằng thuật ngữ nghiệp vụ; và IAM không che được cột.

• B (Dataprep để tìm kiếm, Dataflow để che) — Dataprep là công cụ làm sạch trực quan, Dataflow là engine xử lý; không cái nào là công cụ quản trị và tìm kiếm.

• A (Cloud Monitoring và Cloud Logging) — cả hai đều là công cụ quan sát vận hành, không liên quan tới dữ liệu nghiệp vụ.

Ghi nhớ

⚠ Các lớp quản trị dữ liệu — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | Tìm dữ liệu bằng thuật ngữ nghiệp vụ | Dataplex Universal Catalog — business glossary | | Phân loại mức nhạy cảm | taxonomy + policy tag | | Che giá trị theo vai trò | dynamic data masking trên policy tag | | Chặn hẳn cột | column-level security | | Lọc dòng | row-level security | | Tìm PII ở đâu | Sensitive Data Protection (DLP) | | Chia sẻ dataset ra ngoài | Analytics Hub |

Từ khoá nhận diện:

"tìm bằng thuật ngữ nghiệp vụ + che cột PII" → Catalog + policy tag "quét tìm PII tự động" → Sensitive Data Protection "chia sẻ dataset không sao chép" → Analytics Hub "ai vào được bảng nào" → IAM "làm sạch dữ liệu trực quan" → Dataprep / Data Fusion

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> | | Người này thấy giá trị nào | chạy thử dưới danh nghĩa tài khoản đó | | Thuật ngữ có gắn vào bảng chưa | Dataplex → Search thử bằng tiếng nghiệp vụ |

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 — Project Viewer.

Vì sao đúng

Yêu cầu là XEM ĐƯỢC mọi tài nguyên và cấu hình của project, nhưng KHÔNG được thay đổi hay tạo mới bất cứ thứ gì. Đó chính là vai trò cơ bản Viewer.

⚠ Điểm mấu chốt — ba vai trò cơ bản:

VIEWER   → ĐỌC mọi tài nguyên      ← đề này
           không thay đổi được gì

EDITOR   → Viewer + SỬA, TẠO, XOÁ

OWNER    → Editor + quản lý IAM
           và thanh toán

⚠ Vì sao "Project Browser" không phải câu trả lời:

roles/browser
        ↓
    Chỉ cho DUYỆT CÂY TÀI NGUYÊN:
      thấy project, folder, organization
        ↓
    ⚠ KHÔNG cho xem CẤU HÌNH tài nguyên
      → không thấy dataset, bucket, VM
        ↓
    Đề nói "xem MỌI tài nguyên VÀ CẤU HÌNH"
        ↓
    → cần Viewer

⚠ Nhưng một cảnh báo quan trọng về Viewer:

⚠ roles/viewer cho phép ĐỌC DỮ LIỆU,
  không chỉ xem danh sách tài nguyên
        ↓
    → đọc được NỘI DUNG bảng BigQuery
    → đọc được NỘI DUNG tệp trong bucket
        ↓
    Nếu chỉ cần "thấy có những gì"
    mà KHÔNG được đọc dữ liệu
        ↓
    → dùng roles/browser + các vai trò
      metadata hẹp của từng dịch vụ

Xem thêm câu #12956 (lô 134): cùng tình huống, cùng khoá roles/viewer, và cùng phân biệt với roles/browser. Hai câu hoàn toàn nhất quán.

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

• A (Project Browser) — đây là phương án gần nhất và đúng là vai trò rất hẹp, nhưng nó chỉ cho duyệt cấu trúc phân cấp, không cho xem cấu hình của tài nguyên như đề yêu cầu.

• B (Project Editor) — cho phép sửa, tạo, xoá — vi phạm trực tiếp yêu cầu.

• D (Project Owner) — rộng nhất, kể cả quản lý IAM và thanh toán.

Ghi nhớ

⚠ Ba vai trò cơ bản — bảng phải thuộc: | Vai trò | Cho phép | |---|---| | roles/viewer | ĐỌC mọi tài nguyên, không thay đổi gì | | roles/editor | Viewer + tạo, sửa, xoá | | roles/owner | Editor + quản lý IAM và thanh toán | | roles/browser | chỉ duyệt CÂY tài nguyên — không phải basic role | | Khuyến nghị của Google | hạn chế basic role, ưu tiên vai trò ĐỊNH SẴN theo dịch vụ |

Từ khoá nhận diện:

"xem mọi thứ, không sửa gì" → roles/viewer "chỉ thấy cây project/folder" → roles/browser "xem nhưng KHÔNG được đọc dữ liệu" → vai trò metadata của từng dịch vụ "quản lý quyền của người khác" → roles/resourcemanager.projectIamAdmin "cấp Editor cho nhanh" → luôn sai trong câu hỏi quyền tối thiểu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có vai trò gì | gcloud projects get-iam-policy <id> | | Vai trò gồm quyền nào | gcloud iam roles describe roles/viewer | | Có quyền thừa không | IAM Recommender |

Và một câu nên hỏi trước khi cấp roles/viewer cho người quản lý dự án: họ có thật sự cần ĐỌC dữ liệu, hay chỉ cần biết có những gì và tốn bao nhiêu? Rất thường xuyên câu trả lời là vế sau — và khi đó roles/browser cộng với quyền xem chi phí vừa đủ dùng, vừa không đặt toàn bộ dữ liệu khách hàng vào tầm tay một người không cần tới nó.

Đáp án

B — Từ Vertex AI Model Registry, chọn version 2 của mô hình và dùng thao tác 'Deploy to Endpoint' để thay thế version đang chạy.

Vì sao đúng

Model Registry được thiết kế cho đúng tình huống này: quay lui về một phiên bản ổn định mà không phải đổi endpoint hay đổi cấu hình phía ứng dụng.

⚠ Điểm mấu chốt — endpoint giữ nguyên, chỉ đổi model phía sau:

Endpoint đang phục vụ version 3
        ↓
    Model Registry → chọn version 2
        ↓
    "Deploy to Endpoint" → chọn endpoint hiện có
        ↓
    ⚠ URL endpoint KHÔNG ĐỔI
    ⚠ Ứng dụng KHÔNG phải sửa gì
    ⚠ Có thể CHIA LƯU LƯỢNG dần
      hoặc chuyển 100% ngay
        ↓
    Gỡ version 3 khỏi endpoint sau khi
    version 2 đã nhận đủ lưu lượng

⚠ Vì sao tạo endpoint mới là cách sai:

Tạo endpoint mới cho version 2
        ↓
    ⚠ URL MỚI → ứng dụng phải sửa cấu hình
    ⚠ Phải triển khai lại ứng dụng
    ⚠ Thời gian ngừng dài hơn hẳn
    ⚠ Còn phải dọn endpoint cũ
        ↓
    → nhiều bước hơn, rủi ro hơn,
      cho cùng một kết quả

⚠ Chia lưu lượng — cách quay lui an toàn nhất:

Endpoint hỗ trợ NHIỀU model cùng lúc
        ↓
    version 3: 100% → 50% → 0%
    version 2:   0% → 50% → 100%
        ↓
    ⚠ Theo dõi chỉ số trong lúc chuyển
    ⚠ Dừng lại được bất cứ lúc nào
        ↓
    Đây cũng chính là cơ chế dùng cho
    canary deployment khi ra bản mới

Xem thêm câu #13138 (cùng lô): hỏi bước TRIỂN KHAI một version vừa đăng ký → cũng là "Deploy to endpoint". Hai câu cùng một thao tác, hai ngữ cảnh — hoàn toàn nhất quán. Và #13116 (lô 137): khoá Model Registry là nơi lưu và quản lý phiên bản.

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

• A (tạo endpoint mới rồi xoá endpoint cũ) — đây là phương án gần nhất và về kỹ thuật cũng ra kết quả, nhưng nó đổi URL endpoint, buộc ứng dụng phải sửa cấu hình và triển khai lại — nhiều bước và rủi ro hơn hẳn.

• C (xoá version 3 khỏi endpoint để tự phục vụ version gần nhất) — không có cơ chế tự động như vậy; xoá model khỏi endpoint chỉ khiến endpoint không còn model nào.

• D (huấn luyện lại version 3 với dữ liệu mới) — mất nhiều thời gian trong khi hệ thống đang phục vụ kém; quay lui trước, huấn luyện lại sau.

Ghi nhớ

⚠ Vertex AI — các thành phần cần thuộc: | Thành phần | Việc | |---|---| | Model Registry | lưu, phiên bản hoá, quản lý mô hình | | Endpoint | phục vụ dự đoán trực tuyến | | Batch prediction | dự đoán theo lô | | Model Monitoring | phát hiện TRÔI (drift) | | Pipelines | điều phối luồng ML | | Experiments | theo dõi các lần thử nghiệm | | Feature Store | quản lý đặc trưng dùng chung |

Từ khoá nhận diện:

"quay lui về version ổn định" → Deploy version cũ lên endpoint hiện có "triển khai version mới" → Deploy to endpoint "phát hiện mô hình suy giảm" → Model Monitoring "lưu nhiều phiên bản" → Model Registry "tạo endpoint mới để quay lui" → cách kém hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Version nào đang phục vụ | Vertex AI → Endpoints → xem model deployed | | Chỉ số của từng version | Model Registry và Monitoring | | Lưu lượng chia thế nào | trafficSplit của endpoint |

Và một nguyên tắc vận hành đáng giữ khi mô hình sản xuất có vấn đề: quay lui trước, điều tra sau. Việc huấn luyện lại có thể mất hàng giờ tới hàng ngày, còn chuyển endpoint về version ổn định chỉ mất vài phút — và trong khoảng thời gian đó, hệ thống đang phục vụ khách hàng bằng một mô hình đã biết là kém.

Đáp án

D — Firestore.

Vì sao đúng

Đề nêu bốn điều: ứng dụng di động, tính năng hiện diện THỜI GIAN THỰC, CSDL không máy chủ, hướng TÀI LIỆU, và cập nhật nhỏ liên tục, mở rộng tới hàng triệu người dùng. Firestore khớp cả bốn.

⚠ Điểm mấu chốt — "hướng tài liệu" và "thời gian thực" chỉ thẳng vào Firestore:

Firestore
        ↓
    - CSDL TÀI LIỆU (document)
    - REAL-TIME LISTENER
      → tự đẩy thay đổi tới máy khách
    - SDK cho Android, iOS, Web, Flutter
    - CHẾ ĐỘ NGOẠI TUYẾN
    - không máy chủ, tự co giãn
        ↓
    ⚠ Tính năng "ai đang online" là
      trường hợp dùng kinh điển

⚠ Cập nhật nhỏ liên tục — mô hình phù hợp:

Trạng thái hiện diện
    /trang_thai/{userId}
      { online: true,
        lan_cuoi: <timestamp> }
        ↓
    Mỗi lần đổi trạng thái = một lần ghi NHỎ
        ↓
    Máy khách khác LẮNG NGHE
      → thấy ngay
        ↓
    ⚠ Firestore tính tiền theo SỐ THAO TÁC
    → cập nhật quá dày sẽ tốn

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

SPANNER
    → CSDL QUAN HỆ, lược đồ cố định
    → không có real-time listener
    → chi phí tối thiểu cao

BIGTABLE
    → NoSQL wide-column, ghi cực lớn
    → không có listener, không có SDK di động
    → không có chế độ ngoại tuyến

CLOUD SQL
    → quan hệ, mở rộng theo chiều DỌC
    → không hợp hàng triệu kết nối di động

Xem thêm câu #13076 (lô 136): cùng tình huống ứng dụng chat thời gian thực, cùng khoá Firestore. Hai câu hoàn toàn nhất quán. Và #13084 (lô 137): khoá Bigtable cho IoT chuỗi thời gian — mô hình dữ liệu khác hẳn.

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

• B (Bigtable) — đây là phương án gần nhất trong nhóm NoSQL và cũng chịu được ghi rất lớn, nhưng nó là wide-column, không có real-time listener, không có SDK di động với chế độ ngoại tuyến, và chi phí tối thiểu cao.

• A (Spanner) — CSDL quan hệ toàn cầu, lược đồ cố định, không có cơ chế đẩy thay đổi tới máy khách.

• C (Cloud SQL) — quan hệ, một node ghi, không kham nổi hàng triệu kết nối di động và không có listener.

Ghi nhớ

⚠ Chọn CSDL theo mô hình và yêu cầu — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | Thời gian thực, di động, tài liệu, ngoại tuyến | Firestore | | Quan hệ, thông thường, một Region | Cloud SQL | | PostgreSQL hiệu năng cao | AlloyDB | | Quan hệ, toàn cầu, nhất quán mạnh | Spanner | | NoSQL ghi cực lớn, chuỗi thời gian, row key | Bigtable | | Phân tích | BigQuery | | Bộ nhớ đệm | Memorystore |

Từ khoá nhận diện:

"thời gian thực, đẩy cập nhật tới máy khách" → Firestore "ứng dụng di động, chế độ ngoại tuyến" → Firestore "row key, IoT, chuỗi thời gian" → Bigtable "toàn cầu + nhất quán mạnh" → Spanner "giao dịch thông thường" → Cloud SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Security Rules có chặt không | Firestore emulator và bộ kiểm thử rules | | Chi phí đọc ghi bao nhiêu | Firestore usage dashboard | | Chỉ mục có đủ không | lỗi truy vấn thường kèm link tạo chỉ mục |

Và một cân nhắc đáng nhớ riêng cho tính năng hiện diện: cập nhật trạng thái quá dày là khoản chi phí bất ngờ phổ biến nhất trên Firestore. Mỗi lần ghi và mỗi lần listener nhận thay đổi đều là một thao tác tính tiền — nên hãy đặt nhịp heartbeat theo phút chứ không theo giây, và cân nhắc Realtime Database cho riêng phần presence nếu tần suất thật sự cao.

Đáp án

C — Dataform.

Vì sao đúng

Đề nêu bốn yêu cầu, và Dataform được thiết kế quanh đúng bốn thứ đó: biến đổi CHỈ bằng SQL ngay trong BigQuery, quản lý phiên bản bằng Git, tự quản lý đồ thị phụ thuộc giữa các bảng, và định nghĩa kiểm thử chất lượng (assertions).

⚠ Điểm mấu chốt — bốn yêu cầu ánh xạ vào bốn tính năng:

"chỉ dùng SQL, ngay trong BigQuery"
    → mỗi bảng là một câu SELECT trong .sqlx

"quản lý phiên bản bằng Git"
    → Dataform kết nối kho Git,
      có môi trường dev và production

"tự quản lý đồ thị phụ thuộc"
    → ${ref("bang")} khai phụ thuộc
    → Dataform tự sắp thứ tự dựng bảng

"kiểm thử chất lượng (assertions)"
    → uniqueKey, nonNull, rowConditions
    → assertion THẤT BẠI → pipeline DỪNG

⚠ Một tệp .sqlx trông thế nào:

config {
  type: "table",
  schema: "mart",
  assertions: {
    uniqueKey: ["order_id"],
    nonNull: ["order_id", "ngay"],
    rowConditions: ["tong_tien >= 0"]
  }
}

SELECT
  o.order_id, o.ngay, c.khu_vuc,
  SUM(o.tong_tien) AS tong_tien
FROM ${ref("stg_orders")} AS o
JOIN ${ref("dim_customers")} AS c
  ON c.khach_id = o.khach_id
GROUP BY 1, 2, 3

⚠ Vì sao scheduled query không đủ:

BigQuery scheduled query
        ↓
    Chạy MỘT truy vấn theo lịch
        ↓
    ⚠ KHÔNG quản lý phụ thuộc
      → phải tự đặt lịch cách nhau
    ⚠ KHÔNG có kiểm thử
    ⚠ KHÔNG có quản lý phiên bản
        ↓
    → thiếu ba trong bốn yêu cầu

Xem thêm câu #12991 (lô 135): cùng khoá Dataform cho đội SQL-first cần Git và kiểm thử. Và #13124, #13126 (lô 137): về ref() và hành vi khi assertion thất bại. Bốn câu hoàn toàn nhất quán.

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

• A (BigQuery scheduled queries) — đây là phương án gần nhất vì cũng chạy SQL trong BigQuery, nhưng nó không quản lý phụ thuộc, không có kiểm thử, không có Git.

• D (Cloud Composer) — quản lý được phụ thuộc, nhưng DAG viết bằng Python (không phải "SQL-first"), và nó đòi môi trường Airflow thường trực.

• B (Dataflow) — đòi viết Apache Beam bằng Java hoặc Python; hoàn toàn không phải SQL-first.

Ghi nhớ

⚠ Chọn công cụ biến đổi theo cách làm việc — bảng phải thuộc: | Cách làm việc | Công cụ | |---|---| | SQL-first, Git, kiểm thử, trong BigQuery | Dataform | | Một truy vấn theo lịch | scheduled query | | Điều phối nhiều dịch vụ | Cloud Composer | | Kéo thả, không lập trình | Cloud Data Fusion | | Viết mã Beam | Dataflow | | Đã có Spark | Dataproc |

Từ khoá nhận diện:

"SQL-first, Git, assertion, phụ thuộc" → Dataform "một truy vấn mỗi sáng" → scheduled query "nhiều dịch vụ, DAG" → Cloud Composer "kéo thả" → Cloud Data Fusion "viết Beam" → Dataflow

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đồ thị phụ thuộc thế nào | compile trong giao diện Dataform | | Assertion có chạy không | kết quả workflow execution | | Chi phí bao nhiêu | INFORMATION_SCHEMA.JOBS, lọc theo nhãn Dataform |

Và một tính năng nên dùng ngay từ mô hình đầu tiên chứ đừng để dành: assertions. Một dòng khai uniqueKey và nonNull biến lỗi dữ liệu từ thứ được phát hiện sau vài tuần bởi một người dùng khó tính, thành thứ làm dừng pipeline ngay trong lần chạy đầu tiên — và đó là khác biệt lớn nhất giữa một chuỗi truy vấn SQL và một pipeline dữ liệu đáng tin.

Đáp án

D — Cloud Data Fusion.

Vì sao đúng

Trong bốn phương án được đưa ra, Cloud Data Fusion là công cụ duy nhất có giao diện TRỰC QUAN để khám phá và chuẩn bị dữ liệu mà KHÔNG cần viết mã — nhờ thành phần Wrangler.

⚠ Điểm mấu chốt — Wrangler làm đúng những gì đề mô tả:

Nạp mẫu dữ liệu vào Wrangler
        ↓
    Với TỪNG CỘT, Wrangler hiển thị:
      - biểu đồ PHÂN PHỐI giá trị
      - tỉ lệ giá trị THIẾU
      - giá trị SAI ĐỊNH DẠNG (màu đỏ)
      - giá trị NGOẠI LAI
        ↓
    Bấm vào cột → GỢI Ý phép biến đổi
        ↓
    ⚠ Xem trước kết quả ngay
    ⚠ Không viết một dòng mã nào

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

BIGQUERY SQL WORKSPACE
    → phải VIẾT SQL để thăm dò
    → có tab Preview nhưng không có
      biểu đồ phân phối và cảnh báo
      bất thường tự động

VERTEX AI WORKBENCH
    → notebook, phải VIẾT PYTHON

DATAFLOW
    → engine xử lý, phải VIẾT MÃ BEAM
        ↓
    ⚠ Cả ba đều đòi viết mã

⚠ Kết quả của Wrangler là một pipeline chạy được:

"Recipe" = chuỗi các bước biến đổi
        ↓
    Chuyển thành pipeline Data Fusion
        ↓
    Chạy trên Dataproc tạm thời
        ↓
    Ghi kết quả vào BigQuery
        ↓
    ⚠ Từ khám phá tới sản xuất
      trong cùng một công cụ

Ghi nhớ về chất lượng câu hỏi

Trong công việc thật, Dataprep (của Alteryx, tích hợp trong Google Cloud) là công cụ chuyên biệt nhất cho việc "khám phá trực quan, phát hiện bất thường và ngoại lai" mà đề mô tả — nó chủ động chỉ ra vấn đề thay vì để bạn tự tìm.

Nhưng Dataprep KHÔNG có trong bốn phương án, nên trong phạm vi câu hỏi này, Cloud Data Fusion với Wrangler là lựa chọn đúng duy nhất — nó cũng có giao diện trực quan, cũng hiển thị phân phối và giá trị bất thường, và cũng không cần viết mã.

Đối chiếu: câu #13017 (lô 136) mô tả gần như cùng một nhu cầu nhưng khoá là Dataprep — vì ở đó Dataprep CÓ trong danh sách phương án. Hai câu không mâu thuẫn: khoá khác nhau vì bộ phương án khác nhau. Quy tắc khi làm bài: chọn phương án phù hợp nhất CÓ TRONG DANH SÁCH.

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

• A (BigQuery SQL workspace) — đây là phương án gần nhất vì cũng khám phá dữ liệu được và có tab Preview, nhưng nó đòi viết SQL để thăm dò, và không tự chỉ ra bất thường bằng biểu đồ phân phối.

• C (Vertex AI Workbench) — môi trường notebook viết Python; làm được nhưng cần lập trình.

• B (Dataflow) — engine xử lý, phải viết Apache Beam.

Ghi nhớ

⚠ Bốn công cụ dữ liệu không cần lập trình — bảng phải thuộc: | Công cụ | Dùng cho | |---|---| | Dataprep | KHÁM PHÁ và LÀM SẠCH trực quan — chuyên biệt nhất | | Cloud Data Fusion (Wrangler) | dựng PIPELINE kéo thả + làm sạch trực quan | | Dataform | chuỗi biến đổi SQL có Git và kiểm thử | | Connected Sheets | phân tích BigQuery trong bảng tính | | Ghi nhớ | Dataprep khám phá, Data Fusion sản xuất |

Từ khoá nhận diện:

"khám phá trực quan, tìm bất thường, không viết mã" → Dataprep, nếu không có thì Data Fusion "dựng pipeline kéo thả, nhiều nguồn" → Cloud Data Fusion "biến đổi bằng SQL, cần kiểm thử" → Dataform "viết Beam" → Dataflow "viết Python" → notebook

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bao nhiêu giá trị bất thường | biểu đồ chất lượng cột trong Wrangler | | Pipeline có chạy hết dữ liệu không | so số dòng vào và ra | | Chi phí bao nhiêu | billing export — Data Fusion và Dataproc |

Và một chiến lược làm bài đáng nhớ cho những câu mô tả gần giống nhau: đọc kỹ danh sách phương án trước khi chọn. Cùng một mô tả về "khám phá dữ liệu trực quan" có thể dẫn tới Dataprep hoặc Data Fusion tuỳ vào việc công cụ nào được đưa ra — đáp án đúng luôn là phương án phù hợp nhất trong danh sách cho sẵn.

Đáp án

A — Chọn version của mô hình trong Model Registry và bấm "Deploy to endpoint".

Vì sao đúng

Sau khi mô hình đã được đăng ký và phiên bản hoá trong Model Registry, bước tiếp theo để phục vụ dự đoán trực tuyến chính là triển khai lên một endpoint.

⚠ Điểm mấu chốt — luồng từ Registry tới phục vụ:

Mô hình đã huấn luyện
        ↓
    ĐĂNG KÝ vào Model Registry
      → có tên và version
        ↓
    "Deploy to endpoint"
      → chọn endpoint có sẵn, hoặc tạo mới
      → chọn loại máy, số bản sao
      → chọn phần trăm lưu lượng
        ↓
    ENDPOINT sẵn sàng nhận request
        ↓
    Ứng dụng gọi qua REST hoặc gRPC

⚠ Các tuỳ chọn khi triển khai:

Machine type      → CPU hay GPU, kích thước
Min/max replicas  → tự co giãn
Traffic split     → phần trăm lưu lượng
Model Monitoring  → bật giám sát drift
Explainability    → bật giải thích dự đoán
        ↓
    ⚠ min replicas > 0 → luôn sẵn sàng,
      trả tiền liên tục
    ⚠ Vertex AI cũng có endpoint
      co về 0 cho tải thưa

⚠ Trực tuyến ↔ theo lô — chọn đúng cách phục vụ:

ONLINE PREDICTION (endpoint)
    → độ trễ thấp, từng request
    → trả tiền theo thời gian endpoint chạy
    → đề này cần cái này

BATCH PREDICTION
    → dự đoán cho cả một tập dữ liệu
    → không cần endpoint thường trực
    → rẻ hơn nhiều nếu không cần
      thời gian thực

Xem thêm câu #13134 (cùng lô): cùng thao tác "Deploy to endpoint", nhưng trong ngữ cảnh quay lui về version cũ. Và #13116 (lô 137): khoá Model Registry là nơi lưu và quản lý phiên bản. Ba câu mô tả ba giai đoạn liên tiếp — hoàn toàn nhất quán.

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

• C (huấn luyện lại bằng AutoML) — đây là phương án gần nhất trong nhóm thao tác ML, nhưng mô hình đã huấn luyện và đăng ký xong; huấn luyện lại là quay ngược quy trình.

• B (tạo bucket Cloud Storage mới cho endpoint) — không cần thiết: artifact của mô hình đã nằm trong Registry, endpoint không đòi bucket riêng.

• D (viết pipeline Dataflow để phục vụ mô hình) — Dataflow là engine xử lý dữ liệu, không phải nơi phục vụ dự đoán trực tuyến.

Ghi nhớ

⚠ Hai cách phục vụ dự đoán — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Online prediction (endpoint) | độ trễ thấp, từng request, endpoint thường trực | | Batch prediction | cả một tập dữ liệu, không cần endpoint | | BigQuery ML ML.PREDICT | dự đoán ngay trong kho, bằng SQL | | Model đóng gói trong ứng dụng | không qua Vertex AI | | Chọn online khi | cần trả lời trong mili giây |

Từ khoá nhận diện:

"triển khai để dự đoán trực tuyến" → Deploy to endpoint "dự đoán cho cả bảng dữ liệu" → batch prediction "dự đoán bằng SQL trong BigQuery" → ML.PREDICT "lưu và quản lý phiên bản" → Model Registry "phát hiện mô hình suy giảm" → Model Monitoring

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Endpoint đang phục vụ gì | Vertex AI → Endpoints | | Độ trễ và tỉ lệ lỗi | chỉ số của endpoint trong Monitoring | | Chi phí endpoint | billing export, SKU Vertex AI Prediction |

Và một câu hỏi nên đặt ra trước khi triển khai lên endpoint trực tuyến: dự đoán này có thật sự cần trả lời trong mili giây không? Endpoint tính tiền theo thời gian chạy chứ không theo số request, nên với một mô hình chỉ được gọi vài trăm lần mỗi ngày, batch prediction hoặc ML.PREDICT trong BigQuery thường rẻ hơn nhiều lần.

Đáp án

B — label

Vì sao đúng

Tham số label trong LookML dùng để đổi TÊN HIỂN THỊ của một trường trên giao diện, mà không đụng gì tới cột trong CSDL.

⚠ Điểm mấu chốt — label chỉ đổi phần người dùng nhìn thấy:

dimension: order_status {
  type: string
  label: "Sale Status"
  sql: ${TABLE}.order_status ;;
}

        ↓
    Trên giao diện Looker: "Sale Status"
    Trong SQL sinh ra:     order_status
        ↓
    ⚠ Cột trong CSDL KHÔNG đổi
    ⚠ Tên field trong LookML KHÔNG đổi
      → mọi tham chiếu ${order_status}
        vẫn hoạt động

⚠ Ba tham số dễ nhầm với nhau:

label
    → TÊN HIỂN THỊ của trường          ← đề này

sql
    → BIỂU THỨC SQL sinh ra giá trị
    → đổi cái này là đổi DỮ LIỆU

view_label
    → tên hiển thị của cả NHÓM (view)
    → gom trường vào nhóm nào trên giao diện

group_label
    → gom nhiều trường thành một nhóm con

⚠ Vì sao không đổi luôn tên field trong LookML:

Đổi `dimension: order_status`
thành `dimension: sale_status`
        ↓
    ⚠ Mọi chỗ tham chiếu ${order_status}
      sẽ HỎNG
    ⚠ Look và dashboard đã lưu
      dùng tên field cũ → HỎNG THEO
        ↓
    Dùng `label` thay vì đổi tên
        ↓
    → giao diện đổi, nội dung cũ vẫn chạy

Xem thêm câu #13128 (lô 137): về phân cấp LookML — dimension và measure nằm trong view, và label là tham số bên trong chúng. Hai câu bổ sung nhau.

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

• A (sql) — đây là phương án gần nhất vì cũng là tham số của dimension, nhưng nó khai BIỂU THỨC SQL sinh ra giá trị; đổi nó là đổi DỮ LIỆU, không phải đổi nhãn hiển thị.

• C (type) — khai kiểu của dimension (string, number, yesno, date...), không ảnh hưởng tên hiển thị.

• D (primary_key) — đánh dấu khoá chính của view, rất quan trọng cho symmetric aggregates nhưng không liên quan tới nhãn.

Ghi nhớ

⚠ Các tham số hiển thị trong LookML — bảng phải thuộc: | Tham số | Việc | |---|---| | label | tên hiển thị của TRƯỜNG | | view_label | tên hiển thị của cả VIEW trên giao diện | | group_label | gom nhiều trường thành một NHÓM | | description | mô tả hiện khi rê chuột — rất nên viết | | hidden: yes | ẩn trường khỏi giao diện | | value_format_name | định dạng số, tiền tệ, phần trăm |

Từ khoá nhận diện:

"đổi tên hiển thị của một trường" → label "đổi tên hiển thị của cả nhóm" → view_label "đổi công thức tính" → sql "ẩn trường trung gian" → hidden: yes "giải thích ý nghĩa cho người dùng" → description

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhãn hiển thị đúng chưa | mở Explore và nhìn danh sách trường | | SQL có đổi không | tab SQL — cột vẫn là order_status | | Có nội dung nào hỏng không | Content Validator |

Và một thói quen đáng có mỗi khi đổi bất kỳ thứ gì trong LookML, kể cả một nhãn: chạy Content Validator trước khi deploy. Đổi label thì an toàn, nhưng cùng một lần commit có thể chứa những thay đổi khác — và Content Validator là thứ duy nhất cho bạn biết dashboard nào sắp hỏng trước khi người dùng phát hiện ra.

Đáp án

B — Object Lifecycle Management.

Vì sao đúng

Đề mô tả đúng bài toán mà Object Lifecycle Management (OLM) sinh ra để giải: dữ liệu nóng trong 30 ngày đầu, sau đó hiếm khi đọc nhưng phải giữ thêm một năm.

⚠ Điểm mấu chốt — quy tắc vòng đời tự hạ lớp lưu trữ theo tuổi:

{"rule": [
  {"action": {"type": "SetStorageClass",
              "storageClass": "COLDLINE"},
   "condition": {"age": 30}},
  {"action": {"type": "Delete"},
   "condition": {"age": 395}}
]}

        ↓
    Ngày 0–30:  STANDARD   — truy cập rất nhiều
    Ngày 30+:   COLDLINE   — hiếm đọc, rẻ hơn nhiều
    Ngày 395:   XOÁ         — hết hạn lưu trữ
        ↓
    ⚠ Hoàn toàn TỰ ĐỘNG, không cần script
    ⚠ Không tốn phí thao tác cho việc chuyển lớp

⚠ Vì sao chọn Coldline chứ không phải Archive:

NEARLINE  → tối thiểu 30 ngày, đọc ~1 lần/tháng
COLDLINE  → tối thiểu 90 ngày, đọc ~1 lần/quý
ARCHIVE   → tối thiểu 365 ngày, gần như không đọc
        ↓
    Đề nói giữ THÊM 1 năm sau mốc 30 ngày
        ↓
    ⚠ Coldline hoặc Archive đều hợp;
      Archive rẻ nhất nếu chắc chắn không đọc
    ⚠ Nhưng đừng đặt Archive rồi xoá sớm —
      xoá trước thời gian tối thiểu vẫn
      BỊ TÍNH TIỀN đủ số ngày đó

⚠ Vì sao ba phương án kia không giảm chi phí:

UNIFORM BUCKET-LEVEL ACCESS
    → chỉ là cách quản lý QUYỀN
    → không đụng tới giá lưu trữ

CMEK
    → khoá mã hoá tự quản
    → còn TỐN THÊM tiền Cloud KMS

SAO CHÉP SANG BUCKET ĐA VÙNG
    → nhân đôi dữ liệu
    → ⚠ TĂNG chi phí, không giảm

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

• A (Uniform bucket-level access) — chế độ kiểm soát truy cập ở mức bucket (bỏ ACL từng đối tượng). Đây là thực hành bảo mật tốt nhưng không liên quan gì tới chi phí lưu trữ.

• C (CMEK) — khoá mã hoá do khách hàng quản lý qua Cloud KMS, dùng khi có yêu cầu tuân thủ. Làm tăng chi phí chứ không giảm.

• D (sao chép sang bucket đa vùng) — đa vùng dùng cho độ sẵn sàng và độ trễ toàn cầu, và đắt hơn một vùng đơn. Đi ngược hoàn toàn mục tiêu tiết kiệm.

Ghi nhớ

⚠ Bốn lớp lưu trữ Cloud Storage — bảng phải thuộc: | Lớp | Thời gian tối thiểu | Dùng khi | |---|---|---| | Standard | không có | truy cập thường xuyên | | Nearline | 30 ngày | ~1 lần/tháng | | Coldline | 90 ngày | ~1 lần/quý | | Archive | 365 ngày | lưu trữ dài hạn, gần như không đọc | | ⚠ Bẫy | xoá sớm vẫn bị tính đủ số ngày tối thiểu |

Từ khoá nhận diện:

"nóng N ngày rồi nguội, tự động" → Object Lifecycle Management "không đoán được kiểu truy cập" → Autoclass "không được xoá trong N năm" → Bucket Lock / Retention Policy "giữ nhiều bản của một đối tượng" → Object Versioning

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy tắc đã áp chưa | gcloud storage buckets describe — xem lifecycle | | Có bao nhiêu byte ở mỗi lớp | Storage Insights hoặc metric storage/total_bytes | | Tiết kiệm được bao nhiêu | billing export sang BigQuery, nhóm theo SKU |

Và một điều đáng nhớ khi thiết kế vòng đời: quy tắc chỉ chạy mỗi ngày một lần và không có hiệu lực hồi tố tức thì. Đặt xong đừng chờ thấy đổi ngay trong vài phút — Google chạy vòng quét theo lô, thường mất tới 24 giờ, và đó là hành vi đúng chứ không phải cấu hình sai.