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

Đáp án

A — Nó tăng cường đáng kể bảo mật tài khoản bằng cách thêm một lớp xác thực thứ hai.

Vì sao đúng

Đề mô tả đúng vấn đề mà 2SV giải: mật khẩu bị đánh cắp qua phishing vẫn không đủ để đăng nhập.

⚠ Vì sao 2SV chặn được kịch bản trong đề:

Kẻ tấn công có MẬT KHẨU
(lấy được qua phishing)
        ↓
    KHÔNG có 2SV
        ↓
    ⚠ Đăng nhập thành công ngay
        ↓
    CÓ 2SV
        ↓
    ⚠ Còn cần MÃ từ ứng dụng
      xác thực trên ĐIỆN THOẠI
        ↓
    ⚠ Kẻ tấn công KHÔNG có
      điện thoại đó
        ↓
    → tấn công thất bại

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

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

⚠ ĐIỀU BẠN CÓ
    → điện thoại, khoá bảo mật

⚠ ĐIỀU BẠN LÀ
    → vân tay, khuôn mặt
        ↓
    ⚠ 2SV = kết hợp HAI yếu tố
      KHÁC LOẠI

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

"LOẠI BỎ nhu cầu có mật khẩu"
    → ⚠ 2SV THÊM một lớp,
      KHÔNG bỏ mật khẩu
    → (passwordless là chuyện khác)

"ĐẢM BẢO vượt qua MỌI kiểm toán
 tuân thủ"
    → ⚠ 2SV là MỘT biện pháp
    → ⚠ không đảm bảo được gì
      "mọi"

"Dễ CHIA SẺ tài khoản với đồng nghiệp"
    → ⚠ NGƯỢC LẠI: 2SV làm việc
      chia sẻ tài khoản KHÓ HƠN
    → và chia sẻ tài khoản vốn
      là thực hành XẤU

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

• C (đảm bảo vượt qua mọi kiểm toán tuân thủ) — phương án gần nhất về mặt "cũng là lợi ích thật": 2SV thường là yêu cầu của nhiều chuẩn tuân thủ. Nhưng chữ "đảm bảo mọi" làm nó sai — tuân thủ đòi hỏi nhiều biện pháp khác nữa.

• B (loại bỏ nhu cầu có mật khẩu) — 2SV thêm lớp thứ hai, không bỏ mật khẩu.

• D (dễ chia sẻ tài khoản) — ngược lại, và chia sẻ tài khoản là thực hành xấu.

Ghi nhớ

⚠ Các phương thức 2SV — xếp theo độ mạnh: | Phương thức | Độ mạnh | |---|---| | ⚠ Khoá bảo mật phần cứng (Titan) | ⚠ MẠNH NHẤT — chống được phishing | | Google Prompt | mạnh, tiện | | Ứng dụng xác thực (TOTP) | ⚠ tốt — đề này | | Mã dự phòng | dùng khi mất thiết bị | | SMS | ⚠ YẾU NHẤT — bị SIM swap |

Từ khoá nhận diện:

"thêm lớp xác thực thứ hai" → 2SV / MFA "chống được cả phishing" → ⚠ khoá bảo mật phần cứng "không tin theo vị trí mạng" → zero trust "xét cả thiết bị và ngữ cảnh" → Context-Aware Access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bao nhiêu % tài khoản đã bật 2SV | 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 | | Có tài khoản dùng chung nào không | ⚠ 2SV không hoạt động tốt với tài khoản dùng chung |

Và một con số đáng ghi nhớ khi thuyết phục ban lãnh đạo đầu tư vào 2SV: nó chặn được phần lớn các vụ chiếm tài khoản tự động. Không có biện pháp bảo mật nào khác cho tỉ lệ hiệu quả trên chi phí cao đến vậy — và với khoá phần cứng, con số đó còn tiến gần tới tuyệt đối với riêng loại tấn công phishing.

Đáp án

A — Security Command Center.

Vì sao đúng

Đề đòi một bảng điều khiển tập trung để phát hiện nhanh bucket công khai và các cấu hình sai khác — đó là chức năng cốt lõi của Security Command Center.

⚠ Vì sao SCC phù hợp:

⚠ Quét TOÀN BỘ tổ chức
    → mọi project, kể cả mới tạo

⚠ Phát hiện dựng sẵn
    → PUBLIC_BUCKET_ACL
    → PUBLIC_IP_ADDRESS
    → OPEN_FIREWALL
    → quyền quá rộng

⚠ Bảng điều khiển tập trung
    → xem, lọc, xuất, theo dõi
      tiến độ khắc phục

⚠ Liên tục, không phải rà tay

⚠ Bucket công khai — vì sao là rủi ro số một:

Gán `allUsers` quyền đọc
        ↓
    ⚠ BẤT KỲ AI trên Internet
      cũng đọc được
    ⚠ Không cần đăng nhập
    ⚠ Có thể bị Google index
        ↓
    ⚠ Đây là nguyên nhân của
      RẤT NHIỀU vụ rò rỉ dữ liệu
      đám mây nổi tiếng

⚠ Ngăn chặn tận gốc:

⚠ Organization Policy:
  `storage.publicAccessPrevention`
        ↓
    ⚠ CẤM tạo bucket công khai
      ở MỌI project
    ⚠ Kể cả Owner cũng không lách
        ↓
    ⚠ Nhưng KHÔNG tự sửa cái
      đã tồn tại → vẫn cần SCC
      để rà và dọn

⚠ Gần trùng với #13445 (cùng lô này) — đề đó cũng hỏi cách rà soát rủi ro trên toàn tổ chức và cùng khoá Security Command Center. Hoàn toàn nhất quán.

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

• C (Cloud Armor) — phương án gần nhất về mặt "cũng là sản phẩm bảo mật", nhưng nó chặn tấn công ở biên (DDoS, WAF). Nó không quét cấu hình tài nguyên của bạn.

• D (Cloud Monitoring) — theo dõi hiệu năng và tình trạng hệ thống, không phải cấu hình bảo mật.

• B (Cloud Billing) — báo cáo chi phí.

Ghi nhớ

⚠ Công cụ bảo mật — chặn hay phát hiện: | Công cụ | Vai trò | |---|---| | ⚠ Security Command Center | ⚠ PHÁT HIỆN cấu hình sai và rủi ro | | Organization Policy | ⚠ CHẶN từ đầu, kể cả Owner | | Cloud Armor | CHẶN tấn công ở biên | | IAM | ai được làm gì | | VPC Service Controls | vành đai chống rò rỉ | | Cloud Audit Logs | ghi lại, điều tra sau |

Từ khoá nhận diện:

"tìm bucket công khai, cấu hình sai" → Security Command Center "cấm tạo bucket công khai" → ⚠ Organization Policy "chống DDoS và WAF" → Cloud Armor "ai có quyền gì" → Policy Analyzer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bucket công khai nào không | ⚠ SCC — lọc PUBLIC_BUCKET_ACL | | Đã chặn tạo mới chưa | Organization Policy | | Ai đã đặt nó công khai | Cloud Audit Logs |

Và một điều nên làm ngay sau khi dọn xong bucket công khai đầu tiên: bật publicAccessPrevention ở cấp tổ chức. Phát hiện và sửa là việc phải làm liên tục; chặn từ đầu là việc chỉ phải làm một lần — và nó loại bỏ hẳn loại rủi ro phổ biến nhất trong bảo mật đám mây.

Đáp án

A — Replatform.

Vì sao đúng

Đề mô tả chính xác đặc trưng của replatform: thay đổi có mục tiêu, vừa đủ để tận dụng năng lực đám mây, mà không viết lại ứng dụng.

⚠ Hai vế của đề:

"vài THAY ĐỔI CÓ MỤC TIÊU
 (targeted changes)"
        ↓
    ⚠ CÓ thay đổi — không phải rehost

"chuyển từ CSDL TỰ QUẢN sang
 dịch vụ CÓ QUẢN LÝ như Cloud SQL"
        ↓
    ⚠ Đổi NỀN TẢNG, giữ ứng dụng
        ↓
    → REPLATFORM

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

REHOST
    → ⚠ bê nguyên lên VM
    → không sửa gì
    → vẫn tự vá, tự sao lưu

⚠ REPLATFORM              ← đề này
    → ⚠ đổi sang dịch vụ có quản lý
    → ⚠ sửa nhẹ: chuỗi kết nối
    → Google lo vá, sao lưu, HA

REFACTOR
    → ⚠ VIẾT LẠI kiến trúc
    → tách microservices
    → mất hàng tháng

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

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

Lợi ích: rất lớn
    ⚠ bỏ hẳn việc vá CSDL
    ⚠ sao lưu tự động + PITR
    ⚠ 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

⚠ Gần trùng với #13385 (lô 141) và #13297 (lô 140) — cả ba đề đều là chuyển CSDL tự quản sang Cloud SQL mà không sửa ứng dụng, và cả ba cùng khoá Replatform. Hoàn toàn nhất quán.

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

• C (Rehost) — phương án gần nhất và bị nhầm nhiều: rehost là bê nguyên trạng lên VM, tức là cài CSDL trên một máy ảo và vẫn tự vá. Đề nói rõ họ dùng dịch vụ CÓ QUẢN LÝ.

• D (Reimagine) — không phải một chiến lược trong bộ "6 R" chuẩn; từ gần nghĩa là Refactor.

• B (Retire) — bỏ hẳn ứng dụng; ở đây họ đang chuyển nó đi.

Ghi nhớ

⚠ Bộ "6 R" — bảng phải thuộc: | Chiến lược | Nội dung | |---|---| | Rehost | bê nguyên lên VM — nhanh nhất | | ⚠ Replatform | ⚠ đổi sang dịch vụ có quản lý — điểm ngọt | | Refactor | viết lại kiến trúc — lợi ích lớn nhất | | Repurchase | thay bằng SaaS | | Retire | ⚠ bỏ hẳn | | Retain | giữ lại tại chỗ |

Từ khoá nhận diện:

"dịch vụ có quản lý, không sửa ứng dụng" → Replatform "bê nguyên lên máy ảo" → 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 danh sách Cloud SQL hỗ trợ | | 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 |

Và một lý do khiến cơ sở dữ liệu thường là ứng viên replatform đầu tiên trong mọi dự án di cư: nó là thứ tốn công vận hành nhất nhưng lại dễ thay thế nhất. Đổi chuỗi kết nối mất một buổi chiều, còn thứ bạn bỏ lại là những đêm thức trắng vì vá bảo mật và khôi phục sao lưu.

Đáp án

B — Container.

Vì sao đúng

Đề nêu ba đặc điểm, và cụm quyết định là "ảo hoá HỆ ĐIỀU HÀNH":

⚠ Ba đặc điểm ↔ container:

1. "đóng gói MÃ cùng PHỤ THUỘC
    để chạy trong môi trường
    CÁCH LY"
     → ⚠ đúng định nghĩa container

2. "NHẸ HƠN và KHỞI ĐỘNG NHANH HƠN
    máy ảo truyền thống"
     → ⚠ MB thay vì GB,
       giây thay vì phút

3. ⚠ "bằng cách ẢO HOÁ HỆ ĐIỀU HÀNH"
     → ⚠ đây là cụm quyết định
     → máy ảo ảo hoá PHẦN CỨNG

⚠ Hai tầng ảo hoá:

        MÁY ẢO                 CONTAINER
   ┌──────────────┐       ┌──────────────┐
   │  Ứng dụng    │       │  Ứng dụng    │
   │  Thư viện    │       │  Thư viện    │
   │ ⚠ OS KHÁCH   │       └──────────────┘
   └──────────────┘        Container runtime
   ⚠ HYPERVISOR           ┌──────────────┐
   (ảo hoá PHẦN CỨNG)     │ ⚠ OS CHỦ     │
   ┌──────────────┐       │ (dùng CHUNG  │
   │  OS máy chủ  │       │  NHÂN)       │
   └──────────────┘       └──────────────┘
     Phần cứng              Phần cứng

⚠ Vì sao nhẹ hơn và nhanh hơn:

VM mang theo CẢ MỘT HỆ ĐIỀU HÀNH
        ↓
    ⚠ nặng hàng GB
    ⚠ khởi động mất PHÚT

CONTAINER dùng CHUNG NHÂN
với hệ chủ
        ↓
    ⚠ nhẹ hàng MB
    ⚠ khởi động trong GIÂY
    ⚠ chạy được hàng trăm cái
      trên một máy

⚠ Gần trùng với #13290 (lô 139) — đề đó cũng hỏi công nghệ đóng gói ứng dụng cùng phụ thuộc, và cùng khoá container. Và #13349 (lô 139) về khác biệt kỹ thuật giữa container và VM. Cả ba nhất quán.

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

• D (serverless function) — phương án gần nhất về mặt "cũng nhẹ và khởi động nhanh", nhưng nó là mô hình THỰC THI, không phải kỹ thuật đóng gói. (Và Cloud Run Functions thực chất chạy bên trong container.)

• C (máy chủ vật lý) — không đóng gói gì cả.

• A (luật tường lửa) — cơ chế kiểm soát mạng, không liên quan.

Ghi nhớ

⚠ Container và VM — bảng phải thuộc: | | Container | Máy ảo | |---|---|---| | Ảo hoá | ⚠ HỆ ĐIỀU HÀNH | ⚠ PHẦN CỨNG | | Mang theo | ứng dụng + thư viện | ⚠ cả một OS khách | | Kích thước | MB | GB | | Khởi động | ⚠ giây | ⚠ phút | | Nhân OS | ⚠ DÙNG CHUNG | riêng | | Cách ly | mức tiến trình | ⚠ mạnh hơn |

Từ khoá nhận diện:

"đóng gói cùng phụ thuộc, nhẹ, ảo hoá OS" → container "ảo hoá phần cứng, hypervisor" → máy ảo "không quản máy chủ, co về 0" → serverless "điều phối hàng trăm container" → GKE

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 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

B — VPC và Firewall Rules.

Vì sao đúng

Đề đòi hai điều kiện trái chiều: VM giao tiếp được với VM khác cùng project, nhưng không truy cập được từ Internet công cộng. Đó chính là việc của VPC và luật tường lửa.

⚠ Cấu hình đúng:

1. ⚠ ĐỪNG GÁN IP CÔNG KHAI
     → ⚠ đây là bước quan trọng nhất
     → không có IP công khai thì
       Internet không tới được

2. VM nằm trong VPC với IP nội bộ
     → nói chuyện được với VM khác
       cùng VPC

3. LUẬT TƯỜNG LỬA:
     - ⚠ INGRESS mặc định là DENY
     - tạo luật ALLOW cho lưu lượng
       từ dải IP nội bộ
        ↓
    ⚠ Nội bộ thông, ngoài chặn

⚠ Hai luật mặc định phải nhớ:

⚠ INGRESS (đi vào)
    → mặc định ⚠ DENY tất cả
    → phải tạo luật ALLOW mới thông

⚠ EGRESS (đi ra)
    → mặc định ⚠ ALLOW tất cả
    → phải tạo luật DENY mới chặn
        ↓
    → với đề này, mặc định INGRESS
      đã bảo vệ sẵn

⚠ Nếu VM cần gọi API Google:

VM không có IP công khai
        ↓
    ⚠ Bật PRIVATE GOOGLE ACCESS
      trên subnet
        ↓
    → gọi được BigQuery, Cloud Storage
      qua IP nội bộ
        ↓
    Nếu cần ra Internet để tải gói
        ↓
    ⚠ Dùng CLOUD NAT
      → ra được nhưng KHÔNG ai
        vào được từ ngoài

⚠ Gần trùng với #13446 (cùng lô này) — đề đó cũng dùng VPC Firewall Rules để kiểm soát lưu lượng, nhưng theo hướng chặn EGRESS ra Internet. Câu này chặn INGRESS từ Internet. Cùng công cụ, hai hướng. Nhất quán.

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

• D (Cloud Load Balancing) — phương án gần nhất về mặt "cũng liên quan tới mạng", nhưng nó phân phối lưu lượng đến; nếu dùng nó thì càng mở dịch vụ ra ngoài, ngược yêu cầu.

• C (Cloud DNS) — dịch tên miền thành IP, không kiểm soát truy cập.

• A (Cloud Storage) — lưu tệp; không liên quan tới cách ly mạng.

Ghi nhớ

⚠ Các lớp kiểm soát mạng — bảng phải thuộc: | Lớp | Việc | |---|---| | ⚠ VPC | ⚠ mạng riêng ảo — TOÀN CẦU trên Google Cloud | | ⚠ Firewall Rules | ⚠ cho phép/chặn theo IP, cổng, tag | | Private Google Access | ⚠ VM không IP công khai gọi được API Google | | Cloud NAT | ⚠ ra Internet mà không cần IP công khai | | VPC Service Controls | vành đai chống rò rỉ dữ liệu | | Cloud Armor | chống tấn công ở biên |

Từ khoá nhận diện:

"không truy cập được từ Internet" → ⚠ không gán IP công khai + firewall "VM cần ra Internet nhưng không cho vào" → Cloud NAT "gọi API Google từ VM riêng tư" → Private Google Access "chặn dữ liệu sang project khác" → VPC Service Controls

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM có IP công khai không | ⚠ kiểm và gỡ nếu không cần | | Có cổng nào mở ra Internet không | Firewall Insights hoặc SCC | | Nội bộ còn thông không | thử kết nối giữa hai VM |

Và một thói quen nên áp cho mọi máy ảo mới: mặc định KHÔNG gán IP công khai. Đó là tuỳ chọn bật sẵn khi tạo VM và là nguyên nhân của rất nhiều bề mặt tấn công không cần thiết — trong khi IAP và Cloud NAT đã đủ cho hầu hết nhu cầu truy cập thực tế.

Đáp án

A — Autoscaling (tự động mở rộng).

Vì sao đúng

Đề mô tả đúng một việc: MIG tự động THÊM instance khi lưu lượng tăng đột ngột — đó là autoscaling.

⚠ Cơ chế:

Lưu lượng tăng vọt
        ↓
    CPU trung bình của nhóm
    vượt ngưỡng mục tiêu
        ↓
    ⚠ Autoscaler của MIG
      TẠO THÊM instance
      từ instance template
        ↓
    Lưu lượng giảm
        ↓
    ⚠ Autoscaler XOÁ BỚT instance
        ↓
    → năng lực bám theo tải thật

⚠ Phân biệt với ba phương án kia:

MANUAL SCALING
    → ⚠ phải có NGƯỜI bấm
    → đề nói rõ "TỰ ĐỘNG"

LOAD BALANCING
    → ⚠ CHIA lưu lượng giữa các
      instance ĐÃ CÓ
    → không thêm instance
    → đi cùng autoscaling nhưng
      là việc khác

LIVE MIGRATION
    → ⚠ chuyển VM đang chạy sang
      máy chủ vật lý khác khi
      Google bảo trì
    → ⚠ VM KHÔNG dừng
    → không liên quan tới tải

⚠ Live migration — tính năng riêng của Google:

Google cần bảo trì phần cứng
        ↓
    ⚠ VM được CHUYỂN SỐNG sang
      máy chủ khác
    ⚠ Ứng dụng KHÔNG bị dừng
        ↓
    → đây là tính năng về
      ĐỘ TIN CẬY, không phải
      về MỞ RỘNG

⚠ Gần trùng với #13359 (lô 140) — đề đó cũng mô tả MIG thêm/bớt instance theo CPU và cùng khoá autoscaling. Và #13319 (lô 140) về MIG tự chữa lành. Cả ba nhất quán.

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

• C (load balancing) — phương án gần nhất và luôn đi cùng autoscaling, nhưng nó phân phối lưu lượng giữa các instance đã có, không tạo thêm instance.

• B (manual scaling) — cần người bấm; đề nói rõ là tự động.

• D (live migration) — chuyển VM sang máy chủ vật lý khác khi bảo trì; là tính năng về độ tin cậy, không liên quan tới tải.

Ghi nhớ

⚠ Các tính năng của MIG — bảng phải thuộc: | Tính năng | Việc | |---|---| | ⚠ Autoscaling | ⚠ thêm/bớt instance theo tải | | Autohealing | ⚠ tạo lại instance khi health check fail | | Rolling update | cập nhật dần, quay lui được | | Regional MIG | ⚠ trải instance qua nhiều zone | | Instance template | ⚠ khuôn bất biến |

Từ khoá nhận diện:

"tự thêm/bớt máy theo tải" → autoscaling "chia lưu lượng" → load balancing "máy chết thì tạo lại" → autohealing "VM không dừng khi Google bảo trì" → ⚠ live migration

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có mở rộng kịp không | ⚠ thử tải mô phỏng đỉnh | | Có thu hẹp lại không | xem số instance ban đêm | | Quota có đủ không | xin nâng trước sự kiện |

Và một nửa của autoscaling thường bị bỏ quên: chiều thu hẹp. Nhiều hệ thống mở rộng rất tốt trong ngày cao điểm rồi giữ nguyên số máy đó suốt nhiều tuần sau, đơn giản vì không ai kiểm tra xem chúng có thật sự giảm xuống hay không.

Đáp án

D — Rút ra hiểu biết có ý nghĩa từ dữ liệu đã được chuẩn bị, để dẫn dắt các quyết định kinh doanh.

Vì sao đúng

Trong chuỗi giá trị dữ liệu, Analyze là giai đoạn đặt câu hỏi trên dữ liệu đã sẵn sàng và biến câu trả lời thành hành động.

⚠ Năm giai đoạn của chuỗi giá trị dữ liệu:

1. GENERATE / COLLECT
     → ⚠ thu thập dữ liệu thô
     → chính là phương án A

2. STORE
     → ⚠ lưu vào kho an toàn,
       mở rộng được
     → chính là phương án B

3. TRANSFORM / PROCESS
     → ⚠ làm sạch và biến đổi
       để chuẩn bị dùng
     → chính là phương án C

4. ⚠ ANALYZE
     → ⚠ RÚT RA HIỂU BIẾT
     → truy vấn, dashboard, ML
     → đề này

5. ACTIVATE
     → đưa hiểu biết vào hành động

⚠ Ba phương án sai chính là ba giai đoạn khác:

"Thu thập dữ liệu thô từ nhiều nguồn"
    → ⚠ COLLECT

"Lưu trong kho an toàn, mở rộng được"
    → ⚠ STORE

"Làm sạch và biến đổi để chuẩn bị"
    → ⚠ TRANSFORM
        ↓
    ⚠ Đề cố ý đưa ba giai đoạn
      liền kề làm phương án nhiễu

⚠ Giai đoạn Analyze gồm những gì:

⚠ MÔ TẢ (descriptive)
    → "đã xảy ra gì?"
    → dashboard, báo cáo

⚠ CHẨN ĐOÁN (diagnostic)
    → "vì sao?"
    → khoan sâu, phân đoạn

⚠ DỰ ĐOÁN (predictive)
    → "sẽ xảy ra gì?"
    → học máy

⚠ ĐỀ XUẤT (prescriptive)
    → "nên làm gì?"
    → tối ưu hoá

⚠ Đối chiếu #13389 (lô 141) — đề đó mô tả việc gộp và chuẩn hoá dữ liệu để CHUẨN BỊ trực quan hoá và khoá TRANSFORM. Câu này hỏi giai đoạn rút ra hiểu biết, tức là ANALYZE. Không mâu thuẫn — hai giai đoạn liền kề, ranh giới là chữ "chuẩn bị" hay "rút ra".

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

• C (làm sạch và biến đổi để chuẩn bị dùng) — phương án gần nhất vì đó là giai đoạn ngay trước, nhưng đó là Transform, không phải Analyze.

• A (thu thập dữ liệu thô) — là giai đoạn Collect / Ingest.

• B (lưu trong kho an toàn) — là giai đoạn Store.

Ghi nhớ

⚠ Chuỗi giá trị dữ liệu — bảng phải thuộc: | Giai đoạn | Việc | Sản phẩm | |---|---|---| | Generate / Collect | thu thập | Pub/Sub, Datastream | | Store | lưu | Cloud Storage, BigQuery | | Transform | ⚠ làm sạch, chuẩn hoá | Dataflow, Dataform | | ⚠ Analyze | ⚠ RÚT RA HIỂU BIẾT | ⚠ BigQuery, Looker, Vertex AI | | Activate | đưa vào hành động | |

Từ khoá nhận diện:

"rút ra hiểu biết, dẫn dắt quyết định" → Analyze "làm sạch, gộp, chuẩn hoá" → Transform "nhận dữ liệu vào" → Collect / Ingest "lưu ở đâu" → Store

Ba câu hỏi kiểm chứng: | Câu hỏi | Giai đoạn | |---|---| | Dữ liệu đến từ đâu | Collect | | Đã sạch chưa | Transform | | Ai dùng kết quả và làm gì với nó | ⚠ Analyze và Activate |

Và một câu hỏi nên đặt cho mọi dự án phân tích trước khi bắt đầu: ai sẽ HÀNH ĐỘNG dựa trên kết quả này? Nếu không có câu trả lời rõ ràng, thì dù dashboard có đẹp đến đâu, giai đoạn Analyze cũng chỉ dừng ở việc tạo ra những con số không ai dùng tới.

Đáp án

A — Microservices (kiến trúc vi dịch vụ).

Vì sao đúng

Đề nêu ba đặc trưng, và cụm quyết định là "độc lập với ngôn ngữ lập trình":

⚠ Ba đặc trưng ↔ microservices:

1. "chia ứng dụng thành các
    DỊCH VỤ NHỎ"
     → mỗi dịch vụ một chức năng

2. ⚠ "ĐỘC LẬP VỚI NGÔN NGỮ
    (language-agnostic)"
     → ⚠ mỗi đội dùng ngôn ngữ
       mạnh nhất của mình

3. "giao tiếp QUA MẠNG"
     → ⚠ REST, gRPC, hoặc
       thông điệp bất đồng bộ

⚠ Vì sao "độc lập ngôn ngữ" là lợi thế:

Khối nguyên (monolith)
        ↓
    ⚠ MỌI người phải dùng
      CÙNG một ngôn ngữ
    ⚠ Đội giỏi Python phải
      viết Java

Microservices
        ↓
    ⚠ Dịch vụ tính toán → Python
    ⚠ Dịch vụ hiệu năng cao → Go
    ⚠ Dịch vụ nghiệp vụ cũ → Java
        ↓
    ⚠ Giao tiếp qua HỢP ĐỒNG API,
      không qua ngôn ngữ

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

MONOLITHIC
    → ⚠ một khối duy nhất
    → ngược hẳn

SERVERLESS
    → ⚠ mô hình VẬN HÀNH
      (không quản máy chủ)
    → không phải cách CHIA ứng dụng
    → (microservice có thể chạy
       serverless)

TWO-TIER
    → ⚠ kiến trúc hai tầng cổ điển
      (máy khách + CSDL)
    → không phải chia nhỏ dịch vụ

⚠ Gần trùng với #13256 (lô 138) và #13393 (lô 141) — cả ba đề đều mô tả việc chia ứng dụng thành dịch vụ nhỏ, ghép lỏng, triển khai độc lập, và cả ba cùng khoá Microservices. Hoàn toàn nhất quán.

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

• D (Serverless) — phương án gần nhất về mặt "cũng là kiến trúc hiện đại", và microservices thường chạy trên nền serverless. Nhưng serverless nói về ai quản máy chủ, còn câu hỏi là về cách chia ứng dụng.

• C (Monolithic) — một khối duy nhất; ngược hẳn.

• B (Two-tier) — kiến trúc hai tầng cổ điển; không phải chia nhỏ theo chức năng nghiệp vụ.

Ghi nhớ

⚠ Monolith và microservices — bảng phải thuộc: | | Monolith | Microservices | |---|---|---| | Triển khai | cả khối | ⚠ từng dịch vụ độc lập | | Mở rộng | nhân cả khối | ⚠ nhân đúng phần cần | | Lỗi | có thể sập tất cả | ⚠ cô lập | | Ngôn ngữ | ⚠ thống nhất một stack | ⚠ mỗi dịch vụ chọn riêng | | ⚠ Độ phức tạp | thấp | ⚠ CAO |

Từ khoá nhận diện:

"nhỏ, độc lập ngôn ngữ, giao tiếp qua mạng" → microservices "không quản máy chủ" → serverless "đóng gói cùng phụ thuộc" → container "chạy nguyên trạng trên đám mây" → rehost

Ba câu hỏi kiểm chứng: | Câu hỏi | Nếu... | |---|---| | Triển khai một dịch vụ có đụng dịch vụ khác không | có → chưa độc lập | | Hai dịch vụ có dùng chung bảng CSDL không | ⚠ có → vẫn ghép chặt | | Có lần theo được request xuyên dịch vụ không | không → thiếu quan sát |

Và một điều cần cân nhắc kỹ với lợi thế "độc lập ngôn ngữ": tự do chọn ngôn ngữ nghe rất hấp dẫn cho đến khi phải bảo trì năm stack khác nhau. Phần lớn tổ chức trưởng thành cuối cùng đều thu hẹp về vài ngôn ngữ được duyệt — giữ lại lợi ích của việc tách dịch vụ mà không gánh chi phí của sự phân mảnh.

Đáp án

D — Malware (phần mềm độc hại).

Vì sao đúng

Malware là thuật ngữ bao trùm cho mọi phần mềm được thiết kế để gây hại — đúng như đề mô tả.

⚠ Malware là từ ghép:

MALicious + softWARE
    → ⚠ phần mềm ĐỘC HẠI
        ↓
    Bao gồm:
      ⚠ virus, worm, trojan
      ⚠ ransomware
      ⚠ spyware, adware
      ⚠ rootkit, keylogger
      ⚠ cryptominer

⚠ Vì sao ba phương án kia không phải:

PHISHING KIT
    → ⚠ bộ công cụ dựng TRANG GIẢ
    → là công cụ cho một loại
      tấn công KHÁC
    → không phải phần mềm cài
      lên máy nạn nhân

IAM POLICY
    → ⚠ chính sách phân quyền
    → là cơ chế BẢO VỆ

FIREWALL RULE
    → ⚠ luật tường lửa
    → cũng là cơ chế BẢO VỆ

⚠ Kịch bản trong đề — hai giai đoạn:

1. ⚠ TRUY CẬP TRÁI PHÉP vào VM
     → có thể qua: mật khẩu yếu,
       SSH mở ra Internet,
       lỗ hổng chưa vá,
       khoá bị lộ

2. ⚠ CÀI PHẦN MỀM ĐỘC HẠI
     → đây là MALWARE
        ↓
    ⚠ Phải xử lý CẢ HAI:
      bịt đường vào VÀ dọn malware

⚠ Đối chiếu #13435 (cùng lô này) — đề đó khoá Phishing vì mô tả việc lừa lấy thông tin đăng nhập qua email. Câu này khoá Malware vì mô tả việc cài phần mềm độc hại lên máy. Không mâu thuẫn — hai giai đoạn khác nhau của một chuỗi tấn công.

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

• A (phishing kit) — phương án gần nhất về mặt "cũng là công cụ của kẻ tấn công", nhưng đó là bộ công cụ dựng trang đăng nhập giả, không phải phần mềm cài lên máy nạn nhân.

• B (IAM policy) và C (firewall rule) — đều là cơ chế bảo vệ của Google Cloud, không phải phần mềm độc hại.

Ghi nhớ

⚠ Các loại malware — bảng nên thuộc: | Loại | Đặc điểm | |---|---| | Virus | lây khi người dùng chạy tệp nhiễm | | Worm | ⚠ tự lan qua mạng, không cần người | | Trojan | giả dạng phần mềm hữu ích | | ⚠ Ransomware | ⚠ mã hoá dữ liệu, đòi tiền chuộc | | Spyware | lén thu thập thông tin | | Rootkit | ⚠ ẩn mình ở tầng sâu, rất khó phát hiện | | Cryptominer | ⚠ đào tiền mã hoá bằng máy của bạn | | Keylogger | ghi lại phím gõ |

Từ khoá nhận diện:

"phần mềm được thiết kế để gây hại" → malware "mã hoá dữ liệu đòi tiền chuộc" → ransomware "email giả lừa lấy mật khẩu" → phishing "dội lưu lượng làm sập" → DDoS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cổng nào mở ra Internet không | ⚠ Security Command Center | | VM đã vá tới đâu | VM Manager | | CPU có bất thường không | ⚠ dấu hiệu cryptominer |

Và một nguyên tắc quan trọng khi xử lý máy ảo bị xâm nhập: dựng lại từ image sạch, đừng cố dọn máy cũ. Bạn không bao giờ chắc chắn đã tìm hết mọi thứ kẻ tấn công để lại — và với hạ tầng bất biến, dựng lại một máy mới thường nhanh hơn cả việc điều tra.

Đáp án

B — IaaS cho nhiều quyền kiểm soát hơn với hạ tầng bên dưới, còn PaaS cho mức trừu tượng hoá cao hơn và dễ dùng hơn.

Vì sao đúng

Đây là trục đánh đổi cơ bản giữa hai mô hình dịch vụ đám mây.

⚠ Hai đầu của trục:

IaaS (Compute Engine)
    ✔ ⚠ KIỂM SOÁT: chọn OS,
      quyền root, kernel,
      phần mềm bất kỳ
        ↓
    ⚠ Đổi lại: tự cài, tự vá,
      tự cấu hình mở rộng

PaaS (App Engine, Cloud Run)
    ✔ ⚠ DỄ DÙNG: đẩy mã lên là chạy,
      tự mở rộng, tự HTTPS
        ↓
    ⚠ Đổi lại: không chọn OS,
      ràng buộc runtime

⚠ Ai quản tầng nào:

                IaaS      PaaS
Ứng dụng        BẠN       BẠN
Dữ liệu         BẠN       BẠN
Runtime         ⚠ BẠN    n.c.cấp
Middleware      ⚠ BẠN    n.c.cấp
⚠ Hệ điều hành  ⚠ BẠN    n.c.cấp
Ảo hoá         n.c.cấp   n.c.cấp
Phần cứng      n.c.cấp   n.c.cấp

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

"IaaS cho WEB HOSTING, PaaS cho
 LƯU TRỮ DỮ LIỆU"
    → ⚠ hoàn toàn sai — cả hai
      không phân chia theo
      chức năng như vậy

"PaaS cho quyền kiểm soát TRUNG TÂM
 DỮ LIỆU VẬT LÝ"
    → ⚠ KHÔNG mô hình đám mây nào
      cho quyền đó

"IaaS LUÔN đắt hơn PaaS"
    → ⚠ tuỳ tải; PaaS co về 0
      thì rẻ hơn cho tải thất thường,
      còn VM + CUD rẻ hơn cho
      tải ổn định

Nhất quán với #13363 (lô 140) — câu đó hỏi đánh đổi giữa Compute Engine và App Engine và cũng khoá Control vs Ease of Use. Hai câu cùng một trục.

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

• D (IaaS luôn đắt hơn PaaS) — phương án gần nhất về mặt "cũng là một khác biệt có thật đôi khi", nhưng chữ "LUÔN" làm nó sai: không có quy luật chung về giá giữa hai mô hình.

• A (IaaS cho web hosting, PaaS cho lưu trữ dữ liệu) — hoàn toàn sai; hai mô hình không phân chia theo chức năng.

• C (PaaS cho quyền kiểm soát trung tâm dữ liệu vật lý) — không mô hình đám mây nào cho quyền đó.

Ghi nhớ

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

Từ khoá nhận diện:

"toàn quyền kiểm soát OS" → IaaS "chỉ viết mã, không quản hạ tầng" → PaaS "dùng phần mềm có sẵn" → SaaS "đánh đổi giữa IaaS và PaaS" → ⚠ kiểm soát vs dễ dùng

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Có yêu cầu gì đặc biệt ở tầng OS không | có → IaaS | | Ai trong đội muốn vá hệ điều hành | không ai → PaaS | | Tải có ổn định không | ổn định cao → cân nhắc VM + CUD |

Và một cách chọn thực dụng khi phân vân: bắt đầu từ mức dễ dùng nhất giải quyết được bài toán, và chỉ đi xuống khi gặp rào cản thật. Chuyển từ PaaS sang IaaS khi cần là việc làm được; còn thời gian đội bạn tiêu vào vá máy chủ ngay từ đầu thì không lấy lại được.