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

Đáp án

A — Mất thị phần vì đổi mới chậm hơn và không có khả năng mở rộng.

Vì sao đúng

Câu này hỏi rủi ro KINH DOANH, không hỏi rủi ro kỹ thuật. Và rủi ro kinh doanh lớn nhất khi đối thủ đã lên đám mây còn mình thì không, là thua trong cuộc đua tốc độ.

⚠ Hai bất lợi cụ thể:

1. TỐC ĐỘ ĐỔI MỚI
   Tại chỗ: cần máy chủ mới
            → duyệt ngân sách
            → đặt mua, chờ giao
            → lắp đặt, cấu hình
            → ⚠ HÀNG TUẦN tới HÀNG THÁNG
        so với
   Đám mây: ⚠ vài PHÚT

2. KHẢ NĂNG MỞ RỘNG
   Đợt khuyến mãi lớn:
   Tại chỗ: phải mua sẵn cho ĐỈNH
            → ⚠ 95% thời gian máy nằm không
            → mà đỉnh vượt dự đoán thì SẬP
        so với
   Đám mây: ⚠ tự co giãn, trả theo dùng

⚠ Vòng xoáy đi xuống của bán lẻ:

Đối thủ ra tính năng mới hằng tuần
        ↓
Mình ra mỗi quý một lần
        ↓
Khách thấy trải nghiệm bên kia tốt hơn
        ↓
    ⚠ Ngày mua sắm lớn: web mình SẬP
      vì không mở rộng kịp
        ↓
Mất doanh thu VÀ mất uy tín
        ↓
    → MẤT THỊ PHẦN

⚠ Vì sao phương án D nghe hợp lý nhưng sai:

"Tăng chi phí IT do chuyển từ CapEx sang OpEx"
        ↓
    ⚠ MÂU THUẪN với chính đề bài:
      công ty KHÔNG chuyển lên đám mây
        ↓
    → ở lại tại chỗ nghĩa là
      VẪN Ở CapEx, không có
      chuyển đổi nào cả
        ↓
    ⚠ Và CapEx → OpEx thường được coi
      là LỢI ÍCH, không phải rủi ro

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

• D (tăng chi phí do chuyển CapEx sang OpEx) — phương án gần nhất về mặt "nghe có vẻ kinh tế", nhưng mô tả điều sẽ xảy ra nếu HỌ LÊN đám mây, trong khi đề giả định họ ở lại. Ngoài ra chuyển sang OpEx thường là ưu điểm.

• B (bị cơ quan quản lý ép di cư lên đám mây) — không có quy định nào như vậy. Ngược lại, một số ngành còn bị hạn chế đưa dữ liệu lên đám mây.

• C (giảm quyền kiểm soát phần cứng và phần mềm) — đây là rủi ro của việc LÊN đám mây, không phải của việc ở lại. Ở lại tại chỗ thì quyền kiểm soát là tối đa.

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ả theo dùng | | Ví dụ | mua máy chủ, xây trung tâm dữ liệu | hoá đơn đám mây hằng tháng | | Trả tiền | trả trước một cục | trả dần theo mức dùng | | Rủi ro | mua thừa hoặc mua thiếu | chi phí trôi nếu không quản lý | | ⚠ | lên đám mây = chuyển CapEx sang OpEx |

Từ khoá nhận diện:

"đối thủ nhanh hơn, mình chậm" → rủi ro mất thị phần "phải mua máy cho ngày cao điểm" → thiếu tính co giãn "trả theo mức dùng" → OpEx, lợi ích của đám mây "mất quyền kiểm soát hạ tầng" → đánh đổi KHI LÊN đám mây

Ba việc kiểm chứng cho một tổ chức: | Việc | Cách | |---|---| | Đổi mới nhanh chậm ra sao | đo thời gian từ ý tưởng tới sản xuất | | Có mở rộng nổi ngày cao điểm không | diễn tập tải trước mùa bán hàng | | Đang tốn bao nhiêu cho phần nằm không | tỉ lệ sử dụng máy chủ hiện tại |

Và một góc nhìn đáng giữ khi đọc những câu hỏi kiểu này: rủi ro lớn nhất của việc không thay đổi hiếm khi là chi phí, mà là tốc độ. Một hệ thống cũ vẫn chạy tốt hôm nay có thể vẫn chạy tốt sang năm — vấn đề là đối thủ khi ấy đã ở phiên bản thứ năm mươi của sản phẩm, còn bạn thì mới ở phiên bản thứ tư.

Đáp án

D — Phi quan hệ (NoSQL).

Vì sao đúng

Đề nêu hai đặc điểm, và cả hai đều chỉ thẳng vào NoSQL kiểu tài liệu:

⚠ Hai đặc điểm ↔ NoSQL:

1. "CẤU TRÚC CÓ THỂ THAY ĐỔI THEO THỜI GIAN"
     → ⚠ CSDL quan hệ đòi schema CỐ ĐỊNH
     → đổi schema = ALTER TABLE trên
       bảng hàng triệu dòng
     → NoSQL: schema linh hoạt,
       mỗi tài liệu có thể khác nhau

2. "BIỂU DIỄN TỐT NHẤT DƯỚI DẠNG
    TÀI LIỆU JSON"
     → ⚠ đó chính là ĐỊNH NGHĨA
       của CSDL tài liệu

⚠ Một hồ sơ người dùng dạng tài liệu:

{
  "user_id": "u123",
  "ten": "Lan",
  "so_thich": ["nhạc", "du lịch"],
  "dia_chi": {
    "thanh_pho": "Đà Nẵng",
    "quoc_gia": "VN"
  },
  "cai_dat": { "che_do_toi": true }
}

        ↓
    ⚠ Mảng và đối tượng LỒNG NHAU
      nằm gọn trong MỘT tài liệu
        ↓
    Quan hệ hoá sẽ cần ít nhất
    BA BẢNG và các phép JOIN
        ↓
    NoSQL: đọc một lượt là xong

⚠ Thêm trường mới — hai thế giới:

QUAN HỆ                    NOSQL
ALTER TABLE users          Chỉ cần ghi tài liệu mới
  ADD COLUMN avatar        có thêm trường "avatar"
        ↓                          ↓
⚠ Khoá bảng, cần migration  ⚠ Tài liệu cũ không cần đổi
⚠ Phải phối hợp triển khai  ⚠ Ứng dụng xử lý trường thiếu

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

• B (quan hệ) — phương án gần nhất và là lựa chọn mặc định của nhiều người. Nhưng CSDL quan hệ đòi schema cố định, đúng thứ đề nói sẽ thay đổi theo thời gian. Nó mạnh khi dữ liệu có cấu trúc ổn định và cần join phức tạp.

• A (object storage) — lưu tệp (ảnh, video, sao lưu). Bạn không truy vấn theo trường trong object storage được.

• C (data warehouse) — nơi phân tích dữ liệu lịch sử quy mô lớn, không phải nơi ứng dụng di động đọc ghi hồ sơ người dùng theo mili-giây.

Ghi nhớ

⚠ Bốn khái niệm lưu trữ dữ liệu — bảng phải thuộc: | Khái niệm | Dùng cho | |---|---| | Quan hệ (SQL) | schema cố định, giao dịch, join — Cloud SQL, Spanner | | Phi quan hệ (NoSQL) | schema linh hoạt, mở rộng ngang — Firestore, Bigtable | | Data warehouse | phân tích quy mô lớn — BigQuery | | Object storage | tệp, ảnh, sao lưu — Cloud Storage |

Từ khoá nhận diện:

"JSON linh hoạt, cấu trúc hay đổi" → NoSQL tài liệu (Firestore) "giao dịch, khoá ngoại, join" → quan hệ "báo cáo trên hàng tỉ dòng" → data warehouse "lưu ảnh, video, tệp" → object storage

Ba việc kiểm chứng khi chọn CSDL: | Việc | Câu hỏi | |---|---| | Truy vấn nào chạy nhiều nhất | liệt kê ra trước khi chọn | | Schema có ổn định không | nếu đổi thường xuyên → NoSQL | | Có cần giao dịch nhiều thực thể không | nếu có → nghiêng về quan hệ |

Và một lời nhắc thường bị bỏ qua khi mới dùng NoSQL: schema linh hoạt không có nghĩa là không cần thiết kế. Trong CSDL quan hệ, schema nằm trong cơ sở dữ liệu; trong NoSQL, nó nằm trong mã ứng dụng và trong đầu đội phát triển — nếu không ai viết nó ra, sáu tháng sau sẽ không ai còn chắc một tài liệu hợp lệ trông như thế nào.

Đáp án

B — Cloud Armor.

Vì sao đúng

Cloud Armor là sản phẩm bảo vệ vành đai mạng của Google Cloud, và chống DDoS là công năng chính của nó.

⚠ Cloud Armor đứng ở đâu:

    Người chơi (và kẻ tấn công)
              ↓
    Mạng biên toàn cầu của Google
              ↓
    ⚠ CLOUD ARMOR  ← lọc ở ĐÂY
              ↓
    Cloud Load Balancing
              ↓
    Máy chủ game (GKE / Compute Engine)
        ↓
    ⚠ Lưu lượng xấu bị chặn TỪ BIÊN,
      chưa hề chạm tới máy chủ
    ⚠ Máy chủ không phải trả giá
      cho việc lọc

⚠ Hai tầng phòng thủ:

TẦNG 3/4 (mạng và vận chuyển)
  SYN flood, UDP amplification
        ↓
    ⚠ Hạ tầng Google hấp thụ
      TỰ ĐỘNG, mặc định

TẦNG 7 (ứng dụng)
  HTTP flood, SQL injection, XSS
        ↓
    ⚠ Cần luật của Cloud Armor
    → đây là phần "WAF"

⚠ Vì sao ba phương án kia không liên quan:

CLOUD KMS   → quản lý KHOÁ MÃ HOÁ
AUDIT LOGS  → ghi lại AI ĐÃ LÀM GÌ
              → phát hiện SAU, không chặn
IAM         → ai được phép làm gì
              → ⚠ kẻ tấn công DDoS
                KHÔNG cần đăng nhập

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

• D (Cloud IAM) — phương án gần nhất về mặt "nghe như bảo mật", nhưng IAM kiểm soát danh tính đã xác thực. Tấn công DDoS đến từ người dùng ẩn danh gửi lưu lượng vào endpoint công khai — IAM không có vai trò gì ở đó.

• A (Cloud KMS) — quản lý khoá mã hoá. Không liên quan tới lưu lượng mạng.

• C (Cloud Audit Logs) — ghi nhật ký để điều tra sau sự việc. Hữu ích, nhưng không chặn được gì.

Ghi nhớ

⚠ Các sản phẩm bảo mật Google Cloud — bảng phải thuộc: | Sản phẩm | Việc | |---|---| | Cloud Armor | DDoS + WAF ở tầng biên | | Cloud IAM | ai được làm gì | | Cloud KMS | khoá mã hoá | | Cloud Audit Logs | nhật ký ai đã làm gì | | Security Command Center | bảng điều khiển rủi ro toàn tổ chức | | VPC Service Controls | vành đai chống rò rỉ dữ liệu | | Identity-Aware Proxy (IAP) | kiểm soát truy cập ứng dụng theo danh tính |

Từ khoá nhận diện:

"DDoS, tràn lưu lượng, WAF" → Cloud Armor "SQL injection, XSS" → luật WAF dựng sẵn của Cloud Armor "ai được truy cập tài nguyên" → IAM "chặn rò rỉ dữ liệu ra ngoài vành đai" → VPC Service Controls "tổng quan lỗ hổng toàn tổ chức" → Security Command Center

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật có chặn nhầm người thật không | chạy chế độ preview và đọc log | | Đang bị tấn công kiểu gì | bảng Cloud Armor trong console | | Backend có chịu nổi không | thử tải trước mùa cao điểm |

Và một thói quen đáng có với mọi luật Cloud Armor mới: bật chế độ preview trước, đọc log vài ngày, rồi mới chuyển sang chặn thật. Một luật WAF quá chặt sẽ khoá luôn người chơi hợp lệ — và về mặt kinh doanh, chuyện đó khó phân biệt với chính trận tấn công mà bạn đang cố ngăn.

Đáp án

A — Triển khai ứng dụng trên nhiều vùng (region) tách biệt về mặt địa lý.

Vì sao đúng

Đề nói rõ: phải sống sót khi cả một vùng địa lý gặp sự cố. Muốn chịu được mất một vùng thì phải có bản sao ở vùng khác — không có cách nào khác.

⚠ Phân cấp địa lý của Google Cloud:

    REGION (ví dụ asia-southeast1)
       ├── ZONE a  ─┐
       ├── ZONE b   ├─ ⚠ hạ tầng điện, mạng,
       └── ZONE c  ─┘   làm mát TÁCH BIỆT
                        nhưng CÙNG khu vực địa lý
        ↓
    Mất MỘT ZONE
        → triển khai đa zone là đủ
        ↓
    Mất CẢ REGION
      (thiên tai, sự cố diện rộng)
        → ⚠ đa zone KHÔNG cứu được
        → phải có REGION THỨ HAI

⚠ Kiến trúc đa vùng cho ứng dụng quan trọng:

        Global Load Balancer
       (một địa chỉ IP toàn cầu)
              ↓
      ┌───────┴───────┐
   Region A        Region B
   (asia-se1)      (asia-ne1)
   backend         backend
        ↓
    ⚠ LB tự định tuyến người dùng
      tới vùng GẦN NHẤT còn khoẻ
    ⚠ Một vùng chết → lưu lượng
      tự dồn sang vùng kia
        ↓
    Dữ liệu: Spanner đa vùng,
             bucket đa vùng,
             hoặc bản sao xuyên vùng

Bổ sung cho câu #13154 (cùng lô này) — câu đó nói về mất một ZONE và trả lời bằng cấu hình HA của Cloud SQL. Câu này nói về mất cả REGION, và câu trả lời phải ở cấp kiến trúc đa vùng. Hai câu nhất quán, chỉ khác cấp độ sự cố.

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

• C (triển khai nhiều zone trong MỘT vùng) — phương án gần nhất và là bẫy chính. Đa zone là thực hành tốt và bắt buộc, nhưng nó chỉ chống được mất một zone. Cả ba zone vẫn nằm trong cùng một vùng — vùng đó sập thì tất cả cùng sập.

• B (đặt hạn ngạch tài nguyên) — hạn ngạch kiểm soát chi phí và chống dùng quá mức, không liên quan gì tới khả năng chịu lỗi.

• D (dùng máy ảo preemptible/Spot) — giảm chi phí bằng cách chấp nhận máy có thể bị thu hồi bất cứ lúc nào. Nó làm giảm độ tin cậy, đi ngược mục tiêu.

Ghi nhớ

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

Từ khoá nhận diện:

"cả một vùng gặp sự cố" → đa vùng (multi-region) "một zone gặp sự cố" → đa zone trong cùng vùng "người dùng toàn cầu, độ trễ thấp" → đa vùng + global load balancer "tuân thủ chủ quyền dữ liệu" → ⚠ có thể BỊ CẤM dùng đa vùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự chịu được mất vùng không | ⚠ DIỄN TẬP — tắt hẳn một vùng thử | | Dữ liệu có ở cả hai nơi không | kiểm cấu hình sao chép của từng dịch vụ | | Chuyển đổi mất bao lâu | đo RTO thật, đừng chỉ ước lượng |

Và điều quan trọng nhất về mọi kiến trúc đa vùng: nó chỉ có giá trị nếu đã được diễn tập. Một hệ thống dự phòng chưa bao giờ được thử là một giả thiết, không phải một biện pháp bảo vệ — và ngày sự cố thật xảy ra là ngày tệ nhất để phát hiện ra rằng giả thiết ấy sai.

Đáp án

C — Google Kubernetes Engine (GKE).

Vì sao đúng

Đề liệt kê đúng bốn việc mà một bộ điều phối container (container orchestrator) làm, và Kubernetes là chuẩn của ngành cho việc đó.

⚠ Bốn yêu cầu ↔ Kubernetes:

1. TRIỂN KHAI tự động
     → Deployment: khai "muốn 10 bản"
       Kubernetes tự đưa về trạng thái đó

2. MỞ RỘNG tự động
     → HorizontalPodAutoscaler theo CPU
     → Cluster Autoscaler thêm/bớt node

3. TỰ CHỮA LÀNH (healing)
     → ⚠ liveness probe phát hiện
       container chết → KHỞI ĐỘNG LẠI
     → node chết → dời pod sang node khác

4. MẠNG giữa các container
     → Service: một tên DNS ổn định
     → Ingress: đưa ra ngoài

⚠ Vòng lặp điều hoà — ý tưởng cốt lõi:

Bạn khai TRẠNG THÁI MONG MUỐN
   (10 bản sao, ảnh v2)
        ↓
Kubernetes liên tục so sánh
   mong muốn ↔ thực tế
        ↓
    Lệch → tự hành động sửa
        ↓
    ⚠ Container chết → tạo lại
    ⚠ Node chết → dời sang node khác
    ⚠ Đây là "self-healing"
      mà đề nhắc tới

⚠ Vì sao ba phương án kia không phải bộ điều phối:

COMPUTE ENGINE
    → ⚠ chỉ là MÁY ẢO
    → bạn tự cài Docker, tự viết
      script khởi động lại
    → chính là thứ Kubernetes thay thế

CLOUD RUN FUNCTIONS
    → serverless, chạy TỪNG HÀM
    → hợp cho vài dịch vụ đơn giản
    → không điều phối HÀNG CHỤC
      container phụ thuộc lẫn nhau

APP ENGINE FLEXIBLE
    → PaaS, chạy container được
    → ⚠ nhưng KHÔNG cho kiểm soát
      điều phối; là nền tảng ứng dụng,
      không phải bộ điều phối

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

• B (App Engine Flexible) — phương án gần nhất: nó có chạy container và có tự mở rộng. Nhưng nó là PaaS cho một ứng dụng, không phải công cụ điều phối hàng chục container phụ thuộc nhau trên một cụm; bạn không kiểm soát được lịch xếp pod, mạng nội bộ hay chiến lược cập nhật.

• A (Cloud Run Functions) — chạy từng hàm không trạng thái, tự mở rộng rất tốt. Nhưng đề nói "ứng dụng nhiều thành phần, hàng chục container" cần điều phối — đó là bài toán của Kubernetes.

• D (Compute Engine) — chỉ cung cấp máy ảo trống. Mọi việc trong đề bạn sẽ phải tự làm bằng tay.

Ghi nhớ

⚠ Bốn lựa chọn tính toán trên Google Cloud — bảng phải thuộc: | Lựa chọn | Dùng khi | |---|---| | Compute Engine (IaaS) | cần kiểm soát tối đa, phần mềm cũ, GPU đặc thù | | GKE (CaaS) | nhiều container, kiến trúc microservice, cần điều phối | | Cloud Run (serverless container) | container không trạng thái, co về 0, ít vận hành | | App Engine (PaaS) | ứng dụng web, không muốn quản hạ tầng | | Cloud Run Functions | hàm nhỏ phản ứng theo sự kiện |

Từ khoá nhận diện:

"điều phối container, hàng chục container, tự chữa lành" → GKE "một container, HTTP, co về 0" → Cloud Run "phản ứng khi có sự kiện, hàm nhỏ" → Cloud Run Functions "nâng và chuyển máy chủ cũ" → Compute Engine

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pod có khoẻ không | kubectl get pods — cột RESTARTS cao là dấu hiệu xấu | | Vì sao pod chết | kubectl describe pod và kubectl logs --previous | | Cụm có đủ tài nguyên không | kubectl top nodes |

Và một điều nên nói thẳng về Kubernetes: nó rất mạnh nhưng cũng rất phức tạp. Với một dịch vụ web đơn giản, Cloud Run cho gần như toàn bộ lợi ích với một phần nhỏ công sức vận hành — GKE xứng đáng khi bạn thật sự có hàng chục thành phần phụ thuộc nhau, đúng như đề bài này mô tả.

Đáp án

D — Archive.

Vì sao đúng

Đề cho ba manh mối, và cả ba đều chỉ vào lớp Archive:

⚠ Ba manh mối ↔ Archive:

1. GIỮ BẢY NĂM
     → ⚠ vượt xa thời gian tối thiểu
       365 ngày của Archive

2. "GẦN NHƯ KHÔNG BAO GIỜ ĐỌC"
     sau 30 ngày đầu
     → đúng hồ sơ của Archive

3. "TIẾT KIỆM NHẤT" cho lưu trữ dài hạn
     → ⚠ Archive có GIÁ LƯU TRỮ
       THẤP NHẤT trong bốn lớp

⚠ So sánh bốn lớp — điều phải thuộc:

                Thời gian    Giá lưu trữ   Phí truy xuất
                tối thiểu
STANDARD        không có     cao nhất      không có
NEARLINE        30 ngày      ↓             có
COLDLINE        90 ngày      ↓             cao hơn
ARCHIVE         365 ngày     ⚠ THẤP NHẤT   ⚠ CAO NHẤT

        ↓
    ⚠ Đánh đổi rất rõ:
      lưu càng rẻ thì đọc càng đắt
        ↓
    Với bản sao lưu tuân thủ
    gần như không bao giờ đọc
        ↓
    → Archive là lựa chọn đúng

⚠ Kết hợp với quy tắc vòng đời:

{"rule": [
  {"action": {"type": "SetStorageClass",
              "storageClass": "ARCHIVE"},
   "condition": {"age": 30}},
  {"action": {"type": "Delete"},
   "condition": {"age": 2557}}
]}

        ↓
    30 ngày đầu: Standard (còn hay đọc)
    Sau đó:      Archive (rẻ nhất)
    Sau 7 năm:   xoá tự động
        ↓
    ⚠ Nên bật thêm Bucket Lock
      để không ai xoá sớm được

Xem thêm #13140 (cùng lô này) — câu đó hỏi tính năng nào tự chuyển lớp (Object Lifecycle Management); câu này hỏi chuyển sang lớp nào. Hai câu ghép lại thành một giải pháp trọn vẹn.

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

• C (Coldline) — phương án gần nhất: cũng dành cho dữ liệu ít đọc, thời gian tối thiểu 90 ngày. Nhưng với chu kỳ bảy năm và gần như không đọc, Coldline đắt hơn Archive đáng kể về lưu trữ. Coldline hợp khi vẫn đọc vài lần mỗi năm.

• B (Nearline) — cho dữ liệu đọc khoảng một lần mỗi tháng. Quá đắt cho kho lưu trữ bảy năm.

• A (Standard) — cho dữ liệu truy cập thường xuyên, giá lưu trữ cao nhất. Sai hoàn toàn với mục tiêu tiết kiệm.

Ghi nhớ

⚠ Bốn lớp lưu trữ — bảng phải thuộc: | Lớp | Tối thiểu | Tần suất đọc | |---|---|---| | Standard | không | thường xuyên | | Nearline | 30 ngày | ~1 lần/tháng | | Coldline | 90 ngày | ~1 lần/quý | | Archive | 365 ngày | ~1 lần/năm hoặc ít hơn | | ⚠ Chung | cùng độ bền, cùng API, cùng độ trễ ~mili-giây |

Từ khoá nhận diện:

"lưu trữ tuân thủ nhiều năm, không đọc" → Archive "sao lưu hằng tháng còn phục hồi" → Nearline "tự chuyển lớp theo tuổi" → Object Lifecycle Management "không đoán được kiểu truy cập" → Autoclass "không ai được xoá trong N năm" → Bucket Lock

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu đang ở lớp nào | Storage Insights hoặc gcloud storage ls -L | | Có bị tính phí truy xuất bất ngờ không | billing export, lọc SKU retrieval | | Chính sách giữ đã khoá chưa | gcloud storage buckets describe → retentionPolicy |

Và một cảnh báo rất đáng nhớ trước khi bấm nút Bucket Lock: nó không thể gỡ được, kể cả bởi chính bạn hay bởi Google. Đó chính là điều khiến nó có giá trị pháp lý — và cũng là lý do phải chắc chắn tuyệt đối về thời hạn trước khi khoá lại.

Đáp án

D — Mô hình sẽ đưa ra dự đoán sai và không đáng tin.

Vì sao đúng

Đây là nguyên tắc nền tảng nhất của học máy, thường được gọi bằng đúng năm chữ: "rác vào, rác ra" (garbage in, garbage out).

⚠ Mô hình học từ dữ liệu, không sửa dữ liệu:

Dữ liệu huấn luyện
        ↓
    Mô hình tìm QUY LUẬT trong đó
        ↓
    ⚠ Dữ liệu sai → quy luật sai
    ⚠ Mô hình KHÔNG biết đâu là lỗi
        ↓
    Nó học luôn cả lỗi và
    coi đó là sự thật

⚠ Ba khuyết tật của đề gây hại thế nào:

GIÁ TRỊ THIẾU
    → thư viện thường tự điền
      trung bình hoặc 0
    → ⚠ bịa ra quan hệ không có thật

ĐỊNH DẠNG KHÔNG NHẤT QUÁN
    → "TP.HCM", "tp hcm", "HCMC"
    → ⚠ mô hình coi là BA nơi khác nhau
    → sức mạnh dự đoán bị chia nhỏ

BẢN GHI SAI
    → tuổi = 250, doanh thu = −5000
    → ⚠ ngoại lai kéo lệch toàn bộ
      mô hình tuyến tính

⚠ Vì sao nguy hiểm hơn là "mô hình chạy chậm":

Mô hình vẫn HUẤN LUYỆN XONG
Vẫn cho ra một con số độ chính xác
        ↓
    ⚠ KHÔNG có thông báo lỗi nào
        ↓
    Doanh nghiệp tin vào dự đoán
        ↓
    Chi tiền giữ chân nhầm khách hàng
    Bỏ sót khách sắp rời đi
        ↓
    → Thiệt hại kinh doanh THẬT

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

• B (mô hình tự sửa lỗi trong dữ liệu) — hiểu lầm phổ biến nhất về học máy. Mô hình học theo dữ liệu, nó không có khái niệm đúng sai để mà sửa.

• A (huấn luyện nhanh hơn) — không có liên hệ nào; dữ liệu bẩn thậm chí thường làm quá trình hội tụ chậm và bất ổn hơn.

• C (tốn ít sức tính toán hơn) — cũng không đúng, và dù có đúng thì cũng không phải kết quả đáng nói so với việc dự đoán sai.

Ghi nhớ

⚠ Vòng đời một dự án ML — bảng phải thuộc: | Bước | Nội dung | |---|---| | 1. Xác định bài toán nghiệp vụ | dự đoán cái gì, để làm gì | | 2. Thu thập dữ liệu | | | 3. ⚠ CHUẨN BỊ VÀ LÀM SẠCH | thường chiếm 60–80% thời gian dự án | | 4. Huấn luyện | | | 5. Đánh giá | | | 6. Triển khai | | | 7. Giám sát | phát hiện xuống cấp |

Từ khoá nhận diện:

"dữ liệu bẩn, thiếu, không nhất quán" → dự đoán không đáng tin "chất lượng dữ liệu quyết định chất lượng mô hình" → garbage in, garbage out "dữ liệu huấn luyện thiên lệch" → mô hình thiên lệch theo "độ chính xác đẹp bất thường" → ⚠ nghi ngờ rò rỉ nhãn

Ba việc kiểm chứng trước khi huấn luyện: | Việc | Cách | |---|---| | Mỗi cột thiếu bao nhiêu | COUNTIF(x IS NULL) / COUNT(*) | | Có ngoại lai vô lý không | MIN, MAX, APPROX_QUANTILES | | Có bao nhiêu biến thể của cùng một giá trị | COUNT(DISTINCT TRIM(LOWER(x))) |

Và một điều mà mọi người làm dữ liệu đều học được sau vài dự án: thời gian bỏ ra làm sạch dữ liệu gần như luôn đem lại nhiều cải thiện hơn thời gian bỏ ra tinh chỉnh thuật toán. Một mô hình đơn giản chạy trên dữ liệu sạch thường thắng một mô hình phức tạp chạy trên dữ liệu bẩn — và nó còn dễ giải thích cho ban lãnh đạo hơn nhiều.

Đáp án

C — 1. API dựng sẵn, 2. AutoML, 3. Mô hình tuỳ biến (Vertex AI).

Vì sao đúng

Google Cloud có ba mức giải pháp AI, xếp theo công sức bỏ ra và mức kiểm soát nhận lại. Đề cho đúng ba tình huống, mỗi tình huống rơi vào một mức.

⚠ Ba mức — thang đo cần thuộc:

API DỰNG SẴN
  Google đã huấn luyện sẵn
  → dùng ngay, không cần dữ liệu
  → ⚠ ÍT công sức nhất,
    ÍT kiểm soát nhất

AUTOML
  Bạn đưa DỮ LIỆU của bạn
  → Google lo thuật toán
  → ⚠ cân bằng ở giữa

MÔ HÌNH TUỲ BIẾN
  Bạn viết mã, chọn kiến trúc
  → ⚠ NHIỀU công sức nhất,
    TOÀN QUYỀN kiểm soát

⚠ Ghép từng mục tiêu:

MỤC TIÊU 1 — chuyển giọng nói thành chữ,
              thời gian thực
    → ⚠ đây là bài toán PHỔ QUÁT
    → Speech-to-Text API đã rất giỏi
    → ⚠ tự huấn luyện là lãng phí lớn
    → API DỰNG SẴN

MỤC TIÊU 2 — dự đoán giá bất động sản
              từ DỮ LIỆU RIÊNG,
              "không viết mã ML phức tạp"
    → cần mô hình trên dữ liệu CỦA HỌ
    → ⚠ nhưng KHÔNG muốn lập trình
    → AUTOML

MỤC TIÊU 3 — engine gợi ý kiểu mới,
              "lợi thế cạnh tranh cốt lõi",
              "TOÀN QUYỀN kiểm soát kiến trúc"
    → ⚠ AutoML không cho đổi kiến trúc
    → MÔ HÌNH TUỲ BIẾN

⚠ Ba cụm từ trong đề là kim chỉ nam:

"real-time voice transcription"
    → việc phổ biến → API dựng sẵn

"unique, structured dataset"
+ "without writing complex ML code"
    → dữ liệu riêng + không lập trình → AutoML

"core business differentiator"
+ "full control over the model architecture"
    → ⚠ hai cụm này LUÔN nghĩa là tuỳ biến

Xem thêm #13149 (cùng lô này) — cũng khoá AutoML cho nhóm không biết lập trình. Nhất quán với mục tiêu 2 ở đây.

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

• B (API dựng sẵn / tuỳ biến / AutoML) — phương án gần nhất, đúng ở mục tiêu 1 nhưng đảo hai mục còn lại: dùng mô hình tuỳ biến cho một bài toán bảng biểu thông thường là quá sức cần thiết, còn dùng AutoML cho thứ đòi toàn quyền kiểm soát kiến trúc là không làm được.

• A — sai cả ba: dùng AutoML cho chuyển giọng nói (lãng phí), và dùng API dựng sẵn cho engine gợi ý độc đáo (không tồn tại API nào làm việc riêng của bạn).

• D — cũng sai cả ba, theo cách tương tự.

Ghi nhớ

⚠ Ba mức giải pháp AI — bảng phải thuộc: | Mức | Đặc điểm | Ví dụ | |---|---|---| | API dựng sẵn | Google huấn luyện, dùng ngay | Speech-to-Text, Vision, Translation, Natural Language | | AutoML | dữ liệu của bạn, không cần mã | Vertex AI AutoML | | Mô hình tuỳ biến | toàn quyền, cần kỹ năng | Vertex AI custom training, TensorFlow, PyTorch | | Mô hình sinh | dùng và tinh chỉnh mô hình nền | Gemini, Model Garden |

Từ khoá nhận diện:

"việc phổ biến: dịch, OCR, nhận diện giọng nói" → API dựng sẵn "dữ liệu riêng nhưng không biết lập trình" → AutoML "lợi thế cạnh tranh cốt lõi, kiểm soát kiến trúc" → tuỳ biến "sinh văn bản, tóm tắt, chatbot" → Gemini / Vertex AI

Ba câu hỏi để chọn mức: | Câu hỏi | Nếu... | |---|---| | Có API sẵn làm được không? | có → dùng luôn | | Có dữ liệu riêng nhưng thiếu người viết mã? | → AutoML | | Đây có phải lợi thế cạnh tranh cốt lõi? | có → tuỳ biến |

Và một nguyên tắc chọn lựa đáng mang theo ra khỏi phòng thi: hãy bắt đầu từ mức đơn giản nhất giải quyết được bài toán. Rất nhiều dự án AI thất bại không phải vì mô hình yếu, mà vì đội ngũ chọn con đường phức tạp nhất ngay từ đầu và cạn thời gian trước khi kịp đưa được thứ gì vào sản xuất.

Đáp án

A — Quản trị dữ liệu (Data governance).

Vì sao đúng

Đề liệt kê đúng định nghĩa sách giáo khoa của quản trị dữ liệu: khung chính sách và quy trình để quản lý tính sẵn có, khả dụng, toàn vẹn và bảo mật của dữ liệu, kèm kiểm soát truy cập, chất lượng dữ liệu và tuân thủ pháp luật.

⚠ Bốn trụ cột trong chính lời đề:

AVAILABILITY  — dữ liệu sẵn có khi cần
USABILITY     — tìm được, hiểu được, dùng được
INTEGRITY     — chính xác và nhất quán
SECURITY      — chỉ đúng người được xem
        ↓
    Cộng thêm:
    ⚠ AI ĐƯỢC TRUY CẬP CÁI GÌ
    ⚠ CHẤT LƯỢNG duy trì thế nào
    ⚠ TUÂN THỦ GDPR, CCPA
        ↓
    → Đây chính là DATA GOVERNANCE

⚠ Quản trị dữ liệu không phải một công cụ:

    CON NGƯỜI
      → data owner, data steward
      → hội đồng quản trị dữ liệu
           +
    QUY TRÌNH
      → duyệt cấp quyền
      → quy trình xử lý sự cố dữ liệu
      → chu kỳ rà soát
           +
    CÔNG NGHỆ
      → Dataplex, policy tag,
        IAM, audit log
        ↓
    ⚠ Thiếu con người và quy trình
      thì công cụ vô nghĩa

⚠ Vì sao càng lớn càng cấp thiết:

10 bảng, 3 người dùng
    → hỏi nhau là biết

10.000 bảng, 500 người dùng
    → ⚠ không ai biết bảng nào
      là bảng đúng
    → ⚠ ba đội tính "doanh thu"
      ra ba con số khác nhau
    → ⚠ dữ liệu cá nhân nằm rải rác
      không ai biết ở đâu
        ↓
    → phải có QUẢN TRỊ

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

• B (hạ tầng dữ liệu) — chỉ phần công nghệ: máy chủ, kho, pipeline. Đó là một phần giúp thực thi quản trị, không phải bản thân khung quản trị.

• C (kiếm tiền từ dữ liệu) — biến dữ liệu thành nguồn doanh thu. Là một mục tiêu kinh doanh, và nó cần quản trị dữ liệu làm nền, nhưng không phải khái niệm đề mô tả.

• D (di chuyển dữ liệu) — chỉ là việc chuyển dữ liệu từ nơi này sang nơi khác. Một dự án, không phải một khung quản lý liên tục.

Ghi nhớ

⚠ Các khái niệm dữ liệu hay bị lẫn — bảng phải thuộc: | Khái niệm | Nghĩa | |---|---| | Data governance | khung CHÍNH SÁCH và QUY TRÌNH quản lý dữ liệu | | Data infrastructure | hạ tầng kỹ thuật lưu và xử lý | | Data monetization | biến dữ liệu thành doanh thu | | Data migration | chuyển dữ liệu sang nơi mới | | Data lineage | dữ liệu này đến từ đâu, đi qua những đâu | | Data catalog | danh mục để tìm và hiểu dữ liệu |

Từ khoá nhận diện:

"chính sách, ai được xem gì, chất lượng, tuân thủ" → data governance "tìm dữ liệu ở đâu trong tổ chức" → data catalog / Dataplex "cột này tính từ đâu ra" → data lineage "phát hiện dữ liệu cá nhân" → Sensitive Data Protection

Ba việc kiểm chứng: | Việc | Câu hỏi | |---|---| | Có biết dữ liệu cá nhân nằm ở đâu không | quét bằng Sensitive Data Protection | | Ai đang truy cập dữ liệu nhạy cảm | Data Access audit logs | | Bảng nào là bảng "chính thức" | danh mục có đánh dấu và có người sở hữu chưa |

Và một sự thật mà mọi tổ chức đều gặp: quản trị dữ liệu thất bại khi nó chỉ là một dự án công nghệ. Công cụ dựng xong trong vài tuần, nhưng nếu không ai được chỉ định chịu trách nhiệm về từng miền dữ liệu, thì sáu tháng sau danh mục lại đầy những bảng không ai biết dùng để làm gì.

Đáp án

C — Cloud Spanner.

Vì sao đúng

Đề nêu bốn yêu cầu, và chúng chỉ cùng tồn tại được trong Spanner:

⚠ Bốn yêu cầu ↔ Spanner:

1. QUAN HỆ ĐẦY ĐỦ (SQL + giao dịch)
     → Spanner có GoogleSQL và
       phương ngữ PostgreSQL

2. MỞ RỘNG NGANG XUYÊN LỤC ĐỊA
     → thêm node là thêm năng lực
     → dữ liệu tự chia và cân bằng

3. ĐỌC/GHI ĐỘ TRỄ THẤP Ở CẢ
   CHÂU Á VÀ BẮC MỸ
     → cấu hình đa vùng đặt
       bản sao gần người dùng

4. NHẤT QUÁN GIAO DỊCH MẠNH
     → ⚠ TrueTime — đồng hồ nguyên tử
       và GPS ở mọi trung tâm dữ liệu

⚠ Vì sao tồn kho bán lẻ cần nhất quán mạnh:

Cửa hàng Hà Nội bán chiếc cuối cùng
        ↓
    Nếu chỉ NHẤT QUÁN CUỐI CÙNG
        ↓
    ⚠ Cửa hàng New York vẫn
      thấy còn hàng
    ⚠ Bán tiếp → BÁN QUÁ SỐ CÓ
        ↓
    Spanner: giao dịch nguyên tử toàn cầu
        ↓
    → mọi nơi thấy cùng một con số
      tại cùng một thời điểm

⚠ Ba CSDL kia thiếu đúng một thứ then chốt:

CLOUD SQL
    → quan hệ ĐẦY ĐỦ ✔
    → ⚠ chỉ mở rộng DỌC ✘
    → ⚠ không ghi đa vùng ✘

FIRESTORE
    → mở rộng toàn cầu ✔
    → ⚠ KHÔNG quan hệ, không SQL,
      không join phức tạp ✘

BIGQUERY
    → SQL ✔, quy mô lớn ✔
    → ⚠ là kho PHÂN TÍCH (OLAP) ✘
    → không phải OLTP độ trễ thấp

⚠ Gần trùng với #13141 (cùng lô này) — đề đó là hệ thanh toán toàn cầu, đề này là quản lý tồn kho, nhưng bộ yêu cầu giống hệt và cùng khoá Spanner. Hai câu nhất quán. Đây là mẫu đề rất hay lặp: quan hệ + toàn cầu + nhất quán mạnh thì đáp án luôn là Spanner.

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

• D (Cloud SQL) — phương án gần nhất và là bẫy quen thuộc: nó thật sự là CSDL quan hệ có giao dịch. Nhưng nó chỉ mở rộng dọc (đổi máy to hơn) và không ghi được ở nhiều vùng; bản sao đọc xuyên vùng chỉ nhất quán cuối cùng.

• A (Firestore) — mở rộng toàn cầu tốt nhưng là NoSQL tài liệu: không phải quan hệ, không có SQL đầy đủ và join phức tạp.

• B (BigQuery) — kho phân tích. Sai loại tải công việc: nó không phục vụ đọc ghi giao dịch độ trễ mili-giây.

Ghi nhớ

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

Từ khoá nhận diện:

"quan hệ + nhiều châu lục + nhất quán mạnh" → Spanner "MySQL/PostgreSQL, một vùng" → Cloud SQL "báo cáo, phân tích lịch sử" → BigQuery "đồng bộ thời gian thực cho app" → Firestore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hotspot khoá không | Key Visualizer | | Truy vấn nào chậm | Query Insights | | Độ trễ ở từng vùng | metric latency theo vùng trong Cloud Monitoring |

Và điều đáng nhớ nhất khi bắt tay thiết kế trên Spanner: hiệu năng nằm ở khoá chính, không nằm ở số node. Một khoá tăng dần theo thời gian sẽ dồn toàn bộ lượt ghi vào một split, và khi ấy trả thêm tiền cho node cũng không mua được thêm chút thông lượng nào.