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

Đáp án

B — Nó cung cấp tốc độ cao, độ trễ thấp và bảo mật tăng cường cho lưu lượng giữa các dịch vụ Google Cloud, cải thiện hiệu năng ứng dụng.

Vì sao đúng

Đề mô tả một hệ thống trải ba châu lục với dữ liệu chảy liên tục giữa các dịch vụ — đúng bối cảnh mà mạng riêng của Google tạo ra khác biệt.

⚠ Ba lợi ích trong một:

⚠ TỐC ĐỘ CAO
    → cáp quang riêng, kể cả
      cáp biển do Google sở hữu

⚠ ĐỘ TRỄ THẤP và ỔN ĐỊNH
    → ⚠ không phụ thuộc vào
      tình trạng Internet công cộng
    → ít chặng, đường đi tối ưu

⚠ BẢO MẬT TĂNG CƯỜNG
    → ⚠ lưu lượng KHÔNG rời khỏi
      hạ tầng Google
    → mã hoá tự động giữa các
      trung tâm dữ liệu

⚠ Với hệ thống trong đề:

Cloud Storage (Bắc Mỹ)
        ↕
BigQuery (châu Âu)
        ↕
Compute Engine (châu Á)
        ↓
    ⚠ Nếu đi qua Internet công cộng:
      độ trễ thất thường, nhiều chặng,
      bề mặt tấn công lớn
        ↓
    ⚠ Đi trong mạng riêng Google:
      đường đi được kiểm soát,
      hiệu năng ổn định,
      mã hoã tự động

⚠ VPC toàn cầu — điểm khác biệt của Google:

Nhiều nhà cung cấp: VPC theo VÙNG
    → nối hai vùng phải peering
        ↓
⚠ Google: VPC là TOÀN CẦU
    → ⚠ một VPC trải 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ộ

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

"Làm Google Cloud ĐẮT HƠN
 đối thủ"
    → ⚠ không phải lợi ích,
      và không đúng

"Đảm bảo dữ liệu LUÔN đi qua
 Internet CÔNG CỘNG"
    → ⚠ NGƯỢC LẠI hoàn toàn

"Là CÙNG một mạng mà mọi nhà
 cung cấp khác dùng"
    → ⚠ SAI: đây là mạng RIÊNG
      của Google

Nhất quán với #13312 (lô 139) — câu đó về lưu lượng giữa VM và Cloud SQL đi trong mạng riêng của Google. Câu này ở quy mô toàn cầu. Hai câu cùng một nội dung.

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

• C (đảm bảo dữ liệu luôn đi qua Internet công cộng) — phương án gần nhất về mặt "cũng nói về đường đi của dữ liệu", nhưng ngược hoàn toàn: ưu điểm chính là KHÔNG đi qua Internet công cộng.

• A (làm Google Cloud đắt hơn đối thủ) — không phải lợi ích, và không đúng.

• D (là cùng một mạng mọi nhà cung cấp dùng) — sai: đây là hạ tầng riêng do Google đầu tư và sở hữu.

Ghi nhớ

⚠ Đặc điểm mạng 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 nhiều nhà cung cấp | | Mạng xương sống riêng | ⚠ cáp quang và cáp biển của Google | | 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, anycast | | Premium / Standard tier | ⚠ Premium đi mạng Google càng xa càng tốt |

Từ khoá nhận diện:

"mạng riêng, độ trễ thấp, nhiều vùng" → mạng xương sống Google "không ra Internet công cộng" → Private IP, Private Service Connect "một IP toàn cầu" → Global Load Balancer "nối tới trung tâm dữ liệu riêng" → Cloud Interconnect

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lưu lượng đi đường nào | VPC Flow Logs | | Phí truyền giữa vùng bao nhiêu | ⚠ billing report — SKU network | | Có tài nguyên nào IP công khai thừa không | rà và tắt |

Và một khoản chi phí hay gây bất ngờ với kiến trúc trải ba châu lục như trong đề: phí truyền dữ liệu GIỮA CÁC VÙNG. Mạng riêng của Google nhanh và an toàn, nhưng không miễn phí — nên thiết kế tốt vẫn là đặt phần tính toán ở gần nơi dữ liệu nằm, thay vì kéo terabyte qua lại giữa các châu lục.

Đáp án

A — Tấn công lừa đảo (phishing).

Vì sao đúng

Đề mô tả đúng ba yếu tố của một cuộc tấn công phishing kinh điển:

⚠ Ba yếu tố trong đề:

1. ⚠ MẠO DANH
     "email trông như từ bộ phận IT"

2. ⚠ TẠO CỚ KHẨN CẤP
     "để tài khoản không bị vô hiệu hoá"

3. ⚠ THU THẬP THÔNG TIN ĐĂNG NHẬP
     "bấm link và nhập mật khẩu"
        ↓
    Kẻ tấn công dùng thông tin đó
    để vào hệ thống công ty
        ↓
    → PHISHING

⚠ Vì sao phishing hiệu quả:

Không cần khai thác lỗ hổng
kỹ thuật nào
        ↓
    ⚠ Nó khai thác TÂM LÝ:
      - tin vào thẩm quyền
      - sợ mất tài khoản
      - vội vàng không kiểm tra
        ↓
    ⚠ Tường lửa, bản vá, mã hoá
      đều KHÔNG giúp gì
        ↓
    → véc-tơ tấn công phổ biến
      nhất trong thực tế

⚠ Ba loại tấn công kia khác hẳn:

MALWARE
    → ⚠ phần mềm độc hại cài lên máy
    → (phishing có thể là CÁCH phát tán,
       nhưng đề không nhắc tới việc
       cài phần mềm nào)

XÂM PHẠM AN NINH VẬT LÝ
    → ⚠ kẻ tấn công vào được toà nhà
    → đây là tấn công từ xa

DDoS
    → ⚠ dội lưu lượng làm sập dịch vụ
    → không đánh cắp gì

⚠ Gần trùng với #13301 (lô 139) — đề đó cũng là email giả mạo bộ phận IT đòi nhập thông tin đăng nhập, và cùng khoá Phishing. Hoàn toàn nhất quán.

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

• B (tấn công phần mềm độc hại) — phương án gần nhất vì phishing thường là cách phát tán malware. Nhưng đề chỉ mô tả việc đánh cắp thông tin đăng nhập, không nhắc tới việc cài phần mềm nào lên máy.

• C (xâm phạm an ninh vật lý) — đây là tấn công từ xa qua email.

• D (DDoS) — nhằm làm ngừng dịch vụ, không đánh cắp thông tin.

Ghi nhớ

⚠ Các loại tấn công phải phân biệt — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | ⚠ Phishing | ⚠ email/tin nhắn giả mạo lừa lấy thông tin | | Spear phishing | ⚠ nhắm MỘT người cụ thể, có nghiên cứu | | Whaling | nhắm lãnh đạo cấp cao | | Vishing / Smishing | qua điện thoại / SMS | | Malware / Ransomware | phần mềm độc hại, mã hoá đòi tiền | | Man-in-the-middle | chặn giữa hai bên | | DDoS | dội lưu lượng làm ngừng dịch vụ | | Social engineering | ⚠ khái niệm bao trùm — thao túng con người |

Từ khoá nhận diện:

"email giả, trang đăng nhập giả" → phishing "dữ liệu bị mã hoá đòi tiền chuộc" → ransomware "làm sập bằng lưu lượng" → DDoS → Cloud Armor "nghe lén trên đường truyền" → man-in-the-middle

Ba việc kiểm chứng cho một tổ chức: | Việc | Cách | |---|---| | Đã bắt buộc MFA chưa | Admin console | | Tài khoản quản trị đã dùng khoá phần cứng chưa | ⚠ ưu tiên nhóm này trước | | Nhân viên có nhận ra phishing không | diễn tập nội bộ định kỳ |

Và một sự thật đáng suy nghĩ về bảo mật đám mây: kẻ tấn công hiếm khi phá vỡ mã hoá của Google — họ chỉ cần một nhân viên gõ mật khẩu vào một trang giả. Đó cũng là lý do khoá bảo mật phần cứng, thứ khiến trang giả không thể hoạt động dù nạn nhân có bấm vào, là khoản đầu tư bảo mật hiệu quả nhất trên mỗi đồng bỏ ra.

Đáp án

B — Di chuyển dữ liệu từ hệ nguồn, định dạng lại hoặc làm sạch, rồi nạp vào hệ đích như một kho dữ liệu.

Vì sao đúng

Đây là định nghĩa nguyên văn của ETL, và đề mô tả đúng ba vấn đề mà bước Transform giải quyết.

⚠ Ba chữ E-T-L ứng với đề:

E — EXTRACT (rút)
    → lấy từ MySQL, tệp JSON,
      nền tảng CRM SaaS

⚠ T — TRANSFORM (biến đổi)
    → ⚠ chuẩn hoá ĐỊNH DẠNG NGÀY
    → ⚠ chuẩn hoá CẤU TRÚC MÃ KHÁCH
    → ⚠ chuẩn hoá TÊN SẢN PHẨM

L — LOAD (nạp)
    → đưa vào BigQuery

⚠ Vì sao bước Transform là phần khó nhất:

Ba nguồn, ba quy ước khác nhau
        ↓
    Ngày: "02/09/2026" vs
          "2026-09-02" vs
          timestamp Unix
        ↓
    Mã khách: "C12345" vs
              "12345" vs
              email
        ↓
    ⚠ Tên sản phẩm viết khác nhau
        ↓
    ⚠ Không chuẩn hoá thì JOIN TRƯỢT
      và báo cáo đếm sai

⚠ Vì sao ba phương án kia là việc khác:

"Tạo mô hình ML dự đoán tương lai"
    → ⚠ đó là bước SAU, khi dữ liệu
      đã sạch

"Trực quan hoá trên dashboard
 thời gian thực"
    → ⚠ đó là Looker, ở CUỐI
      đường ống

"Lưu dữ liệu THÔ ở định dạng gốc"
    → ⚠ đó là DATA LAKE,
      ngược với "transform"

Liên quan #13152 (lô 138) về ETL và ELT, và #13389 (lô 141) về giai đoạn Transform trong chuỗi giá trị dữ liệu. Cả ba nhất quán.

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

• D (lưu dữ liệu thô ở định dạng gốc để dùng sau) — phương án gần nhất về mặt "cũng là xử lý dữ liệu", nhưng đó là mô tả của data lake, ngược với ý nghĩa của chữ Transform.

• A (tạo mô hình ML) — là bước sau, khi dữ liệu đã được chuẩn hoá.

• C (trực quan hoá trên dashboard) — nằm ở cuối đường ống, không phải ETL.

Ghi nhớ

⚠ ETL và ELT — bảng phải thuộc: | Mô hình | Thứ tự | |---|---| | ETL | ⚠ Extract → Transform → Load | | | ⚠ biến đổi TRƯỚC khi nạp — kho chỉ chứa dữ liệu sạch | | ELT | ⚠ Extract → Load → Transform | | | ⚠ nạp thô rồi biến đổi bằng SQL trong kho | | Trên BigQuery | ⚠ ELT phổ biến hơn — kho có sức tính toán lớn |

Từ khoá nhận diện:

"làm sạch TRƯỚC khi nạp" → ETL "nạp thô rồi biến đổi bằng SQL" → ELT "giữ nguyên định dạng gốc" → data lake "sao chép nguyên trạng, không biến đổi" → replication / CDC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gộp có mất bản ghi không | ⚠ so số dòng trước và sau join | | Tỉ lệ khớp khoá nối | ⚠ thước đo chất lượng của việc hợp nhất | | Dữ liệu có nhất quán không | Dataform assertions |

Và một quyết định nên cân nhắc sớm khi hợp nhất nhiều nguồn: giữ lại một bản sao dữ liệu thô, kể cả khi chọn ETL. Quy tắc chuẩn hoá sẽ thay đổi — và ngày đó bạn sẽ cần chạy lại toàn bộ lịch sử, điều chỉ làm được nếu bản gốc vẫn còn.

Đáp án

C — Looker.

Vì sao đúng

Đề nêu bốn yêu cầu, tất cả đều là mô tả của một nền tảng BI tự phục vụ:

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

1. "KẾT NỐI tới kho dữ liệu BigQuery"
     → Looker truy vấn thẳng BigQuery

2. ⚠ "người dùng KHÔNG CHUYÊN
    KỸ THUẬT"
     → ⚠ không cần biết SQL

3. "DỰNG, CHIA SẺ và KHÁM PHÁ
    dashboard"
     → Look, dashboard, Explore

4. "báo cáo TỰ PHỤC VỤ"
     → ⚠ không phải xin đội dữ liệu

⚠ LookML — thứ làm nên khác biệt:

Đội dữ liệu viết LookML MỘT LẦN:
    - bảng nào nối với bảng nào
    - "doanh thu" định nghĩa thế nào
        ↓
Người dùng nghiệp vụ trong Explore:
    kéo thả chiều và chỉ số
        ↓
    ⚠ Looker sinh SQL, chạy trên
      BigQuery
        ↓
    ⚠ Không ai gõ SQL
    ⚠ ⚠ Mọi người ra CÙNG một con số

⚠ Vì sao ba phương án kia không phải:

DATAFLOW
    → ⚠ engine XỬ LÝ dữ liệu
    → đứng ở GIỮA đường ống

PUB/SUB
    → ⚠ nhận và truyền thông điệp
    → đứng ở ĐẦU đường ống

CLOUD FUNCTIONS
    → ⚠ chạy mã theo sự kiện
    → không phải công cụ BI

⚠ Gần trùng với #13261 (lô 138) và #13343 (lô 140) — cả ba đề đều là người dùng nghiệp vụ tự dựng dashboard từ BigQuery mà không cần SQL, và cả ba cùng khoá Looker. Hoàn toàn nhất quán.

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

• B (Dataflow) — phương án gần nhất trong các sản phẩm dữ liệu, nhưng nó là engine xử lý và biến đổi, cần viết Apache Beam. Không phải nơi người dùng nghiệp vụ nhìn vào.

• D (Pub/Sub) — nhận và truyền thông điệp, ở đầu đường ống.

• A (Cloud Functions) — chạy mã theo sự kiện; không phải công cụ trực quan hoá.

Ghi nhớ

⚠ Vai của từng sản phẩm — bảng phải thuộc: | Giai đoạn | Sản phẩm | |---|---| | Nhận | Pub/Sub, Datastream | | Xử lý | Dataflow, Dataform | | Lưu và phân tích | BigQuery | | ⚠ Trực quan hoá | ⚠ Looker, Looker Studio | | Học máy | Vertex AI, BigQuery ML |

Từ khoá nhận diện:

"dashboard tự phục vụ, không cần SQL" → Looker "báo cáo nhanh, có bản miễn phí" → Looker Studio "phân tích BigQuery trong bảng tính" → Connected Sheets "xử lý và biến đổi dữ liệu" → Dataflow

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có tự làm được không | ⚠ quan sát một người mới trong 30 phút đầu | | Chi phí truy vấn bao nhiêu | BigQuery job history lọc theo Looker | | Có nội dung nào hỏng không | Content Validator |

Và một điều quyết định thành bại của mọi triển khai BI tự phục vụ: chất lượng mô hình dữ liệu phía sau. Công cụ chỉ tốt bằng mô hình của nó — một LookML đặt tên khó hiểu và thiếu mô tả sẽ khiến người dùng nghiệp vụ quay lại thói quen cũ là gửi yêu cầu cho đội dữ liệu.

Đáp án

C — Vertex AI.

Vì sao đúng

Đề đòi một nền tảng DUY NHẤT, HỢP NHẤT cho toàn bộ vòng đời MLOps với nhiều vai cùng cộng tác — đó chính là lý do Vertex AI ra đời.

⚠ Bốn yêu cầu ↔ Vertex AI:

1. "huấn luyện mô hình bằng
    DỮ LIỆU CỦA CHÍNH HỌ"
     → Vertex AI Training / AutoML

2. "TỰ ĐỘNG TRIỂN KHAI để phục vụ
    dự đoán"
     → Model Registry → Endpoints

3. ⚠ "MỘT nền tảng HỢP NHẤT"
     → ⚠ không phải ghép nhiều
       sản phẩm rời rạc

4. ⚠ "nhà khoa học dữ liệu, kỹ sư ML
    và lập trình viên CÙNG CỘNG TÁC"
     → ⚠ một hệ thống quyền,
       một nơi ghi nguồn gốc

⚠ Các thành phần phục vụ từng vai:

NHÀ KHOA HỌC DỮ LIỆU
    → Workbench (notebook),
      Datasets, AutoML

KỸ SƯ ML
    → ⚠ Pipelines, Model Registry,
      Feature Store, Model Monitoring

LẬP TRÌNH VIÊN ỨNG DỤNG
    → ⚠ Endpoints — gọi API dự đoán
        ↓
    ⚠ Tất cả trong MỘT nền tảng,
      MỘT hệ thống IAM

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

TRƯỚC khi có Vertex AI
    ⚠ mỗi giai đoạn một sản phẩm
    ⚠ mỗi cái 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
    ⚠ 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,
      bằng mã nào

⚠ Gần trùng với #13307 (lô 139) — đề đó cũng đòi nền tảng hợp nhất cho toàn bộ quy trình ML, và cùng khoá Vertex AI. Hoàn toàn nhất quán.

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

• A (BigQuery) — phương án gần nhất vì BigQuery ML rất mạnh, 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ó Workbench, không có Model Monitoring, không có pipeline MLOps đầy đủ. (Hai sản phẩm tích hợp: mô hình BigQuery ML đăng ký được vào Vertex AI Model Registry.)

• B (Apigee) — quản lý API.

• D (Looker) — nền tảng BI.

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 tập dữ liệu và gán nhãn | | 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 | | Feature Store | ⚠ đặc trưng dùng chung | | Model Monitoring | phát hiện drift | | Explainable AI | giải thích dự đoán | | Model Garden | mô hình nền |

Từ khoá nhận diện:

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

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 | ⚠ tính tiền cả khi rảnh — nhớ hạ khi không dùng |

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, schema thượng nguồn đổi — và đó chính là phần mà một nền tảng MLOps hợp nhất tồn tại để lo.

Đáp án

D — Một triết lý nhấn mạnh việc phá bỏ ốc đảo giữa đội phát triển và đội vận hành để tăng tốc độ và cải thiện độ tin cậy.

Vì sao đúng

Đề mô tả đúng vấn đề mà DevOps sinh ra để giải, và đáp án nêu đúng bản chất của nó: một TRIẾT LÝ, không phải một công cụ.

⚠ Vấn đề "ném qua bức tường" trong đề:

ĐỘI PHÁT TRIỂN
  viết mã hàng tháng trời
        ↓
    ⚠ Ném qua BỨC TƯỜNG
        ↓
ĐỘI VẬN HÀNH
  vật lộn triển khai và duy trì
  ứng dụng KHÔNG QUEN THUỘC
        ↓
    ⚠ Chu kỳ phát hành chậm (hằng quý)
    ⚠ Sự cố sản xuất thường xuyên
    ⚠ Đổ lỗi cho nhau khi hỏng
    ⚠ Không phản ứng kịp nhu cầu khách

⚠ Vì sao gốc rễ là ĐỘNG CƠ NGƯỢC NHAU:

Đội phát triển được thưởng vì
RA TÍNH NĂNG NHANH
        ↓
Đội vận hành được thưởng vì
HỆ THỐNG ỔN ĐỊNH
        ↓
    ⚠ Hai mục tiêu ĐỐI NGHỊCH
        ↓
    Vận hành dựng thêm rào để tự vệ
        ↓
    → phát hành ngày càng chậm

⚠ DevOps giải bằng gì:

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

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

⚠ PHẢN HỒI NHANH
    → giám sát, đo lường

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

⚠ Gần trùng với #13321 (lô 140) — đề đó cũng mô tả đúng cảnh "ném qua bức tường" và cùng khoá DevOps. Nhất quán.

Liên quan #13415 (lô 141) — câu đó về năm mục tiêu của DevOps, trong đó có "chấp nhận thất bại là bình thường" và "giảm silo". Bổ sung cho nhau.

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

• C (một sản phẩm Google Cloud cụ thể để triển khai ứng dụng) — phương án gần nhất về mặt "cũng liên quan tới triển khai", nhưng DevOps không phải sản phẩm. Cloud Build và Cloud Deploy là công cụ hỗ trợ DevOps, không phải bản thân nó.

• B (mô hình bảo mật không tin ai theo mặc định) — đó là zero trust.

• A (phương pháp quản chi phí bằng ngân sách chặt) — đó là FinOps.

Ghi nhớ

⚠ Bốn khái niệm dễ lẫn — bảng phải thuộc: | Khái niệm | Trọng tâm | |---|---| | ⚠ DevOps | ⚠ TRIẾT LÝ VĂN HOÁ — phá silo dev và ops | | SRE | cách CÀI ĐẶT DevOps của Google — SLO, error budget | | Zero trust | ⚠ không tin theo vị trí mạng | | FinOps | quản chi phí đám mây | | Agile | phát triển theo vòng lặp ngắn |

Từ khoá nhận diện:

"văn hoá, phá silo, dev và ops" → DevOps "SLO, error budget, do Google khởi xướng" → SRE "không tin ai, xác minh mọi yêu cầu" → zero trust "kiểm soát chi phí đám mây" → FinOps

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

Và một phép thử rất thẳng cho biết một tổ chức có thật sự làm DevOps hay chỉ mua công cụ: hỏi ai chịu trách nhiệm khi dịch vụ sập lúc nửa đêm. Nếu câu trả lời vẫn là "đội vận hành", thì bức tường mà đề mô tả vẫn còn nguyên — chỉ là giờ có thêm một đường ống CI/CD chạy xuyên qua nó.

Đáp án

A — BigQuery.

Vì sao đúng

BigQuery có tích hợp gốc (native) với Google Analytics 4, cho phép xuất dữ liệu sự kiện thô sang và truy vấn bằng SQL.

⚠ Vì sao cần đưa GA4 sang BigQuery:

Báo cáo chuẩn của GA4
    → ⚠ giao diện dựng sẵn
    → ⚠ dữ liệu đã được TỔNG HỢP
    → ⚠ giới hạn về chiều và
      cách kết hợp
        ↓
Xuất sang BigQuery
        ↓
    ⚠ Dữ liệu SỰ KIỆN THÔ,
      từng lượt tương tác
    ⚠ Truy vấn SQL TUỲ Ý
    ⚠ ⚠ NỐI với dữ liệu khác:
      đơn hàng, CRM, quảng cáo
    ⚠ Dựng mô hình dự đoán

⚠ Đúng ba nhu cầu trong đề:

"SQL phức tạp kết hợp hành vi web,
 mẫu mua hàng và phân khúc riêng"
        ↓
    ⚠ Chỉ làm được khi có dữ liệu THÔ
      trong một kho truy vấn được

"dựng MÔ HÌNH DỰ ĐOÁN"
        ↓
    ⚠ BigQuery ML — huấn luyện
      ngay trên dữ liệu đó

⚠ Cách tích hợp hoạt động:

GA4 → bật "BigQuery Links"
        ↓
    ⚠ Xuất tự động hằng ngày
      (hoặc theo luồng)
        ↓
    Bảng `events_YYYYMMDD`
        ↓
    ⚠ Mỗi dòng là MỘT SỰ KIỆN,
      có cấu trúc LỒNG NHAU
      (event_params là mảng)
        ↓
    Truy vấn bằng SQL với UNNEST

⚠ Vì sao ba phương án kia không phải:

CLOUD SPANNER
    → ⚠ CSDL giao dịch toàn cầu
    → không có tích hợp GA4

FIRESTORE
    → ⚠ NoSQL cho ứng dụng di động
    → không truy vấn SQL phức tạp

CLOUD SQL
    → ⚠ CSDL quan hệ một vùng
    → không có tích hợp GA4,
      và không quét nổi khối lượng
      dữ liệu clickstream

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

• D (Cloud SQL) — phương án gần nhất về mặt "cũng dùng SQL", nhưng nó là CSDL giao dịch một máy chủ: không có tích hợp gốc với GA4, và không xử lý nổi khối lượng dữ liệu clickstream.

• B (Cloud Spanner) — CSDL quan hệ toàn cầu cho giao dịch, không phải phân tích.

• C (Firestore) — NoSQL tài liệu, không hỗ trợ truy vấn phân tích phức tạp.

Ghi nhớ

⚠ Các nguồn có connector sẵn cho BigQuery — bảng nên thuộc: | Nguồn | Công cụ | |---|---| | ⚠ Google Analytics 4 | ⚠ BigQuery Links — tích hợp gốc | | Google Ads | ⚠ BigQuery Data Transfer Service | | YouTube | Data Transfer Service | | Google Search Console | Data Transfer Service | | CSDL quan hệ | Datastream (CDC) | | SaaS bên thứ ba | Data Transfer Service hoặc partner |

Từ khoá nhận diện:

"GA4, SQL, phân tích sâu" → BigQuery "dữ liệu quảng cáo Google" → Data Transfer Service → BigQuery "dashboard cho lãnh đạo" → Looker trên BigQuery "dự đoán bằng SQL" → BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu byte | ⚠ luôn lọc theo ngày trước | | Có nối được với đơn hàng không | ⚠ cần user_id được gửi lên GA4 | | Số liệu có khớp báo cáo GA4 không | có thể lệch nhẹ do cách tính khác nhau |

Và một điều gây bối rối cho nhiều đội khi mới đưa GA4 sang BigQuery: con số tự tính bằng SQL thường không khớp chính xác với báo cáo trong giao diện GA4. Đó không phải lỗi — hai nơi dùng cách gom phiên, lọc bot và lấy mẫu khác nhau, nên điều quan trọng là chọn một nguồn làm chuẩn và giải thích rõ cho người đọc báo cáo.

Đáp án

B — Cloud Spanner.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ Spanner có đủ cả ba:

⚠ Ba yêu cầu ↔ Spanner:

1. "quy mô TOÀN CẦU, người chơi
    khắp thế giới"
     → cấu hình đa vùng

2. "HÀNG TRIỆU GIAO DỊCH MỖI GIÂY"
     → mở rộng ngang, thêm node
       là thêm năng lực

3. ⚠ "NHẤT QUÁN MẠNH"
     → ⚠ đây là điều kiện loại trừ
     → TrueTime, nhất quán ngoại

⚠ Vì sao game cần nhất quán mạnh:

Vật phẩm giới hạn, giao dịch trong game
        ↓
    Nếu chỉ NHẤT QUÁN CUỐI CÙNG
        ↓
    ⚠ Hai máy chủ ở hai châu lục
      cùng thấy "còn hàng"
    ⚠ Cùng bán → bán quá số có
    ⚠ Hoặc trừ tiền hai lần
        ↓
    Spanner: giao dịch nguyên tử
    xuyên vùng
        ↓
    → mọi nơi thấy cùng một trạng thái

⚠ Vì sao ba phương án kia thiếu một thứ:

BIGTABLE
    → mở rộng ngang ✔
    → thông lượng cực lớn ✔
    → ⚠ nhưng giao dịch CHỈ TRONG
      MỘT DÒNG ✘
    → ⚠ bản sao đa vùng chỉ
      NHẤT QUÁN CUỐI CÙNG ✘

CLOUD SQL
    → quan hệ, ACID ✔
    → ⚠ chỉ mở rộng DỌC ✘
    → ⚠ không ghi đa vùng ✘

CLOUD STORAGE
    → ⚠ lưu TỆP, không phải CSDL

⚠ Gần trùng với #13331 (lô 140), #13300 (lô 139), #13253 và #13141 (lô 138) — cả năm đề đều nêu bộ yêu cầu toàn cầu + nhất quán mạnh + giao dịch, và cả năm cùng khoá Spanner. Hoàn toàn nhất quán. Đây là mẫu đề lặp nhiều nhất trong phần cơ sở dữ liệu.

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

• D (Bigtable) — phương án gần nhất về mặt "hàng triệu thao tác mỗi giây": Bigtable thật sự đạt được thông lượng đó. Nhưng nó chỉ có giao dịch trong phạm vi MỘT DÒNG và bản sao đa vùng là nhất quán cuối cùng — không thoả "nhất quán mạnh".

• C (Cloud SQL) — quan hệ và ACID, nhưng chỉ mở rộng dọc và không ghi được ở nhiều vùng.

• A (Cloud Storage) — lưu tệp, không phải cơ sở dữ liệu giao dịch.

Ghi nhớ

⚠ Ma trận chọn CSDL — bảng phải thuộc: | CSDL | Giao dịch nhiều dòng? | Ngang? | Nhất quán mạnh toàn cầu? | |---|---|---|---| | Cloud SQL | ✔ | ✘ | ✘ | | ⚠ Spanner | ✔ | ✔ | ⚠ ✔ — duy nhất | | Bigtable | ⚠ ✘ (chỉ 1 dòng) | ✔ | ✘ | | Firestore | phạm vi hẹp | ✔ | phạm vi hẹp | | BigQuery | không áp dụng | ✔ | OLAP |

Từ khoá nhận diện:

"toàn cầu + nhất quán mạnh + giao dịch" → ⚠ Spanner, luôn luôn "hàng triệu ghi/giây, KHÔNG cần giao dịch" → Bigtable "MySQL một vùng" → Cloud SQL "phân tích lịch sử" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hotspot khoá không | Key Visualizer | | CPU thế nào | ⚠ giữ dưới 65% cho đa vùng | | Truy vấn nào chậm | Query Insights |

Và một quyết định quan trọng hơn việc chọn Spanner: quyết định dữ liệu nào cần đưa vào đó. Giao dịch mua vật phẩm thì có, nhưng vị trí nhân vật cập nhật ba mươi lần mỗi giây thì không — đưa nhầm loại dữ liệu vào là cách nhanh nhất biến một lựa chọn đúng thành một hoá đơn sai.

Đáp án

D — Là một PHÉP ĐO ĐỊNH LƯỢNG về hiệu năng của dịch vụ, ví dụ độ sẵn sàng hoặc độ trễ.

Vì sao đúng

SLI (Service Level Indicator) là con số được đo, không phải mục tiêu và cũng không phải hợp đồng.

⚠ Ba khái niệm, ba vai:

⚠ SLI — Service Level Indicator
    → ⚠ CHỈ SỐ được ĐO
    → "tỉ lệ request thành công",
      "độ trễ p99"
    → ⚠ là con số thô — đề này

SLO — Service Level Objective
    → ⚠ MỤC TIÊU đặt TRÊN chỉ số đó
    → "99,9% request dưới 300ms"

SLA — Service Level Agreement
    → ⚠ HỢP ĐỒNG với khách hàng
    → có bồi thường nếu vi phạm

⚠ Áp vào đề:

"theo dõi hiệu năng THỰC TẾ"
"đo các chỉ số CỤ THỂ như tỉ lệ
 request thành công và thời gian
 phản hồi"
        ↓
    ⚠ Đây là mô tả của SLI:
      PHÉP ĐO, chưa có ngưỡng
        ↓
    Thêm ngưỡng → thành SLO
    Đưa vào hợp đồng → thành SLA

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

"TỰ ĐỘNG SỬA các vấn đề gây lỗi"
    → ⚠ SLI chỉ ĐO, không sửa

"Định nghĩa HỢP ĐỒNG kinh doanh
 với khách hàng"
    → ⚠ đó là SLA

"Đặt MỤC TIÊU về mức độ tin cậy"
    → ⚠ đó là SLO
        ↓
    ⚠ Ba phương án sai được tạo ra
      bằng cách lấy định nghĩa của
      SLA và SLO

⚠ Đối chiếu #13353 (lô 140) — đề đó mô tả "độ trễ đo mỗi phút phải DƯỚI 300ms" và khoá SLO, vì có NGƯỠNG. Câu này chỉ mô tả phép đo, nên khoá SLI. Không mâu thuẫn — khác nhau ở chỗ có ngưỡng hay không.

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

• C (đặt mục tiêu về mức độ tin cậy) — phương án gần nhất và là bẫy chính: đó là định nghĩa của SLO. SLI là chỉ số, SLO là mục tiêu đặt trên chỉ số đó.

• B (định nghĩa hợp đồng kinh doanh với khách hàng) — đó là SLA.

• A (tự động sửa vấn đề) — SLI chỉ đo, không có khả năng hành động.

Ghi nhớ

⚠ SLI, SLO, SLA, Error budget — bảng phải thuộc: | Khái niệm | Là gì | Ví dụ | |---|---|---| | ⚠ SLI | ⚠ CHỈ SỐ đo được | "tỉ lệ request dưới 300ms" | | SLO | MỤC TIÊU trên SLI | "99,9% request dưới 300ms" | | SLA | ⚠ HỢP ĐỒNG, có bồi thường | "99,5%, không đạt thì hoàn tiền" | | Error budget | 100% − SLO | "0,1% ≈ 43 phút/tháng" |

Từ khoá nhận diện:

"phép đo, chỉ số được đo" → SLI "mục tiêu, ngưỡng phải đạt" → SLO "cam kết với khách, có bồi thường" → SLA "phần được phép hỏng" → error budget

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SLI có phản ánh trải nghiệm không | ⚠ người dùng có cảm nhận được chỉ số này không | | Đang đo percentile hay trung bình | ⚠ trung bình là dấu hiệu chưa chín | | SLO có dựa trên đường nền thật không | |

Và một sai lầm rất phổ biến khi mới thiết lập SLI: chọn thứ dễ đo thay vì thứ đáng đo. CPU và bộ nhớ hiện sẵn trong mọi dashboard, nhưng người dùng không bao giờ phàn nàn về CPU — họ phàn nàn vì trang tải chậm, và đó mới là thứ SLI nên đo.

Đáp án

C — Bare Metal Solution.

Vì sao đúng

Đề nêu một ràng buộc rất cụ thể mà máy ảo không đáp ứng được: phải chạy trên PHẦN CỨNG VẬT LÝ ĐƯỢC CHỨNG NHẬN.

⚠ Ba manh mối ↔ Bare Metal Solution:

1. "tải Oracle CHUYÊN BIỆT"
     → phần mềm doanh nghiệp
       có ràng buộc chứng nhận

2. ⚠ "CHƯA ĐƯỢC CHỨNG NHẬN chạy
    trong môi trường ẢO HOÁ chuẩn"
     → ⚠ loại thẳng mọi máy ảo

3. ⚠ "phải chạy trên PHẦN CỨNG
    VẬT LÝ được chứng nhận"
     → ⚠ cần máy chủ THẬT

⚠ Bare Metal Solution là gì:

Máy chủ VẬT LÝ chuyên dụng
        ↓
    ⚠ Đặt trong cơ sở của Google,
      KỀ SÁT các vùng Google Cloud
        ↓
    ⚠ KHÔNG có hypervisor —
      bạn chạy thẳng trên phần cứng
        ↓
    ⚠ Kết nối độ trễ RẤT THẤP
      (dưới 2ms) tới Google Cloud
        ↓
    → dùng được BigQuery, GKE,
      Cloud Storage như bình thường

⚠ Vì sao đây là cầu nối lý tưởng:

Công ty muốn RA KHỎI trung tâm
dữ liệu của mình
        ↓
    ⚠ Nhưng Oracle không chạy
      trên VM được
        ↓
    Bare Metal Solution:
    ⚠ ra khỏi trung tâm dữ liệu ✔
    ⚠ vẫn có phần cứng vật lý ✔
    ⚠ vẫn dùng được dịch vụ
      Google Cloud ✔

⚠ Đối chiếu #13338 và #13384 (lô 140/141) — hai đề đó khoá Compute Engine vì chỉ cần kiểm soát hệ điều hành (module kernel, phần mềm cũ). Câu này khoá Bare Metal Solution vì cần phần cứng VẬT LÝ được chứng nhận, không chấp nhận tầng ảo hoá. Không mâu thuẫn — khác nhau ở mức độ ràng buộc.

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

• D (Compute Engine) — phương án gần nhất và đúng cho phần lớn tải công việc cần kiểm soát OS. Nhưng nó vẫn là máy ẢO chạy trên hypervisor, mà đề nói rõ workload chưa được chứng nhận cho môi trường ảo hoá.

• A (Cloud SQL) — dịch vụ có quản lý cho MySQL, PostgreSQL, SQL Server — không hỗ trợ Oracle.

• B (GKE) — chạy container; càng xa yêu cầu phần cứng vật lý.

Ghi nhớ

⚠ Thang mức kiểm soát hạ tầng — bảng nên thuộc: | Mức | Sản phẩm | |---|---| | ⚠ Phần cứng VẬT LÝ chuyên dụng | ⚠ Bare Metal Solution | | Máy chủ vật lý riêng (vẫn ảo hoá) | ⚠ Sole-tenant node | | Máy ảo | Compute Engine | | Container | GKE, Cloud Run | | Chỉ mã nguồn | App Engine |

Từ khoá nhận diện:

"phần cứng vật lý được chứng nhận, Oracle chuyên biệt" → Bare Metal Solution "giấy phép tính theo lõi vật lý, vẫn dùng VM" → ⚠ sole-tenant node "cần quyền root và kernel" → Compute Engine "MySQL/PostgreSQL có quản lý" → Cloud SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phần mềm có thật sự không chạy được trên VM không | ⚠ kiểm ma trận chứng nhận của nhà cung cấp | | Giấy phép có mang sang được không | đọc kỹ điều khoản | | Độ trễ tới dịch vụ Google Cloud | đo thật sau khi triển khai |

Và một câu hỏi đáng đặt lại định kỳ với mọi tải công việc đang chạy trên Bare Metal: ràng buộc chứng nhận đó có còn đúng không? Ma trận hỗ trợ của các nhà cung cấp phần mềm doanh nghiệp thay đổi theo thời gian, và một hệ thống bị khoá vào phần cứng vật lý từ năm năm trước đôi khi đã có thể chạy trên máy ảo từ lâu.