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

Tìm thấy 611 câu.

Câu 121 Digital Transformation with Google Cloud

To increase resiliency and leverage the unique capabilities of different cloud providers, a company decides to run its production application across both Google Cloud and another major public cloud.

What is this strategy called?

  1. A Private Cloud
  2. B Hybrid Cloud
  3. C On-premises
  4. D Multi-cloud
Xem giải thích

Đáp án

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

Vì sao đúng

Đề mô tả rõ: chạy ứng dụng sản xuất trên cả Google Cloud và MỘT NHÀ CUNG CẤP ĐÁM MÂY CÔNG CỘNG KHÁC — đó chính là định nghĩa của multi-cloud.

⚠ Bốn mô hình triển khai — phân biệt cho rõ:

PUBLIC CLOUD
    → toàn bộ trên MỘT nhà cung cấp

PRIVATE CLOUD
    → hạ tầng ảo hoá RIÊNG,
      chỉ một tổ chức dùng

HYBRID CLOUD
    → ⚠ TẠI CHỖ + đám mây CÔNG CỘNG

⚠ MULTI-CLOUD
    → ⚠ NHIỀU NHÀ CUNG CẤP
      đám mây công cộng
    → ví dụ Google Cloud + AWS
    → đề này

⚠ Hai lý do trong đề:

1. "TĂNG KHẢ NĂNG PHỤC HỒI"
     → ⚠ một nhà cung cấp gặp sự cố
       diện rộng thì vẫn còn bên kia
     → không phụ thuộc một đơn vị

2. "TẬN DỤNG NĂNG LỰC RIÊNG
   của từng nhà cung cấp"
     → ⚠ ví dụ: BigQuery của Google
       cho phân tích, dịch vụ khác
       của bên kia cho phần khác

⚠ Cái giá rất thật của multi-cloud:

⚠ Hai hệ thống danh tính và quyền
⚠ Hai bộ công cụ giám sát
⚠ Hai đội kỹ năng, hoặc một đội
  phải biết cả hai
⚠ Phí truyền dữ liệu giữa hai bên
⚠ Độ trễ giữa hai đám mây
⚠ Chỉ dùng được MẪU SỐ CHUNG
  của cả hai
        ↓
    → chỉ nên làm khi có lý do
      rõ ràng, không phải "cho chắc"

⚠ Đối chiếu #13265 (lô 138) — đề đó khoá Hybrid cloud vì bệnh viện giữ hồ sơ tại chỗ và dùng BigQuery trên đám mây. Câu này khoá Multi-cloud vì có hai nhà cung cấp đám mây công cộng. Hai câu KHÔNG mâu thuẫn — chúng là hai mô hình khác nhau.

Cách phân biệt: có hạ tầng TẠI CHỖ trong bức tranh → hybrid. Có hai nhà cung cấp công cộng → multi-cloud.

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

  • B (hybrid cloud) — phương án gần nhất và hay bị nhầm nhất: hybrid đòi có hạ tầng tại chỗ, mà đề không nhắc tới trung tâm dữ liệu riêng nào.

  • A (private cloud) — hạ tầng riêng cho một tổ chức, không phải nhiều nhà cung cấp công cộng.

  • C (on-premises) — chạy hoàn toàn tại chỗ.

Ghi nhớ

⚠ Bốn mô hình triển khai — bảng phải thuộc: | Mô hình | Nghĩa | |---|---| | Public cloud | một nhà cung cấp công cộng | | Private cloud | hạ tầng riêng của một tổ chức | | Hybrid cloud | ⚠ TẠI CHỖ + công cộng | | Multi-cloud | ⚠ NHIỀU nhà cung cấp công cộng | | ⚠ Kết hợp | có thể vừa hybrid vừa multi-cloud |

Từ khoá nhận diện:

"Google Cloud và AWS/Azure" → multi-cloud "giữ một phần tại chỗ" → hybrid "tất cả trên một đám mây" → public "trung tâm dữ liệu riêng đã ảo hoá" → private

Lý do chọn multi-cloud Lý do
Tránh phụ thuộc một nhà cung cấp ⚠ cả kỹ thuật lẫn thương lượng giá
Tận dụng thế mạnh riêng BigQuery, Vertex AI của Google
Yêu cầu pháp lý của một số ngành
Sáp nhập doanh nghiệp ⚠ thừa hưởng hạ tầng của bên kia
Phủ vùng địa lý nhà cung cấp này có vùng mà bên kia không
⚠ Công cụ của Google cho multi-cloud Công cụ
GKE Enterprise (Anthos) ⚠ quản cụm Kubernetes ở MỌI đám mây
BigQuery Omni ⚠ truy vấn dữ liệu nằm ở AWS/Azure
Cloud Interconnect / Partner Interconnect kết nối riêng
Cloud Service Mesh định tuyến và bảo mật xuyên môi trường
Looker ⚠ kết nối được nhiều nguồn ở nhiều đám mây
Terraform hạ tầng dưới dạng mã cho cả hai
⚠ Cái giá phải cân nhắc nghiêm túc Cái giá
Độ phức tạp vận hành nhân đôi
⚠ Phí truyền dữ liệu giữa hai đám mây thường rất đắt
Độ trễ giữa hai bên
Kỹ năng đội ngũ ⚠ chi phí lớn nhất và ít được nói tới
⚠ Chỉ dùng được mẫu số chung mất các dịch vụ đặc thù
Giảm rủi ro khoá chân mà không cần multi-cloud Cách
Dùng container và Kubernetes ⚠ chuẩn mở, chuyển đi được
Định dạng dữ liệu mở Parquet, Iceberg
Hạ tầng dưới dạng mã Terraform
Tách logic nghiệp vụ khỏi SDK riêng
⚠ Thực tế phần lớn tổ chức chọn cách này thay vì multi-cloud thật
Ba mức "multi-cloud" trong thực tế Mức
Dùng SaaS ở nhiều nơi ⚠ hầu như ai cũng đang thế
Workload khác nhau ở đám mây khác nhau phổ biến
⚠ MỘT workload chạy song song ở hai đám mây khó nhất, hiếm nhất

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao | |---|---| | Lý do multi-cloud là gì | ⚠ "cho chắc" không phải lý do đủ | | Đội có đủ kỹ năng cả hai không | | | Phí truyền dữ liệu giữa hai bên là bao nhiêu | ⚠ tính trước, đừng để bất ngờ |

Và một quan sát thực tế đáng cân nhắc trước khi chọn con đường này: phần lớn tổ chức nói mình làm multi-cloud thật ra đang chạy các workload khác nhau ở các đám mây khác nhau, chứ không phải một ứng dụng chạy song song ở cả hai. Mức đó rẻ hơn nhiều và vẫn giữ được phần lớn lợi ích về khả năng thương lượng.

Câu 122 Digital Transformation with Google Cloud

An organization has a very large and sophisticated data center that it has invested in for many years. It wants to maintain full control over its infrastructure for security and governance reasons but does not want to use any public cloud services.

Which infrastructure model is this?

  1. A Public Cloud
  2. B Private Cloud
  3. C Multi-cloud
  4. D Hybrid Cloud
Xem giải thích

Đáp án

B — Private Cloud (đám mây riêng).

Vì sao đúng

Đề nêu ba đặc điểm, và cả ba đều chỉ vào đám mây riêng:

⚠ Ba đặc điểm ↔ private cloud:

1. "TRUNG TÂM DỮ LIỆU RẤT LỚN VÀ
    TINH VI, đã đầu tư nhiều năm"
     → hạ tầng riêng đã có sẵn

2. "GIỮ TOÀN QUYỀN KIỂM SOÁT
    vì lý do bảo mật và quản trị"
     → ⚠ lý do điển hình chọn
       đám mây riêng

3. ⚠ "KHÔNG muốn dùng BẤT KỲ
    dịch vụ đám mây CÔNG CỘNG nào"
     → ⚠ loại thẳng public,
       hybrid và multi-cloud

⚠ Đám mây riêng khác trung tâm dữ liệu truyền thống:

TRUNG TÂM DỮ LIỆU TRUYỀN THỐNG
    → máy chủ vật lý gán cho
      từng ứng dụng
    → xin máy mới mất hàng tuần

⚠ PRIVATE CLOUD
    → ⚠ ẢO HOÁ và TỰ PHỤC VỤ
    → ⚠ có cổng để đội tự xin
      tài nguyên
    → ⚠ tính tiền nội bộ (chargeback)
    → ⚠ tự động hoá bằng API
        ↓
    → có "trải nghiệm đám mây"
      nhưng hạ tầng là của riêng

⚠ Đánh đổi của đám mây riêng:

ƯU
  ✔ toàn quyền kiểm soát
  ✔ đáp ứng quy định khắt khe
  ✔ tận dụng đầu tư đã có

⚠ NHƯỢC
  ⚠ vẫn phải mua cho MỨC ĐỈNH
  ⚠ mở rộng vẫn mất hàng tuần
  ⚠ tự lo mọi thứ, kể cả an ninh
    vật lý
  ⚠ CapEx lớn, đọng vốn
  ⚠ không có dịch vụ có quản lý
    kiểu BigQuery

Hoàn chỉnh bộ bốn mô hình cùng #13364 (cùng lô, multi-cloud) và #13265 (lô 138, hybrid). Cả ba nhất quán. Quy tắc phân biệt: có tại chỗ + công cộng → hybrid; nhiều nhà cung cấp công cộng → multi-cloud; chỉ hạ tầng riêng → private; chỉ nhà cung cấp công cộng → public.

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

  • D (hybrid cloud) — phương án gần nhất và bị nhầm nhiều: hybrid đòi có dùng đám mây công cộng, mà đề nói rõ họ không muốn dùng bất kỳ dịch vụ công cộng nào.

  • A (public cloud) — trái ngược hoàn toàn với yêu cầu của đề.

  • C (multi-cloud) — đòi nhiều nhà cung cấp công cộng; ở đây không có nhà cung cấp nào.

Ghi nhớ

⚠ Bốn mô hình triển khai — bảng phải thuộc: | Mô hình | Đặc điểm | |---|---| | Public cloud | hạ tầng dùng chung của nhà cung cấp | | ⚠ Private cloud | ⚠ hạ tầng RIÊNG, chỉ một tổ chức dùng | | Hybrid cloud | ⚠ tại chỗ + công cộng | | Multi-cloud | ⚠ nhiều nhà cung cấp công cộng |

Từ khoá nhận diện:

"chỉ hạ tầng riêng, không dùng công cộng" → private cloud "giữ một phần tại chỗ, dùng công cộng phần còn lại" → hybrid "Google Cloud và AWS" → multi-cloud "tất cả trên một nhà cung cấp" → public

⚠ Lý do chọn đám mây riêng Lý do
Quy định rất khắt khe ⚠ quốc phòng, ngân hàng trung ương
Đã đầu tư lớn chưa khấu hao xong
Yêu cầu kiểm soát tuyệt đối
Độ trễ tới thiết bị tại chỗ
Chính sách nội bộ ⚠ đôi khi chỉ là thói quen chưa rà lại
Giải pháp trung gian của Google Giải pháp
Google Distributed Cloud ⚠ hạ tầng Google chạy TẠI CHỖ của bạn
GDC air-gapped ⚠ hoàn toàn ngắt kết nối — cho quốc phòng
GKE Enterprise quản Kubernetes ở mọi nơi
Sovereign cloud partner vận hành bởi đối tác trong nước
Ý nghĩa có "đám mây riêng" mà vẫn dùng công nghệ Google
⚠ Điều đám mây riêng KHÔNG cho Điều
Co giãn thật sự ⚠ vẫn phải mua trước cho đỉnh
Trả theo mức dùng vẫn là CapEx
Dịch vụ có quản lý quy mô lớn ⚠ không có BigQuery, Spanner
Vươn ra toàn cầu trong vài phút
Đổi mới liên tục từ nhà cung cấp
Câu hỏi nên đặt lại định kỳ Câu hỏi
Lý do "không dùng công cộng" còn đúng không ⚠ quy định có thể đã đổi
Có phải chỉ là thói quen không
Chi phí thật của đám mây riêng là bao nhiêu ⚠ tính cả điện, mặt bằng, nhân sự
Có thể hybrid cho phần không nhạy cảm không
Con đường thường thấy trong thực tế Bước
Private cloud → hybrid cho phần không nhạy cảm
→ dùng công cộng cho phân tích và AI ⚠ nơi đám mây mạnh nhất
→ giữ dữ liệu lõi tại chỗ
Nguyên tắc không phải chuyện tất cả hoặc không gì

Ba việc kiểm chứng cho một tổ chức: | Việc | Câu hỏi | |---|---| | Tỉ lệ sử dụng hạ tầng hiện tại | ⚠ thường dưới 30% | | Mở rộng mất bao lâu | so với vài phút | | Quy định cụ thể nào cấm | ⚠ đọc lại văn bản, đừng dựa vào lời truyền miệng |

Và một câu hỏi rất đáng đặt lại vài năm một lần với mọi quyết định "chúng tôi không dùng đám mây công cộng": văn bản nào nói vậy, và nó được ban hành năm nào? Nhiều chính sách kiểu này ra đời từ thời các dịch vụ đám mây chưa có chứng nhận tuân thủ như bây giờ, và chưa từng được rà soát lại kể từ đó.

Câu 123 Innovating with Google Cloud Artificial Intelligence

A retail company analyzes five years of sales data, customer demographics, and seasonal trends to predict which products will be in high demand next quarter. They use these predictions to optimize inventory levels, reducing waste from overstocking while preventing stockouts that lose sales.

What is the primary business value created by machine learning (ML) in this scenario?

  1. A It guarantees 100% accurate predictions in all situations.
  2. B It eliminates the need for any human oversight in business processes.
  3. C It reduces the amount of data a company needs to store.
  4. D It finds patterns in data to make predictions and support decision-making at scale.
Xem giải thích

Đáp án

D — Nó tìm ra quy luật trong dữ liệu để đưa ra dự đoán và hỗ trợ ra quyết định ở quy mô lớn.

Vì sao đúng

Đề mô tả đúng giá trị cốt lõi của học máy: học từ năm năm dữ liệu lịch sử để dự đoán nhu cầu quý tới, rồi dùng dự đoán đó tối ưu tồn kho.

⚠ Chuỗi giá trị trong đề:

DỮ LIỆU: 5 năm bán hàng,
         nhân khẩu học khách,
         xu hướng mùa vụ
        ↓
⚠ ML TÌM QUY LUẬT
    → mặt hàng nào bán chạy khi nào
    → nhóm khách nào mua gì
    → mùa vụ ảnh hưởng ra sao
        ↓
⚠ DỰ ĐOÁN nhu cầu quý tới
        ↓
⚠ QUYẾT ĐỊNH: đặt hàng bao nhiêu
        ↓
GIÁ TRỊ:
    ⚠ giảm hàng tồn ế
    ⚠ giảm mất doanh thu do hết hàng

⚠ "Ở quy mô lớn" là phần quan trọng:

Một chuyên gia giỏi có thể dự đoán
tốt cho 10 mặt hàng
        ↓
    ⚠ Nhưng chuỗi bán lẻ có
      hàng chục nghìn mã hàng
      × hàng trăm cửa hàng
        ↓
    ⚠ ML dự đoán cho TỪNG cặp
      mặt hàng–cửa hàng,
      cập nhật hằng tuần
        ↓
    → đây là điều con người
      không làm nổi bằng tay

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

"ĐẢM BẢO dự đoán chính xác 100%"
    → ⚠ KHÔNG mô hình nào
      đảm bảo điều đó
    → ML cho DỰ ĐOÁN CÓ XÁC SUẤT

"LOẠI BỎ nhu cầu giám sát của
 con người"
    → ⚠ NGƯỢC LẠI: mô hình cần
      người theo dõi và hiệu chỉnh
    → nguyên tắc AI có trách nhiệm

"GIẢM lượng dữ liệu phải lưu"
    → ⚠ ML thường cần LƯU NHIỀU HƠN

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

  • A (đảm bảo dự đoán chính xác 100%) — phương án gần nhất về mặt "cũng nói về dự đoán", nhưng chữ "đảm bảo 100%" làm nó sai: ML luôn có sai số, và mọi mô hình đều cần theo dõi độ chính xác theo thời gian.

  • B (loại bỏ nhu cầu giám sát của con người) — ngược lại: mô hình cần con người đặt ngưỡng, kiểm tra và can thiệp khi bối cảnh thay đổi.

  • C (giảm lượng dữ liệu phải lưu) — ML thường cần thêm dữ liệu, không giảm.

Ghi nhớ

⚠ Bốn cấp phân tích — bảng phải thuộc: | Cấp | Câu hỏi | Công cụ | |---|---|---| | Descriptive | "đã xảy ra gì?" | dashboard BI | | Diagnostic | "vì sao?" | khoan sâu | | ⚠ Predictive | ⚠ "sẽ xảy ra gì?" — đề này | BigQuery ML, Vertex AI | | Prescriptive | "nên làm gì?" | tối ưu hoá |

Từ khoá nhận diện:

"dự đoán, nhu cầu quý tới, khả năng" → học máy "quý trước bán bao nhiêu" → phân tích dữ liệu "đảm bảo 100%" → ⚠ luôn là phương án SAI "loại bỏ hoàn toàn con người" → ⚠ cũng thường là phương án SAI

⚠ Bài toán dự báo nhu cầu — thực hiện thế nào Cách
BigQuery ML ARIMA_PLUS ⚠ dự báo chuỗi thời gian bằng SQL
Tự phát hiện mùa vụ và ngày lễ
Vertex AI Forecasting mô hình mạnh hơn, nhiều đặc trưng hơn
ML.FORECAST ⚠ trả về cả KHOẢNG TIN CẬY
Dữ liệu cần ⚠ ít nhất 2–3 chu kỳ mùa vụ
⚠ Khoảng tin cậy quan trọng hơn con số đơn lẻ Lý do
Dự báo "bán 1.000 cái" ⚠ thiếu thông tin
Dự báo "800–1.200, tin cậy 80%" ⚠ dùng để quyết định được
Ứng dụng đặt tồn kho an toàn theo cận trên
Nguyên tắc ML cho phân phối xác suất, không cho sự thật
Cân bằng hai loại sai lầm Sai lầm
Đặt quá nhiều ⚠ tồn kho ế, hàng hết hạn
Đặt quá ít ⚠ hết hàng, mất doanh thu và khách
Quyết định ⚠ hai loại sai lầm có CHI PHÍ khác nhau
Cách làm đặt ngưỡng theo chi phí nghiệp vụ, không theo độ chính xác thuần
⚠ Vì sao vẫn cần con người Lý do
Mô hình học từ QUÁ KHỨ ⚠ không biết về sự kiện chưa từng có
Bối cảnh thay đổi dịch bệnh, đứt gãy chuỗi cung ứng
Quyết định có yếu tố chiến lược ra mắt sản phẩm mới
Phải giám sát drift Vertex AI Model Monitoring
Nguyên tắc ⚠ ML HỖ TRỢ quyết định, không THAY THẾ
Đo giá trị của dự án này Đo
Tỉ lệ hết hàng ⚠ giảm là thành công
Giá trị hàng tồn ế
Vòng quay tồn kho
So với cách đoán cũ ⚠ luôn cần một ĐƯỜNG CƠ SỞ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự báo có tốt hơn cách cũ không | ⚠ so với "bằng cùng kỳ năm ngoái" | | Sai số bao nhiêu | MAPE — dễ giải thích cho lãnh đạo | | Mô hình còn đúng không | Model Monitoring, huấn luyện lại định kỳ |

Và một mẹo làm bài rất hữu ích với những câu hỏi về giá trị của AI: cảnh giác với mọi phương án chứa chữ "đảm bảo", "100%", hoặc "loại bỏ hoàn toàn". Học máy là công cụ xác suất và luôn cần con người giám sát — nên những khẳng định tuyệt đối gần như luôn là đáp án sai.

Câu 124 Modernize Infrastructure and Applications with Google Cloud
A startup is building a new event-driven application. A key business requirement is that they should incur absolutely no costs when the application is not being used, but it must scale instantly when it receives traffic. Which compute option offers this "scale to zero" capability as a primary benefit?
  1. A Compute Engine with a preemptible VM.
  2. B A dedicated on-premises server.
  3. C Compute Engine with a minimum of one instance running at all times.
  4. D

    Serverless computing (e.g., Cloud Run).
Xem giải thích

Đáp án

D — Điện toán serverless (ví dụ Cloud Run).

Vì sao đúng

Đề nêu hai yêu cầu tuyệt đối, và chỉ serverless đáp ứng cả hai:

⚠ Hai yêu cầu ↔ serverless:

1. ⚠ "TUYỆT ĐỐI KHÔNG TỐN CHI PHÍ
    khi ứng dụng không được dùng"
     → ⚠ CO VỀ 0 — đây là điều kiện
       loại trừ then chốt

2. "MỞ RỘNG TỨC THÌ khi có lưu lượng"
     → tự mở rộng theo request,
       không cần khởi động trước

⚠ Vì sao ba phương án kia đều tính tiền lúc rảnh:

PREEMPTIBLE / SPOT VM
    → ⚠ RẺ HƠN nhưng VẪN TÍNH TIỀN
      khi đang chạy
    → và ⚠ bị THU HỒI bất cứ lúc nào
      → không hợp cho ứng dụng
        phải sẵn sàng

MÁY CHỦ VẬT LÝ TẠI CHỖ
    → ⚠ tốn tiền 24/7:
      điện, làm mát, khấu hao
    → xa nhất với yêu cầu

COMPUTE ENGINE với TỐI THIỂU
MỘT INSTANCE luôn chạy
    → ⚠ chính lời phương án đã nói
      là KHÔNG co về 0

⚠ Đường chi phí — khác biệt rõ nhất:

MÁY ẢO CHẠY LIÊN TỤC
Chi phí ┤████████████████████
        └────────────────────
        ⚠ trả cả lúc 3h sáng

SERVERLESS
Chi phí ┤██▁▁▁████▁▁▁██▁▁▁
        └────────────────────
        ⚠ ban đêm, cuối tuần
          gần như 0 đồng

⚠ Gần trùng với #13344 (lô 140) và #13274 (lô 139) — cả ba đề đều nêu yêu cầu "không tốn tiền lúc rảnh + tự mở rộng", 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

  • A (Compute Engine với preemptible VM) — phương án gần nhất về mặt tiết kiệm: Spot VM rẻ hơn tới 60–91%. Nhưng nó vẫn tính tiền khi chạy và bị thu hồi bất cứ lúc nào — không phù hợp cho ứng dụng cần phản hồi ngay khi có lưu lượng.

  • C (Compute Engine tối thiểu một instance) — chính lời phương án đã tự loại mình: luôn có một máy chạy nghĩa là luôn tính tiền.

  • B (máy chủ vật lý tại chỗ) — tốn chi phí cố định 24/7, xa nhất với yêu cầu.

Ghi nhớ

⚠ Nền tảng nào co về 0 — bảng phải thuộc: | Sản phẩm | Co về 0? | |---|---| | Cloud Run | ⚠ CÓ | | Cloud Run Functions | CÓ | | App Engine Standard | CÓ | | BigQuery, Pub/Sub, Cloud Storage | ⚠ serverless sẵn | | App Engine Flexible | ⚠ KHÔNG | | GKE | ⚠ KHÔNG — cụm luôn chạy | | Compute Engine | KHÔNG |

Từ khoá nhận diện:

"không tốn tiền lúc rảnh, mở rộng tức thì" → serverless "rẻ nhưng chịu được gián đoạn" → Spot VM "cần kiểm soát hệ điều hành" → Compute Engine "nhiều container phụ thuộc nhau" → GKE

⚠ Spot / Preemptible VM — hiểu cho đúng Điểm
Giảm giá tới 60–91%
⚠ Bị thu hồi bất cứ lúc nào báo trước 30 giây
Hợp với ⚠ xử lý theo lô, huấn luyện ML, render
Không hợp với ⚠ dịch vụ phải sẵn sàng liên tục
Điều kiện phải lưu checkpoint để chạy lại được
⚠ Cold start — đánh đổi của việc co về 0 Điểm
Request đầu phải khởi động instance
Thêm vài trăm ms tới vài giây
Giảm bằng min-instances — ⚠ nhưng mất tính co về 0
Giảm cách khác image nhẹ, khởi động nhanh
Với đề này ⚠ họ ưu tiên chi phí, nên chấp nhận cold start
Điều kiện để dùng được serverless Điều kiện
Ứng dụng KHÔNG TRẠNG THÁI ⚠ instance bị huỷ bất cứ lúc nào
Trạng thái để ở kho ngoài Firestore, Cloud Storage, Memorystore
Khởi động nhanh
Xử lý được thông điệp trùng idempotent
Đặt max-instances ⚠ chặn hoá đơn bất ngờ
Kiến trúc hướng sự kiện serverless Thành phần
Eventarc định tuyến sự kiện
Pub/Sub hàng đợi, tách rời
Cloud Run / Functions xử lý
Firestore trạng thái
Workflows điều phối nhiều bước
⚠ Điểm chung tất cả đều co về 0

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ỉ | | Có bị mở rộng vô hạn không | kiểm max-instances |

Và một tham số nên đặt ngay ở lần triển khai đầu tiên với mọi startup dùng serverless: max-instances. Mô hình "không dùng thì không mất tiền" rất hấp dẫn, nhưng mặt kia của nó là "dùng nhiều thì mất nhiều" — và một vòng lặp gọi nhầm có thể biến hoá đơn tháng đầu thành một bài học rất đắt.

Câu 125 Digital Transformation with Google Cloud
Which term describes the benefit of being able to rapidly develop, test, and launch new software features, allowing a business to respond more quickly to market changes?
  1. A Sustainability
  2. B Agility
  3. C Total Cost of Ownership (TCO)
  4. D Capital Expenditure (CapEx)
Xem giải thích

Đáp án

B — Agility (tính linh hoạt, tốc độ).

Vì sao đúng

Đề định nghĩa thẳng khái niệm cần tìm: phát triển, kiểm thử và ra mắt tính năng NHANH, để doanh nghiệp phản ứng kịp với thay đổi của thị trường.

⚠ Agility gồm hai vế:

VẾ KỸ THUẬT
    → cấp tài nguyên trong vài phút
    → môi trường thử nghiệm dựng
      và xoá dễ dàng
    → CI/CD tự động

VẾ KINH DOANH
    → ⚠ thử ý tưởng nhanh, sai thì
      bỏ rẻ
    → ra mắt trước đối thủ
    → phản ứng với thay đổi thị trường

⚠ Vì sao đám mây tạo ra agility:

TẠI CHỖ
  Có ý tưởng
        ↓
    Xin ngân sách → đặt mua máy
    → chờ giao → lắp → cấu hình
        ↓
    ⚠ HÀNG TUẦN tới HÀNG THÁNG
        ↓
    → nhiều ý tưởng CHẾT trước
      khi được thử

ĐÁM MÂY
  Có ý tưởng
        ↓
    ⚠ Dựng môi trường trong VÀI PHÚT
        ↓
    Thử, đo, học
        ↓
    ⚠ Sai thì XOÁ, chỉ mất tiền
      vài giờ chạy

⚠ Ba khái niệm kia nói về chuyện khác:

SUSTAINABILITY
    → ⚠ bền vững, carbon,
      năng lượng tái tạo

TCO
    → ⚠ tổng chi phí sở hữu
    → là con số, không phải năng lực

CapEx
    → ⚠ chi phí vốn, mua tài sản
    → chính là thứ làm CHẬM lại

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

  • C (TCO) — phương án gần nhất về mặt "cũng là lợi ích của đám mây", nhưng TCO là một con số chi phí, không phải năng lực phản ứng nhanh mà đề mô tả.

  • A (sustainability) — về môi trường và phát thải.

  • D (CapEx) — chi phí vốn; mô hình này chính là thứ khiến việc thử nghiệm trở nên chậm và tốn kém.

Ghi nhớ

⚠ Các lợi ích kinh doanh của đám mây — bảng nên thuộc: | Lợi ích | Nội dung | |---|---| | ⚠ Agility | ⚠ thử nghiệm và ra mắt nhanh | | Elasticity | co giãn theo nhu cầu thật | | Scalability | mở rộng được tới quy mô lớn | | Reliability | đa zone, đa vùng | | Cost (OpEx) | trả theo mức dùng | | Global reach | vùng mới trong vài phút | | Sustainability | carbon thấp hơn |

Từ khoá nhận diện:

"ra mắt nhanh, phản ứng với thị trường" → agility "tăng giảm theo tải" → elasticity "tổng chi phí sở hữu" → TCO "chuyển từ mua sang thuê" → CapEx → OpEx

⚠ Đo agility bằng gì — chỉ số DORA Chỉ số
Deployment frequency ⚠ triển khai bao nhiêu lần
Lead time for changes từ commit tới production mất bao lâu
Change failure rate % triển khai gây sự cố
Time to restore service phục hồi mất bao lâu
Phát hiện ⚠ đội tốt vừa NHANH HƠN vừa ỔN ĐỊNH HƠN
Điều gì thật sự tạo ra agility Điều
Hạ tầng theo yêu cầu ⚠ điều kiện cần, không phải điều kiện đủ
CI/CD tự động
Hạ tầng dưới dạng mã dựng lại môi trường trong phút
Kiến trúc tách rời đổi một phần không ảnh hưởng phần khác
⚠ Văn hoá và quy trình duyệt thay đổi kéo dài vài tuần thì hạ tầng nhanh cũng vô ích
⚠ Agility không có nghĩa là cẩu thả Điểm
Vẫn cần kiểm thử tự động
Vẫn cần giám sát và cảnh báo
Vẫn cần quay lui được ⚠ nhanh mà không quay lui được là liều
Error budget cân giữa tốc độ và ổn định
Thử nghiệm rẻ — điều đám mây cho phép Cách
Môi trường tạm cho từng nhánh mã
A/B testing trên sản xuất traffic splitting
Canary release ⚠ thử trên 5% người dùng
Xoá môi trường ngay sau khi xong
Nguyên tắc ⚠ thất bại rẻ thì mới dám thử nhiều

Ba câu hỏi kiểm chứng cho một tổ chức: | Câu hỏi | Vì sao | |---|---| | Từ ý tưởng tới sản xuất mất bao lâu | ⚠ thước đo agility thật | | Dựng một môi trường thử mất bao lâu | | | Có bao nhiêu bước duyệt thủ công | ⚠ thường là nút thắt thật |

Và một điều cần nói thẳng về agility: hạ tầng đám mây chỉ gỡ được một nửa nút thắt. Nếu mọi thay đổi vẫn phải qua ba vòng duyệt kéo dài hai tuần, thì việc dựng được máy ảo trong ba mươi giây chẳng thay đổi được gì cho tốc độ ra thị trường.

Câu 126 Scaling with Google Cloud Operations
A company's finance team needs to understand and analyze their Google Cloud spending. They want to see cost trends, identify which services are most expensive, and group costs by project. Which Google Cloud tool provides this functionality?
  1. A Cloud Monitoring
  2. B The Google Cloud Pricing Calculator
  3. C Cloud Billing reports
  4. D Cloud Logging
Xem giải thích

Đáp án

C — Cloud Billing reports (báo cáo thanh toán).

Vì sao đúng

Đề đòi ba việc, và cả ba đều là chức năng của báo cáo thanh toán:

⚠ Ba yêu cầu ↔ Billing reports:

1. "XEM XU HƯỚNG CHI PHÍ"
     → biểu đồ theo thời gian

2. "XÁC ĐỊNH DỊCH VỤ NÀO ĐẮT NHẤT"
     → ⚠ nhóm theo SERVICE và SKU

3. "NHÓM CHI PHÍ THEO PROJECT"
     → ⚠ bộ lọc và nhóm dựng sẵn

⚠ Các chiều bóc tách có sẵn:

Nhóm theo:
    ⚠ Project
    ⚠ Service (Compute, BigQuery…)
    ⚠ SKU (chi tiết nhất)
    ⚠ Label (theo đội, môi trường)
    Location
    Folder
        ↓
    Kết hợp với bộ lọc thời gian
        ↓
    → trả lời gần hết câu hỏi
      thường gặp về chi phí

⚠ Phân biệt bốn công cụ chi phí:

⚠ BILLING REPORTS
    → XEM và PHÂN TÍCH chi phí ĐÃ PHÁT SINH
    → bị động, phải mở ra xem
    → đề này

BUDGET & ALERTS
    → ⚠ CẢNH BÁO CHỦ ĐỘNG theo ngưỡng %

PRICING CALCULATOR
    → ⚠ ƯỚC TÍNH TRƯỚC khi dùng

BILLING EXPORT → BIGQUERY
    → ⚠ phân tích SÂU bằng SQL,
      giữ lịch sử dài

⚠ Đối chiếu #13345 (lô 140) và #13255 (lô 138) — hai đề đó khoá budget alert vì yêu cầu là được THÔNG BÁO chủ động. Câu này khoá billing reports vì yêu cầu là XEM và PHÂN TÍCH. Không mâu thuẫn — khác nhau ở chỗ "báo cho tôi" hay "cho tôi xem".

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

  • B (Pricing Calculator) — phương án gần nhất về mặt "cũng về chi phí", nhưng nó ước tính TRƯỚC khi dùng, dựa trên cấu hình giả định. Nó không biết gì về chi tiêu thực tế của bạn.

  • A (Cloud Monitoring) — theo dõi hiệu năng và tình trạng hệ thống. (Có thể đặt cảnh báo ngân sách qua kênh của nó, nhưng nó không phải nơi phân tích chi phí.)

  • D (Cloud Logging) — thu thập và tra cứu nhật ký, không phải chi phí.

Ghi nhớ

⚠ Bốn công cụ chi phí — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Billing reports | ⚠ XEM và phân tích chi phí đã phát sinh | | Budgets & alerts | ⚠ CẢNH BÁO chủ động theo ngưỡng | | Pricing Calculator | ⚠ ƯỚC TÍNH trước khi dùng | | Billing export → BigQuery | ⚠ phân tích sâu bằng SQL | | Recommender | gợi ý cắt giảm | | Quotas | chặn cứng số lượng tài nguyên |

Từ khoá nhận diện:

"xem xu hướng, dịch vụ nào đắt nhất" → billing reports "báo cho tôi khi tới X%" → budget alert "ước tính trước khi triển khai" → Pricing Calculator "phân tích theo nhãn bằng SQL" → billing export + BigQuery

⚠ Vì sao nên bật billing export sang BigQuery Lý do
Giao diện báo cáo có giới hạn
BigQuery cho truy vấn TUỲ Ý ⚠ theo nhãn, theo ngày, theo SKU
Giữ lịch sử dài hơn
Nối với dữ liệu nghiệp vụ chi phí trên mỗi đơn hàng
Dựng dashboard riêng bằng Looker
⚠ Nên bật ngay từ đầu — dữ liệu không hồi tố được
⚠ Nhãn (label) — điều kiện để phân tích có ý nghĩa Điểm
Không có nhãn thì chỉ nhóm được theo project
Nhãn nên có ⚠ team, env, app, cost-center
Đặt chính sách bắt buộc gắn nhãn
Kết quả ⚠ trả lời được "chi phí này của ai"
Ba câu hỏi mà báo cáo trả lời tốt Câu hỏi
"Tháng này tăng so với tháng trước ở đâu?" so sánh kỳ
"Dịch vụ nào chiếm nhiều nhất?" nhóm theo service
"Project nào tiêu nhiều nhất?" nhóm theo project
Câu khó hơn ⚠ cần billing export và SQL
Sau khi phân tích thì làm gì Việc
Đặt ngân sách và cảnh báo ⚠ để lần sau không phải ngồi xem
Xem Recommender tài nguyên nằm không, rightsizing
Mua CUD cho tải ổn định
Đặt hạn mức byte quét BigQuery
Tắt máy dev ngoài giờ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí tăng ở đâu | so sánh hai tháng, nhóm theo SKU | | Có tài nguyên nào không ai nhận không | ⚠ lọc theo nhãn — cái nào thiếu nhãn | | Có lãng phí không | Recommender |

Và một việc nên làm ngay hôm nay nếu chưa làm: bật billing export sang BigQuery. Dữ liệu chi phí chi tiết chỉ có từ thời điểm bạn bật trở đi và không dựng lại được quá khứ — nên mỗi tháng chậm trễ là một tháng dữ liệu vĩnh viễn không có để phân tích.

Câu 127 Modernize Infrastructure and Applications with Google Cloud
A company is migrating its legacy applications to Google Cloud. Their primary goal is to move quickly and minimize immediate code changes. Which migration strategy should they choose?
  1. A Retire
  2. B Refactor
  3. C Reimagine
  4. D Rehost (Lift and Shift)
Xem giải thích

Đáp án

D — Rehost (Lift and Shift).

Vì sao đúng

Đề nêu hai mục tiêu, và cả hai đều chỉ vào rehost:

⚠ Hai mục tiêu ↔ rehost:

1. "DI CHUYỂN NHANH"
     → ⚠ rehost là chiến lược
       NHANH NHẤT trong sáu chữ R

2. "GIẢM THIỂU thay đổi mã NGAY LẬP TỨC"
     → ⚠ bê nguyên ứng dụng lên
       máy ảo, không sửa mã

⚠ Rehost làm gì:

Máy chủ vật lý tại chỗ
        ↓
    Chuyển gần như NGUYÊN TRẠNG
        ↓
Máy ảo trên Compute Engine
        ↓
    ⚠ Cùng hệ điều hành
    ⚠ Cùng phần mềm
    ⚠ Cùng cấu hình
    ⚠ KHÔNG sửa mã ứng dụng
        ↓
    → nhanh nhất, rủi ro thấp nhất

⚠ Đánh đổi phải biết:

ƯU
  ✔ nhanh nhất
  ✔ rủi ro thấp — ít thay đổi
  ✔ đội không phải học nhiều

⚠ NHƯỢC
  ⚠ KHÔNG tận dụng tính co giãn
  ⚠ Vẫn tự vá hệ điều hành
  ⚠ ⚠ Chi phí có khi CAO HƠN
    nếu bê nguyên máy thừa công suất
  ⚠ Nợ kỹ thuật đi theo lên đám mây

⚠ Gần trùng với #13280 (lô 139) — đề đó là công ty phải ra khỏi trung tâm dữ liệu gấp vì hết hạn thuê, và cùng khoá Rehost. Hoàn toàn nhất quán.

⚠ Đối chiếu #13297 (lô 140) — đề đó khoá Replatform vì công ty chủ động đổi CSDL sang Cloud SQL có quản lý. Ở đây họ giảm thiểu thay đổi, nên là rehost. Khác nhau ở MỨC ĐỘ thay đổi.

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

  • B (Refactor) — phương án gần nhất về mặt "cũng là chiến lược di cư", nhưng nó là viết lại kiến trúc cho đám mây: lợi ích lớn nhất nhưng chậm nhất, trái hẳn mục tiêu "di chuyển nhanh, ít thay đổi mã".

  • A (Retire) — bỏ hẳn ứng dụng. Ở đây họ đang chuyển nó đi.

  • C (Reimagine) — không phải một chiến lược trong bộ "6 R" chuẩn; từ gần nghĩa là Refactor / Re-architect.

Ghi nhớ

⚠ Bộ "6 R" — bảng phải thuộc: | Chiến lược | Nội dung | |---|---| | ⚠ Rehost | ⚠ bê nguyên lên VM — NHANH nhất, lợi ích ít nhất | | Replatform | chỉnh nhẹ để dùng dịch vụ có quản lý | | Refactor | ⚠ viết lại theo kiến trúc đám mây — CHẬM nhất, lợi ích lớn nhất | | Repurchase | thay bằng SaaS | | Retire | ⚠ bỏ hẳn — thường 10–20% ứng dụng không ai dùng | | Retain | tạm giữ lại tại chỗ |

Từ khoá nhận diện:

"nhanh, ít thay đổi nhất" → Rehost "đổi sang dịch vụ có quản lý" → Replatform "tách microservices, viết lại" → Refactor "mua SaaS thay thế" → Repurchase "không ai dùng nữa" → Retire

⚠ "Chuyển trước, tối ưu sau" Điểm
Rehost là bước một, không phải đích
Sau khi lên đám mây có số liệu và thời gian để tối ưu
Thứ tự thường thấy rehost → replatform → refactor
⚠ Rủi ro rehost xong rồi DỪNG — nợ kỹ thuật ở lại mãi
Chữa ⚠ lên kế hoạch tối ưu NGAY khi lập kế hoạch di cư
Công cụ di cư của Google Cloud Công cụ
Migrate to Virtual Machines ⚠ di cư VM từ VMware, AWS, Azure
Migration Center ⚠ kiểm kê và đánh giá TRƯỚC
Database Migration Service CSDL
Storage Transfer Service dữ liệu tệp
Transfer Appliance dữ liệu rất lớn, ngoại tuyến
⚠ Sai lầm hay gặp khi rehost Sai lầm
Bê nguyên kích cỡ máy cũ ⚠ máy cũ vốn đã thừa công suất
Không tắt máy dev ngoài giờ
Không mua cam kết dài hạn
Không đo lại sau khi chuyển
Hệ quả ⚠ hoá đơn cao hơn chi phí cũ → kết luận sai rằng đám mây đắt
Việc phải làm ngay sau khi rehost Việc
Chạy 2–4 tuần rồi xem Recommender ⚠ rightsizing
Mua CUD cho phần chạy ổn định
Đặt lịch tắt môi trường không sản xuất
Bật giám sát và cảnh báo
Lên danh sách ứng viên replatform ⚠ CSDL thường là đầu tiên

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 vài tuần đầu sau khi rehost xong: đ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.

Câu 128 Trust and Security with Google Cloud

A company's Cloud Administrator is setting up access controls for a new project that will involve multiple teams: developers who need to deploy applications, data analysts who need to query databases, and finance staff who need to view billing information.

To adhere to the principle of "least privilege," what is the best practice the administrator should follow when granting these users access to Google Cloud resources?

  1. A Grant permissions to groups of users rather than individuals, and assign the most specific, predefined role that meets their needs.
  2. B Create a single custom role with all possible permissions and assign it to everyone.
  3. C Allow all authenticated users from the company to have editor access to all projects.
  4. D Grant each user the Project Owner" role to ensure they never face permission issues."
Xem giải thích

Đáp án

A — Cấp quyền cho NHÓM người dùng thay vì từng cá nhân, và gán vai dựng sẵn CỤ THỂ nhất đủ đáp ứng nhu cầu.

Vì sao đúng

Phương án này gộp hai thực hành tốt nhất của IAM: quản theo nhóm và vai hẹp nhất đủ dùng.

⚠ Vì sao cấp cho NHÓM:

Cấp cho từng cá nhân
        ↓
    ⚠ Người mới vào → phải nhớ
      cấp đủ mọi quyền
    ⚠ Người chuyển bộ phận → phải
      nhớ gỡ hết quyền cũ
    ⚠ Người nghỉ việc → ⚠ quyền
      hay bị sót lại
        ↓
Cấp cho NHÓM
        ↓
    ⚠ Thêm/bớt người khỏi nhóm
      là xong
    ⚠ Rà soát dễ: xem nhóm nào
      có quyền gì

⚠ Vì sao vai DỰNG SẴN CỤ THỂ:

Ba nhóm trong đề, ba vai khác nhau:

LẬP TRÌNH VIÊN (triển khai ứng dụng)
    → `run.developer`,
      `compute.instanceAdmin.v1`

NHÀ PHÂN TÍCH (truy vấn CSDL)
    → ⚠ `bigquery.dataViewer` +
      `bigquery.jobUser`

NHÂN VIÊN TÀI CHÍNH (xem thanh toán)
    → ⚠ `billing.viewer`
        ↓
    ⚠ Mỗi nhóm CHỈ có đúng
      quyền mình cần

⚠ Vì sao ba phương án kia nguy hiểm:

"MỘT vai tuỳ biến chứa MỌI quyền
 gán cho tất cả"
    → ⚠ ngược hoàn toàn quyền tối thiểu

"Mọi người trong công ty có quyền
 EDITOR trên mọi project"
    → ⚠ ai cũng xoá được production

"Cấp PROJECT OWNER để không gặp
 vấn đề về quyền"
    → ⚠ tiện nhất và nguy hiểm nhất
    → Owner CẤP QUYỀN được cho
      người khác

Bổ sung cho #13268 và #13299 (lô 139) — hai câu đó về chọn vai cho một người cụ thể. Câu này về cách tổ chức phân quyền cho nhiều nhóm. Cả ba nhất quán về nguyên tắc quyền tối thiểu.

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

  • D (cấp Project Owner cho mọi người để tránh vướng quyền) — phương án gần nhất về mặt "giải quyết được vấn đề vận hành", và là cám dỗ thật trong thực tế. Nhưng Owner cho phép cấp quyền cho người khác và quản lý thanh toán — vi phạm nghiêm trọng nhất.

  • B (một vai tuỳ biến chứa mọi quyền) — đánh mất toàn bộ ý nghĩa của vai tuỳ biến, vốn sinh ra để thu hẹp quyền.

  • C (mọi người đều là Editor trên mọi project) — ai cũng sửa và xoá được mọi thứ, kể cả production.

Ghi nhớ

⚠ Thực hành tốt về IAM — bảng phải thuộc: | Thực hành | Nội dung | |---|---| | ⚠ Cấp cho NHÓM | dễ quản khi người vào ra | | ⚠ Vai DỰNG SẴN hẹp nhất | thay cho ba vai cơ bản | | Cấp ở cấp THẤP NHẤT đủ dùng | project thay vì tổ chức | | IAM Recommender | ⚠ gợi ý thu hẹp theo mức dùng thật | | IAM Conditions | quyền có thời hạn, theo IP | | Rà soát định kỳ | | | Bật audit log | |

Từ khoá nhận diện:

"quyền tối thiểu, nhiều nhóm khác nhau" → nhóm + vai dựng sẵn "chỉ xem" → Viewer hoặc vai viewer theo dịch vụ "cấp cho người ngoài" → ⚠ IAM Conditions có thời hạn "chặn hành vi ở mọi nơi" → Organization Policy

Ba loại vai IAM Loại
Vai cơ bản Owner / Editor / Viewer — ⚠ Google khuyên HẠN CHẾ dùng
⚠ Vai dựng sẵn ⚠ theo từng dịch vụ, hẹp hơn — NÊN dùng
Vai tuỳ biến hẹp nhất, ⚠ tốn công bảo trì
Vai dựng sẵn cho ba nhóm trong đề Nhóm
Lập trình viên run.developer, compute.instanceAdmin.v1, artifactregistry.writer
Nhà phân tích ⚠ bigquery.dataViewer + bigquery.jobUser
Tài chính ⚠ billing.viewer, billing.admin nếu cần quản
⚠ Lưu ý dataViewer không đủ để CHẠY truy vấn — cần thêm jobUser
⚠ Kế thừa quyền — điều dễ sai nhất Điểm
Tổ chức → Thư mục → Project → Tài nguyên
Cấp ở cấp trên ⚠ LAN XUỐNG mọi cấp dưới
Không có cách "trừ bớt" ở cấp dưới
Chữa cấp ở cấp thấp nhất đủ dùng
Ngoại lệ IAM Deny policy chặn tường minh
Quản nhóm bằng gì Công cụ
Google Groups ⚠ qua Cloud Identity hoặc Workspace
Đồng bộ từ hệ thống nhân sự Cloud Identity sync
Nhóm lồng nhau ⚠ quản theo phòng ban
Lợi ích người nghỉ việc → xoá khỏi nhóm → mất mọi quyền
⚠ Cạm bẫy "cấp Owner cho nhanh" Hậu quả
Owner tự cấp thêm quyền cho mình
Owner gỡ được quyền của người khác
Owner đụng được tài khoản thanh toán
Owner xoá được project
⚠ Thực tế đây là nguyên nhân gốc của rất nhiều sự cố

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu Owner | ⚠ càng ít càng tốt, thường chỉ 2–3 người | | Ai có quyền không dùng tới | IAM Recommender | | Quyền cấp cho cá nhân hay nhóm | rà chính sách IAM |

Và một phép thử nhanh để biết mô hình phân quyền có ổn không: hỏi xem khi một người nghỉ việc thì cần bao nhiêu thao tác để gỡ hết quyền của họ. Nếu câu trả lời là "xoá khỏi vài nhóm" thì mô hình đang tốt; nếu là "phải đi rà từng project" thì đó là dấu hiệu quyền đang được cấp cho cá nhân.

Câu 129 Digital Transformation with Google Cloud
A startup wants to launch a new mobile application but has very limited upfront capital to invest in physical hardware. Which statement best describes the primary financial advantage of using Google Cloud for this scenario?
  1. A It shifts the cost model from a large, upfront Capital Expenditure (CapEx) to a pay-as-you-go Operational Expenditure (OpEx).
  2. B It allows the startup to make a large initial investment in servers, which is considered a Capital Expenditure (CapEx).
  3. C It completely eliminates all IT infrastructure costs for the startup.
  4. D It mandates a fixed monthly cost, regardless of the actual usage of the application.
Xem giải thích

Đáp án

A — Nó chuyển mô hình chi phí từ một khoản chi phí vốn (CapEx) lớn trả trước sang chi phí vận hành (OpEx) trả theo mức dùng.

Vì sao đúng

Đây là lợi thế tài chính quan trọng nhất với một startup có rất ít vốn ban đầu — đúng tình huống đề mô tả.

⚠ Hai mô hình với một startup:

MUA MÁY CHỦ (CapEx)
    → ⚠ bỏ ra vài trăm triệu NGAY
    → ⚠ đọng vốn vào tài sản
    → ⚠ phải đoán nhu cầu 3 năm tới
        ↓
    Ứng dụng không thành công
        ↓
    ⚠ mất trắng khoản đầu tư

ĐÁM MÂY (OpEx)
    → ⚠ KHÔNG cần vốn ban đầu
    → trả theo mức dùng thật
        ↓
    Ứng dụng không thành công
        ↓
    ⚠ chỉ mất vài tháng tiền thuê
    → dùng vốn cho sản phẩm và
      con người

⚠ Vì sao điều này quyết định với startup:

Vốn của startup là HỮU HẠN
        ↓
    ⚠ Mỗi đồng bỏ vào máy chủ
      là một đồng KHÔNG dùng để
      tuyển người hoặc làm marketing
        ↓
    Đám mây:
    ⚠ chi phí hạ tầng BÁM THEO
      số người dùng thật
        ↓
    → ít người dùng, chi phí thấp
    → đông người dùng, doanh thu
      cũng tăng theo

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

"Cho phép đầu tư lớn ban đầu
 vào máy chủ, tức là CapEx"
    → ⚠ ĐẢO NGƯỢC chiều

"LOẠI BỎ HOÀN TOÀN mọi chi phí
 hạ tầng CNTT"
    → ⚠ SAI: vẫn có hoá đơn hằng tháng

"BẮT BUỘC chi phí cố định hằng tháng
 bất kể mức dùng"
    → ⚠ SAI: đám mây tính theo
      mức dùng thật

⚠ Gần trùng với #13291 (lô 139) — đề đó cũng hỏi thay đổi cách hạch toán khi rời trung tâm dữ liệu, và cùng khoá CapEx → OpEx. Hoàn toàn nhất quán.

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

  • D (bắt buộc chi phí cố định hằng tháng) — phương án gần nhất về mặt "cũng nói về chi phí định kỳ", nhưng sai bản chất: đám mây tính theo mức dùng thật, tháng ít dùng thì trả ít. (Có mô hình cam kết như CUD, nhưng đó là lựa chọn để giảm giá, không phải bắt buộc.)

  • B (cho phép đầu tư lớn ban đầu, tức CapEx) — đảo ngược chiều hoàn toàn.

  • C (loại bỏ hoàn toàn mọi chi phí hạ tầng) — không đúng: chi phí chuyển 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 mua 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:

"ít vốn ban đầu, trả theo mức dùng" → OpEx, lợi thế của đám mây "mua máy chủ, đầu tư trước" → CapEx "tổng chi phí sở hữu" → TCO "cam kết 1–3 năm để giảm giá" → CUD

⚠ Lợi ích tài chính khác cho startup Lợi ích
Không phải đoán nhu cầu tương lai ⚠ mở rộng khi có khách
Chi phí bám theo doanh thu
Có chương trình tín dụng cho startup ⚠ Google for Startups Cloud Program
Hạn mức miễn phí (Free Tier) nhiều dịch vụ có
Thử nghiệm rẻ, thất bại rẻ
⚠ Mặt trái của OpEx phải biết Mặt trái
Chi phí có thể TRÔI ⚠ không ai chịu trách nhiệm thì tăng dần
Khó dự báo hơn biến động theo lưu lượng
Dễ quên tài nguyên đang chạy
Chữa ⚠ ngân sách + cảnh báo + nhãn ngay từ đầu
Việc startup nên làm ngay Việc
Đặt ngân sách và cảnh báo ⚠ trước khi tạo tài nguyên
Gắn nhãn mọi tài nguyên
Dùng serverless co về 0 ⚠ hợp nhất với giai đoạn đầu
Đặt max-instances chặn hoá đơn bất ngờ
Xem Recommender hằng tháng
Đăng ký chương trình startup tín dụng miễn phí
Khi nào nên cân nhắc CUD Trường hợp
Đã có tải ổn định vài tháng ⚠ đừng cam kết quá sớm
Biết rõ mức dùng tối thiểu
Cam kết 1 năm linh hoạt hơn 3 năm
⚠ Với startup mới serverless thường tốt hơn cam kết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí có bám theo lưu lượng không | ⚠ so đường chi phí với đường người dùng | | Có tài nguyên nào chạy mà không ai dùng không | Recommender | | Ngân sách đã đặt chưa | trang Billing |

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.

Câu 130 Modernize Infrastructure and Applications with Google Cloud
A company wants to modernize a monolithic legacy application. The plan is to break it down into smaller, independent components and completely rewrite them using modern, cloud-native principles to achieve maximum scalability and efficiency. Which migration strategy does this represent?
  1. A Retain
  2. B Refactor / Reimagine
  3. C Rehost
  4. D Replatform
Xem giải thích

Đáp án

B — Refactor / Reimagine.

Vì sao đúng

Đề nêu ba đặc điểm, và cụm quyết định là "VIẾT LẠI HOÀN TOÀN":

⚠ Ba đặc điểm ↔ refactor:

1. "TÁCH khối nguyên thành các
    thành phần NHỎ, ĐỘC LẬP"
     → microservices

2. ⚠ "VIẾT LẠI HOÀN TOÀN theo
    nguyên tắc CLOUD-NATIVE"
     → ⚠ cụm này loại thẳng
       rehost và replatform

3. "đạt khả năng MỞ RỘNG và
    HIỆU QUẢ TỐI ĐA"
     → mục tiêu của refactor

⚠ Ba mức thay đổi — nhìn cạnh nhau:

REHOST
    bê nguyên lên VM
    ⚠ không sửa mã
        ↓
REPLATFORM
    đổi sang dịch vụ có quản lý
    ⚠ sửa nhẹ (chuỗi kết nối)
        ↓
⚠ REFACTOR
    ⚠ VIẾT LẠI kiến trúc
    ⚠ tách microservices
    ⚠ dùng container, serverless,
      dịch vụ có quản lý
        ↓
    → công sức lớn nhất,
      lợi ích lớn nhất

⚠ Cái giá của refactor:

⚠ Mất hàng tháng tới hàng năm
⚠ Rủi ro cao — viết lại là
  cơ hội tạo lỗi mới
⚠ Cần đội có kỹ năng cloud-native
⚠ Phải chạy song song hai hệ thống
  trong giai đoạn chuyển
        ↓
    → chỉ đáng cho ứng dụng
      ⚠ CỐT LÕI và SỐNG LÂU

Hoàn chỉnh bộ 6R cùng #13370 (cùng lô, Rehost) và #13297 (lô 140, Replatform). Cả ba nhất quán. Quy tắc: không sửa mã → rehost; sửa nhẹ để dùng dịch vụ có quản lý → replatform; viết lại kiến trúc → refactor.

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

  • D (Replatform) — phương án gần nhất: cũng là hiện đại hoá và cũng có thay đổi. Nhưng replatform chỉnh nhẹ (đổi CSDL sang Cloud SQL chẳng hạn) mà giữ nguyên kiến trúc; đề nói "viết lại hoàn toàn" và "tách thành thành phần độc lập".

  • C (Rehost) — bê nguyên trạng lên máy ảo, không sửa mã. Ngược hẳn.

  • A (Retain) — giữ lại tại chỗ, không di cư gì cả.

Ghi nhớ

⚠ Bộ "6 R" — bảng phải thuộc: | Chiến lược | Công sức | Lợi ích | |---|---|---| | Retire | ⚠ thấp nhất — bỏ hẳn | rất lớn nếu đúng | | Rehost | thấp | ít nhất | | Replatform | vừa | ⚠ điểm ngọt | | ⚠ Refactor | ⚠ cao nhất | ⚠ lớn nhất | | Repurchase | vừa | thay bằng SaaS | | Retain | không | giữ nguyên tại chỗ |

Từ khoá nhận diện:

"viết lại, tách microservices, cloud-native" → Refactor "đổi sang dịch vụ có quản lý, không sửa mã" → Replatform "bê nguyên lên VM" → Rehost "bỏ hẳn" → Retire "mua SaaS" → Repurchase

Refactor đem lại gì Lợi ích
Mở rộng ngang thật sự ⚠ nhân từng phần, không nhân cả khối
Triển khai độc lập sửa một dịch vụ không đụng dịch vụ khác
Cô lập lỗi một phần hỏng không sập cả hệ thống
Dùng dịch vụ có quản lý ít việc vận hành
Chi phí tối ưu hơn serverless co về 0
Đội làm việc song song mỗi đội một dịch vụ
⚠ Khi nào KHÔNG nên refactor Trường hợp
Ứng dụng sắp bị thay thế ⚠ refactor rồi bỏ là lãng phí
Hạn chót gấp rehost trước
Đội chưa có kỹ năng cloud-native
Ứng dụng ổn định, ít thay đổi ⚠ refactor không đem lại gì
Nguyên tắc refactor thứ bạn sẽ còn sửa nhiều trong nhiều năm
Cách refactor an toàn — Strangler Fig Bước
Đặt một lớp mặt tiền trước khối cũ
Tách từng tính năng ra dịch vụ mới ⚠ từng phần một
Chuyển dần lưu lượng sang dịch vụ mới
Khối cũ teo dần rồi bỏ
⚠ Lợi ích không có "ngày X" đầy rủi ro
Đích đến cloud-native Thành phần
Container đóng gói nhất quán
GKE hoặc Cloud Run chạy
Pub/Sub giao tiếp bất đồng bộ
Dịch vụ CSDL có quản lý Cloud SQL, Spanner, Firestore
CI/CD tự động Cloud Build, Cloud Deploy
Quan sát được Monitoring, Logging, Trace

Ba câu hỏi kiểm chứng trước khi refactor: | Câu hỏi | Nếu... | |---|---| | Ứng dụng này còn sống bao lâu nữa | dưới 2 năm → ⚠ đừng refactor | | Có bao nhiêu thay đổi mỗi tháng | rất ít → lợi ích thấp | | Đội có kỹ năng chưa | chưa → đào tạo trước |

Và một chiến lược thực tế được nhiều tổ chức chọn: rehost trước để ra khỏi trung tâm dữ liệu, rồi refactor dần từng phần. Nó tách được hai rủi ro lớn ra khỏi nhau — rủi ro di cư và rủi ro viết lại — thay vì gánh cả hai cùng lúc trong một dự án duy nhất.