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

Đáp án

C — Apigee API Management.

Vì sao đúng

Đề dùng đúng cụm "quản lý API trọn vòng đời" (full-lifecycle API management), và liệt kê bốn năng lực chỉ Apigee có đầy đủ.

⚠ Bốn yêu cầu ↔ Apigee:

1. BẢO MẬT
     → OAuth 2.0, JWT, API key,
       kiểm tra mối đe doạ

2. RATE LIMIT VÀ QUOTA
     → theo từng đối tác,
       theo từng gói dịch vụ

3. PHÂN TÍCH CHI TIẾT
     → ⚠ ai gọi, gọi bao nhiêu,
       lỗi ở đâu, độ trễ thế nào

4. ⚠ KIẾM TIỀN (monetization)
     → tính phí theo lượt gọi,
       theo gói — ⚠ CHỈ Apigee có

⚠ "Trọn vòng đời" nghĩa là gì:

THIẾT KẾ  → đặc tả OpenAPI
    ↓
BẢO MẬT   → chính sách xác thực
    ↓
TRIỂN KHAI→ proxy đứng trước backend
    ↓
CÔNG BỐ   → ⚠ cổng lập trình viên,
             đối tác tự đăng ký
    ↓
THEO DÕI  → phân tích, cảnh báo
    ↓
KIẾM TIỀN → gói giá, hoá đơn
    ↓
NGỪNG     → quản lý phiên bản,
             thông báo ngừng hỗ trợ

⚠ Gần trùng với #13269 (cùng lô này) — đề đó là hãng hàng không mở dịch vụ cho đại lý du lịch, đề này là công ty tài chính mở dữ liệu thị trường cho đối tác. Bộ yêu cầu giống nhau, cùng khoá Apigee. Hoàn toàn nhất quán. Mẫu đề lặp: đối tác bên ngoài + hạn ngạch + phân tích + kiếm tiền → luôn là Apigee.

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

• A (Cloud Load Balancing) — chỉ phân phối lưu lượng. Không xác thực đối tác, không hạn ngạch theo khách hàng, không phân tích cách API được dùng.

• B (IAM) — quản lý quyền cho danh tính Google Cloud. Đối tác bên ngoài không nằm trong hệ thống IAM của bạn, và IAM không có khái niệm gói API hay tính phí theo lượt gọi.

• D (Cloud Run Functions) — nơi chạy mã. Nó là backend đứng sau lớp quản lý API, không phải lớp đó.

Ghi nhớ

⚠ Ba lựa chọn quản lý API — bảng phải thuộc: | Sản phẩm | Dùng khi | |---|---| | Apigee | ⚠ API là SẢN PHẨM — đối tác ngoài, kiếm tiền, phân tích sâu, cổng lập trình viên | | API Gateway | API serverless nhẹ cho Cloud Run / Functions | | Cloud Endpoints | API nội bộ, nhẹ | | Cloud Load Balancing | chỉ phân phối lưu lượng |

Từ khoá nhận diện:

"trọn vòng đời, đối tác, kiếm tiền, cổng lập trình viên" → Apigee "API nội bộ đơn giản" → API Gateway / Endpoints "chống DDoS và WAF" → Cloud Armor "chia lưu lượng tới backend" → Load Balancing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối tác nào dùng nhiều nhất | Apigee analytics | | Có ai vượt hạn ngạch không | báo cáo quota | | Backend chịu nổi không | ⚠ đặt spike arrest TRƯỚC khi mở |

Và một cách nghĩ giúp phân biệt Apigee với mọi thứ khác: Apigee không phải hạ tầng, nó là mặt tiền thương mại của API. Khi câu hỏi nhắc tới đối tác, hợp đồng sử dụng, gói dịch vụ hay doanh thu, thì đáp án đã rời khỏi địa hạt của load balancer và IAM từ lâu.

Đáp án

B — Folders (thư mục).

Vì sao đúng

Đề đòi hai thứ cho cùng một nhóm project: tách thanh toán và áp một chính sách IAM riêng. Folder là tầng duy nhất trong phân cấp tài nguyên làm được cả hai.

⚠ Hai yêu cầu ↔ folder:

1. TÁCH THANH TOÁN dev khỏi prod
     → gắn folder `dev` vào một
       tài khoản thanh toán riêng
     → hoặc bóc tách báo cáo theo folder

2. ÁP CHÍNH SÁCH IAM CHỈ CHO DEV
     → cấp vai ở cấp folder `dev`
        ↓
    ⚠ LAN XUỐNG mọi project bên trong
    ⚠ Project dev MỚI tự động
      kế thừa — không phải nhớ cấp

⚠ Cấu trúc thường dùng:

        ORGANIZATION
              │
      ┌───────┴───────┐
   FOLDER          FOLDER
    dev             prod
      │               │
  projects        projects
        ↓
    Trên folder `dev`:
      - lập trình viên có quyền rộng
      - Organization Policy thoáng hơn
      - ngân sách nhỏ, quota thấp
        ↓
    Trên folder `prod`:
      ⚠ - quyền rất hẹp
      ⚠ - chính sách chặt
      ⚠ - bắt buộc CMEK, cấm IP công khai

⚠ Vì sao label không đủ:

LABEL
    ✔ bóc tách CHI PHÍ trong báo cáo
        ↓
    ⚠ NHƯNG KHÔNG cấp quyền theo label
    ⚠ KHÔNG áp Organization Policy
      theo label
        ↓
    → giải được một nửa yêu cầu,
      trượt nửa còn lại

⚠ Gần trùng với #13279 (cùng lô này) — đề đó nhóm project theo phòng ban (Finance, Marketing, Engineering), đề này nhóm theo môi trường (dev, prod). Cùng khoá Folder, hoàn toàn nhất quán. Mẫu đề lặp: nhóm project + áp chính sách chung → luôn là Folder.

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

• A (Labels) — phương án gần nhất và bị nhầm nhiều nhất: label rất tốt cho bóc tách chi phí nhưng chỉ là siêu dữ liệu, không phải ranh giới quản trị. Không cấp quyền theo label được.

• D (vai IAM tuỳ biến) — vai tuỳ biến định nghĩa tập quyền, nhưng không nhóm project. Bạn vẫn phải gán nó ở đâu đó — và chỗ hợp lý chính là folder.

• C (Networks) — VPC là tài nguyên mạng, không phải tầng tổ chức 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 trong báo cáo" → 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 dev | tab Organization Policies của folder | | Chi phí dev là bao nhiêu | billing report nhóm theo folder |

Và một ranh giới nên thiết lập trước khi hệ thống lớn lên: dev và prod phải nằm ở hai project khác nhau, dưới hai folder khác nhau. Chia sẻ một project cho cả hai môi trường nghe tiện lúc mới bắt đầu, nhưng đó cũng là cách nhanh nhất để một lệnh thử nghiệm chạm vào dữ liệu thật.

Đáp án

A — Explainability (khả năng giải thích).

Vì sao đúng

Đề nêu một yêu cầu pháp lý cụ thể: ngân hàng phải nêu được lý do rõ ràng cho MỌI quyết định, nhất là khi từ chối hồ sơ vay. Đó chính là định nghĩa của explainability.

⚠ Vì sao đây là vấn đề thật:

Mô hình học sâu là "HỘP ĐEN"
        ↓
    Nó trả về: "TỪ CHỐI, điểm 0,23"
        ↓
    ⚠ Khách hàng hỏi: "TẠI SAO?"
    ⚠ Cơ quan quản lý hỏi: "TẠI SAO?"
        ↓
    "Vì mạng nơ-ron nói vậy"
    KHÔNG phải câu trả lời hợp lệ
        ↓
    → cần công cụ bóc tách
      ĐÓNG GÓP CỦA TỪNG ĐẶC TRƯNG

⚠ Explainability cho ra cái gì:

Hồ sơ #12345 — TỪ CHỐI
        ↓
Đóng góp của từng yếu tố:
  Tỉ lệ nợ trên thu nhập  −0,42
  Lịch sử thanh toán trễ  −0,31
  Thời gian làm việc      +0,08
  Số dư tài khoản         +0,05
        ↓
    ⚠ Giờ ngân hàng NÓI ĐƯỢC:
      "hồ sơ bị từ chối chủ yếu do
       tỉ lệ nợ trên thu nhập cao
       và lịch sử thanh toán trễ"
        ↓
    → đáp ứng yêu cầu pháp lý
    → và khách hàng biết cần cải thiện gì

⚠ Vì sao ba phương án kia không liên quan:

AVAILABILITY  → hệ thống có chạy không
DURABILITY    → dữ liệu có mất không
SCALABILITY   → chịu được bao nhiêu tải
        ↓
    ⚠ Cả ba là thuộc tính HẠ TẦNG
    ⚠ Không cái nào trả lời được
      câu hỏi "vì sao mô hình
      quyết định như vậy"

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

• B (Availability), C (Durability), D (Scalability) — đều là đặc tính kỹ thuật của hệ thống, quan trọng nhưng thuộc địa hạt hạ tầng. Không cái nào liên quan tới việc giải thích quyết định của mô hình.

Ghi nhớ

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

Từ khoá nhận diện:

"phải nêu được lý do cho quyết định" → Explainability "mô hình đối xử không công bằng với một nhóm" → Fairness / thiên lệch "dữ liệu cá nhân trong huấn luyện" → Privacy "có người xem lại trước khi áp dụng" → Human oversight

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có giải thích được từng quyết định không | ⚠ thử với một hồ sơ bị từ chối thật | | Mô hình có thiên lệch không | đánh giá theo từng nhóm nhân khẩu | | Có người xem lại không | quy trình khiếu nại và phúc thẩm |

Và một điều rất đáng cân nhắc khi triển khai AI trong lĩnh vực bị quản lý chặt: một mô hình chính xác hơn nhưng không giải thích được có thể hoàn toàn không dùng được. Trong những bối cảnh này, khả năng giải thích không phải tính năng phụ mà là điều kiện cần — nếu thiếu, mô hình dù tốt đến đâu cũng không được phép ra quyết định.

Đáp án

B — Vertex AI.

Vì sao đúng

Đề đòi một nền tảng DUY NHẤT cho toàn bộ vòng đời ML, và Vertex AI ra đời chính để gom mọi mảnh rời rạc đó lại.

⚠ Năm nhu cầu ↔ năm thành phần của Vertex AI:

"chuẩn bị dữ liệu"
    → Vertex AI Datasets, Feature Store,
      Workbench

"dựng mô hình bằng AutoML"
    → Vertex AI AutoML

"huấn luyện mô hình tuỳ biến"
    → Vertex AI Training

"quản lý và đánh phiên bản mô hình"
    → ⚠ Vertex AI Model Registry

"triển khai lên sản xuất"
    → Vertex AI Endpoints
        ↓
    ⚠ Tất cả trong MỘT giao diện,
      MỘT hệ thống quyền,
      MỘT nơi ghi nhận nguồn gốc

⚠ Vì sao "hợp nhất" lại quan trọng:

TRƯỚC khi có Vertex AI
  AutoML Tables — một sản phẩm
  AI Platform Training — sản phẩm khác
  AI Platform Prediction — khác nữa
        ↓
    ⚠ Mỗi cái một giao diện,
      một API, một cách quản quyền
    ⚠ Không có nơi chung để
      theo dõi phiên bản và nguồn gốc

SAU khi có Vertex AI
    ⚠ Một nền tảng
    ⚠ Chuyển từ AutoML sang tuỳ biến
      mà không đổi công cụ
    ⚠ Lineage xuyên suốt: mô hình này
      huấn luyện từ dữ liệu nào

⚠ Vì sao ba phương án kia chỉ là một mảnh:

BIGQUERY ML
    → ⚠ CHỈ huấn luyện bằng SQL
      trong kho dữ liệu
    → không có AutoML ảnh, không có
      Model Registry đầy đủ,
      không có pipeline MLOps

VISION API
    → ⚠ chỉ là MỘT mô hình dựng sẵn
    → không huấn luyện gì cả

LOOKER
    → ⚠ công cụ BI, không phải ML

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

• A (BigQuery ML) — phương án gần nhất và rất mạnh trong phạm vi của nó, nhưng nó chỉ phủ một phần: huấn luyện bằng SQL trên dữ liệu bảng. Không có chuẩn bị dữ liệu đa dạng, AutoML cho ảnh và video, hay hạ tầng MLOps đầy đủ. (Hai sản phẩm tích hợp với nhau — mô hình BigQuery ML đăng ký được vào Vertex AI Model Registry.)

• C (Vision API) — một mô hình dựng sẵn, không phải nền tảng.

• D (Looker) — nền tảng BI để trực quan hoá.

Ghi nhớ

⚠ Các thành phần của Vertex AI — bảng nên thuộc: | Thành phần | Việc | |---|---| | Workbench | notebook có quản lý | | Datasets | quản lý tập dữ liệu và gán nhãn | | Feature Store | ⚠ đặc trưng dùng chung, tránh training–serving skew | | AutoML | huấn luyện không cần mã | | Training | huấn luyện tuỳ biến | | Model Registry | ⚠ quản lý phiên bản mô hình | | Endpoints | phục vụ suy luận | | Pipelines | ⚠ tự động hoá quy trình ML | | Model Monitoring | phát hiện drift | | Explainable AI | giải thích dự đoán | | Model Garden | mô hình nền dùng sẵn |

Từ khoá nhận diện:

"nền tảng hợp nhất, toàn bộ vòng đời ML, MLOps" → Vertex AI "huấn luyện bằng SQL trong kho dữ liệu" → BigQuery ML "dùng ngay, không huấn luyện" → API dựng sẵn "dashboard nghiệp vụ" → Looker

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tái lập được kết quả không | lineage trong Vertex AI Metadata | | Mô hình có xuống cấp không | Model Monitoring | | Endpoint tốn bao nhiêu | ⚠ endpoint tính tiền cả khi rảnh |

Và một điều mà các đội mới làm ML thường học được theo cách tốn kém: phần khó nhất không phải huấn luyện mô hình, mà là giữ cho nó còn đúng sau sáu tháng. Dữ liệu đầu vào đổi, hành vi người dùng đổi, hệ thống thượng nguồn đổi schema — và đó chính là phần mà một nền tảng MLOps như Vertex AI tồn tại để lo.

Đáp án

B — Tìm trong tài liệu chính thức của Google Cloud và các issue tracker công khai.

Vì sao đúng

Google Cloud Customer Care khuyến nghị một thứ tự leo thang rõ ràng, và câu hỏi "cách dùng một hàm SQL" thuộc mức thấp nhất của thang đó.

⚠ Thứ tự leo thang được khuyến nghị:

1. ⚠ TÀI LIỆU CHÍNH THỨC
     → thường có ngay, kèm ví dụ

2. ISSUE TRACKER CÔNG KHAI,
   Stack Overflow, cộng đồng
     → ⚠ có thể đã có người hỏi rồi

3. Hỏi đồng nghiệp nội bộ

4. MỞ TICKET HỖ TRỢ
     → khi đã tự tìm mà chưa ra
        ↓
    ⚠ Nhanh hơn cho CHÍNH BẠN,
      không chỉ để đỡ phiền Google

⚠ Vì sao mở P1 cho câu hỏi này là sai:

P1 = "dịch vụ sản xuất KHÔNG DÙNG ĐƯỢC"
        ↓
    Đề nói rõ: "câu hỏi KHÔNG
    quan trọng về cách dùng"
        ↓
    ⚠ Mở P1 sai mức:
      - đánh thức kỹ sư trực đêm
      - làm chậm ca P1 THẬT của
        khách hàng khác
      - ⚠ "báo động giả" lặp lại
        làm mất giá trị của P1
        ↓
    → mức đúng cho câu này là P4

⚠ Mức ưu tiên đúng cho từng tình huống:

P1  sản xuất NGỪNG hoạt động
P2  suy giảm nghiêm trọng, còn chạy
P3  ảnh hưởng vừa, có cách đi vòng
P4  ⚠ câu hỏi chung, hướng dẫn sử dụng
      ← đề này, NẾU vẫn cần mở ticket

Xem thêm #13293 (cùng lô này) — về các gói hỗ trợ và mục tiêu phản hồi. Câu này nói về quy trình sử dụng hỗ trợ cho đúng. Hai câu bổ sung nhau.

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

• A (mở ngay ticket P1) — phương án gần nhất về mặt "dùng đúng quyền lợi đã trả tiền", nhưng sai mức ưu tiên nghiêm trọng. Gói Enhanced cho quyền mở ticket, nhưng mức ưu tiên phải phản ánh tác động thật.

• C (email trực tiếp lãnh đạo Google Cloud) — không phải kênh hỗ trợ, và không hiệu quả.

• D (đăng lên kênh marketing nội bộ) — sai nơi hoàn toàn.

Ghi nhớ

⚠ Bốn mức ưu tiên — bảng phải thuộc: | Mức | Khi nào | |---|---| | P1 — Critical | ⚠ sản xuất NGỪNG hoạt động | | P2 — High | suy giảm nghiêm trọng | | P3 — Medium | ảnh hưởng vừa, có cách đi vòng | | P4 — Low | ⚠ câu hỏi chung, hướng dẫn — đề này |

Từ khoá nhận diện:

"câu hỏi cách dùng, không khẩn cấp" → tài liệu trước, P4 nếu cần "sản xuất sập" → P1 "gói nào có TAM" → Premium "mục tiêu 15 phút cho P1" → Premium

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đây có phải sự cố của Google không | Status Dashboard | | Đã có ai gặp chưa | Issue Tracker, Stack Overflow | | Mức ưu tiên đặt đúng chưa | so với bảng P1–P4 |

Và một lý do rất thực dụng để tra tài liệu trước: thường thì nó nhanh hơn. Một câu hỏi về cú pháp hàm SQL có câu trả lời kèm ví dụ ngay trong trang tham chiếu, đọc mất hai phút — trong khi chờ một kỹ sư hỗ trợ phản hồi rồi trao đổi qua lại luôn tốn nhiều thời gian hơn thế.

Đáp án

D — Chấp nhận những rủi ro có tính toán, ví dụ tung ra một tính năng mới có thể gây bất ổn.

Vì sao đúng

Error budget không phải là một hạn mức để tiết kiệm, mà là một khoản được phép tiêu — và tiêu vào việc phát hành nhanh hơn.

⚠ Ý tưởng cốt lõi của error budget:

SLO 99,9% trong 30 ngày
        ↓
    Ngân sách lỗi = 0,1%
    ≈ 43 phút ngừng dịch vụ / tháng
        ↓
    ⚠ CÒN ngân sách
      → được phép TRIỂN KHAI,
        thử nghiệm, chạy canary,
        diễn tập sự cố
        ↓
    ⚠ HẾT ngân sách
      → ⚠ ĐÓNG BĂNG tính năng,
        cả đội chuyển sang
        làm độ tin cậy

⚠ Nó giải quyết mâu thuẫn muôn thuở:

ĐỘI PHÁT TRIỂN muốn ra tính năng NHANH
ĐỘI VẬN HÀNH muốn hệ thống ỔN ĐỊNH
        ↓
    ⚠ Không có error budget:
      hai bên 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"
      cuộc tranh luận

⚠ Chưa tiêu ngân sách KHÔNG phải điều tốt tuyệt đối:

Giữa tháng mà gần như chưa tiêu gì
        ↓
    ⚠ Có thể nghĩa là đội đang
      QUÁ THẬN TRỌNG
    ⚠ Đang phát hành quá chậm
    ⚠ Đang bỏ lỡ cơ hội
        ↓
    → SRE coi đây là tín hiệu
      NÊN MẠO HIỂM HƠN

Xem thêm #13264 (lô 138) — về SRE nói chung, SLI/SLO/SLA và toil. Câu này đào sâu vào error budget, khái niệm đặc trưng nhất của SRE. Hai câu nhất quán.

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

• B (tập trung sửa lỗi nhỏ để đạt 100%) — phương án gần nhất về mặt "nghe có trách nhiệm", nhưng 100% là mục tiêu SAI theo SRE: chi phí tăng theo cấp số nhân, và không có ngân sách lỗi thì không dám triển khai gì cả.

• A (phạt lập trình viên gây ra sự cố) — trái ngược với văn hoá blameless postmortem. Quy tội khiến người ta giấu sự cố, và hệ thống không được cải thiện.

• C (nghỉ nốt tháng vì dịch vụ ổn định) — hiểu sai hoàn toàn: ngân sách còn dư nghĩa là có dư địa để làm việc mạo hiểm hơn, không phải để ngừng làm việc.

Ghi nhớ

⚠ Error budget — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | Công thức | 100% − SLO | | Ý nghĩa | ⚠ mức KHÔNG tin cậy được PHÉP có | | Còn ngân sách | ⚠ được phép mạo hiểm, phát hành nhanh | | Hết ngân sách | ⚠ đóng băng tính năng, tập trung độ tin cậy | | Dư quá nhiều | ⚠ dấu hiệu đang quá thận trọng |

Từ khoá nhận diện:

"error budget cho phép làm gì" → chấp nhận rủi ro có tính toán "hết ngân sách lỗi" → đóng băng phát hành "100% availability" → ⚠ mục tiêu SAI "mổ xẻ sự cố" → blameless postmortem

Ba việc kiểm chứng cho một đội: | Việc | Câu hỏi | |---|---| | Có SLO viết ra chưa | hay chỉ nói miệng "phải luôn chạy" | | 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 thống nhất 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 đã ký vào nó từ lúc mọi thứ còn yên bình — thoả thuận sau khi hệ thống vừa sập không bao giờ khách quan được nữa.

Đáp án

A — Firestore.

Vì sao đúng

Đề nêu bốn yêu cầu, và cả bốn là những gì Firestore được thiết kế riêng để làm:

⚠ Bốn yêu cầu ↔ Firestore:

1. NoSQL
     → Firestore là CSDL tài liệu

2. NHIỀU NGƯỜI SỬA CÙNG LÚC,
   THỜI GIAN THỰC
     → ⚠ real-time listener:
       dữ liệu TỰ ĐẨY về mọi máy khách
       khi có thay đổi

3. ĐỒNG BỘ GIỮA WEB VÀ DI ĐỘNG
     → SDK cho iOS, Android, web,
       Flutter, Unity

4. ⚠ HOẠT ĐỘNG NGOẠI TUYẾN MẠNH
     → ⚠ đây là điều kiện loại trừ
       then chốt — chỉ Firestore có

⚠ Real-time listener khác truy vấn thường thế nào:

CSDL THÔNG THƯỜNG
  Máy khách hỏi → server trả lời
        ↓
    Muốn biết có thay đổi không
    → ⚠ phải HỎI LẠI liên tục (polling)

FIRESTORE
  Máy khách ĐĂNG KÝ nghe một tài liệu
        ↓
    Ai đó sửa tài liệu
        ↓
    ⚠ Firestore TỰ ĐẨY bản mới
      xuống MỌI máy đang nghe
        ↓
    → cộng tác thời gian thực
      gần như không phải viết mã đồng bộ

⚠ Chế độ ngoại tuyến:

Mất mạng
        ↓
    ⚠ SDK ghi vào bộ đệm CỤC BỘ
    ⚠ Ứng dụng VẪN đọc và ghi được
        ↓
    Có mạng trở lại
        ↓
    ⚠ Tự đồng bộ lên máy chủ
    ⚠ Tự xử lý xung đột
        ↓
    → người dùng gần như không
      nhận ra đã mất mạng

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

• D (Cloud Spanner) — phương án gần nhất về mặt "CSDL mạnh cho ứng dụng", nhưng nó là quan hệ, không có SDK máy khách với đồng bộ thời gian thực và chế độ ngoại tuyến. Nó dành cho backend, không dành cho máy khách di động.

• B (Cloud Bigtable) — NoSQL nhưng là wide-column cho thông lượng cực lớn; không có SDK máy khách, không có listener thời gian thực, không có chế độ ngoại tuyến.

• C (Cloud SQL) — CSDL quan hệ truyền thống; máy khách di động không nên kết nối trực tiếp vào nó.

Ghi nhớ

⚠ Firestore — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Mô hình | NoSQL tài liệu — collection và document | | Real-time listener | ⚠ dữ liệu tự đẩy về máy khách | | Chế độ ngoại tuyến | ⚠ đọc ghi khi mất mạng, tự đồng bộ lại | | SDK máy khách | iOS, Android, web, Flutter, Unity | | Security Rules | ⚠ phân quyền NGAY Ở CSDL — máy khách gọi thẳng được | | Giao dịch ACID | trong phạm vi giới hạn | | Tự mở rộng, serverless | | | Chỉ mục | ⚠ tự tạo cho trường đơn; truy vấn phức hợp cần chỉ mục tổng hợp |

Từ khoá nhận diện:

"di động, thời gian thực, ngoại tuyến, cộng tác" → Firestore "chuỗi thời gian, thông lượng cực lớn" → Bigtable "quan hệ toàn cầu, ACID" → Spanner "MySQL/PostgreSQL" → Cloud SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Security Rules có chặt không | ⚠ kiểm thử bằng Firebase emulator | | Có bao nhiêu lượt đọc mỗi phiên | đây là thứ quyết định hoá đơn | | Ngoại tuyến có hoạt động không | thử tắt mạng trên thiết bị thật |

Và một sai lầm rất tốn tiền với Firestore mà đề thi không hỏi nhưng thực tế hay gặp: thiết kế khiến mỗi lần mở màn hình phải đọc hàng trăm tài liệu. Giá của Firestore tính theo số lượt đọc chứ không theo dung lượng, nên một cấu trúc dữ liệu sai không làm chậm ứng dụng — nó chỉ âm thầm nhân hoá đơn lên nhiều lần.

Đáp án

A — Dataflow.

Vì sao đúng

Trong kiến trúc dữ liệu luồng chuẩn của Google Cloud, mỗi sản phẩm có đúng một vai, và biến đổi là vai của Dataflow.

⚠ Kiến trúc và vai của từng mảnh:

NGUỒN sự kiện
        ↓
PUB/SUB     ← nhận và đệm ("cửa trước")
        ↓
⚠ DATAFLOW  ← BIẾN ĐỔI, LÀM GIÀU,
               TỔNG HỢP theo cửa sổ
        ↓
BIGQUERY    ← lưu và phân tích
        ↓
LOOKER      ← trực quan hoá

⚠ Ba việc đề nêu, Dataflow làm cả ba:

"BIẾN ĐỔI" (transform)
    → ParDo, Map trên từng phần tử

"LÀM GIÀU" (enrich)
    → ⚠ side input hoặc CoGroupByKey
      để ghép thêm dữ liệu tham chiếu

"TỔNG HỢP THỜI GIAN THỰC" (aggregate)
    → ⚠ WINDOW + Combine
      → ví dụ: tổng doanh thu mỗi
        5 phút, tính liên tục

⚠ Cửa sổ thời gian — thứ chỉ engine luồng mới có:

Luồng dữ liệu là VÔ HẠN
        ↓
    ⚠ Không thể "tính tổng tất cả"
      vì không bao giờ hết dữ liệu
        ↓
    → chia thành CỬA SỔ:
      - Fixed  : mỗi 5 phút một khối
      - Sliding: 5 phút, trượt mỗi 1 phút
      - Session: gom theo phiên hoạt động
        ↓
    ⚠ Watermark: khi nào coi là
      "đã đủ dữ liệu cho cửa sổ này"

⚠ Gần trùng với #13313 (cùng lô này) — đề đó cũng mô tả Pub/Sub → xử lý → BigQuery cho dữ liệu IoT, và cùng khoá Dataflow. Hoàn toàn nhất quán. Mẫu đề lặp: biến đổi/làm giàu dữ liệu luồng, có quản lý, tự mở rộng → luôn là Dataflow.

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

• C (Cloud SQL) — cơ sở dữ liệu giao dịch. Không phải engine xử lý luồng; không có khái niệm cửa sổ thời gian hay watermark.

• D (Cloud Storage) — lưu tệp. Là nơi chứa, không phải nơi biến đổi.

• B (Looker) — công cụ BI, nằm ở cuối đường ống để hiển thị kết quả.

Ghi nhớ

⚠ Vai của từng sản phẩm trong pipeline dữ liệu — bảng phải thuộc: | Giai đoạn | Sản phẩm | |---|---| | Nhận (ingest) | Pub/Sub (luồng), Datastream (CDC), Storage Transfer (lô) | | ⚠ Xử lý (transform) | ⚠ Dataflow, Dataproc, Dataform | | Lưu | BigQuery, Cloud Storage, Bigtable | | Phân tích | BigQuery | | Trực quan hoá | Looker, Looker Studio | | Điều phối | Cloud Composer, Cloud Workflows |

Từ khoá nhận diện:

"biến đổi, làm giàu, tổng hợp thời gian thực" → Dataflow "nhận luồng, cửa trước" → Pub/Sub "biến đổi bằng SQL trong kho" → Dataform "Spark/Hadoop có sẵn" → Dataproc "chỉ nạp thẳng, không biến đổi" → managed Pub/Sub → BigQuery subscription

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline có theo kịp không | ⚠ System lag và Data freshness | | Bước nào chậm | đồ thị pipeline — wall time từng bước | | Có bản ghi hỏng không | đếm dòng ở bảng dead-letter |

Và một câu hỏi nên đặt trước khi viết pipeline Dataflow đầu tiên: có thật sự cần biến đổi không? Nếu chỉ là đưa dữ liệu nguyên trạng từ Pub/Sub vào BigQuery thì subscription có quản lý làm được mà không cần một dòng mã nào — Dataflow xứng đáng khi bạn thật sự phải làm sạch, làm giàu hoặc tổng hợp.

Đáp án

D — Lưu lượng có thể đi hoàn toàn trong mạng riêng, được định nghĩa bằng phần mềm, của Google.

Vì sao đúng

Khi hai tài nguyên Google Cloud trong cùng một vùng nói chuyện với nhau, gói tin không cần ra Internet công cộng.

⚠ Hai đường đi có thể có:

QUA INTERNET CÔNG CỘNG (không cần thiết)
  VM → IP công khai của Cloud SQL
        ↓
    ⚠ đi qua nhiều ISP
    ⚠ bề mặt tấn công lớn hơn
    ⚠ độ trễ cao hơn, kém ổn định
    ⚠ có phí đi ra

⚠ QUA MẠNG RIÊNG CỦA GOOGLE
  VM → Private IP / Private Service Connect
        ↓
    ⚠ KHÔNG bao giờ rời khỏi
      hạ tầng Google
    ⚠ Được mã hoá tự động
      giữa các trung tâm dữ liệu
    ⚠ Độ trễ thấp và ổn định
    ⚠ Bề mặt tấn công nhỏ hơn nhiều

⚠ Mạng "định nghĩa bằng phần mềm" nghĩa là gì:

VPC của Google là TOÀN CẦU
        ↓
    ⚠ Một VPC trải khắp mọi vùng
    ⚠ Subnet thuộc từng vùng nhưng
      cùng một mạng logic
        ↓
    → tài nguyên ở Tokyo và Frankfurt
      nói chuyện bằng IP nội bộ,
      không cần VPN hay peering
        ↓
    ⚠ Khác hẳn mô hình VPC theo vùng
      của các nhà cung cấp khác

⚠ Cách thực hiện với Cloud SQL:

Cấu hình PRIVATE IP cho instance
        ↓
    Cloud SQL nhận IP nội bộ trong
    dải VPC của bạn
        ↓
    ⚠ TẮT hẳn IP công khai
        ↓
    → không có đường nào từ Internet
      chạm tới CSDL

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

• A (lưu lượng được ứng dụng của khách tự mã hoá) — phương án gần nhất về mặt "nghe như bảo mật", nhưng câu hỏi là về lợi ích do HẠ TẦNG của Google cung cấp. Mã hoá ở tầng ứng dụng là việc của bạn, không phải thứ hạ tầng tự làm.

• C (định tuyến qua nhiều ISP công cộng để dự phòng) — ngược lại: ưu điểm chính là KHÔNG đi qua ISP công cộng.

• B (log tự động vào một bucket Cloud Storage CÔNG KHAI) — không đúng, và một bucket công khai chứa log mạng sẽ là lỗ hổng bảo mật nghiêm trọng.

Ghi nhớ

⚠ Đặc điểm mạng của Google Cloud — bảng nên thuộc: | Đặc điểm | Nội dung | |---|---| | VPC TOÀN CẦU | ⚠ một VPC trải mọi vùng — khác các nhà cung cấp khác | | Mạng xương sống riêng | lưu lượng giữa các vùng không ra Internet | | Mã hoá khi truyền | ⚠ tự động giữa các trung tâm dữ liệu | | Global Load Balancer | một IP toàn cầu, không cần khởi động trước | | Premium / Standard network tier | ⚠ Premium đi mạng Google càng xa càng tốt |

Từ khoá nhận diện:

"không ra Internet công cộng" → mạng riêng của Google / Private IP "truy cập API Google mà không cần IP công khai" → Private Google Access "kết nối tới dịch vụ có quản lý qua IP nội bộ" → Private Service Connect "nối tới trung tâm dữ liệu riêng" → Cloud Interconnect / VPN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cloud SQL còn IP công khai không | ⚠ kiểm và TẮT nếu không cần | | Có VM nào có IP công khai thừa không | dùng Cloud NAT thay thế | | Lưu lượng đi đường nào | VPC Flow Logs |

Và một việc rất đáng làm ngay sau khi dựng xong hệ thống: rà xem còn tài nguyên nào có IP công khai mà không thật sự cần. Mỗi địa chỉ công khai là một cánh cửa ra Internet, và phần lớn trong số đó tồn tại chỉ vì nó là tuỳ chọn mặc định lúc tạo, chứ không phải vì ai đó cần tới.

Đáp án

D — Dataflow.

Vì sao đúng

Đề nêu năm yêu cầu, và Dataflow là dịch vụ duy nhất đáp ứng đủ:

⚠ Năm yêu cầu ↔ Dataflow:

1. HÀNG TRIỆU SỰ KIỆN MỖI GIỜ
     → tự mở rộng theo tải

2. LÀM SẠCH và LỌC
     → ParDo, Filter

3. ⚠ LÀM GIÀU bằng dữ liệu khách hàng
   TỪ MỘT CSDL KHÁC
     → ⚠ side input hoặc
       CoGroupByKey để tra cứu

4. CÓ QUẢN LÝ, TỰ MỞ RỘNG
     → serverless, không dựng cụm

5. THỜI GIAN THỰC
     → xử lý luồng với cửa sổ thời gian

⚠ Làm giàu dữ liệu — phần khó nhất trong đề:

Sự kiện cảm biến:  {sensor_id, nhiệt độ}
                        +
Dữ liệu khách hàng: {sensor_id → tên,
                     gói dịch vụ, khu vực}
                        ↓
    ⚠ Cách 1 — SIDE INPUT
      nạp bảng tra cứu vào bộ nhớ
      của mọi worker
      → hợp khi bảng NHỎ, ít đổi
        ↓
    ⚠ Cách 2 — TRA CỨU TỪNG BẢN GHI
      gọi CSDL trong DoFn
      → nhớ dùng bộ đệm và
        gom theo lô, nếu không
        sẽ giết chết CSDL
        ↓
    ⚠ Cách 3 — CoGroupByKey
      nếu bảng tra cứu cũng là luồng

⚠ Gần trùng với #13311 (cùng lô này) — đề đó cũng là Pub/Sub → biến đổi → BigQuery và cùng khoá Dataflow. Hoàn toàn nhất quán. Điểm khác duy nhất là đề này nhấn thêm vào việc làm giàu từ CSDL khác, vốn cũng là việc của Dataflow.

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

• B (Cloud SQL) — phương án gần nhất vì đề có nhắc tới "dữ liệu khách hàng từ một CSDL khác". Nhưng Cloud SQL là nguồn tra cứu, không phải engine xử lý: nó không nhận được luồng hàng triệu sự kiện mỗi giờ.

• A (Cloud Storage) — lưu tệp, không biến đổi gì.

• C (Looker) — công cụ BI ở cuối đường ống.

Ghi nhớ

⚠ Chọn engine xử lý — bảng phải thuộc: | Nhu cầu | Chọn | |---|---| | Luồng hoặc lô, có quản lý, tự mở rộng | ⚠ Dataflow | | Đã có mã Spark/Hadoop sẵn | Dataproc | | Biến đổi bằng SQL trong kho | Dataform | | Kéo thả, không viết mã | Cloud Data Fusion | | Chỉ nạp thẳng, không biến đổi | managed Pub/Sub → BigQuery subscription |

Từ khoá nhận diện:

"làm sạch, lọc, làm giàu, thời gian thực, có quản lý" → Dataflow "đã quen Spark" → Dataproc "chỉ chuyển thẳng vào bảng" → subscription có quản lý "giao diện kéo thả" → Data Fusion

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có theo kịp luồng không | System lag không tăng dần | | CSDL tra cứu có bị quá tải không | ⚠ theo dõi kết nối và CPU của nó | | Bản ghi hỏng đi đâu | có bảng dead-letter chưa |

Và một quyết định thiết kế đáng cân nhắc sớm khi phải làm giàu dữ liệu luồng: đưa bảng tra cứu sang một kho đọc nhanh như Bigtable hoặc Memorystore. Cloud SQL rất tốt cho tải giao dịch, nhưng hàng triệu lượt tra mỗi giờ từ một pipeline luồng là kiểu tải mà nó không được sinh ra để chịu.