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

Đáp án

A — Resource Quotas (hạn ngạch tài nguyên).

Vì sao đúng

Đề đòi một giới hạn CỨNG về số lượng tài nguyên, và đó chính xác là việc của quota.

⚠ Quota chặn cứng:

Đặt quota: CPUs = 2 (hoặc số instance)
        ↓
    Sinh viên tạo máy ảo thứ ba
        ↓
    ⚠ LỖI NGAY LẬP TỨC:
      "Quota exceeded"
        ↓
    ⚠ Máy KHÔNG được tạo
    ⚠ Không có cách nào lách
        ↓
    → đúng thứ đề gọi là
      "hard limit"

⚠ Vì sao ngân sách KHÔNG chặn được:

Cloud Billing Budget
        ↓
    Đạt 50%, 90%, 100%
        ↓
    ⚠ CHỈ GỬI CẢNH BÁO
    ⚠ Dịch vụ VẪN chạy
    ⚠ Sinh viên VẪN tạo được máy
        ↓
    → không phải "hard limit"

⚠ Đối chiếu #13255 (lô 138) — đề đó khoá budget threshold rules, vì yêu cầu là được THÔNG BÁO ở các mốc phần trăm. Câu này khoá quota, vì yêu cầu là CHẶN CỨNG số lượng tài nguyên. Hai câu KHÔNG mâu thuẫn — chúng hỏi hai cơ chế khác nhau.

Cách phân biệt: "báo cho tôi biết khi..." → budget alert. "không cho phép tạo quá..." → quota.

⚠ Vì sao IAM cũng không giải quyết:

IAM quyết định ĐƯỢC HAY KHÔNG
được tạo máy ảo
        ↓
    ⚠ Nhưng KHÔNG đếm SỐ LƯỢNG
        ↓
    Có quyền → tạo được 2 máy
              → cũng tạo được 200 máy
        ↓
    → IAM là công tắc bật/tắt,
      quota là cái van định lượng

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

• B (ngân sách Cloud Billing) — phương án gần nhất vì cũng nhằm kiểm soát chi tiêu. Nhưng ngân sách chỉ cảnh báo, không chặn. Đề nói rõ là muốn "hard limit".

• C (chính sách IAM) — kiểm soát ai được làm gì, không kiểm soát bao nhiêu.

• D (Cloud Monitoring) — theo dõi và cảnh báo, không chặn hành động nào.

Ghi nhớ

⚠ Bốn công cụ kiểm soát — bảng phải thuộc: | Công cụ | Tác dụng | |---|---| | Resource Quota | ⚠ CHẶN CỨNG số lượng tài nguyên | | Cloud Billing budget | ⚠ chỉ CẢNH BÁO theo % chi tiêu | | IAM | ai được làm gì | | Organization Policy | ⚠ CẤM một loại hành vi, kể cả với Owner |

Từ khoá nhận diện:

"không cho tạo quá N tài nguyên" → quota "báo cho tôi khi tiêu tới X%" → budget alert "cấm tạo IP công khai ở mọi project" → Organization Policy "ai được tạo máy ảo" → IAM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quota hiện tại là bao nhiêu | trang IAM & Admin → Quotas | | Đã hạ ở mọi vùng chưa | ⚠ lọc theo vùng, đừng chỉ xem một | | Sinh viên có bị chặn thật không | thử tạo máy thứ ba bằng tài khoản thử |

Và một cách phân biệt gọn để không bao giờ nhầm hai công cụ này: quota nói "không", ngân sách nói "coi chừng". Khi đề bài dùng những chữ như hard limit, prevent, not allowed thì câu trả lời gần như luôn là quota hoặc Organization Policy, chứ không phải cảnh báo ngân sách.

Đáp án

D — Cloud SQL.

Vì sao đúng

Đề nêu bốn yêu cầu, và Cloud SQL khớp cả bốn một cách thẳng thắn:

⚠ Bốn yêu cầu ↔ Cloud SQL:

1. CSDL GIAO DỊCH cho WordPress
     → WordPress vốn chạy trên MySQL

2. QUAN HỆ, CÓ QUẢN LÝ HOÀN TOÀN
     → Google lo vá, sao lưu, HA

3. ⚠ HỖ TRỢ MySQL
     → Cloud SQL có MySQL, PostgreSQL,
       SQL Server

4. ⚠ TỐI ƯU CHO MỘT VÙNG,
   ĐƠN GIẢN VÀ TIẾT KIỆM NHẤT
     → đúng vị trí của Cloud SQL

⚠ Di cư WordPress gần như không phải sửa gì:

WordPress tại chỗ
    → MySQL tự quản
        ↓
    Database Migration Service
        ↓
Cloud SQL for MySQL
        ↓
    ⚠ Chỉ đổi chuỗi kết nối
      trong wp-config.php
    ⚠ KHÔNG sửa mã WordPress
    ⚠ KHÔNG đổi schema

⚠ Vì sao Spanner là thừa ở đây:

SPANNER
    ✔ quan hệ, ACID
    ✔ mở rộng ngang toàn cầu
        ↓
    ⚠ Nhưng đề nói rõ:
      "TỐI ƯU CHO MỘT VÙNG"
      "ĐƠN GIẢN và TIẾT KIỆM NHẤT"
        ↓
    ⚠ Spanner ĐẮT hơn nhiều
    ⚠ Và WordPress KHÔNG được
      chứng nhận chạy trên Spanner
        ↓
    → dùng Spanner ở đây là
      trả tiền cho thứ không cần

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

• C (Cloud Spanner) — phương án gần nhất vì cũng là CSDL quan hệ có quản lý. Nhưng nó sinh ra cho quy mô toàn cầu với nhất quán mạnh, đắt hơn đáng kể, và đề chỉ cần một vùng cùng tiết kiệm nhất.

• B (BigQuery) — kho phân tích (OLAP). WordPress cần đọc ghi giao dịch độ trễ thấp, hoàn toàn sai loại.

• A (Cloud Storage) — lưu tệp, không phải cơ sở dữ liệu. (Nó có vai trò cho ảnh và tệp tải lên của WordPress, nhưng không thay được CSDL.)

Ghi nhớ

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

Từ khoá nhận diện:

"nâng và chuyển MySQL/WordPress" → Cloud SQL "nhiều châu lục, nhất quán mạnh" → Spanner "đơn giản nhất, tiết kiệm nhất, một vùng" → ⚠ thường là Cloud SQL "báo cáo, phân tích" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần HA không | ⚠ production thì có, dev thì không | | Kích cỡ máy có hợp không | Cloud Monitoring — CPU và bộ nhớ | | Sao lưu có chạy không | ⚠ và đã thử KHÔI PHỤC bao giờ chưa |

Và một việc mà rất nhiều đội bỏ qua cho tới ngày cần đến: thử khôi phục từ bản sao lưu. Cloud SQL sao lưu tự động rất đáng tin, nhưng một bản sao lưu chưa từng được khôi phục thử vẫn chỉ là một giả thiết — và ngày mất dữ liệu là ngày tệ nhất để kiểm chứng giả thiết đó.

Đáp án

B — "BigQuery chủ yếu được thiết kế cho tải OLTP như thanh toán trong thương mại điện tử." Đây là mệnh đề KHÔNG đúng.

Vì sao đúng

⚠ Đây là câu hỏi PHỦ ĐỊNH — đề hỏi mệnh đề nào SAI. Ba mệnh đề còn lại đều mô tả đúng BigQuery.

⚠ BigQuery là OLAP, không phải OLTP:

OLTP (Online Transaction Processing)
    → nhiều thao tác NHỎ, rất nhanh
    → đọc/ghi vài dòng, độ trễ mili-giây
    → ⚠ ví dụ: thanh toán đơn hàng
    → công cụ: Cloud SQL, Spanner,
      Firestore, Bigtable

OLAP (Online Analytical Processing)
    → ⚠ ÍT truy vấn nhưng mỗi truy vấn
      QUÉT RẤT NHIỀU dữ liệu
    → độ trễ tính bằng GIÂY
    → ví dụ: doanh thu theo vùng
      trong ba năm
    → công cụ: ⚠ BIGQUERY

⚠ Vì sao BigQuery không làm được việc thanh toán:

Thanh toán đơn hàng cần:
    - ⚠ giao dịch ACID trên vài dòng
    - ⚠ độ trễ dưới 100ms
    - ⚠ hàng nghìn thao tác/giây
        ↓
    BigQuery:
    ⚠ độ trễ truy vấn tính bằng GIÂY
    ⚠ tính tiền theo BYTE QUÉT
    ⚠ ⚠ có giới hạn số lần
      UPDATE/DELETE mỗi bảng
        ↓
    → sai hoàn toàn loại tải công việc

⚠ Ba mệnh đề kia đều ĐÚNG:

A. "SQL nhanh trên hàng petabyte"
     → ⚠ ĐÚNG — đây là thế mạnh chính

C. "TÁCH lưu trữ và tính toán,
    mở rộng độc lập"
     → ⚠ ĐÚNG — kiến trúc cốt lõi:
       Colossus lưu, Dremel tính,
       Jupiter nối hai bên

D. "Serverless, không phải
    cấp phát hạ tầng"
     → ⚠ ĐÚNG — không có cụm nào
       để quản

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

(Ở câu phủ định, "sai" nghĩa là mệnh đề đó đúng về BigQuery, nên không phải đáp án.)

• A — BigQuery thật sự chạy được truy vấn SQL trên hàng petabyte trong vài giây.
• C — kiến trúc tách lưu trữ khỏi tính toán là đặc điểm nền tảng của BigQuery.
• D — BigQuery là serverless: không cụm, không máy chủ, không cấp phát.

Ghi nhớ

⚠ OLTP và OLAP — bảng phải thuộc: | | OLTP | OLAP | |---|---|---| | Mục đích | giao dịch | phân tích | | Truy vấn | nhiều, nhỏ | ⚠ ít, quét rất nhiều | | Độ trễ | mili-giây | giây | | Dữ liệu | hiện hành | lịch sử | | Sản phẩm | Cloud SQL, Spanner, Firestore, Bigtable | ⚠ BigQuery |

Từ khoá nhận diện:

"thanh toán, đặt hàng, cập nhật hồ sơ" → OLTP "báo cáo, xu hướng, tổng hợp nhiều năm" → OLAP → BigQuery "tách lưu trữ và tính toán" → BigQuery "serverless kho dữ liệu" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu byte | ⚠ xem ước tính ở góc trên trước khi chạy | | Bảng đã phân vùng chưa | bq show — xem timePartitioning | | Ai đang tốn nhiều nhất | INFORMATION_SCHEMA.JOBS |

Và một thói quen nhỏ giúp tiết kiệm rất nhiều tiền trong BigQuery: luôn nhìn con số ước tính byte quét trước khi bấm chạy. Nó hiện sẵn trong giao diện, mất một giây để đọc, và là thứ duy nhất phân biệt một truy vấn vài xu với một truy vấn vài triệu đồng.

Đáp án

A — Replatform.

Vì sao đúng

Replatform nằm giữa rehost và refactor: có thay đổi, nhưng chỉ đủ để dùng dịch vụ có quản lý, không viết lại ứng dụng.

⚠ Đọc đề thấy đúng đặc trưng của replatform:

"THAY VÌ chuyển MySQL tự quản
 sang một máy ảo..."
        ↓
    ⚠ Đó chính là mô tả rehost
      bị BÁC BỎ

"...họ chuyển sang Cloud SQL
 có quản lý hoàn toàn"
        ↓
    ⚠ ĐỔI nền tảng chạy CSDL

"...KHÔNG thay đổi về căn bản
 mã của ứng dụng"
        ↓
    ⚠ KHÔNG phải refactor
        ↓
    → REPLATFORM

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

REHOST
  MySQL tự quản → MySQL trên VM
        ↓
    ⚠ vẫn tự vá, tự sao lưu,
      tự dựng HA

REPLATFORM             ← đề này
  MySQL tự quản → Cloud SQL
        ↓
    ⚠ chỉ đổi chuỗi kết nối
    ⚠ Google lo vá, sao lưu, HA

REFACTOR
  Ứng dụng khối → microservices,
  CSDL chia theo dịch vụ
        ↓
    ⚠ viết lại nhiều, mất hàng tháng

⚠ Vì sao replatform thường là điểm ngọt:

Công sức: vừa phải
    → đổi chuỗi kết nối, thử lại

Lợi ích: rất lớn
    → ⚠ bỏ hẳn việc vá CSDL
    → ⚠ có sao lưu tự động và PITR
    → ⚠ bật HA bằng một hộp kiểm
    → ⚠ read replica trong vài phút
        ↓
    → tỉ lệ lợi ích trên công sức
      cao nhất trong ba chiến lược

⚠ Đối chiếu #13280 (cùng lô này) — đề đó khoá Rehost vì công ty phải ra khỏi trung tâm dữ liệu gấp và muốn thay đổi ít nhất có thể, chạy trên VM mô phỏng máy chủ cũ. Câu này khoá Replatform vì họ chủ động đổi sang dịch vụ có quản lý. Hai câu KHÔNG mâu thuẫn — chúng khác nhau ở mức độ thay đổi.

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

• C (Rehost) — phương án gần nhất, và chính đề đã bác bỏ nó tường minh: "thay vì chuyển sang một máy ảo". Rehost là bê nguyên trạng lên VM.

• B (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, và dù sao cũng đòi viết lại — trái với "không đổi mã ứng dụng".

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

Ghi nhớ

⚠ Bộ "6 R" chiến lược di cư — 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ý — điểm ngọt | | Refactor | viết lại theo kiến trúc đám mây — 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:

"đổi sang dịch vụ có quản lý, không sửa mã" → Replatform "bê nguyên trạng, thay đổi ít nhất" → Rehost "tách microservices, viết lại" → Refactor "mua SaaS thay thế" → Repurchase

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phiên bản có tương thích không | kiểm phiên bản MySQL Cloud SQL hỗ trợ | | Plugin/extension có chạy không | ⚠ thử ở staging trước | | Hiệu năng có giữ nguyên không | đo trước và sau khi chuyển |

Và một quy tắc rất đáng theo khi lập kế hoạch di cư: đừng chuyển thứ không ai dùng. Mỗi tổ chức đều có một số ứng dụng vẫn chạy chỉ vì chưa ai dám tắt — và bước "retire" thường tiết kiệm nhiều thời gian hơn mọi kỹ thuật tối ưu khác cộng lại.

Đáp án

A — BigQuery.

Vì sao đúng

Đề mô tả đúng loại tải công việc mà BigQuery sinh ra để làm: truy vấn SQL phức tạp, trên nhiều terabyte dữ liệu lịch sử, để tìm xu hướng dài hạn.

⚠ Ba manh mối ↔ BigQuery:

1. "SQL PHỨC TẠP"
     → BigQuery hỗ trợ SQL chuẩn
       đầy đủ, có window function,
       CTE, mảng và cấu trúc lồng

2. "NHIỀU NĂM DỮ LIỆU, HÀNG TERABYTE"
     → ⚠ BigQuery quét hàng petabyte
       trong vài giây

3. "TÌM XU HƯỚNG VÀ MẪU DÀI HẠN"
     → ⚠ đây là PHÂN TÍCH (OLAP),
       không phải giao dịch

⚠ Vì sao BigQuery nhanh đến vậy:

LƯU TRỮ THEO CỘT
    → truy vấn 3 cột trong bảng
      có 200 cột
        ↓
    ⚠ chỉ đọc 3 cột đó
    ⚠ không đọc 197 cột còn lại
        ↓
XỬ LÝ SONG SONG QUY MÔ LỚN
    → ⚠ hàng nghìn slot cùng chạy
      một truy vấn
        ↓
TÁCH LƯU TRỮ VÀ TÍNH TOÁN
    → thêm sức tính toán mà
      không phải chuyển dữ liệu

⚠ Vì sao ba phương án kia không hợp:

CLOUD SQL
    → ⚠ CSDL GIAO DỊCH, một máy chủ
    → truy vấn quét terabyte sẽ
      chạy hàng giờ hoặc treo

CLOUD SPANNER
    → quan hệ, quy mô lớn ✔
    → ⚠ nhưng tối ưu cho GIAO DỊCH
    → phân tích nặng thì đắt và chậm
      hơn BigQuery nhiều

CLOUD STORAGE
    → ⚠ lưu TỆP, không truy vấn được
    → (BigQuery CÓ THỂ đọc dữ liệu ở đó
       qua bảng ngoài, nhưng engine
       phân tích vẫn là BigQuery)

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

• C (Cloud Spanner) — phương án gần nhất về mặt "quy mô lớn và SQL", nhưng Spanner tối ưu cho OLTP. Chạy phân tích nặng trên Spanner vừa chậm hơn vừa đắt hơn, và còn ảnh hưởng tới tải giao dịch đang chạy.

• B (Cloud SQL) — CSDL một máy chủ cho tải giao dịch. Không có kiến trúc song song để quét terabyte.

• D (Cloud Storage) — chỉ lưu tệp, tự nó không chạy được truy vấn SQL.

Ghi nhớ

⚠ Chọn công cụ theo loại tải — bảng phải thuộc: | Tải | Chọn | |---|---| | Phân tích, báo cáo, xu hướng | ⚠ BigQuery | | Giao dịch, một vùng | Cloud SQL | | Giao dịch, toàn cầu | Spanner | | Đọc/ghi khoá–giá trị cực nhanh | Bigtable | | Lưu tệp | Cloud Storage |

Từ khoá nhận diện:

"phân tích lịch sử, hàng terabyte, xu hướng" → BigQuery "thanh toán, đặt hàng" → Cloud SQL / Spanner "dashboard cho người dùng nghiệp vụ" → Looker trên BigQuery "dự báo bằng SQL" → BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu | ⚠ ước tính hiện ở góc trên | | Bảng đã phân vùng chưa | bq show | | Ai tốn nhiều nhất | INFORMATION_SCHEMA.JOBS |

Và một quyết định thiết kế nên làm ngay từ bảng đầu tiên: phân vùng theo cột ngày. Nó không tốn gì để bật lúc tạo bảng, nhưng thêm vào sau khi bảng đã có hàng tỉ dòng thì phải viết lại toàn bộ bảng — và cho tới lúc đó, mọi truy vấn đều đang quét nhiều hơn mức cần thiết.

Đáp án

C — Project Editor.

Vì sao đúng

Trong bốn vai được đưa ra, Editor là vai hẹp nhất mà vẫn đủ để nhà thầu làm được việc đề mô tả: cập nhật mã của ứng dụng chạy trên máy ảo Compute Engine.

⚠ So bốn vai với công việc cần làm:

BROWSER
    → ⚠ CHỈ xem cây phân cấp tài nguyên
    → không xem được nội dung
    → KHÔNG đủ

VIEWER
    → xem tài nguyên và cấu hình
    → ⚠ KHÔNG SỬA được gì
    → KHÔNG đủ để cập nhật mã

EDITOR                    ← đủ
    → xem + tạo + sửa + xoá tài nguyên
    → ⚠ triển khai được mã lên VM
    → ⚠ KHÔNG quản lý được QUYỀN
    → KHÔNG quản lý được thanh toán

OWNER
    → mọi quyền của Editor
    → ⚠ + CẤP QUYỀN cho người khác
    → ⚠ + quản lý thanh toán
    → QUÁ RỘNG cho nhà thầu tạm thời

⚠ Ranh giới quan trọng nhất giữa Editor và Owner:

EDITOR có thể đổi TÀI NGUYÊN
OWNER có thể đổi AI ĐƯỢC LÀM GÌ
        ↓
    ⚠ Owner tự cấp thêm quyền
      cho chính mình hoặc người khác
    ⚠ Owner gỡ được quyền của bạn
        ↓
    → tuyệt đối không cấp Owner
      cho người ngoài tổ chức

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

Trong thực tế, quyền tối thiểu thật sự cho việc này còn hẹp hơn Editor rất nhiều. Nhà thầu chỉ cần triển khai mã lên vài máy ảo, nên các vai dựng sẵn phù hợp hơn sẽ là:

• roles/compute.instanceAdmin.v1 — quản lý máy ảo
• roles/compute.osLogin hoặc osAdminLogin — đăng nhập SSH vào máy
• roles/iap.tunnelResourceAccessor — vào máy qua IAP mà không cần IP công khai

Editor cho quyền trên MỌI dịch vụ trong project — kể cả BigQuery, Cloud Storage, Pub/Sub — những thứ nhà thầu không cần đụng tới.

Nhưng các vai hẹp đó KHÔNG có trong danh sách phương án, và trong bốn vai cơ bản được đưa ra thì Editor là lựa chọn đúng. Khoá đáp án giữ nguyên là C. Quy tắc làm bài: chọn phương án phù hợp nhất CÓ TRONG DANH SÁCH — nhưng khi làm thật, hãy tìm vai dựng sẵn hẹp hơn.

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

• B (Project Viewer) — phương án gần nhất theo hướng "càng hẹp càng tốt", nhưng Viewer chỉ đọc. Nhà thầu sẽ không triển khai được bản cập nhật nào — quyền tối thiểu vẫn phải đủ để làm việc.

• D (Project Owner) — quá rộng: 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 nguyên tắc quyền tối thiểu.

• A (Project Browser) — chỉ cho xem cấu trúc phân cấp (danh sách project, folder), không xem được nội dung tài nguyên. Còn hẹp hơn Viewer.

Ghi nhớ

⚠ Các vai cơ bản của IAM — bảng phải thuộc: | Vai | Làm được gì | |---|---| | Browser | chỉ xem CÂY phân cấp | | Viewer | xem tài nguyên và cấu hình, KHÔNG sửa | | Editor | ⚠ xem + tạo + sửa + xoá, KHÔNG quản quyền | | Owner | ⚠ mọi thứ + CẤP QUYỀN + thanh toán | | ⚠ Google khuyến nghị | dùng vai DỰNG SẴN thay cho bốn vai này |

Từ khoá nhận diện:

"chỉ xem, kiểm toán" → Viewer "cần sửa và triển khai" → Editor (hoặc vai dựng sẵn hẹp hơn) "quản lý quyền cho người khác" → Owner "quyền tối thiểu trong thực tế" → ⚠ vai dựng sẵn theo dịch vụ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhà thầu đang có quyền gì | gcloud projects get-iam-policy | | Họ có dùng hết quyền đó không | ⚠ IAM Recommender sau vài tuần | | Quyền đã hết hạn chưa | kiểm IAM Conditions, hoặc lịch nhắc thủ công |

Và một việc nên làm cùng lúc với việc cấp quyền cho nhà thầu: đặt luôn ngày hết hạn. IAM Conditions cho phép ghi thẳng thời điểm quyền tự mất hiệu lực — và đó là cách duy nhất chắc chắn rằng một hợp đồng ba tháng không biến thành một tài khoản có quyền sửa production suốt ba năm.

Đáp án

A — Cloud Spanner.

Vì sao đúng

Đề nêu hai yêu cầu tuyệt đối, và điểm mấu chốt là chúng phải cùng tồn tại:

⚠ Hai yêu cầu, và vì sao chỉ Spanner có cả hai:

YÊU CẦU 1
  Quan hệ đầy đủ: SQL + giao dịch ACID
        ↓
    Cloud SQL   ✔
    Spanner     ✔
    Bigtable    ✘ (chỉ ACID trong 1 dòng)
    BigQuery    ✘ (không phải OLTP)

YÊU CẦU 2
  Mở rộng NGANG xuyên lục địa +
  nhất quán mạnh TOÀN CẦU
        ↓
    Cloud SQL   ✘ (chỉ mở rộng DỌC)
    Spanner     ✔
        ↓
    ⚠ GIAO của hai tập:
      CHỈ CÒN SPANNER

⚠ TrueTime — thứ làm nên điều bất thường này:

Định lý CAP nói: khi mạng phân mảnh,
phải chọn giữa nhất quán và sẵn sàng
        ↓
    Spanner không phá vỡ định lý,
    nhưng làm phân mảnh trở nên
    CỰC KỲ HIẾM
        ↓
    ⚠ Đồng hồ nguyên tử + GPS
      ở mọi trung tâm dữ liệu
    ⚠ Mạng riêng của Google
        ↓
    → nhất quán ngoại (external
      consistency): mọi giao dịch có
      THỨ TỰ TOÀN CỤC thống nhất

⚠ Vì sao sàn giao dịch cần chính xác điều đó:

Lệnh mua ở Tokyo và
lệnh bán ở New York
        ↓
    ⚠ Phải có MỘT thứ tự duy nhất
      mà cả hai nơi đều đồng ý
        ↓
    Nếu chỉ nhất quán cuối cùng
        ↓
    ⚠ Hai nơi thấy hai trạng thái
      sổ lệnh khác nhau
    ⚠ Khớp lệnh sai, đối soát sai

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

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

• B (Cloud SQL) — phương án gần nhất: thoả yêu cầu 1 (quan hệ, ACID) nhưng trượt yêu cầu 2. Nó mở rộng dọc, và bản sao xuyên vùng chỉ nhất quán cuối cùng.

• C (Cloud Bigtable) — thoả yêu cầu 2 một phần (mở rộng ngang) nhưng trượt yêu cầu 1: không phải quan hệ, không SQL đầy đủ, giao dịch chỉ trong một dòng.

• D (BigQuery) — có SQL và quy mô lớn, nhưng là kho phân tích, không phải CSDL giao dịch.

Ghi nhớ

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

Từ khoá nhận diện:

"quan hệ + nhiều châu lục + nhất quán mạnh" → ⚠ Spanner, luôn luôn "MySQL/PostgreSQL một vùng" → Cloud SQL "phi quan hệ + hàng triệu thao tác/giây" → Bigtable "phân tích lịch sử" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CPU có quá tải không | ⚠ giữ dưới 65% cho đa vùng | | Có hotspot không | Key Visualizer | | Truy vấn nào chậm | Query Insights |

Và một mẫu câu hỏi rất đáng nhận diện khi ôn thi: hễ đề liệt kê "quan hệ" và "toàn cầu" và "nhất quán mạnh" cùng một lúc thì đáp án là Spanner. Đó là sản phẩm duy nhất trong danh mục Google Cloud có cả ba, và các đề thi khai thác điều đó rất nhiều lần dưới những vỏ ngành nghề khác nhau.

Đáp án

A — Phishing (tấn công lừa đảo).

Vì sao đúng

Đề mô tả đúng ba yếu tố cấu thành một cuộc tấn công phishing: mạo danh một nguồn đáng tin, tạo cớ khẩn cấp, và lừa lấy thông tin đăng nhập qua một trang web giả.

⚠ Ba yếu tố trong đề:

1. MẠO DANH
     "email trông như từ bộ phận IT
      của công ty"
        ↓
2. CỚ HỢP LÝ VÀ KHẨN CẤP
     "cập nhật bảo mật BẮT BUỘC"
        ↓
3. THU THẬP THÔNG TIN ĐĂNG NHẬP
     "trang web GIẢ để đánh cắp
      tên đăng nhập và mật khẩu"
        ↓
    ⚠ Đây là định nghĩa của phishing:
      tấn công vào CON NGƯỜI,
      không phải vào hệ thống

⚠ Vì sao phishing hiệu quả đến vậy:

Không cần khai thác lỗ hổng nào
        ↓
    ⚠ Nó khai thác TÂM LÝ:
      - tin vào thẩm quyền (bộ phận IT)
      - sợ hậu quả ("bắt buộc")
      - vội vàng, không kiểm tra kỹ
        ↓
    → Mọi tường lửa và bản vá
      đều không giúp gì
        ↓
    ⚠ Đây là véc-tơ tấn công
      phổ biến nhất trong thực tế

⚠ Ba loại tấn công kia khác hẳn:

RANSOMWARE
    → mã độc MÃ HOÁ dữ liệu
      rồi đòi tiền chuộc
    → ⚠ phishing thường là
      CÁCH ransomware xâm nhập,
      nhưng là hai thứ khác nhau

MAN-IN-THE-MIDDLE
    → ⚠ kẻ tấn công CHẶN GIỮA
      hai bên đang liên lạc
    → nạn nhân không hề gõ gì
      vào trang giả

DDoS
    → dội lưu lượng làm dịch vụ sập
    → ⚠ không đánh cắp gì cả

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

• B (ransomware) — phương án gần nhất vì phishing thường là cửa vào của ransomware. Nhưng bản thân ransomware là mã độc mã hoá dữ liệu đòi tiền chuộc; đề chỉ mô tả bước đánh cắp thông tin đăng nhập.

• C (man-in-the-middle) — kẻ tấn công xen vào giữa một phiên liên lạc hợp lệ. Ở đây nạn nhân chủ động truy cập một trang giả.

• D (DDoS) — nhằm làm ngừng dịch vụ, không đánh cắp thông tin.

Ghi nhớ

⚠ Các loại tấn công phải phân biệt được: | Loại | Đặc điểm | |---|---| | Phishing | ⚠ email/tin nhắn giả mạo lừa lấy thông tin | | Spear phishing | ⚠ nhắm vào MỘT người cụ thể, có nghiên cứu trước | | Whaling | nhắm vào lãnh đạo cấp cao | | Vishing / Smishing | qua điện thoại / tin nhắn SMS | | Ransomware | mã hoá dữ liệu, đòi tiền chuộc | | Man-in-the-middle | chặn giữa hai bên liên lạc | | DDoS | dội lưu lượng làm ngừng dịch vụ | | Social engineering | ⚠ khái niệm bao trùm — thao túng con người |

Từ khoá nhận diện:

"email giả, trang đăng nhập giả" → phishing "dữ liệu bị mã hoá, đòi tiền chuộc" → ransomware "nghe lén, chặn giữa" → man-in-the-middle "làm sập bằng lưu lượng" → DDoS → Cloud Armor

Ba việc kiểm chứng cho một tổ chức: | Việc | Cách | |---|---| | Đã bắt buộc MFA chưa | Admin console | | Tài khoản quản trị đã dùng khoá phần cứng chưa | ⚠ ưu tiên nhóm này trước | | Nhân viên có nhận ra phishing không | diễn tập phishing nội bộ định kỳ |

Và một sự thật đáng suy nghĩ về bảo mật đám mây: kẻ tấn công hiếm khi phá vỡ mã hoá của Google — họ chỉ cần một nhân viên gõ mật khẩu vào một trang giả. Đó cũng là lý do khoá bảo mật phần cứng, thứ khiến trang giả không thể hoạt động dù nạn nhân có bấm vào, là khoản đầu tư bảo mật hiệu quả nhất trên mỗi đồng bỏ ra.

Đáp án

D — Tensor Processing Unit (TPU).

Vì sao đúng

Đề nêu ba đặc điểm, và cả ba chỉ đúng TPU: phần cứng độc quyền do Google tự thiết kế, tối ưu cho TensorFlow, và rút ngắn thời gian huấn luyện.

⚠ Ba manh mối ↔ TPU:

1. "PHẦN CỨNG ĐỘC QUYỀN của Google"
     → ⚠ TPU do Google tự thiết kế
     → CPU và GPU là của Intel/AMD/NVIDIA

2. "TỐI ƯU CAO ĐỘ CHO TENSORFLOW"
     → ⚠ TPU sinh ra cho TensorFlow
       (nay hỗ trợ cả JAX và PyTorch)

3. "GIẢM THỜI GIAN HUẤN LUYỆN
    TỪ TUẦN XUỐNG NGÀY"
     → mô hình rất lớn, rất phức tạp

⚠ Vì sao TPU nhanh cho học sâu:

Huấn luyện mạng nơ-ron chủ yếu là
NHÂN MA TRẬN khổng lồ, lặp đi lặp lại
        ↓
    CPU: vài chục lõi mạnh, đa dụng
        → linh hoạt, không chuyên
    GPU: hàng nghìn lõi nhỏ
        → tốt cho tính toán song song
    ⚠ TPU: MẠCH CHUYÊN DỤNG (ASIC)
        chỉ để nhân ma trận
        ↓
    ⚠ Systolic array — dữ liệu chảy
      qua mảng nhân mà không phải
      quay lại bộ nhớ liên tục
        ↓
    → hiệu suất trên mỗi watt
      cao hơn nhiều

⚠ Khi nào chọn cái nào:

CPU
  → mô hình nhỏ, tiền xử lý,
    suy luận đơn giản

GPU
  → ⚠ linh hoạt nhất: nhiều framework,
    nhiều kiểu mô hình
  → mô hình vừa, nghiên cứu đa dạng

TPU
  → ⚠ mô hình RẤT LỚN,
    huấn luyện dài ngày,
    kiến trúc phù hợp
  → hiệu quả chi phí cao nhất
    ở quy mô lớn

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

• B (GPU) — phương án gần nhất và thật sự dùng được cho việc này. Nhưng GPU không phải phần cứng độc quyền của Google (chủ yếu là NVIDIA), và không được thiết kế riêng cho TensorFlow. Đề nhấn mạnh cả hai điểm đó.

• C (CPU) — đa dụng, chậm hơn nhiều lần cho học sâu quy mô lớn.

• A (FPGA) — mạch lập trình lại được, không phải sản phẩm Google cung cấp cho khách hàng huấn luyện ML trên Google Cloud.

Ghi nhớ

⚠ Ba loại bộ xử lý cho ML — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | CPU | đa dụng, ít lõi mạnh — tiền xử lý, mô hình nhỏ | | GPU | ⚠ hàng nghìn lõi, linh hoạt, hỗ trợ mọi framework | | TPU | ⚠ ASIC của Google, chuyên nhân ma trận, quy mô rất lớn |

Từ khoá nhận diện:

"phần cứng độc quyền của Google, tối ưu cho TensorFlow" → TPU "linh hoạt, nhiều framework, CUDA" → GPU "mô hình nhỏ, tiền xử lý" → CPU "huấn luyện mô hình khổng lồ, tiết kiệm chi phí ở quy mô lớn" → TPU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nút thắt nằm ở đâu | ⚠ chạy profiler trước khi đổi phần cứng | | Mức sử dụng chip bao nhiêu | thấp nghĩa là nghẽn ở dữ liệu | | Chi phí mỗi lần huấn luyện | so giữa GPU và TPU trên cùng bài toán |

Và một lời nhắc thực tế trước khi ai đó đề xuất mua thêm phần cứng mạnh hơn: rất nhiều lần vấn đề không nằm ở chip. Nếu đường ống nạp dữ liệu không theo kịp, TPU đắt tiền sẽ ngồi chờ đúng như GPU rẻ hơn đã ngồi chờ — và profiler là thứ cho bạn biết điều đó trong mười phút.

Đáp án

C — Pub/Sub.

Vì sao đúng

Đề dùng đúng ba chữ mô tả Pub/Sub: bus thông điệp, bất đồng bộ, đáng tin cậy — và mục tiêu là giảm ràng buộc chặt (tight coupling) giữa các dịch vụ.

⚠ Trước và sau khi có Pub/Sub:

RÀNG BUỘC CHẶT
  user service
      ├── gọi HTTP → email service
      └── gọi HTTP → analytics service
        ↓
    ⚠ user service PHẢI BIẾT
      địa chỉ của cả hai
    ⚠ Một dịch vụ chết → đăng ký
      người dùng LỖI THEO
    ⚠ Thêm dịch vụ thứ ba
      → phải SỬA MÃ user service

TÁCH RỜI VỚI PUB/SUB
  user service → publish "user.created"
                     ↓
                 TOPIC
          ┌────────┴────────┐
   subscription        subscription
   email service      analytics service
        ↓
    ⚠ user service KHÔNG biết
      ai đang nghe
    ⚠ Một bên chết → thông điệp
      NẰM CHỜ, không mất
    ⚠ Thêm dịch vụ mới → chỉ tạo
      thêm SUBSCRIPTION

⚠ Fan-out — cơ chế then chốt:

MỘT topic, NHIỀU subscription
        ↓
    ⚠ MỖI subscription nhận
      MỘT BẢN SAO ĐẦY ĐỦ
        ↓
    Email service xử lý theo cách của nó
    Analytics service theo cách của nó
        ↓
    → hai bên độc lập hoàn toàn

Xem thêm #13260 (lô 138) — Pub/Sub với vai trò "cửa trước" của dữ liệu luồng. Câu này là vai trò thứ hai: bus thông điệp giữa các microservice. Cùng một sản phẩm, hai kiểu dùng.

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

• A (Dataflow) — công cụ xử lý dữ liệu luồng và lô. Nó tiêu thụ dữ liệu từ Pub/Sub, không thay thế vai trò truyền tin.

• B (Cloud SQL) — cơ sở dữ liệu. Có thể giả lập hàng đợi bằng bảng, nhưng đó là mẫu chống (anti-pattern): không mở rộng, phải hỏi vòng (polling), khó bảo đảm giao đúng một lần.

• D (Cloud Load Balancing) — phân phối lưu lượng đồng bộ tới các backend. Người gọi vẫn phải chờ phản hồi, và backend chết thì lời gọi vẫn lỗi.

Ghi nhớ

⚠ Đồng bộ và bất đồng bộ — bảng phải thuộc: | | Đồng bộ (HTTP) | Bất đồng bộ (Pub/Sub) | |---|---|---| | Người gọi | CHỜ phản hồi | ⚠ gửi xong đi luôn | | Bên nhận chết | ⚠ lời gọi LỖI | thông điệp NẰM CHỜ | | Thêm bên nhận | phải sửa mã bên gửi | ⚠ chỉ thêm subscription | | Hợp với | cần kết quả ngay | việc chạy nền, thông báo |

Từ khoá nhận diện:

"tách rời, bất đồng bộ, bus thông điệp" → Pub/Sub "nhận luồng dữ liệu quy mô lớn" → Pub/Sub "xử lý và biến đổi luồng" → Dataflow "hàng đợi tác vụ có kiểm soát tốc độ" → Cloud Tasks "định tuyến sự kiện tới dịch vụ" → Eventarc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bị dồn ứ không | num_undelivered_messages | | Thông điệp có bị mất không | ⚠ kiểm hạn giữ và dead-letter topic | | Xử lý trùng có an toàn không | rà lại tính idempotent của bên nhận |

Và một lợi ích của kiến trúc tách rời chỉ lộ rõ khi hệ thống lớn lên: thêm một tính năng mới không cần đụng tới mã cũ. Sáu tháng nữa, khi đội chống gian lận cũng muốn biết mỗi lần có người đăng ký, họ chỉ cần tạo một subscription — còn dịch vụ người dùng thì không hề biết có gì thay đổi.