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

Đáp án

D — Linh hoạt và phân tán (Cloud Sprawl).

Vì sao đúng

Đề mô tả đúng hiện tượng cloud sprawl: nhiều đội tự tạo tài nguyên, không có ngân sách rõ ràng, không ai giám sát, dẫn tới chi tiêu khó đoán.

⚠ Vì sao sprawl xảy ra:

Đám mây cho ai cũng tạo được
tài nguyên trong vài phút
        ↓
    ⚠ Đó chính là ĐIỂM MẠNH
      (agility)
        ↓
    ⚠ Nhưng thiếu nhãn, thiếu
      ngân sách, thiếu rà soát
        ↓
    ⚠ Máy dựng để thử rồi quên tắt
    ⚠ Môi trường test không ai dùng
    ⚠ Đĩa mồ côi, IP tĩnh không gắn
    ⚠ Ảnh chụp cũ hàng năm
        ↓
    ⚠ Hoá đơn tăng mà KHÔNG AI
      giải thích nổi

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

"Predictable and centralized"
    → ⚠ NGƯỢC hẳn với mô tả

"CapEx"
    → ⚠ chi phí VỐN, mua trước —
      đám mây là OpEx

"TCO"
    → ⚠ tổng chi phí sở hữu, một
      công cụ SO SÁNH, không phải
      hiện tượng mất kiểm soát

Nhất quán với #13524 (cùng lô) — đề đó khoá FinOps. Sprawl là căn bệnh, FinOps là cách chữa. Hai đề bổ sung nhau.

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

• C (TCO) — phương án gần nhất về mặt "cũng là thuật ngữ chi phí đám mây", nhưng TCO là phép tính so sánh, không mô tả tình trạng chi tiêu mất kiểm soát.

• A (CapEx) — mô hình chi phí ngược lại.

• B (dự đoán được và tập trung) — mô tả trạng thái đối lập.

Ghi nhớ

⚠ Nguồn lãng phí phổ biến — bảng nên thuộc: | Nguồn | Dấu hiệu | |---|---| | ⚠ Máy chạy mà không ai dùng | ⚠ CPU gần 0 suốt nhiều tuần | | ⚠ Máy mua dư cỡ | ⚠ Recommender chỉ ra ngay | | Môi trường dev chạy 24/7 | ⚠ tắt ngoài giờ tiết kiệm rất nhiều | | Đĩa và ảnh chụp mồ côi | ⚠ VM xoá rồi, đĩa còn | | IP tĩnh không gắn máy | ⚠ vẫn tính tiền | | ⚠ Không thu hẹp sau cao điểm | ⚠ kiểm số instance ban đêm | | Log ồn | ⚠ tính theo khối lượng nạp |

Từ khoá nhận diện:

"chi tiêu phân tán, không ai giám sát" → ⚠ cloud sprawl "tài chính và kỹ thuật cùng quản chi phí" → FinOps "tổng chi phí sở hữu" → TCO "chi phí định kỳ hằng tháng" → OpEx

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Chi phí tháng này của đội nào | ⚠ trả lời không được → thiếu nhãn | | Có tài nguyên nào không ai nhận không | ⚠ thường có, và thường nhiều | | Ai xem hoá đơn hằng tháng | ⚠ không ai xem thì sprawl chắc chắn xảy ra |

Và bước đầu tiên để thoát khỏi tình trạng này không phải là cắt giảm gì cả, mà là làm cho chi phí trở nên nhìn thấy được đối với chính đội tạo ra nó. Rất nhiều khoản lãng phí tự biến mất ngay khi có người nhận ra rằng con số đó thuộc về mình.

Đáp án

C — Vertex AI.

Vì sao đúng

Đề nêu ba yêu cầu: đã có mô hình TensorFlow tuỳ biến, cần nền tảng có quản lý để lưu trữ mô hình, và phục vụ dự đoán qua endpoint API mà không quản máy chủ. Đó chính là Vertex AI Prediction.

⚠ Vòng đời mô hình trên Vertex AI:

Mô hình TensorFlow đã huấn luyện
        ↓
    ⚠ Đưa vào MODEL REGISTRY
        ↓
    ⚠ Triển khai lên ENDPOINT
        ↓
    ⚠ Có ngay API dự đoán
    ⚠ Tự co giãn theo lưu lượng
    ⚠ Không máy chủ nào để quản
        ↓
    ⚠ Model Monitoring theo dõi drift

⚠ Vertex AI gồm những gì:

⚠ TRAINING — huấn luyện có quản lý,
   dùng GPU/TPU
⚠ AUTOML — không cần viết mã
⚠ MODEL REGISTRY — quản phiên bản
⚠ PREDICTION — ⚠ endpoint trực tuyến
   và dự đoán theo LÔ
⚠ PIPELINES — tự động hoá MLOps
⚠ FEATURE STORE — quản đặc trưng
⚠ EXPLAINABLE AI, MODEL MONITORING

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

"BigQuery"
    → ⚠ kho phân tích; BigQuery ML
      dựng mô hình bằng SQL nhưng
      không phải nơi PHỤC VỤ mô hình
      TensorFlow tuỳ biến

"Cloud SQL"  → ⚠ CSDL quan hệ
"Cloud Storage"
    → ⚠ LƯU được tệp mô hình,
      nhưng ⚠ KHÔNG chạy dự đoán

Nhất quán với #13517 (cùng lô) — TensorFlow là framework mở, Vertex AI là nơi huấn luyện và phục vụ nó mà vẫn giữ mô hình ở định dạng mang đi được. Bổ sung nhau.

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

• D (Cloud Storage) — phương án gần nhất vì tệp mô hình thật sự nằm trong Cloud Storage, nhưng nó chỉ lưu; nó không tạo endpoint dự đoán.

• A (BigQuery) và B (Cloud SQL) — không phải nền tảng phục vụ mô hình.

Ghi nhớ

⚠ Ai làm gì trong vòng đời ML — bảng nên thuộc: | Việc | Dịch vụ | |---|---| | Chuẩn bị dữ liệu | ⚠ BigQuery, Dataflow | | Huấn luyện bằng SQL | BigQuery ML | | Huấn luyện không cần mã | AutoML (Vertex AI) | | Huấn luyện tuỳ biến | ⚠ Vertex AI Training | | ⚠ Phục vụ dự đoán | ⚠ Vertex AI Prediction — đề này | | Theo dõi sau triển khai | ⚠ Vertex Model Monitoring |

Từ khoá nhận diện:

"phục vụ mô hình qua endpoint, có quản lý" → ⚠ Vertex AI "dựng mô hình bằng SQL" → BigQuery ML "tác vụ phổ quát" → API dựng sẵn "mã nguồn mở, mang đi được" → TensorFlow

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần dự đoán tức thì không | ⚠ không → dùng batch, rẻ hơn nhiều | | Endpoint nào đang sống mà không ai gọi | ⚠ kiểm ngay, thường có | | Mô hình còn chính xác không | ⚠ bật Model Monitoring |

Và khoản chi phí gây ngạc nhiên nhiều nhất với các đội mới dùng Vertex AI: một endpoint để lại từ đợt thử nghiệm vẫn tính tiền đều đặn, kể cả khi không ai gọi tới nó lần nào. Rà danh sách endpoint đang sống là việc đáng làm ngay ở lần xem hoá đơn tiếp theo.

Đáp án

B — Nó có thể làm TĂNG độ phức tạp vận hành, vì các đội phải quản lý tài nguyên và bảo mật trên nhiều nền tảng khác nhau.

Vì sao đúng

Multi-cloud mang lại lợi ích thật, nhưng cái giá lớn nhất là mọi thứ phải làm nhiều lần, theo nhiều cách khác nhau.

⚠ Phức tạp nhân lên ở đâu:

Mỗi nền tảng có:
    ⚠ mô hình IAM riêng
    ⚠ mô hình mạng riêng
    ⚠ công cụ giám sát riêng
    ⚠ cách tính tiền riêng
    ⚠ thuật ngữ riêng
        ↓
    ⚠ Đội phải GIỎI cả hai
    ⚠ Quy trình phải viết hai lần
    ⚠ Sự cố phải điều tra ở hai nơi
        ↓
    ⚠ Chi phí lớn nhất là CON NGƯỜI

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

"GIẢM số dịch vụ dùng được"
    → ⚠ NGƯỢC: multi-cloud MỞ RỘNG
      lựa chọn — đó là lý do người ta
      chọn nó

"LUÔN LUÔN rẻ hơn dùng một
 nhà cung cấp"
    → ⚠ SAI: ⚠ mất chiết khấu theo
      cam kết, ⚠ thêm phí truyền
      dữ liệu giữa các đám mây

"Làm ứng dụng KÉM chịu lỗi hơn"
    → ⚠ NGƯỢC: làm đúng thì TĂNG
      khả năng chịu lỗi

⚠ Gần trùng với #13539 (cùng lô) — đề đó hỏi thách thức về BẢO MẬT của multi-cloud, đề này hỏi thách thức nói chung. Hai khoá bổ sung nhau, không mâu thuẫn. Định nghĩa multi-cloud ở #13529 (cùng lô).

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

• C (luôn rẻ hơn) — phương án gần nhất vì tiết kiệm chi phí là một kỳ vọng phổ biến, nhưng chữ "luôn luôn" khiến nó sai; multi-cloud thường tốn hơn.

• A (giảm số dịch vụ) và D (kém chịu lỗi hơn) — trái với mục đích của chiến lược này.

Ghi nhớ

⚠ Lợi ích và cái giá của multi-cloud — bảng nên thuộc: | Lợi ích | Cái giá | |---|---| | Chọn dịch vụ tốt nhất từng bên | ⚠ đội phải giỏi nhiều nền tảng | | Giảm phụ thuộc nhà cung cấp | ⚠ phí truyền dữ liệu giữa các đám mây | | Chịu lỗi ở mức nhà cung cấp | ⚠ mất chiết khấu theo cam kết | | Đáp ứng chủ quyền dữ liệu | ⚠ bảo mật và IAM quản hai lần | | Lợi thế đàm phán | ⚠ giám sát rời rạc |

Từ khoá nhận diện:

"thách thức của multi-cloud" → ⚠ phức tạp vận hành "nhiều đám mây công cộng" → multi-cloud "tại chỗ + đám mây" → hybrid "một mặt phẳng quản lý cho nhiều nơi" → ⚠ Anthos / GKE Enterprise

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đội có kỹ năng cho cả hai không | ⚠ đây là chi phí lớn nhất | | Dữ liệu đi qua lại bao nhiêu | ⚠ ước tính phí egress | | Có dùng được công nghệ chung không | ⚠ K8s và Terraform giảm đau nhiều |

Và điều đáng nói rõ với ban lãnh đạo trước khi chọn multi-cloud: nó hiếm khi tiết kiệm tiền. Nó mua sự linh hoạt và giảm rủi ro phụ thuộc — và như mọi thứ khác, sự linh hoạt đó có giá, phần lớn trả bằng thời gian của đội vận hành.

Đáp án

D — Authorization (phân quyền).

Vì sao đúng

Sau khi hệ thống đã biết bạn là ai, bước tiếp theo là quyết định bạn được làm gì — đó là authorization.

⚠ Thứ tự hai bước:

1. ⚠ AUTHENTICATION
   → "bạn là ai?"
   → mật khẩu, MFA, chứng chỉ
        ↓
2. ⚠ AUTHORIZATION
   → ⚠ "bạn được làm gì?"
   → ⚠ vai IAM, quyền
   → ⚠ ĐỀ NÀY
        ↓
3. AUDITING
   → "bạn đã làm gì?"

⚠ Authorization trên Google Cloud hoạt động ra sao:

⚠ CHÍNH SÁCH IAM gắn vào TÀI NGUYÊN
        ↓
    ⚠ ai (principal)
    ⚠ được vai gì (role)
    ⚠ trên tài nguyên nào
        ↓
    ⚠ Vai = một TẬP HỢP QUYỀN
      ví dụ `compute.instances.start`
        ↓
    ⚠ Chính sách KẾ THỪA xuống dưới:
      tổ chức → thư mục → dự án
      → tài nguyên

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

"Authentication"
    → ⚠ bước TRƯỚC: xác minh danh tính

"Auditing"
    → ⚠ GHI LẠI sau khi việc đã xảy ra

"Logging"
    → ⚠ ghi nhật ký, không quyết định
      ai được làm gì

⚠ Cặp đôi với #13533 (cùng lô) — đề đó hỏi Authentication. Hai đề mô tả hai bước liên tiếp, bổ sung nhau, hoàn toàn nhất quán.

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

• A (Authentication) — phương án gần nhất và là bẫy chính, nhưng đó là bước xác minh danh tính diễn ra trước.

• C (Auditing) và B (Logging) — ghi nhận lại hành vi, không cấp quyền.

Ghi nhớ

⚠ Ba trụ "A" của kiểm soát truy cập: | Trụ | Câu hỏi | Trên Google Cloud | |---|---|---| | Authentication | ⚠ "bạn là ai?" | ⚠ Cloud Identity, MFA | | ⚠ Authorization | ⚠ "được làm gì?" | ⚠ IAM | | Auditing | ⚠ "đã làm gì?" | ⚠ Cloud Audit Logs |

Từ khoá nhận diện:

"cấp quyền, kiểm quyền, vai" → ⚠ authorization / IAM "đăng nhập, chứng minh danh tính" → authentication "ai đã làm gì lúc nào" → audit log "chặn tường minh dù có vai" → ⚠ IAM Deny policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang có vai Owner | ⚠ kiểm ngay — danh sách thường dài hơn dự kiến | | Quyền nào cấp mà không dùng | ⚠ IAM Recommender | | Service account có quyền quá rộng không | ⚠ rà từng cái |

Và nguyên tắc đáng nhớ nhất về phân quyền: quyền hạn chỉ có xu hướng tăng lên nếu không có ai chủ động rà lại. Mỗi lần cấp thêm để giải quyết một việc gấp đều hợp lý tại thời điểm đó — và chính chuỗi những lần hợp lý ấy tạo ra một tổ chức mà ai cũng là Owner.

Đáp án

B — Container.

Vì sao đúng

Container đóng gói ứng dụng cùng toàn bộ phụ thuộc thành một đơn vị mang đi được, chạy giống hệt nhau trên máy lập trình viên, môi trường kiểm thử và môi trường sản xuất.

⚠ Vấn đề mà container giải quyết:

"Trên máy tôi chạy được mà"
        ↓
    ⚠ máy dev có Python 3.11
    ⚠ máy test có Python 3.9
    ⚠ máy prod thiếu một thư viện
        ↓
    ⚠ Lỗi chỉ xuất hiện ở một nơi
        ↓
    → ⚠ CONTAINER: đóng gói CẢ
      môi trường chạy vào cùng
        ↓
    ⚠ image giống nhau ở mọi nơi

⚠ Container khác máy ảo thế nào:

MÁY ẢO
    → ⚠ ảo hoá PHẦN CỨNG
    → ⚠ mỗi VM một HỆ ĐIỀU HÀNH đầy đủ
    → nặng GB, khởi động hàng phút

⚠ CONTAINER
    → ⚠ ảo hoá HỆ ĐIỀU HÀNH
    → ⚠ DÙNG CHUNG nhân của máy chủ
    → ⚠ nhẹ MB, khởi động trong GIÂY

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

"Máy chủ vật lý"
    → ⚠ là phần cứng, không đóng gói gì

"VPN"
    → ⚠ kết nối mạng an toàn

"Cloud SQL"
    → ⚠ dịch vụ CSDL

Nhất quán với #13507 (lô 143) về ba trụ cột cloud-native, và #13513 (lô 143) — container là đơn vị mà Kubernetes điều phối.

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

• A (máy chủ vật lý) — phương án gần nhất về mặt "cũng là nơi ứng dụng chạy", nhưng nó không đóng gói và không mang đi được.

• C (VPN) và D (Cloud SQL) — thuộc lĩnh vực hoàn toàn khác.

Ghi nhớ

⚠ Container và máy ảo — bảng phải thuộc: | | Máy ảo | ⚠ Container | |---|---|---| | Ảo hoá | phần cứng | ⚠ hệ điều hành | | Hệ điều hành | ⚠ đầy đủ cho mỗi VM | ⚠ DÙNG CHUNG nhân | | Kích thước | GB | ⚠ MB | | Khởi động | phút | ⚠ giây | | Cách ly | ⚠ mạnh hơn | ⚠ nhẹ hơn | | Trên Google Cloud | Compute Engine | ⚠ GKE, Cloud Run |

Từ khoá nhận diện:

"đóng gói cùng phụ thuộc, chạy nhất quán" → ⚠ container "điều phối container quy mô lớn" → Kubernetes / GKE "chạy container serverless" → Cloud Run "lưu image container" → ⚠ Artifact Registry

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Image có bí mật lẫn trong không | ⚠ kiểm lịch sử lớp image | | Image nặng bao nhiêu | ⚠ quá nặng thì cold start chậm | | Có lỗ hổng đã biết không | ⚠ bật quét trong Artifact Registry |

Và điều container thật sự loại bỏ không phải là công việc vận hành, mà là một loại tranh cãi: câu "trên máy tôi chạy được" không còn là một lập luận nữa, vì thứ chạy trên máy lập trình viên và thứ chạy ở sản xuất giờ đã là cùng một image.

Đáp án

B — Đội bảo mật phải học cách quản lý danh tính, quyền hạn và chính sách mạng một cách NHẤT QUÁN trên hai môi trường khác nhau.

Vì sao đúng

Mỗi nhà cung cấp có mô hình bảo mật riêng. Multi-cloud không nhân đôi công việc — nó nhân đôi cả công việc lẫn khả năng sai lệch giữa hai bên.

⚠ Ba nơi phải giữ nhất quán:

⚠ DANH TÍNH
    → hai hệ tài khoản riêng
    → ⚠ ai còn quyền ở bên kia
      sau khi nghỉ việc?

⚠ QUYỀN HẠN
    → ⚠ mô hình vai KHÁC NHAU
    → "quyền tương đương" không
      phải lúc nào cũng tồn tại

⚠ CHÍNH SÁCH MẠNG
    → tường lửa, phân vùng, mã hoá
      trên đường truyền
    → ⚠ cấu hình theo cách khác nhau

⚠ Rủi ro thật:

⚠ Cấu hình lệch giữa hai bên
        ↓
    ⚠ Một bên siết, một bên hở
        ↓
    ⚠ Kẻ tấn công tìm ĐIỂM YẾU NHẤT
        ↓
    ⚠ Bảo mật tổng thể = mức của
      môi trường YẾU NHẤT

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

"Bảo mật ĐƠN GIẢN HƠN vì chỉ có
 một nhà cung cấp để quản"
    → ⚠ tự mâu thuẫn: multi-cloud
      có NHIỀU nhà cung cấp

"KHÔNG cần lo bảo mật nữa vì
 nhà cung cấp lo hết"
    → ⚠ SAI MÔ HÌNH TRÁCH NHIỆM
      CHUNG: cấu hình, dữ liệu và
      quyền LUÔN thuộc về khách hàng

"TẮT hết tường lửa để hai đám mây
 giao tiếp được"
    → ⚠ nguy hiểm, và không cần thiết

⚠ Gần trùng với #13536 (cùng lô) — đề đó hỏi thách thức vận hành nói chung, đề này hỏi riêng bảo mật. Hai khoá bổ sung nhau, hoàn toàn nhất quán. Định nghĩa multi-cloud ở #13529 (cùng lô).

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

• C (nhà cung cấp lo hết bảo mật) — phương án gần nhất về mặt nghe hợp lý với người mới, nhưng nó vi phạm mô hình trách nhiệm chung: nhà cung cấp lo hạ tầng, khách hàng luôn chịu trách nhiệm về cấu hình, danh tính và dữ liệu.

• A (đơn giản hơn) — tự mâu thuẫn với chính khái niệm multi-cloud.

• D (tắt tường lửa) — sai về mọi mặt.

Ghi nhớ

⚠ Mô hình trách nhiệm chung — bảng phải thuộc: | Nhà cung cấp lo | ⚠ KHÁCH HÀNG lo | |---|---| | Phần cứng, trung tâm dữ liệu | ⚠ cấu hình dịch vụ | | Mạng vật lý, ảo hoá | ⚠ DANH TÍNH và QUYỀN (IAM) | | Vá lỗi hạ tầng nền | ⚠ DỮ LIỆU của mình | | Bảo mật vật lý | ⚠ quy tắc tường lửa | | Ghi nhớ | ⚠ càng dùng dịch vụ có quản lý, phần của khách càng nhỏ — nhưng KHÔNG BAO GIỜ về 0 |

Từ khoá nhận diện:

"bảo mật nhất quán trên nhiều nền tảng" → ⚠ thách thức multi-cloud "nhà cung cấp lo phần nào" → ⚠ shared responsibility "một danh tính cho mọi nơi" → ⚠ SSO / federation "không tin ai mặc định" → ⚠ zero trust / BeyondCorp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người nghỉ việc có bị gỡ ở cả hai không | ⚠ kiểm bên ít dùng trước | | Log của hai bên có gom chung không | ⚠ thiếu thì điều tra rất chậm | | Chính sách hai bên có tương đương không | ⚠ rà từng nhóm quyền, đừng giả định |

Và nguyên tắc chi phối mọi kiến trúc nhiều môi trường: mức bảo mật thực tế bằng mức của môi trường yếu nhất, chứ không phải trung bình của cả hai. Vì vậy môi trường ít được dùng nhất — nơi không ai để mắt tới — thường lại là nơi cần rà soát trước.

Đáp án

D — TensorFlow kết hợp với Cloud TPU.

Vì sao đúng

Đề nói rõ: mô hình nhận diện ảnh rất lớn và phức tạp, cần phần cứng chuyên dụng tối ưu cho phép tính MA TRẬN lớn. Đó chính xác là mô tả của TPU.

⚠ TPU là gì:

⚠ Tensor Processing Unit
    → ⚠ chip do GOOGLE thiết kế
      riêng cho học máy
    → ⚠ tối ưu cho phép nhân ma trận
      quy mô lớn
    → ⚠ đúng phép tính chiếm phần
      lớn thời gian huấn luyện
      mạng nơ-ron
        ↓
    ⚠ Rút thời gian huấn luyện từ
      TUẦN xuống GIỜ với mô hình lớn

⚠ Ba loại bộ xử lý — bảng cốt lõi:

⚠ CPU
    → đa năng, ít luồng song song
    → ⚠ hợp với mô hình nhỏ,
      logic phức tạp

⚠ GPU
    → ⚠ hàng nghìn lõi song song
    → ⚠ linh hoạt, hợp hầu hết
      khối lượng ML

⚠ TPU
    → ⚠ CHUYÊN cho phép tính ma trận
    → ⚠ hiệu quả nhất với mô hình
      RẤT LỚN, tối ưu cho TensorFlow

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

"Cloud SQL với CPU thường"
    → ⚠ CSDL quan hệ, không huấn
      luyện mô hình

"Cloud Spanner triển khai toàn cầu"
    → ⚠ CSDL phân tán

"Looker với CSDL trong bộ nhớ"
    → ⚠ công cụ BI

Nhất quán với #13517 (cùng lô) về TensorFlow mã nguồn mở, và #13535 (cùng lô) về Vertex AI phục vụ mô hình. Ba đề vẽ đủ vòng đời: framework → phần cứng huấn luyện → nơi phục vụ.

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

• A (Cloud SQL với CPU thường) — phương án gần nhất về mặt "có nhắc tới bộ xử lý", nhưng Cloud SQL là dịch vụ cơ sở dữ liệu, không phải nền tảng huấn luyện.

• B (Cloud Spanner) và C (Looker) — không liên quan tới huấn luyện mô hình.

Ghi nhớ

⚠ CPU, GPU, TPU — bảng phải thuộc: | Bộ xử lý | Mạnh ở | Dùng khi | |---|---|---| | CPU | ⚠ đa năng, tuần tự | ⚠ mô hình nhỏ, tiền xử lý | | ⚠ GPU | ⚠ song song, linh hoạt | ⚠ hầu hết bài toán ML | | ⚠ TPU | ⚠ phép nhân ma trận lớn | ⚠ mô hình RẤT lớn, TensorFlow |

Từ khoá nhận diện:

"mô hình rất lớn, phép tính ma trận" → ⚠ TPU "tăng tốc huấn luyện nói chung" → GPU "phần cứng do Google thiết kế cho ML" → ⚠ TPU "nền tảng có quản lý cho ML" → Vertex AI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ tăng tốc có được dùng hết không | ⚠ mức sử dụng thấp → nghẽn ở dữ liệu | | Có lưu checkpoint chưa | ⚠ bắt buộc với Spot | | Chi phí một lần huấn luyện | ⚠ tính trước, đừng để bất ngờ |

Và sai lầm tốn kém nhất khi thuê phần cứng tăng tốc: để nó ngồi chờ dữ liệu. Một cụm TPU chạy ở mức sử dụng ba mươi phần trăm vẫn tính tiền đủ một trăm — nên trước khi nâng cấp phần cứng, việc đáng làm là đo xem phần cứng hiện tại có thật sự đang bận hay không.

Đáp án

D — Speech-to-Text API.

Vì sao đúng

Từ khoá quyết định là "bước ĐẦU TIÊN" và "đầu vào âm thanh THÔ". Máy tính không hiểu được sóng âm — phải chuyển thành văn bản trước đã.

⚠ Chuỗi xử lý lệnh nói:

🎤 Âm thanh thô
        ↓
    ⚠ SPEECH-TO-TEXT
    ⚠ BƯỚC ĐẦU TIÊN — đề này
        ↓
    "bật đèn phòng khách"
        ↓
    ⚠ NATURAL LANGUAGE / NLU
    → hiểu ý định và thực thể
        ↓
    ý định: BẬT_THIẾT_BỊ
    thiết bị: đèn
    vị trí: phòng khách
        ↓
    Thực thi hành động
        ↓
    ⚠ TEXT-TO-SPEECH (nếu cần
      trả lời bằng giọng nói)

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

"Natural Language API"
    → ⚠ đúng ở BƯỚC SAU, nhưng
      nó nhận VĂN BẢN, không nhận
      âm thanh

"Vision AI API"     → ⚠ xử lý ẢNH
"Translation API"   → ⚠ DỊCH văn bản

Nhất quán với #13470 (lô 143) — cùng khoá Speech-to-Text cho đầu vào âm thanh. Đối chiếu #13504 (lô 143) khoá Vision API cho ảnh, và #13498 (lô 143) cho địa danh. Cùng nguyên tắc: chọn API theo LOẠI DỮ LIỆU ĐẦU VÀO.

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

• A (Natural Language API) — phương án gần nhất và là bẫy chính: nó thật sự cần thiết để hiểu câu lệnh, nhưng chỉ ở bước sau; nó không đọc được âm thanh.

• B (Vision) và C (Translation) — sai loại dữ liệu đầu vào.

Ghi nhớ

⚠ Chọn API theo LOẠI ĐẦU VÀO — bảng phải thuộc: | Đầu vào | API | |---|---| | ⚠ Âm thanh → chữ | ⚠ Speech-to-Text | | Chữ → âm thanh | Text-to-Speech | | Ảnh | Vision API | | Video | Video Intelligence | | Chữ → hiểu nghĩa | ⚠ Natural Language | | Chữ → ngôn ngữ khác | Translation | | Tài liệu, biểu mẫu | ⚠ Document AI |

Từ khoá nhận diện:

"âm thanh thô, bước đầu tiên" → ⚠ Speech-to-Text "hiểu ý định trong câu" → Natural Language / NLU "trợ lý ảo hoàn chỉnh" → ⚠ Dialogflow / CCAI "đọc thành giọng nói" → Text-to-Speech

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ chính xác trên giọng thật ra sao | ⚠ thử với bản ghi thật, có tiếng ồn | | Thuật ngữ riêng có nhận đúng không | ⚠ thêm vào từ vựng tuỳ biến | | Chi phí | ⚠ tính theo phút âm thanh |

Và điều quyết định chất lượng một hệ thống lệnh giọng nói thường không nằm ở mô hình: chất lượng micro và mức tiếng ồn nền ảnh hưởng tới kết quả nhiều hơn bất kỳ tinh chỉnh nào ở tầng phần mềm. Thử nghiệm nên làm bằng bản ghi trong môi trường thật, không phải bản ghi trong phòng yên tĩnh.

Đáp án

B — Redundancy (dự phòng / nhân bản).

Vì sao đúng

Redundancy là việc triển khai thành phần nhân bản để hệ thống vẫn hoạt động khi một thành phần hỏng — đúng điều Cloud SQL làm với instance dự phòng ở zone khác.

⚠ Cloud SQL HA hoạt động ra sao:

Instance chính ở zone A
    ⚠ Instance dự phòng ở zone B
        ↓
    ⚠ Ghi được đồng bộ sang
      dự phòng
        ↓
    ⚠ Zone A hỏng
        ↓
    ⚠ TỰ ĐỘNG chuyển sang zone B
    ⚠ Tên kết nối KHÔNG đổi
        ↓
    → ứng dụng chỉ thấy một
      khoảng gián đoạn ngắn

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

"Latency"       → ⚠ độ trễ
"Authorization" → ⚠ phân quyền
"Saturation"    → ⚠ mức bão hoà tài nguyên

⚠ Cả ba đều là thuật ngữ có thật nhưng không mô tả việc nhân bản thành phần.

Nhất quán với #13468 (lô 143) và #13425 (lô 142) — cùng khoá đa zone cho sự cố một zone. Đối chiếu #13493 (lô 143) khoá đa vùng cho sự cố cả region. Không mâu thuẫn — khác phạm vi sự cố.

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

• D (Saturation) — phương án gần nhất về mặt "cũng là thuật ngữ về độ tin cậy hệ thống", nhưng nó đo mức đầy của tài nguyên, không phải việc nhân bản.

• A (Latency) và C (Authorization) — thuộc lĩnh vực khác hẳn.

Ghi nhớ

⚠ Thuật ngữ độ tin cậy — bảng phải thuộc: | Thuật ngữ | Nghĩa | |---|---| | ⚠ Redundancy | ⚠ nhân bản thành phần — đề này | | ⚠ High Availability | ⚠ KẾT QUẢ: dịch vụ vẫn chạy khi có lỗi | | Failover | ⚠ hành động chuyển sang bản dự phòng | | ⚠ Disaster Recovery | ⚠ phục hồi sau thảm hoạ diện rộng | | Fault tolerance | ⚠ chịu lỗi mà không gián đoạn |

Từ khoá nhận diện:

"nhân bản thành phần" → ⚠ redundancy "chịu được mất một zone" → triển khai đa zone / HA "chịu được mất cả vùng" → ⚠ đa vùng / DR "RPO, RTO" → kế hoạch phục hồi thảm hoạ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Failover có thật sự hoạt động không | ⚠ Cloud SQL cho kích hoạt THỬ — hãy làm | | Ứng dụng có kết nối lại được không | ⚠ thử ngắt kết nối xem có tự phục hồi | | Đã có sao lưu chưa | ⚠ HA không thay thế backup |

Và điều dễ nhầm nhất về tính sẵn sàng cao: nó bảo vệ khỏi phần cứng hỏng, chứ không bảo vệ khỏi con người. Một câu lệnh xoá nhầm sẽ được sao chép sang bản dự phòng trong tích tắc — thứ cứu được tình huống đó là sao lưu và khả năng khôi phục về thời điểm, không phải standby.

Đáp án

C — Google Kubernetes Engine (GKE).

Vì sao đúng

Đề đòi hai vế cùng lúc: control plane Kubernetes phức tạp do Google quản lý hoàn toàn, nhưng vẫn tuỳ biến được worker node. Chỉ GKE cho cả hai.

⚠ Ranh giới trách nhiệm trong GKE Standard:

⚠ GOOGLE QUẢN — control plane
    → API server, etcd, scheduler,
      controller manager
    → ⚠ vá lỗi, nâng cấp, sao lưu,
      sẵn sàng cao
    → ⚠ bạn KHÔNG thấy máy nào

⚠ BẠN TUỲ BIẾN — worker node
    → loại máy, số lượng, GPU
    → ⚠ Spot VM, ổ đĩa, image
    → taint, label, autoscaling
      từng pool

⚠ Vì sao đây là điểm cân bằng:

Tự dựng Kubernetes trên VM
    → ⚠ phải tự vận hành etcd,
      tự nâng cấp control plane
    → ⚠ rất tốn công và dễ hỏng

⚠ GKE
    → ⚠ bỏ được phần khó nhất
    → ⚠ giữ được phần cần linh hoạt

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

"Cloud Run"
    → ⚠ không có node để tuỳ biến

"App Engine"
    → ⚠ PaaS, trừu tượng hoá cao hơn

"Compute Engine"
    → ⚠ máy ảo trần: bạn phải TỰ
      cài và TỰ vận hành Kubernetes

⚠ Gần trùng với #13528 (cùng lô) — đề đó diễn đạt gần như y hệt và cùng khoá GKE, chỉ khác chữ cái phương án (B ở #13528, C ở đây — bộ đề xáo thứ tự). Hoàn toàn nhất quán. Cùng nhóm với #13515 (lô 143).

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

• D (Compute Engine) — phương án gần nhất về mặt "cho tuỳ biến node tối đa", nhưng khi đó không có control plane nào được quản lý; bạn phải tự dựng tất cả.

• B (Cloud Run) và A (App Engine) — giấu hoàn toàn tầng node.

Ghi nhớ

⚠ Ba cách chạy Kubernetes — bảng phải thuộc: | Cách | Control plane | Node | |---|---|---| | Tự dựng trên VM | ⚠ BẠN quản — rất tốn công | bạn quản | | ⚠ GKE Standard | ⚠ GOOGLE quản | ⚠ BẠN tuỳ biến — đề này | | GKE Autopilot | ⚠ Google quản | ⚠ Google quản |

Từ khoá nhận diện:

"control plane có quản lý + tuỳ biến node" → ⚠ GKE Standard "không muốn quản node nào cả" → GKE Autopilot "chỉ có container, không cần cụm" → Cloud Run "toàn quyền trên OS" → Compute Engine

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có cấu hình node nào thật sự cần không | không → Autopilot | | Node có bị bỏ trống nhiều không | ⚠ Standard phải tự tối ưu | | Ai nâng cấp cụm | ⚠ bật release channel để tự động |

Và điểm mà GKE thật sự giải phóng cho đội vận hành nằm ở phần ít được nhắc tới nhất: etcd và việc nâng cấp control plane. Đó là phần khó nhất và rủi ro nhất khi tự vận hành Kubernetes, và cũng chính là phần bạn không bao giờ phải nhìn thấy khi dùng GKE.