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

Đáp án

B — Vision AI API.

Vì sao đúng

Face detection của Cloud Vision API trả về vị trí khuôn mặt kèm mức độ khả năng của các biểu cảm — vui, buồn, giận, ngạc nhiên — ngay khi gọi, không cần huấn luyện gì.

⚠ Face detection trả về gì:

Với MỖI khuôn mặt trong ảnh:
    → khung bao và các điểm mốc
      (mắt, mũi, miệng)
    → góc nghiêng đầu
    → ⚠ joyLikelihood
    → ⚠ sorrowLikelihood
    → ⚠ angerLikelihood
    → ⚠ surpriseLikelihood
    → headwear, blurred, underExposed
        ↓
    ⚠ Mỗi mục là một MỨC KHẢ NĂNG:
      VERY_UNLIKELY … VERY_LIKELY

⚠ Ranh giới cực kỳ quan trọng:

⚠ PHÁT HIỆN khuôn mặt
    → "có một khuôn mặt ở đây"
    → ⚠ Vision API LÀM

⚠ NHẬN DẠNG danh tính
    → "đây là ông A"
    → ⚠ Vision API KHÔNG LÀM
    → ⚠ Google KHÔNG cung cấp API
      nhận dạng danh tính đại trà

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

"Cloud Translation API" → ⚠ dịch chữ
"Natural Language API"  → ⚠ phân tích VĂN BẢN
"Speech-to-Text API"    → ⚠ xử lý ÂM THANH

⚠ Gần trùng với #13498 (cùng lô) — đề đó cũng khoá Vision API nhưng cho landmark detection. Hai đề khác tính năng, cùng dịch vụ, hoàn toàn nhất quán. Cùng nhóm với #13325/#13357 (lô 140).

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

• C (Natural Language API) — phương án gần nhất vì nó cũng phân tích cảm xúc (sentiment), nhưng cảm xúc trong VĂN BẢN, không phải trên khuôn mặt trong ảnh.

• A (Translation) và D (Speech-to-Text) — không xử lý ảnh.

Ghi nhớ

⚠ Hai loại "cảm xúc" — rất dễ nhầm, bảng phải thuộc: | Đầu vào | Dịch vụ | Ra gì | |---|---|---| | ⚠ Ảnh khuôn mặt | ⚠ Vision API face detection | ⚠ mức khả năng biểu cảm | | ⚠ Văn bản | ⚠ Natural Language sentiment | ⚠ điểm −1 → +1 và magnitude | | Âm thanh | Speech-to-Text → NL | ⚠ phải qua hai bước | | Video | Video Intelligence | nhãn theo mốc thời gian |

Từ khoá nhận diện:

"khuôn mặt trong ảnh, biểu cảm" → ⚠ Vision API "đánh giá của khách, tích cực hay tiêu cực" → Natural Language "địa danh, logo, chữ trong ảnh" → Vision API "nhận ra ĐÍCH DANH người" → ⚠ Vision API KHÔNG làm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết quả có đủ tin cậy không | ⚠ thử trên ảnh thật của bạn | | Có được phép xử lý ảnh mặt không | ⚠ kiểm quy định về sinh trắc học | | Chi phí | ⚠ số ảnh × số tính năng bật |

Và một ranh giới đáng ghi lại rõ ràng trước khi đưa tính năng này vào sản phẩm: Vision API cho biết một khuôn mặt trông như thế nào, chứ không cho biết người đó đang cảm thấy gì. Khoảng cách giữa hai điều đó nhỏ trong tài liệu kỹ thuật, nhưng rất lớn khi kết quả được dùng để đánh giá con người.

Đáp án

D — Dùng hạ tầng đã được chứng nhận và các giải pháp tự động hoá của Google Cloud dành cho khối lượng công việc SAP.

Vì sao đúng

SAP là khối lượng công việc đặc thù: nó chỉ được SAP hỗ trợ khi chạy trên cấu hình đã được SAP chứng nhận. Google Cloud có sẵn dòng máy và giải pháp cho việc này.

⚠ Vì sao phải là hạ tầng chứng nhận:

SAP HANA là CSDL IN-MEMORY
        ↓
    ⚠ đòi lượng RAM rất lớn
      (hàng trăm GB tới hàng TB)
    ⚠ đòi tỉ lệ CPU/RAM cụ thể
    ⚠ đòi thông lượng đĩa tối thiểu
        ↓
    ⚠ Chạy trên cấu hình KHÔNG
      chứng nhận
        ↓
    ⚠ SAP có thể TỪ CHỐI hỗ trợ
      khi có sự cố

⚠ Google Cloud cung cấp gì cho SAP:

⚠ DÒNG MÁY ĐƯỢC CHỨNG NHẬN
    → M-series: bộ nhớ rất lớn
    → ⚠ tới nhiều TB RAM

⚠ TỰ ĐỘNG HOÁ TRIỂN KHAI
    → mẫu dựng sẵn cho HANA,
      NetWeaver

⚠ GIẢI PHÁP HA/DR
    → agent cho Linux cluster

⚠ TÍCH HỢP PHÂN TÍCH
    → đưa dữ liệu SAP sang BigQuery

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

"Chạy SAP trên MỘT máy e2-micro
 dùng chung lõi"
    → ⚠ vô lý: máy nhỏ nhất,
      không đủ RAM cho cả khởi động

"VIẾT LẠI toàn bộ SAP bằng
 Cloud Functions"
    → ⚠ SAP là phần mềm THƯƠNG MẠI,
      không viết lại được

"Chuyển CSDL SAP sang Cloud SQL
 for MySQL"
    → ⚠ SAP không chạy trên đó

Đối chiếu #13443 (lô 142) — đề đó khoá Bare Metal Solution cho Oracle. Cùng một ý lớn: khối lượng công việc doanh nghiệp đặc thù cần hạ tầng chuyên biệt được chứng nhận. Không mâu thuẫn — khác phần mềm, khác giải pháp.

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

• C (chuyển CSDL SAP sang Cloud SQL for MySQL) — phương án gần nhất vì nghe hợp lý về mặt hiện đại hoá, nhưng SAP chỉ hỗ trợ một số CSDL nhất định; MySQL không nằm trong đó.

• A (e2-micro) — cỡ máy nhỏ nhất, không thể chạy SAP.

• B (viết lại bằng Cloud Functions) — không viết lại được phần mềm thương mại.

Ghi nhớ

⚠ Khối lượng công việc doanh nghiệp đặc thù — bảng nên thuộc: | Workload | Giải pháp trên Google Cloud | |---|---| | ⚠ SAP / SAP HANA | ⚠ dòng M có chứng nhận + tự động hoá | | Oracle | ⚠ Bare Metal Solution | | VMware | Google Cloud VMware Engine | | Windows Server / SQL Server | ⚠ ảnh có sẵn giấy phép | | HPC | dòng C, GPU, TPU | | Điểm chung | ⚠ KHÔNG viết lại — chạy như đang chạy |

Từ khoá nhận diện:

"SAP, được chứng nhận" → ⚠ hạ tầng SAP-certified "Oracle, phần cứng vật lý" → Bare Metal Solution "VMware, giữ nguyên vSphere" → VMware Engine "ứng dụng cũ, chuyển nhanh" → Rehost / lift and shift

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cấu hình có trong danh sách chứng nhận không | ⚠ tra SAP Note tương ứng | | Cần bao nhiêu RAM | ⚠ chạy công cụ định cỡ của SAP | | Chi phí | ⚠ máy bộ nhớ lớn rất đắt — cam kết 1–3 năm |

Và món lợi mà nhiều doanh nghiệp không lường trước khi đưa SAP lên đám mây: có thể dựng một bản sao đầy đủ của hệ thống production để kiểm thử trong vài giờ. Việc đó ở trung tâm dữ liệu riêng thường mất nhiều tháng chờ phần cứng — và chính nó là thứ thay đổi nhịp làm việc của đội SAP nhiều nhất.

Đáp án

C — On-demand pricing (tính theo mức dùng).

Vì sao đúng

Đề mô tả tải rất thưa: vài truy vấn lớn, mỗi tháng một lần. Với mô hình dung lượng cố định, bạn trả tiền cho năng lực nằm không suốt 29 ngày còn lại.

⚠ Hai mô hình tính tiền tính toán của BigQuery:

⚠ ON-DEMAND
    → ⚠ trả theo SỐ BYTE QUÉT
    → ⚠ không dùng thì KHÔNG TRẢ ĐỒNG NÀO
    → hợp với tải THƯA, khó đoán
    → ⚠ đề này

CAPACITY / FLAT-RATE (slot)
    → ⚠ mua sẵn năng lực theo
      giờ / tháng / năm
    → ⚠ trả ĐỀU dù có chạy hay không
    → hợp với tải LỚN và LIÊN TỤC
    → ⚠ chi phí DỰ ĐOÁN ĐƯỢC

⚠ Điểm hoà vốn:

Chi phí on-demand tháng này
        ↓
    ⚠ nếu ĐỀU ĐẶN cao hơn giá
      của số slot tương ứng
        ↓
    → chuyển sang capacity

    ⚠ nếu chỉ thỉnh thoảng mới chạy
        ↓
    → ⚠ giữ on-demand

⚠ Vì sao hai phương án còn lại sai:

"Streaming insert pricing"
    → ⚠ giá cho việc GHI dữ liệu
      theo dòng, không phải TRUY VẤN

"Active storage pricing"
    → ⚠ giá LƯU TRỮ, tách riêng
      hoàn toàn với giá tính toán

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

• D (flat-rate) — phương án gần nhất vì với tải liên tục nó rẻ hơn hẳn, nhưng ở đây bạn sẽ trả cho năng lực nằm không gần cả tháng.

• A (streaming insert) và B (active storage) — không phải mô hình giá cho truy vấn; chúng tính cho việc ghi và việc lưu.

Ghi nhớ

⚠ Ba nhóm chi phí BigQuery — bảng phải thuộc: | Nhóm | Tính theo | |---|---| | ⚠ Tính toán — truy vấn | ⚠ on-demand (byte quét) HOẶC capacity (slot) | | ⚠ Lưu trữ | ⚠ active (< 90 ngày) và long-term (rẻ hơn ~50%) | | Nạp và xuất dữ liệu | ⚠ batch load MIỄN PHÍ, streaming CÓ PHÍ |

Từ khoá nhận diện:

"thỉnh thoảng, khó đoán, ít truy vấn" → ⚠ on-demand "chạy liên tục, cần chi phí dự đoán được" → capacity / slot "bảng không sửa 90 ngày" → ⚠ long-term storage tự động "ghi từng dòng thời gian thực" → streaming insert

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn này quét bao nhiêu | ⚠ ước tính hiện ngay trong Console | | Chi tiêu tháng qua bao nhiêu | ⚠ INFORMATION_SCHEMA.JOBS — xem ai tốn nhất | | Có nên đổi mô hình không | ⚠ so chi phí on-demand với giá slot tương đương |

Và biện pháp phòng vệ đơn giản nhất mà mọi đội dùng BigQuery on-demand nên bật từ ngày đầu: giới hạn số byte tối đa mỗi truy vấn được phép tính tiền. Nó biến một câu SELECT * gõ vội thành một thông báo lỗi thay vì một dòng bất ngờ trên hoá đơn cuối tháng.

Đáp án

C — Được xây bằng microservices, triển khai trong container và quản lý bằng điều phối động.

Vì sao đúng

Ba yếu tố trong đáp án chính là định nghĩa của cloud-native: chia nhỏ, đóng gói, và để hệ thống tự quản lý.

⚠ Ba trụ cột:

⚠ MICROSERVICES
    → mỗi dịch vụ một trách nhiệm
    → ⚠ triển khai ĐỘC LẬP
    → đội nhỏ sở hữu trọn vẹn

⚠ CONTAINER
    → ⚠ đóng gói cả phụ thuộc
    → chạy giống nhau ở mọi nơi
    → khởi động trong giây

⚠ ĐIỀU PHỐI ĐỘNG
    → Kubernetes tự đặt lịch,
      ⚠ tự khởi động lại, tự co giãn
    → ⚠ máy hỏng thì tự chuyển chỗ

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

"Cần MỞ RỘNG THỦ CÔNG bởi đội
 quản trị đông người"
    → ⚠ ngược: cloud-native tự động hoá

"Khối MONOLITH lớn, cập nhật
 MỖI NĂM MỘT LẦN"
    → ⚠ đúng thứ cloud-native
      muốn thay thế

"Chỉ chạy được trên máy chủ VẬT LÝ
 tại chỗ"
    → ⚠ ngược hoàn toàn

Nhất quán với #13473 (cùng lô) về triển khai độc lập của microservices, và #13513 (cùng lô) về Kubernetes điều phối container. Ba đề mô tả ba mặt của cùng một mô hình.

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

• B (monolith cập nhật mỗi năm) — phương án gần nhất về mặt "cũng mô tả một kiến trúc ứng dụng thật", nhưng đó chính là mô hình truyền thống mà cloud-native ra đời để thay thế.

• A (mở rộng thủ công) và D (chỉ chạy trên máy vật lý) — trái ngược với mọi đặc trưng của cloud-native.

Ghi nhớ

⚠ Cloud-native và truyền thống — bảng phải thuộc: | | Truyền thống | ⚠ Cloud-native | |---|---|---| | Kiến trúc | monolith | ⚠ microservices | | Đóng gói | cài lên máy chủ | ⚠ container | | Mở rộng | thủ công, theo chiều dọc | ⚠ tự động, theo chiều ngang | | Phát hành | vài lần một năm | ⚠ nhiều lần một ngày | | Xử lý lỗi | tránh lỗi | ⚠ thiết kế để CHỊU được lỗi | | Hạ tầng | bấm tay | ⚠ khai báo bằng mã |

Từ khoá nhận diện:

"microservices, container, điều phối" → cloud-native "chuyển nguyên trạng lên máy ảo" → ⚠ lift and shift — CHƯA cloud-native "viết lại theo kiến trúc đám mây" → Refactor "không quản máy chủ nào" → serverless

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Đội có đủ người vận hành không | ⚠ microservices tăng gánh nặng vận hành | | Có CI/CD và giám sát chưa | ⚠ thiếu thì đừng chia nhỏ | | Biên dịch vụ đặt ở đâu | ⚠ theo miền nghiệp vụ, không theo tầng kỹ thuật |

Và điều đáng cân nhắc trước khi một đội quyết định "làm cloud-native": microservices giải quyết vấn đề của tổ chức nhiều hơn vấn đề của phần mềm. Nếu chỉ có một đội năm người, chia mười dịch vụ thường tạo ra nhiều việc vận hành hơn là giá trị thu được.

Đáp án

A — Data democratization (dân chủ hoá dữ liệu).

Vì sao đúng

Dân chủ hoá dữ liệu là việc để người không chuyên kỹ thuật cũng tự truy cập và phân tích dữ liệu — không phải mở phiếu yêu cầu và chờ đội kỹ thuật.

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

Marketing cần một báo cáo
        ↓
    Mở phiếu cho đội dữ liệu
        ↓
    ⚠ Chờ vài ngày tới vài tuần
        ↓
    Nhận báo cáo — ⚠ nhưng đã
      nảy ra câu hỏi mới
        ↓
    ⚠ Lặp lại vòng chờ
        ↓
    ⚠ Kết quả: quyết định dựa
      trên CẢM TÍNH vì chờ không nổi

⚠ Dân chủ hoá thì thành:

Marketing tự mở dashboard
        ↓
    ⚠ tự lọc, tự khoan sâu
    ⚠ có câu trả lời TRONG PHÚT
        ↓
    Đội dữ liệu chuyển sang
    ⚠ XÂY NỀN TẢNG thay vì
      chạy báo cáo lẻ

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

"Data silo-ing"
    → ⚠ NGƯỢC LẠI: dữ liệu bị nhốt
      trong từng bộ phận

"Data obfuscation"
    → ⚠ LÀM MỜ dữ liệu để bảo vệ
      riêng tư — mục đích khác hẳn

"Data hoarding"
    → ⚠ tích trữ dữ liệu mà không dùng

Nhất quán với #13475 (cùng lô) về Looker mang lại giá trị nghiệp vụ, và #13509 (cùng lô) về data silo — hai mặt đối lập của cùng một chủ đề.

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

• B (data silo-ing) — phương án gần nhất vì cũng nói về việc ai tiếp cận được dữ liệu, nhưng nó mô tả tình trạng ngược lại: dữ liệu bị cô lập trong từng hệ thống.

• C (obfuscation) — kỹ thuật che dữ liệu nhạy cảm.

• D (hoarding) — thu thập rồi để đó.

Ghi nhớ

⚠ Bốn thuật ngữ về dữ liệu — rất hay ra đề: | Thuật ngữ | Nghĩa | |---|---| | ⚠ Data democratization | ⚠ ai cũng tự truy cập và phân tích được | | ⚠ Data silo | ⚠ dữ liệu bị nhốt trong từng bộ phận | | Data obfuscation / masking | ⚠ che dữ liệu nhạy cảm | | Data governance | ⚠ quy tắc: ai được xem gì, chất lượng, vòng đời |

Từ khoá nhận diện:

"người không chuyên tự làm báo cáo" → ⚠ data democratization "mỗi phòng một hệ thống riêng" → data silo "che số thẻ, ẩn tên" → masking / DLP "ai được xem dữ liệu nào" → data governance

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người không chuyên có tự làm được không | ⚠ thử với một người thật, xem họ vấp ở đâu | | Chỉ số có thống nhất không | ⚠ hỏi hai phòng cùng một câu, so kết quả | | Có ai xem được thứ không nên xem không | ⚠ rà IAM và column-level security |

Và thước đo thật của việc dân chủ hoá dữ liệu không phải là số dashboard đã dựng, mà là: khi hai bộ phận cùng báo cáo doanh thu tháng, họ có ra cùng một con số hay không. Nếu không, cái đang được dân chủ hoá là sự nhầm lẫn chứ không phải dữ liệu.

Đáp án

B — Dữ liệu bị mắc kẹt trong các hệ thống cô lập ("data silo"), khiến khó có được cái nhìn thống nhất về doanh nghiệp.

Vì sao đúng

Silo dữ liệu là rào cản kinh điển: dữ liệu có đủ, nhưng nằm rải rác ở những nơi không nói chuyện với nhau.

⚠ Silo hình thành thế nào:

Mỗi bộ phận mua hệ thống riêng
        ↓
    Bán hàng → CRM
    Marketing → công cụ quảng cáo
    Tài chính → phần mềm kế toán
    Kho → hệ thống ERP
        ↓
    ⚠ Mỗi nơi một định nghĩa
      "khách hàng"
    ⚠ Mỗi nơi một con số doanh thu
        ↓
    ⚠ Không ai trả lời nổi câu hỏi
      "khách này đóng góp bao nhiêu
       trong suốt vòng đời?"

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

"TUYỂN QUÁ NHIỀU nhà phân tích"
    → ⚠ hiếm khi là vấn đề; và
      không phải rào cản của văn hoá

"Có QUÁ NHIỀU dữ liệu CHẤT LƯỢNG CAO"
    → ⚠ đó là tài sản, không phải rào cản

"Dùng kho dữ liệu NHANH như BigQuery"
    → ⚠ đó là GIẢI PHÁP, không phải
      vấn đề

Đối chiếu #13508 (cùng lô) — đề đó hỏi về data democratization. Hai đề là hai mặt của cùng một chủ đề: silo là bệnh, dân chủ hoá là đích đến. Hoàn toàn nhất quán.

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

• D (dùng BigQuery) — phương án gần nhất về mặt "cũng nói tới dữ liệu quy mô lớn", nhưng kho dữ liệu nhanh chính là cách phá bỏ silo, không phải nguyên nhân gây ra vấn đề.

• A (tuyển quá nhiều nhà phân tích) và C (quá nhiều dữ liệu chất lượng cao) — cả hai đều không phải rào cản thật.

Ghi nhớ

⚠ Bốn rào cản của văn hoá dữ liệu — nên thuộc: | Rào cản | Biểu hiện | |---|---| | ⚠ Data silo | ⚠ không có cái nhìn thống nhất — đề này | | Chất lượng dữ liệu kém | ⚠ không ai tin con số | | Thiếu kỹ năng và công cụ | phải nhờ đội kỹ thuật cho mọi câu hỏi | | ⚠ Văn hoá dựa vào cấp trên | ⚠ quyết theo ý người to nhất, không theo số |

Từ khoá nhận diện:

"mỗi phòng một hệ thống, không nối được" → ⚠ data silo "người không chuyên tự phân tích" → data democratization "gom mọi nguồn về một nơi" → ⚠ data warehouse / lakehouse "quy tắc ai xem gì, chất lượng, vòng đời" → data governance

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu nguồn dữ liệu thật | ⚠ kiểm kê — thường nhiều hơn ta nghĩ | | Định nghĩa chỉ số có thống nhất không | ⚠ hỏi ba phòng cùng một câu | | Nối được nguồn nào trước | ⚠ chọn nguồn mang giá trị nhanh nhất |

Và cách nhanh nhất để biết một tổ chức có silo dữ liệu hay không: hỏi ba bộ phận cùng một câu hỏi đơn giản về doanh thu tháng trước. Nếu nhận về ba con số khác nhau, vấn đề đã được chẩn đoán xong — phần còn lại chỉ là chọn nguồn nào hợp nhất trước.

Đáp án

D — Một API được quản lý bằng nền tảng như Apigee.

Vì sao đúng

Ba yêu cầu của đề — kiểm soát truy cập, áp hạn mức sử dụng, có phân tích về cách đối tác dùng — chính là ba việc mà một nền tảng quản lý API sinh ra để làm.

⚠ Apigee đứng ở đâu:

Đối tác bên ngoài
        ↓
    ⚠ APIGEE (cổng API)
        ↓
    ⚠ Xác thực bằng API key / OAuth
    ⚠ Áp QUOTA cho từng đối tác
    ⚠ Chống lạm dụng, chặn tấn công
    ⚠ Ghi nhận PHÂN TÍCH mọi lời gọi
    ⚠ Chuyển đổi, ghép nhiều dịch vụ
        ↓
    Dịch vụ danh mục sản phẩm
    ở bên trong

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

"VPN riêng cho TỪNG đối tác"
    → ⚠ mở cả mạng nội bộ ra
    → ⚠ không có quota, không có
      phân tích theo API
    → ⚠ quản lý cực nặng khi
      có nhiều đối tác

"BẢNG TÍNH chia sẻ danh mục"
    → ⚠ không có kiểm soát, không
      cập nhật thời gian thực

"Bucket Cloud Storage CÔNG KHAI"
    → ⚠ ai cũng đọc được
    → ⚠ không quota, không định danh

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

• A (VPN riêng cho từng đối tác) — phương án gần nhất vì cũng là một cơ chế truy cập có kiểm soát, nhưng VPN kiểm soát ở tầng mạng: nó không biết đối tác gọi API nào, bao nhiêu lần, và không áp được hạn mức theo lời gọi.

• B (bảng tính) và C (bucket công khai) — không có định danh, không có hạn mức, không có phân tích.

Ghi nhớ

⚠ Bốn việc của một nền tảng quản lý API — bảng phải thuộc: | Việc | Nội dung | |---|---| | ⚠ Bảo mật | ⚠ API key, OAuth, JWT, mTLS | | ⚠ Quota và rate limit | ⚠ theo TỪNG đối tác, từng gói | | ⚠ Phân tích | ⚠ ai gọi gì, bao nhiêu, lỗi ở đâu | | ⚠ Trải nghiệm lập trình viên | ⚠ cổng tài liệu, tự đăng ký lấy key | | Thêm | chuyển đổi dữ liệu, ghép nhiều dịch vụ, phiên bản API |

Từ khoá nhận diện:

"đối tác bên ngoài, quota, phân tích" → ⚠ Apigee "kết nối mạng riêng giữa hai nơi" → VPN / Interconnect "phân tải cho nhiều máy chủ" → Load Balancer "chặn tấn công web, bot" → ⚠ Cloud Armor "API nội bộ giữa microservices" → ⚠ service mesh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chặn được đối tác gọi quá mức không | ⚠ thử vượt quota xem có bị 429 | | Có biết ai gọi gì không | ⚠ mở bảng phân tích của Apigee | | Đối tác tự lấy được key chưa | ⚠ thử quy trình đăng ký như người ngoài |

Và một quyết định nên đưa ra ngay ngày đầu mở API cho bên thứ ba: đặt hạn mức mặc định thấp hơn mức bạn nghĩ là cần. Nới hạn mức cho một đối tác đang dùng tốt là cuộc trò chuyện dễ chịu; siết lại một đối tác đã quen gọi thoải mái thì không.

Đáp án

A — Cloud Run.

Vì sao đúng

Bốn dữ kiện của đề trùng khít với Cloud Run: container, không trạng thái, có quản lý hoàn toàn / serverless, chỉ trả tiền khi đang xử lý request.

⚠ Bốn dữ kiện khớp:

"đóng gói trong CONTAINER"
    → ⚠ Cloud Run chạy container
      bất kỳ

"KHÔNG TRẠNG THÁI"
    → ⚠ đúng mô hình Cloud Run

"SERVERLESS, có quản lý hoàn toàn"
    → ⚠ không cụm nào để quản

"⚠ chỉ trả tiền KHI ĐANG xử lý"
    → ⚠ Cloud Run CO VỀ 0 —
      không request thì không trả

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

"GKE"
    → ⚠ node chạy LIÊN TỤC và
      tính tiền LIÊN TỤC
    → ⚠ phải quản cụm
    (Autopilot bớt việc quản
     nhưng vẫn không co về 0
     như Cloud Run)

"Compute Engine"
    → ⚠ máy ảo, trả tiền theo
      thời gian máy chạy

"Bare Metal Solution"
    → ⚠ máy chủ vật lý thuê riêng,
      xa nhất với serverless

Nhất quán với #13489 (cùng lô) — cùng nói về co về 0 của Cloud Run. Đối chiếu #13515 (cùng lô) khoá GKE vì đề đó đòi kiểm soát chi tiết cụm, mạng và node pool. Không mâu thuẫn — khác mức kiểm soát cần có.

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

• C (GKE) — phương án gần nhất vì cũng chạy container và cũng có quản lý, nhưng bạn vẫn trả tiền cho node đang chạy kể cả khi không có request nào.

• D (Compute Engine) — phải tự cài, tự vá, tự mở rộng.

• B (Bare Metal Solution) — dành cho khối lượng công việc như Oracle, hoàn toàn không phù hợp.

Ghi nhớ

⚠ Bốn lựa chọn tính toán — bảng phải thuộc: | Dịch vụ | Bạn quản gì | Trả tiền khi | |---|---|---| | Compute Engine | ⚠ OS, vá lỗi, mở rộng | máy bật | | GKE | ⚠ cụm, node pool, mạng | node chạy | | ⚠ Cloud Run | ⚠ CHỈ container | ⚠ đang xử lý request | | Cloud Functions | ⚠ chỉ một hàm | ⚠ hàm chạy |

Từ khoá nhận diện:

"container, serverless, trả theo request" → ⚠ Cloud Run "cần kiểm soát cụm, node pool" → GKE "toàn quyền trên OS" → Compute Engine "một hàm phản ứng với sự kiện" → Cloud Functions

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Ứng dụng có giữ trạng thái không | có → ⚠ đưa ra ngoài: Cloud SQL, Memorystore | | Cold start có chấp nhận được không | không → ⚠ min instances | | Có cần kiểm soát mạng cụm không | có → GKE |

Và một cách nhìn giúp chọn nhanh giữa Cloud Run và GKE: hãy hỏi đội đang thật sự muốn cấu hình cái gì. Nếu câu trả lời chỉ là "container của tôi", Cloud Run đủ; nếu là node pool, chính sách mạng, sidecar và các thứ tương tự, thì GKE mới là chỗ đúng.

Đáp án

D — Operating Expenses (OpEx).

Vì sao đúng

OpEx là chi phí vận hành định kỳ để duy trì hoạt động hằng ngày — và hoá đơn dịch vụ đám mây hằng tháng là ví dụ chuẩn mực nhất.

⚠ CapEx và OpEx:

⚠ CAPEX — chi phí VỐN
    → ⚠ mua tài sản, trả TRƯỚC
      một khoản lớn
    → máy chủ, thiết bị mạng,
      xây trung tâm dữ liệu
    → ⚠ khấu hao nhiều năm
    → ⚠ phải xin duyệt ngân sách,
      chờ hàng tháng

⚠ OPEX — chi phí VẬN HÀNH
    → ⚠ chi phí ĐỊNH KỲ hằng tháng
    → ⚠ hoá đơn đám mây, tiền điện,
      lương, thuê văn phòng
    → ⚠ ghi nhận NGAY vào kỳ đó

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

"Capital Expenditures (CapEx)"
    → ⚠ NGƯỢC LẠI: mua trước,
      dùng dần

"Total Cost of Ownership (TCO)"
    → ⚠ TỔNG mọi chi phí —
      CapEx CỘNG OpEx cộng chi phí ẩn
    → ⚠ là công cụ SO SÁNH,
      không phải loại chi phí

"Compute Power"
    → ⚠ không phải thuật ngữ tài chính

Nhất quán với #13471 và #13476 (cùng lô) — cả ba đề cùng chủ đề chuyển CapEx sang OpEx khi lên đám mây. Hoàn toàn nhất quán.

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

• C (TCO) — phương án gần nhất vì cũng là thuật ngữ tài chính về chi phí, nhưng TCO là tổng hợp mọi chi phí trong vòng đời, không phải riêng nhóm chi phí định kỳ.

• B (CapEx) — đúng khái niệm đối lập.

• A (Compute Power) — không phải thuật ngữ tài chính.

Ghi nhớ

⚠ Ba thuật ngữ tài chính — bảng phải thuộc: | Thuật ngữ | Nghĩa | Ví dụ | |---|---|---| | ⚠ CapEx | ⚠ mua tài sản, trả trước | mua máy chủ | | ⚠ OpEx | ⚠ chi phí ĐỊNH KỲ | ⚠ hoá đơn đám mây hằng tháng | | ⚠ TCO | ⚠ TỔNG mọi chi phí vòng đời | ⚠ CapEx + OpEx + điện, làm mát, nhân sự |

Từ khoá nhận diện:

"hằng tháng, định kỳ, theo mức dùng" → ⚠ OpEx "mua trước, khấu hao" → CapEx "so sánh tại chỗ với đám mây" → ⚠ TCO "tiết kiệm khi cam kết dài hạn" → ⚠ CUD — vẫn là OpEx

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So sánh có công bằng không | ⚠ so TCO, đừng so giá máy với giá máy | | Chi tiêu tháng này thuộc về ai | ⚠ gán nhãn từ ngày đầu | | Có gì đang chạy mà không ai dùng | ⚠ Recommender + rà soát hằng tháng |

Và sai lầm hay gặp nhất khi một doanh nghiệp so sánh chi phí tại chỗ với đám mây: đem giá thuê máy ảo so với giá mua máy chủ. Phép so sánh đúng là TCO với TCO — và khi cộng đủ điện, mặt bằng, nhân sự vận hành và phần năng lực mua dư nằm không, con số thường khác hẳn.

Đáp án

D — Kubernetes.

Vì sao đúng

Kubernetes là chuẩn công nghiệp để điều phối container ở quy mô lớn — đúng việc mà đề mô tả sau khi tách monolith thành nhiều dịch vụ đóng gói riêng.

⚠ Vì sao cần điều phối:

Một container thì chạy tay được
        ↓
    Nhưng 50 dịch vụ × nhiều bản sao
        ↓
    ⚠ Đặt container nào lên máy nào?
    ⚠ Container chết thì ai khởi động lại?
    ⚠ Tải tăng thì ai thêm bản sao?
    ⚠ Máy hỏng thì chuyển đi đâu?
    ⚠ Các dịch vụ tìm nhau bằng cách nào?
    ⚠ Phát hành phiên bản mới không
      gián đoạn ra sao?
        ↓
    → ⚠ KUBERNETES làm tất cả

⚠ Kubernetes làm gì:

⚠ ĐẶT LỊCH — chọn node phù hợp
⚠ TỰ CHỮA — pod chết thì tạo lại
⚠ TỰ CO GIÃN — HPA theo CPU/metric
⚠ SERVICE DISCOVERY — DNS nội bộ
⚠ CÂN BẰNG TẢI giữa các pod
⚠ ROLLING UPDATE và ROLLBACK
⚠ QUẢN CẤU HÌNH và BÍ MẬT

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

"Virtual Machines"
    → ⚠ là NƠI CHẠY, không phải
      công cụ điều phối

"Một máy chủ VẬT LÝ duy nhất"
    → ⚠ ngược hẳn với "ở quy mô lớn"

"Cloud SQL"
    → ⚠ CSDL quan hệ có quản lý,
      không liên quan tới container

Nhất quán với #13507 (cùng lô) về ba trụ cột cloud-native và #13473 (cùng lô) về triển khai độc lập của microservices.

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

• A (Virtual Machines) — phương án gần nhất vì container thật sự chạy trên máy ảo, nhưng máy ảo là hạ tầng, không phải lớp điều phối.

• B (một máy chủ vật lý) — không thể mở rộng.

• C (Cloud SQL) — dịch vụ cơ sở dữ liệu.

Ghi nhớ

⚠ Ba lớp — đừng lẫn, bảng phải thuộc: | Lớp | Ví dụ | Vai trò | |---|---|---| | Hạ tầng | VM, máy vật lý | ⚠ nơi chạy | | Đóng gói | ⚠ container (Docker) | ⚠ ứng dụng + phụ thuộc | | ⚠ Điều phối | ⚠ Kubernetes | ⚠ quản container ở quy mô lớn |

Từ khoá nhận diện:

"điều phối container quy mô lớn" → ⚠ Kubernetes "Kubernetes có quản lý trên Google Cloud" → ⚠ GKE "container nhưng KHÔNG muốn quản cụm" → Cloud Run "chạy K8s ở nhiều đám mây" → ⚠ Anthos / GKE Enterprise

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có bao nhiêu dịch vụ cần điều phối | ít → ⚠ Cloud Run | | Đội có kinh nghiệm K8s không | không → ⚠ Autopilot hoặc Cloud Run | | Có cần cấu hình mạng đặc thù không | có → GKE Standard |

Và câu hỏi nên đặt trước khi một đội quyết định dựng cụm Kubernetes: có ai trong đội sẽ chịu trách nhiệm vận hành nó lúc 3 giờ sáng không? Kubernetes giải quyết rất nhiều bài toán, nhưng nó cũng là một hệ thống cần được hiểu — và với nhiều đội nhỏ, Cloud Run là câu trả lời đúng hơn.