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

Đáp án

D — Data Lake (hồ dữ liệu).

Vì sao đúng

Định nghĩa trong đề — kho tập trung, chứa dữ liệu có cấu trúc, bán cấu trúc và PHI cấu trúc, ở mọi quy mô — là định nghĩa chuẩn của data lake.

⚠ Điều gì làm nên hồ dữ liệu:

⚠ MỌI ĐỊNH DẠNG
    → bảng CSV, JSON, log,
      ảnh, video, âm thanh, PDF

⚠ DỮ LIỆU THÔ, GIỮ NGUYÊN GỐC
    → ⚠ không phải làm sạch
      trước khi nạp

⚠ SCHEMA-ON-READ
    → ⚠ áp cấu trúc LÚC ĐỌC,
      không phải lúc ghi
    → ngược với warehouse

⚠ QUY MÔ KHÔNG GIỚI HẠN, GIÁ RẺ
    → trên Google Cloud:
      ⚠ Cloud Storage

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

"Database"
    → ⚠ dữ liệu CÓ CẤU TRÚC,
      cho GIAO DỊCH

"Data Warehouse"
    → ⚠ có cấu trúc, ĐÃ LÀM SẠCH,
      schema-on-WRITE

"Data Mart"
    → ⚠ một LÁT CẮT nhỏ của kho,
      phục vụ một phòng ban

Đối chiếu #13495 (cùng lô) — đề đó phân biệt database (OLTP) và warehouse (OLAP). Cùng với đề này thành bộ ba hoàn chỉnh: hồ – kho – CSDL. Hoàn toàn nhất quán.

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

• B (Data Warehouse) — phương án gần nhất vì cũng là kho tập trung quy mô lớn, nhưng nó chỉ nhận dữ liệu đã có cấu trúc và đã được làm sạch, với schema xác định trước khi ghi.

• A (Database) — hệ giao dịch, dữ liệu có cấu trúc.

• C (Data Mart) — tập con của kho, không phải nơi chứa mọi loại dữ liệu.

Ghi nhớ

⚠ Bốn khái niệm — bảng phải thuộc: | | Chứa gì | Schema | Ai dùng | |---|---|---|---| | Database | ⚠ có cấu trúc, hiện hành | on-write | ứng dụng | | Data Warehouse | ⚠ có cấu trúc, đã sạch | on-write | nhà phân tích | | ⚠ Data Lake | ⚠ MỌI loại, THÔ | ⚠ on-READ | ⚠ kỹ sư dữ liệu, ML | | Data Mart | ⚠ lát cắt của kho | on-write | một phòng ban |

Từ khoá nhận diện:

"mọi định dạng, thô, mọi quy mô" → ⚠ data lake "đã làm sạch, để báo cáo" → data warehouse "riêng cho phòng marketing" → ⚠ data mart "kết hợp hồ và kho" → ⚠ lakehouse — BigLake, Dataplex

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai tìm được dữ liệu trong hồ không | ⚠ thử hỏi một người mới | | Chi phí lưu trữ đang tăng thế nào | ⚠ bật lifecycle policy hoặc Autoclass | | Dữ liệu nhạy cảm nằm ở đâu | ⚠ quét bằng Sensitive Data Protection |

Và ranh giới giữa một hồ dữ liệu và một đầm lầy dữ liệu không nằm ở công nghệ mà ở kỷ luật: mỗi tập dữ liệu phải có chủ sở hữu, mô tả và chính sách vòng đời ngay từ lúc được đổ vào. Bổ sung những thứ đó sau, khi hồ đã chứa hàng chục nghìn thư mục, gần như không ai làm nổi.

Đáp án

B — Google Kubernetes Engine (GKE).

Vì sao đúng

Đề nói rõ: môi trường có quản lý để chạy container, nhưng muốn kiểm soát chi tiết cấu hình cụm, mạng và node pool. Chỉ GKE cho cả hai vế đó.

⚠ Vì sao là GKE:

"môi trường CÓ QUẢN LÝ"
    → ⚠ Google lo control plane,
      vá lỗi, nâng cấp

"kiểm soát CHI TIẾT cụm"
    → ⚠ phiên bản K8s, kênh phát hành

"kiểm soát MẠNG"
    → ⚠ VPC-native, network policy,
      Private cluster, dải IP pod

"kiểm soát NODE POOL"
    → ⚠ loại máy, GPU, Spot VM,
      taint và label, autoscaling
      từng pool riêng

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

"Cloud Run"
    → ⚠ chạy container rất tốt
    → ⚠ nhưng KHÔNG có khái niệm
      node pool hay cấu hình cụm
    → đó chính là ĐIỂM MẠNH của nó,
      và ở đề này là điểm không hợp

"App Engine"
    → ⚠ PaaS, ít quyền kiểm soát
      hạ tầng hơn nữa

"Cloud Functions"
    → ⚠ chạy HÀM, không chạy
      container tuỳ ý theo cách này

⚠ Đối chiếu #13511 (cùng lô) — đề đó khoá Cloud Run vì yêu cầu là serverless, trả theo request. Đề này khoá GKE vì yêu cầu là kiểm soát chi tiết. Không mâu thuẫn — dữ kiện quyết định khác nhau.

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

• A (Cloud Run) — phương án gần nhất vì cũng chạy chính những container đó và cũng có quản lý, nhưng nó cố tình giấu đi cụm, mạng và node — đúng thứ đề đòi phải kiểm soát được.

• C (App Engine) — trừu tượng hoá còn cao hơn.

• D (Cloud Functions) — đơn vị triển khai là hàm.

Ghi nhớ

⚠ Thang mức kiểm soát — bảng phải thuộc: | Dịch vụ | Bạn kiểm soát | Google lo | |---|---|---| | Compute Engine | ⚠ toàn bộ OS | phần cứng | | ⚠ GKE Standard | ⚠ node pool, mạng, phiên bản | ⚠ control plane | | GKE Autopilot | ⚠ workload, một phần cấu hình | ⚠ node | | Cloud Run | ⚠ CHỈ container | ⚠ mọi thứ còn lại | | Cloud Functions | ⚠ chỉ mã hàm | mọi thứ còn lại |

Từ khoá nhận diện:

"kiểm soát cụm, node pool, mạng" → ⚠ GKE "container nhưng không muốn quản gì" → Cloud Run "cần GPU, cấu hình máy đặc thù" → ⚠ GKE hoặc Compute Engine "chạy K8s ở nhiều nơi" → Anthos / GKE Enterprise

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có thật sự cần cấu hình cụm không | không → ⚠ Cloud Run rẻ và nhẹ hơn | | Cần GPU hay loại máy đặc thù không | có → GKE | | Ai vận hành cụm | ⚠ không rõ → chọn Autopilot |

Và cách phân biệt nhanh hai đề trông rất giống nhau trong bài thi: tìm xem đề có nhắc tới node, cụm, mạng hay không. Có thì là GKE; còn nếu đề chỉ nói "container, serverless, trả theo mức dùng" thì đó là Cloud Run.

Đáp án

B — Cloud Logging.

Vì sao đúng

Đề mô tả chính xác việc tìm kiếm trong log: lọc các dòng chứa chữ "FATAL" trong một giờ qua. Đó là công việc của Cloud Logging.

⚠ Cloud Logging cho bạn:

⚠ THU THẬP
    → log từ mọi dịch vụ Google Cloud
    → ⚠ và từ ứng dụng của bạn

⚠ TÌM KIẾM
    → Logs Explorer, lọc theo
      thời gian, mức độ, chuỗi

⚠ LƯU GIỮ và ĐỊNH TUYẾN
    → ⚠ sink sang BigQuery,
      Cloud Storage, Pub/Sub

⚠ CẢNH BÁO TỪ LOG
    → ⚠ log-based metric →
      Cloud Monitoring alert

⚠ Truy vấn cho đúng đề này:

severity>=ERROR
textPayload:"FATAL"
        ↓
    ⚠ chọn khoảng thời gian
      "Last 1 hour"

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

"Cloud Monitoring"
    → ⚠ làm việc với CHỈ SỐ (số liệu
      theo thời gian): CPU, độ trễ
    → ⚠ không phải nơi tìm chuỗi
      trong văn bản log

"Resource Manager"
    → ⚠ quản CÂY TỔ CHỨC:
      tổ chức, thư mục, dự án

"Cloud Billing"
    → ⚠ chi phí

Đối chiếu #13485 (cùng lô) — đề đó về Admin Activity audit log, cũng nằm trong Cloud Logging. Đề này là log ứng dụng. Cùng dịch vụ, khác loại log — hoàn toàn nhất quán.

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

• C (Cloud Monitoring) — phương án gần nhất vì cả hai đều thuộc bộ Google Cloud Observability và thường dùng cùng nhau, nhưng Monitoring làm việc với chỉ số dạng số, không phải văn bản log.

• A (Resource Manager) và D (Cloud Billing) — không liên quan tới log.

Ghi nhớ

⚠ Bộ quan sát của Google Cloud — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | ⚠ Cloud Logging | ⚠ "chuyện gì đã xảy ra?" — VĂN BẢN | | ⚠ Cloud Monitoring | ⚠ "hệ thống khoẻ không?" — CHỈ SỐ | | ⚠ Cloud Trace | ⚠ "thời gian tiêu ở đâu?" — độ trễ phân tán | | Cloud Profiler | ⚠ "hàm nào ngốn CPU?" | | Error Reporting | ⚠ gom lỗi giống nhau thành nhóm |

Từ khoá nhận diện:

"tìm chuỗi trong log, gỡ lỗi" → ⚠ Cloud Logging "CPU, độ trễ, cảnh báo ngưỡng" → Cloud Monitoring "request chậm ở bước nào" → ⚠ Cloud Trace "ai đã làm gì trên tài nguyên" → ⚠ Cloud Audit Logs

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có ghi log đủ để gỡ lỗi không | ⚠ thử tái hiện lỗi rồi tìm lại | | Chi phí log tháng này bao nhiêu | ⚠ xem theo nguồn, loại bớt log ồn | | Có cảnh báo khi xuất hiện FATAL chưa | ⚠ dựng log-based metric + alert |

Và một thay đổi nhỏ mang lại khác biệt lớn khi đến lúc phải gỡ lỗi thật: ghi log dưới dạng JSON có cấu trúc và gắn sẵn trace id. Lúc đó việc tìm nguyên nhân không còn là mò chuỗi văn bản, mà là lọc theo trường và nhảy thẳng sang toàn bộ hành trình của đúng request đã hỏng.

Đáp án

C — TensorFlow.

Vì sao đúng

Dữ kiện quyết định của đề là lo bị khoá chân nhà cung cấp và muốn framework mã nguồn mở để có thể mang mô hình đi nơi khác.

⚠ Vì sao TensorFlow đáp ứng:

⚠ MÃ NGUỒN MỞ
    → Google tạo ra rồi mở mã
    → ⚠ chạy được ở BẤT KỲ đâu:
      đám mây khác, máy tại chỗ,
      cả trên điện thoại

⚠ MÔ HÌNH LÀ TỆP CHUẨN
    → SavedModel mang đi được
        ↓
    ⚠ Không lệ thuộc vào một
      nhà cung cấp nào

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

"BigQuery ML"
    → ⚠ tuyệt vời khi đội biết SQL
    → ⚠ nhưng mô hình sống TRONG
      BigQuery — đúng thứ đề lo
    (⚠ xuất sang TensorFlow được,
     nhưng bản thân nó không phải
     framework mã nguồn mở)

"Apigee"  → ⚠ quản lý API
"Looker"  → ⚠ công cụ BI

⚠ Đối chiếu #13523 (cùng lô) — đề đó khoá BigQuery ML vì dữ kiện là "thạo SQL, dữ liệu ở BigQuery". Đề này khoá TensorFlow vì dữ kiện là "mã nguồn mở, chống khoá chân". Không mâu thuẫn — hai đề hỏi hai tiêu chí khác nhau.

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

• D (BigQuery ML) — phương án gần nhất vì cũng dựng được mô hình dự đoán rời bỏ, nhưng nó là dịch vụ riêng của Google Cloud, không phải framework mở mang đi được.

• A (Apigee) và B (Looker) — không phải công cụ học máy.

Ghi nhớ

⚠ Trụ cột "Freedom" — công nghệ mở của Google Cloud: | Công nghệ | Google mở mã | |---|---| | ⚠ Kubernetes | ⚠ điều phối container | | ⚠ TensorFlow | ⚠ học máy | | Apache Beam | ⚠ nền của Dataflow | | gRPC, Istio | giao tiếp dịch vụ | | Ý nghĩa | ⚠ mang khối lượng công việc đi nơi khác được |

Từ khoá nhận diện:

"mã nguồn mở, chống khoá chân" → ⚠ TensorFlow / Kubernetes "thạo SQL, dữ liệu ở BigQuery" → BigQuery ML "không có kỹ sư ML, nhãn riêng" → AutoML "nhiều đám mây, một mặt phẳng quản lý" → ⚠ Anthos / GKE Enterprise

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Chuyển đi thật thì tốn gì | ⚠ ước tính đi, đừng chỉ lo chung chung | | Phần nào thật sự cần mang đi được | ⚠ hiếm khi là TẤT CẢ | | Định dạng dữ liệu có mở không | ⚠ Parquet, Avro dễ đi hơn |

Và một cách nhìn thực tế về nỗi lo khoá chân: chi phí của việc không bao giờ dùng dịch vụ có quản lý thường cao hơn chi phí của việc một ngày nào đó phải chuyển đi. Đáng làm là giữ phần lõi ở định dạng và framework mở, rồi thoải mái tận dụng những gì nền tảng cung cấp quanh nó.

Đáp án

D — Rehost (hay Lift and Shift).

Vì sao đúng

Rehost là chuyển ứng dụng lên đám mây gần như nguyên trạng — nhanh nhất và ít thay đổi mã nhất, đúng hai điều kiện đề nêu.

⚠ Rehost làm gì:

Máy chủ vật lý tại chỗ
        ↓
    ⚠ chuyển sang MÁY ẢO
      trên Compute Engine
        ↓
    ⚠ mã nguồn gần như KHÔNG ĐỔI
    ⚠ kiến trúc KHÔNG ĐỔI
    ⚠ CSDL vẫn tự quản
        ↓
    → nhanh nhất, rủi ro thấp nhất

⚠ Đánh đổi phải biết:

ĐƯỢC
    → ⚠ nhanh, rủi ro thấp
    → ⚠ RA KHỎI trung tâm dữ liệu sớm
    → dừng hợp đồng thuê chỗ

MẤT
    → ⚠ KHÔNG tận dụng được
      tính co giãn tự động
    → ⚠ vẫn phải vá OS, vẫn quản CSDL
    → ⚠ chi phí có khi KHÔNG giảm
      nhiều nếu chỉ chuyển y nguyên

Nhất quán với #13280 và #13370 (lô 141) — cùng khoá Rehost. Đối chiếu #13502 (lô 143) khoá Retire, #13297/#13385 khoá Replatform, #13373 khoá Refactor. Cùng khung sáu chữ R, khác mức thay đổi đề yêu cầu.

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

• A (Refactor) — phương án gần nhất vì cũng là một chiến lược di chuyển hợp lệ, nhưng nó đòi viết lại ứng dụng — trái hẳn với "ít thay đổi mã nhất".

• C (Retire) — dành cho ứng dụng không còn giá trị.

• B (Reimagine) — không phải một trong sáu chữ R chuẩn.

Ghi nhớ

⚠ Sáu chữ R — bảng phải thuộc: | Chữ R | Mức thay đổi | Khi nào | |---|---|---| | ⚠ Rehost | ⚠ gần như không đổi | ⚠ nhanh nhất — đề này | | Replatform | ⚠ đổi nhỏ, ví dụ sang CSDL có quản lý | cân bằng | | Refactor | ⚠ viết lại theo kiến trúc đám mây | giá trị cao | | Repurchase | bỏ, mua SaaS | có sản phẩm thay thế | | Retire | ⚠ bỏ hẳn | không còn giá trị | | Retain | giữ tại chỗ | ⚠ chưa sẵn sàng hoặc luật cấm |

Từ khoá nhận diện:

"nhanh nhất, ít đổi mã nhất" → ⚠ Rehost "đổi sang dịch vụ có quản lý" → Replatform "tận dụng tối đa đám mây" → Refactor "không ai dùng nữa" → Retire "luật buộc ở lại" → Retain

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí sau khi chuyển | ⚠ chuyển y nguyên có thể KHÔNG rẻ hơn — phải giảm cỡ | | Có phụ thuộc gì ở lại không | ⚠ kiểm mạng và hệ thống liên quan | | Kế hoạch tối ưu sau đó | ⚠ đặt mốc thời gian, đừng để quên |

Và điều khiến nhiều dự án lift-and-shift gây thất vọng về mặt tài chính: hoá đơn tháng đầu tiên thường không thấp hơn chi phí cũ. Khoản tiết kiệm thật đến từ bước sau — giảm cỡ máy, bật co giãn tự động và chuyển dần sang dịch vụ có quản lý — nên nếu bỏ qua bước đó thì công sức di chuyển chỉ đổi được chỗ đặt máy.

Đáp án

B — Cloud Run.

Vì sao đúng

Đề mô tả đúng lời hứa của Cloud Run: đưa vào một image container, nền tảng lo phần chạy và co giãn theo lưu lượng.

⚠ Quy trình thật:

Đóng gói ứng dụng thành container
        ↓
    Đẩy image lên Artifact Registry
        ↓
    ⚠ `gcloud run deploy`
        ↓
    ⚠ Có ngay URL HTTPS
    ⚠ Tự co giãn từ 0 tới hàng nghìn
    ⚠ Không cụm, không máy chủ
      nào để quản

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

"Cloud Armor"
    → ⚠ tường lửa ứng dụng web,
      chống DDoS — bảo vệ chứ
      không CHẠY ứng dụng

"BigQuery"
    → ⚠ kho dữ liệu phân tích

"Cloud Storage"
    → ⚠ lưu đối tượng; ⚠ phục vụ
      được trang TĨNH nhưng KHÔNG
      chạy được container

Nhất quán với #13511 (lô 143) — cùng khoá Cloud Run cho container serverless, và #13489 (lô 143) về co về 0. Đối chiếu #13515 (lô 143) khoá GKE khi đề đòi kiểm soát cụm.

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

• D (Cloud Storage) — phương án gần nhất về mặt "cũng phục vụ nội dung web trực tiếp", nhưng nó chỉ trả về tệp tĩnh; nó không chạy mã trong container.

• A (Cloud Armor) — lớp bảo vệ đặt trước ứng dụng.

• C (BigQuery) — dịch vụ phân tích dữ liệu.

Ghi nhớ

⚠ Chạy ứng dụng ở đâu — bảng phải thuộc: | Dịch vụ | Đơn vị triển khai | Co về 0 | |---|---|---| | Compute Engine | máy ảo | ❌ | | GKE | ⚠ pod trên cụm | ❌ ⚠ node vẫn tính tiền | | ⚠ Cloud Run | ⚠ container | ✅ ⚠ có | | Cloud Functions | ⚠ một hàm | ✅ | | App Engine | mã ứng dụng | ✅ (standard) |

Từ khoá nhận diện:

"đưa image container, tự co giãn" → ⚠ Cloud Run "cần kiểm soát cụm và node" → GKE "phản ứng một sự kiện, một hàm" → Cloud Functions "trang web tĩnh" → ⚠ Cloud Storage + CDN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Container có nghe đúng cổng không | ⚠ phải nghe biến PORT | | Có giữ trạng thái trong đĩa không | ⚠ đĩa là tạm, mất khi instance biến mất | | Chi phí xấu nhất là bao nhiêu | ⚠ đặt max instances rồi tính |

Và cấu hình nên đặt ngay ở lần triển khai đầu tiên, trước cả khi có người dùng thật: giới hạn số instance tối đa. Cloud Run co giãn rất tốt, và đó cũng là lý do một vòng lặp gọi nhầm hay một đợt bot quét có thể biến thành một hoá đơn bất ngờ nếu không có trần.

Đáp án

A — Cloud Logging.

Vì sao đúng

Đề mô tả chính xác log ứng dụng: bản ghi dạng văn bản mà mã nguồn ghi ra mỗi khi thực hiện hành động hoặc gặp lỗi. Thu thập, tìm kiếm và phân tích chúng là việc của Cloud Logging.

⚠ Vì sao là Logging chứ không phải ba cái kia:

⚠ CLOUD LOGGING
    → ⚠ VĂN BẢN: "chuyện gì đã xảy ra"
    → tìm chuỗi, lọc theo mức độ
    → ⚠ đề này

CLOUD MONITORING
    → ⚠ CHỈ SỐ dạng SỐ theo thời gian
    → CPU, độ trễ, số request

CLOUD TRACE
    → ⚠ độ trễ của MỘT request
      đi qua nhiều dịch vụ

CLOUD PROFILER
    → ⚠ hàm nào ngốn CPU/bộ nhớ

⚠ Cách gỡ lỗi thường dùng cả bộ:

Monitoring cảnh báo "tỉ lệ lỗi tăng"
        ↓
    ⚠ Logging: đọc thông báo lỗi
      cụ thể, tìm stack trace
        ↓
    ⚠ Trace: xem request chậm ở
      bước nào
        ↓
    Profiler: nếu nghi CPU

Nhất quán với #13516 (lô 143) — cùng khoá Cloud Logging, đề đó diễn đạt bằng tình huống tìm chữ "FATAL". Đối chiếu #13485 (lô 143) về Admin Activity audit log — cũng nằm trong Cloud Logging nhưng là loại log khác.

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

• C (Cloud Monitoring) — phương án gần nhất vì hai dịch vụ luôn đi cùng nhau trong bộ quan sát, nhưng Monitoring xử lý chỉ số dạng số, không phải bản ghi văn bản.

• B (Cloud Trace) — đo độ trễ phân tán.

• D (Cloud Profiler) — phân tích tiêu thụ tài nguyên ở mức hàm.

Ghi nhớ

⚠ Bốn công cụ quan sát — bảng phải thuộc: | Công cụ | Dữ liệu | Trả lời | |---|---|---| | ⚠ Cloud Logging | ⚠ văn bản | ⚠ "chuyện gì đã xảy ra?" | | ⚠ Cloud Monitoring | ⚠ số theo thời gian | ⚠ "hệ thống khoẻ không?" | | ⚠ Cloud Trace | ⚠ span của request | ⚠ "chậm ở bước nào?" | | Cloud Profiler | mẫu CPU/bộ nhớ | ⚠ "hàm nào tốn nhất?" | | Error Reporting | lỗi đã gom nhóm | "lỗi nào hay xảy ra nhất?" |

Từ khoá nhận diện:

"bản ghi văn bản, tìm kiếm, phân tích" → ⚠ Cloud Logging "ngưỡng, cảnh báo, biểu đồ CPU" → Cloud Monitoring "request đi qua nhiều dịch vụ" → Cloud Trace "ai đã thay đổi tài nguyên" → ⚠ Cloud Audit Logs

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log có đủ để dựng lại sự cố không | ⚠ thử tái hiện rồi tìm lại từ đầu | | Nguồn nào tốn nhiều nhất | ⚠ xem theo resource type trong báo cáo | | Có cảnh báo tự động chưa | ⚠ log-based metric + alert policy |

Và câu hỏi đáng đặt ra trước khi sự cố xảy ra chứ không phải trong lúc nó đang xảy ra: nếu dịch vụ này hỏng lúc nửa đêm, log hiện tại có đủ để biết vì sao không? Câu trả lời thường là chưa — và lúc bình thường thì thêm vài dòng ngữ cảnh vào log là việc rất rẻ.

Đáp án

C — Analyze (phân tích).

Vì sao đúng

Nhà phân tích đang dựng dashboard, khoan sâu và rút ra kết luận về dòng sản phẩm nào lãi nhất. Đó là giai đoạn Analyze trong chuỗi giá trị dữ liệu.

⚠ Chuỗi giá trị dữ liệu:

⚠ GENERATE (sinh ra)
    → giao dịch, cảm biến, log,
      click của người dùng

⚠ COLLECT / INGEST (thu thập)
    → Pub/Sub, Datastream,
      Storage Transfer

⚠ STORE (lưu trữ)
    → Cloud Storage, BigQuery,
      Cloud SQL

⚠ PROCESS / TRANSFORM (biến đổi)
    → Dataflow, Dataproc, Dataform
    → làm sạch, chuẩn hoá, ghép

⚠ ANALYZE (phân tích)
    → ⚠ BigQuery, Looker
    → ⚠ dashboard, rút ra hiểu biết
    → ⚠ ĐỀ NÀY

⚠ ACTIVATE (hành động)
    → đổi giá, đổi chiến dịch,
      đưa vào sản phẩm

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

"Transform"
    → ⚠ làm SẠCH và CHUẨN HOÁ dữ liệu
    → đã xong TRƯỚC khi dựng dashboard

"Store"
    → ⚠ cất giữ dữ liệu

"Generate"
    → ⚠ tạo ra dữ liệu ban đầu

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

• A (Transform) — phương án gần nhất vì Looker cũng có tầng mô hình hoá dữ liệu (LookML), nhưng việc mà đề mô tả — xem dashboard để tìm dòng sản phẩm lãi nhất — là rút ra hiểu biết, tức Analyze.

• B (Store) và D (Generate) — nằm ở đầu chuỗi.

Ghi nhớ

⚠ Chuỗi giá trị dữ liệu và công cụ — bảng nên thuộc: | Giai đoạn | Công cụ trên Google Cloud | |---|---| | Generate | ứng dụng, thiết bị IoT, log | | ⚠ Ingest | ⚠ Pub/Sub (luồng), Datastream (CDC), Transfer Service | | Store | ⚠ Cloud Storage (hồ), BigQuery (kho) | | ⚠ Process | ⚠ Dataflow, Dataproc, Dataform, Data Fusion | | ⚠ Analyze | ⚠ BigQuery, Looker, BigQuery ML — đề này | | Activate | ⚠ đưa hiểu biết vào hành động |

Từ khoá nhận diện:

"dashboard, tìm hiểu biết, so sánh" → ⚠ Analyze "làm sạch, chuẩn hoá, ghép nguồn" → Transform "đưa dữ liệu vào hệ thống" → Ingest "hành động dựa trên kết quả" → ⚠ Activate

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Dữ liệu mới đến mức nào | ⚠ quyết định được ra kịp không | | Ai chịu trách nhiệm định nghĩa chỉ số | ⚠ thiếu là mỗi phòng một số | | Kết quả này dẫn tới hành động gì | ⚠ không có thì dừng lại ở Analyze |

Và câu hỏi nên đặt cho mỗi dashboard đang tồn tại trong tổ chức: tháng trước nó đã làm thay đổi quyết định nào chưa? Nếu không, nó đang tiêu tốn chi phí truy vấn và công bảo trì mà chưa từng bước sang được giai đoạn cuối của chuỗi giá trị.

Đáp án

D — The Four Golden Signals (Bốn tín hiệu vàng).

Vì sao đúng

Bốn chỉ số đề liệt kê là bốn tín hiệu vàng kinh điển của SRE, theo đúng thứ tự mô tả.

⚠ Bốn tín hiệu vàng — bảng gốc:

⚠ LATENCY (độ trễ)
    → thời gian phục vụ một request
    → ⚠ tách request THÀNH CÔNG
      và THẤT BẠI ra riêng

⚠ ERRORS (lỗi)
    → tỉ lệ request thất bại
    → ⚠ gồm cả lỗi ngầm: trả 200
      nhưng nội dung sai

⚠ TRAFFIC (lưu lượng)
    → ⚠ nhu cầu đặt lên hệ thống
    → request/giây

⚠ SATURATION (mức bão hoà)
    → ⚠ hệ thống đang "đầy" bao nhiêu
    → ⚠ tài nguyên khan hiếm nhất:
      CPU, bộ nhớ, I/O, kết nối

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

"Four Pillars of Observability"
    → ⚠ nghe rất giống nhưng KHÔNG
      phải tên chuẩn; quan sát được
      thường nói tới BA trụ cột:
      log, metric, trace

"Five Objectives of DevOps"
    → ⚠ không phải khung có tên

"Six Strategies of Migration"
    → ⚠ đó là SÁU CHỮ R, và về
      di chuyển chứ không về giám sát

Đối chiếu #13442 (SLI), #13353 (SLO), #13479 (SLA), #13449 (error budget) — bốn tín hiệu vàng chính là nguồn để chọn SLI. Cùng một hệ khái niệm SRE, hoàn toàn nhất quán.

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

• B (Four Pillars of Observability) — phương án gần nhất và là bẫy được thiết kế kỹ: cùng con số "bốn", cùng chủ đề giám sát. Nhưng tên chuẩn của bốn chỉ số này là Four Golden Signals.

• A và C — không phải khung về giám sát.

Ghi nhớ

⚠ Bốn tín hiệu vàng — bảng phải thuộc: | Tín hiệu | Đo gì | Cảnh báo khi | |---|---|---| | ⚠ Latency | ⚠ thời gian phục vụ | ⚠ p99 vượt ngưỡng | | ⚠ Errors | ⚠ tỉ lệ thất bại | vượt ngân sách lỗi | | ⚠ Traffic | ⚠ request/giây | ⚠ tăng/giảm bất thường | | ⚠ Saturation | ⚠ mức đầy của tài nguyên | ⚠ sắp chạm trần |

Từ khoá nhận diện:

"bốn chỉ số: trễ, lỗi, lưu lượng, bão hoà" → ⚠ Four Golden Signals "chỉ số ĐO được của dịch vụ" → SLI "MỤC TIÊU nội bộ, ví dụ 99,9%" → SLO "HỢP ĐỒNG với khách, có bồi hoàn" → SLA "phần được phép hỏng" → ⚠ error budget

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đủ bốn tín hiệu chưa | ⚠ saturation hay thiếu nhất | | Đang xem trung bình hay phân vị | ⚠ đổi sang p95/p99 | | Cảnh báo tuần qua có ai xử lý không | ⚠ không ai xử → xoá hoặc sửa ngưỡng |

Và cách đơn giản nhất để biết một hệ thống cảnh báo còn khoẻ hay đã hỏng: đếm xem tuần qua có bao nhiêu cảnh báo bị bấm tắt mà không ai làm gì. Mỗi cảnh báo như vậy đang dạy đội trực rằng thông báo tiếp theo cũng có thể bỏ qua — và đó là cách một sự cố thật đi lọt.

Đáp án

A — BigQuery ML.

Vì sao đúng

Đề nêu ba dữ kiện quyết định: thạo SQL, dữ liệu nằm trong bảng BigQuery, và muốn dựng mô hình chỉ bằng lệnh SQL.

⚠ Ba dữ kiện khớp:

"kỹ năng SQL rất tốt"
    → ⚠ BigQuery ML dùng CHÍNH SQL

"dữ liệu trong bảng BigQuery"
    → ⚠ huấn luyện NGAY TẠI CHỖ,
      không phải chuyển đi đâu

"chỉ dùng lệnh SQL"
    → ⚠ loại bỏ TensorFlow và
      Vertex AI custom training

⚠ Bài toán này viết ra sao:

CREATE MODEL `ds.du_doan_click`
OPTIONS(model_type='logistic_reg',
        input_label_cols=['da_click'])
AS SELECT * FROM `ds.quang_cao`;

SELECT * FROM ML.PREDICT(
  MODEL `ds.du_doan_click`,
  TABLE `ds.hien_thi_moi`);

⚠ Dự đoán xác suất click là bài toán phân loại nhị phân → logistic_reg.

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

"Vertex AI"
    → ⚠ nền tảng ML đầy đủ, nhưng
      luồng chính đòi Python/SDK
    → AutoML tabular thì không
      phải "chỉ bằng SQL"

"TensorFlow"
    → ⚠ framework, viết bằng Python

"Cloud Functions"
    → ⚠ chạy hàm, không phải
      công cụ học máy

⚠ Gần trùng với #13503 (lô 143) và #13284 (lô 139) — cùng tình huống, cùng khoá BigQuery ML. Đối chiếu #13517 (cùng lô) khoá TensorFlow vì đề đó hỏi về chống khoá chân. Không mâu thuẫn — tiêu chí quyết định khác nhau.

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

• C (Vertex AI) — phương án gần nhất vì nó thật sự làm được bài toán này, nhưng đề nhấn mạnh chỉ bằng SQL, mà luồng làm việc chính của Vertex AI không phải SQL.

• D (TensorFlow) và B (Cloud Functions) — không phải công cụ dựng mô hình bằng SQL.

Ghi nhớ

⚠ Chọn công cụ ML theo kỹ năng — bảng phải thuộc: | Kỹ năng đội | Dữ liệu ở | Công cụ | |---|---|---| | ⚠ SQL | ⚠ BigQuery | ⚠ BigQuery ML | | Không lập trình | có nhãn | AutoML | | Không gì | tác vụ phổ quát | API dựng sẵn | | Python, kỹ sư ML | bất kỳ | Vertex AI custom |

Từ khoá nhận diện:

"chỉ bằng SQL" → ⚠ BigQuery ML "chống khoá chân, mã nguồn mở" → TensorFlow "không có kỹ sư ML, nhãn riêng" → AutoML "toàn quyền kiến trúc" → Vertex AI custom training

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình có thật sự tốt không | ⚠ ML.EVALUATE — xem AUC | | Có cột nào lộ đáp án không | ⚠ rà từng cột đầu vào | | Chi phí huấn luyện | ⚠ tính theo byte quét như truy vấn thường |

Và với bài toán dự đoán click, con số cần nhìn đầu tiên không phải độ chính xác mà là tỉ lệ click thật trong dữ liệu. Nếu chỉ có một phần trăm hiển thị dẫn tới click, thì một mô hình luôn trả lời "không click" đã đạt chín mươi chín phần trăm chính xác — và hoàn toàn vô dụng.