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

Đáp án

D — Điện toán serverless.

Vì sao đúng

Đề nêu ba yêu cầu, và serverless là mô hình duy nhất đáp ứng đủ cả ba:

⚠ Ba yêu cầu ↔ serverless:

1. LƯU LƯỢNG KHÓ ĐOÁN
   (hàng nghìn người giờ cao điểm,
    gần như không ai ban đêm)
     → ⚠ tự mở rộng TỨC THÌ,
       không cần cấu hình trước

2. TẬP TRUNG VIẾT MÃ,
   KHÔNG QUẢN HẠ TẦNG
     → không máy chủ, không bản vá

3. ⚠ GIẢM CHI PHÍ LÚC RẢNH
     → CO VỀ 0 — không request
       thì gần như không tốn tiền

⚠ Đường chi phí — điểm khác biệt lớn nhất:

MÁY ẢO CHẠY 24/7
Chi phí ┤████████████████████
        └────────────────────
        ⚠ Trả tiền cả lúc 3h sáng
          không ai dùng

SERVERLESS
Chi phí ┤██▁▁▁████▁▁▁██▁▁▁
        └────────────────────
        ⚠ Trả theo REQUEST và
          thời gian chạy thật
        ⚠ Cuối tuần gần như 0 đồng

⚠ Vì sao "mở rộng thủ công" không cứu được:

IaaS + mở rộng THỦ CÔNG
        ↓
    Lưu lượng tăng đột ngột
        ↓
    ⚠ Phải có NGƯỜI bấm thêm máy
    ⚠ Máy khởi động mất vài phút
        ↓
    → người dùng đã gặp lỗi
      trước khi máy sẵn sàng
        ↓
    Serverless: mở rộng trong
    vài trăm mili-giây, tự động

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

• A (IaaS với mở rộng thủ công) — phương án gần nhất vì nó có mở rộng, nhưng thủ công nghĩa là chậm và cần người trực. Với lưu lượng khó đoán, đó là công thức của sự cố. Và máy vẫn tốn tiền khi rảnh.

• B (máy ảo truyền thống chạy 24/7) — trả tiền cho toàn bộ thời gian nhàn rỗi, đúng thứ đề muốn tránh, và vẫn phải quản hệ điều hành.

• C (máy chủ vật lý riêng) — đắt nhất, kém linh hoạt nhất, và phải mua cho mức đỉnh.

Ghi nhớ

⚠ Bốn đặc điểm của serverless — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Không quản máy chủ | nhà cung cấp lo hết | | Tự mở rộng | theo lưu lượng thật, tức thì | | ⚠ Co về 0 | không dùng thì gần như không tốn tiền | | Trả theo mức dùng | theo request và thời gian chạy |

Từ khoá nhận diện:

"lưu lượng thất thường, co về 0, chỉ viết mã" → serverless "cần kiểm soát hệ điều hành" → IaaS "nhiều container phụ thuộc nhau" → GKE "tải ổn định, chạy liên tục" → ⚠ máy ảo có cam kết dài hạn có khi RẺ HƠN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí lúc rảnh có gần 0 không | billing report theo ngày | | Cold start có ảnh hưởng người dùng không | đo độ trễ p99 | | Có mở rộng kịp lúc cao điểm không | ⚠ thử tải trước khi ra mắt |

Và một chi tiết cấu hình nên xem lại sớm với mọi dịch vụ serverless: giới hạn số instance tối đa. Tự mở rộng không giới hạn nghe rất hay cho tới khi một vòng lặp lỗi hoặc một đợt tấn công tạo ra hàng chục nghìn lượt gọi — và hoá đơn cuối tháng trở thành sự cố nghiêm trọng hơn cả sự cố ban đầu.

Đáp án

B — Phân cấp tài nguyên kết hợp chính sách IAM ở cấp tổ chức.

Vì sao đúng

Đề đòi hai thứ cùng lúc: cấp quyền một lần cho MỌI project, nhưng chỉ đúng một loại quyền (tường lửa), không kèm quyền vào dữ liệu.

⚠ Phân cấp tài nguyên của Google Cloud:

        ORGANIZATION
              │
    ┌─────────┼─────────┐
 Folder     Folder    Folder
Marketing  Finance     R&D
    │         │          │
 Projects  Projects   Projects
    │         │          │
 Tài nguyên (VM, bucket, CSDL)
        ↓
    ⚠ Quyền cấp ở cấp trên
      LAN XUỐNG mọi cấp dưới

⚠ Cách làm đúng cho đội bảo mật:

Cấp tại ORGANIZATION:
    roles/compute.securityAdmin
        ↓
    ⚠ Quyền này cho phép:
      - tạo, sửa, xoá LUẬT TƯỜNG LỬA
      - quản lý SSL policy
        ↓
    ⚠ Quyền này KHÔNG cho phép:
      - đọc dữ liệu trong BigQuery
      - đọc đối tượng trong Cloud Storage
      - vào bên trong máy ảo
        ↓
    → cấp MỘT LẦN, áp cho MỌI project
    → ⚠ project mới tạo cũng
      TỰ ĐỘNG có quyền này

⚠ Vì sao "cấp từng project" không dùng được:

Cấp thủ công ở từng project
        ↓
    ⚠ Hàng chục, hàng trăm project
    ⚠ Project MỚI thì QUÊN cấp
      → có lỗ hổng tường lửa
        mà không ai canh
    ⚠ Gỡ quyền khi người rời đội
      phải làm ở từng nơi
        ↓
    → không mở rộng được,
      và dễ sai

Xem thêm #13268 (cùng lô này) — về quyền tối thiểu và vai dựng sẵn. Câu này là ứng dụng của cùng nguyên tắc ở quy mô toàn tổ chức: chọn vai hẹp, nhưng cấp ở cấp cao.

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

• A (cấp vai IAM ở từng project) — phương án gần nhất và kỹ thuật thì làm được, nhưng không mở rộng nổi: phải lặp lại ở mọi project, và project mới sẽ bị bỏ sót. Đề nói rõ là muốn kiểm soát tập trung.

• C (hạn ngạch tài nguyên) — giới hạn số lượng tài nguyên được tạo, không liên quan gì tới quyền.

• D (ngân sách Cloud Billing) — cảnh báo về chi tiêu, không phải cơ chế phân quyền.

Ghi nhớ

⚠ Phân cấp tài nguyên — bảng phải thuộc: | Cấp | Vai trò | |---|---| | Organization | ⚠ gốc — nơi đặt chính sách toàn công ty | | Folder | nhóm theo phòng ban, môi trường, hoặc đội | | Project | ⚠ ranh giới TÍNH TIỀN, hạn ngạch, API | | Resource | VM, bucket, dataset | | ⚠ Quy tắc | quyền LAN XUỐNG, không lan lên |

Từ khoá nhận diện:

"áp cho MỌI project, kiểm soát tập trung" → IAM ở cấp tổ chức hoặc thư mục "chặn hành vi ở mọi nơi, kể cả Owner" → Organization Policy "chặn dữ liệu rò ra ngoài vành đai" → VPC Service Controls "chỉ một project" → IAM ở cấp project

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền ở cấp tổ chức | gcloud organizations get-iam-policy | | Vai đó có kèm quyền đọc dữ liệu không | đọc danh sách quyền của vai trong tài liệu | | Project mới có kế thừa đúng không | tạo thử một project và kiểm tra |

Và một nguyên tắc gọn để nhớ khi thiết kế phân quyền ở quy mô lớn: vai càng rộng thì cấp càng thấp, vai càng hẹp thì cấp càng cao. Một vai chuyên biệt như quản trị tường lửa cấp ở cấp tổ chức là hợp lý; còn vai Editor cấp ở cùng chỗ đó thì là một sự cố bảo mật đang chờ xảy ra.

Đáp án

A — Xác thực (Authentication) rồi phân quyền (Authorization).

Vì sao đúng

Hai hành động trong đề diễn ra theo đúng thứ tự kinh điển của mọi hệ thống bảo mật.

⚠ Hai bước, hai câu hỏi khác nhau:

BƯỚC 1 — nhập tên đăng nhập và mật khẩu
        ↓
    ⚠ AUTHENTICATION (xác thực)
    → "BẠN LÀ AI?"
    → chứng minh danh tính
        ↓
BƯỚC 2 — hệ thống kiểm chính sách xem
         người này có được đọc tệp không
        ↓
    ⚠ AUTHORIZATION (phân quyền)
    → "BẠN ĐƯỢC LÀM GÌ?"
    → kiểm tra quyền

⚠ Thứ tự không thể đảo:

Chưa biết bạn là ai
        ↓
    ⚠ thì không thể tra xem
      bạn được phép làm gì
        ↓
    → AuthN LUÔN đi trước AuthZ
        ↓
    Mẹo nhớ:
    ⚠ chữ N trước chữ Z
      trong bảng chữ cái
    (AuthN → AuthZ)

⚠ Bốn chữ A của bảo mật:

AUTHENTICATION  — bạn là ai
AUTHORIZATION   — bạn được làm gì
AUDITING        — ⚠ bạn ĐÃ làm gì
ACCOUNTING      — bạn dùng bao nhiêu
        ↓
    Ba chữ đầu là bộ ba
    kiểm soát truy cập

⚠ Vì sao mã hoá không phải bước ở đây:

Mã hoá (encryption)
    → bảo vệ NỘI DUNG dữ liệu
    → chạy SUỐT quá trình,
      không phải một bước
      trong luồng đăng nhập
        ↓
    ⚠ Nó song song với hai bước trên,
      không nối tiếp

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

• C (phân quyền rồi xác thực) — đảo ngược thứ tự. Không thể kiểm tra quyền của một người mà bạn chưa biết là ai.

• B (kiểm toán rồi phân quyền) — kiểm toán là ghi lại sau khi việc đã xảy ra, không phải bước đăng nhập.

• D (xác thực rồi mã hoá) — đúng vế đầu nhưng sai vế sau: hành động thứ hai trong đề là kiểm tra chính sách quyền, không phải mã hoá.

Ghi nhớ

⚠ Ba khái niệm kiểm soát truy cập — bảng phải thuộc: | Khái niệm | Câu hỏi | Trên Google Cloud | |---|---|---| | Authentication (AuthN) | "Bạn là ai?" | Cloud Identity, Google Account, service account | | Authorization (AuthZ) | "Bạn được làm gì?" | IAM roles và policies | | Auditing | "Bạn đã làm gì?" | Cloud Audit Logs |

Từ khoá nhận diện:

"đăng nhập, mật khẩu, MFA, chứng minh danh tính" → xác thực "vai trò, quyền, được phép hay không" → phân quyền "ai đã xoá cái này lúc nào" → kiểm toán "bảo vệ nội dung dữ liệu" → mã hoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bắt buộc MFA chưa | Admin console — chính sách 2SV | | Có tài khoản dịch vụ nào dùng khoá tệp không | ⚠ chuyển sang Workload Identity | | Ai đã truy cập dữ liệu nhạy cảm | Data Access audit logs |

Và một sai lầm đáng chú ý mà nhiều tổ chức mắc: lo rất kỹ cho xác thực nhưng buông lỏng phân quyền. Bắt buộc MFA cho toàn công ty rồi cấp vai Editor cho tất cả mọi người là đã khoá cửa trước rất chắc — nhưng để ngỏ mọi cánh cửa bên trong.

Đáp án

A — Công cụ chọn vùng (region selection tool) trong Google Cloud Console.

Vì sao đúng

Google gắn thông tin phát thải ngay tại nơi bạn phải ra quyết định — màn hình chọn vùng — thay vì bắt bạn tra cứu ở một báo cáo riêng.

⚠ Huy hiệu lá cây trong console:

Khi tạo tài nguyên, chọn vùng:

  us-central1 (Iowa)        🍃 Low CO₂
  europe-north1 (Finland)   🍃 Low CO₂
  asia-southeast1 (Singapore)
  ...
        ↓
    ⚠ Huy hiệu 🍃 = vùng có tỉ lệ
      năng lượng KHÔNG CARBON cao
        ↓
    → quyết định ngay tại chỗ,
      không cần rời màn hình

⚠ Vì sao vùng lại quyết định phát thải:

Trung tâm dữ liệu dùng điện
từ LƯỚI ĐIỆN ĐỊA PHƯƠNG
        ↓
    Lưới ở Phần Lan: nhiều thuỷ điện,
    hạt nhân, gió → rất sạch
        ↓
    Lưới ở nơi khác: nhiều than
        ↓
    ⚠ CÙNG một khối lượng tính toán
      có thể phát thải chênh nhau
      NHIỀU LẦN chỉ vì chọn vùng khác
        ↓
    → đây là đòn bẩy ĐƠN GIẢN NHẤT
      để giảm phát thải

⚠ Ba phương án kia không hỗ trợ quyết định này:

CLOUD BILLING COST TABLE
    → ⚠ giá tiền, không phải carbon
    → vùng rẻ chưa chắc sạch

COMPLIANCE REPORTS MANAGER
    → tải chứng nhận ISO, SOC
    → không có số liệu môi trường

CLOUD MONITORING DASHBOARD
    → hiệu năng và tình trạng hệ thống
    → không đo phát thải

Bổ sung cho #13271 (cùng lô này): Carbon Footprint dùng để ĐO phát thải đã phát sinh; công cụ chọn vùng dùng để QUYẾT ĐỊNH trước khi triển khai. Một cái nhìn về sau, một cái nhìn về trước — cả hai đều thuộc trụ cột Sustainability ở #13262 (lô 138).

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

• B (bảng chi phí của Cloud Billing) — phương án gần nhất vì cũng giúp so sánh giữa các vùng, nhưng nó so giá tiền. Vùng rẻ nhất không đồng nghĩa với vùng sạch nhất.

• C (Compliance Reports Manager) — nơi tải báo cáo tuân thủ và chứng nhận. Không có dữ liệu carbon theo vùng.

• D (bảng điều khiển Cloud Monitoring) — theo dõi hiệu năng và tình trạng hệ thống.

Ghi nhớ

⚠ Công cụ bền vững — dùng lúc nào: | Công cụ | Thời điểm | |---|---| | Huy hiệu vùng phát thải thấp | ⚠ TRƯỚC khi triển khai — lúc chọn vùng | | Google Cloud Region Picker | so sánh giá, độ trễ, carbon cùng lúc | | Carbon Footprint | ⚠ SAU khi dùng — đo và báo cáo | | Active Assist | liên tục — tìm lãng phí |

Từ khoá nhận diện:

"chọn vùng ít carbon nhất" → công cụ chọn vùng / Region Picker "đo phát thải của mình" → Carbon Footprint "tìm tài nguyên nằm không" → Active Assist / Recommender "tải chứng nhận ISO 27001" → Compliance Reports Manager

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vùng đang dùng sạch tới đâu | xem huy hiệu và CFE% trong Region Picker | | Chuyển vùng thì giá đổi thế nào | Pricing calculator | | Độ trễ có chấp nhận được không | ⚠ đo thật từ nơi người dùng ở |

Và một cách tiếp cận thực dụng cho mục tiêu bền vững: bắt đầu từ những tải công việc không ai nhìn thấy. Huấn luyện mô hình, xử lý lô ban đêm, sao lưu — chúng không nhạy cảm với độ trễ, nên chuyển sang vùng sạch là quyết định gần như không có nhược điểm nào.

Đáp án

C — Cho phép công ty cấp phát và mở rộng tài nguyên nhanh chóng, theo nhu cầu, để chịu được các đợt tăng lưu lượng.

Vì sao đúng

Đề mô tả một vấn đề rất cụ thể và đáp án phải giải đúng vấn đề đó: web sập vì vượt năng lực máy chủ, và mua máy mới mất hàng tuần.

⚠ Vấn đề và lời giải:

TẠI CHỖ
  Đợt khuyến mãi → lưu lượng tăng vọt
        ↓
    ⚠ Máy chủ hết công suất → SẬP
        ↓
    Đặt mua máy mới
        ↓
    ⚠ Duyệt ngân sách → đặt hàng
      → giao → lắp → cấu hình
      = HÀNG TUẦN
        ↓
    Đợt khuyến mãi đã kết thúc

ĐÁM MÂY
    ⚠ Thêm năng lực trong VÀI PHÚT
    ⚠ Hoặc TỰ ĐỘNG mở rộng
      theo lưu lượng thật
    ⚠ Xong đợt thì TỰ THU LẠI

⚠ Hai từ khoá then chốt:

SCALABILITY (khả năng mở rộng)
    → tăng năng lực khi cần

ELASTICITY (tính co giãn)
    → ⚠ tăng VÀ GIẢM tự động
      theo nhu cầu thật
        ↓
    Đám mây cho cả hai
        ↓
    ⚠ Tại chỗ buộc phải mua cho
      MỨC ĐỈNH và trả tiền cho nó
      quanh năm

⚠ Vì sao phương án A sai chiều:

"Chuyển từ OpEx BIẾN ĐỔI
 sang CapEx CỐ ĐỊNH"
        ↓
    ⚠ NGƯỢC HOÀN TOÀN
        ↓
    Đám mây chuyển
    CapEx (mua máy) → OpEx (thuê)
        ↓
    Phương án này đảo hai từ

Liên quan #13244 (lô 138) — câu đó hỏi rủi ro của việc ở lại hạ tầng tại chỗ (mất thị phần vì chậm và không mở rộng nổi). Câu này hỏi lợi ích của đám mây giải đúng vấn đề đó. Hai câu nhìn cùng một chuyện từ hai chiều, hoàn toàn nhất quán.

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

• A (chuyển từ OpEx biến đổi sang CapEx cố định) — phương án gần nhất về mặt thuật ngữ, nhưng đảo ngược chiều: đám mây chuyển CapEx sang OpEx, không phải ngược lại. Và dù có đúng chiều thì nó cũng không giải quyết việc web sập.

• B (kiểm soát vật lý phần cứng) — đó là đặc điểm của hạ tầng tại chỗ, chính là thứ họ đang có và đang gây ra vấn đề.

• D (đảm bảo giảm số mối đe doạ bảo mật) — đám mây không đảm bảo điều đó; theo mô hình trách nhiệm chung, khách hàng vẫn phải tự lo phần của mình. Và cũng không liên quan tới việc web sập vì tải cao.

Ghi nhớ

⚠ Sáu lợi ích cốt lõi của đám mây — bảng nên thuộc: | Lợi ích | Nội dung | |---|---| | Co giãn (elasticity) | ⚠ tăng và giảm tự động theo nhu cầu — đề này | | Nhanh (agility) | triển khai trong phút thay vì tuần | | Trả theo mức dùng | CapEx → OpEx | | Vươn ra toàn cầu | vùng mới trong vài phút | | Độ tin cậy | đa vùng, đa zone | | Dịch vụ có quản lý | đội tập trung vào sản phẩm |

Từ khoá nhận diện:

"tăng đột biến, cao điểm, mở rộng theo nhu cầu" → elasticity "mua máy mất hàng tuần" → agility / tốc độ cấp phát "trả theo mức dùng" → CapEx → OpEx "mất thị phần vì chậm" → ⚠ rủi ro của việc KHÔNG lên đám mây

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có mở rộng kịp không | thử tải mô phỏng đỉnh | | Quota có đủ không | ⚠ xin nâng quota TRƯỚC sự kiện | | Chi phí đỉnh là bao nhiêu | ước tính và đặt ngân sách cảnh báo |

Và một bước chuẩn bị rất hay bị bỏ sót trước mọi đợt bán hàng lớn: kiểm tra hạn ngạch tài nguyên. Đám mây mở rộng được không có nghĩa là tài khoản của bạn được phép mở rộng tới đó — và phát hiện ra trần quota vào đúng giờ cao điểm thì cũng chẳng khác gì hết máy chủ.

Đáp án

C — Folder (thư mục).

Vì sao đúng

Folder là tầng nhóm trong phân cấp tài nguyên của Google Cloud, sinh ra đúng để làm việc đề mô tả: gom nhiều project lại và áp chính sách chung cho cả nhóm.

⚠ Phân cấp tài nguyên với folder:

        ORGANIZATION
              │
    ┌─────────┼─────────┐
 FOLDER    FOLDER    FOLDER
Finance   Marketing  Engineering
    │         │          │
 projects  projects   projects
        ↓
    ⚠ Chính sách đặt ở folder
      LAN XUỐNG mọi project bên trong
    ⚠ Project MỚI thêm vào folder
      TỰ ĐỘNG kế thừa

⚠ Áp đúng hai yêu cầu của đề:

"KIỂM SOÁT MẠNG RIÊNG cho Finance"
        ↓
    Đặt Organization Policy ở
    folder Finance:
      - cấm tạo IP công khai
      - giới hạn vùng được dùng
        ↓
    ⚠ Áp cho MỌI project của Finance,
      KHÔNG ảnh hưởng phòng khác

"TÁCH THANH TOÁN cho Engineering"
        ↓
    Gắn folder Engineering vào
    tài khoản thanh toán riêng,
    hoặc bóc tách chi phí theo folder

⚠ Vì sao label không thay được folder:

LABEL
    → cặp khoá–giá trị gắn lên tài nguyên
    → ⚠ RẤT tốt để BÓC TÁCH CHI PHÍ
      và tìm kiếm
        ↓
    ⚠ NHƯNG label KHÔNG phải
      ranh giới quản trị
    ⚠ KHÔNG cấp quyền theo label được
    ⚠ KHÔNG áp Organization Policy
      theo label được
        ↓
    → label để BÁO CÁO,
      folder để QUẢN TRỊ

Xem thêm #13275 (cùng lô này) — về cấp quyền IAM ở cấp tổ chức. Folder là tầng ở giữa: hẹp hơn tổ chức, rộng hơn project — đúng chỗ cho chính sách theo phòng ban.

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

• B (Labels) — phương án gần nhất và bị nhầm nhiều nhất: label rất hữu ích để nhóm chi phí trong báo cáo, nhưng nó chỉ là siêu dữ liệu. Không cấp quyền, không áp chính sách theo label được.

• A (Networks) — VPC là tài nguyên mạng, không phải tầng tổ chức project.

• D (Resource Quotas) — giới hạn số lượng tài nguyên dùng được, không nhóm project.

Ghi nhớ

⚠ Bốn cấp phân cấp tài nguyên — bảng phải thuộc: | Cấp | Vai trò | |---|---| | Organization | gốc, chính sách toàn công ty | | Folder | ⚠ nhóm project theo phòng ban / môi trường — có thể LỒNG NHAU | | Project | ⚠ ranh giới TÍNH TIỀN, hạn ngạch, bật API | | Resource | VM, bucket, dataset | | ⚠ Quy tắc | chính sách LAN XUỐNG, project mới tự kế thừa |

Từ khoá nhận diện:

"nhóm project theo phòng ban, áp chính sách chung" → Folder "bóc tách chi phí, gắn thẻ để báo cáo" → Label "giới hạn số lượng tài nguyên" → Quota "ranh giới thanh toán" → Project và Billing Account

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cây tổ chức đang ra sao | gcloud projects list và trang Manage resources | | Chính sách nào đang áp | tab Organization Policies ở từng folder | | Chi phí theo phòng ban | billing report, nhóm theo folder hoặc label |

Và một quyết định nên làm cho tử tế ngay từ đầu: thiết kế cây folder trước khi tạo hàng loạt project. Chuyển project giữa các folder về sau là làm được, nhưng chính sách kế thừa sẽ đổi theo, và việc phát hiện ra điều đó khi hệ thống đã chạy thường không dễ chịu chút nào.

Đáp án

B — Rehost (thường gọi là "lift and shift").

Vì sao đúng

Đề nêu hai điều kiện quyết định: ra khỏi trung tâm dữ liệu GẤP và thay đổi ÍT NHẤT có thể, chạy trên máy ảo mô phỏng máy chủ cũ.

⚠ Rehost là 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 trong bốn chiến lược

⚠ Vì sao hợp với tình huống của đề:

Hợp đồng thuê chỗ SẮP HẾT HẠN
        ↓
    ⚠ Ràng buộc là THỜI GIAN,
      không phải tối ưu chi phí
        ↓
    Refactor mất hàng tháng tới hàng năm
    Rehost mất vài tuần
        ↓
    → chuyển đi trước,
      tối ưu sau
        ↓
    ⚠ Đây là chiến lược hợp lý,
      không phải lựa chọn tồi

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

ƯU
  ✔ nhanh nhất
  ✔ rủi ro thấp — ít thay đổi
  ✔ không cần viết lại mã
  ✔ đội không phải học nhiều

⚠ NHƯỢC
  ⚠ KHÔNG tận dụng được
    tính co giãn của đám mây
  ⚠ Vẫn phải quản hệ điều hành,
    bản vá
  ⚠ Chi phí có khi CAO HƠN
    nếu chỉ bê nguyên máy to
  ⚠ Nợ kỹ thuật đi theo lên đám mây

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

• C (Replatform) — phương án gần nhất: cũng là di cư có ít thay đổi, nhưng có chỉnh sửa để dùng dịch vụ có quản lý (ví dụ đổi CSDL tự quản sang Cloud SQL). Đề nói "ít thay đổi NHẤT có thể" và "mô phỏng máy chủ cũ" — đó là rehost thuần.

• A (Refactor) — viết lại kiến trúc cho phù hợp đám mây. Lợi ích lớn nhất nhưng chậm nhất, không hợp với hạn chót gấp.

• D (Retire) — bỏ hẳn ứng dụng vì không còn cần. Đề nói họ đang chuyển ứng dụng, không bỏ.

Ghi nhớ

⚠ Các chiến lược di cư ("6 R") — bảng phải thuộc: | Chiến lược | Nội dung | |---|---| | Rehost (lift and shift) | ⚠ chuyển nguyên trạng 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 / Re-architect | ⚠ 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 có 10–20% ứng dụng không ai dùng | | Retain | giữ lại tại chỗ (chưa chuyển) |

Từ khoá nhận diện:

"ít thay đổi nhất, gấp, mô phỏng máy cũ" → Rehost "đổi CSDL sang dịch vụ có quản lý" → Replatform "tách microservice, viết lại" → Refactor "thay bằng phần mềm mua sẵn" → Repurchase

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ó phù hợp không | ⚠ Recommender — rightsizing sau 2–4 tuần chạy thật | | Chi phí so với trước ra sao | so hoá đơn với chi phí vận hành cũ |

Và một việc rất nên 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 để dự phòng, 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 công suất chưa bao giờ được dùng tới.

Đáp án

C — Cloud Run.

Vì sao đúng

Đề nêu bốn đặc điểm, và Cloud Run là sản phẩm duy nhất khớp cả bốn:

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

1. DỊCH VỤ WEB ĐÓNG GÓI TRONG CONTAINER
     → ⚠ Cloud Run chạy container
       bất kỳ, ngôn ngữ nào cũng được

2. KHÔNG TRẠNG THÁI (stateless)
     → đúng mô hình Cloud Run

3. LƯU LƯỢNG RẤT THẤT THƯỜNG
     → mở rộng từ 0 tới hàng nghìn
       instance trong vài giây

4. ⚠ "TRẢ ĐÚNG BẰNG KHÔNG khi không
    ai dùng"
     → ⚠ CO VỀ 0 — đây là điều
       kiện loại trừ then chốt

⚠ Vì sao ba phương án kia không co về 0:

GKE
    → ⚠ CỤM luôn chạy, node luôn tính tiền
    → kể cả không có pod nào

COMPUTE ENGINE
    → ⚠ máy ảo chạy là tính tiền
    → phải tự tắt bằng tay

APP ENGINE STANDARD
    → ⚠ CÓ co về 0 được
    → nhưng chỉ chạy MỘT SỐ NGÔN NGỮ
      trong môi trường bị giới hạn
    → đề nói rõ là đã có CONTAINER
      → Cloud Run là lựa chọn tự nhiên

⚠ App Engine Standard và Cloud Run — khác biệt thật:

App Engine Standard
    ✔ co về 0
    ⚠ ngôn ngữ và runtime BỊ GIỚI HẠN
    ⚠ không chạy container tuỳ ý

Cloud Run
    ✔ co về 0
    ✔ ⚠ chạy BẤT KỲ container nào
    ✔ dựa trên Knative — chuẩn mở
        ↓
    Đề đã có sẵn container
        ↓
    → Cloud Run

Xem thêm #13274 (cùng lô này) — câu đó hỏi mô hình (serverless), câu này hỏi sản phẩm cụ thể. Hai câu nhất quán.

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

• D (App Engine Standard) — phương án gần nhất và cũng co về 0. Nhưng nó có giới hạn về ngôn ngữ và runtime, còn đề nói dịch vụ đã đóng gói trong container — Cloud Run được thiết kế chính xác cho tình huống đó.

• A (GKE) — mạnh cho hệ nhiều dịch vụ, nhưng cụm luôn tính tiền kể cả lúc rảnh. Quá nặng cho một dịch vụ đơn giản.

• B (Compute Engine) — máy ảo, không serverless, phải tự quản hệ điều hành và tự lo mở rộng.

Ghi nhớ

⚠ Bốn lựa chọn tính toán — bảng phải thuộc: | Lựa chọn | Co về 0? | Dùng khi | |---|---|---| | Cloud Run | ⚠ CÓ | container không trạng thái, tải thất thường | | Cloud Run Functions | CÓ | hàm nhỏ theo sự kiện | | App Engine Standard | CÓ | ứng dụng web, runtime được hỗ trợ | | GKE | ⚠ KHÔNG (cụm luôn chạy) | nhiều dịch vụ phụ thuộc nhau | | Compute Engine | KHÔNG | cần kiểm soát hệ điều hành |

Từ khoá nhận diện:

"container + co về 0 + tải thất thường" → Cloud Run "phản ứng khi có sự kiện" → Cloud Run Functions "hàng chục container phụ thuộc nhau" → GKE "phần mềm cũ, cần kiểm soát OS" → Compute Engine

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 độ trễ p99 sau khoảng rảnh | | Có bị mở rộng vô hạn không | ⚠ kiểm max-instances |

Và một tham số nên đặt ngay khi triển khai dịch vụ Cloud Run đầu tiên: max-instances. Khả năng mở rộng không giới hạn là điểm mạnh cho tới khi một vòng lặp gọi nhầm tạo ra hàng chục nghìn instance — và lúc đó thứ bị đánh sập không phải hệ thống mà là ngân sách.

Đáp án

A — Triển khai ứng dụng trên nhiều zone trong cùng một vùng (region).

Vì sao đúng

Đề nói rất rõ hai điều, và chính vế thứ hai quyết định đáp án:

⚠ Đọc kỹ hai vế của đề:

VẾ 1: "sống sót khi MẤT MỘT
       TRUNG TÂM DỮ LIỆU"
        ↓
    → cần nhiều hơn một zone

VẾ 2: ⚠ "KHÔNG cần chống thảm hoạ
       thiên nhiên ảnh hưởng CẢ MỘT
       KHU VỰC ĐÔ THỊ"
        ↓
    → ⚠ KHÔNG cần đa vùng
        ↓
VẾ 3: "TIẾT KIỆM CHI PHÍ NHẤT"
        ↓
    → ⚠ đa vùng là thừa và ĐẮT
        ↓
    Kết luận: ĐA ZONE trong MỘT VÙNG

⚠ Zone là gì:

    REGION (ví dụ asia-southeast1)
       ├── zone a   ⚠ điện riêng
       ├── zone b   ⚠ mạng riêng
       └── zone c   ⚠ làm mát riêng
        ↓
    ⚠ Mỗi zone thường là MỘT hoặc
      vài trung tâm dữ liệu độc lập
        ↓
    Một zone chết → hai zone kia
    vẫn phục vụ
        ↓
    ⚠ Nhưng cả ba nằm trong
      cùng khu vực địa lý

⚠ Vì sao đa zone rẻ hơn đa vùng nhiều:

ĐA ZONE
  ✔ truyền dữ liệu giữa zone
    ⚠ RẺ hoặc miễn phí
  ✔ độ trễ RẤT THẤP (< 1ms)
  ✔ sao chép đồng bộ dễ dàng
  ✔ nhiều dịch vụ hỗ trợ SẴN

ĐA VÙNG
  ⚠ phí truyền dữ liệu giữa vùng
  ⚠ độ trễ hàng chục mili-giây
  ⚠ hạ tầng gần như NHÂN ĐÔI
  ⚠ kiến trúc phức tạp hơn nhiều

⚠ Đối chiếu #13247 (lô 138) — đề đó khoá ĐA VÙNG vì yêu cầu là sống sót khi mất cả một region. Câu này khoá đa zone vì đề nói rõ KHÔNG cần chống thảm hoạ cả khu vực và đòi tiết kiệm nhất. Hai câu KHÔNG mâu thuẫn — chúng khác nhau ở phạm vi sự cố cần chống.

Cách đọc đề để không nhầm: tìm cụm chỉ cấp độ sự cố. "Mất một trung tâm dữ liệu / một zone" → đa zone. "Mất cả một region / thảm hoạ khu vực" → đa vùng.

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

• C (đa vùng, tách biệt địa lý) — phương án gần nhất, và đúng cho một đề khác. Ở đây nó chống được nhiều hơn mức cần thiết với chi phí cao hơn hẳn — vi phạm yêu cầu "tiết kiệm nhất".

• B (một máy ảo preemptible duy nhất) — preemptible/Spot có thể bị thu hồi bất cứ lúc nào, và một máy thì không có dự phòng nào. Đi ngược mục tiêu.

• D (kết nối đám mây lai) — nói về kết nối tới hạ tầng tại chỗ, không phải chiến lược chịu lỗi trong đám mây.

Ghi nhớ

⚠ Ba cấp triển khai và mức chống lỗi: | Cấp | Chống được | Chi phí | |---|---|---| | Zonal | không gì — mất zone là mất hết | thấp nhất | | Regional (đa zone) | ⚠ mất một ZONE — đề này | trung bình | | Multi-region | mất cả một REGION | cao nhất |

Từ khoá nhận diện:

"mất một trung tâm dữ liệu / một zone" → đa zone trong một vùng "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 "người dùng toàn cầu, độ trễ thấp khắp nơi" → đa vùng

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 — VM, đĩa, CSDL | | Có thật sự chịu được không | ⚠ diễn tập tắt một zone | | Quota ở zone khác có đủ không | kiểm trước, không đợi lúc sự cố |

Và một câu hỏi rất đáng đặt ra khi ai đó đề xuất kiến trúc đa vùng: chúng ta đang chống lại sự cố nào? Đa vùng là công cụ đúng cho thảm hoạ cấp khu vực, nhưng nếu rủi ro thật sự chỉ là hỏng phần cứng hay mất một zone thì nó là một khoản chi gấp đôi để mua thứ mình không cần.

Đáp án

D — 1: SaaS, 2: PaaS, 3: IaaS.

Vì sao đúng

Ba dịch vụ trong đề là ví dụ chuẩn cho ba mô hình, và chính lời mô tả trong đề đã chỉ ra từng cái.

⚠ Ghép từng dịch vụ:

1. GOOGLE WORKSPACE (Gmail, Docs)
     → phần mềm DÙNG NGAY
     → không viết mã, không quản gì
     → ⚠ SaaS

2. APP ENGINE
     → "triển khai mã tuỳ biến mà
        KHÔNG quản máy chủ hay
        hệ điều hành"
     → ⚠ PaaS — đúng định nghĩa

3. COMPUTE ENGINE
     → "tự tạo và quản máy ảo với
        TOÀN QUYỀN kiểm soát hệ điều hành"
     → ⚠ IaaS

⚠ Bảng trách nhiệm — thứ phải thuộc lòng:

                IaaS     PaaS     SaaS
Ứng dụng        BẠN      BẠN     n.c.cấp
Dữ liệu         BẠN      BẠN     n.c.cấp
Runtime         BẠN     n.c.cấp  n.c.cấp
Middleware      BẠN     n.c.cấp  n.c.cấp
Hệ điều hành    BẠN     n.c.cấp  n.c.cấp
Ảo hoá         n.c.cấp  n.c.cấp  n.c.cấp
Máy chủ        n.c.cấp  n.c.cấp  n.c.cấp
Lưu trữ, mạng  n.c.cấp  n.c.cấp  n.c.cấp
        ↓
    ⚠ Càng sang phải, bạn càng
      quản ít, nhưng cũng càng
      ít kiểm soát

⚠ Ví von cho dễ nhớ — bữa ăn:

TẠI CHỖ   → tự trồng rau, tự nấu ở nhà
IaaS      → mua nguyên liệu, tự nấu
PaaS      → ⚠ mua đồ nấu sẵn,
             chỉ hâm và bày biện
SaaS      → ⚠ ra nhà hàng ăn

Nhất quán với #13272 (cùng lô này) — câu đó hỏi chọn mô hình nào cho một startup, câu này hỏi ghép sản phẩm vào mô hình. Cùng một khung khái niệm.

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

• A (PaaS / SaaS / IaaS) — đúng vị trí thứ ba nhưng hoán đổi hai vị trí đầu: Workspace không phải PaaS (bạn không triển khai mã lên đó), và App Engine không phải SaaS (bạn có viết mã).

• B và C — đều xếp sai ở nhiều vị trí.

Ghi nhớ

⚠ Ba mô hình dịch vụ — bảng phải thuộc: | Mô hình | Bạn quản | Ví dụ Google | |---|---|---| | IaaS | hệ điều hành trở lên | Compute Engine | | PaaS | chỉ mã và dữ liệu | App Engine, Cloud Run | | SaaS | không gì cả | Google Workspace, Looker Studio |

Từ khoá nhận diện:

"toàn quyền kiểm soát hệ điều hành" → IaaS "chỉ đẩy mã lên" → PaaS "dùng phần mềm có sẵn" → SaaS "co về 0, trả theo request" → serverless (một dạng PaaS)

Ba câu hỏi kiểm chứng: | Câu hỏi | Trả lời dẫn tới | |---|---| | Tôi có phải vá hệ điều hành không? | có → IaaS | | Tôi có viết mã ứng dụng không? | không → SaaS | | Tôi có quản máy chủ không? | không, nhưng có viết mã → PaaS |

Và một cách nhìn giúp trả lời nhanh mọi câu hỏi kiểu này: đếm xem bạn phải chịu trách nhiệm tới tầng nào trong chồng công nghệ. Càng lên cao thì càng ít việc phải làm và càng ít quyền kiểm soát — mọi tranh luận IaaS/PaaS/SaaS rốt cuộc chỉ là chọn điểm dừng trên chồng đó.