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

Đáp án

C — Ransomware (mã độc tống tiền).

Vì sao đúng

Đề mô tả đúng hai đặc trưng của ransomware: mã hoá tệp và đòi tiền chuộc để mở khoá.

⚠ Cách ransomware hoạt động:

1. XÂM NHẬP
     → phishing, lỗ hổng chưa vá,
       RDP/SSH mở ra Internet

2. LAN NGANG
     → ⚠ tìm thêm máy và bản sao lưu

3. ⚠ MÃ HOÁ
     → toàn bộ tệp trên máy chủ

4. ⚠ ĐÒI TIỀN CHUỘC
     → thường bằng tiền mã hoá

5. ⚠ ĐE DOẠ CÔNG BỐ DỮ LIỆU
     → "tống tiền kép" — xu hướng
       hiện nay

⚠ Phân biệt với ba loại kia:

ADWARE
    → ⚠ hiển thị quảng cáo không
      mong muốn
    → phiền chứ không phá hoại

SPYWARE
    → ⚠ LÉN thu thập thông tin
    → càng lâu càng có lợi cho
      kẻ tấn công → không phá hoại

VIRUS
    → ⚠ mã lây lan khi người dùng
      chạy tệp nhiễm
    → là CÁCH LÂY, không phải
      mục đích
        ↓
    ⚠ Ransomware có thể lây
      như virus, nhưng ĐẶC TRƯNG
      của nó là MÃ HOÁ + ĐÒI TIỀN

⚠ Vì sao ransomware phá cả ba trụ cột CIA:

⚠ CONFIDENTIALITY
    → kẻ tấn công đọc và doạ
      công bố dữ liệu

⚠ INTEGRITY
    → dữ liệu bị mã hoá,
      không còn dùng được

⚠ AVAILABILITY
    → dịch vụ ngừng hoạt động
        ↓
    → hiếm có loại tấn công nào
      phá đủ cả ba

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

• D (Virus) — phương án gần nhất và bị nhầm nhiều vì "virus" hay được dùng như từ chung cho mọi mã độc. Nhưng virus mô tả cách LÂY LAN (bám vào tệp, cần người chạy), còn đề mô tả mục đích: mã hoá và đòi tiền.

• B (Spyware) — lén thu thập thông tin; nó cần ở ẩn càng lâu càng tốt, ngược với việc mã hoá lộ liễu.

• A (Adware) — hiển thị quảng cáo; phiền toái chứ không phá hoại dữ liệu.

Ghi nhớ

⚠ Các loại malware — bảng nên thuộc: | Loại | Mục đích | |---|---| | ⚠ Ransomware | ⚠ mã hoá dữ liệu, đòi tiền chuộc | | Spyware | lén thu thập thông tin | | Adware | hiển thị quảng cáo | | Virus | ⚠ lây qua tệp, cần người chạy | | Worm | ⚠ tự lan qua mạng | | Trojan | giả dạng phần mềm hữu ích | | Cryptominer | ⚠ đào tiền bằng tài nguyên của bạn | | Rootkit | ẩn mình ở tầng sâu |

Từ khoá nhận diện:

"mã hoá dữ liệu, đòi tiền chuộc" → ransomware "lén theo dõi" → spyware "tự lan qua mạng" → worm "email giả lừa mật khẩu" → phishing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sao lưu có bất biến không | ⚠ Bucket Lock đã bật chưa | | Đã thử khôi phục bao giờ chưa | ⚠ bản sao lưu chưa thử là giả thiết | | Kẻ tấn công vào được thì lan tới đâu | rà quyền và phân đoạn mạng |

Và lớp phòng thủ cuối cùng quyết định một vụ ransomware là sự cố nhỏ hay thảm hoạ: bản sao lưu bất biến đã được thử khôi phục. Mọi biện pháp khác đều nhằm giảm xác suất bị tấn công; riêng bản sao lưu quyết định điều gì xảy ra khi xác suất đó thành hiện thực.

Đáp án

C — Regression (hồi quy).

Vì sao đúng

Đề nói thẳng manh mối quyết định: dự đoán một GIÁ TRỊ SỐ — doanh số dự kiến của một cửa hàng trong một ngày.

⚠ Manh mối trong đề:

"dự đoán một GIÁ TRỊ SỐ
 (numerical value)"
        ↓
    ⚠ đầu ra là một CON SỐ
      trong một khoảng liên tục
        ↓
    → REGRESSION

⚠ Phân biệt bốn loại bài toán:

⚠ REGRESSION
    → ⚠ đầu ra là SỐ LIÊN TỤC
    → doanh số, giá nhà, nhiệt độ
    → đề này

CLASSIFICATION
    → ⚠ đầu ra là NHÃN RỜI RẠC
    → huỷ / không huỷ, spam / không

CLUSTERING
    → ⚠ KHÔNG có nhãn
    → tự tìm nhóm tự nhiên

REINFORCEMENT LEARNING
    → ⚠ học qua THƯỞNG PHẠT
    → robot, game, điều khiển

⚠ Phép thử nhanh:

Câu hỏi: "Đầu ra là gì?"
        ↓
    Một SỐ bất kỳ trong một khoảng
        → ⚠ REGRESSION

    Một trong vài LỰA CHỌN cho sẵn
        → ⚠ CLASSIFICATION

    Không có đầu ra định trước
        → ⚠ CLUSTERING

⚠ Dự báo doanh số — trường hợp riêng:

Dự đoán doanh số THEO THỜI GIAN
        ↓
    ⚠ Đây là FORECASTING —
      một dạng đặc biệt của
      regression
        ↓
    Có yếu tố riêng:
      ⚠ mùa vụ, xu hướng, ngày lễ
        ↓
    Công cụ: ⚠ `ARIMA_PLUS` trong
    BigQuery ML, hoặc
    Vertex AI Forecasting

⚠ Gần trùng với #13406 (lô 141) — đề đó dự đoán giá nhà và cùng khoá Regression. Nhất quán.

⚠ Đối chiếu #13430 (cùng lô này) — đề đó dự đoán khách có huỷ đăng ký hay không và khoá Classification. Không mâu thuẫn — khác nhau ở kiểu đầu ra: SỐ hay NHÃN.

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

• D (Classification) — phương án gần nhất và là bẫy chính: nếu đề hỏi "cửa hàng này thuộc nhóm doanh số CAO / TRUNG BÌNH / THẤP" thì đúng là phân loại. Nhưng đề nói rõ đầu ra là giá trị số.

• B (Clustering) — không có nhãn; ở đây có dữ liệu doanh số thật để học.

• A (Reinforcement Learning) — học qua thưởng phạt trong môi trường tương tác; không phù hợp.

Ghi nhớ

⚠ Bốn loại bài toán ML — bảng phải thuộc: | Loại | Đầu ra | Ví dụ | |---|---|---| | ⚠ Regression | ⚠ SỐ liên tục | ⚠ doanh số, giá nhà | | Classification | NHÃN rời rạc | khách rời bỏ, spam | | Clustering | nhóm tự tìm | phân khúc khách hàng | | Forecasting | ⚠ số liên tục theo THỜI GIAN | ⚠ dự báo doanh số | | Reinforcement | chuỗi hành động | robot, game |

Từ khoá nhận diện:

"dự đoán một con số" → regression "dự đoán theo thời gian, mùa vụ" → ⚠ forecasting "thuộc nhóm nào" → classification "tự tìm nhóm" → clustering

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đầu ra là số hay nhãn | ⚠ quyết định loại bài toán | | Có tốt hơn "bằng cùng kỳ năm ngoái" không | ⚠ luôn cần đường cơ sở | | Sai số bao nhiêu là chấp nhận được | ⚠ hỏi bên nghiệp vụ |

Và một đường cơ sở luôn nên đo trước khi tự hào về mô hình dự báo doanh số: "doanh số hôm nay bằng doanh số cùng ngày tuần trước". Nó không cần mô hình nào cả, và nếu mô hình phức tạp không vượt được nó thì công sức bỏ ra chưa tạo ra giá trị.

Đáp án

A — Compute Engine.

Vì sao đúng

Đề hỏi dịch vụ tương đương TRỰC TIẾP của một máy ảo tại chỗ — và đó chính là Compute Engine.

⚠ Vì sao Compute Engine là tương đương trực tiếp:

Máy ảo tại chỗ
    → hệ điều hành riêng
    → quyền root
    → cài phần mềm tuỳ ý
    → đĩa gắn vào
        ↓
COMPUTE ENGINE
    ⚠ Chọn image OS bất kỳ
    ⚠ Quyền root, SSH/RDP
    ⚠ Cài phần mềm tuỳ ý
    ⚠ Persistent Disk
        ↓
    → chuyển được gần như
      NGUYÊN TRẠNG

⚠ Vì sao "lift and shift" đi với Compute Engine:

Lift and shift = REHOST
    → ⚠ thay đổi ÍT NHẤT có thể
        ↓
    ⚠ Ba phương án kia đều đòi
      THAY ĐỔI ứng dụng:

GKE
    → ⚠ phải ĐÓNG GÓI thành container
    → phải học Kubernetes

APP ENGINE
    → ⚠ phải theo runtime được hỗ trợ
    → có thể phải sửa mã

CLOUD FUNCTIONS
    → ⚠ phải VIẾT LẠI thành hàm
    → thay đổi lớn nhất

⚠ Công cụ di cư sẵn có:

⚠ MIGRATE TO VIRTUAL MACHINES
    → di cư VM từ VMware, AWS, Azure
    → sao chép dữ liệu trong lúc
      máy cũ vẫn chạy
    → cắt chuyển với thời gian
      ngừng rất ngắn
        ↓
    ⚠ Migration Center
      → kiểm kê và đánh giá TRƯỚC

Nhất quán với #13370 (lô 141) và #13280 (lô 139) — hai câu đó về chiến lược Rehost. Câu này hỏi sản phẩm nào thực hiện nó. Bổ sung cho nhau.

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

• C (GKE) — phương án gần nhất trong các lựa chọn hiện đại, nhưng nó đòi đóng gói ứng dụng thành container và vận hành Kubernetes — thay đổi lớn, trái với "lift and shift".

• D (App Engine) — PaaS, đòi ứng dụng phù hợp với runtime được hỗ trợ.

• B (Cloud Functions) — đòi viết lại thành hàm; thay đổi lớn nhất.

Ghi nhớ

⚠ Bản đồ tương đương khi di cư — bảng nên thuộc: | Tại chỗ | Google Cloud | |---|---| | ⚠ Máy ảo | ⚠ Compute Engine | | MySQL/PostgreSQL tự quản | Cloud SQL | | Hadoop/Spark | Dataproc | | Kafka | Pub/Sub | | Redis | Memorystore | | NFS chia sẻ | Filestore | | Kho dữ liệu | BigQuery | | Airflow | Cloud Composer |

Từ khoá nhận diện:

"lift and shift, thay đổi ít nhất" → Compute Engine "đổi sang dịch vụ có quản lý" → Replatform "container hoá" → GKE hoặc Cloud Run "viết lại theo kiến trúc đám mây" → Refactor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã kiểm kê hết phụ thuộc chưa | Migration Center | | Kích cỡ máy có hợp không | ⚠ Recommender sau vài tuần | | Chi phí so với trước ra sao | so với TCO cũ, tính cả điện và nhân sự |

Và một việc rất đáng làm trong tháng đầu sau khi lift and shift: đo tải thật rồi chỉnh lại kích cỡ máy. Máy chủ tại chỗ thường được mua dư rất nhiều để phòng xa, và bê nguyên cấu hình đó lên đám mây là cách chắc chắn nhất để trả tiền hằng tháng cho phần công suất chưa bao giờ được dùng tới.

Đáp án

A — Natural Language API.

Vì sao đúng

Phân tích cảm xúc (sentiment) — tích cực, tiêu cực hay trung tính — là một trong bốn tính năng chính của Natural Language API.

⚠ API trả về hai con số:

Nhận xét: "Giao hàng nhanh nhưng
           đóng gói cẩu thả."
        ↓
  score:     ⚠ từ −1,0 tới +1,0
             → CHIỀU của cảm xúc
  magnitude: ⚠ từ 0 tới vô hạn
             → ĐỘ MẠNH của cảm xúc
        ↓
    ⚠ Phải đọc CẢ HAI:
      score ≈ 0 + magnitude CAO
      → ⚠ cảm xúc LẪN LỘN,
        KHÔNG phải trung tính

⚠ Vì sao ba API kia sai hướng:

VISION AI API
    → ⚠ xử lý ẢNH

CLOUD TRANSLATION API
    → ⚠ DỊCH ngôn ngữ

SPEECH-TO-TEXT API
    → ⚠ ÂM THANH → chữ
    → nhận xét trực tuyến đã là
      văn bản

⚠ Gần trùng với #13361 (lô 141) và #13318 (lô 140) — cả ba đề đều dùng Natural Language API cho văn bản (cảm xúc, thực thể). Hoàn toàn nhất quán.

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

• C (Cloud Translation API) — phương án gần nhất về mặt "cũng xử lý văn bản", nhưng nó dịch ngôn ngữ, không phân tích cảm xúc.

• B (Vision AI API) — xử lý ảnh.

• D (Speech-to-Text API) — chuyển âm thanh thành chữ; nhận xét trực tuyến đã là văn bản.

Ghi nhớ

⚠ Các API AI dựng sẵn — bảng phải thuộc: | API | Việc | |---|---| | ⚠ Natural Language | ⚠ cảm xúc, thực thể, cú pháp, phân loại | | Cloud Translation | phát hiện ngôn ngữ + dịch | | Vision | ảnh: nhãn, OCR, SafeSearch | | Speech-to-Text | giọng nói → chữ | | Text-to-Speech | chữ → giọng nói | | Document AI | trích xuất từ hoá đơn, hợp đồng |

Từ khoá nhận diện:

"khách hài lòng hay không, cảm xúc" → Natural Language API "tìm người, tổ chức, địa điểm" → cùng API, tính năng entity "dịch" → Translation API "nhãn riêng của ngành" → AutoML hoặc Gemini

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Điểm có khớp cảm nhận người đọc không | ⚠ lấy 50 nhận xét đối chiếu | | Có nhận xét mỉa mai bị hiểu sai không | rà các ca lệch nhiều nhất | | Chi phí bao nhiêu | số ký tự × đơn giá |

Và một giá trị lớn hơn điểm số trung bình mà nhiều đội bỏ lỡ: phân tích cảm xúc theo từng thực thể. Biết điểm hài lòng đang là 0,3 thì ít hữu ích; biết khách khen sản phẩm nhưng chê khâu giao hàng thì lại chỉ thẳng ra việc cần làm tuần tới.

Đáp án

B — Sự cố của một trung tâm dữ liệu duy nhất (một zone).

Vì sao đúng

Triển khai VM trên nhiều zone trong cùng một vùng bảo vệ đúng ở cấp độ zone — không hơn, không kém.

⚠ Phân cấp và mức bảo vệ tương ứng:

    REGION (ví dụ asia-southeast1)
       ├── zone a  ⚠ điện, mạng,
       ├── zone b     làm mát RIÊNG
       └── zone c
        ↓
    ⚠ Đa zone → chống MẤT MỘT ZONE
        ↓
    ⚠ Cả ba zone vẫn trong CÙNG
      khu vực địa lý
        ↓
    → mất CẢ REGION thì đa zone
      KHÔNG cứu được

⚠ Ba cấp triển khai:

ZONAL
    → ⚠ không chống được gì

⚠ REGIONAL (đa zone)
    → ⚠ chống mất MỘT ZONE
    → đề này

MULTI-REGION
    → ⚠ chống mất CẢ MỘT REGION
    → đắt hơn nhiều

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

"Mất CẢ REGION"
    → ⚠ cần ĐA VÙNG, không phải
      đa zone

"Mất trung tâm dữ liệu TẠI CHỖ"
    → ⚠ không liên quan — họ đang
      chạy trên Google Cloud

"Mất TOÀN BỘ mạng toàn cầu
 của Google"
    → ⚠ kịch bản gần như không
      xảy ra, và không kiến trúc
      nào trong Google Cloud
      chống được

⚠ Gần trùng với #13425 (lô 142) và #13282 (lô 139) — cả ba đề đều về đa zone chống mất một zone, và cùng khoá. Nhất quán.

Đối chiếu #13247 (lô 138) — đề đó khoá đa vùng vì cần chống mất cả một region. Không mâu thuẫn — khác cấp độ sự cố.

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

• A (mất cả region) — phương án gần nhất và là bẫy chính: đa zone không bảo vệ được ở cấp này. Cần triển khai đa vùng.

• C (mất trung tâm dữ liệu tại chỗ) — không liên quan; họ đang chạy trên đám mây.

• D (mất toàn bộ mạng toàn cầu của Google) — kịch bản gần như không xảy ra và không kiến trúc nào chống được.

Ghi nhớ

⚠ Ba cấp triển khai — bảng phải thuộc: | Cấp | Chống được | Chi phí | |---|---|---| | Zonal | ⚠ không gì cả | thấp nhất | | ⚠ Regional (đa zone) | ⚠ mất MỘT ZONE | trung bình | | Multi-region | mất CẢ REGION | cao nhất |

Từ khoá nhận diện:

"mất một zone / một trung tâm dữ liệu" → đa zone "mất cả vùng, thảm hoạ khu vực" → đa vùng "tiết kiệm nhất mà vẫn chịu lỗi" → ⚠ thường là đa zone "xoá nhầm dữ liệu" → ⚠ backup và PITR — đa zone KHÔNG cứu được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thành phần nào chỉ ở một zone không | ⚠ rà từng tài nguyên | | MIG là regional hay zonal | gcloud compute instance-groups list | | Có chịu được thật không | ⚠ diễn tập tắt một zone |

Và một điều luôn đúng với mọi kiến trúc dự phòng: nó chỉ có giá trị nếu đã được diễn tập. Một hệ thống đa zone chưa bao giờ bị thử tắt một zone chỉ là một giả thiết — và thường thì thứ lộ ra trong lần diễn tập đầu tiên là cơ sở dữ liệu vẫn nằm gọn trong một zone duy nhất.

Đáp án

C — Cloud Bigtable.

Vì sao đúng

Đề nêu bốn đặc điểm, và cả bốn đều là mô tả sách giáo khoa của Bigtable:

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

1. "đọc và ghi RẤT THƯỜNG XUYÊN"
     → thông lượng cao

2. ⚠ "mẫu truy vấn ĐƠN GIẢN,
    thường lấy dữ liệu người chơi
    THEO USER ID"
     → ⚠ đọc theo ROW KEY —
       đúng thế mạnh của Bigtable

3. ⚠ "ĐỘ TRỄ CỰC THẤP"
     → một chữ số mili-giây

4. "KHẢ NĂNG MỞ RỘNG KHỔNG LỒ"
     → mở rộng ngang tuyến tính

⚠ Vì sao đọc theo khoá lại nhanh đến vậy:

row key = user_id
        ↓
    ⚠ MỘT lượt tìm trực tiếp
    ⚠ Không join
    ⚠ Không quét bảng
        ↓
    → dưới 10ms, kể cả ở quy mô
      hàng tỉ dòng

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

CLOUD SPANNER
    → ⚠ quan hệ, ACID toàn cầu
    → ⚠ ĐẮT hơn nhiều
    → đề KHÔNG nhắc tới giao dịch
      hay nhất quán mạnh

CLOUD SQL
    → ⚠ chỉ mở rộng DỌC
    → không chịu nổi "mở rộng
      khổng lồ"

BIGQUERY
    → ⚠ kho PHÂN TÍCH
    → độ trễ tính bằng GIÂY

⚠ Gần trùng với #13147 (lô 138) và #13289 (lô 139) — cả ba đề đều là phi quan hệ + thông lượng lớn + độ trễ mili-giây, và cả ba cùng khoá Bigtable. Nhất quán.

⚠ Đối chiếu #13441 (lô 142) — đề đó cũng là công ty game nhưng đòi NHẤT QUÁN MẠNH cho giao dịch, nên khoá Spanner. Không mâu thuẫn — câu này chỉ cần tra hồ sơ theo khoá, không cần giao dịch.

Cách phân biệt: thấy "giao dịch, nhất quán mạnh, quan hệ" → Spanner. Thấy "truy vấn đơn giản theo khoá, độ trễ cực thấp" → Bigtable.

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

• A (Cloud Spanner) — phương án gần nhất vì cũng mở rộng ngang tới quy mô rất lớn. Nhưng nó sinh ra cho giao dịch quan hệ ACID, đắt hơn nhiều, và đề không nhắc tới giao dịch — chỉ cần tra hồ sơ theo ID.

• B (Cloud SQL) — chỉ mở rộng dọc, có trần rõ ràng.

• D (BigQuery) — kho phân tích; độ trễ giây, không phải mili-giây.

Ghi nhớ

⚠ Chọn CSDL — bảng phải thuộc: | Nhu cầu | Chọn | |---|---| | ⚠ Đọc theo khoá, mili-giây, thông lượng lớn | ⚠ Bigtable | | Quan hệ + toàn cầu + nhất quán mạnh | Spanner | | Quan hệ, một vùng | Cloud SQL | | NoSQL tài liệu, ứng dụng di động | Firestore | | Phân tích | BigQuery | | Bộ nhớ đệm | Memorystore |

Từ khoá nhận diện:

"tra theo ID, độ trễ cực thấp, quy mô lớn" → Bigtable "giao dịch ACID toàn cầu" → Spanner "MySQL một vùng" → Cloud SQL "báo cáo lịch sử" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hotspot không | Key Visualizer — vệt sáng dọc là xấu | | CPU thế nào | ⚠ giữ dưới 70% | | Độ trễ p99 bao nhiêu | metric server/latencies |

Và một câu hỏi quyết định giữa Bigtable và Spanner: "có cần giao dịch trên nhiều dòng không?". Nếu chỉ tra và cập nhật hồ sơ của từng người chơi riêng lẻ thì Bigtable nhanh hơn và rẻ hơn nhiều; còn nếu phải trừ tiền ở một chỗ và cộng vật phẩm ở chỗ khác trong cùng một thao tác thì mới cần Spanner.

Đáp án

C — Dùng một API dựng sẵn như Speech-to-Text API.

Vì sao đúng

Đề đòi phiên âm video thành văn bản để tìm kiếm được — một bài toán phổ quát đã có API sẵn.

⚠ Ba lý do chọn API dựng sẵn:

1. ⚠ PHIÊN ÂM là bài toán PHỔ QUÁT
     → Google đã huấn luyện trên
       lượng dữ liệu khổng lồ

2. ⚠ HIỆU QUẢ NHẤT (efficient)
     → gọi API là xong,
       không huấn luyện gì

3. Không cần nhãn riêng
     → khác với phân loại theo
       danh mục nội bộ

⚠ Quy trình xử lý video:

Video đào tạo → Cloud Storage
        ↓
    ⚠ Trích âm thanh (hoặc gửi
      thẳng nếu định dạng hỗ trợ)
        ↓
SPEECH-TO-TEXT API
    ⚠ chế độ BẤT ĐỒNG BỘ cho
      file dài
        ↓
    Bản chép lời + ⚠ TIMESTAMP
      từng từ
        ↓
    Lưu vào BigQuery / Firestore
        ↓
    ⚠ Tìm kiếm được, và NHẢY
      tới đúng giây trong video

⚠ Vì sao ba phương án kia lãng phí:

HUẤN LUYỆN MÔ HÌNH TỪ ĐẦU
BẰNG TENSORFLOW
    → ⚠ cần hàng nghìn giờ
      dữ liệu có nhãn
    → ⚠ mất hàng tháng để đạt
      chất lượng KÉM HƠN

AUTOML để dựng mô hình
phiên âm riêng
    → ⚠ AutoML KHÔNG có sản phẩm
      cho phiên âm giọng nói
    → và cũng không cần

BIGQUERY ML "phân tích file video"
    → ⚠ BigQuery ML làm việc với
      DỮ LIỆU BẢNG BIỂU
    → không xử lý video

Nhất quán với #13432 (lô 142) — đề đó cũng là phiên âm ghi âm cuộc gọi và cùng khoá Speech-to-Text API. Hoàn toàn nhất quán.

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

• B (dùng AutoML để dựng mô hình phiên âm riêng) — phương án gần nhất về mặt "cũng là giải pháp ít mã", nhưng AutoML không có sản phẩm cho phiên âm giọng nói, và bài toán này không cần mô hình riêng.

• A (huấn luyện từ đầu bằng TensorFlow) — cần dữ liệu và thời gian khổng lồ để đạt kết quả kém hơn.

• D (BigQuery ML phân tích file video) — BigQuery ML làm việc với dữ liệu bảng biểu.

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Khi nào | |---|---| | ⚠ API dựng sẵn | ⚠ việc PHỔ QUÁT: phiên âm, dịch, OCR | | AutoML | nhãn RIÊNG + có dữ liệu gán nhãn | | Tuỳ biến | cần kiểm soát kiến trúc |

Từ khoá nhận diện:

"phiên âm, video/âm thanh thành chữ" → Speech-to-Text API "phân tích NỘI DUNG video" → ⚠ Video Intelligence API "dịch" → Translation API "nhãn riêng của nghiệp vụ" → AutoML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ chính xác bản chép | ⚠ nghe lại 20 phút và đối chiếu | | Thuật ngữ nội bộ có đúng không | ⚠ → dùng speech adaptation | | Có nhảy được tới đúng đoạn không | kiểm timestamp |

Và một tính năng nên bật ngay cho video đào tạo nội bộ: speech adaptation với danh sách thuật ngữ của công ty. Tên sản phẩm, tên viết tắt nội bộ và thuật ngữ chuyên ngành là những chỗ mô hình chung hay nghe nhầm nhất — và đó cũng chính là những từ mà người học sẽ dùng để tìm kiếm.

Đáp án

A — Chuyển từ mô hình chi phí vốn (CapEx) lớn trả trước sang mô hình chi phí vận hành (OpEx) định kỳ, trả theo mức dùng.

Vì sao đúng

Đây là thay đổi tài chính căn bản khi rời trung tâm dữ liệu riêng để lên đám mây, và chiều của nó chỉ có một.

⚠ Hai mô hình:

TRUNG TÂM DỮ LIỆU RIÊNG — CapEx
    Mua máy chủ
        ↓
    ⚠ TRẢ TRƯỚC MỘT CỤC
    ⚠ Ghi nhận là TÀI SẢN
    ⚠ Khấu hao 3–5 năm
    ⚠ Cộng thêm: điện, làm mát,
      mặt bằng, nhân sự

ĐÁM MÂY — OpEx
    Hoá đơn hằng tháng
        ↓
    ⚠ KHÔNG đọng vốn ban đầu
    ⚠ Ghi nhận là CHI PHÍ vận hành
    ⚠ Bám theo mức dùng thật

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

"D — OpEx sang CapEx"
    → ⚠ ĐẢO NGƯỢC chiều

"LOẠI BỎ HOÀN TOÀN mọi chi tiêu CNTT"
    → ⚠ chi phí ĐỔI HÌNH THỨC,
      không biến mất

"ĐẢM BẢO giảm ĐÚNG 50%"
    → ⚠ không có con số nào
      được đảm bảo
    → ⚠ chữ "đảm bảo" và "đúng 50%"
      đều là dấu hiệu phương án sai

⚠ Gần trùng với #13291 (lô 139) và #13372 (lô 141) — cả ba đề đều hỏi thay đổi tài chính khi lên đám mây, và cả ba cùng khoá CapEx → OpEx. Hoàn toàn nhất quán.

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

• C (đảm bảo giảm chi tiêu đúng 50%) — phương án gần nhất về mặt "nghe như lợi ích tài chính", nhưng không có con số nào được đảm bảo; tiết kiệm phụ thuộc vào việc vận hành có tốt hay không.

• D (OpEx sang CapEx) — đảo ngược chiều.

• B (loại bỏ hoàn toàn mọi chi tiêu CNTT) — chi phí đổi hình thức, không biến mất.

Ghi nhớ

⚠ CapEx và OpEx — bảng phải thuộc: | | CapEx | OpEx | |---|---|---| | Nghĩa | chi phí VỐN — mua tài sản | chi phí VẬN HÀNH | | Trả tiền | ⚠ trước, một cục | ⚠ dần, theo mức dùng | | Kế toán | tài sản, khấu hao nhiều năm | chi phí trong kỳ | | Rủi ro | ⚠ mua thừa hoặc thiếu | ⚠ chi phí trôi nếu buông lỏng | | ⚠ Lên đám mây | CapEx → OpEx |

Từ khoá nhận diện:

"lên đám mây, đổi cách hạch toán" → CapEx → OpEx "tổng chi phí sở hữu" → TCO "cam kết 1–3 năm giảm giá" → CUD "quản chi phí đám mây liên tục" → FinOps

Ba việc kiểm chứng: | Việc | Cách | |---|---| | TCO hiện tại thật sự bao nhiêu | ⚠ hỏi cả bộ phận cơ sở vật chất | | Tỉ lệ sử dụng máy chủ | ⚠ thường dưới 20% | | Ai chịu trách nhiệm hoá đơn đám mây | ⚠ không có chủ thì chi phí sẽ trôi |

Và một điều mà OpEx đòi hỏi mà CapEx thì không: phải có người theo dõi thường xuyên. Mua một máy chủ là quyết định một lần rồi thôi; thuê hạ tầng đám mây là hàng nghìn quyết định nhỏ mỗi tháng — và nếu không ai nhìn vào hoá đơn, nó sẽ lớn dần mà không ai nhận ra.

Đáp án

C — Serverless.

Vì sao đúng

Đề mô tả đúng định nghĩa của serverless: trừu tượng hoá hoàn toàn hạ tầng máy chủ, cho phép chạy mã mà không phải nghĩ tới máy ảo hay cụm.

⚠ Ba đặc điểm trong đề:

"TRỪU TƯỢNG HOÁ HOÀN TOÀN hạ tầng
 máy chủ bên dưới"
        ↓
    ⚠ không thấy máy chủ nào

"chạy mã mà KHÔNG PHẢI NGHĨ TỚI
 máy ảo hay CỤM"
        ↓
    ⚠ không quản VM, không quản
      Kubernetes cluster
        ↓
    → SERVERLESS

⚠ "Serverless" không có nghĩa là không có máy chủ:

Vẫn có máy chủ ở đâu đó
        ↓
    ⚠ Nhưng BẠN không thấy,
      không quản, không trả tiền
      cho lúc nó nhàn rỗi
        ↓
    ⚠ Đơn vị tính tiền đổi từ
      "máy chủ mỗi giờ" sang
      "request và thời gian chạy"

⚠ Bốn đặc điểm của serverless:

⚠ Không quản hạ tầng
⚠ Tự mở rộng theo tải
⚠ CO VỀ 0 khi rảnh
⚠ Trả tiền theo mức dùng thật

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

IaaS
    → ⚠ nhận MÁY ẢO TRỐNG
    → ⚠ phải nghĩ tới VM — đúng
      thứ đề nói KHÔNG muốn

COLOCATION
    → ⚠ thuê CHỖ ĐẶT máy chủ
      trong trung tâm dữ liệu
      của người khác
    → ⚠ máy vẫn là của bạn

ON-PREMISES
    → tự lo mọi thứ

⚠ Gần trùng với #13344 (lô 140) và #13367 (lô 141) — cả ba đề đều mô tả nhu cầu "không quản máy chủ, chỉ viết mã", và cả ba cùng khoá serverless. Hoàn toàn nhất quán.

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

• B (IaaS) — phương án gần nhất về mặt "cũng là mô hình đám mây", nhưng với IaaS bạn nhận máy ảo trống và phải nghĩ tới VM — đúng thứ đề nói họ muốn tránh.

• A (Colocation) — thuê chỗ đặt máy chủ của chính bạn trong trung tâm dữ liệu của người khác; máy vẫn là của bạn.

• D (On-premises) — tự lo mọi thứ, kể cả phần cứng.

Ghi nhớ

⚠ Mức trách nhiệm theo mô hình — bảng phải thuộc: | Mô hình | Bạn quản | |---|---| | On-premises | ⚠ mọi thứ, kể cả phần cứng | | Colocation | ⚠ máy chủ của bạn, đặt ở nơi khác | | IaaS | hệ điều hành trở lên | | PaaS | mã và dữ liệu | | ⚠ Serverless | ⚠ CHỈ mã, không lo mở rộng | | SaaS | không gì cả |

Từ khoá nhận diện:

"trừu tượng hoá hạ tầng, không nghĩ tới VM hay cụm" → serverless "cần kiểm soát hệ điều hành" → IaaS "thuê chỗ đặt máy" → ⚠ colocation "co về 0" → serverless

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí lúc rảnh có bằng 0 không | billing report theo ngày | | Cold start ảnh hưởng bao nhiêu | đo p99 sau khoảng nghỉ | | Ứng dụng có thật sự không trạng thái không | ⚠ thử khởi động lại instance giữa chừng |

Và một điểm hay bị hiểu sai về serverless đáng nói rõ: nó không tự động rẻ hơn, nó rẻ hơn cho một hình dạng tải nhất định. Với lưu lượng thất thường thì lợi ích rất lớn; với một dịch vụ chạy hết công suất suốt ngày đêm thì một máy ảo có cam kết dài hạn vẫn kinh tế hơn.

Đáp án

A — Cho phép cập nhật và triển khai TỪNG dịch vụ một cách ĐỘC LẬP, tăng tốc độ phát triển.

Vì sao đúng

Triển khai độc lập là lợi thế cốt lõi của microservices, và cũng là thứ tạo ra tốc độ.

⚠ So sánh với khối nguyên:

MONOLITH
    Sửa một dòng ở tính năng gợi ý
        ↓
    ⚠ Kiểm thử LẠI TOÀN BỘ
    ⚠ Triển khai LẠI TOÀN BỘ
    ⚠ Rủi ro làm hỏng thanh toán,
      tìm kiếm, hồ sơ
        ↓
    → chậm và nguy hiểm

MICROSERVICES
    Sửa dịch vụ gợi ý
        ↓
    ⚠ Chỉ kiểm thử và triển khai
      DỊCH VỤ ĐÓ
    ⚠ Các dịch vụ khác không đụng tới
        ↓
    → nhanh hơn, rủi ro nhỏ hơn

⚠ Vì sao "tăng tốc độ phát triển":

Nhiều đội làm SONG SONG
        ↓
    ⚠ Đội A triển khai 5 lần/ngày
    ⚠ Đội B triển khai 2 lần/tuần
    ⚠ Không ai chờ ai
        ↓
    → thay vì tất cả phải chờ
      một đợt phát hành chung

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

"Đơn giản hơn vì MỌI MÃ Ở MỘT CHỖ"
    → ⚠ đó là mô tả của MONOLITH
    → ⚠ microservices PHỨC TẠP HƠN

"GIẢM số máy ảo cần dùng"
    → ⚠ thường TĂNG, vì mỗi dịch vụ
      cần tài nguyên riêng

"Đảm bảo lỗi ở một dịch vụ LUÔN
 làm sập TOÀN BỘ ứng dụng"
    → ⚠ NGƯỢC LẠI hoàn toàn —
      microservices CÔ LẬP lỗi

⚠ Gần trùng với #13256 (lô 138), #13393 (lô 141) và #13461 (lô 142) — cả bốn đề đều về microservices. Câu này hỏi lợi thế chính. Hoàn toàn nhất quán.

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

• C (giảm số máy ảo cần dùng) — phương án gần nhất về mặt "nghe như lợi ích", nhưng microservices thường cần NHIỀU tài nguyên hơn: mỗi dịch vụ có runtime, giám sát và dự phòng riêng.

• B (đơn giản hơn vì mọi mã ở một chỗ) — đó là mô tả của monolith; microservices phức tạp hơn.

• D (đảm bảo lỗi một dịch vụ luôn làm sập toàn bộ) — ngược lại: cô lập lỗi là một lợi thế của microservices.

Ghi nhớ

⚠ Monolith và microservices — bảng phải thuộc: | | Monolith | Microservices | |---|---|---| | ⚠ Triển khai | cả khối một lần | ⚠ từng dịch vụ ĐỘC LẬP | | Mở rộng | nhân cả khối | ⚠ nhân đúng phần cần | | Lỗi | có thể sập tất cả | ⚠ cô lập trong một dịch vụ | | Công nghệ | thống nhất | mỗi dịch vụ chọn riêng | | ⚠ Độ phức tạp | thấp | ⚠ CAO | | ⚠ Tài nguyên | ít hơn | ⚠ thường NHIỀU hơn |

Từ khoá nhận diện:

"triển khai độc lập, tăng tốc độ" → lợi thế microservices "đơn giản, một khối" → monolith "không quản máy chủ" → serverless "đóng gói cùng phụ thuộc" → container

Ba câu hỏi kiểm chứng: | Câu hỏi | Nếu... | |---|---| | Triển khai một dịch vụ có đụng dịch vụ khác không | có → chưa độc lập | | Hai dịch vụ có dùng chung bảng không | ⚠ có → vẫn ghép chặt | | Có lần theo được request xuyên dịch vụ không | không → thiếu quan sát |

Và một dấu hiệu cho biết việc tách microservices chưa thật sự thành công: vẫn phải triển khai nhiều dịch vụ cùng lúc mới chạy được. Khi đó bạn đã gánh toàn bộ chi phí phức tạp của kiến trúc phân tán mà chưa thu được lợi ích chính của nó.