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

Đáp án

A — "Nó tự động quản lý việc vá hệ điều hành và cập nhật bảo mật cho ứng dụng của người dùng." Đây là mệnh đề KHÔNG đúng.

Vì sao đúng

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

⚠ Compute Engine là IaaS — ranh giới rất rõ:

    ỨNG DỤNG              ← ⚠ BẠN
    RUNTIME, THƯ VIỆN     ← ⚠ BẠN
    ⚠ HỆ ĐIỀU HÀNH KHÁCH  ← ⚠ BẠN
       (vá bảo mật)
  ────────── ranh giới ──────────
    HYPERVISOR             ← Google
    HỆ ĐIỀU HÀNH MÁY CHỦ   ← Google
    PHẦN CỨNG              ← Google
        ↓
    ⚠ Google KHÔNG tự vào VM
      của bạn để vá

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

B. "chọn loại máy với số vCPU và
    bộ nhớ cụ thể"
     → ⚠ ĐÚNG — có cả máy tuỳ chỉnh
       (custom machine type)

C. "quyền root và toàn quyền kiểm soát
    hệ điều hành"
     → ⚠ ĐÚNG — đó chính là điểm
       mạnh của IaaS

D. "được coi là IaaS"
     → ⚠ ĐÚNG — Compute Engine là
       ví dụ chuẩn của IaaS

⚠ Nhưng Google CÓ công cụ giúp:

VM MANAGER (OS Config)
    → ⚠ quản lý bản vá cho
      HÀNG LOẠT VM
    → lên lịch, báo cáo tuân thủ
        ↓
    ⚠ NHƯNG bạn phải BẬT và
      CẤU HÌNH nó
    ⚠ Trách nhiệm vẫn là của bạn
        ↓
    → "có công cụ hỗ trợ" khác hẳn
      "tự động lo cho bạn"

Nhất quán với #13288 (lô 139) — câu đó hỏi trách nhiệm nào thuộc về khách hàng với Compute Engine, và đáp án cũng là vá hệ điều hành khách. Hai câu nhìn cùng một sự thật từ hai hướng.

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

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

• B — Compute Engine thật sự cho chọn loại máy, kể cả cấu hình tuỳ chỉnh vCPU và RAM.
• C — bạn thật sự có quyền root và toàn quyền với hệ điều hành.
• D — Compute Engine thật sự là IaaS.

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, 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 | | Hypervisor, phần cứng | 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 "toàn quyền root, kiểm soát OS" → IaaS "không phải quản OS" → PaaS / serverless "an ninh vật lý, hypervisor" → Google

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ủ | | Ai SSH được vào máy | OS Login + audit log | | Kích cỡ máy có hợp không | Recommender — rightsizing |

Và một hiểu lầm rất phổ biến mà câu hỏi này nhắm đúng vào: "trên đám mây thì nhà cung cấp lo bảo mật hết". Với IaaS thì không — máy ảo của bạn cũng cần vá đều đặn như máy chủ trong phòng máy ngày xưa, chỉ khác là giờ bạn có công cụ tốt hơn để làm việc đó hàng loạt.

Đáp án

A — "Nó đòi người dùng phải cấp phát trước một cụm máy ảo và tự quản việc vá hệ điều hành." Đây là mệnh đề KHÔNG đúng.

Vì sao đúng

⚠ Đây là câu hỏi PHỦ ĐỊNH. Mệnh đề A mô tả GKE Standard hoặc Compute Engine, hoàn toàn ngược với bản chất serverless của Cloud Run.

⚠ Cloud Run là serverless — không có cụm nào cả:

Bạn cung cấp:  ⚠ MỘT CONTAINER IMAGE
Google lo:
    ⚠ máy chủ
    ⚠ hệ điều hành và bản vá
    ⚠ cấp phát và thu hồi tài nguyên
    ⚠ mở rộng và cân bằng tải
    ⚠ chứng chỉ TLS
        ↓
    → không có cụm để dựng,
      không có node để vá

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

B. "tính tiền theo vCPU, bộ nhớ và
    số request thực tế"
     → ⚠ ĐÚNG — tính theo mili-giây

C. "tự lo HTTPS và cấp chứng chỉ TLS
    có quản lý cho tên miền mặc định"
     → ⚠ ĐÚNG — mỗi dịch vụ được
       cấp một URL `*.run.app`
       kèm chứng chỉ tự động

D. "co về 0 khi không có request"
     → ⚠ ĐÚNG — đặc trưng cốt lõi

⚠ Phân biệt ba nền tảng chạy container:

CLOUD RUN
    → ⚠ không thấy máy chủ nào
    → co về 0

GKE AUTOPILOT
    → Google quản node
    → ⚠ cụm vẫn tồn tại và tính tiền

GKE STANDARD / COMPUTE ENGINE
    → ⚠ BẠN quản node và vá OS
    → chính là mô tả trong mệnh đề A

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

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

• B — Cloud Run thật sự tính tiền theo tài nguyên và số request thực dùng.
• C — Cloud Run thật sự cấp HTTPS và chứng chỉ TLS tự động.
• D — Cloud Run thật sự co về 0.

Ghi nhớ

⚠ Cloud Run — đặc điểm phải thuộc: | Đặc điểm | Nội dung | |---|---| | Serverless hoàn toàn | ⚠ không cụm, không node, không vá OS | | Chạy container bất kỳ | ngôn ngữ tuỳ ý | | Co về 0 | không request thì gần như 0 đồng | | Tính tiền theo mili-giây | vCPU, RAM, số request | | HTTPS tự động | ⚠ URL *.run.app kèm chứng chỉ | | Tên miền riêng | cũng có chứng chỉ có quản lý | | Dựa trên Knative | chuẩn mở |

Từ khoá nhận diện:

"không quản máy chủ, co về 0, container" → Cloud Run "tự quản node, vá OS" → GKE Standard / Compute Engine "Google quản node nhưng vẫn có cụm" → GKE Autopilot "hàm theo sự kiện" → Cloud Run Functions

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí lúc rảnh có bằng 0 không | billing report theo ngày | | Có mở rộng vô hạn không | ⚠ kiểm max-instances | | HTTPS có hoạt động không | mở URL *.run.app |

Và một chi tiết nhỏ nhưng hay làm hỏng lần triển khai Cloud Run đầu tiên: container phải đọc số cổng từ biến môi trường PORT. Nền tảng có thể truyền một cổng khác 8080, và một dòng hard-code sẽ khiến dịch vụ không bao giờ vượt qua được bước kiểm tra sức khoẻ.

Đáp án

B — "Làm cơ sở dữ liệu giao dịch độ trễ thấp cho ứng dụng di động." Đây KHÔNG phải ca sử dụng của Cloud Storage.

Vì sao đúng

⚠ Đây là câu hỏi PHỦ ĐỊNH. Cloud Storage là lưu trữ đối tượng, không phải cơ sở dữ liệu.

⚠ Vì sao object storage không làm CSDL được:

CLOUD STORAGE
    → thao tác trên CẢ MỘT ĐỐI TƯỢNG
    → ⚠ KHÔNG sửa được một phần
    → ⚠ KHÔNG truy vấn theo trường
    → ⚠ KHÔNG có giao dịch,
      không có chỉ mục
        ↓
    Muốn đổi một trường trong JSON
        ↓
    ⚠ phải tải CẢ tệp về,
      sửa, rồi ghi ĐÈ toàn bộ
        ↓
    → không thể là CSDL giao dịch

⚠ Ba ca sử dụng kia đều ĐÚNG:

A. "lưu tệp dữ liệu THÔ cho data lake"
     → ⚠ ĐÚNG — Cloud Storage là
       nền của hồ dữ liệu trên
       Google Cloud

C. "lưu BẢN SAO LƯU của CSDL sản xuất"
     → ⚠ ĐÚNG — ca sử dụng kinh điển,
       kết hợp lớp Nearline/Coldline

D. "phục vụ tài nguyên TĨNH (ảnh, CSS)
    cho website"
     → ⚠ ĐÚNG — thường kèm Cloud CDN

⚠ Ứng dụng di động nên dùng gì:

Cần CSDL độ trễ thấp cho app
        ↓
    ⚠ FIRESTORE
      → NoSQL tài liệu
      → đồng bộ thời gian thực
      → hoạt động ngoại tuyến
      → SDK cho iOS và Android
        ↓
    Mẫu đúng:
    ⚠ TỆP (ảnh đại diện) → Cloud Storage
    ⚠ DỮ LIỆU + đường dẫn → Firestore

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

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

• A — data lake trên Cloud Storage là ca sử dụng chuẩn.
• C — lưu bản sao lưu là ca sử dụng chuẩn.
• D — phục vụ tài nguyên tĩnh cho website là ca sử dụng chuẩn.

Ghi nhớ

⚠ Cloud Storage — ca sử dụng đúng và sai: | ✔ Nên dùng cho | ✘ Không nên dùng cho | |---|---| | Data lake, dữ liệu thô | ⚠ CSDL giao dịch | | Sao lưu và lưu trữ dài hạn | ⚠ dữ liệu cần sửa từng phần liên tục | | Tài nguyên tĩnh cho web | ⚠ dữ liệu cần truy vấn theo trường | | Ảnh, video, tệp người dùng | ⚠ hàng đợi thông điệp | | Đích cho log và export | dữ liệu cần khoá và giao dịch |

Từ khoá nhận diện:

"tệp, ảnh, video, sao lưu, dữ liệu thô" → Cloud Storage "CSDL cho ứng dụng di động" → ⚠ Firestore "truy vấn SQL trên dữ liệu lớn" → BigQuery "giao dịch quan hệ" → Cloud SQL / Spanner

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai đang dùng bucket như CSDL không | ⚠ dấu hiệu: ghi đè cùng một tệp liên tục | | Bucket có công khai không | Security Command Center | | Dữ liệu ở lớp nào | Storage Insights |

Và một dấu hiệu rất dễ nhận biết rằng ai đó đang dùng sai công cụ: một tệp JSON trong bucket bị ghi đè hàng trăm lần mỗi phút. Đó là một cơ sở dữ liệu đang được giả lập bằng object storage — nó sẽ chạy được một thời gian, rồi hỏng đúng lúc có hai tiến trình cùng ghi.

Đáp án

C — Latency (độ trễ).

Vì sao đúng

Đề định nghĩa thẳng luôn khái niệm cần tìm: "thời gian trễ giữa hành động của người chơi và phản hồi của máy chủ" — đó chính là độ trễ.

⚠ Bốn khái niệm mạng, phân biệt cho rõ:

LATENCY (độ trễ)
    → ⚠ THỜI GIAN gói tin đi từ A tới B
    → đo bằng mili-giây
    → ⚠ đề này

BANDWIDTH (băng thông)
    → ⚠ DUNG LƯỢNG tối đa của đường truyền
    → đo bằng Mbps hoặc Gbps
    → như số làn của con đường

THROUGHPUT (thông lượng)
    → ⚠ lượng dữ liệu THỰC TẾ truyền được
    → luôn ≤ băng thông

JITTER
    → ⚠ mức DAO ĐỘNG của độ trễ
    → quan trọng cho thoại và video

⚠ Vì sao game nhiều người chơi nhạy với độ trễ:

Người chơi bấm nút
        ↓
    Gói tin đi tới máy chủ    (½ RTT)
    Máy chủ xử lý
    Gói tin đi về             (½ RTT)
        ↓
    Người chơi thấy kết quả
        ↓
    ⚠ Dưới 50ms  → mượt
    ⚠ 50–100ms   → chấp nhận được
    ⚠ Trên 150ms → thấy rõ độ trễ
    ⚠ Trên 200ms → không chơi được
      với game bắn súng

⚠ Vì sao băng thông không cứu được:

Gói tin game rất NHỎ
    (vài chục tới vài trăm byte)
        ↓
    ⚠ Băng thông 1 Gbps không làm
      gói tin tới NHANH HƠN
        ↓
    Độ trễ bị chi phối bởi
    ⚠ KHOẢNG CÁCH VẬT LÝ và
      số chặng mạng
        ↓
    → giải pháp là ĐẶT MÁY CHỦ
      GẦN NGƯỜI CHƠI

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

• D (jitter) — phương án gần nhất và thật sự quan trọng với game: độ trễ dao động thất thường gây giật. Nhưng đề định nghĩa rõ "thời gian trễ giữa hành động và phản hồi", đó là độ trễ, không phải mức dao động của nó.

• A (bandwidth) — dung lượng đường truyền, không phải thời gian đi lại.

• B (throughput) — lượng dữ liệu truyền được thực tế; quan trọng cho tải tệp lớn, không phải cho phản hồi tức thời.

Ghi nhớ

⚠ Bốn khái niệm mạng — bảng phải thuộc: | Khái niệm | Đo gì | Đơn vị | |---|---|---| | Latency | ⚠ THỜI GIAN đi từ A tới B | ms | | Bandwidth | dung lượng tối đa | Mbps, Gbps | | Throughput | lượng thực tế truyền được | Mbps | | Jitter | ⚠ mức dao động của độ trễ | ms | | Packet loss | tỉ lệ gói tin mất | % |

Từ khoá nhận diện:

"thời gian phản hồi, độ trễ, ping" → latency "tải tệp lớn nhanh" → bandwidth / throughput "video giật, tiếng ngắt quãng" → jitter "đặt máy chủ gần người dùng" → giảm latency

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ thật từ nơi người chơi ở | ⚠ đo từ chính vị trí đó, đừng đoán | | Vùng nào gần nhất | công cụ đo latency của Google Cloud | | Có bị jitter không | đo phân bố, không chỉ đo trung bình |

Và một điều rất đáng nhớ khi đọc số liệu độ trễ: giá trị trung bình che giấu vấn đề. Một dịch vụ có độ trễ trung bình 40ms nhưng p99 là 400ms sẽ khiến một phần trăm người chơi có trải nghiệm tệ hại — và trong game, đó là những người sẽ viết đánh giá một sao.

Đáp án

D — Compute Engine.

Vì sao đúng

Đề nêu ba đặc điểm, và cả ba đều loại trừ mọi lựa chọn có quản lý:

⚠ Ba đặc điểm ↔ Compute Engine:

1. "ỨNG DỤNG CŨ CHUYÊN BIỆT"
     → không viết lại được

2. ⚠ "ĐÒI MỘT PHIÊN BẢN CỤ THỂ
    CỦA HỆ ĐIỀU HÀNH THƯƠNG MẠI"
     → ⚠ PaaS và serverless
       KHÔNG cho chọn OS

3. ⚠ "PHẢI CÀI ĐẶT THỦ CÔNG"
   + "TOÀN QUYỀN kiểm soát môi trường"
     → cần quyền root và SSH
        ↓
    → chỉ IaaS đáp ứng được

⚠ Vì sao ba phương án kia bất khả thi:

APP ENGINE
    → ⚠ chỉ RUNTIME được hỗ trợ
    → không chọn OS, không SSH
      (bản Standard)

CLOUD RUN
    → cần đóng gói thành CONTAINER
    → ⚠ ứng dụng cũ đòi cài thủ công
      và OS thương mại cụ thể
      thì thường KHÔNG container hoá
      dễ dàng
    → không có quyền kernel

CLOUD RUN FUNCTIONS
    → ⚠ dành cho HÀM nhỏ
    → hoàn toàn sai loại

⚠ Compute Engine cho những gì cần thiết:

⚠ Chọn image OS bất kỳ
   → Windows Server, RHEL, SUSE,
     hoặc image tự dựng
⚠ Quyền root, SSH hoặc RDP
⚠ Cài phần mềm thương mại
⚠ Mang giấy phép sẵn có
   (BYOL — sole-tenant node nếu
    giấy phép ràng buộc phần cứng)
⚠ Cấu hình kernel, driver

Nhất quán với #13334 (cùng lô này) — câu đó nhắc rằng với Compute Engine bạn phải tự vá hệ điều hành. Đó chính là cái giá của quyền kiểm soát mà đề này đang cần.

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

• C (Cloud Run) — phương án gần nhất trong các lựa chọn hiện đại, và nếu ứng dụng container hoá được thì đây là lựa chọn tốt. Nhưng đề nói rõ nó đòi một phiên bản OS thương mại cụ thể và phải cài thủ công — hai điều kiện gần như loại trừ container hoá.

• A (App Engine) — không cho chọn hệ điều hành, chỉ chạy runtime được hỗ trợ.

• B (Cloud Run Functions) — dành cho hàm nhỏ theo sự kiện, sai hoàn toàn loại.

Ghi nhớ

⚠ Chọn nền tảng theo mức kiểm soát — bảng phải thuộc: | Nhu cầu | Chọn | |---|---| | ⚠ Kiểm soát OS, phần mềm cũ, giấy phép riêng | ⚠ Compute Engine (IaaS) | | Container không trạng thái | Cloud Run | | Nhiều container phụ thuộc nhau | GKE | | Mã nguồn, runtime hỗ trợ | App Engine | | Hàm theo sự kiện | Cloud Run Functions |

Từ khoá nhận diện:

"ứng dụng cũ, OS cụ thể, cài thủ công, toàn quyền" → Compute Engine "lift and shift" → Compute Engine "container hoá được" → Cloud Run hoặc GKE "không muốn quản gì" → serverless

Ba việc kiểm chứng: | Việc | Cách | |---|---| | OS đó có image sẵn không | danh sách image công khai của Google | | Giấy phép có mang sang được không | ⚠ đọc kỹ điều khoản của nhà cung cấp | | Kích cỡ máy có hợp không | Recommender sau vài tuần |

Và một lời khuyên hợp lý cho tình huống của đề: đưa ứng dụng cũ lên Compute Engine trước, rồi hiện đại hoá sau. Ràng buộc về hệ điều hành thương mại là có thật và không thể phá bỏ bằng ý chí — nhưng một khi đã ở trên đám mây, bạn có thời gian và số liệu để tính chuyện thay thế nó.

Đáp án

D — Autoscaling và load balancing (tự mở rộng và cân bằng tải).

Vì sao đúng

Hai năng lực này luôn đi cùng nhau trong một kiến trúc chịu tải trên Compute Engine, và thứ tự trong phương án D là thứ tự chúng phát huy tác dụng.

⚠ Autoscaling — thêm và bớt máy:

Đợt flash sale bắt đầu
        ↓
    CPU trung bình vượt ngưỡng
        ↓
    ⚠ Managed Instance Group
      TẠO THÊM VM
        ↓
    Đợt sale kết thúc
        ↓
    ⚠ MIG XOÁ BỚT VM
        ↓
    → chỉ trả tiền cho năng lực
      thật sự cần

⚠ Load balancing — chia lưu lượng:

                Người dùng
                    ↓
        Global Load Balancer
        ┌───────┬───────┬───────┐
       VM1     VM2     VM3     VM4 (mới)
        ↓
    ⚠ Tự đưa VM MỚI vào pool
    ⚠ Tự loại VM không khoẻ
    ⚠ Không có nó thì thêm VM
      cũng vô nghĩa — không ai
      gửi lưu lượng vào chúng

⚠ Hai thứ này phụ thuộc nhau:

Chỉ có AUTOSCALING
    → có thêm VM nhưng lưu lượng
      vẫn dồn vào VM cũ
    → ⚠ vô dụng

Chỉ có LOAD BALANCING
    → chia đều lưu lượng nhưng
      tổng năng lực không tăng
    → ⚠ vẫn quá tải
        ↓
    ⚠ PHẢI CÓ CẢ HAI

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

Đề mô tả hai hành động: "tự động thêm VM để chịu tải" và "bớt chúng đi khi sale kết thúc". Về mặt kỹ thuật, cả hai đều là autoscaling (scale out và scale in) — load balancing không được mô tả tường minh trong đề.

Chữ "respectively" (tương ứng) vì thế hơi lỏng lẻo. Nhưng trong bốn phương án, D là lựa chọn đúng duy nhất: nó nêu đúng cặp năng lực làm nên kiến trúc chịu tải, và đặt autoscaling trước — khớp với phần được mô tả rõ nhất trong đề.

Phương án B có cùng hai khái niệm nhưng đảo thứ tự, nên sai theo cách đọc "tương ứng". Khoá đáp án giữ nguyên là D.

Mẹo làm bài: khi đề dùng chữ "respectively" mà mô tả không rõ ràng, hãy bám vào thứ tự các mệnh đề trong đề — ở đây "thêm VM" được nói trước, và autoscaling đứng trước trong phương án D.

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

• B (load balancing và autoscaling) — đúng hai khái niệm nhưng đảo thứ tự, không khớp với trình tự mô tả trong đề.

• A (disaster recovery và high availability) — nói về chịu lỗi và phục hồi sau thảm hoạ, không phải về chịu tải cao.

• C (serverless và containers) — hai khái niệm về mô hình tính toán và đóng gói, không phải cơ chế xử lý đợt tăng tải trên Compute Engine.

Ghi nhớ

⚠ Bốn khái niệm hay bị lẫn — bảng phải thuộc: | Khái niệm | Giải quyết | |---|---| | Autoscaling | ⚠ TẢI thay đổi — thêm/bớt năng lực | | Load balancing | ⚠ PHÂN PHỐI lưu lượng, tránh máy hỏng | | High availability | chịu được HỎNG một thành phần | | Disaster recovery | phục hồi sau thảm hoạ diện rộng |

Từ khoá nhận diện:

"thêm/bớt máy theo tải" → autoscaling "chia lưu lượng, tránh máy hỏng" → load balancing "chịu được mất một zone" → HA — regional MIG "mất cả vùng" → DR — đa vùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mở rộng có kịp không | ⚠ thử tải mô phỏng đỉnh | | Quota có đủ không | xin nâng trước sự kiện | | CSDL có chịu nổi không | thử riêng phần đó |

Và một điều rất hay bị bỏ qua khi chuẩn bị cho một đợt bán hàng lớn: tầng ứng dụng mở rộng được không có nghĩa là cả hệ thống mở rộng được. Trăm máy ảo mới sẽ cùng gõ cửa một cơ sở dữ liệu duy nhất — và nếu không chuẩn bị cho phần đó, autoscaling chỉ giúp bạn làm sập nó nhanh hơn.

Đáp án

B — Data sovereignty (chủ quyền dữ liệu).

Vì sao đúng

Đề mô tả đúng định nghĩa: dữ liệu chịu sự điều chỉnh của luật pháp một quốc gia, bất kể nó được lưu ở đâu trên thế giới.

⚠ Ba khái niệm rất dễ lẫn:

DATA RESIDENCY (nơi cư trú)
    → ⚠ dữ liệu LƯU Ở ĐÂU
      về mặt địa lý
    → "phải nằm trong lãnh thổ EU"
    → giải bằng: CHỌN VÙNG

DATA SOVEREIGNTY (chủ quyền)
    → ⚠ dữ liệu chịu LUẬT của
      nước nào
    → ⚠ ĐỘC LẬP với nơi lưu trữ
    → chính là đề này

DATA LOCALITY
    → ⚠ thường dùng theo nghĩa
      KỸ THUẬT: đặt dữ liệu gần
      nơi xử lý để giảm độ trễ

⚠ Đọc kỹ tình huống trong đề:

Dữ liệu KHÁCH HÀNG ÚC
        ↓
    Lưu ở vùng SINGAPORE
        ↓
    Luật mới của Úc:
    ⚠ "mọi dữ liệu LIÊN QUAN TỚI
      CÔNG DÂN ÚC chịu luật riêng tư
      của Úc, ⚠ BẤT KỂ lưu ở đâu"
        ↓
    ⚠ Cụm "bất kể lưu ở đâu" loại
      thẳng data residency
        ↓
    → đây là CHỦ QUYỀN DỮ LIỆU

⚠ Vì sao doanh nghiệp phải quan tâm:

Một tập dữ liệu có thể chịu
NHIỀU hệ thống pháp luật cùng lúc
        ↓
    ⚠ Luật nơi lưu trữ (Singapore)
    ⚠ Luật quốc tịch chủ thể dữ liệu (Úc)
    ⚠ Luật nơi doanh nghiệp đăng ký
        ↓
    → nhiều tổ chức chọn cách
      đơn giản nhất: ⚠ GIỮ DỮ LIỆU
      TRONG CHÍNH NƯỚC ĐÓ

⚠ Đối chiếu #13285 (lô 139) — đề đó khoá "chọn một vùng châu Âu" vì yêu cầu là data residency (dữ liệu phải nằm trong lãnh thổ EU). Câu này hỏi tên của nguyên tắc pháp lý khi luật áp dụng bất kể nơi lưu trữ — đó là data sovereignty. Hai câu KHÔNG mâu thuẫn — chúng là hai khái niệm khác nhau, và cách xử lý thực tế thường giống nhau: chọn vùng trong lãnh thổ.

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

• D (data residency) — phương án gần nhất và bị nhầm nhiều nhất: residency nói về VỊ TRÍ VẬT LÝ của dữ liệu. Đề nhấn mạnh "bất kể lưu ở đâu", tức là đang nói về thẩm quyền pháp lý, không phải vị trí.

• A (data locality) — thường mang nghĩa kỹ thuật: đặt dữ liệu gần nơi xử lý để giảm độ trễ.

• C (mã hoá dữ liệu) — biện pháp kỹ thuật bảo vệ nội dung, không phải nguyên tắc pháp lý.

Ghi nhớ

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

Từ khoá nhận diện:

"chịu luật của nước X, bất kể lưu ở đâu" → data sovereignty "phải lưu trong lãnh thổ nước X" → data residency → chọn vùng "kiểm soát cả việc nhân viên nhà cung cấp truy cập" → ⚠ operational sovereignty "gói kiểm soát tuân thủ theo khu vực" → Assured Workloads

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu công dân nước đó đang ở đâu | ⚠ quét toàn bộ, gồm cả log và backup | | Có chính sách chặn không | Organization Policy | | Ai ngoài tổ chức truy cập được | Access Transparency |

Và một nơi rất hay bị bỏ sót khi rà soát tuân thủ về dữ liệu: nhật ký hệ thống. Ứng dụng có thể chạy đúng vùng, cơ sở dữ liệu cũng đúng vùng, nhưng log sink lại đẩy toàn bộ về một dự án tập trung ở nước khác — và log ứng dụng thì thường chứa đúng loại dữ liệu cá nhân mà luật đang bảo vệ.

Đáp án

D — App Engine.

Vì sao đúng

Đề nêu ba yêu cầu, và cụm từ quyết định là "chỉ cần tải MÃ NGUỒN lên":

⚠ Ba yêu cầu ↔ App Engine:

1. "KHÔNG quản máy chủ chút nào"
     → serverless

2. ⚠ "PaaS — chỉ TẢI MÃ NGUỒN LÊN
    rồi Google lo phần còn lại"
     → ⚠ đây là cụm quyết định:
       KHÔNG tự dựng container

3. "TỰ MỞ RỘNG"
     → App Engine Standard co từ 0
       tới N tự động

⚠ Triển khai chỉ có vậy:

# app.yaml
runtime: python312

gcloud app deploy

        ↓
    ⚠ Google tự dựng, tự chạy,
      tự cấp HTTPS, tự mở rộng
    ⚠ Không viết Dockerfile
    ⚠ Không quản hệ điều hành

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

GKE
    → ⚠ cần container, cần quản cụm
    → xa nhất với "không quản gì"

COMPUTE ENGINE
    → ⚠ IaaS, tự cài OS
    → ngược hoàn toàn

CLOUD RUN FUNCTIONS
    → ⚠ dành cho HÀM theo sự kiện
    → đề nói "ứng dụng web",
      không phải một hàm

⚠ Còn Cloud Run thì sao — nó không có trong danh sách:

Cloud Run cũng nhận mã nguồn
(`gcloud run deploy --source .`)
        ↓
    ⚠ Nhưng nó KHÔNG có trong
      bốn phương án
        ↓
    → App Engine là lựa chọn
      đúng duy nhất ở đây

Nhất quán với #13314 (lô 139) — đề đó ghép "đã có container → Cloud Run" và "triển khai từ mã nguồn → App Engine Standard". Câu này chỉ có vế thứ hai, và cùng khoá App Engine.

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

• C (Cloud Run Functions) — phương án gần nhất về mặt serverless, nhưng nó dành cho một hàm đơn nhiệm phản ứng theo sự kiện, không phải cả một ứng dụng web.

• A (GKE) — cần container và cần vận hành cụm Kubernetes; xa nhất với yêu cầu "không quản gì".

• B (Compute Engine) — IaaS, phải tự cài và vá hệ điều hành.

Ghi nhớ

⚠ Bốn nền tảng tính toán — bảng phải thuộc: | Nền tảng | Đầu vào | Mức quản lý | |---|---|---| | App Engine | ⚠ MÃ NGUỒN + app.yaml | PaaS, không quản gì | | Cloud Run | ⚠ CONTAINER (hoặc mã nguồn) | serverless | | GKE | container | quản cụm | | Compute Engine | ⚠ máy ảo trống | quản toàn bộ OS |

Từ khoá nhận diện:

"chỉ tải mã nguồn lên, PaaS" → App Engine "đã có container image" → Cloud Run "hàm theo sự kiện" → Cloud Run Functions "nhiều container phụ thuộc nhau" → GKE "cần kiểm soát hệ điều hành" → Compute Engine

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Runtime có được hỗ trợ không | kiểm danh sách trong tài liệu | | Chi phí lúc rảnh | ⚠ Standard co về 0, Flexible thì không | | Có phụ thuộc hệ thống lạ không | nếu có → Cloud Run |

Và một điều nên biết trước khi tạo ứng dụng App Engine đầu tiên: vùng của nó chọn một lần và không đổi được. Muốn chuyển sang vùng khác thì phải tạo project mới và triển khai lại từ đầu — nên hãy cân nhắc vị trí người dùng trước khi gõ lệnh gcloud app create.

Đáp án

B — People connections (kết nối con người).

Vì sao đúng

Đề mô tả hai nhu cầu: cộng tác thời gian thực trên tài liệu và họp video chất lượng cao — cả hai đều thuộc trụ cột về con người và cách họ làm việc cùng nhau.

⚠ Hai nhu cầu ↔ trụ cột này:

1. "CỘNG TÁC THỜI GIAN THỰC
    trên tài liệu chiến lược"
     → Google Docs, Sheets, Slides
     → ⚠ nhiều người sửa cùng lúc

2. "HỌP VIDEO CHẤT LƯỢNG CAO,
    giảm chi phí đi lại"
     → Google Meet
        ↓
    ⚠ Cả hai thuộc Google Workspace
    → trụ cột PEOPLE CONNECTIONS

⚠ Vấn đề của một tập đoàn đa quốc gia:

Đội ở Bắc Mỹ, châu Âu, châu Á
        ↓
    ⚠ Lệch múi giờ rất lớn
    ⚠ Gửi file qua email nhiều phiên bản
      → "báo cáo_v3_final_FINAL2.docx"
    ⚠ Đi công tác tốn kém và mất thời gian
        ↓
Cộng tác thời gian thực
        ↓
    ⚠ MỘT tài liệu duy nhất,
      ai cũng thấy bản mới nhất
    ⚠ Bình luận và góp ý ngay trong file
    ⚠ Làm việc bất đồng bộ qua múi giờ

⚠ Ba trụ cột kia nói về chuyện khác:

DATA DEMOCRATIZATION
    → ⚠ dữ liệu và phân tích
    → BigQuery, Looker

APP AND INFRASTRUCTURE MODERNIZATION
    → ⚠ hiện đại hoá ứng dụng
    → container, Kubernetes, serverless

TRUSTED TRANSACTIONS
    → ⚠ bảo mật, quyền riêng tư,
      tuân thủ

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

• C (app and infrastructure modernization) — phương án gần nhất về mặt "cũng là chuyển đổi số", nhưng nó nói về hiện đại hoá hệ thống công nghệ, không phải về cách con người làm việc với nhau.

• A (data democratization) — về dữ liệu và phân tích tự phục vụ.

• D (trusted transactions) — về bảo mật, riêng tư và niềm tin.

Ghi nhớ

⚠ Các trụ cột của Google Transformation Cloud — bảng nên thuộc: | Trụ cột | Nội dung | Sản phẩm | |---|---|---| | ⚠ People connections | cộng tác, họp, làm việc nhóm | Google Workspace, Meet | | Data democratization | dữ liệu và AI cho mọi người | BigQuery, Looker, Vertex AI | | App & infra modernization | hiện đại hoá hệ thống | GKE, Cloud Run, Anthos | | Trusted transactions | bảo mật, riêng tư, tuân thủ | IAM, Cloud Armor, KMS | | Sustainable technology | bền vững | Carbon Footprint |

Từ khoá nhận diện:

"cộng tác, họp video, làm việc nhóm" → People connections "phân tích, dữ liệu, AI" → Data democratization "container, microservices, di cư" → App & infra modernization "bảo mật, tuân thủ, niềm tin" → Trusted transactions "carbon, năng lượng tái tạo" → Sustainability

Ba việc kiểm chứng: | Việc | Câu hỏi | |---|---| | Còn ai gửi file đính kèm qua email không | ⚠ dấu hiệu chưa chuyển đổi thật | | Chính sách chia sẻ ra ngoài đã đặt chưa | | | Băng thông có đủ cho họp video không | với văn phòng ở nơi mạng yếu |

Và một điều đáng nhớ về trụ cột này trong khung chuyển đổi số: nó thường bị coi nhẹ vì nghe không "kỹ thuật". Nhưng với một tập đoàn trải ba châu lục, khả năng để hai người ở hai múi giờ cùng làm việc trên một tài liệu mà không ai phải chờ ai thường tạo ra thay đổi rõ rệt hơn nhiều so với một dự án hạ tầng.

Đáp án

A — Looker.

Vì sao đúng

Đề nêu bốn yêu cầu, tất cả đều là mô tả của một nền tảng BI tự phục vụ:

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

1. "KHÁM PHÁ và TRỰC QUAN HOÁ
    dữ liệu bán hàng từ BigQuery"
     → Looker kết nối thẳng BigQuery

2. "BẢNG ĐIỀU KHIỂN TƯƠNG TÁC,
    DỄ HIỂU"
     → Look và dashboard

3. "ra quyết định CHIẾN LƯỢC"
     → người dùng là ban lãnh đạo

4. ⚠ "KHÔNG VIẾT MỘT DÒNG SQL NÀO"
     → ⚠ LookML dịch thao tác kéo thả
       thành SQL tự động

⚠ Vì sao ban lãnh đạo cần LookML:

Đội dữ liệu định nghĩa MỘT LẦN:
    "doanh thu thuần" = ?
    "khách hàng hoạt động" = ?
    bảng nào nối với bảng nào
        ↓
Ban lãnh đạo kéo thả trong Explore
        ↓
    Looker sinh SQL, chạy trên BigQuery
        ↓
    ⚠ Mọi người ra CÙNG một con số
    ⚠ Không ai phải học SQL

⚠ Vì sao "một nguồn sự thật" quan trọng ở cấp lãnh đạo:

Không có mô hình chung
        ↓
    Giám đốc kinh doanh: doanh thu 100 tỉ
    Giám đốc tài chính:  doanh thu 95 tỉ
        ↓
    ⚠ Cuộc họp chiến lược biến thành
      cuộc tranh cãi về số liệu
        ↓
Có LookML
        ↓
    → một định nghĩa duy nhất,
      sửa một chỗ là mọi báo cáo đổi

⚠ Gần trùng với #13261 (lô 138) — đề đó là đội marketing và bán hàng muốn tự dựng dashboard từ BigQuery mà không cần biết SQL, và cùng khoá Looker. Hoàn toàn nhất quán. Mẫu đề lặp: BI tự phục vụ + không cần SQL + dữ liệu ở BigQuery → luôn là Looker.

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

• D (Vertex AI) — phương án gần nhất về mặt "cũng khai thác dữ liệu", nhưng đó là nền tảng học máy, không phải công cụ dựng dashboard.

• B (Pub/Sub) — dịch vụ nhận và truyền thông điệp, nằm ở đầu vào của đường ống dữ liệu.

• C (Dataflow) — engine xử lý và biến đổi dữ liệu, đứng ở giữa đường ống.

Ghi nhớ

⚠ Vai của từng sản phẩm trong đường ống dữ liệu: | Giai đoạn | Sản phẩm | |---|---| | Nhận | Pub/Sub, Datastream | | Xử lý | Dataflow, Dataform | | Lưu và phân tích | BigQuery | | ⚠ Trực quan hoá | ⚠ Looker, Looker Studio | | Học máy | Vertex AI, BigQuery ML |

Từ khoá nhận diện:

"dashboard, không cần SQL, tự phục vụ" → Looker "báo cáo nhanh, miễn phí" → Looker Studio "phân tích BigQuery trong bảng tính" → Connected Sheets "dự đoán, mô hình" → Vertex AI / BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lãnh đạo có tự dùng được không | ⚠ quan sát một người trong 15 phút đầu | | Chi phí truy vấn bao nhiêu | BigQuery job history lọc theo Looker | | Có nội dung nào hỏng không | Content Validator |

Và một điều quyết định thành bại của mọi dự án BI mà công cụ không giải quyết được: chất lượng của mô hình dữ liệu phía sau. Một dashboard đẹp dựng trên các định nghĩa chỉ số mập mờ chỉ giúp lãnh đạo ra quyết định sai nhanh hơn mà thôi.