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

Đáp án

C — BigQuery ML.

Vì sao đúng

Đề mô tả đúng nhóm người dùng mà BigQuery ML nhắm tới: nhà phân tích thành thạo SQL, dữ liệu đã nằm sẵn trong BigQuery, và không biết Python.

⚠ Huấn luyện mô hình bằng SQL thuần:

CREATE OR REPLACE MODEL `ban_hang.du_bao`
OPTIONS(
  model_type = 'ARIMA_PLUS',
  time_series_timestamp_col = 'ngay',
  time_series_data_col = 'doanh_thu'
) AS
SELECT ngay, doanh_thu FROM `ban_hang.lich_su`;

-- Dự báo 90 ngày tới
SELECT * FROM ML.FORECAST(
  MODEL `ban_hang.du_bao`,
  STRUCT(90 AS horizon));

        ↓
    ⚠ KHÔNG một dòng Python
    ⚠ KHÔNG chuyển dữ liệu đi đâu
    ⚠ KHÔNG dựng hạ tầng nào

⚠ Ba lợi thế lớn nhất:

1. DỮ LIỆU KHÔNG PHẢI DI CHUYỂN
     → ⚠ mô hình chạy NGAY TRONG kho
     → không xuất, không sao chép,
       không lo rò rỉ

2. DÙNG KỸ NĂNG SẴN CÓ
     → nhà phân tích đã viết SQL
       hằng ngày

3. TỐC ĐỘ TỪ Ý TƯỞNG TỚI KẾT QUẢ
     → ⚠ vài giờ thay vì vài tuần

⚠ Đọc đề để chọn đúng:

"THÀNH THẠO SQL"          → BigQuery ML
"KHÔNG biết Python"       → loại TensorFlow
"dữ liệu ĐÃ Ở BigQuery"   → không cần chuyển
"dự báo doanh số"         → ARIMA_PLUS có sẵn

⚠ Đối chiếu #13149 (lô 138) — đề đó cũng là nhóm nghiệp vụ nhưng nói rõ "không có kinh nghiệm viết mã Python HOẶC SQL", nên khoá là AutoML. Câu này nói nhóm thành thạo SQL, nên khoá là BigQuery ML. Hai câu KHÔNG mâu thuẫn — chúng khác nhau ở kỹ năng SQL của người dùng.

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

• A (Vertex AI AutoML) — phương án gần nhất và cũng không cần lập trình. Nhưng nó đòi đưa dữ liệu ra khỏi kho, làm việc qua giao diện riêng, và không tận dụng thế mạnh SQL mà nhóm này đã có.

• D (TensorFlow trên một máy ảo) — cần Python và cần quản hạ tầng — đúng hai thứ nhóm này không có.

• B (API dựng sẵn như Vision API) — dùng cho ảnh và ngôn ngữ, không dự báo doanh số từ dữ liệu bảng biểu được.

Ghi nhớ

⚠ Chọn công cụ ML theo kỹ năng — bảng phải thuộc: | Người dùng | Công cụ | |---|---| | Biết SQL, dữ liệu ở BigQuery | ⚠ BigQuery ML | | Không biết SQL lẫn Python | Vertex AI AutoML | | Biết Python, cần kiểm soát đầy đủ | Vertex AI custom training | | Cần việc phổ quát | API dựng sẵn |

Từ khoá nhận diện:

"nhà phân tích biết SQL, dữ liệu ở BigQuery" → BigQuery ML "không lập trình được gì cả" → AutoML "dự báo chuỗi thời gian bằng SQL" → ARIMA_PLUS "phân loại khách rời bỏ bằng SQL" → LOGISTIC_REG hoặc BOOSTED_TREE_CLASSIFIER

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình tốt tới đâu | ML.EVALUATE — MAE, RMSE, MAPE | | Có tốt hơn cách đoán đơn giản không | ⚠ so với "bằng kỳ trước" | | Tốn bao nhiêu | job history — byte xử lý khi huấn luyện |

Và một lợi thế của BigQuery ML mà các đội phân tích thường đánh giá thấp cho tới khi dùng thử: kết quả dự báo là một bảng BigQuery bình thường. Nó nối thẳng vào Looker, vào scheduled query, vào mọi thứ đội bạn đã dựng — không cần một đường ống riêng nào để đưa dự đoán từ thế giới ML trở về thế giới báo cáo.

Đáp án

B — Chọn một vùng ở châu Âu khi tạo tài nguyên trên Google Cloud.

Vì sao đúng

Yêu cầu về vị trí dữ liệu (data residency) được đáp ứng bằng quyết định chọn vùng, vì vùng chính là vị trí địa lý thật nơi dữ liệu được lưu và xử lý.

⚠ Vùng quyết định dữ liệu nằm ở đâu:

Tạo tài nguyên → chọn vùng
        ↓
    europe-west3 (Frankfurt, Đức)
    europe-west4 (Hà Lan)
    europe-north1 (Phần Lan)
    europe-west9 (Paris)
        ↓
    ⚠ Dữ liệu ở trạng thái LƯU nằm
      TRONG lãnh thổ đó
    ⚠ Xử lý cũng diễn ra ở đó
        ↓
    → đáp ứng yêu cầu "chỉ trong
      biên giới Liên minh châu Âu"

⚠ Chỉ chọn vùng thôi chưa đủ — cần chặn cả sai sót:

Đặt Organization Policy:
  constraints/gcp.resourceLocations
        ↓
    Chỉ cho phép tạo tài nguyên
    ở các vùng châu Âu
        ↓
    ⚠ Kỹ sư KHÔNG THỂ vô tình
      tạo bucket ở Mỹ
    ⚠ Áp cho MỌI project trong
      tổ chức, kể cả project mới
        ↓
    → biến chính sách giấy tờ
      thành rào chắn kỹ thuật

⚠ Vì sao ba phương án kia không giải quyết vị trí dữ liệu:

2SV
    → bảo vệ ĐĂNG NHẬP
    → ⚠ không quyết định dữ liệu ở đâu

BÁO CÁO MINH BẠCH
    → tài liệu về yêu cầu dữ liệu
      từ cơ quan chính phủ
    → ⚠ để ĐỌC, không phải để
      KIỂM SOÁT vị trí

MÃ HOÁ MẶC ĐỊNH
    → bảo vệ NỘI DUNG
    → ⚠ dữ liệu mã hoá đặt ở Mỹ
      thì VẪN đặt ở Mỹ

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

Phương án đúng viết tên vùng là frankfurt-west3 — không tồn tại. Tên đúng của vùng Frankfurt là europe-west3. Mọi vùng châu Âu của Google Cloud đều bắt đầu bằng tiền tố europe-.

Đây chỉ là lỗi đánh máy trong ví dụ, không làm sai ý của phương án: chọn một vùng ở châu Âu vẫn là cách đúng để đáp ứng yêu cầu vị trí dữ liệu. Khoá đáp án giữ nguyên là B. Nhưng khi đi thi, hãy nhớ đúng quy ước đặt tên vùng — đề thi thật có thể hỏi trực tiếp về nó.

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

• D (dựa vào mã hoá mặc định) — phương án gần nhất về mặt "nghe như bảo vệ dữ liệu": mã hoá bảo vệ nội dung khỏi bị đọc, nhưng không thay đổi vị trí địa lý. Cơ quan quản lý hỏi dữ liệu ở đâu, không hỏi dữ liệu có mã hoá không.

• A (bật 2SV) — bảo vệ tài khoản khỏi bị chiếm. Quan trọng, nhưng không liên quan tới vị trí lưu trữ.

• C (đọc báo cáo minh bạch) — tài liệu về việc Google xử lý yêu cầu dữ liệu từ chính phủ ra sao. Là thông tin tham khảo, không phải cơ chế kiểm soát.

Ghi nhớ

⚠ Ba khái niệm chủ quyền dữ liệu — bảng phải thuộc: | Khái niệm | Nghĩa | |---|---| | Data residency | ⚠ dữ liệu LƯU ở đâu về mặt địa lý | | Data sovereignty | dữ liệu chịu LUẬT của nước nào | | Operational sovereignty | AI được vận hành và truy cập hệ thống |

Từ khoá nhận diện:

"dữ liệu phải ở trong lãnh thổ X" → chọn vùng + Organization Policy "chặn tạo tài nguyên ngoài vùng cho phép" → gcp.resourceLocations "kiểm soát cả việc nhân viên Google truy cập" → Access Transparency / Access Approval "gói tuân thủ cho khu vực" → Assured Workloads

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài nguyên nào ngoài EU không | ⚠ rà bằng Asset Inventory | | Chính sách vị trí đã bật chưa | kiểm Organization Policy | | Log và backup nằm ở đâu | thường bị bỏ sót nhất |

Và một chỗ rất hay bị bỏ quên khi kiểm tra tuân thủ về vị trí dữ liệu: nhật ký hệ thống và bản sao lưu. Ứng dụng có thể chạy đúng ở Frankfurt trong khi log của nó lại chảy về một sink đặt ở Mỹ — và log ứng dụng thì thường xuyên chứa đúng thứ dữ liệu cá nhân mà quy định đang bảo vệ.

Đáp án

B — Confidentiality, Integrity, Availability (Bảo mật, Toàn vẹn, Sẵn sàng) — bộ ba CIA.

Vì sao đúng

Đề mô tả đúng ba trụ cột của bộ ba CIA, mô hình nền tảng của toàn bộ ngành an toàn thông tin.

⚠ Ba nguyên tắc, ghép đúng lời đề:

"bảo vệ khỏi truy cập trái phép"
        ↓
    ⚠ CONFIDENTIALITY (bảo mật)
    → chỉ đúng người được xem

"chính xác và đáng tin cậy"
        ↓
    ⚠ INTEGRITY (toàn vẹn)
    → không bị sửa đổi trái phép

"sẵn sàng khi cần"
        ↓
    ⚠ AVAILABILITY (sẵn sàng)
    → truy cập được lúc cần

⚠ Mỗi trụ cột dùng công cụ gì trên Google Cloud:

CONFIDENTIALITY
    → IAM, mã hoá, VPC Service Controls,
      policy tag, Confidential Computing

INTEGRITY
    → ⚠ checksum, verified boot (Titan),
      Audit Logs, Object Versioning,
      Binary Authorization

AVAILABILITY
    → ⚠ đa zone, đa vùng, Load Balancing,
      backup, Cloud Armor chống DDoS

⚠ Ba trụ cột thường mâu thuẫn nhau:

Siết CONFIDENTIALITY tối đa
    → nhiều lớp xác thực,
      quyền rất hẹp
        ↓
    ⚠ AVAILABILITY giảm —
      người dùng hợp lệ cũng bị chặn

Tối đa AVAILABILITY
    → sao chép khắp nơi,
      truy cập dễ dàng
        ↓
    ⚠ CONFIDENTIALITY giảm —
      nhiều bản sao hơn để rò rỉ
        ↓
    → an toàn thông tin là
      nghệ thuật CÂN BẰNG

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

• A (Authentication, Authorization, Auditing) — phương án gần nhất và là bẫy chính: đây cũng là bộ ba nổi tiếng ("ba chữ A"), nhưng chúng là CƠ CHẾ kiểm soát truy cập, còn CIA là MỤC TIÊU cần đạt. Ba chữ A chủ yếu phục vụ trụ cột Confidentiality.

• C (DevOps, SRE, Agile) — các mô hình vận hành và phát triển phần mềm, không phải nguyên tắc bảo mật.

• D (IaaS, PaaS, SaaS) — mô hình dịch vụ đám mây.

Ghi nhớ

⚠ Bộ ba CIA — bảng phải thuộc: | Trụ cột | Mục tiêu | Bị phá khi | |---|---|---| | Confidentiality | chỉ đúng người xem được | rò rỉ dữ liệu | | Integrity | dữ liệu chính xác, không bị sửa trộm | bị sửa đổi, mã độc tống tiền | | Availability | dùng được khi cần | ⚠ tấn công DDoS, sự cố hạ tầng |

Từ khoá nhận diện:

"ba nguyên tắc cốt lõi của bảo mật" → CIA "ai là ai, được làm gì, đã làm gì" → AuthN, AuthZ, Auditing "độ tin cậy, SLO" → SRE "mô hình dịch vụ đám mây" → IaaS/PaaS/SaaS

Ba câu hỏi kiểm chứng cho một hệ thống: | Câu hỏi | Trụ cột | |---|---| | Ai đọc được dữ liệu này? | Confidentiality | | Làm sao biết dữ liệu chưa bị sửa? | Integrity | | Mất bao lâu để phục hồi sau sự cố? | Availability |

Và một điều nên nhớ khi cân ba trụ cột này trong thực tế: chúng hiếm khi được ưu tiên ngang nhau. Với một sàn giao dịch, Availability là tối thượng; với hồ sơ bệnh án, Confidentiality đứng đầu; với sổ cái tài chính, Integrity mới là thứ không được phép sai — và biết mình đang ưu tiên cái nào là bước đầu tiên của mọi thiết kế bảo mật tử tế.

Đáp án

D — Báo cáo kiểm toán độc lập của bên thứ ba, chứng nhận và attestation.

Vì sao đúng

Tuân thủ không được chứng minh bằng lời hứa của nhà cung cấp, mà bằng kết luận của một bên kiểm toán độc lập. Đó chính là thứ Google cung cấp.

⚠ Vì sao phải là bên thứ ba:

Google tự nói "chúng tôi an toàn"
        ↓
    ⚠ Kiểm toán viên KHÔNG chấp nhận
        ↓
Một hãng kiểm toán độc lập
kiểm tra và chứng nhận
        ↓
    ⚠ Đây mới là bằng chứng
      có giá trị pháp lý
        ↓
    → Khách hàng "kế thừa" phần
      kiểm soát mà Google chịu
      trách nhiệm

⚠ Lấy ở đâu:

COMPLIANCE REPORTS MANAGER
(trong Google Cloud Console)
        ↓
    Tải trực tiếp:
      - ISO 27001, 27017, 27018
      - SOC 1, SOC 2, SOC 3
      - PCI DSS
      - HIPAA (BAA)
      - FedRAMP
      - và nhiều chuẩn theo khu vực
        ↓
    ⚠ Một số báo cáo cần
      thoả thuận bảo mật (NDA)

⚠ Nhưng chứng nhận của Google KHÔNG làm bạn tuân thủ:

Google được chứng nhận HIPAA-ready
        ↓
    ⚠ Điều đó CHƯA làm ứng dụng
      của bạn tuân thủ HIPAA
        ↓
    Bạn vẫn phải:
      - ký BAA với Google
      - ⚠ chỉ dùng dịch vụ NẰM TRONG
        phạm vi BAA
      - cấu hình IAM đúng
      - bật audit log
      - mã hoá đúng cách
      - đào tạo nhân sự
        ↓
    → tuân thủ là TRÁCH NHIỆM CHUNG

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

• B (bảng điều khiển thời gian thực về mọi mối đe doạ trên nền tảng) — phương án gần nhất về mặt "nghe như minh bạch", nhưng không tồn tại và cũng không phải bằng chứng tuân thủ. Kiểm toán viên cần báo cáo có chữ ký, không cần bảng theo dõi thời gian thực. (Security Command Center có bảng điều khiển, nhưng cho môi trường của bạn, không phải toàn nền tảng.)

• A (danh sách nhân viên Google có quyền vào trung tâm dữ liệu) — Google không công bố danh sách này, và nó cũng không phải hình thức bằng chứng mà kiểm toán chấp nhận.

• C (cam kết hợp đồng rằng sẽ không bao giờ có vi phạm dữ liệu) — không nhà cung cấp nào cam kết được điều đó. Hợp đồng nói về biện pháp kiểm soát và nghĩa vụ thông báo, không hứa hẹn tuyệt đối.

Ghi nhớ

⚠ Các chứng nhận hay gặp — bảng nên thuộc: | Chuẩn | Nội dung | |---|---| | ISO 27001 | hệ thống quản lý an toàn thông tin | | ISO 27017 / 27018 | an toàn đám mây / bảo vệ dữ liệu cá nhân trên đám mây | | SOC 1 | kiểm soát ảnh hưởng tới báo cáo tài chính | | SOC 2 | ⚠ bảo mật, sẵn sàng, toàn vẹn, riêng tư | | SOC 3 | bản tóm tắt công khai của SOC 2 | | PCI DSS | dữ liệu thẻ thanh toán | | HIPAA | ⚠ dữ liệu y tế Hoa Kỳ — cần ký BAA | | FedRAMP | cơ quan liên bang Hoa Kỳ | | GDPR | ⚠ là LUẬT, không phải chứng nhận |

Từ khoá nhận diện:

"chứng minh tuân thủ cho kiểm toán viên" → báo cáo kiểm toán bên thứ ba "tải chứng nhận ISO, SOC" → Compliance Reports Manager "gói kiểm soát cho khu vực/ngành" → Assured Workloads "theo dõi cấu hình sai của MÌNH" → Security Command Center

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Google có chứng nhận cần thiết không | Compliance Reports Manager | | Dịch vụ đang dùng có trong phạm vi không | danh sách dịch vụ của từng chuẩn | | Phần của mình đã đủ chưa | Security Command Center + rà cấu hình |

Và một hiểu lầm rất tốn kém mà nhiều tổ chức mắc phải: nghĩ rằng chọn được nhà cung cấp có chứng nhận là xong việc. Chứng nhận của Google trả lời cho phần hạ tầng — phần còn lại, tức là cách bạn cấu hình quyền, xử lý dữ liệu và huấn luyện nhân viên, vẫn là thứ kiểm toán viên sẽ hỏi và bạn phải tự trả lời.

Đáp án

D — Vá hệ điều hành khách (guest OS) trên máy ảo của họ.

Vì sao đúng

Với IaaS, ranh giới trách nhiệm nằm ngay phía trên tầng ảo hoá: Google lo mọi thứ bên dưới, khách hàng lo hệ điều hành khách trở lên.

⚠ Ranh giới trách nhiệm với Compute Engine:

    ỨNG DỤNG              ← ⚠ BẠN
    DỮ LIỆU               ← ⚠ BẠN
    RUNTIME, THƯ VIỆN     ← ⚠ BẠN
    ⚠ HỆ ĐIỀU HÀNH KHÁCH  ← ⚠ BẠN
       (vá bảo mật Linux)
  ────────── ranh giới ──────────
    HYPERVISOR / ẢO HOÁ    ← Google
    HỆ ĐIỀU HÀNH MÁY CHỦ   ← Google
    PHẦN CỨNG, TITAN       ← Google
    MẠNG XƯƠNG SỐNG        ← Google
    TRUNG TÂM DỮ LIỆU      ← Google

⚠ Vì sao ba phương án kia là của Google:

"MẠNG XƯƠNG SỐNG TOÀN CẦU"
    → hạ tầng của Google

"AN NINH VẬT LÝ TRUNG TÂM DỮ LIỆU"
    → ⚠ khách hàng còn KHÔNG BIẾT
      máy chủ của mình ở toà nhà nào

"HỆ ĐIỀU HÀNH MÁY CHỦ VÀ TẦNG ẢO HOÁ"
    → ⚠ đây là bẫy tinh vi nhất:
      HOST OS khác GUEST OS
    → host là của Google,
      guest là của bạn

⚠ Vá lỗi hệ điều hành khách là việc thật sự phải làm:

Lỗ hổng nghiêm trọng trong Linux
được công bố
        ↓
    ⚠ Google KHÔNG tự vào VM
      của bạn để vá
        ↓
    Bạn phải:
      - biết lỗ hổng đó tồn tại
      - vá trên MỌI máy ảo
      - kiểm tra ứng dụng còn chạy
        ↓
    Công cụ giúp:
    ⚠ VM Manager (OS patch management)

Xem thêm #13257 (lô 138) — về bảo mật tầng phần cứng của Google (chip Titan, verified boot). Câu này là nửa còn lại của cùng mô hình: phần trách nhiệm thuộc về khách hàng.

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

• C (hệ điều hành máy chủ và tầng ảo hoá) — phương án gần nhất và là bẫy chính vì chỉ khác một chữ: host OS là hệ điều hành chạy trên máy chủ vật lý của Google, guest OS là hệ điều hành trong máy ảo của bạn. Google lo cái đầu, bạn lo cái sau.

• A (mạng xương sống toàn cầu của Google) — hoàn toàn thuộc về Google.

• B (an ninh vật lý của trung tâm dữ liệu) — thuộc về Google; khách hàng không có quyền vào.

Ghi nhớ

⚠ Trách nhiệm theo mô hình dịch vụ — bảng phải thuộc: | Tầng | IaaS | PaaS | SaaS | |---|---|---|---| | Dữ liệu và phân quyền | BẠN | BẠN | ⚠ BẠN — luôn luôn | | Ứng dụng | BẠN | BẠN | Google | | Runtime | BẠN | Google | Google | | ⚠ Hệ điều hành khách | ⚠ BẠN | Google | Google | | Ảo hoá, phần cứng, vật lý | Google | Google | Google |

Từ khoá nhận diện:

"vá hệ điều hành trong VM" → trách nhiệm của KHÁCH HÀNG (IaaS) "an ninh vật lý, phần cứng, hypervisor" → Google "cấu hình IAM, dữ liệu" → ⚠ LUÔN là khách hàng, ở mọi mô hình "an ninh CỦA đám mây / TRONG đám mây" → Google / khách hàng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM đã vá tới đâu | VM Manager — báo cáo tuân thủ bản vá | | Có lỗ hổng nào đang mở không | Security Command Center | | Ai SSH được vào máy | ⚠ OS Login + audit log |

Và một quan sát đáng nhớ về mô hình trách nhiệm chung: phần Google lo hầu như không bao giờ là nguyên nhân của sự cố. Các vụ rò rỉ dữ liệu đám mây nổi tiếng gần như đều bắt nguồn từ nửa còn lại — một bucket cấu hình sai, một khoá bị đẩy lên GitHub, một máy ảo chưa vá suốt hai năm.

Đáp án

C — Cloud Bigtable.

Vì sao đúng

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

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

1. HÀNG TRIỆU LƯỢT ĐỌC VÀ GHI MỖI GIÂY
     → mở rộng ngang tuyến tính theo node

2. ĐỘ TRỄ DƯỚI 10 MILI-GIÂY
     → đọc theo row key gần như tức thời

3. SCHEMA ĐƠN GIẢN, PHI QUAN HỆ
     → ⚠ đúng mô hình wide-column

4. KHỐI LƯỢNG RẤT LỚN
     → hàng petabyte

⚠ Vì sao giao dịch tần suất cao chọn Bigtable:

Mỗi mili-giây đều quý
        ↓
    Tra dữ liệu thị trường theo mã
        ↓
    row key = ma_chung_khoan#timestamp
        ↓
    ⚠ MỘT lượt tìm, không join,
      không quét bảng
        ↓
    → độ trễ ổn định ở p99,
      ngay cả khi có hàng tỉ dòng

⚠ Vì sao ba CSDL kia không hợp:

CLOUD SQL
    → quan hệ, ⚠ mở rộng DỌC
    → không chịu nổi hàng triệu ghi/giây

CLOUD SPANNER
    → mở rộng ngang được ✔
    → ⚠ nhưng sinh ra cho GIAO DỊCH
      ACID toàn cầu — đề nói rõ
      schema PHI QUAN HỆ và đơn giản
    → đắt hơn nhiều mà không dùng
      tới ưu điểm của nó

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

⚠ Gần trùng với #13147 (lô 138) — đề đó là hệ quảng cáo đấu giá thời gian thực, đề này là giao dịch tần suất cao, nhưng bộ yêu cầu giống hệt và cùng khoá Bigtable. Hai câu nhất quán. Mẫu đề rất hay lặp: phi quan hệ + hàng triệu thao tác/giây + độ trễ mili-giây → luôn là Bigtable.

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

• B (Cloud Spanner) — phương án gần nhất vì cũng mở rộng ngang tới quy mô rất lớn. Nhưng nó là CSDL QUAN HỆ với giao dịch ACID toàn cầu, còn đề nói rõ schema đơn giản và PHI QUAN HỆ. Dùng Spanner ở đây là trả giá cao cho tính năng không cần.

• A (Cloud SQL) — quan hệ và chỉ mở rộng dọc. Có trần rõ ràng.

• D (BigQuery) — kho phân tích, sai hoàn toàn loại tải công việc.

Ghi nhớ

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

Từ khoá nhận diện:

"hàng triệu thao tác/giây, dưới 10ms, wide-column" → Bigtable "giao dịch ACID xuyên lục địa" → Spanner "MySQL/PostgreSQL sẵn có" → Cloud SQL "báo cáo trên dữ liệu lịch sử" → BigQuery

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

Và một kiến trúc rất hay gặp trong ngành tài chính mà đề thi thích hỏi vòng vo: Bigtable phục vụ đọc nóng, BigQuery phục vụ phân tích nguội. Cùng một luồng dữ liệu giao dịch thường được ghi vào cả hai — và chọn sai chỗ để đặt câu hỏi mới là lỗi kiến trúc, chứ không phải chọn sai cơ sở dữ liệu.

Đáp án

A — Container.

Vì sao đúng

Đề mô tả đúng định nghĩa của container: đóng gói ứng dụng cùng mọi phụ thuộc thành một đơn vị nhẹ, chạy nhất quán ở mọi môi trường.

⚠ Container giải bài toán gì:

"Trên máy tôi thì chạy được mà!"
        ↓
    Nguyên nhân: máy dev có
    Python 3.11, máy chủ có 3.9;
    thiếu một thư viện hệ thống;
    biến môi trường khác nhau
        ↓
    Container đóng gói CẢ:
      - mã ứng dụng
      - thư viện, runtime
      - công cụ hệ thống cần thiết
      - cấu hình
        ↓
    ⚠ Cùng một image chạy giống hệt
      trên laptop, staging, production

⚠ Container khác máy ảo thế nào:

        MÁY ẢO                CONTAINER
   ┌──────────────┐      ┌──────────────┐
   │  Ứng dụng    │      │  Ứng dụng    │
   │  Thư viện    │      │  Thư viện    │
   │ ⚠ OS KHÁCH   │      └──────────────┘
   │  (cả một OS) │       Container runtime
   └──────────────┘      ┌──────────────┐
     Hypervisor          │ OS CHUNG     │
   ┌──────────────┐      └──────────────┘
   │  OS máy chủ  │        Phần cứng
   └──────────────┘
        ↓                       ↓
   ⚠ nặng, hàng GB        ⚠ nhẹ, hàng MB
   ⚠ khởi động phút       ⚠ khởi động GIÂY
   cách ly mạnh hơn       ⚠ CHIA SẺ nhân OS

⚠ Vì sao ba phương án kia không đúng:

MÁY ẢO
    → ⚠ CŨNG đóng gói được
    → nhưng NẶNG (cả một hệ điều hành),
      khởi động chậm, không "nhẹ"
      như đề yêu cầu

SERVERLESS FUNCTION
    → ⚠ mô hình CHẠY, không phải
      cách ĐÓNG GÓI
    → và nó thường chạy TRÊN container

MÁY CHỦ VẬT LÝ (bare metal)
    → không đóng gói gì cả
    → ngược hẳn mục tiêu

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

• D (máy ảo) — phương án gần nhất và cũng giải quyết được vấn đề nhất quán môi trường. Nhưng đề nhấn mạnh "NHẸ" (lightweight) — máy ảo mang theo cả một hệ điều hành khách, nặng hàng GB và khởi động mất vài phút.

• B (hàm serverless) — là mô hình thực thi, không phải kỹ thuật đóng gói. Cloud Run Functions thực chất chạy bên trong container.

• C (máy chủ vật lý) — không liên quan tới đóng gói ứng dụng.

Ghi nhớ

⚠ Container và VM — bảng phải thuộc: | | Container | Máy ảo | |---|---|---| | Đóng gói | ứng dụng + phụ thuộc | cả một hệ điều hành | | Kích thước | hàng MB | hàng GB | | Khởi động | ⚠ giây | ⚠ phút | | Nhân OS | ⚠ CHIA SẺ với máy chủ | riêng biệt | | Cách ly | ở mức tiến trình | ⚠ mạnh hơn — mức phần cứng ảo | | Mật độ | hàng chục–trăm trên một máy | ít hơn nhiều |

Từ khoá nhận diện:

"đóng gói cùng phụ thuộc, nhẹ, chạy nhất quán mọi nơi" → container "điều phối hàng chục container" → Kubernetes / GKE "chạy container mà không quản cụm" → Cloud Run "cần cách ly mạnh, kiểm soát OS" → máy ảo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Image có lỗ hổng nào không | Artifact Analysis | | Image có quá lớn không | ⚠ so với base image tối thiểu | | Có chạy bằng root không | kiểm USER trong Dockerfile |

Và một lợi ích của container mà các đội thường chỉ cảm nhận được sau vài tháng: nó xoá bỏ hẳn cuộc tranh luận "trên máy tôi chạy được". Khi thứ chạy trên laptop của lập trình viên và thứ chạy trên production là cùng một image byte-by-byte, cả một loại sự cố vốn tốn rất nhiều thời gian điều tra đơn giản là biến mất.

Đáp án

C — Chi phí chuyển từ chủ yếu là chi phí vốn (CapEx) sang chi phí vận hành (OpEx).

Vì sao đúng

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

⚠ Hai mô hình chi tiêu:

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

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

⚠ Vì sao doanh nghiệp thích chuyển sang OpEx:

Không phải bỏ vốn lớn trước
        ↓
    ⚠ Vốn dành cho việc tạo
      giá trị: sản phẩm, con người
        ↓
Chi phí bám theo doanh thu
        ↓
    ⚠ Kinh doanh xuống thì
      chi phí hạ tầng cũng xuống
        ↓
Không phải đoán nhu cầu 5 năm tới
        ↓
    ⚠ Không mua thừa, không mua thiếu

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

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

"B — phí hằng tháng dự đoán được
     sang mua một lần"
    → ⚠ cũng đảo ngược

"A — TCO LUÔN LUÔN tăng"
    → ⚠ chữ "LUÔN LUÔN" là sai
    → TCO có thể giảm hoặc tăng
      tuỳ tối ưu tốt hay dở
    → và đây không phải "thay đổi
      trong CÁCH HẠCH TOÁN" mà đề hỏi

Nhất quán với #13278 (cùng lô này) — câu đó cũng có một phương án bẫy đảo chiều CapEx/OpEx. Ghi nhớ một chiều duy nhất: lên đám mây = CapEx → OpEx.

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

• A (TCO luôn tăng nhưng hoá đơn dễ đoán hơn) — phương án gần nhất về mặt "nghe như tài chính", nhưng sai hai chỗ: TCO không nhất thiết tăng, và hoá đơn đám mây thay đổi theo mức dùng nên thường khó đoán hơn hoá đơn khấu hao cố định.

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

• B (từ phí hằng tháng sang mua một lần) — cũng đảo ngược, chỉ diễn đạt bằng lời khác.

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 | | Ví dụ | mua máy chủ, xây trung tâm dữ liệu | hoá đơn đám mây, tiền điện, lương | | Thời điểm trả | 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 |

Từ khoá nhận diện:

"lên đám mây, thay đổi cách hạch toán" → CapEx → OpEx "trả theo mức dùng" → OpEx "mua máy chủ, đầu tư ban đầu" → CapEx "tổng chi phí sở hữu" → TCO — gồm cả những khoản ẩn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí đang đi đâu | billing report theo dịch vụ và label | | Có lãng phí không | Recommender — idle resources | | Xu hướng ra sao | billing export sang BigQuery, vẽ theo tháng |

Và một điều kiện gần như quyết định việc chuyển sang OpEx có thành công hay không: phải có người chịu trách nhiệm về hoá đơn. Khi chi phí chuyển từ một quyết định mua sắm mỗi vài năm sang hàng nghìn quyết định nhỏ mỗi ngày, thứ giữ cho nó không trôi không phải là công cụ mà là quyền sở hữu rõ ràng.

Đáp án

B — Dịch vụ 1 là SaaS, dịch vụ 2 là IaaS.

Vì sao đúng

Hai mô tả trong đề là hai định nghĩa gần như nguyên văn của SaaS và IaaS.

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

DỊCH VỤ 1
  "ứng dụng quản lý dự án
   DÙNG NGAY qua trình duyệt"
        ↓
    ⚠ Không cài đặt gì
    ⚠ Không viết mã
    ⚠ Không quản hạ tầng
        ↓
    → SaaS

DỊCH VỤ 2
  "thuê MÁY ẢO THÔ, TỰ cài và
   TỰ quản hệ điều hành và phần mềm"
        ↓
    ⚠ Nhận tài nguyên tính toán trần
    ⚠ Toàn quyền và toàn trách nhiệm
      từ hệ điều hành trở lên
        ↓
    → IaaS

⚠ Ba từ khoá nhận diện tức thì:

"qua TRÌNH DUYỆT, dùng ngay"
    → ⚠ SaaS

"MÁY ẢO THÔ, tự cài OS"
    → ⚠ IaaS

"chỉ đẩy MÃ lên, không quản OS"
    → ⚠ PaaS (không có trong đề này)

⚠ Vì sao PaaS không xuất hiện ở đây:

PaaS nằm GIỮA hai mô tả
        ↓
    Bạn CÓ viết mã (khác SaaS)
    nhưng KHÔNG quản OS (khác IaaS)
        ↓
    ⚠ Đề chỉ nêu hai đầu của trục,
      nên mọi phương án có PaaS
      đều sai

Nhất quán với #13283 (cùng lô này) — câu đó ghép cả ba mô hình với ba sản phẩm Google (Workspace, App Engine, Compute Engine). Câu này chỉ hỏi hai đầu.

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

• C (IaaS và SaaS) — phương án gần nhất: đúng hai khái niệm nhưng đảo thứ tự. Ứng dụng dùng qua trình duyệt không phải IaaS.

• A (PaaS và SaaS) và D (PaaS và IaaS) — đều gán nhầm dịch vụ 1 thành PaaS. Ứng dụng quản lý dự án có sẵn thì bạn không triển khai mã nào cả.

Ghi nhớ

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

Từ khoá nhận diện:

"dùng ngay qua trình duyệt, không cài gì" → SaaS "máy ảo thô, tự cài OS" → IaaS "đẩy mã lên là chạy" → PaaS "container serverless, co về 0" → PaaS/serverless

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Tôi có phải cài 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 viết mã nhưng không quản máy chủ? | → PaaS |

Và một cách nhìn giúp trả lời nhanh mọi câu hỏi dạng này trong phòng thi: đọc xem đề bắt bạn chịu trách nhiệm tới tầng nào. Câu chữ như "tự cài đặt", "tự quản lý", "dùng ngay", "chỉ viết mã" luôn chỉ thẳng vào một trong ba mô hình, và không cần suy luận gì thêm.

Đáp án

D — Truy cập kỹ sư hỗ trợ 24/7 với mục tiêu phản hồi nhanh, 15 phút.

Vì sao đúng

Gói Premium Support của Google Cloud Customer Care cam kết thời gian PHẢN HỒI, và với sự cố P1 thì mục tiêu là 15 phút, suốt 24/7.

⚠ Mức ưu tiên và mục tiêu phản hồi:

P1 — Critical impact
     dịch vụ sản xuất KHÔNG DÙNG ĐƯỢC
        ↓
    ⚠ Premium: mục tiêu 15 phút, 24/7
    ⚠ Enhanced: mục tiêu 1 giờ, 24/7
    ⚠ Standard: mục tiêu 4 giờ, giờ làm việc

P2 — High impact  → phản hồi chậm hơn
P3 — Medium
P4 — Low

⚠ Điểm mấu chốt — PHẢN HỒI, không phải GIẢI QUYẾT:

Google cam kết:
    ⚠ TRONG BAO LÂU sẽ có KỸ SƯ
      bắt đầu làm việc với bạn
        ↓
Google KHÔNG cam kết:
    ⚠ trong bao lâu sẽ SỬA XONG
        ↓
    Vì sao?
    → thời gian sửa phụ thuộc
      bản chất sự cố, không ai
      hứa trước được
        ↓
    → mọi phương án nói "đảm bảo
      GIẢI QUYẾT trong X" đều SAI

⚠ TAM làm gì và không làm gì:

Technical Account Manager (Premium)
  ✔ hiểu kiến trúc và ưu tiên của bạn
  ✔ điều phối khi có sự cố lớn
  ✔ tư vấn kiến trúc, rà soát
  ✔ giúp lập kế hoạch cho sự kiện lớn
        ↓
  ⚠ KHÔNG tự viết mã sửa lỗi
    trong ứng dụng của bạn

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

• B (đảm bảo giải quyết trong một giờ) — phương án gần nhất và là bẫy chính: không nhà cung cấp nào cam kết thời gian GIẢI QUYẾT. Cam kết luôn là về thời gian phản hồi.

• A (TAM tự viết mã sửa lỗi) — Premium có TAM, nhưng vai trò của họ là cố vấn và điều phối, không phải lập trình viên thay cho đội của bạn.

• C (diễn đàn cộng đồng) — có sẵn cho mọi người, kể cả gói miễn phí. Không phải lợi ích riêng của Premium.

Ghi nhớ

⚠ Bốn gói hỗ trợ của Google Cloud — bảng nên thuộc: | Gói | Đặc điểm | |---|---| | Basic | ⚠ MIỄN PHÍ — chỉ tài liệu, cộng đồng, hỗ trợ về thanh toán | | Standard | giờ làm việc, P1 mục tiêu 4 giờ | | Enhanced | 24/7, P1 mục tiêu 1 giờ | | Premium | ⚠ 24/7, P1 mục tiêu 15 phút, có TAM |

Từ khoá nhận diện:

"P1, 15 phút, 24/7, TAM" → Premium "24/7 nhưng không có TAM" → Enhanced "chỉ giờ làm việc" → Standard "chỉ có tài liệu và diễn đàn" → Basic (miễn phí)

Ba việc kiểm chứng cho một tổ chức: | Việc | Câu hỏi | |---|---| | Đang ở gói nào | console — mục Support | | Ai được phép mở ticket P1 | ⚠ cấp vai techSupportEditor trước | | Gói hiện tại có xứng với mức rủi ro không | so chi phí gói với thiệt hại mỗi giờ ngừng dịch vụ |

Và một việc rất nên làm trước khi cần tới nó: thử mở một ticket ưu tiên thấp để làm quen quy trình. Giữa lúc hệ thống sản xuất đang chết là thời điểm tệ nhất để phát hiện ra rằng không ai trong đội có quyền mở ticket, hoặc không ai biết project ID cần điền vào ô nào.