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

Đáp án

D — Đội A: dùng API dựng sẵn; Đội B: xây mô hình tuỳ biến.

Vì sao đúng

Hai đội có hai bài toán hoàn toàn khác nhau về bản chất, và câu chữ trong đề đã chỉ rõ:

⚠ Đội A — dịch tiếng Tây Ban Nha:

"NHANH CHÓNG thêm tính năng dịch"
"để kịp trước đối thủ ra mắt
 THÁNG SAU"
        ↓
    ⚠ Ràng buộc là THỜI GIAN
    ⚠ Dịch thuật là bài toán PHỔ QUÁT
    ⚠ Không ai thắng thị trường nhờ
      dịch tốt hơn 2%
        ↓
    → CLOUD TRANSLATION API
    → triển khai trong vài giờ

⚠ Đội B — phát hiện gian lận:

"MỚI LẠ, ĐỘC QUYỀN"
"⚠ LỢI THẾ CẠNH TRANH CỐT LÕI"
        ↓
    ⚠ Mẫu gian lận là RIÊNG của
      chính doanh nghiệp này
    ⚠ Không có API sẵn nào biết
      dữ liệu của họ
    ⚠ Đây LÀ thứ tạo khác biệt
        ↓
    → MÔ HÌNH TUỲ BIẾN trên Vertex AI

⚠ Nguyên tắc gói gọn:

⚠ "Build what differentiates,
    buy what doesn't"
        ↓
    Tự xây phần TẠO KHÁC BIỆT
    Mua sẵn phần còn lại
        ↓
    Đội A: dịch → không khác biệt → mua
    Đội B: chống gian lận → khác biệt → xây

Nhất quán với #13270 (lô 139) và #13251, #13259 (lô 138) — cùng nguyên tắc ba mức giải pháp AI, và các đề trước cũng đưa dịch thuật làm ví dụ cho API dựng sẵn, phát hiện gian lận làm ví dụ cho mô hình tuỳ biến. Hoàn toàn nhất quán.

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

• B (đội A xây tuỳ biến, đội B dùng API sẵn) — phương án gần nhất về mặt "có cả hai khái niệm" nhưng đảo ngược hoàn toàn: xây mô hình dịch riêng thì không kịp tháng sau, còn không có API dựng sẵn nào phát hiện được gian lận đặc thù của công ty này.

• A (cả hai dùng AutoML) — với đội A là thừa: đã có API sẵn rất tốt. Với đội B là thiếu: AutoML không cho kiểm soát kiến trúc mà một hệ thống lõi cạnh tranh cần.

• C (cả hai dùng BigQuery ML) — BigQuery ML không dịch được ngôn ngữ, nên đội A trượt ngay. (Với đội B thì BigQuery ML có thể là điểm khởi đầu, nhưng không đủ cho "toàn quyền kiểm soát".)

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Khi nào | Ví dụ | |---|---|---| | API dựng sẵn | ⚠ việc phổ quát, cần NHANH, không chuyên gia | Translation, Vision, Speech | | AutoML | dữ liệu riêng, không viết mã | Vertex AI AutoML | | Tuỳ biến | ⚠ lợi thế cạnh tranh, cần kiểm soát kiến trúc | Vertex AI custom training |

Từ khoá nhận diện:

"nhanh, phổ quát, hạn chót gấp" → API dựng sẵn "dữ liệu riêng, không lập trình" → AutoML "độc quyền, lợi thế cạnh tranh cốt lõi" → ⚠ mô hình tuỳ biến "dữ liệu bảng biểu, biết SQL" → BigQuery ML

Ba câu hỏi kiểm chứng cho mỗi sáng kiến AI: | Câu hỏi | Nếu... | |---|---| | API sẵn có đủ tốt không | ⚠ thử và ĐO trước khi tự xây | | Có kịp hạn không | không → chọn mức đơn giản hơn | | Ai nuôi mô hình sau khi ra mắt | không có ai → đừng bắt đầu |

Và một sai lầm rất tốn kém mà nhiều tổ chức mắc phải: đầu tư công sức lớn nhất vào phần không ai quan tâm. Không khách hàng nào đổi nhà cung cấp vì bản dịch tiếng Tây Ban Nha mượt hơn — nhưng họ sẽ rời đi nếu hệ thống chống gian lận để lọt giao dịch giả, và đó mới là chỗ đáng dồn người giỏi vào.

Đáp án

C — Dùng một API dựng sẵn như Cloud Vision API.

Vì sao đúng

Đề nêu ba điều kiện, và cả ba đều dẫn thẳng tới API dựng sẵn:

⚠ Ba điều kiện ↔ Vision API:

1. "KHÔNG có chuyên môn học máy"
     → không thể huấn luyện mô hình

2. "GIẢI PHÁP ĐƠN GIẢN: gửi ảnh tới
    một endpoint, nhận về danh sách nhãn"
     → ⚠ mô tả CHÍNH XÁC cách
       Vision API hoạt động

3. Nhãn ví dụ: "car", "tree", "dog"
     → ⚠ toàn NHÃN PHỔ QUÁT
     → mô hình chung của Google
       đã biết hàng chục nghìn nhãn

⚠ Gọi API chỉ có vậy:

from google.cloud import vision

client = vision.ImageAnnotatorClient()
image = vision.Image()
image.source.image_uri = "gs://bucket/anh.jpg"

for label in client.label_detection(image=image).label_annotations:
    print(label.description, label.score)
# car   0,96
# tree  0,89
# dog   0,84

        ↓
    ⚠ Không dữ liệu huấn luyện
    ⚠ Không mô hình phải nuôi
    ⚠ Không endpoint tính tiền
      thường trực

⚠ Khi nào mới cần AutoML Vision:

Nhãn PHỔ QUÁT ("chó", "xe hơi")
    → ⚠ Vision API

Nhãn RIÊNG của nghiệp vụ
  ("bốt leo núi nam", "lỗi hàn kiểu B")
    → ⚠ AutoML Vision
      → cần dữ liệu đã gán nhãn
        ↓
    Đề này chỉ cần nhãn phổ quát
        ↓
    → Vision API là đủ và đúng

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

• A (xây mô hình tuỳ biến với Vertex AI) — phương án gần nhất về mặt "cũng làm được", nhưng đề nói rõ đội không có chuyên môn ML và muốn giải pháp đơn giản. Tự huấn luyện để nhận diện "chó" và "cây" là lãng phí lớn.

• B (BigQuery ML) — huấn luyện mô hình trên dữ liệu bảng biểu bằng SQL. Không phải công cụ nhận diện ảnh.

• D (gán nhãn ảnh thủ công) — không phải giải pháp tự động; và ứng dụng cần nhận nhãn ngay khi có ảnh mới.

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 | ⚠ nhãn PHỔ QUÁT, không chuyên gia, cần nhanh | | AutoML | nhãn RIÊNG, không viết mã mô hình | | Tuỳ biến | cần kiểm soát kiến trúc, là khác biệt cạnh tranh |

Từ khoá nhận diện:

"nhận diện vật thể thông thường" → Vision API "danh mục sản phẩm riêng" → AutoML Vision "đọc chữ trong ảnh" → Vision API — OCR "trích xuất trường từ hoá đơn" → ⚠ Document AI, không phải Vision

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhãn có đủ dùng không | ⚠ thử 50 ảnh thật của bạn | | Ngưỡng tin cậy bao nhiêu là hợp | xem phân bố điểm | | Chi phí bao nhiêu | số ảnh × số tính năng bật |

Và một bước nên làm trước khi quyết định tự huấn luyện bất cứ mô hình ảnh nào: thử Vision API với ảnh thật của bạn và ghi lại kết quả. Rất nhiều dự án phát hiện ra rằng mô hình chung đã đủ tốt cho 90% trường hợp, và chỉ cần AutoML cho một nhóm nhỏ nhãn chuyên biệt còn lại.

Đáp án

C — Google Kubernetes Engine (GKE).

Vì sao đúng

Đề nêu bốn đặc điểm, và tất cả đều là mô tả của Kubernetes:

⚠ Bốn đặc điểm ↔ GKE:

1. "HÀNG TRĂM CONTAINER PHỤ THUỘC NHAU"
     → ⚠ quy mô đòi hỏi điều phối thật sự

2. "HỆ THỐNG KHAI BÁO (declarative)"
     → ⚠ đây là từ khoá quyết định:
       khai TRẠNG THÁI MONG MUỐN
       bằng YAML, hệ thống tự đưa
       thực tế về đúng trạng thái đó

3. "TỰ ĐỘNG HOÁ triển khai, mở rộng,
    quản lý vận hành"
     → Deployment, HPA, self-healing

4. "TRÊN MỘT CỤM MÁY ẢO"
     → ⚠ đúng mô hình cụm của Kubernetes

⚠ Khai báo khác mệnh lệnh thế nào:

MỆNH LỆNH (imperative)
  "tạo 5 container"
  "xoá container số 3"
        ↓
    ⚠ Bạn mô tả CÁC BƯỚC

KHAI BÁO (declarative)
  replicas: 5
        ↓
    ⚠ Bạn mô tả KẾT QUẢ MONG MUỐN
    ⚠ Kubernetes tự tìm cách đạt
      và GIỮ trạng thái đó
        ↓
    Một pod chết → tự tạo lại
    Node chết → tự dời pod
        ↓
    ⚠ Đây chính là "self-healing"

⚠ Gần trùng với #13248 (lô 138) — đề đó cũng nói về hàng chục container cần điều phối, tự chữa lành, và cùng khoá GKE. Hoàn toàn nhất quán. Mẫu đề lặp: nhiều container phụ thuộc nhau + điều phối + khai báo → luôn là GKE.

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

• B (Cloud Run) — phương án gần nhất và tuyệt vời cho dịch vụ đơn lẻ, nhưng nó không phải bộ điều phối cụm: không có lịch xếp pod, không có mạng nội bộ giữa hàng trăm thành phần, không có DaemonSet hay StatefulSet. Đề nói rõ "hàng trăm container phụ thuộc nhau".

• A (App Engine) — PaaS cho một ứng dụng, không điều phối cụm.

• D (Compute Engine) — chỉ cung cấp máy ảo trống; bạn sẽ phải tự dựng lại toàn bộ Kubernetes.

Ghi nhớ

⚠ Chọn nền tảng theo quy mô — bảng phải thuộc: | Nhu cầu | Chọn | |---|---| | Một dịch vụ container, co về 0 | Cloud Run | | ⚠ Hàng chục–trăm container phụ thuộc nhau | ⚠ GKE | | Ứng dụng web từ mã nguồn | App Engine | | Cần kiểm soát hệ điều hành | Compute Engine | | Hàm theo sự kiện | Cloud Run Functions |

Từ khoá nhận diện:

"điều phối, cụm, khai báo, hàng trăm container" → GKE "một dịch vụ, co về 0" → Cloud Run "service mesh, canary phức tạp, DaemonSet" → GKE "chuẩn mở, chuyển được sang đám mây khác" → ⚠ Kubernetes

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pod có khoẻ không | kubectl get pods — ⚠ cột RESTARTS cao là dấu hiệu xấu | | Vì sao pod chết | kubectl describe pod, kubectl logs --previous | | Cụm có đủ tài nguyên không | kubectl top nodes |

Và một lời nhắc đáng cân nhắc trước khi chọn GKE: Kubernetes trả công cho quy mô, và tính phí cho sự phức tạp. Với hàng trăm container phụ thuộc nhau như đề mô tả thì nó hoàn toàn xứng đáng — nhưng với ba dịch vụ, Cloud Run cho gần như toàn bộ lợi ích mà không cần ai trong đội trở thành chuyên gia Kubernetes.

Đáp án

D — Tăng tốc độ triển khai và giảm rủi ro sai sót do cấu hình thủ công.

Vì sao đúng

Đây là hai lợi ích cốt lõi của Infrastructure as Code (IaC), và chúng đi liền với nhau.

⚠ Vấn đề của cấu hình thủ công:

Kỹ sư SSH vào máy, gõ lệnh
        ↓
    ⚠ Không ai ghi lại đã gõ gì
    ⚠ Máy thứ hai được cấu hình
      hơi khác máy thứ nhất
    ⚠ Sáu tháng sau không ai
      dựng lại được y hệt
        ↓
    ⚠ "SNOWFLAKE SERVER" —
      máy chủ độc nhất vô nhị,
      không ai dám đụng vào
        ↓
    Môi trường dev, staging, prod
    KHÁC NHAU mà không ai biết chỗ nào

⚠ IaC giải quyết thế nào:

Hạ tầng viết thành FILE CẤU HÌNH
        ↓
    ⚠ Đưa vào Git — có lịch sử,
      có review, có quay lui
        ↓
    `terraform apply`
        ↓
    ⚠ Dựng lại y hệt, mọi lúc,
      mọi môi trường
        ↓
    → NHANH: dựng cả môi trường
      trong vài phút
    → ÍT SAI: máy không gõ nhầm lệnh

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

"Cho phép dùng máy MẠNH HƠN
 và ĐẮT HƠN"
    → ⚠ IaC không liên quan tới
      kích cỡ máy

"LOẠI BỎ HOÀN TOÀN nhu cầu
 có đội vận hành"
    → ⚠ SAI: đội vận hành chuyển
      sang viết mã hạ tầng,
      không biến mất

"CHẬM HƠN nhưng ĐẢM BẢO không
 bao giờ có lỗ hổng bảo mật"
    → ⚠ SAI hai lần:
      IaC làm NHANH HƠN,
      và ⚠ KHÔNG có gì đảm bảo
      không bao giờ có lỗ hổng

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

• C (chậm hơn nhưng đảm bảo không bao giờ có lỗ hổng) — phương án gần nhất về mặt "nghe như đánh đổi hợp lý", nhưng sai ở cả hai vế: IaC làm quá trình nhanh hơn, và không công cụ nào đảm bảo tuyệt đối về bảo mật. (IaC có giúp bảo mật — vì cấu hình được review và quét — nhưng không phải "không bao giờ".)

• B (loại bỏ hoàn toàn nhu cầu có đội vận hành) — vai trò thay đổi, không biến mất: đội vận hành viết và bảo trì mã hạ tầng.

• A (dùng máy mạnh hơn, đắt hơn) — không liên quan; IaC thường giảm chi phí nhờ dễ dọn tài nguyên thừa.

Ghi nhớ

⚠ Lợi ích của Infrastructure as Code — bảng nên thuộc: | Lợi ích | Nội dung | |---|---| | Tái lập được (reproducible) | ⚠ dev, staging, prod giống hệt nhau | | Quản lý phiên bản | Git — biết ai đổi gì, khi nào, vì sao | | Review trước khi áp dụng | pull request cho hạ tầng | | Quay lui được | về commit trước | | Tự động hoá | ⚠ đưa vào CI/CD | | Là tài liệu sống | mã chính là mô tả hạ tầng | | Giảm sai sót của con người | |

Từ khoá nhận diện:

"định nghĩa hạ tầng bằng file, đưa vào Git" → IaC "Terraform, Config Connector, Deployment Manager" → công cụ IaC "tự động hoá đường ống phát hành" → CI/CD "máy chủ không ai dám đụng vào" → ⚠ snowflake server — thứ IaC xoá bỏ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai sửa tay ngoài IaC không | ⚠ terraform plan — thấy thay đổi bất ngờ là có drift | | Dựng lại môi trường mất bao lâu | thử dựng một môi trường mới từ đầu | | State có được sao lưu không | bật versioning cho bucket chứa state |

Và một quy tắc phải thống nhất trong cả đội ngay khi bắt đầu dùng IaC: không ai sửa hạ tầng bằng tay nữa, kể cả "chỉ một chút cho nhanh". Chỉ cần vài lần ngoại lệ như vậy là mã trong Git không còn phản ánh thực tế, và khi đó IaC mất toàn bộ giá trị mà vẫn giữ nguyên chi phí.

Đáp án

D — DNS (Domain Name System).

Vì sao đúng

DNS là hệ thống phân cấp, toàn cầu dịch tên miền dễ nhớ thành địa chỉ IP mà máy tính dùng để kết nối — đúng như ví von "danh bạ điện thoại của Internet" trong đề.

⚠ Một lượt phân giải DNS:

Trình duyệt cần www.google.com
        ↓
1. Bộ đệm cục bộ — đã biết chưa?
        ↓ chưa
2. DNS resolver (thường của ISP)
        ↓
3. ROOT server: ".com ở đâu?"
        ↓
4. TLD server (.com): "google.com ở đâu?"
        ↓
5. Authoritative server của google.com:
   "www → 142.250.190.78"
        ↓
    ⚠ Trình duyệt kết nối tới IP đó
    ⚠ Kết quả được ĐỆM theo TTL

⚠ Vì sao gọi là "phân cấp":

            . (root)
             │
    ┌────────┼────────┐
   .com     .org     .vn
    │
 google.com
    │
 www.google.com
        ↓
    ⚠ Mỗi cấp chỉ biết cấp dưới
      kế tiếp ở đâu
    ⚠ Không có một máy chủ nào
      biết TẤT CẢ

⚠ Ba khái niệm mạng kia làm việc khác hẳn:

DHCP
    → ⚠ CẤP địa chỉ IP cho thiết bị
      khi nó vào mạng
    → không dịch tên

NAT
    → ⚠ DỊCH giữa IP nội bộ và
      IP công khai
    → cho nhiều máy dùng chung một IP

ISP
    → ⚠ nhà cung cấp dịch vụ Internet
    → là một công ty, không phải
      một giao thức

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

• A (DHCP) — phương án gần nhất về mặt "cũng liên quan tới địa chỉ IP", nhưng DHCP cấp phát IP cho thiết bị của bạn, không dịch tên miền thành IP.

• C (NAT) — dịch giữa địa chỉ nội bộ và công khai, chuyện hoàn toàn khác.

• B (ISP) — nhà cung cấp dịch vụ Internet, một doanh nghiệp chứ không phải hệ thống phân giải tên.

Ghi nhớ

⚠ Bốn khái niệm mạng cơ bản — bảng phải thuộc: | Khái niệm | Việc | |---|---| | DNS | ⚠ tên miền → địa chỉ IP | | DHCP | cấp IP cho thiết bị khi vào mạng | | NAT | dịch giữa IP nội bộ và công khai | | ISP | nhà cung cấp kết nối Internet |

Từ khoá nhận diện:

"danh bạ Internet, tên miền thành IP" → DNS "thiết bị tự nhận IP khi cắm mạng" → DHCP "nhiều máy chung một IP công khai" → NAT → Cloud NAT "quản lý tên miền trên Google Cloud" → Cloud DNS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản ghi hiện tại là gì | dig www.example.com | | Đổi đã lan chưa | hỏi nhiều resolver khác nhau | | TTL còn bao lâu | ⚠ hiện ngay trong kết quả dig |

Và một bước chuẩn bị rất đáng làm trước mọi lần chuyển hệ thống sang hạ tầng mới: hạ TTL của bản ghi xuống thấp vài ngày trước đó. Nếu không, ngày chuyển thật bạn sẽ đổi bản ghi trong vài giây rồi ngồi chờ hàng giờ để phần còn lại của thế giới nhận ra điều đó.

Đáp án

B — Cloud Run Functions.

Vì sao đúng

Đề nêu bốn đặc điểm, và chúng gộp lại chỉ về đúng mô hình hàm theo sự kiện:

⚠ Bốn đặc điểm ↔ Cloud Run Functions:

1. "MỖI KHI người dùng tải ảnh lên bucket"
     → ⚠ kích hoạt THEO SỰ KIỆN

2. "XỬ LÝ RẤT NHANH, NGẮN"
     → tạo ảnh thu nhỏ mất vài trăm ms

3. "TIẾT KIỆM CHI PHÍ NHẤT"
     → ⚠ trả theo thời gian chạy thật,
       không có ảnh thì 0 đồng

4. "SERVERLESS, HƯỚNG SỰ KIỆN"
     → đúng định nghĩa

⚠ Luồng xử lý:

Người dùng tải ảnh lên bucket
        ↓
Cloud Storage phát sự kiện `finalized`
        ↓
    Eventarc định tuyến
        ↓
Cloud Run Function chạy
    → đọc ảnh
    → thu nhỏ
    → ⚠ GHI SANG BUCKET KHÁC
        ↓
    Hàm kết thúc, tài nguyên thu hồi

⚠ Bẫy chết người của chính bài toán này:

Nếu ghi ảnh thu nhỏ vào
CHÍNH bucket đã kích hoạt hàm
        ↓
    ⚠ Ảnh thu nhỏ là một đối tượng MỚI
        ↓
    ⚠ Kích hoạt lại chính hàm đó
        ↓
    ⚠ VÒNG LẶP VÔ HẠN
        ↓
    Chữa:
    → ghi sang BUCKET KHÁC, hoặc
    → lọc theo TIỀN TỐ và bỏ qua
      ảnh đã thu nhỏ
    → ⚠ và luôn đặt `max-instances`

⚠ Gần trùng với #13315 (lô 139) — đề đó cũng là hàm chạy khi có tệp mới trong Cloud Storage, và 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 + tác vụ nhỏ + rẻ nhất → luôn là Cloud Run Functions.

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

• D (App Engine Standard) — phương án gần nhất vì cũng serverless và cũng co về 0. Nhưng nó là nền tảng cho ứng dụng web nhận request HTTP, không phải mô hình hàm gắn trực tiếp với sự kiện Cloud Storage.

• A (GKE) — cụm luôn chạy và luôn tính tiền; quá nặng và đắt cho một tác vụ vài trăm mili-giây.

• C (Compute Engine) — máy ảo chạy suốt ngày 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, ngắ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 |

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 trong container" → Cloud Run "theo lịch" → Cloud Scheduler kích hoạt "định tuyến sự kiện" → Eventarc

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

Và một quy tắc nên áp cho mọi hàm được 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

B — SecOps.

Vì sao đúng

Đề mô tả việc đưa kiểm tra bảo mật tự động vào thẳng đường ống CI/CD thay vì để một đội riêng rà soát ở cuối chu kỳ. Trong bốn phương án, SecOps là khái niệm duy nhất nói về hợp nhất bảo mật vào quy trình vận hành và phát triển.

⚠ Hai mô hình đối lập:

MÔ HÌNH CŨ — bảo mật ở CUỐI
  Phát triển → Kiểm thử → ⚠ RÀ SOÁT
                            BẢO MẬT
        ↓
    ⚠ Phát hiện lỗ hổng khi mọi thứ
      đã xây xong
    ⚠ Sửa lúc này RẤT ĐẮT
    ⚠ Đội bảo mật thành "người gác cổng
      hay nói không"

MÔ HÌNH MỚI — "SHIFT LEFT"
  Bảo mật ở MỌI bước:
    IDE → commit → build → test → deploy
        ↓
    ⚠ Quét phụ thuộc lúc build
    ⚠ Quét mã tĩnh khi commit
    ⚠ Quét image container
    ⚠ Kiểm cấu hình hạ tầng
        ↓
    → lập trình viên nhận phản hồi
      NGAY, khi sửa còn rẻ

⚠ Vì sao "sửa sớm thì rẻ":

Lỗ hổng phát hiện lúc viết mã
    → sửa trong vài phút

Phát hiện lúc kiểm thử
    → sửa trong vài giờ

⚠ Phát hiện sau khi lên production
    → xử lý sự cố, thông báo khách hàng,
      rủi ro pháp lý
        ↓
    ⚠ Chi phí tăng theo cấp số nhân
      theo từng giai đoạn

Ghi nhớ về chất lượng câu hỏi

Tên chuẩn của thực hành mà đề mô tả là DevSecOps (hoặc "shift-left security") — đưa bảo mật vào mọi giai đoạn của vòng đời phát triển, tự động hoá trong CI/CD.

DevSecOps KHÔNG có trong bốn phương án. Trong số được đưa ra, SecOps là khái niệm gần nhất và là lựa chọn đúng: nó cũng nói về việc hợp nhất bảo mật với vận hành thay vì tách rời.

Phân biệt cho chính xác khi làm bài:

• DevSecOps — bảo mật tích hợp vào quy trình PHÁT TRIỂN, tự động trong CI/CD (đúng nhất với đề)
• SecOps — bảo mật hợp nhất với VẬN HÀNH, thường gắn với SOC, phát hiện và ứng phó sự cố
• DevOps — triết lý gốc, hợp nhất phát triển và vận hành, không nói riêng về bảo mật

Khoá đáp án giữ nguyên là B. Quy tắc làm bài: chọn phương án phù hợp nhất CÓ TRONG DANH SÁCH.

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

• C (DevOps) — phương án gần nhất: DevSecOps là phần mở rộng của DevOps, nên DevOps đúng về tinh thần. Nhưng DevOps nói về hợp nhất phát triển và vận hành nói chung, không đặc biệt nói về bảo mật — mà bảo mật chính là trọng tâm của đề.

• A (Waterfall) — mô hình tuần tự, chính là thứ tạo ra kiểu rà soát bảo mật ở cuối mà đề muốn bỏ.

• D (ITIL) — khung quản lý dịch vụ CNTT theo quy trình, không phải về tích hợp bảo mật vào CI/CD.

Ghi nhớ

⚠ Bốn khái niệm dễ lẫn — bảng phải thuộc: | Khái niệm | Trọng tâm | |---|---| | DevOps | hợp nhất phát triển và vận hành | | DevSecOps | ⚠ + bảo mật tự động trong CI/CD (shift left) | | SecOps | ⚠ bảo mật hợp nhất với vận hành — SOC, phát hiện, ứng phó | | SRE | độ tin cậy — SLO, error budget |

Từ khoá nhận diện:

"quét bảo mật trong CI/CD, phản hồi ngay cho lập trình viên" → DevSecOps / SecOps "trung tâm điều hành an ninh, phát hiện và ứng phó" → SecOps / SOC "phá silo dev và ops" → DevOps "SLO và error budget" → SRE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường ống có quét không | xem các bước trong Cloud Build | | Lỗ hổng phát hiện được sửa sau bao lâu | ⚠ chỉ số "time to remediate" | | Có bí mật nào trong kho mã không | quét toàn bộ lịch sử Git |

Và một cân bằng cần giữ khi triển khai quét tự động: chặn build chỉ với những gì thật sự nghiêm trọng. Một đường ống báo đỏ vì hàng trăm lỗ hổng mức thấp sẽ nhanh chóng bị cả đội học cách bỏ qua — và khi đó lỗ hổng nghiêm trọng thật sự cũng trôi qua cùng với chúng.

Đáp án

B — Cloud Spanner.

Vì sao đúng

Đề nêu ba yêu cầu, và chúng chỉ cùng tồn tại trong Spanner:

⚠ Ba yêu cầu ↔ Spanner:

1. PHỤC VỤ DỮ LIỆU NGƯỜI CHƠI TỪ
   KHẮP THẾ GIỚI, ĐỘ TRỄ THẤP
     → cấu hình đa vùng, bản sao
       gần người dùng

2. ⚠ NHẤT QUÁN MẠNH TOÀN CẦU
   CHO GIAO DỊCH MUA TRONG GAME
     → TrueTime, nhất quán ngoại

3. QUAN HỆ
     → SQL đầy đủ, giao dịch ACID

⚠ Vì sao "bán một vật phẩm hai lần" là bài toán nhất quán:

Vật phẩm giới hạn còn 1 cái
        ↓
    Người chơi ở Tokyo bấm mua
    Người chơi ở London bấm mua
    cùng lúc
        ↓
    Nếu chỉ NHẤT QUÁN CUỐI CÙNG
        ↓
    ⚠ Cả hai máy chủ đều thấy
      "còn 1 cái"
    ⚠ Cả hai đều bán
        ↓
    → bán hai lần, phải hoàn tiền,
      người chơi mất niềm tin

    Spanner: giao dịch nguyên tử
    xuyên vùng
        ↓
    → chỉ một người mua được,
      người kia thấy "hết hàng"

⚠ TrueTime — thứ khiến điều này khả thi:

Đồng hồ nguyên tử + máy thu GPS
ở mọi trung tâm dữ liệu Google
        ↓
    Mọi giao dịch có DẤU THỜI GIAN
    đáng tin trên toàn cầu
        ↓
    ⚠ Có thứ tự TOÀN CỤC thống nhất
    → nhất quán ngoại (external
      consistency), mức mạnh nhất

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

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

• C (Cloud SQL) — phương án gần nhất: quan hệ và ACID đúng, nhưng chỉ mở rộng dọc và không ghi được ở nhiều vùng. Người chơi ở nửa kia thế giới sẽ chịu độ trễ cao, và bản sao đọc chỉ nhất quán cuối cùng.

• A (BigQuery) — kho phân tích, độ trễ tính bằng giây. Không phục vụ giao dịch mua bán được.

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

Ghi nhớ

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

Từ khoá nhận diện:

"quan hệ + toàn cầu + nhất quán mạnh" → ⚠ Spanner, luôn luôn "bán quá số lượng, trừ tiền hai lần" → cần nhất quán mạnh → Spanner "một vùng, MySQL" → Cloud SQL "trạng thái người chơi đọc rất nhanh, không cần giao dịch" → Bigtable hoặc Memorystore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CPU có quá tải không | ⚠ giữ dưới 65% cho đa vùng | | Có hotspot khoá không | Key Visualizer | | Độ trễ ở từng vùng | metric theo vùng trong Cloud Monitoring |

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

Đáp án

B — Dự án 1: Cloud Bigtable; Dự án 2: BigQuery.

Vì sao đúng

Hai dự án là hai loại tải công việc đối lập nhau, và đề đã mô tả rất rõ từng cái.

⚠ Dự án 1 — IoT:

"hàng triệu điểm dữ liệu CHUỖI THỜI GIAN
 mỗi phút"
"đọc/ghi CỰC NHANH (dưới 10ms)"
"trạng thái của TỪNG thiết bị"
        ↓
    ⚠ Ghi rất nhiều, đọc theo khoá
    ⚠ Chuỗi thời gian
    ⚠ Độ trễ mili-giây
        ↓
    → CLOUD BIGTABLE

⚠ Dự án 2 — BI:

"SQL PHỨC TẠP"
"hàng TERABYTE dữ liệu LỊCH SỬ"
"tìm XU HƯỚNG"
        ↓
    ⚠ Ít truy vấn nhưng quét rất nhiều
    ⚠ Độ trễ giây là chấp nhận được
        ↓
    → BIGQUERY

⚠ Đây là cặp đôi kinh điển:

BIGTABLE                BIGQUERY
đọc/ghi NÓNG            phân tích NGUỘI
theo khoá               quét toàn bảng
mili-giây               giây
OLTP-ish                OLAP
        ↓
    ⚠ Không cạnh tranh nhau —
      BỔ SUNG cho nhau
        ↓
    Kiến trúc thật thường có CẢ HAI:
      thiết bị → Pub/Sub → Dataflow
        ├── Bigtable  (trạng thái mới nhất)
        └── BigQuery  (lịch sử để phân tích)

⚠ Vì sao các cặp khác sai:

"Cloud SQL cho dự án 1"
    → ⚠ không chịu nổi hàng triệu
      điểm mỗi phút

"BigQuery cho dự án 1"
    → ⚠ độ trễ GIÂY, không phải
      dưới 10ms

"Bigtable cho dự án 2"
    → ⚠ KHÔNG có SQL đầy đủ,
      không join, quét toàn bảng chậm

"Cloud SQL cho dự án 2"
    → ⚠ không quét nổi hàng terabyte

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

• A (Cloud SQL rồi BigQuery) — phương án gần nhất: đúng dự án 2, nhưng Cloud SQL không chịu nổi tốc độ ghi mà dự án 1 yêu cầu.

• C (BigQuery rồi Bigtable) — đảo ngược hoàn toàn hai vai.

• D (Spanner rồi Cloud SQL) — Spanner mạnh nhưng đắt và thừa cho dữ liệu IoT không cần giao dịch; Cloud SQL không phân tích được hàng terabyte.

Ghi nhớ

⚠ Chọn CSDL theo tải — bảng phải thuộc: | Tải | Chọn | |---|---| | Chuỗi thời gian, IoT, thông lượng lớn, mili-giây | ⚠ Bigtable | | Phân tích, SQL trên terabyte | ⚠ BigQuery | | Giao dịch quan hệ một vùng | Cloud SQL | | Giao dịch quan hệ toàn cầu | Spanner | | Ứng dụng di động, ngoại tuyến | Firestore |

Từ khoá nhận diện:

"IoT, cảm biến, chuỗi thời gian, dưới 10ms" → Bigtable "xu hướng, lịch sử, SQL phức tạp" → BigQuery "trạng thái mới nhất của từng thiết bị" → Bigtable "báo cáo tháng trước" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bigtable có hotspot không | Key Visualizer | | Truy vấn BigQuery quét bao nhiêu | ⚠ xem ước tính trước khi chạy | | Có cần giữ dữ liệu thô mãi không | đặt vòng đời và bảng tổng hợp |

Và một mẫu kiến trúc đáng ghi nhớ cho mọi hệ thống IoT: cùng một luồng dữ liệu ghi vào hai đích khác nhau, phục vụ hai câu hỏi khác nhau. "Thiết bị số 4712 đang thế nào?" là câu hỏi cho Bigtable; "nhiệt độ trung bình quý này có tăng không?" là câu hỏi cho BigQuery — và cố ép một hệ thống trả lời cả hai luôn là quyết định tốn kém.

Đáp án

B — Cloud-native (bản địa đám mây).

Vì sao đúng

Đề liệt kê đúng bốn đặc trưng của một ứng dụng cloud-native, và cả bốn đều xuất hiện trong định nghĩa chính thức của khái niệm này.

⚠ Bốn đặc trưng trong đề:

1. KIẾN TRÚC MICROSERVICES
     → chia thành dịch vụ nhỏ,
       triển khai độc lập

2. ĐÓNG GÓI TRONG CONTAINER
     → chạy nhất quán ở mọi môi trường

3. QUẢN LÝ BỞI KUBERNETES
     → điều phối khai báo, tự chữa lành

4. ⚠ DÙNG DỊCH VỤ CÓ QUẢN LÝ
   (Pub/Sub, Cloud SQL)
     → không tự dựng lại hạ tầng
        ↓
    → CLOUD-NATIVE

⚠ Cloud-native khác "chạy trên đám mây":

LIFT AND SHIFT
  Ứng dụng khối chạy trên VM đám mây
        ↓
    ⚠ Ở TRÊN đám mây nhưng
      KHÔNG tận dụng được đám mây
    ⚠ Vẫn mở rộng dọc
    ⚠ Vẫn phải quản hệ điều hành

CLOUD-NATIVE
  Thiết kế TỪ ĐẦU cho đám mây
        ↓
    ⚠ Mở rộng ngang tự động
    ⚠ Chịu lỗi bằng dư thừa
    ⚠ Triển khai độc lập từng phần
    ⚠ Dùng dịch vụ có quản lý

⚠ Bốn trụ cột theo CNCF:

CONTAINER      → đóng gói nhất quán
MICROSERVICES  → chia nhỏ, độc lập
⚠ DECLARATIVE API → khai trạng thái
                    mong muốn
⚠ IMMUTABLE INFRASTRUCTURE
                 → không sửa, thay mới
        ↓
    Cộng thêm: CI/CD, quan sát được,
    thiết kế chịu lỗi

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

• C (lift and shift) — phương án gần nhất về mặt "cũng nói về ứng dụng trên đám mây", nhưng nó là chiến lược DI CƯ giữ nguyên kiến trúc cũ. Đề mô tả một kiến trúc được thiết kế cho đám mây, ngược hẳn.

• A (monolithic) — ứng dụng khối duy nhất, trái ngược với microservices mà đề nêu.

• D (on-premises) — chạy trên hạ tầng riêng tại chỗ.

Ghi nhớ

⚠ Đặc trưng của ứng dụng cloud-native — bảng nên thuộc: | Đặc trưng | Nội dung | |---|---| | Microservices | dịch vụ nhỏ, triển khai độc lập | | Container | ⚠ đóng gói cùng phụ thuộc | | Điều phối | Kubernetes / Cloud Run | | Dịch vụ có quản lý | ⚠ đừng tự dựng lại CSDL, hàng đợi | | Khai báo và bất biến | không sửa máy đang chạy | | Không trạng thái | trạng thái để ở kho ngoài | | CI/CD tự động | | | Quan sát được | log, metric, trace |

Từ khoá nhận diện:

"microservices + container + Kubernetes + dịch vụ có quản lý" → cloud-native "bê nguyên lên VM" → lift and shift / rehost "một khối duy nhất" → monolithic "tái cấu trúc cho đám mây" → refactor → dẫn tới cloud-native

Ba câu hỏi kiểm chứng: | Câu hỏi | Nếu... | |---|---| | Có thể triển khai một dịch vụ mà không đụng dịch vụ khác không | không → chưa thật sự microservices | | Mất một instance có ảnh hưởng người dùng không | có → chưa chịu lỗi tốt | | Có lần theo được một request qua nhiều dịch vụ không | không → thiếu quan sát |

Và một điều đáng nói thẳng về cloud-native: nó là phương tiện, không phải mục tiêu. Một ứng dụng khối chạy ổn định trên Cloud Run và dùng Cloud SQL có thể phục vụ doanh nghiệp tốt hơn nhiều so với ba mươi microservice mà không ai trong đội gỡ lỗi nổi khi có sự cố.