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

Đáp án

B — Bằng cách thúc đẩy mạnh mẽ và đóng góp cho các dự án mã nguồn mở như Kubernetes và TensorFlow.

Vì sao đúng

Chiến lược mã nguồn mở của Google là câu trả lời trực tiếp cho nỗi lo khoá chân: nếu công nghệ nền là chuẩn mở, ứng dụng của bạn chạy được ở nơi khác.

⚠ Vì sao mã nguồn mở giảm khoá chân:

Ứng dụng dựng trên Kubernetes
        ↓
    Chạy được trên:
      - GKE (Google Cloud)
      - EKS (AWS)
      - AKS (Azure)
      - cụm tự dựng TẠI CHỖ
        ↓
    ⚠ Cùng tệp YAML
    ⚠ Cùng kỹ năng của đội
        ↓
    → chuyển đi được nếu cần
    → ⚠ và chính vì CHUYỂN ĐƯỢC,
      vị thế đàm phán mạnh hơn

⚠ Các công nghệ mở do Google khởi xướng:

KUBERNETES  → điều phối container
              ⚠ chuẩn của ngành
TENSORFLOW  → học máy
APACHE BEAM → ⚠ mô hình lập trình
              của Dataflow
KNATIVE     → ⚠ nền tảng phía sau
              Cloud Run
ISTIO       → service mesh
gRPC        → giao tiếp giữa dịch vụ
        ↓
    ⚠ Mã và kỹ năng của bạn
      MANG ĐI ĐƯỢC

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

"BẮT BUỘC dùng API độc quyền
 cho mọi dịch vụ"
    → ⚠ ngược với chiến lược
      thật của Google

"Làm cho việc chuyển dữ liệu ra
 KHÔNG THỂ về mặt kỹ thuật"
    → ⚠ SAI và phi đạo đức
    → Google có công cụ xuất dữ liệu

"Giá thấp CHỈ khi cam kết dài hạn
 và độc quyền"
    → ⚠ CUD có thật nhưng
      KHÔNG đòi độc quyền,
      và không phải cách chống
      khoá chân

Nhất quán với #13267 (lô 139) — đề đó hỏi lợi ích kinh doanh của chuẩn mở (tăng linh hoạt, giảm khoá chân). Câu này hỏi Google hỗ trợ mục tiêu đó bằng cách nào. Hai câu ghép thành câu trả lời đầy đủ.

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

• D (giá thấp chỉ khi cam kết dài hạn và độc quyền) — phương án gần nhất về mặt "có nhắc tới điều có thật": Committed Use Discount có tồn tại, nhưng nó không đòi độc quyền và không phải cách Google hỗ trợ tránh khoá chân.

• A (bắt buộc dùng API độc quyền) — trái ngược với chiến lược thật.

• C (làm cho việc chuyển dữ liệu ra là bất khả thi) — sai; Google cung cấp công cụ xuất dữ liệu và cam kết về tính di động.

Ghi nhớ

⚠ Công nghệ mở do Google khởi xướng — bảng nên thuộc: | Công nghệ | Việc | |---|---| | Kubernetes | ⚠ điều phối container — chuẩn ngành | | TensorFlow | học máy | | Apache Beam | ⚠ mô hình của Dataflow | | Knative | ⚠ nền tảng của Cloud Run | | Istio | service mesh | | gRPC | giao tiếp giữa dịch vụ | | Go | ngôn ngữ lập trình |

Từ khoá nhận diện:

"chuẩn mở, tránh khoá chân" → trụ cột Freedom "chạy được ở nhiều đám mây" → Kubernetes / GKE Enterprise "truy vấn dữ liệu ở đám mây khác" → BigQuery Omni "định dạng dữ liệu mở" → Parquet, Iceberg

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao | |---|---| | Nếu phải rời đi, mất bao lâu | ⚠ ước lượng thật, đừng phỏng đoán | | Dữ liệu có ở định dạng mở không | | | Đội có kỹ năng chuyển đi được không | Kubernetes, SQL, Python |

Và một cách nhìn cân bằng về khoá chân đáng mang theo: mục tiêu không phải tránh nó hoàn toàn mà là biết mình đang trả giá bao nhiêu. Dùng BigQuery gắn bạn với Google Cloud, nhưng nếu nó giúp đội bạn phân tích nhanh gấp năm lần thì đó thường là đổi chác xứng đáng — miễn là quyết định ấy được đưa ra một cách tỉnh táo.

Đáp án

D — Cloud Load Balancing.

Vì sao đúng

Đề mô tả đúng một việc: phân phối lưu lượng đến giữa các máy ảo có sẵn để không máy nào bị quá tải.

⚠ Load balancer làm gì:

        Người dùng
            ↓
    Cloud Load Balancing
    ┌────┬────┬────┬────┐
   VM1  VM2  VM3  VM4
        ↓
    ⚠ Chia đều request
    ⚠ Kiểm tra sức khoẻ từng VM
    ⚠ NGỪNG gửi vào VM không khoẻ
    ⚠ Tự đưa VM mới vào pool

⚠ Phân biệt với autoscaling:

LOAD BALANCING
    → ⚠ CHIA lưu lượng giữa
      các máy ĐÃ CÓ
    → không thêm hay bớt máy
    → đề này

AUTOSCALING
    → ⚠ THÊM/BỚT máy theo tải
    → không chia lưu lượng
        ↓
    ⚠ Hai việc khác nhau,
      nhưng LUÔN đi cùng nhau

⚠ Vì sao phải có cả hai:

Chỉ có LOAD BALANCING
    → chia đều nhưng tổng năng lực
      không tăng
    → ⚠ vẫn quá tải

Chỉ có AUTOSCALING
    → có thêm máy nhưng lưu lượng
      vẫn dồn vào máy cũ
    → ⚠ vô dụng

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

FIREWALL RULES
    → ⚠ CHO PHÉP hoặc CHẶN
      lưu lượng theo IP và cổng
    → không phân phối

CLOUD DNS
    → ⚠ dịch tên miền thành IP
    → (DNS round-robin có chia được
      thô sơ nhưng ⚠ KHÔNG kiểm tra
      sức khoẻ, không phải giải pháp)

AUTOSCALING
    → thêm/bớt máy, không chia

⚠ Đối chiếu #13359 và #13339 (lô 140) — hai đề đó khoá autoscaling vì mô tả việc thêm và bớt máy theo CPU. Câu này khoá load balancing vì mô tả việc chia lưu lượng. Không mâu thuẫn — hai năng lực khác nhau trong cùng một kiến trúc.

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

• B (Autoscaling) — phương án gần nhất và luôn đi cùng load balancing, nhưng nó thêm/bớt instance, không phân phối request giữa các instance đã có.

• C (Cloud DNS) — dịch tên miền thành IP. DNS round-robin có thể chia thô sơ nhưng không kiểm tra sức khoẻ, nên không giải quyết được yêu cầu của đề.

• A (Firewall Rules) — cho phép hoặc chặn lưu lượng theo quy tắc mạng, không phân phối.

Ghi nhớ

⚠ Bốn khái niệm hay bị lẫn — bảng phải thuộc: | Khái niệm | Việc | |---|---| | ⚠ Load balancing | ⚠ CHIA lưu lượng giữa các backend | | Autoscaling | ⚠ THÊM/BỚT tài nguyên theo tải | | Firewall rules | cho phép/chặn theo IP và cổng | | Cloud DNS | dịch tên miền thành IP |

Từ khoá nhận diện:

"chia lưu lượng, không máy nào quá tải" → Load Balancing "thêm máy khi CPU cao" → Autoscaling "chặn cổng 22 từ Internet" → firewall rules "chống DDoS và SQL injection" → Cloud Armor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backend có khoẻ không | ⚠ trang chi tiết LB — trạng thái từng backend | | Lưu lượng có chia đều không | metric request theo backend | | Health check có đúng không | thử làm ứng dụng lỗi mà cổng vẫn mở |

Và một chi tiết quyết định chất lượng của cả hệ thống cân bằng tải: endpoint kiểm tra sức khoẻ phải thật sự phản ánh tình trạng ứng dụng. Một health check chỉ trả về "200 OK" mà không chạm tới cơ sở dữ liệu sẽ vui vẻ báo khoẻ trong khi mọi request thật đều đang lỗi.

Đáp án

C — Mô hình học quy luật từ dữ liệu được đưa vào; nếu dữ liệu có lỗi thì dự đoán của mô hình cũng sẽ sai.

Vì sao đúng

Đây là nguyên tắc nền tảng nhất của học máy — "rác vào, rác ra" — và trong bối cảnh y tế thì hậu quả đặc biệt nghiêm trọng.

⚠ Bốn lỗi trong đề gây hại thế nào:

MÃ CHẨN ĐOÁN SAI
    → ⚠ mô hình học sai mối liên hệ
      giữa bệnh và nguy cơ tái nhập viện

DẤU HIỆU SINH TỒN THIẾU
    → ⚠ thư viện tự điền trung bình
    → bịa ra bệnh nhân "trung bình"
      không tồn tại

TÊN THUỐC KHÔNG NHẤT QUÁN
    → "Paracetamol", "Acetaminophen",
      "paracetamol 500mg"
    → ⚠ mô hình coi là BA loại thuốc

THÔNG TIN NHÂN KHẨU CŨ
    → địa chỉ, bảo hiểm đã đổi
    → ⚠ tín hiệu sai lệch

⚠ Vì sao nguy hiểm hơn là "mô hình chạy chậm":

Mô hình vẫn HUẤN LUYỆN XONG
Vẫn cho ra một điểm chính xác
        ↓
    ⚠ KHÔNG có thông báo lỗi nào
        ↓
    Bệnh viện tin vào dự đoán
        ↓
    ⚠ Bỏ sót bệnh nhân nguy cơ cao
    ⚠ Dồn nguồn lực vào người
      không cần
        ↓
    → hậu quả về SỨC KHOẺ,
      không chỉ về tiền

⚠ Vì sao mô hình KHÔNG tự sửa được:

Thuật toán tối ưu một HÀM MẤT MÁT
        ↓
    Nó tìm quy luật KHỚP NHẤT
    với dữ liệu được đưa
        ↓
    ⚠ Nó KHÔNG có khái niệm
      "dữ liệu này sai"
        ↓
    → dữ liệu sai → quy luật sai
      → dự đoán sai

⚠ Gần trùng với #13250 (lô 138) — đề đó cũng về dự đoán khách rời bỏ với dữ liệu bẩn, và cùng khoá "dự đoán sẽ sai". Hoàn toàn nhất quán.

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

• B (dữ liệu kém có thể được thuật toán tự sửa) — phương án gần nhất về mặt "nghe như AI thông minh", nhưng đây là hiểu lầm phổ biến nhất về ML: mô hình học theo dữ liệu, không đánh giá đúng sai.

• A (chỉ số lượng dữ liệu mới quan trọng, không phải chất lượng) — sai; nhiều dữ liệu bẩn chỉ khiến mô hình tự tin hơn vào quy luật sai.

• D (dữ liệu chất lượng cao lưu rẻ hơn) — không liên quan tới chất lượng mô hình.

Ghi nhớ

⚠ Vòng đời dự án ML — bảng phải thuộc: | Bước | Nội dung | |---|---| | 1. Xác định bài toán nghiệp vụ | | | 2. Thu thập dữ liệu | | | 3. ⚠ CHUẨN BỊ VÀ LÀM SẠCH | ⚠ thường chiếm 60–80% thời gian | | 4. Huấn luyện | | | 5. Đánh giá | | | 6. Triển khai | | | 7. Giám sát | phát hiện drift |

Từ khoá nhận diện:

"dữ liệu bẩn, thiếu, không nhất quán" → dự đoán không đáng tin "mô hình tự sửa lỗi dữ liệu" → ⚠ luôn là phương án SAI "chỉ cần nhiều dữ liệu" → ⚠ cũng là phương án SAI "độ chính xác đẹp bất thường" → nghi ngờ rò rỉ nhãn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu sạch tới đâu | Dataplex data quality — chấm điểm | | Mô hình có thiên lệch không | ⚠ đánh giá theo TỪNG nhóm bệnh nhân | | Có tốt hơn quy tắc đơn giản không | so với một đường cơ sở |

Và một sự thật mà mọi đội dữ liệu đều học được sau vài dự án: thời gian bỏ ra làm sạch dữ liệu gần như luôn đem lại nhiều cải thiện hơn thời gian tinh chỉnh thuật toán. Với dữ liệu y tế, nó còn là điều kiện đạo đức — một mô hình học từ mã chẩn đoán sai sẽ đưa ra khuyến nghị ảnh hưởng tới người thật.

Đáp án

B — Cloud Run Functions.

Vì sao đúng

Đề nêu ba đặc điểm, và cả ba đều là mô tả của mô hình hàm theo sự kiện:

⚠ Ba đặc điểm ↔ Cloud Run Functions:

1. "MỘT ĐOẠN MÃ NHỎ, phản ứng khi
    có tệp tải lên Cloud Storage"
     → ⚠ kích hoạt THEO SỰ KIỆN

2. "ĐƠN GIẢN NHẤT, TIẾT KIỆM NHẤT"
     → ⚠ viết một hàm, trả theo
       thời gian chạy thật

3. "KHÔNG cần quản máy chủ"
     → serverless

⚠ Luồng xử lý:

Tệp tải lên bucket
        ↓
Cloud Storage phát sự kiện `finalized`
        ↓
    Eventarc định tuyến
        ↓
Cloud Run Function chạy
    → nhận metadata: bucket, tên tệp
    → xử lý
        ↓
    Hàm kết thúc, tài nguyên thu hồi
        ↓
    ⚠ Không có tệp → không tốn tiền

⚠ Cloud Run cũng làm được, nhưng:

CLOUD RUN
    → phải viết cả một DỊCH VỤ WEB
      trong container
    → tự dựng Dockerfile
    → tự xử lý HTTP
        ↓
    ⚠ Đề hỏi "ĐƠN GIẢN NHẤT"
        ↓
CLOUD RUN FUNCTIONS
    → chỉ viết một hàm
    → nền tảng lo phần còn lại
    → ⚠ gắn sẵn với nguồn sự kiện

⚠ Gần trùng với #13329 (lô 140) và #13315 (lô 139) — cả ba đề đều là hàm chạy khi có tệp mới trong Cloud Storage, và cả ba cùng khoá Cloud Run Functions. Hoàn toàn nhất quán. Mẫu đề lặp: mỗi khi có tệp mới + đoạn mã nhỏ + đơn giản/rẻ nhất → luôn là Cloud Run Functions.

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

• A (Cloud Run) — phương án gần nhất và hoàn toàn làm được (Cloud Run Functions thực chất chạy trên nền Cloud Run). Nhưng với một đoạn mã nhỏ, việc đóng gói container và máy chủ HTTP là thừa so với yêu cầu "đơn giản nhất".

• D (GKE) — cụm luôn chạy và luôn tính tiền; quá nặng cho một tác vụ ngắn.

• C (Compute Engine) — máy ảo chạy suốt chờ sự kiện; tốn tiền liên tục và phải tự viết cơ chế theo dõi.

Ghi nhớ

⚠ Chọn nền tảng cho tác vụ theo sự kiện — bảng phải thuộc: | Nhu cầu | Chọn | |---|---| | Hàm nhỏ, theo sự kiện | ⚠ Cloud Run Functions | | Dịch vụ web container | Cloud Run | | Tác vụ chạy tới khi xong | Cloud Run jobs | | Nhiều dịch vụ phụ thuộc nhau | GKE | | Cần kiểm soát OS | Compute Engine |

Từ khoá nhận diện:

"mỗi khi có tệp mới / bản ghi mới" → Cloud Run Functions "dịch vụ HTTP đóng gói container" → Cloud Run "định tuyến sự kiện" → Eventarc "theo lịch" → Cloud Scheduler

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có vòng lặp không | ⚠ số lần kích hoạt trong Cloud Monitoring | | Timeout có đủ không | thử với tệp lớn nhất | | Chi phí bao nhiêu | số lần gọi × thời gian × bộ nhớ |

Và một quy tắc nên áp cho mọi hàm kích hoạt bởi Cloud Storage: đầu ra phải nằm ở bucket khác đầu vào. Nó không tốn thêm gì, làm kiến trúc rõ ràng hơn, và loại bỏ hoàn toàn loại tai nạn vòng lặp vốn chỉ lộ ra khi hoá đơn cuối tháng về.

Đáp án

D — Hybrid Cloud (đám mây lai).

Vì sao đúng

Đề mô tả đúng định nghĩa: kết hợp hạ tầng tại chỗ với đám mây công cộng, mỗi bên đảm nhận phần phù hợp.

⚠ Bức tranh trong đề:

TRUNG TÂM DỮ LIỆU RIÊNG (tại chỗ)
    Dữ liệu khách hàng nhạy cảm
    ⚠ ở lại vì quy định nghiêm ngặt
              │
              │ dữ liệu KHÔNG nhạy cảm
              ▼
GOOGLE CLOUD (công cộng)
    Phân tích dữ liệu và học máy
        ↓
    ⚠ Hai môi trường, một chiến lược
    → ĐÁM MÂY LAI

⚠ Bốn mô hình — phân biệt cho rõ:

PUBLIC CLOUD
    → toàn bộ trên nhà cung cấp
      công cộng

PRIVATE CLOUD
    → ⚠ CHỈ hạ tầng riêng,
      không dùng công cộng

⚠ HYBRID CLOUD
    → ⚠ TẠI CHỖ + CÔNG CỘNG
    → đề này

MULTI-CLOUD
    → ⚠ NHIỀU nhà cung cấp
      công cộng

⚠ Vì sao mô hình này hợp lý ở đây:

Giữ dữ liệu nhạy cảm tại chỗ
    → ⚠ đáp ứng quy định
    → tận dụng hạ tầng đã đầu tư
        +
Dùng BigQuery và Vertex AI
cho dữ liệu không nhạy cảm
    → ⚠ có sức tính toán mà
      công ty không thể tự dựng
    → trả theo mức dùng
        ↓
    → vừa tuân thủ, vừa hiện đại

⚠ Gần trùng với #13265 (lô 138) — đề đó là bệnh viện giữ hồ sơ bệnh nhân tại chỗ và dùng BigQuery cho nghiên cứu, và cùng khoá Hybrid. Hoàn toàn nhất quán. Mẫu đề lặp: dữ liệu nhạy cảm ở lại + dùng dịch vụ đám mây cho phần còn lại → luôn là hybrid.

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

• A (Multi-cloud) — phương án gần nhất và hay bị nhầm nhất: multi-cloud đòi NHIỀU nhà cung cấp đám mây công cộng. Ở đây chỉ có một (Google) cộng với hạ tầng tại chỗ.

• B (Private cloud) — sẽ đúng nếu mọi thứ nằm trên hạ tầng riêng, nhưng họ có dùng Google Cloud.

• C (Public cloud) — sẽ đúng nếu mọi thứ trên đám mây công cộng, nhưng dữ liệu nhạy cảm ở lại tại chỗ.

Ghi nhớ

⚠ Bốn mô hình triển khai — bảng phải thuộc: | Mô hình | Nghĩa | |---|---| | Public cloud | toàn bộ trên nhà cung cấp công cộng | | Private cloud | ⚠ chỉ hạ tầng riêng | | ⚠ Hybrid cloud | ⚠ TẠI CHỖ + CÔNG CỘNG | | Multi-cloud | ⚠ NHIỀU nhà cung cấp công cộng | | ⚠ Kết hợp | có thể vừa hybrid vừa multi-cloud |

Từ khoá nhận diện:

"giữ một phần tại chỗ, dùng đám mây phần còn lại" → hybrid "Google Cloud và AWS" → multi-cloud "chỉ hạ tầng riêng" → private "tất cả trên một đám mây" → public

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao | |---|---| | Vì sao phần này phải ở lại tại chỗ | ⚠ quy định, độ trễ, hay chỉ là thói quen | | Dữ liệu đưa lên đã được phân loại chưa | | | Kết nối có đủ băng thông và an toàn không | Interconnect hay VPN |

Và một câu hỏi đáng đặt lại định kỳ cho mọi kiến trúc lai: ranh giới "nhạy cảm / không nhạy cảm" có còn đúng không? Nó thường được vẽ ra một lần lúc bắt đầu rồi không ai rà lại, trong khi cả quy định lẫn năng lực bảo vệ dữ liệu của nền tảng đám mây đều đã thay đổi kể từ đó.

Đáp án

A — Dữ liệu luồng được xử lý LIÊN TỤC ngay khi được sinh ra, còn dữ liệu lô được xử lý theo những KHỐI LỚN, RỜI RẠC.

Vì sao đúng

Khác biệt căn bản giữa hai mô hình nằm ở thời điểm xử lý, và mọi khác biệt khác đều bắt nguồn từ đó.

⚠ Hai mô hình:

XỬ LÝ THEO LÔ (batch)
    Gom dữ liệu cả ngày
        ↓
    2 giờ sáng: chạy một lần
        ↓
    ⚠ Độ trễ: hàng giờ
    ⚠ Dữ liệu HỮU HẠN, biết trước
      điểm bắt đầu và kết thúc

XỬ LÝ LUỒNG (streaming)
    Sự kiện đến
        ↓
    ⚠ Xử lý NGAY, từng cái một
      hoặc theo cửa sổ nhỏ
        ↓
    ⚠ Độ trễ: giây
    ⚠ Dữ liệu VÔ HẠN, không bao
      giờ "hết"

⚠ Vì sao nhà máy trong đề cần luồng:

Cảm biến báo nhiệt độ tăng bất thường
        ↓
    XỬ LÝ THEO LÔ
        ↓
    ⚠ 2 giờ sáng mai mới biết
    ⚠ Máy đã hỏng từ chiều hôm trước
        ↓
    XỬ LÝ LUỒNG
        ↓
    ⚠ Cảnh báo trong vài giây
    → dừng máy trước khi hỏng
        ↓
    → giá trị nằm ở TÍNH KỊP THỜI

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

Dữ liệu luồng là VÔ HẠN
        ↓
    ⚠ Không thể "tính trung bình
      tất cả" vì không bao giờ hết
        ↓
    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"

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

• D (luồng luôn có cấu trúc, lô thì phi cấu trúc) — phương án gần nhất về mặt "nghe như một khác biệt kỹ thuật", nhưng sai: cả hai đều xử lý được mọi loại dữ liệu.

• B (luồng lưu ở Cloud Storage, lô lưu ở BigQuery) — nhầm lẫn giữa cách xử lý và nơi lưu trữ; cả hai đều có thể ghi vào cả hai nơi.

• C (dữ liệu luồng ít giá trị hơn) — không có cơ sở; giá trị tuỳ bài toán.

Ghi nhớ

⚠ Lô và luồng — bảng phải thuộc: | | Batch | Streaming | |---|---|---| | Thời điểm xử lý | ⚠ theo lịch, khối lớn | ⚠ liên tục, ngay khi đến | | Độ trễ | giờ | giây | | Dữ liệu | hữu hạn | ⚠ vô hạn | | Chi phí | thường rẻ hơn | cao hơn | | Hợp với | báo cáo, ETL đêm | ⚠ cảnh báo, gian lận, IoT |

Từ khoá nhận diện:

"thời gian thực, cảnh báo ngay, IoT" → streaming "báo cáo hằng đêm, ETL theo lịch" → batch "nhận luồng sự kiện" → Pub/Sub "xử lý cả lô lẫn luồng" → ⚠ Dataflow (Apache Beam)

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Chậm một giờ có sao không | không → batch, rẻ hơn | | Có cần cảnh báo tức thì không | có → streaming | | Dữ liệu có đến muộn không | ⚠ phải xử lý watermark |

Và một câu hỏi nên đặt trước khi dựng pipeline luồng: ai sẽ HÀNH ĐỘNG với dữ liệu thời gian thực này? Xử lý luồng đắt hơn và phức tạp hơn xử lý lô, nên nó chỉ đáng nếu có người hoặc hệ thống thật sự phản ứng trong vài giây — còn nếu kết quả chỉ để xem vào sáng hôm sau thì một job chạy đêm là đủ.

Đáp án

D — Dùng AutoML.

Vì sao đúng

Đề đặt công ty này đúng vào giữa thang giải pháp AI: có dữ liệu riêng đã gán nhãn, có quy trình độc quyền, nhưng muốn rất ít lập trình.

⚠ Ba manh mối ↔ AutoML:

1. ⚠ "QUY TRÌNH ĐỘC QUYỀN,
    RIÊNG của công ty"
     → ⚠ không API sẵn nào biết
       mẫu gian lận của họ

2. ⚠ "TẬP DỮ LIỆU LỚN ĐÃ GÁN NHÃN
    của các yêu cầu bồi thường
    trong quá khứ"
     → ⚠ có đủ nguyên liệu để
       huấn luyện

3. ⚠ "TỐI THIỂU HOÁ VIỆC LẬP TRÌNH"
     → ⚠ loại mô hình tuỳ biến

⚠ AutoML làm gì cho họ:

Tải tập dữ liệu đã gán nhãn lên
        ↓
    AutoML tự:
      - chọn kiến trúc mô hình
      - tinh chỉnh siêu tham số
      - chia train / valid / test
      - xử lý mất cân bằng nhãn
        ↓
    ⚠ Đội vẫn kiểm soát:
      chất lượng nhãn, đặc trưng,
      đọc chỉ số, quyết định triển khai
        ↓
    → mô hình RIÊNG của họ,
      không cần viết mã mô hình

⚠ Vì sao API dựng sẵn không dùng được:

Natural Language API
    → phân tích cảm xúc, thực thể
    → ⚠ KHÔNG biết "yêu cầu bồi
      thường này có gian lận không"

Vision API
    → ⚠ xử lý ẢNH, sai loại dữ liệu

Mô hình có sẵn trên Marketplace
    → ⚠ huấn luyện trên dữ liệu
      của người khác
    → không nắm được mẫu riêng
      của công ty này

Nhất quán với #13273 (lô 139) và #13324 (lô 140) — các đề đó cũng khoá AutoML cho tình huống có dữ liệu riêng đã gán nhãn + không muốn viết mã mô hình. Hoàn toàn nhất quán.

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

• B (mô hình dựng sẵn trên Marketplace) — phương án gần nhất về mặt "cũng là mô hình dùng nhanh", nhưng nó được huấn luyện trên dữ liệu của người khác và không nắm được quy trình độc quyền mà đề nhấn mạnh.

• A (Natural Language API) — phân tích văn bản ở mức chung; không phát hiện gian lận theo mẫu riêng.

• C (Vision AI API) — xử lý ảnh, sai loại dữ liệu.

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Khi nào | |---|---| | API dựng sẵn | việc PHỔ QUÁT, không cần dữ liệu riêng | | ⚠ AutoML | ⚠ có dữ liệu riêng ĐÃ GÁN NHÃN + ít lập trình | | Mô hình tuỳ biến | cần kiểm soát kiến trúc, có đội ML |

Từ khoá nhận diện:

"dữ liệu riêng đã gán nhãn, ít lập trình" → AutoML "việc phổ quát: dịch, OCR, cảm xúc" → API dựng sẵn "cần toàn quyền kiến trúc" → Vertex AI custom training "biết SQL, dữ liệu ở BigQuery" → BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình có tốt hơn quy tắc hiện tại không | ⚠ so với quy trình thủ công đang dùng | | Có rò rỉ nhãn không | ⚠ độ chính xác quá đẹp là dấu hiệu | | Giải thích được quyết định không | Explainable AI |

Và một yêu cầu gần như bắt buộc với mô hình phát hiện gian lận trong ngành bảo hiểm: phải giải thích được vì sao một hồ sơ bị đánh dấu. Khách hàng bị từ chối có quyền hỏi lý do, và một câu trả lời kiểu "mô hình nói vậy" không đứng vững được trước cơ quan quản lý.

Đáp án

D — Intelligence (trí tuệ / khai thác dữ liệu và AI).

Vì sao đúng

Đề mô tả một nhà phân tích dùng học máy ngay trong kho dữ liệu bằng SQL — đó là biểu hiện điển hình của trụ cột Intelligence: biến dữ liệu thành hiểu biết và dự đoán.

⚠ Tình huống trong đề chính là BigQuery ML:

CREATE MODEL `ban_hang.du_bao`
OPTIONS(model_type='ARIMA_PLUS', ...) AS
SELECT ngay, doanh_thu FROM `ban_hang.lich_su`;

SELECT * FROM ML.FORECAST(
  MODEL `ban_hang.du_bao`,
  STRUCT(90 AS horizon));

        ↓
    ⚠ Nhà phân tích biết SQL
      tự làm được học máy
    ⚠ Dữ liệu KHÔNG phải di chuyển
    ⚠ Không cần đội ML riêng
        ↓
    → đúng tinh thần trụ cột
      INTELLIGENCE

⚠ Trụ cột Intelligence gồm những gì:

DỮ LIỆU
    → BigQuery, Dataplex, Looker
        +
HỌC MÁY
    → Vertex AI, BigQuery ML
        +
⚠ AI CHO MỌI NGƯỜI
    → không chỉ nhà khoa học
      dữ liệu mới dùng được
        ↓
    → ra quyết định dựa trên
      dữ liệu, ở mọi cấp

⚠ Ba trụ cột kia nói về chuyện khác:

FREEDOM
    → ⚠ mã nguồn mở, đa đám mây,
      tránh khoá chân

SUSTAINABILITY
    → carbon, năng lượng tái tạo

COLLABORATION
    → ⚠ Workspace, họp, làm việc nhóm

Nhất quán với #13284 (lô 139) — đề đó khoá BigQuery ML cho đúng tình huống này (nhà phân tích biết SQL, dữ liệu ở BigQuery). Câu này hỏi trụ cột chuyển đổi nào mà nó thể hiện. Hai câu ghép thành hiểu biết đầy đủ.

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

• C (Collaboration) — phương án gần nhất về mặt "cũng trao quyền cho người dùng", nhưng nó nói về cộng tác giữa con người: Workspace, Docs, Meet. Đề nói về khai thác dữ liệu.

• A (Freedom) — về mã nguồn mở và tránh khoá chân.

• B (Sustainability) — về môi trường và phát thải.

Ghi nhớ

⚠ Các trụ cột chuyển đổi của Google Cloud — bảng nên thuộc: | Trụ cột | Nội dung | Sản phẩm | |---|---|---| | ⚠ Intelligence | ⚠ dữ liệu và AI để ra quyết định | BigQuery, Looker, Vertex AI | | Freedom | mã nguồn mở, đa đám mây | Kubernetes, GKE Enterprise | | Collaboration | làm việc nhóm | Google Workspace | | Trusted transactions | bảo mật, riêng tư | IAM, Cloud Armor | | Sustainability | carbon | Carbon Footprint |

Từ khoá nhận diện:

"phân tích, ML, ra quyết định bằng dữ liệu" → Intelligence "chuẩn mở, chuyển đi được" → Freedom "họp, tài liệu chung" → Collaboration "carbon, năng lượng" → Sustainability

Ba câu hỏi kiểm chứng cho một tổ chức: | Câu hỏi | Vì sao | |---|---| | Nhà phân tích có tự chạy được ML không | ⚠ hay vẫn phải xếp hàng chờ đội dữ liệu | | Từ câu hỏi tới câu trả lời mất bao lâu | | | Ba đội hỏi cùng một câu có ra cùng số không | phép thử của mô hình chung |

Và một điều làm nên sức mạnh thật sự của cách tiếp cận này: kết quả dự đoán là một bảng BigQuery bình thường. Nó nối thẳng vào Looker, vào scheduled query, vào mọi thứ đội bạn đã dựng — không cần một đường ống riêng nào để đưa dự đoán từ thế giới ML trở về thế giới báo cáo.

Đáp án

B — Mất năng lực cạnh tranh và trở nên không còn phù hợp với thị trường vì thiếu tính linh hoạt.

Vì sao đúng

Đề đặt hai hình ảnh cạnh nhau: một công ty lâu năm chậm đổi mới và một đối thủ cloud-native ra tính năng gần như hằng tuần. Rủi ro lớn nhất là thua trong cuộc đua tốc độ.

⚠ Vòng xoáy đi xuống:

Đối thủ ra tính năng mới hằng tuần
        ↓
Mình ra mỗi quý một lần
        ↓
    ⚠ Khách thấy bên kia tốt hơn
        ↓
    ⚠ Mất khách dần
        ↓
    Doanh thu giảm → ngân sách giảm
        ↓
    ⚠ Càng chậm đổi mới hơn
        ↓
    → vòng xoáy tự củng cố

⚠ Vì sao đối thủ nhanh hơn:

CÔNG TY CŨ
    Có ý tưởng → xin ngân sách
    → đặt mua máy → chờ giao
    → lắp → cấu hình
        ↓
    ⚠ HÀNG TUẦN tới HÀNG THÁNG

ĐỐI THỦ CLOUD-NATIVE
    Có ý tưởng
        ↓
    ⚠ Dựng môi trường trong VÀI PHÚT
    ⚠ CI/CD tự động triển khai
    ⚠ Kiến trúc tách rời — sửa một
      phần không đụng phần khác
        ↓
    → ra mắt trong vài ngày

⚠ Vì sao ba phương án kia không phải rủi ro nghiêm trọng:

"Giảm nhu cầu an ninh vật lý
 tại trung tâm dữ liệu"
    → ⚠ đó là LỢI ÍCH nếu chuyển đi,
      và ở lại thì nhu cầu KHÔNG giảm

"Có QUÁ NHIỀU quyền kiểm soát
 hạ tầng"
    → ⚠ nghe như rủi ro nhưng
      không phải — và không phải
      thứ khiến họ mất khách

"Tăng NHẸ chi phí điện"
    → ⚠ nhỏ so với việc mất thị phần

⚠ Gần trùng với #13244 (lô 138) — đề đó cũng là công ty bán lẻ bám hạ tầng cũ trong khi đối thủ đã lên đám mây, và cùng khoá "mất thị phần vì chậm đổi mới". Hoàn toàn nhất quán.

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

• D (tăng nhẹ chi phí điện) — phương án gần nhất về mặt "cũng là một bất lợi có thật", nhưng nó nhỏ đến mức không đáng kể so với rủi ro mất thị phần.

• A (giảm nhu cầu an ninh vật lý) — mô tả lợi ích của việc CHUYỂN ĐI, còn ở lại thì nhu cầu đó không giảm.

• C (có quá nhiều quyền kiểm soát hạ tầng) — không phải rủi ro; và không giải thích được vì sao họ mất khách.

Ghi nhớ

⚠ Bốn bất lợi của việc không chuyển đổi — bảng nên thuộc: | Bất lợi | Nội dung | |---|---| | ⚠ Chậm đổi mới | ⚠ rủi ro lớn nhất — mất thị phần | | Không mở rộng kịp | sập vào ngày cao điểm | | Chi phí cố định cao | mua cho đỉnh, dùng ở mức thấp | | Khó tuyển người giỏi | kỹ sư muốn làm công nghệ hiện đại | | Bảo mật khó theo kịp | tự vá mọi thứ |

Từ khoá nhận diện:

"đối thủ nhanh hơn, mình chậm" → rủi ro mất năng lực cạnh tranh "phải mua máy cho ngày cao điểm" → thiếu co giãn "trả theo mức dùng" → lợi ích OpEx "mất kiểm soát hạ tầng" → ⚠ đánh đổi KHI LÊN đám mây

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 | ⚠ mỗi quý một lần là dấu hiệu xấu | | Từ ý tưởng tới khách hàng mất bao lâu | | | Có bao nhiêu bước duyệt thủ công | thường là nút thắt thật |

Và một điều đáng suy nghĩ về loại rủi ro này: nó không xuất hiện trong bất kỳ báo cáo tài chính nào. Chi phí điện và khấu hao máy chủ đều có dòng riêng trong sổ sách, còn cái giá của việc ra tính năng chậm hơn đối thủ ba tháng thì chỉ hiện ra sau vài năm, dưới dạng thị phần đã mất.

Đáp án

A — GKE Enterprise.

Vì sao đúng

Đề nêu hai yêu cầu, và cụm quyết định là "bất kể chúng đang chạy ở đâu":

⚠ Hai yêu cầu ↔ GKE Enterprise:

1. Cụm Kubernetes ở BA NƠI:
     - trung tâm dữ liệu tại chỗ
     - Google Cloud
     - một đám mây công cộng khác

2. ⚠ "MỘT NỀN TẢNG DUY NHẤT,
    NHẤT QUÁN để quản lý, bảo mật
    và giám sát TẤT CẢ"
     → ⚠ mặt phẳng điều khiển
       HỢP NHẤT

⚠ GKE Enterprise làm gì:

        GKE ENTERPRISE
     (mặt phẳng điều khiển
      hợp nhất trên Google Cloud)
              │
    ┌─────────┼─────────┐
Cụm tại chỗ  GKE      Cụm ở
             (GCP)    đám mây khác
        ↓
    ⚠ Fleet management — quản cả
      "đội cụm" như một
    ⚠ Config Sync — ⚠ áp CẤU HÌNH
      GIỐNG NHAU cho mọi cụm từ Git
    ⚠ Policy Controller — áp chính
      sách bảo mật đồng nhất
    ⚠ Cloud Service Mesh — quan sát
      và bảo mật giữa các dịch vụ
    ⚠ Giám sát tập trung

⚠ Vì sao GKE thường không đủ:

GKE (bản thường)
    → ⚠ Kubernetes có quản lý
      CHỈ TRÊN Google Cloud
    → không quản được cụm ở
      tại chỗ hay đám mây khác
        ↓
    ⚠ Đề nói rõ "bất kể chạy ở đâu"
        ↓
    → cần bản Enterprise

Phân biệt với #13326 và #13350 (lô 140) — hai đề đó khoá GKE vì chỉ nói về điều phối container trên Google Cloud. Câu này khoá GKE Enterprise vì có cụm ở nhiều môi trường. Không mâu thuẫn — khác nhau ở phạm vi.

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

• B (Google Kubernetes Engine) — phương án gần nhất và là bẫy chính: GKE thật sự quản lý Kubernetes rất tốt, nhưng chỉ trong Google Cloud. Đề đòi quản cả cụm tại chỗ và cụm ở đám mây khác.

• C (Cloud Run) — nền tảng chạy container serverless trên Google Cloud, không phải công cụ quản cụm Kubernetes ở nhiều nơi.

• D (Compute Engine) — máy ảo; không có khái niệm quản lý cụm.

Ghi nhớ

⚠ GKE và GKE Enterprise — bảng phải thuộc: | | GKE | GKE Enterprise | |---|---|---| | Phạm vi | ⚠ chỉ Google Cloud | ⚠ MỌI nơi: tại chỗ, GCP, đám mây khác | | Fleet management | không | ⚠ có | | Config Sync | không | ⚠ cấu hình đồng nhất từ Git | | Policy Controller | không | ⚠ chính sách bảo mật đồng nhất | | Service Mesh | tuỳ chọn | tích hợp | | Chi phí | theo cụm | ⚠ có phí bản quyền riêng |

Từ khoá nhận diện:

"nhiều cụm ở nhiều môi trường, quản tập trung" → GKE Enterprise "cụm Kubernetes trên Google Cloud" → GKE "một dịch vụ container serverless" → Cloud Run "hạ tầng Google chạy tại chỗ" → Google Distributed Cloud

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các cụm có cùng cấu hình không | ⚠ Config Sync — trạng thái đồng bộ | | Chính sách có được áp đủ không | Policy Controller — báo cáo vi phạm | | Chi phí bản quyền bao nhiêu | ⚠ tính theo vCPU — kiểm trước khi triển khai |

Và một điều nên cân nhắc trước khi chọn GKE Enterprise: nó giải quyết bài toán của quy mô, và tính phí theo quy mô đó. Với ba cụm thì công sức quản tay vẫn chấp nhận được; với ba mươi cụm trải ba môi trường thì một mặt phẳng điều khiển hợp nhất gần như là điều kiện để hệ thống còn quản được.