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

Đáp án

A — Software as a Service (SaaS).

Vì sao đúng

Đề mô tả bộ ứng dụng nghiệp vụ hoàn chỉnh — email, soạn thảo văn bản, bảng tính — do bên thứ ba quản lý toàn bộ. Người dùng chỉ việc đăng nhập và dùng.

⚠ Ba mô hình — nhớ bằng câu ngắn:

⚠ IaaS → thuê MÁY
    → Compute Engine
    → bạn lo OS trở lên

⚠ PaaS → thuê NỀN TẢNG chạy mã
    → App Engine, Cloud Run
    → bạn lo MÃ và DỮ LIỆU

⚠ SaaS → ⚠ dùng PHẦN MỀM luôn
    → ⚠ Google Workspace, Gmail
    → ⚠ bạn chỉ lo DỮ LIỆU và
      NGƯỜI DÙNG
    → ⚠ ĐỀ NÀY

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

"IaaS"  → ⚠ bạn tự cài phần mềm
"PaaS"  → ⚠ bạn tự VIẾT ứng dụng
"FaaS"  → ⚠ chạy HÀM theo sự kiện
          (Cloud Functions) — vẫn là
          nơi để bạn viết mã

⚠ Gần trùng với #13556 (cùng lô) — đề đó cũng mô tả email và cộng tác tài liệu do bên thứ ba quản lý, và cùng khoá SaaS. Hoàn toàn nhất quán. Đối chiếu #13546 (cùng lô) khoá PaaS vì ở đó đội tự viết ứng dụng.

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

• C (PaaS) — phương án gần nhất vì cũng là mô hình mà nhà cung cấp quản phần lớn hạ tầng, nhưng PaaS là nơi bạn triển khai mã của mình; ở đây công ty mua phần mềm dùng ngay.

• B (IaaS) và D (FaaS) — đòi bạn tự cài hoặc tự viết.

Ghi nhớ

⚠ Ai lo gì — bảng phải thuộc: | | IaaS | PaaS | ⚠ SaaS | |---|---|---|---| | Phần cứng | nhà cc | nhà cc | nhà cc | | OS | ⚠ BẠN | nhà cc | nhà cc | | Runtime | bạn | nhà cc | nhà cc | | ⚠ Ứng dụng | bạn | ⚠ BẠN | ⚠ nhà cc | | ⚠ Dữ liệu | bạn | bạn | ⚠ BẠN — luôn luôn |

Từ khoá nhận diện:

"dùng phần mềm sẵn có, bên thứ ba quản" → ⚠ SaaS "chỉ viết mã, không quản máy chủ" → PaaS "cần toàn quyền trên OS" → IaaS "chạy một hàm theo sự kiện" → ⚠ FaaS

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Ai còn tài khoản mà đã nghỉ | ⚠ tính tiền theo người dùng, và là rủi ro | | Tài liệu nào đang chia sẻ công khai | ⚠ rà định kỳ | | Xuất dữ liệu ra được không | ⚠ kiểm trước khi phụ thuộc sâu |

Và điều không đổi ở mọi mô hình dịch vụ, từ IaaS tới SaaS: dữ liệu và quyền truy cập luôn là trách nhiệm của bạn. Nhà cung cấp lo cho phần mềm chạy đúng; việc ai được đọc tài liệu nào thì không ai làm thay được.

Đáp án

A — Transform (biến đổi).

Vì sao đúng

Công việc đề mô tả — phân tích cú pháp log, bỏ trường thừa, chuẩn hoá định dạng thời gian — đều là làm sạch và định hình dữ liệu, tức giai đoạn Transform.

⚠ Vị trí trong chuỗi giá trị dữ liệu:

GENERATE
    → máy chủ web sinh ra log

INGEST + STORE
    → ⚠ log thô đã nằm trong
      Cloud Storage
        ↓
⚠ TRANSFORM
    → ⚠ Dataflow phân tích cú pháp
    → ⚠ bỏ trường không cần
    → ⚠ chuẩn hoá timestamp
    → ⚠ ĐỀ NÀY
        ↓
STORE (lần hai)
    → nạp vào BigQuery

ANALYZE → ACTIVATE

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

"Generate"
    → ⚠ máy chủ web đã sinh log
      TRƯỚC ĐÓ

"Store"
    → ⚠ log đã được cất vào bucket
      rồi; nạp vào BigQuery là
      KẾT QUẢ của bước biến đổi

"Analyze"
    → ⚠ diễn ra SAU, khi truy vấn
      và dựng báo cáo

Đối chiếu #13521 (cùng lô) — đề đó khoá Analyze vì nhà phân tích đang dựng dashboard rút ra hiểu biết. Đề này khoá Transform vì đang làm sạch dữ liệu. Không mâu thuẫn — hai giai đoạn khác nhau của cùng một chuỗi.

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

• D (Store) — phương án gần nhất vì công việc kết thúc bằng việc nạp vào BigQuery, nghe như lưu trữ. Nhưng phần việc mà Dataflow job thực hiện là biến đổi; lưu chỉ là đích đến.

• B (Generate) và C (Analyze) — nằm ở hai đầu của chuỗi.

Ghi nhớ

⚠ Chuỗi giá trị dữ liệu — bảng phải thuộc: | Giai đoạn | Việc | Công cụ | |---|---|---| | Generate | sinh dữ liệu | ứng dụng, IoT, log | | Ingest | ⚠ đưa vào hệ thống | ⚠ Pub/Sub, Datastream | | Store | cất giữ | ⚠ Cloud Storage, BigQuery | | ⚠ Transform | ⚠ làm sạch, chuẩn hoá — đề này | ⚠ Dataflow, Dataproc, Dataform | | Analyze | rút hiểu biết | ⚠ BigQuery, Looker | | Activate | ⚠ hành động | ⚠ đích đến thật sự |

Từ khoá nhận diện:

"phân tích cú pháp, làm sạch, chuẩn hoá" → ⚠ Transform "dashboard, tìm xu hướng" → Analyze "đưa dữ liệu vào hệ thống" → Ingest "ra quyết định, đổi hành vi kinh doanh" → ⚠ Activate

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản ghi hỏng đi đâu | ⚠ phải có dead-letter, không vứt im lặng | | Có giữ dữ liệu thô không | ⚠ giữ để làm lại được | | Múi giờ đã chuẩn hoá chưa | ⚠ lưu UTC, đổi khi hiển thị |

Và quy tắc đáng theo trong mọi đường ống dữ liệu: giữ lại bản thô, dù đã biến đổi. Logic làm sạch sẽ có lúc sai — và khi đó, khoảng cách giữa việc chạy lại trong một buổi chiều và việc mất vĩnh viễn vài tháng dữ liệu chính là bản sao thô ấy.

Đáp án

B — Software as a Service (SaaS).

Vì sao đúng

Đề mô tả đúng SaaS: dùng ứng dụng của bên thứ ba cho email và cộng tác tài liệu, không phải quản máy chủ ứng dụng, hệ điều hành hay việc cập nhật.

⚠ Ba việc đề nói KHÔNG phải quản:

"máy chủ ứng dụng"
    → ⚠ nhà cung cấp lo

"hệ điều hành"
    → ⚠ nhà cung cấp lo

"cập nhật phần mềm"
    → ⚠ nhà cung cấp lo
        ↓
    ⚠ Ba việc này thuộc về khách hàng
      ở IaaS, và một phần ở PaaS
        ↓
    → ⚠ chỉ SaaS mới lo hết cả ba

⚠ Nhớ bằng câu ngắn:

IaaS → ⚠ thuê MÁY
PaaS → ⚠ thuê NỀN TẢNG chạy mã
⚠ SaaS → ⚠ dùng PHẦN MỀM luôn

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

"IaaS"  → ⚠ bạn quản OS và tự
          cài phần mềm
"PaaS"  → ⚠ bạn tự VIẾT ứng dụng
"On-premises" → ⚠ quản MỌI THỨ

⚠ Gần trùng với #13554 (cùng lô) — đề đó cũng là bộ ứng dụng email và tài liệu do bên thứ ba quản lý, và cùng khoá SaaS, chỉ khác cách diễn đạt và thứ tự phương án (A ở #13554, B ở đây). Hoàn toàn nhất quán. Đối chiếu #13546 (cùng lô) khoá PaaS vì đội ở đó tự viết ứng dụng.

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

• C (PaaS) — phương án gần nhất vì cũng bỏ được việc quản OS, nhưng PaaS là nơi bạn triển khai mã của mình; ở đây công ty dùng phần mềm có sẵn.

• A (IaaS) và D (on-premises) — mức tự quản cao hơn nhiều.

Ghi nhớ

⚠ Bốn mô hình theo mức tự quản — bảng phải thuộc: | Mô hình | Bạn quản | |---|---| | On-premises | ⚠ mọi thứ | | IaaS | ⚠ OS, runtime, ứng dụng, dữ liệu | | PaaS | ⚠ ứng dụng và dữ liệu | | ⚠ SaaS | ⚠ CHỈ dữ liệu và người dùng |

Từ khoá nhận diện:

"không quản máy chủ, OS, cập nhật" → ⚠ SaaS "chỉ viết mã" → PaaS "cần toàn quyền OS" → IaaS "tự sở hữu phần cứng" → on-premises

Ba việc kiểm chứng: | Việc | Cách | |---|---| | MFA đã bật cho mọi người chưa | ⚠ đặc biệt là quản trị viên | | Tài liệu nào chia sẻ ra ngoài | ⚠ rà định kỳ | | Ai còn tài khoản mà đã nghỉ | ⚠ quy trình gỡ quyền khi nghỉ việc |

Và điều dễ bị hiểu nhầm nhất khi chuyển sang SaaS: nhà cung cấp lo phần mềm chạy đúng, không lo dữ liệu của bạn được chia sẻ đúng người. Rủi ro lớn nhất trong các bộ công cụ cộng tác hiếm khi là hạ tầng — nó thường là một liên kết chia sẻ đặt ở chế độ "ai có link cũng xem được".

Đáp án

B — Ưu tiên dùng các công nghệ mã nguồn mở như Kubernetes, TensorFlow và SQL chuẩn.

Vì sao đúng

Công nghệ mở giải quyết cả hai mối lo của đề: khối lượng công việc mang đi được và kỹ năng của lập trình viên dùng lại được ở nơi khác.

⚠ Vì sao mã nguồn mở chống được khoá chân:

⚠ KUBERNETES
    → chạy ở mọi đám mây và
      cả tại chỗ
    → ⚠ cùng một tệp YAML

⚠ TENSORFLOW
    → ⚠ mô hình ở định dạng chuẩn,
      mang đi được

⚠ SQL CHUẨN
    → ⚠ truy vấn viết lại ít nhất
    → kỹ năng phổ quát
        ↓
    ⚠ Kỹ năng của đội cũng
      MANG THEO được

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

"Ký hợp đồng dài hạn ràng buộc
 với MỘT nhà cung cấp"
    → ⚠ đó chính là KHOÁ CHÂN

"Dùng dịch vụ ĐỘC QUYỀN bất cứ
 khi nào có thể"
    → ⚠ tăng phụ thuộc

"Chỉ đào tạo lập trình viên về
 GIAO DIỆN của Google Cloud"
    → ⚠ kỹ năng KHÔNG chuyển
      đi đâu được

⚠ Gần trùng với #13566 (cùng lô) — đề đó hỏi Google Cloud giúp gì, đề này hỏi công ty nên làm gì. Và #13517 (cùng lô) hỏi công nghệ cụ thể. Ba đề cùng hướng, hoàn toàn nhất quán.

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

• C (dùng dịch vụ độc quyền) — phương án gần nhất về mặt "cũng là một chiến lược kỹ thuật hợp lệ" và thường cho tốc độ tốt nhất, nhưng nó làm tăng khoá chân chứ không giảm.

• A (hợp đồng dài hạn) và D (chỉ học giao diện) — đều đi ngược mục tiêu.

Ghi nhớ

⚠ Công nghệ mở của Google — trụ cột "Freedom": | Công nghệ | Lĩnh vực | |---|---| | ⚠ Kubernetes | ⚠ điều phối container | | ⚠ TensorFlow | ⚠ học máy | | Apache Beam | ⚠ nền của Dataflow | | gRPC, Istio | giao tiếp dịch vụ | | ⚠ SQL chuẩn trong BigQuery | ⚠ kỹ năng phổ quát |

Từ khoá nhận diện:

"chống khoá chân, kỹ năng chuyển được" → ⚠ công nghệ mã nguồn mở "chạy K8s nhiều nơi" → ⚠ Anthos / GKE Enterprise "nhiều nhà cung cấp" → multi-cloud "hạ tầng khai báo bằng mã" → ⚠ Terraform

Ba câu hỏi kiểm chứng: | Câu hỏi | Vì sao hỏi | |---|---| | Phần nào thật sự cần mang đi được | ⚠ hiếm khi là tất cả | | Chuyển đi tốn bao nhiêu | ⚠ ước tính rồi hãy quyết | | Kỹ năng đội có phổ quát không | ⚠ K8s, SQL, Terraform là kỹ năng chuyển được |

Và cách cân bằng thực dụng nhất giữa tốc độ và tự do: giữ dữ liệu ở định dạng mở, ứng dụng trong container, hạ tầng trong Terraform — rồi thoải mái dùng những dịch vụ có quản lý tốt nhất bên trên. Ba lớp đó chiếm phần lớn chi phí chuyển đổi, và cũng là phần rẻ nhất để làm đúng ngay từ đầu.

Đáp án

B — Two-step verification (2SV) — xác minh hai bước.

Vì sao đúng

Người dùng phải cung cấp hai yếu tố khác loại: mật khẩu (điều bạn biết) và mã gửi tới điện thoại (điều bạn có). Đó là xác minh hai bước, còn gọi là MFA.

⚠ Ba loại yếu tố xác thực:

⚠ ĐIỀU BẠN BIẾT
    → mật khẩu, mã PIN

⚠ ĐIỀU BẠN CÓ
    → ⚠ điện thoại, khoá bảo mật,
      ứng dụng sinh mã
    → ⚠ mã 6 chữ số trong đề

⚠ ĐIỀU BẠN LÀ
    → vân tay, khuôn mặt
        ↓
    ⚠ Từ HAI loại KHÁC NHAU
      = xác thực đa yếu tố

⚠ Vì sao 2SV hiệu quả:

Mật khẩu bị lộ
    (rò rỉ, dùng lại, lừa đảo)
        ↓
    ⚠ Kẻ tấn công vẫn KHÔNG
      đăng nhập được
        ↓
    ⚠ vì không có yếu tố THỨ HAI
        ↓
    → ⚠ chặn được phần lớn
      các vụ chiếm tài khoản

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

"Authorization"
    → ⚠ QUYỀN LÀM GÌ sau khi đã
      đăng nhập

"Encryption at rest"
    → ⚠ mã hoá dữ liệu khi LƯU

"Auditing"
    → ⚠ ghi lại ai đã làm gì

Nhất quán với #13533 (cùng lô) — 2SV là một cơ chế authentication. Đối chiếu #13537 (cùng lô) về authorization — hai bước khác nhau.

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

• D (Authorization) — phương án gần nhất vì cũng thuộc lĩnh vực kiểm soát truy cập, nhưng nó xảy ra sau khi danh tính đã được xác minh.

• C (mã hoá khi lưu) và A (auditing) — thuộc các lớp bảo mật khác.

Ghi nhớ

⚠ Các cơ chế xác thực — mạnh dần: | Cơ chế | Mức bảo vệ | |---|---| | Chỉ mật khẩu | ⚠ yếu nhất | | Mã SMS | ⚠ tốt hơn nhiều, nhưng có rủi ro SIM swap | | Ứng dụng sinh mã | ⚠ tốt hơn SMS | | ⚠ Khoá bảo mật vật lý | ⚠ MẠNH NHẤT — chống được lừa đảo | | Passkey | ⚠ không mật khẩu, gắn với thiết bị |

Từ khoá nhận diện:

"mật khẩu + mã điện thoại" → ⚠ 2SV / MFA "được phép làm gì" → authorization "dữ liệu mã hoá khi lưu" → encryption at rest "nhật ký thao tác" → audit log

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài khoản quản trị đã bật chưa | ⚠ ưu tiên số một | | Có ai còn dùng mật khẩu đơn lẻ không | ⚠ đặt chính sách bắt buộc | | Mất thiết bị thì khôi phục thế nào | ⚠ chuẩn bị trước, đừng đợi sự cố |

Và trong toàn bộ danh sách việc cần làm để tăng bảo mật cho một tổ chức, bật xác minh hai bước cho các tài khoản quản trị vẫn là việc có tỉ lệ hiệu quả trên công sức cao nhất. Nó mất vài phút, và nó chặn đứng loại tấn công phổ biến nhất: dùng lại một mật khẩu đã bị lộ ở nơi khác.

Đáp án

D — Latency (độ trễ).

Vì sao đúng

Latency đo thời gian ứng dụng phản hồi một request của người dùng — đúng câu hỏi đề đặt ra.

⚠ Bốn tín hiệu và câu hỏi tương ứng:

⚠ LATENCY
    → ⚠ "PHẢN HỒI MẤT BAO LÂU?"
    → ⚠ ĐỀ NÀY

TRAFFIC
    → "có bao nhiêu request?"

ERRORS
    → "bao nhiêu request hỏng?"

SATURATION
    → "hệ thống đầy tới đâu?"

⚠ Đo latency cho đúng:

⚠ ĐỪNG dùng TRUNG BÌNH
        ↓
    ⚠ trung bình GIẤU đuôi chậm
        ↓
    ⚠ p50 — người dùng điển hình
    ⚠ p95 / p99 — người dùng KHỔ nhất
        ↓
    ⚠ p99 của một triệu request
      = 10.000 người thật bị chậm
        ↓
    → ⚠ đặt SLO theo PHÂN VỊ

⚠ Một chi tiết SRE nhấn mạnh:

⚠ Tách latency của request
  THÀNH CÔNG và THẤT BẠI
        ↓
    ⚠ request lỗi thường trả về
      RẤT NHANH
        ↓
    ⚠ gộp chung sẽ làm con số
      latency trông ĐẸP GIẢ TẠO

Bộ bốn với #13522 (tên gọi), #13527 (traffic), #13550 (saturation) trong cùng lô. Bốn đề phủ đủ khung Four Golden Signals, hoàn toàn nhất quán.

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

• C (Saturation) — phương án gần nhất trong bối cảnh "ứng dụng chậm" vì bão hoà thường gây ra độ trễ, nhưng nó đo mức đầy của tài nguyên, không đo thời gian phản hồi.

• A (Traffic) và B (Errors) — đo nhu cầu và tỉ lệ thất bại.

Ghi nhớ

⚠ Bốn tín hiệu vàng — bảng phải thuộc: | Tín hiệu | Đo gì | Chỉ số nên dùng | |---|---|---| | ⚠ Latency | ⚠ thời gian phản hồi | ⚠ p50, p95, p99 | | Traffic | nhu cầu | request/giây | | Errors | tỉ lệ thất bại | % 5xx | | Saturation | mức đầy | % tài nguyên khan hiếm |

Từ khoá nhận diện:

"mất bao lâu để phản hồi" → ⚠ latency "bao nhiêu request đang tới" → traffic "CPU gần 100%" → saturation "tỉ lệ request hỏng" → errors

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang xem trung bình hay phân vị | ⚠ đổi biểu đồ sang p95/p99 | | Thời gian tiêu ở bước nào | ⚠ Cloud Trace | | Latency lỗi có bị gộp vào không | ⚠ tách ra rồi xem lại |

Và con số đầu tiên nên đổi trên bảng theo dõi nếu nó vẫn đang hiển thị độ trễ trung bình: thay bằng phân vị thứ 99. Rất nhiều đội phát hiện ra rằng dịch vụ họ vẫn tin là nhanh thực ra đang phục vụ một phần đáng kể người dùng chậm hơn nhiều lần so với con số họ vẫn báo cáo.

Đáp án

B — Cloud Logging.

Vì sao đúng

Đề cần xem nhật ký sự kiện chi tiết, dạng văn bản, theo từng bước của đường ống CI/CD để tìm nguyên nhân một lần triển khai thất bại. Đó là việc của Cloud Logging.

⚠ Log CI/CD nằm ở đâu:

⚠ Cloud Build chạy từng bước
        ↓
    ⚠ Mỗi bước ghi log ra
      Cloud Logging
        ↓
    ⚠ Xem trong giao diện Cloud Build
      hoặc Logs Explorer
        ↓
    ⚠ Lọc theo bước, theo mức độ,
      tìm chuỗi lỗi

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

"Cloud Monitoring"
    → ⚠ CHỈ SỐ dạng số, không phải
      log văn bản từng bước

"Cloud Armor"
    → ⚠ tường lửa ứng dụng web

"Cloud Scheduler"
    → ⚠ chạy việc theo lịch cron

⚠ Truy vấn thường dùng:

resource.type="build"
severity>=ERROR
        ↓
    ⚠ khoanh khoảng thời gian
      của lần build hỏng

⚠ Gần trùng với #13520 (cùng lô) và #13516 (lô 143) — cả ba đề đều là tìm trong log văn bản và cùng khoá Cloud Logging, chỉ khác bối cảnh (lỗi ứng dụng, chữ "FATAL", đường ống CI/CD). Hoàn toàn nhất quán.

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

• D (Cloud Monitoring) — phương án gần nhất vì hai dịch vụ luôn đi cùng nhau, nhưng Monitoring làm việc với chỉ số, không phải nhật ký từng bước.

• A (Cloud Armor) và C (Cloud Scheduler) — thuộc lĩnh vực khác.

Ghi nhớ

⚠ Bộ quan sát — bảng phải thuộc: | Dịch vụ | Trả lời | |---|---| | ⚠ Cloud Logging | ⚠ "chuyện gì đã xảy ra?" — văn bản | | Cloud Monitoring | ⚠ "hệ thống khoẻ không?" — chỉ số | | Cloud Trace | ⚠ "chậm ở bước nào?" | | Cloud Profiler | "hàm nào tốn CPU?" | | Error Reporting | ⚠ gom lỗi giống nhau |

Từ khoá nhận diện:

"log từng bước, tìm lỗi triển khai" → ⚠ Cloud Logging "biểu đồ, ngưỡng, cảnh báo" → Cloud Monitoring "đường ống CI/CD trên Google Cloud" → ⚠ Cloud Build, Cloud Deploy "chạy việc theo lịch" → Cloud Scheduler

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước nào hỏng | ⚠ lọc log theo bước, không đọc từ đầu | | Khác gì so với lần chạy được | ⚠ so log hai lần build | | Có bí mật nào lọt vào log không | ⚠ rà lại, và sửa ngay nếu có |

Và thói quen giúp rút ngắn nhiều nhất thời gian gỡ lỗi một đường ống CI/CD: giữ lại log của lần chạy thành công gần nhất. Phần lớn sự cố triển khai là do một thứ vừa thay đổi — và cách nhanh nhất để tìm ra nó là đặt hai bản log cạnh nhau.

Đáp án

B — Organization Policy Service.

Vì sao đúng

Đề cần một chính sách khai báo áp cho TOÀN tổ chức, chặn hành vi tạo bucket công khai — kể cả khi người dùng có quyền tạo bucket. Đó là việc của Organization Policy.

⚠ IAM và Organization Policy khác nhau ra sao:

⚠ IAM
    → ⚠ AI được làm gì
    → cấp quyền cho từng người
    → ⚠ người có quyền vẫn có thể
      tạo bucket công khai

⚠ ORGANIZATION POLICY
    → ⚠ HÀNH VI NÀO bị cấm,
      áp cho MỌI NGƯỜI
    → ⚠ kể cả Owner cũng bị chặn
    → ⚠ kế thừa xuống toàn cây
    → ⚠ ĐỀ NÀY

⚠ Ràng buộc dùng cho tình huống này:

⚠ constraints/storage.
  publicAccessPrevention
        ↓
    ⚠ chặn mọi cách làm bucket
      công khai
        ↓
    ⚠ Áp ở mức TỔ CHỨC
      → mọi project hiện có và
        MỌI PROJECT TẠO SAU

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

"Cloud Monitoring"
    → ⚠ PHÁT HIỆN sau khi đã xảy ra,
      không NGĂN

"Cloud Build" → ⚠ CI/CD
"Cloud Billing" → ⚠ chi phí

Đối chiếu #13494 và #13487 (lô 143) — hai đề đó khoá vai IAM không có quyền xoá. Ở đây yêu cầu là cấm một hành vi trên toàn tổ chức, nên là Organization Policy. Không mâu thuẫn — hai công cụ ở hai tầng khác nhau.

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

• D (Cloud Monitoring) — phương án gần nhất vì cũng là công cụ quản trị và có thể cảnh báo khi bucket bị mở, nhưng đề đòi NGĂN CHẶN, không phải phát hiện.

• C (Cloud Build) và A (Cloud Billing) — không liên quan.

Ghi nhớ

⚠ Bốn tầng kiểm soát — bảng phải thuộc: | Tầng | Tác dụng | |---|---| | IAM | ⚠ ai được làm gì | | IAM Deny policy | ⚠ chặn tường minh dù có vai | | ⚠ Organization Policy | ⚠ cấm HÀNH VI, kế thừa toàn cây | | Quota | ⚠ giới hạn số lượng | | Audit log | ⚠ ghi lại, phát hiện sau |

Từ khoá nhận diện:

"cấm hành vi trên toàn tổ chức" → ⚠ Organization Policy "cấp quyền cho người dùng" → IAM "phát hiện cấu hình sai" → ⚠ Security Command Center "giới hạn số tài nguyên" → quota

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bucket nào công khai không | ⚠ rà trước khi bật chính sách | | Có ứng dụng nào đang dựa vào bucket công khai | ⚠ kiểm để không làm gãy | | Chính sách có áp cho project mới không | ⚠ áp ở mức tổ chức là có |

Và giá trị lớn nhất của việc đặt chính sách ở mức tổ chức nằm ở thì tương lai: nó bảo vệ cả những project chưa được tạo ra. Một quy tắc viết trong tài liệu nội bộ chỉ có tác dụng với người đã đọc nó; một ràng buộc ở mức tổ chức có tác dụng với mọi người, mãi mãi.

Đáp án

A — Vertex AI.

Vì sao đúng

Đội cần toàn quyền kiểm soát: tự chọn framework (TensorFlow hay PyTorch), tự viết mã mô hình — và cần một nền tảng thống nhất quản lý cả quy trình MLOps. Vertex AI hỗ trợ đúng hai vế đó.

⚠ Vertex AI phục vụ cả hai kiểu người dùng:

⚠ NGƯỜI KHÔNG VIẾT MÃ
    → AutoML: chọn dữ liệu,
      bấm huấn luyện

⚠ KỸ SƯ ML — đề này
    → ⚠ custom training container
    → ⚠ TensorFlow, PyTorch,
      scikit-learn, XGBoost, JAX
    → ⚠ toàn quyền viết mã
    → ⚠ dùng GPU/TPU có quản lý
        ↓
    ⚠ CẢ HAI dùng chung: Registry,
      Endpoint, Pipelines, Monitoring

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

"BigQuery"
    → ⚠ BigQuery ML dựng mô hình
      BẰNG SQL — ngược với yêu cầu
      "tự chọn framework và tự
       viết mã"

"Looker"    → ⚠ công cụ BI
"Cloud SQL" → ⚠ CSDL quan hệ

⚠ Gần trùng với #13535, #13547, #13552 (cùng lô) — bốn đề cùng khoá Vertex AI ở bốn góc khác nhau: phục vụ mô hình, vòng đời đầu-cuối, nền tảng MLOps trung tâm, và huấn luyện tuỳ biến. Hoàn toàn nhất quán. Đối chiếu #13523 (cùng lô) khoá BigQuery ML vì ở đó yêu cầu là chỉ dùng SQL.

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

• C (BigQuery) — phương án gần nhất vì BigQuery ML thật sự huấn luyện được mô hình, nhưng bằng SQL, không cho chọn framework và viết mã mô hình.

• B (Looker) và D (Cloud SQL) — không phải nền tảng học máy.

Ghi nhớ

⚠ Bốn nấc theo mức kiểm soát — bảng phải thuộc: | Nấc | Bạn viết gì | Dịch vụ | |---|---|---| | API dựng sẵn | ⚠ chỉ lời gọi | Vision, Speech | | BigQuery ML | ⚠ SQL | BigQuery | | AutoML | ⚠ không viết mã | Vertex AI | | ⚠ Custom training | ⚠ MÃ MÔ HÌNH — đề này | ⚠ Vertex AI |

Từ khoá nhận diện:

"tự chọn framework, tự viết mã" → ⚠ Vertex AI custom training "chỉ dùng SQL" → BigQuery ML "không có kỹ sư ML" → AutoML "tác vụ phổ quát" → API dựng sẵn

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có thật sự cần tự viết mã không | ⚠ thử AutoML trước — có khi đủ | | Dữ liệu là bảng hay ảnh/văn bản | ⚠ bảng thì XGBoost thường thắng deep learning | | Ai duy trì mã mô hình sau này | ⚠ mã tuỳ biến là gánh nặng dài hạn |

Và bước đáng làm trước khi một đội bắt tay viết mô hình tuỳ biến: chạy AutoML trên chính tập dữ liệu đó để lấy một mốc so sánh. Nếu mô hình tự viết không vượt được mốc ấy một cách rõ ràng, thì công sức bỏ ra đang mua về sự phức tạp chứ không phải chất lượng.

Đáp án

D — Principle of Least Privilege (nguyên tắc đặc quyền tối thiểu).

Vì sao đúng

Đặc quyền tối thiểu: mỗi người chỉ được cấp đúng mức quyền tối thiểu cần để làm việc của mình — nhà phân tích đọc được dữ liệu nhưng không xoá được.

⚠ Vì sao nguyên tắc này quan trọng:

Cấp quyền RỘNG cho tiện
        ↓
    ⚠ Tài khoản bị chiếm →
      kẻ tấn công có luôn quyền đó
    ⚠ Thao tác nhầm → hậu quả lớn
    ⚠ Người trong nội bộ lạm quyền
        ↓
    ⚠ Quyền tối thiểu GIỚI HẠN
      thiệt hại của MỌI kịch bản

⚠ Áp dụng thực tế:

Nhà phân tích dữ liệu
        ↓
    ⚠ `bigquery.dataViewer` — ĐỌC
    ⚠ `bigquery.jobUser` — chạy
      truy vấn
        ↓
    ⚠ KHÔNG cấp `bigquery.dataEditor`
      hay `dataOwner`
        ↓
    → đọc được, KHÔNG xoá được

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

"Defense in Depth"
    → ⚠ NHIỀU LỚP phòng thủ chồng lên
      nhau — nguyên tắc khác

"Zero Trust"
    → ⚠ không tin vào vị trí mạng,
      luôn xác minh — nguyên tắc khác

"Authentication"
    → ⚠ xác minh danh tính, không
      phải mức quyền

Nhất quán với #13537 (cùng lô) về authorization, và #13494/#13487 (lô 143) — hai đề đó chính là áp dụng nguyên tắc này bằng cách chọn vai không có quyền xoá.

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

• B (Zero Trust) — phương án gần nhất vì cũng là một nguyên tắc bảo mật nền tảng và thường đi cùng least privilege, nhưng nó nói về việc không tin tưởng mặc định theo vị trí mạng.

• A (Defense in Depth) — nói về nhiều lớp phòng thủ.

• C (Authentication) — bước xác minh danh tính.

Ghi nhớ

⚠ Bốn nguyên tắc bảo mật — bảng phải thuộc: | Nguyên tắc | Nội dung | |---|---| | ⚠ Least Privilege | ⚠ quyền tối thiểu đủ dùng | | ⚠ Defense in Depth | ⚠ nhiều lớp phòng thủ chồng lên nhau | | ⚠ Zero Trust | ⚠ không tin theo vị trí mạng, luôn xác minh | | Separation of Duties | ⚠ tách quyền để một người không làm trọn quy trình |

Từ khoá nhận diện:

"chỉ đủ quyền để làm việc" → ⚠ least privilege "nhiều lớp bảo vệ" → defense in depth "trong hay ngoài mạng đều phải xác minh" → zero trust "người duyệt khác người thực hiện" → ⚠ separation of duties

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang có vai Owner | ⚠ kiểm ngay, danh sách thường dài | | Quyền nào cấp mà không dùng | ⚠ IAM Recommender | | Service account nào quá mạnh | ⚠ đặc biệt là của CI/CD |

Và nơi nguyên tắc này hay bị bỏ quên nhất không phải ở tài khoản con người, mà ở service account của đường ống triển khai — thứ thường được cấp quyền rất rộng để mọi việc chạy trơn, rồi giữ nguyên quyền đó suốt nhiều năm mà không ai rà lại.