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

Đáp án

B — FinOps.

Vì sao đúng

FinOps là thực hành quản trị tài chính cho đám mây: đội tài chính, kỹ thuật và kinh doanh cùng nhau cân nhắc giữa chi phí, tốc độ và chất lượng.

⚠ Vì sao FinOps ra đời:

Thời tại chỗ
    → ⚠ chi tiêu là quyết định
      MỘT LẦN, do tài chính duyệt

Thời đám mây
    → ⚠ MỖI KỸ SƯ đều có thể tạo
      tài nguyên tốn tiền
    → ⚠ chi tiêu diễn ra HẰNG NGÀY
        ↓
    ⚠ Tài chính không thể duyệt
      từng dòng
    ⚠ Kỹ sư không thấy hoá đơn
        ↓
    → ⚠ FinOps: đưa hai bên lại,
      cho kỹ sư THẤY chi phí của
      quyết định mình

⚠ Ba giai đoạn của FinOps:

⚠ INFORM (thông tin)
    → ⚠ gán nhãn, chia chi phí về
      từng đội, dashboard

⚠ OPTIMIZE (tối ưu)
    → giảm cỡ máy, cam kết sử dụng,
      Spot VM, tắt tài nguyên rảnh

⚠ OPERATE (vận hành)
    → ⚠ đưa vào quy trình đều đặn,
      đặt mục tiêu, rà soát hằng tháng

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

"DevOps"   → ⚠ phát triển + vận hành
"SecOps"   → ⚠ bảo mật + vận hành
"Agile"    → ⚠ phương pháp phát triển
             phần mềm lặp ngắn

Nhất quán với #13486 (lô 143) về DevOps là hợp tác giữa hai bộ phận — FinOps là mô hình tương tự, áp cho tài chính.

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

• D (DevOps) — phương án gần nhất vì cùng mô hình "phá bỏ rào cản giữa hai bộ phận", nhưng DevOps kết nối phát triển và vận hành, không phải tài chính và kỹ thuật.

• C (SecOps) — bảo mật.

• A (Agile) — cách tổ chức công việc phát triển.

Ghi nhớ

⚠ Bốn từ "…Ops" — bảng phải thuộc: | Từ | Ghép ai với ai | Mục tiêu | |---|---|---| | ⚠ FinOps | ⚠ tài chính + kỹ thuật | ⚠ cân đối chi phí, tốc độ, chất lượng | | DevOps | phát triển + vận hành | ⚠ giao hàng nhanh và ổn định | | DevSecOps | ⚠ thêm bảo mật vào CI/CD | ⚠ shift-left | | MLOps | ML + vận hành | ⚠ vòng đời mô hình |

Từ khoá nhận diện:

"quản trị tài chính đám mây" → ⚠ FinOps "phá rào giữa dev và ops" → DevOps "quét bảo mật trong CI/CD" → ⚠ DevSecOps "đưa mô hình ML vào sản xuất" → MLOps

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí tháng này thuộc về đội nào | ⚠ có nhãn chưa — thiếu thì bắt đầu từ đây | | Có gì chạy mà không ai dùng | ⚠ Recommender + xem số instance ban đêm | | Ai nhận cảnh báo ngân sách | ⚠ phải là người có thể HÀNH ĐỘNG |

Và điều dễ hiểu nhầm nhất về ngân sách trên Google Cloud: cảnh báo ngân sách chỉ gửi thông báo, nó không dừng chi tiêu. Muốn có trần cứng thì phải dùng quota, hoặc dựng cơ chế tự tắt tài nguyên — chứ một cái email lúc ba giờ sáng không ngăn được cụm máy nào cả.

Đáp án

D — Dữ liệu có cấu trúc tuân theo một mô hình định trước (như bảng có hàng và cột), còn dữ liệu phi cấu trúc thì không.

Vì sao đúng

Ranh giới nằm ở có schema định sẵn hay không — chứ không nằm ở kích thước, kiểu chữ/số, hay việc dùng cho học máy.

⚠ Ba mức:

⚠ CÓ CẤU TRÚC
    → ⚠ bảng, hàng, cột, kiểu dữ liệu
      xác định trước
    → CSDL quan hệ, CSV, bảng BigQuery
    → ⚠ truy vấn bằng SQL

⚠ BÁN CẤU TRÚC
    → ⚠ có thẻ đánh dấu nhưng
      KHÔNG có schema cứng
    → JSON, XML, log

⚠ PHI CẤU TRÚC
    → ⚠ KHÔNG có mô hình định trước
    → ảnh, video, âm thanh, PDF,
      email, tài liệu tự do
    → ⚠ chiếm PHẦN LỚN dữ liệu
      của doanh nghiệp

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

"Có cấu trúc dùng cho học máy,
 phi cấu trúc thì không"
    → ⚠ SAI: ML dùng RẤT NHIỀU
      dữ liệu phi cấu trúc —
      ảnh, giọng nói, văn bản

"Có cấu trúc LUÔN LỚN HƠN"
    → ⚠ NGƯỢC: phi cấu trúc
      thường lớn hơn nhiều

"Có cấu trúc là CHỮ, phi cấu trúc
 LUÔN là SỐ"
    → ⚠ vô lý: bảng chứa cả số
      lẫn chữ; ảnh và video không
      phải "số"

Nhất quán với #13514 (lô 143) — đề đó về data lake chứa mọi loại dữ liệu, và #13495 (lô 143) về database và warehouse.

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

• A (có cấu trúc dùng cho ML) — phương án gần nhất về mặt "cũng nêu một khác biệt nghe hợp lý", nhưng sai: học máy hiện đại làm việc rất nhiều với ảnh, âm thanh và văn bản tự do.

• B (luôn lớn hơn) và C (chữ và số) — cả hai đều sai về bản chất.

Ghi nhớ

⚠ Ba loại dữ liệu — bảng phải thuộc: | Loại | Ví dụ | Lưu ở đâu | |---|---|---| | ⚠ Có cấu trúc | ⚠ bảng CSDL, CSV | Cloud SQL, BigQuery | | ⚠ Bán cấu trúc | ⚠ JSON, XML, log | ⚠ Firestore, BigQuery (JSON) | | ⚠ Phi cấu trúc | ⚠ ảnh, video, âm thanh, PDF | ⚠ Cloud Storage |

Từ khoá nhận diện:

"hàng và cột, schema định trước" → có cấu trúc "JSON, log, có thẻ nhưng không cứng" → bán cấu trúc "ảnh, video, tài liệu tự do" → ⚠ phi cấu trúc → Cloud Storage "chứa mọi loại ở mọi quy mô" → data lake

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Dữ liệu có schema cố định không | có → CSDL/kho; không → ⚠ hồ | | Cần truy vấn bằng SQL không | có → ⚠ BigQuery hoặc BigLake | | Tệp lớn cỡ nào | ⚠ lớn → Cloud Storage, đừng nhét vào CSDL |

Và mẫu thiết kế nên áp dụng mỗi khi ứng dụng cần lưu ảnh hay tệp đính kèm: để tệp trong Cloud Storage và chỉ giữ đường dẫn trong cơ sở dữ liệu. Nhồi dữ liệu nhị phân vào cột CSDL làm chậm sao lưu, tăng chi phí và khiến việc mở rộng khó hơn nhiều so với giá trị mà nó mang lại.

Đáp án

B — Bare Metal Solution.

Vì sao đúng

Đề nêu một ràng buộc rất cụ thể: giấy phép chỉ cho chạy trên máy chủ vật lý xác định, không hỗ trợ môi trường ảo hoá. Chỉ có một dịch vụ cung cấp phần cứng vật lý thật.

⚠ Bare Metal Solution là gì:

⚠ MÁY CHỦ VẬT LÝ THẬT
    → ⚠ KHÔNG có lớp ảo hoá
    → đặt trong cơ sở của Google,
      cạnh các vùng Google Cloud
        ↓
    ⚠ Kết nối độ trễ RẤT THẤP
      tới dịch vụ Google Cloud
        ↓
    → ⚠ đáp ứng ràng buộc giấy phép
      mà VẪN dùng được đám mây

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

"Compute Engine"
    → ⚠ là MÁY ẢO — đúng thứ
      giấy phép KHÔNG cho phép
    (⚠ dù có sole-tenant node,
     nó vẫn là ảo hoá)

"Cloud SQL"
    → ⚠ CSDL có quản lý, chỉ hỗ trợ
      MySQL, PostgreSQL, SQL Server

"Cloud Spanner"
    → ⚠ CSDL riêng của Google,
      không chạy phần mềm của bạn

Nhất quán với #13443 (lô 142) — cùng khoá Bare Metal Solution cho Oracle. Đối chiếu #13505 (lô 143) khoá hạ tầng SAP-certified. Cùng một nhóm ý: khối lượng công việc doanh nghiệp có ràng buộc đặc thù, khác giải pháp cụ thể. Không mâu thuẫn.

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

• C (Compute Engine) — phương án gần nhất vì cho toàn quyền trên hệ điều hành, nhưng nó vẫn là máy ảo, và đề nói rõ môi trường ảo hoá không được hỗ trợ.

• A (Cloud SQL) và D (Cloud Spanner) — không chạy được phần mềm CSDL thương mại của bên thứ ba.

Ghi nhớ

⚠ Thang hạ tầng — bảng phải thuộc: | Mức | Dịch vụ | Bạn kiểm soát | |---|---|---| | ⚠ Phần cứng vật lý | ⚠ Bare Metal Solution | ⚠ máy thật, không ảo hoá | | Máy chủ riêng | ⚠ Sole-tenant node | ⚠ vẫn là ảo hoá, nhưng không chia máy | | Máy ảo | Compute Engine | OS | | Container | GKE, Cloud Run | ứng dụng | | Có quản lý | Cloud SQL, BigQuery | dữ liệu |

Từ khoá nhận diện:

"giấy phép đòi máy vật lý, không ảo hoá" → ⚠ Bare Metal Solution "phải chạy riêng máy, không chia với ai" → ⚠ sole-tenant node "SAP, cần chứng nhận" → hạ tầng SAP-certified "giữ nguyên vSphere" → VMware Engine

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Giấy phép có cấm ảo hoá không | có → ⚠ Bare Metal Solution | | Có bản thay thế có quản lý không | có → ⚠ cân nhắc Replatform | | Chi phí so với tại chỗ ra sao | ⚠ so TCO đầy đủ |

Và đáng cân nhắc trước khi chốt phương án bare metal: ràng buộc ở đây là hợp đồng giấy phép, không phải kỹ thuật. Đôi khi việc đàm phán lại điều khoản, hoặc chuyển sang một cơ sở dữ liệu có quản lý, rẻ hơn nhiều so với việc duy trì cả một tầng phần cứng vật lý chỉ để làm hài lòng một dòng trong hợp đồng cũ.

Đáp án

A — Traffic (lưu lượng).

Vì sao đúng

Trong bốn tín hiệu vàng, Traffic chính là thước đo nhu cầu đang đặt lên dịch vụ — bao nhiêu request đang tới.

⚠ Bốn tín hiệu và câu hỏi mỗi cái trả lời:

⚠ TRAFFIC
    → ⚠ "CÓ BAO NHIÊU NHU CẦU?"
    → request/giây, kết nối/giây
    → ⚠ ĐỀ NÀY

LATENCY
    → "phục vụ MẤT BAO LÂU?"

ERRORS
    → "bao nhiêu phần THẤT BẠI?"

SATURATION
    → ⚠ "hệ thống ĐẦY tới đâu?"

⚠ Vì sao tình huống trong đề rất điển hình:

Traffic tăng vọt
        ↓
    ⚠ Saturation tăng theo
      (CPU, kết nối gần cạn)
        ↓
    ⚠ Latency bắt đầu tăng
        ↓
    ⚠ Nếu không xử lý:
      Errors tăng (timeout)
        ↓
    → ⚠ bốn tín hiệu KỂ MỘT
      CÂU CHUYỆN theo thứ tự

Đề hỏi riêng cái đo nhu cầu, nên đáp án là Traffic — dù triệu chứng người dùng thấy là latency.

Nhất quán với #13522 (cùng lô) — đề đó hỏi tên gọi của cả bốn tín hiệu, đề này hỏi một tín hiệu cụ thể. Cùng khung, hoàn toàn nhất quán.

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

• D (Latency) — phương án gần nhất vì đề có nhắc tới độ trễ tăng, nhưng đó là triệu chứng; câu hỏi là cái nào đo nhu cầu.

• B (Saturation) — đo mức đầy của tài nguyên, là hệ quả của nhu cầu chứ không phải bản thân nhu cầu.

• C (Errors) — đo tỉ lệ thất bại.

Ghi nhớ

⚠ Bốn tín hiệu vàng — bảng phải thuộc: | Tín hiệu | Đo gì | Ví dụ chỉ số | |---|---|---| | ⚠ Traffic | ⚠ NHU CẦU | ⚠ request/giây, QPS | | ⚠ Latency | ⚠ thời gian phục vụ | ⚠ p50, p95, p99 | | ⚠ Errors | ⚠ tỉ lệ thất bại | % mã 5xx | | ⚠ Saturation | ⚠ mức đầy | ⚠ % CPU, % kết nối đã dùng |

Từ khoá nhận diện:

"nhu cầu đặt lên dịch vụ" → ⚠ Traffic "phục vụ mất bao lâu" → Latency "bao nhiêu request hỏng" → Errors "tài nguyên còn bao nhiêu" → ⚠ Saturation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đỉnh lưu lượng năm ngoái là bao nhiêu | ⚠ xem lại dữ liệu, đừng đoán | | Hệ thống chịu được tới đâu | ⚠ thử tải tới điểm gãy | | Nút thắt nằm ở đâu | ⚠ thường là CSDL hoặc quota |

Và bài học rút ra từ chuỗi nhân quả này: khi người dùng bắt đầu phàn nàn về độ trễ, tín hiệu đáng nhìn đầu tiên không phải độ trễ. Traffic và saturation đã kể trước câu chuyện đó vài phút — và đó chính là khoảng thời gian dùng để can thiệp kịp.

Đáp án

B — Google Kubernetes Engine (GKE).

Vì sao đúng

Đề mô tả chính xác mô hình GKE Standard: control plane do Google quản lý hoàn toàn, nhưng bạn tự cấu hình và quản node pool để có độ linh hoạt tối đa.

⚠ Chia trách nhiệm trong GKE:

⚠ GOOGLE LO — control plane
    → API server, etcd, scheduler
    → ⚠ vá lỗi, nâng cấp, HA
    → ⚠ bạn không thấy máy nào

⚠ BẠN LO — node pool (Standard)
    → ⚠ chọn loại máy, số node
    → GPU, Spot VM, ổ đĩa
    → ⚠ taint, label, autoscaling
      riêng từng pool

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

"Cloud Run"
    → ⚠ chạy container rất tốt
    → ⚠ nhưng KHÔNG có node pool
      để cấu hình — đó là điểm
      mạnh của nó, không hợp đề này

"Compute Engine"
    → ⚠ máy ảo trần, ⚠ KHÔNG có
      control plane Kubernetes
      được quản lý

"App Engine Flexible"
    → ⚠ PaaS chạy container, nhưng
      không cho quản node pool
      kiểu Kubernetes

Nhất quán với #13515 (lô 143) — cùng khoá GKE khi đề đòi kiểm soát cụm và node pool. Đối chiếu #13519 (cùng lô) khoá Cloud Run vì đề đó chỉ cần "đưa image, tự chạy". Không mâu thuẫn — mức kiểm soát yêu cầu khác nhau.

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

• A (Cloud Run) — phương án gần nhất vì cùng chạy container có quản lý, nhưng nó cố tình giấu node và cụm.

• C (Compute Engine) — bạn phải tự cài và tự vận hành cả Kubernetes.

• D (App Engine Flexible) — không cho kiểm soát ở mức node pool.

Ghi nhớ

⚠ Standard và Autopilot — bảng phải thuộc: | | GKE Standard | GKE Autopilot | |---|---|---| | Control plane | ⚠ Google quản | ⚠ Google quản | | ⚠ Node | ⚠ BẠN quản — đề này | ⚠ Google quản | | Tính tiền | ⚠ theo NODE | ⚠ theo POD yêu cầu | | Linh hoạt | ⚠ cao nhất | ⚠ có giới hạn | | Hợp với | ⚠ cần GPU, cấu hình đặc thù | ⚠ muốn ít việc vận hành |

Từ khoá nhận diện:

"control plane có quản lý, tự quản node" → ⚠ GKE Standard "container nhưng không muốn quản gì" → Cloud Run "Kubernetes nhưng không muốn quản node" → ⚠ GKE Autopilot "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ó thật sự cần cấu hình node không | không → ⚠ Autopilot hoặc Cloud Run | | Có workload cần GPU không | có → Standard | | Ai vận hành cụm ngoài giờ | ⚠ không rõ → chọn mức trừu tượng cao hơn |

Và câu hỏi phân biệt nhanh nhất giữa GKE Standard và Autopilot: đội có ai thật sự muốn chọn loại máy cho node không? Nếu câu trả lời là "miễn nó chạy", thì mọi công sức bỏ ra để quản node pool là chi phí thuần — Autopilot lo phần đó tốt hơn.

Đáp án

D — Multi-cloud (đa đám mây).

Vì sao đúng

Multi-cloud là chiến lược dùng nhiều nhà cung cấp đám mây CÔNG CỘNG cùng lúc, chọn dịch vụ tốt nhất từ mỗi bên — đúng mô tả của đề.

⚠ Bốn mô hình triển khai — phân biệt bằng NƠI ĐẶT:

⚠ PUBLIC CLOUD
    → hạ tầng dùng chung của
      nhà cung cấp

⚠ PRIVATE CLOUD
    → ⚠ hạ tầng RIÊNG của một
      tổ chức, tại chỗ hoặc thuê

⚠ HYBRID CLOUD
    → ⚠ TẠI CHỖ (hoặc private)
      KẾT HỢP với đám mây công cộng

⚠ MULTI-CLOUD
    → ⚠ NHIỀU đám mây CÔNG CỘNG
    → ⚠ ĐỀ NÀY

⚠ Điểm phân biệt then chốt:

HYBRID
    → ⚠ có yếu tố TẠI CHỖ

MULTI-CLOUD
    → ⚠ TOÀN đám mây công cộng,
      chỉ khác NHÀ CUNG CẤP

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

"Private Cloud"
    → ⚠ hạ tầng riêng một tổ chức

"Hybrid Cloud"
    → ⚠ đề KHÔNG nhắc tới tại chỗ

"On-premises"
    → ⚠ hoàn toàn không phải đám mây

Đối chiếu #13517 (cùng lô) về chống khoá chân bằng TensorFlow — multi-cloud là một chiến lược khác cho cùng mối lo. Không mâu thuẫn.

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

• B (Hybrid Cloud) — phương án gần nhất và là bẫy chính: hai khái niệm rất hay bị nhầm. Hybrid bắt buộc có yếu tố tại chỗ hoặc private, mà đề chỉ nói tới nhiều nhà cung cấp công cộng.

• A (Private Cloud) và C (On-premises) — không phải mô hình đang được mô tả.

Ghi nhớ

⚠ Bốn mô hình — bảng phải thuộc: | Mô hình | Định nghĩa | |---|---| | Public | ⚠ hạ tầng dùng chung của nhà cung cấp | | Private | ⚠ hạ tầng riêng một tổ chức | | ⚠ Hybrid | ⚠ tại chỗ/private + công cộng | | ⚠ Multi-cloud | ⚠ NHIỀU nhà cung cấp công cộng |

Từ khoá nhận diện:

"nhiều nhà cung cấp công cộng" → ⚠ multi-cloud "trung tâm dữ liệu riêng + đám mây" → ⚠ hybrid "quản lý K8s ở nhiều nơi bằng một mặt phẳng" → ⚠ Anthos / GKE Enterprise "truy vấn dữ liệu ở đám mây khác" → ⚠ BigQuery Omni

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Lý do nghiệp vụ là gì | ⚠ không rõ thì đừng làm | | Dữ liệu đi qua lại bao nhiêu | ⚠ phí egress là khoản hay bị bỏ sót | | Ai vận hành phía nào | ⚠ kỹ năng phải có thật |

Và lý do phổ biến nhất khiến một doanh nghiệp trở thành multi-cloud trong thực tế: không phải một quyết định chiến lược nào cả, mà là một vụ sáp nhập. Khi đó câu hỏi không còn là "có nên multi-cloud không" mà là "quản lý nó cho gọn bằng cách nào" — và đó đúng là bài toán mà Anthos và BigQuery Omni sinh ra để giải.

Đáp án

C — Cloud Functions.

Vì sao đúng

Đề mô tả đúng bài toán của Cloud Functions: một script Python duy nhất, chạy mỗi đêm một lần, cần rẻ nhất, serverless, không quản hạ tầng.

⚠ Vì sao Cloud Functions hợp nhất:

"MỘT script Python"
    → ⚠ đơn vị triển khai của
      Cloud Functions đúng là MỘT HÀM
    → ⚠ không phải đóng gói container

"chạy MỘT LẦN mỗi đêm"
    → ⚠ 23 giờ 59 phút còn lại
      KHÔNG trả đồng nào

"RẺ NHẤT, không quản hạ tầng"
    → ⚠ serverless, co về 0

⚠ Dựng lịch chạy hằng đêm:

⚠ Cloud Scheduler (cron)
        ↓
    ⚠ Pub/Sub hoặc gọi HTTP
        ↓
    ⚠ Cloud Function chạy script
        ↓
    xong thì tắt

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

"Compute Engine"
    → ⚠ máy ảo chạy 24/7 để dùng
      vài phút mỗi đêm
    → ⚠ lãng phí, và phải tự vá OS

"GKE"
    → ⚠ cả một cụm cho một script:
      quá nặng và quá đắt

"Bare Metal Solution"
    → ⚠ máy chủ vật lý — xa nhất
      với "serverless, rẻ nhất"

Đối chiếu #13519 (cùng lô) khoá Cloud Run — đề đó nói rõ "đã đóng gói thành container". Đề này nói "một script Python". Không mâu thuẫn — khác đơn vị triển khai.

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

• A (Compute Engine) — phương án gần nhất vì chắc chắn chạy được script, nhưng bạn trả tiền cho máy suốt cả ngày và vẫn phải tự vận hành nó.

• D (GKE) và B (Bare Metal Solution) — nặng nề và tốn kém hơn nhiều so với nhu cầu.

Ghi nhớ

⚠ Bốn lựa chọn tính toán theo đơn vị triển khai: | Dịch vụ | Đơn vị | Hợp với | |---|---|---| | ⚠ Cloud Functions | ⚠ MỘT HÀM | ⚠ script nhỏ, phản ứng sự kiện | | Cloud Run | ⚠ container | ⚠ ứng dụng web, API | | GKE | pod trên cụm | nhiều dịch vụ, cần kiểm soát | | Compute Engine | máy ảo | ⚠ cần toàn quyền OS |

Từ khoá nhận diện:

"một script, một hàm, chạy theo lịch" → ⚠ Cloud Functions "đã có container" → Cloud Run "tác vụ chạy rồi kết thúc, có container" → ⚠ Cloud Run jobs "chạy theo lịch" → ⚠ Cloud Scheduler kích hoạt

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Script chạy bao lâu | dài → ⚠ Cloud Run jobs | | Chạy hai lần có sao không | ⚠ phải làm idempotent | | Ai biết khi nó hỏng | ⚠ dựng cảnh báo — việc chạy đêm hỏng rất dễ bị bỏ qua |

Và rủi ro thật sự của mọi tác vụ chạy hằng đêm không nằm ở việc chọn dịch vụ nào, mà ở chỗ: khi nó âm thầm ngừng chạy, có thể vài tuần sau mới có người phát hiện. Một cảnh báo khi tác vụ không báo cáo thành công đúng giờ đáng giá hơn mọi tối ưu chi phí ở đây.

Đáp án

A — DevOps và Site Reliability Engineering (SRE).

Vì sao đúng

Cả hai phong trào đều dựa trên cùng một niềm tin: thất bại là điều tất yếu, nên hãy đầu tư vào phục hồi nhanh thay vì cố ngăn mọi sự cố.

⚠ Vì sao tư duy này dẫn tới đổi mới nhanh:

"Không được phép hỏng"
        ↓
    ⚠ mỗi lần phát hành thành
      sự kiện lớn, phải duyệt nhiều
        ↓
    ⚠ phát hành THƯA và TO
        ↓
    ⚠ thay đổi to thì rủi ro CAO hơn
        ↓
    ⚠ càng sợ, càng thưa — vòng xoáy

"Hỏng là chuyện bình thường"
        ↓
    ⚠ đầu tư vào phát hiện nhanh,
      quay lui nhanh
        ↓
    ⚠ phát hành NHỎ và THƯỜNG XUYÊN
        ↓
    ⚠ mỗi thay đổi nhỏ, dễ sửa

⚠ Cơ chế cụ thể của hai phong trào:

DEVOPS
    → CI/CD tự động
    → ⚠ phát hành nhỏ, thường xuyên
    → ⚠ quay lui dễ dàng

SRE
    → ⚠ SLO và ERROR BUDGET
    → ⚠ hậu kiểm KHÔNG QUY TỘI
    → ⚠ giảm việc thủ công bằng
      tự động hoá

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

"ITIL và PRINCE2"
    → ⚠ khung quản trị theo quy trình,
      thiên về kiểm soát thay đổi

"FinOps và SecOps"
    → ⚠ chi phí và bảo mật, không
      phải về chấp nhận thất bại

"Waterfall và Six Sigma"
    → ⚠ Waterfall: kế hoạch cứng
    → ⚠ Six Sigma: LOẠI BỎ khuyết tật —
      gần như NGƯỢC với ý đề

Nhất quán với #13486 (lô 143) về DevOps là hợp tác, và #13478 (lô 143) về ưu tiên độ tin cậy khi vượt ngân sách lỗi.

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

• D (Waterfall và Six Sigma) — phương án gần nhất vì cũng là hai phương pháp có tên tuổi, nhưng Six Sigma hướng tới giảm khuyết tật về gần không, tức là triết lý ngược lại.

• B (ITIL và PRINCE2) và C (FinOps và SecOps) — không phải về chủ đề này.

Ghi nhớ

⚠ Bốn chỉ số DORA — thước đo của DevOps: | Chỉ số | Đo gì | |---|---| | Deployment frequency | ⚠ phát hành bao nhiêu lần | | Lead time for changes | từ commit tới sản xuất | | ⚠ Change failure rate | ⚠ bao nhiêu % phát hành gây sự cố | | ⚠ Time to restore (MTTR) | ⚠ phục hồi mất bao lâu — trọng tâm đề này |

Từ khoá nhận diện:

"thất bại là bình thường, phục hồi nhanh" → ⚠ DevOps và SRE "phần trăm được phép hỏng" → ⚠ error budget "hậu kiểm không quy tội" → ⚠ blameless postmortem "giảm việc lặp thủ công" → ⚠ toil reduction

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Quay lui mất bao lâu | ⚠ thử thật, đừng giả định | | Sự cố gần nhất có hậu kiểm không | ⚠ có quy tội ai không | | Phát hành bao lâu một lần | ⚠ thưa thường là dấu hiệu của SỢ |

Và phép thử ngắn nhất cho văn hoá mà đề nói tới: hỏi xem đội mất bao lâu để quay lui một lần phát hành hỏng. Nếu câu trả lời tính bằng phút, nỗi sợ phát hành sẽ tự biến mất; nếu tính bằng giờ, thì mọi lời kêu gọi đổi mới nhanh đều sẽ vấp phải một nỗi sợ hoàn toàn có cơ sở.

Đáp án

B — Clustering (Topic Modeling) — phân cụm.

Vì sao đúng

Dữ kiện quyết định nằm ở cụm từ "không có danh mục định trước": không có nhãn thì không thể huấn luyện mô hình phân loại. Việc tự nhóm các đánh giá theo nội dung là học không giám sát.

⚠ Có nhãn hay không — ranh giới quyết định:

CÓ nhãn sẵn
    → ⚠ HỌC CÓ GIÁM SÁT
    → phân loại, hồi quy

⚠ KHÔNG có nhãn
    → ⚠ HỌC KHÔNG GIÁM SÁT
    → ⚠ PHÂN CỤM — đề này
    → ⚠ mô hình TỰ tìm nhóm

⚠ Kết quả phân cụm trông thế nào:

Hàng nghìn đánh giá văn bản
        ↓
    ⚠ Mô hình gom thành các nhóm
      theo độ tương đồng nội dung
        ↓
    Nhóm 1: giao hàng chậm
    Nhóm 2: sản phẩm hỏng khi nhận
    Nhóm 3: khó dùng
        ↓
    ⚠ TÊN nhóm do NGƯỜI đặt sau
      khi đọc mẫu đại diện

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

"Classification"
    → ⚠ cần danh mục ĐỊNH TRƯỚC và
      dữ liệu đã gán nhãn — đề nói
      rõ là KHÔNG CÓ

"Regression"
    → ⚠ dự đoán một CON SỐ

"Anomaly Detection"
    → ⚠ tìm điểm BẤT THƯỜNG hiếm gặp,
      không phải gom nhóm toàn bộ

Đối chiếu #13430 (phân loại), #13465/#13406 (hồi quy), #13491 (phát hiện bất thường) — bộ bốn kỹ thuật đã đủ. Phân biệt bằng có nhãn không và đầu ra là gì. Hoàn toàn nhất quán.

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

• A (Classification) — phương án gần nhất và là bẫy chính: cả hai đều "chia dữ liệu thành nhóm". Khác biệt là phân loại cần nhãn định sẵn, còn ở đây chưa có danh mục nào.

• C (Regression) — cho đầu ra là số.

• D (Anomaly Detection) — tìm ngoại lệ.

Ghi nhớ

⚠ Bốn kỹ thuật — bảng phải thuộc: | Kỹ thuật | Có nhãn | Đầu ra | |---|---|---| | Classification | ⚠ CÓ | ⚠ danh mục định trước | | Regression | ⚠ CÓ | ⚠ một CON SỐ | | ⚠ Clustering | ⚠ KHÔNG | ⚠ nhóm do mô hình TỰ tìm | | Anomaly detection | thường không | ⚠ điểm bất thường |

Từ khoá nhận diện:

"không có danh mục định trước, tự gom nhóm" → ⚠ clustering "phân vào các loại đã biết" → classification "dự đoán doanh thu, giá, số lượng" → regression "giao dịch gian lận, cảm biến lạ" → anomaly detection

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có nhãn sẵn không | có → classification; không → ⚠ clustering | | Cụm tìm được có nghĩa không | ⚠ đọc mẫu — cụm vô nghĩa là chuyện thường | | Bao nhiêu cụm là hợp lý | ⚠ thử vài giá trị rồi đánh giá |

Và mẫu hình thường gặp nhất trong thực tế với bài toán này: phân cụm trước để tìm ra các chủ đề, rồi lấy chính chúng làm nhãn cho một bộ phân loại. Lúc đó việc gán chủ đề cho từng đánh giá mới trở thành bài toán có giám sát — nhanh hơn, ổn định hơn và đo được chất lượng.

Đáp án

D — Authentication (xác thực).

Vì sao đúng

Authentication = CHỨNG MINH BẠN LÀ AI. Đó là bước diễn ra trước tiên, trước khi hệ thống quyết định bạn được làm gì.

⚠ Hai từ luôn đi cặp — nhớ bằng câu hỏi:

⚠ AUTHENTICATION (AuthN)
    → ⚠ "BẠN LÀ AI?"
    → mật khẩu, khoá bảo mật,
      chứng chỉ, sinh trắc học
    → ⚠ diễn ra TRƯỚC
    → ⚠ ĐỀ NÀY

⚠ AUTHORIZATION (AuthZ)
    → ⚠ "BẠN ĐƯỢC LÀM GÌ?"
    → vai IAM, quyền
    → ⚠ diễn ra SAU khi đã xác thực

⚠ Ba yếu tố xác thực:

⚠ ĐIỀU BẠN BIẾT
    → mật khẩu, mã PIN

⚠ ĐIỀU BẠN CÓ
    → ⚠ khoá bảo mật, điện thoại,
      mã một lần

⚠ ĐIỀU BẠN LÀ
    → vân tay, khuôn mặt
        ↓
    ⚠ Kết hợp từ HAI yếu tố trở lên
      = MFA / xác thực đa yếu tố

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

"Authorization"
    → ⚠ bước SAU: được làm gì

"Encryption"
    → ⚠ BẢO VỆ dữ liệu bằng mã hoá,
      không xác minh ai

"Auditing"
    → ⚠ GHI LẠI ai đã làm gì —
      diễn ra sau cùng

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

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

• A (Authorization) — phương án gần nhất và là bẫy chính: hai khái niệm luôn đi cùng nhau. Nhưng đề nói rõ "chứng minh danh tính", đó là xác thực.

• B (Encryption) và C (Auditing) — thuộc các lớp bảo mật khác.

Ghi nhớ

⚠ Bốn khái niệm bảo mật — bảng phải thuộc: | Khái niệm | Câu hỏi | |---|---| | ⚠ Authentication | ⚠ "bạn LÀ AI?" | | ⚠ Authorization | ⚠ "bạn ĐƯỢC LÀM GÌ?" | | Auditing | ⚠ "ai ĐÃ LÀM GÌ?" | | Encryption | ⚠ "dữ liệu có bị đọc trộm không?" |

Từ khoá nhận diện:

"chứng minh danh tính, đăng nhập" → ⚠ authentication "được phép làm gì, vai, quyền" → authorization "nhật ký, ai đã thao tác" → ⚠ Cloud Audit Logs "mã hoá khi lưu và khi truyền" → encryption

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài khoản quản trị đã bật MFA chưa | ⚠ kiểm ngay, đây là ưu tiên số một | | Còn khoá service account tĩnh nào không | ⚠ liệt kê và thay dần | | Ai còn quyền mà đã nghỉ việc | ⚠ rà soát định kỳ |

Và thứ tự đúng luôn là xác thực trước, phân quyền sau — nhưng thứ tự ưu tiên khi siết bảo mật thì ngược lại với trực giác: bật xác thực đa yếu tố cho các tài khoản quản trị mang lại hiệu quả tức thì lớn hơn hầu hết mọi việc tinh chỉnh quyền hạn.