Ngân hàng đề — Google Cloud Associate Cloud Engineer

Đáp án

B — BigQuery.

Vì sao đúng

Đề cho rất nhiều manh mối, và mọi manh mối đều chỉ về BigQuery.

⚠ Đọc từng manh mối:

"business intelligence, dùng SQL nhiều"
        ↓
    → cần SQL chuẩn, kết nối được công cụ BI

"nạp dữ liệu MỖI ĐÊM"
        ↓
    → tải theo LÔ, không phải giao dịch thời gian thực

"truy vấn VÀI CỘT nhưng quét NHIỀU DÒNG"
        ↓
    → đây là dấu hiệu KINH ĐIỂN của tải phân tích
    → BigQuery lưu theo CỘT
      → chỉ đọc cột được nêu tên

"dữ liệu quá 3 năm thì không cần nữa"
        ↓
    → partition theo ngày + luật hết hạn phân vùng

"giảm công quản lý CSDL"
        ↓
    → serverless

⚠ Vì sao lưu theo cột lại quan trọng đến thế:

CSDL quan hệ lưu theo DÒNG
        ↓
    Đọc vài cột vẫn phải đọc cả dòng
    → quét nhiều dữ liệu vô ích

BigQuery lưu theo CỘT
        ↓
    Chỉ đọc đúng cột được nêu trong SELECT
        ↓
    → đọc 3 cột trong bảng 50 cột
      → quét khoảng 6% dữ liệu
    → và đây cũng là cơ sở tính tiền

⚠ Và "dữ liệu quá 3 năm không cần nữa" có giải pháp sẵn:

Bảng phân vùng theo ngày
        ↓
    Đặt partition expiration = 1095 ngày
        ↓
    → BigQuery TỰ XOÁ phân vùng quá hạn
    → không cần script dọn dẹp
        ↓
    Hoặc để dữ liệu cũ tự chuyển sang
    long-term storage (rẻ hơn ~50%)
      → tự động khi không sửa trong 90 ngày

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

• D (Cloud SQL) — đây là phương án gần nhất vì đội đang dùng CSDL quan hệ, nhưng Cloud SQL là CSDL GIAO DỊCH lưu theo DÒNG: truy vấn quét hàng triệu dòng để tổng hợp sẽ rất chậm, và nó cũng cần nhiều công quản lý hơn (chọn cỡ máy, đĩa, chỉ mục).

• A (Bigtable) — NoSQL, không có SQL đầy đủ, không kết nối được công cụ BI truyền thống.

• C (Cloud Firestore) — NoSQL tài liệu cho ứng dụng web và di động, không phải kho phân tích.

Ghi nhớ

⚠ Nhận diện tải PHÂN TÍCH ↔ tải GIAO DỊCH — bảng phải thuộc: | Dấu hiệu | Loại tải | Dịch vụ | |---|---|---| | "quét nhiều dòng, vài cột" | PHÂN TÍCH (OLAP) | BigQuery | | "tổng hợp, báo cáo, BI" | PHÂN TÍCH | BigQuery | | "nạp theo lô hằng đêm" | phân tích | BigQuery | | "nhiều đọc ghi bản ghi nhỏ" | GIAO DỊCH (OLTP) | Cloud SQL / Spanner | | "cần khoá ngoại, giao dịch" | giao dịch | Cloud SQL | | "ghi rất nhiều, độ trễ mili giây" | NoSQL | Bigtable |

Từ khoá nhận diện:

"quét nhiều dòng, ít cột" → BigQuery (lưu theo cột) "SQL, BI, giảm công quản lý" → BigQuery "giao dịch, ràng buộc toàn vẹn" → Cloud SQL "dữ liệu cũ hết hạn" → partition expiration "chuỗi thời gian, ghi lớn" → Bigtable

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu | bq query --dry-run | | Bảng có partition không | bq show <dataset>.<bang> | | Ai tốn nhiều nhất | INFORMATION_SCHEMA.JOBS |

Và một cấu hình rất đáng bật cho bảng lớn có phân vùng: require_partition_filter. Nó khiến mọi truy vấn quên mệnh đề lọc theo ngày thất bại ngay lập tức thay vì âm thầm quét toàn bộ bảng — biến một sai sót tốn kém thành một thông báo lỗi rõ ràng mà người viết truy vấn nhận được trong vài giây.

Đáp án

B — Bigtable.

Vì sao đúng

Ba manh mối: dữ liệu CHUỖI THỜI GIAN, nạp khối lượng lớn trong thời gian ngắn, và cách truy vấn ĐÃ BIẾT VÀ CỐ ĐỊNH.

⚠ Điểm mấu chốt — manh mối thứ ba là quyết định:

"Người dùng truy vấn theo vài cách,
 nhưng những cách đó ĐÃ BIẾT và CỐ ĐỊNH"
        ↓
    Bigtable CHỈ có MỘT chỉ mục: ROW KEY
        ↓
    → truy vấn phải đi qua row key
    → không có chỉ mục phụ, không có SQL tuỳ ý
        ↓
    Biết trước cách truy vấn
        ↓
    → THIẾT KẾ ĐƯỢC row key cho đúng
    → đây chính là điều kiện để dùng Bigtable
        ↓
    Nếu truy vấn TUỲ Ý, không đoán trước
      → BigQuery mới phù hợp

⚠ Và hai manh mối còn lại củng cố lựa chọn:

Chuỗi thời gian + ghi khối lượng lớn
        ↓
    Bigtable:
      - thông lượng ghi rất cao
      - độ trễ mili giây một chữ số
      - mở rộng bằng cách thêm node
      - thiết kế riêng cho chuỗi thời gian

⚠ Nhưng ROW KEY quyết định tất cả:

Row key bắt đầu bằng DẤU THỜI GIAN
        ↓
    → mọi lượt ghi dồn vào MỘT node
    → HOTSPOT, thông lượng sụp đổ
        ↓
Mẫu đúng cho IoT:
    <ma-cam-bien>#<dau-thoi-gian>
    hoặc thêm tiền tố băm để trải đều
        ↓
    Và row key phải hỗ trợ ĐÚNG các
    truy vấn đã biết trước

Xem thêm câu #12489 và #12506 (lô 131 và 132): cùng chủ đề Bigtable cho IoT và chuỗi thời gian. Khoá nhất quán.

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

• A (BigQuery) — đây là phương án gần nhất vì cũng xử lý được dữ liệu rất lớn, nhưng BigQuery tối ưu cho truy vấn PHÂN TÍCH quét lớn, không cho ghi từng bản ghi ở độ trễ mili giây. (Mô hình phổ biến: Bigtable ghi và đọc nóng, BigQuery phân tích lịch sử.)

• D (Cloud Spanner) — CSDL quan hệ có giao dịch, chi phí cao hơn nhiều, không tối ưu cho khối lượng ghi chuỗi thời gian.

• C (Cloud SQL) — mở rộng theo chiều dọc, không chịu nổi khối lượng ghi mà đề mô tả.

Ghi nhớ

⚠ Chọn CSDL theo mẫu truy vấn — bảng phải thuộc: | Mẫu truy vấn | Dịch vụ | |---|---| | Đã biết, cố định, qua một khoá | Bigtable | | Tuỳ ý, tổng hợp, SQL | BigQuery | | Giao dịch quan hệ | Cloud SQL / Spanner | | Theo tài liệu, ứng dụng di động | Firestore | | Bẫy | Bigtable KHÔNG cho truy vấn tuỳ ý |

Từ khoá nhận diện:

"chuỗi thời gian, ghi lớn, truy vấn đã biết" → Bigtable "truy vấn tuỳ ý, phân tích" → BigQuery "HBase" → Bigtable "giao dịch, khoá ngoại" → Cloud SQL "cần cả hai" → Bigtable cho nóng, BigQuery cho lịch sử

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hotspot không | Key Visualizer trong console | | Node đủ chưa | chỉ số CPU utilization — nên dưới 70% | | Độ trễ thực tế | chỉ số read/write latency |

Và một câu hỏi nên đặt ra trước khi chọn Bigtable: các truy vấn có thật sự cố định không. Bigtable rất mạnh khi bạn biết trước cách dữ liệu sẽ được đọc, nhưng nếu sáu tháng sau đội phân tích muốn hỏi một câu hoàn toàn khác, bạn sẽ phải thiết kế lại row key và nạp lại toàn bộ dữ liệu — trong khi BigQuery cho phép hỏi bất cứ điều gì bằng SQL mà không cần đụng tới dữ liệu đã lưu.

Đáp án

A — bq ls

Vì sao đúng

BigQuery có công cụ dòng lệnh riêng là bq, và động từ liệt kê là ls.

⚠ Điểm mấu chốt — mỗi dịch vụ có công cụ riêng:

bq       → BigQuery
gsutil   → Cloud Storage (cũ)
gcloud storage → Cloud Storage (mới)
gcloud   → hầu hết dịch vụ còn lại
kubectl  → bên trong cụm Kubernetes
        ↓
    → dùng gsutil cho BigQuery là luôn SAI

⚠ Các dạng của bq ls:

bq ls
        ↓
    Liệt kê DATASET trong project hiện tại

bq ls <dataset>
        ↓
    Liệt kê BẢNG và VIEW trong dataset đó

bq ls --project_id=<project>
        ↓
    Dataset của một project khác

bq ls -j
        ↓
    Liệt kê JOB gần đây

bq ls --transfer_config
        ↓
    Cấu hình Data Transfer Service

⚠ Và cấu trúc định danh của BigQuery:

project:dataset.table
        ↓
    Dấu HAI CHẤM giữa project và dataset
    Dấu CHẤM giữa dataset và table
        ↓
    Ví dụ: my-project:analytics.events
        ↓
    Trong SQL thì dùng dấu huyền:
      `my-project.analytics.events`
      → ở đây là dấu CHẤM cả hai chỗ

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

• C (gsutil ls) — đây là phương án gần nhất và là lệnh có thật, nhưng gsutil chỉ làm việc với Cloud Storage, không quản lý BigQuery.

• B (bq dir) — không có động từ dir trong bq. Đây là thói quen từ Windows.

• D (gsutil dir) — sai cả công cụ lẫn động từ.

Ghi nhớ

⚠ Các công cụ dòng lệnh của Google Cloud — bảng phải thuộc: | Công cụ | Dịch vụ | |---|---| | gcloud | hầu hết dịch vụ — Compute, IAM, GKE, Cloud Run… | | bq | BigQuery | | gsutil | Cloud Storage (công cụ CŨ) | | gcloud storage | Cloud Storage (công cụ MỚI, nhanh hơn) | | kubectl | bên trong cụm Kubernetes | | bt (cbt) | Bigtable | | Đều nằm trong | Google Cloud SDK |

Từ khoá nhận diện:

"liệt kê dataset" → bq ls "chi tiết một dataset hoặc bảng" → bq show "chạy truy vấn" → bq query "nạp dữ liệu" → bq load "gsutil cho BigQuery" → luôn SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những dataset nào | bq ls | | Dataset nằm ở vị trí nào | bq show --format=prettyjson <dataset> | | Bảng lớn bao nhiêu | bq show <dataset>.<bang> → numBytes |

Và một cờ nên đưa vào thói quen với mọi lệnh bq query: --use_legacy_sql=false. Legacy SQL là phương ngữ cũ với cú pháp khác biệt đáng kể, và nhiều tính năng hiện đại của BigQuery không hoạt động với nó — khai rõ SQL chuẩn ngay từ đầu tránh được cả một lớp lỗi cú pháp khó hiểu.

Đáp án

B — bq show --format=prettyjson analytics1:primarydata

Vì sao đúng

Cần thông tin chi tiết của MỘT dataset, và trong bq thì động từ cho việc đó là show.

⚠ Điểm mấu chốt — ls ↔ show:

bq ls
        ↓
    LIỆT KÊ nhiều thứ
    → chỉ vài trường tóm tắt

bq show <định danh>
        ↓
    CHI TIẾT của MỘT thứ
    → lược đồ, kích thước, thời điểm tạo,
      vị trí, nhãn, quyền truy cập
        ↓
    → tương đương `describe` của gcloud

⚠ Và cú pháp định danh của BigQuery:

project:dataset
        ↓
    Dấu HAI CHẤM giữa project và dataset
        ↓
    analytics1:primarydata   ✓
    analytics1//primarydata  ✗
        ↓
    Với bảng:
      project:dataset.table
      → hai chấm rồi chấm

⚠ --format=prettyjson cho đầu ra dễ đọc:

--format=prettyjson
        ↓
    JSON có thụt lề, dễ đọc bằng mắt
        ↓
Các định dạng khác của bq:
    --format=pretty   → bảng đẹp (mặc định)
    --format=json     → JSON một dòng
    --format=csv      → CSV
    --format=sparse   → tối giản
        ↓
    → prettyjson hữu ích khi cần xem
      lược đồ đầy đủ hoặc đưa vào script

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

• A (bq ls --format=prettyjson analytics1:primarydata) — đây là phương án gần nhất và cú pháp định danh đúng, nhưng ls sẽ liệt kê các BẢNG bên trong dataset chứ không cho thông tin về chính dataset.

• D (bq ls --format=prettyjson analytics1//primarydata) — sai cả hai: động từ ls, và dấu phân cách // không hợp lệ.

• C (bq metadata ...) — không có động từ metadata trong bq.

Ghi nhớ

⚠ Các lệnh bq hay dùng — bảng phải thuộc: | Lệnh | Việc | |---|---| | bq ls | liệt kê dataset | | bq ls <dataset> | liệt kê bảng trong dataset | | bq show <dataset> | chi tiết một DATASET | | bq show <dataset>.<bang> | chi tiết một BẢNG — lược đồ, kích thước, partition | | bq show -j <job_id> | chi tiết một JOB — đọc lỗi ở đây | | bq query | chạy truy vấn | | bq load | nạp dữ liệu | | bq mk / bq rm | tạo / xoá |

Từ khoá nhận diện:

"chi tiết một dataset hoặc bảng" → bq show "liệt kê" → bq ls "vì sao job thất bại" → bq show -j <job_id> "ước tính chi phí" → bq query --dry-run "project//dataset" → sai — phải là project:dataset

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dataset có những gì | bq show --format=prettyjson <dataset> | | Bảng lớn bao nhiêu | bq show <dataset>.<bang> → numBytes | | Vị trí dataset | cùng lệnh, trường location |

Và một trường rất đáng để mắt tới khi chạy bq show trên một dataset: location. Nó không đổi được sau khi tạo, và truy vấn chỉ chạy được giữa các dataset cùng vị trí — nên phát hiện sớm việc hai dataset nằm ở hai vùng khác nhau sẽ tiết kiệm rất nhiều thời gian so với việc gặp một lỗi khó hiểu giữa lúc viết truy vấn kết hợp.

Đáp án

A — Dùng bảng PHÂN VÙNG THEO THỜI ĐIỂM NẠP (ingestion time partitioned table) và khai bộ lọc _PARTITIONTIME khi truy vấn.

Vì sao đúng

Đề cho một manh mối then chốt: phần lớn truy vấn dựa trên thời điểm dữ liệu đến. Đó chính là điều kiện lý tưởng cho phân vùng theo thời điểm nạp.

⚠ Điểm mấu chốt — phân vùng giới hạn lượng dữ liệu quét:

Bảng KHÔNG phân vùng
        ↓
    Mọi truy vấn quét TOÀN BỘ bảng
    → trả tiền cho toàn bộ, dù chỉ cần một ngày

Bảng PHÂN VÙNG theo thời điểm nạp
        ↓
    Dữ liệu chia thành từng phân vùng theo NGÀY
        ↓
    WHERE _PARTITIONTIME BETWEEN ... AND ...
        ↓
    → BigQuery CHỈ QUÉT các phân vùng khớp
    → chi phí giảm theo đúng tỉ lệ
        ↓
    Bảng 3 năm, truy vấn 1 ngày
      → quét khoảng 0,1% dữ liệu

⚠ Cột giả _PARTITIONTIME — điểm cần nhớ:

Bảng phân vùng theo THỜI ĐIỂM NẠP
        ↓
    BigQuery tự thêm cột giả:
      _PARTITIONTIME  (kiểu TIMESTAMP, theo UTC)
      _PARTITIONDATE  (kiểu DATE)
        ↓
    → dùng chúng trong WHERE để lọc phân vùng
        ↓
    Khác với phân vùng theo CỘT THỜI GIAN
    (cột thật trong dữ liệu)
      → khi đó lọc theo chính cột đó

⚠ Và một cấu hình rất nên bật kèm:

require_partition_filter = true
        ↓
    → mọi truy vấn KHÔNG lọc theo phân vùng
      sẽ THẤT BẠI ngay
        ↓
    → biến một sai sót tốn kém thành
      một lỗi rõ ràng trong vài giây
    → cách hiệu quả nhất để kiểm soát chi phí

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

• D (dùng LIMIT để giới hạn số dòng trả về) — đây là phương án gần nhất và là hiểu nhầm phổ biến nhất về BigQuery: LIMIT KHÔNG giảm chi phí. BigQuery vẫn quét toàn bộ dữ liệu rồi mới cắt kết quả, và tính tiền theo lượng quét.

• C (dùng covering index) — BigQuery KHÔNG có chỉ mục theo kiểu CSDL quan hệ. Nó dùng phân vùng và phân cụm để giới hạn dữ liệu quét.

• B (dùng read replica, chỉ truy vấn replica) — BigQuery không có khái niệm read replica; nó là kho phân tích serverless, không phải CSDL giao dịch.

Ghi nhớ

⚠ Cách giảm chi phí truy vấn BigQuery — theo hiệu quả: | Cách | Hiệu quả | |---|---| | Bỏ SELECT * | rất cao — chỉ quét cột nêu tên | | Phân vùng + lọc theo phân vùng | rất cao — giảm theo tỉ lệ ngày | | Phân cụm theo cột hay lọc | cao | | require_partition_filter | ngăn sai sót từ gốc | | Materialized view | cho truy vấn tổng hợp lặp lại | | LIMIT | KHÔNG giảm chi phí | | Preview bảng | xem dữ liệu MIỄN PHÍ |

Từ khoá nhận diện:

"truy vấn theo thời gian dữ liệu đến" → ingestion time partition + _PARTITIONTIME "truy vấn theo một cột ngày trong dữ liệu" → partition theo CỘT đó "LIMIT giảm chi phí" → SAI, luôn luôn "chỉ mục" → BigQuery KHÔNG có chỉ mục "biết trước chi phí" → --dry-run

⚠ Ba kiểu phân vùng của BigQuery — bảng phải thuộc: | Kiểu | Lọc bằng | |---|---| | Theo thời điểm NẠP | _PARTITIONTIME hoặc _PARTITIONDATE | | Theo CỘT thời gian | chính cột đó (DATE, TIMESTAMP, DATETIME) | | Theo dải số nguyên | cột số nguyên | | Số phân vùng tối đa | 4.000 | | Kết hợp | partition + cluster là mẫu phổ biến nhất |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có phân vùng không | bq show <dataset>.<bang> → timePartitioning | | Truy vấn quét bao nhiêu | bq query --dry-run | | Ai tốn nhiều nhất | INFORMATION_SCHEMA.JOBS |

Và một hiểu nhầm rất phổ biến đáng nói rõ với đội phát triển: LIMIT 10 không làm truy vấn rẻ hơn một đồng nào. BigQuery đọc toàn bộ dữ liệu cần thiết rồi mới cắt kết quả, nên một câu SELECT * FROM bang_lon LIMIT 10 vẫn quét cả bảng — muốn xem thử vài dòng thì hãy dùng chức năng Preview của bảng, hoàn toàn miễn phí.

Đáp án

D — Cloud Functions.

Vì sao đúng

Đề mô tả đúng mô hình của Cloud Functions: phản ứng với message Pub/Sub, xử lý dưới một giây, và tải không đều.

⚠ Điểm mấu chốt — Pub/Sub kích hoạt Cloud Function trực tiếp:

Dữ liệu IoT được nạp qua Pub/Sub
        ↓
    Cloud Function đăng ký trigger Pub/Sub
        ↓
    Mỗi message → một lần gọi hàm
        ↓
    Kiểm tra định dạng, dưới 1 giây, rồi kết thúc
        ↓
    → "tự động chạy khi có dữ liệu mới"
      → đúng yêu cầu đề

⚠ Và mô hình chi phí khớp với tải IoT:

Tải IoT thường không đều
        ↓
    Lúc nhiều message, lúc gần như không có
        ↓
    Cloud Functions co giãn về 0
        ↓
    → không có message → KHÔNG tốn tiền
    → nhiều message → chạy song song nhiều instance
        ↓
    Trả tiền theo: số lần gọi × thời gian chạy
    → tác vụ dưới 1 giây là rất rẻ

⚠ Nhưng phải cấu hình max-instances cẩn thận:

Đợt tăng đột biến từ hàng nghìn cảm biến
        ↓
    Cloud Functions có thể chạy
    hàng nghìn instance cùng lúc
        ↓
    → làm ngập hệ thống phía sau
      (CSDL, API bên thứ ba)
        ↓
    → đặt max-instances để giới hạn
    → và Pub/Sub sẽ đệm phần còn lại

Xem thêm câu #12486 (lô 131) và #12535 (cùng lô): cùng mô hình — Cloud Functions cho tác vụ ngắn phản ứng với sự kiện. Khoá nhất quán.

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

• B (App Engine Standard) — đây là phương án gần nhất và cũng co về 0, nhưng nó hướng tới ứng dụng web phục vụ request HTTP. Để nhận message Pub/Sub thì phải dựng thêm một endpoint push, nhiều mảnh ghép hơn.

• C (App Engine Flexible) — KHÔNG co về 0: luôn có ít nhất một instance, tốn tiền cả khi không có dữ liệu.

• A (Compute Engine) — tự quản máy, chạy 24/7, và phải tự viết vòng lặp tiêu thụ message.

Ghi nhớ

⚠ Chọn dịch vụ theo mô hình kích hoạt — bảng phải thuộc: | Mô hình | Dịch vụ | |---|---| | Phản ứng với sự kiện, xử lý NGẮN | Cloud Functions | | Container, HTTP hoặc sự kiện, co về 0 | Cloud Run | | Ứng dụng web nhiều route | App Engine | | Xử lý luồng phức tạp, có cửa sổ thời gian | Dataflow | | Microservice phức tạp | GKE |

Từ khoá nhận diện:

"khi có message Pub/Sub, xử lý ngắn" → Cloud Functions "xử lý luồng có cửa sổ, gộp nhóm" → Dataflow "đã có container" → Cloud Run "tải lúc có lúc không" → dịch vụ co về 0 "App Engine Flexible" → KHÔNG co về 0

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có được gọi không | Cloud Logging, lọc theo tên hàm | | Có tồn đọng message không | num_undelivered_messages của subscription | | Có lỗi không | chỉ số error rate, và dead letter topic |

Và một cấu hình rất nên đặt cho hàm xử lý dữ liệu IoT: max-instances. Một đợt tăng đột biến từ hàng nghìn cảm biến có thể khiến Cloud Functions mở hàng nghìn instance cùng lúc và làm ngập cơ sở dữ liệu phía sau — trong khi đặt trần cho phép Pub/Sub làm đúng việc của nó là đệm lại phần vượt quá, thay vì đẩy toàn bộ áp lực xuống tầng dưới.

Đáp án

A — Tên tệp dùng NGÀY làm phần ĐẦU, nên có thể tạo hotspot khi ghi vào Cloud Storage.

Vì sao đúng

Cloud Storage đánh chỉ mục đối tượng theo thứ tự từ điển của tên, nên tên có tiền tố tuần tự làm mọi lượt ghi dồn vào cùng một vùng.

⚠ Điểm mấu chốt — tiền tố tuần tự gây hotspot:

Tên tệp: 2026-09-02-sensor001
         2026-09-02-sensor002
         2026-09-02-sensor003
        ↓
    Tất cả có CÙNG TIỀN TỐ (ngày)
        ↓
    Cloud Storage sắp xếp theo thứ tự từ điển
        ↓
    → mọi lượt ghi dồn vào cùng một dải khoá
    → hạ tầng phía sau không chia tải được
        ↓
    → thông lượng ghi bị giới hạn
    → đúng hiện tượng "tải lên chậm hơn dự kiến"

⚠ Cách sửa — làm cho tiền tố PHÂN TÁN:

Đảo thứ tự:
    sensor001-2026-09-02
        ↓
    → tiền tố là mã cảm biến, phân tán tự nhiên

Thêm tiền tố BĂM:
    a3f2/2026-09-02-sensor001
        ↓
    → băm vài ký tự đầu của tên gốc
    → trải đều trên toàn dải khoá

Thêm số ngẫu nhiên:
    7/2026-09-02-sensor001

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

Đây là kiến thức về thiết kế tên đối tượng vốn quan trọng ở giai đoạn trước. Cloud Storage đã cải thiện đáng kể khả năng tự phân chia dải khoá (auto-scaling), nên hiện tượng hotspot ngày nay ít nghiêm trọng hơn và thường tự giải quyết sau một thời gian ngắn khi hệ thống thích nghi với mẫu truy cập.

Khoá đáp án không đổi: trong bốn phương án, chỉ A nêu đúng một nguyên nhân có cơ sở kỹ thuật, và khuyến nghị của Google về việc tránh tiền tố tuần tự khi ghi ở tốc độ rất cao vẫn còn hiệu lực. Ba phương án còn lại nêu những yếu tố hoàn toàn không ảnh hưởng tới tốc độ tải lên.

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

• B (tệp ở định dạng CSV thay vì Avro) — đây là phương án gần nhất vì định dạng tệp đúng là chuyện quan trọng, nhưng nó ảnh hưởng tới hiệu năng TRUY VẤN sau này, không ảnh hưởng tốc độ TẢI LÊN: Cloud Storage coi mọi tệp là byte thuần.

• C (dữ liệu bị mã hoá trước khi lưu) — mã hoá là mặc định ở Cloud Storage, được thực hiện trong suốt và không làm chậm việc tải lên một cách đáng kể.

• D (tệp ở định dạng gzip thay vì Avro) — cùng lý do như B; hơn nữa nén thường làm tệp NHỎ HƠN nên tải LÊN NHANH HƠN.

Ghi nhớ

⚠ Thiết kế tên đối tượng cho thông lượng cao — bảng đáng thuộc: | Nên | Tránh | |---|---| | Tiền tố phân tán (mã thực thể, băm) | tiền tố tuần tự (ngày, số tăng dần) | | sensor001/2026-09-02.json | 2026-09-02/sensor001.json | | a3f2/... (băm) | 00001, 00002, … | | Lý do | Cloud Storage đánh chỉ mục theo thứ tự từ điển | | Khi nào quan trọng | ghi ở tốc độ RẤT CAO (hàng nghìn/giây) |

Từ khoá nhận diện:

"tải lên chậm, tên tệp có tiền tố tuần tự" → hotspot "tải lên chậm từ XA" → Transfer Acceleration của AWS / upload gần Region hơn "chuyển hàng chục TB" → Storage Transfer Service, Transfer Appliance "nhiều tệp nhỏ" → gộp lại, hoặc tải song song "định dạng tệp" → ảnh hưởng truy vấn, không ảnh hưởng tải lên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tốc độ tải thực tế | đo bằng time với một mẫu nhỏ | | Bucket ở Region nào | gcloud storage buckets describe gs://<ten> | | Có lỗi thử lại nhiều không | bật log chi tiết của công cụ tải lên |

Và một khuyến nghị nên áp dụng cho khối lượng như trong đề: dùng Storage Transfer Service thay vì chạy lệnh copy bằng tay. Với hàng nghìn tệp và 2 TB dữ liệu, một dịch vụ được quản lý sẽ tự xử lý việc thử lại, tự kiểm chứng checksum và cho bạn một báo cáo rõ ràng về những tệp thất bại — thay vì một script chạy nửa chừng rồi dừng mà không ai biết đã tới đâu.

Đáp án

A — gcloud sql connect [INSTANCE ID] --user=root

Vì sao đúng

gcloud sql connect là lệnh chuyên dụng để kết nối tới Cloud SQL bằng client dựng sẵn, và nó lo giúp bạn phần rắc rối nhất: cấp quyền mạng tạm thời.

⚠ Điểm mấu chốt — lệnh này làm ba việc cùng lúc:

gcloud sql connect <instance-id> --user=root
        ↓
    1. TẠM THỜI thêm IP của máy bạn
       vào danh sách được phép của instance
        ↓
    2. Khởi động client dựng sẵn
       (mysql, psql, hoặc sqlcmd)
        ↓
    3. Sau khi thoát, GỠ IP đó ra
        ↓
    → không phải tự cấu hình authorized networks
    → rất tiện khi chẩn đoán nhanh từ Cloud Shell

⚠ Vì sao gọi thẳng mysql không đủ:

mysql --host=<instance-id> --user=root
        ↓
    Vấn đề 1: `--host` cần ĐỊA CHỈ IP hoặc
              tên miền, không phải INSTANCE ID
        ↓
    Vấn đề 2: IP của Cloud Shell CHƯA nằm trong
              authorized networks
        ↓
    → kết nối bị từ chối
        ↓
    → phải tự thêm IP, hoặc dùng Cloud SQL Auth Proxy

⚠ Và cách chuẩn cho ứng dụng — Cloud SQL Auth Proxy:

Cloud SQL Auth Proxy
        ↓
    Tiến trình chạy cạnh ứng dụng
        ↓
    - Xác thực bằng IAM
    - Mã hoá kết nối tự động
    - KHÔNG cần mở IP công cộng
    - KHÔNG cần quản lý authorized networks
        ↓
    → cách khuyến nghị cho ứng dụng production
    → `gcloud sql connect` hợp cho thao tác THỦ CÔNG

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

• B (mysql --host=[INSTANCE ID] --user=root) — đây là phương án gần nhất và là lệnh MySQL có thật, nhưng --host cần địa chỉ IP hoặc tên miền, không phải instance ID. Và IP của bạn chưa được cấp quyền.

• C (gsutil sql connect ...) — sai công cụ: gsutil chỉ làm việc với Cloud Storage.

• D (gcloud mysql connect ...) — không có nhóm lệnh gcloud mysql. Nhóm đúng là gcloud sql.

Ghi nhớ

⚠ Các cách kết nối tới Cloud SQL — bảng phải thuộc: | Cách | Dùng khi | |---|---| | gcloud sql connect | thao tác THỦ CÔNG, chẩn đoán nhanh | | Cloud SQL Auth Proxy | ứng dụng production — khuyến nghị | | Cloud SQL Language Connectors | thư viện cho Java, Python, Go, Node | | Private IP + VPC | an toàn nhất — không lộ ra internet | | Public IP + authorized networks | tránh — dễ cấu hình sai | | IAM database authentication | không cần mật khẩu |

Từ khoá nhận diện:

"kết nối nhanh từ Cloud Shell" → gcloud sql connect "ứng dụng kết nối an toàn" → Cloud SQL Auth Proxy, hoặc Private IP "không muốn quản mật khẩu" → IAM database authentication "gcloud mysql ..." → SAI — nhóm đúng là gcloud sql "không lộ CSDL ra internet" → Private IP + Organization Policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có IP nào | gcloud sql instances describe <ten> → ipAddresses | | Ai được phép kết nối | cùng lệnh, xem authorizedNetworks | | Người dùng CSDL nào tồn tại | gcloud sql users list --instance=<ten> |

Và một lời khuyên về việc dùng gcloud sql connect trong môi trường doanh nghiệp: nó tạm thời mở authorized network cho IP của bạn. Rất tiện khi chẩn đoán, nhưng nếu tổ chức đã bật Organization Policy cấm IP công cộng cho Cloud SQL thì lệnh này sẽ không hoạt động — và khi đó cách đúng là dùng Cloud SQL Auth Proxy qua Private IP, thứ vốn nên là mặc định cho mọi kết nối production.

Đáp án

B — Cloud CDN.

Vì sao đúng

Đề mô tả đúng bài toán CDN giải: nội dung tĩnh nặng (ảnh và video), người dùng ở khắp thế giới, độ trễ cao với người ở xa, và nội dung được truy cập lặp lại.

⚠ Điểm mấu chốt — CDN đưa nội dung tới gần người dùng:

Nội dung nằm ở trung tâm dữ liệu Bắc Mỹ
        ↓
    Người học ở châu Á, châu Phi, châu Âu
        ↓
    Mỗi tệp phải đi nửa vòng trái đất
    → độ trễ cao, video giật
        ↓
CLOUD CDN
        ↓
    Cache nội dung ở hơn 100 điểm hiện diện
    trên toàn cầu
        ↓
    Lần đầu: lấy từ origin
    Từ lần sau: phục vụ NGAY TẠI EDGE gần người dùng
        ↓
    → độ trễ giảm mạnh và ĐỒNG ĐỀU ở mọi nơi
    → đúng yêu cầu "cùng một mức độ trễ, và thấp"

⚠ Và Cloud CDN dùng được cả với origin ngoài Google Cloud:

Đề nói: nội dung đang ở trung tâm dữ liệu
        RIÊNG của công ty
        ↓
    Cloud CDN hỗ trợ EXTERNAL BACKEND
    (internet NEG)
        ↓
    → origin có thể là máy chủ tại chỗ
    → không cần chuyển toàn bộ nội dung
      lên Cloud Storage trước
        ↓
    Dù vậy, chuyển nội dung sang Cloud Storage
    thường là bước tiếp theo hợp lý

⚠ Cách bật — Cloud CDN gắn vào backend service:

Global external HTTP(S) Load Balancer
        ↓
    Backend service
        ↓
    Bật cờ --enable-cdn
        ↓
    → Cloud CDN KHÔNG phải dịch vụ độc lập
    → nó là một TÍNH NĂNG của backend service
        ↓
    Cache mode:
      CACHE_ALL_STATIC (mặc định)
      USE_ORIGIN_HEADERS
      FORCE_CACHE_ALL

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

• A (Cloud Storage lớp Nearline) — đây là phương án gần nhất vì cũng liên quan tới lưu trữ nội dung, nhưng storage class chỉ ảnh hưởng CHI PHÍ LƯU TRỮ, không giảm độ trễ theo địa lý. (Và Nearline còn có phí đọc cao hơn — sai hướng cho nội dung được truy cập thường xuyên.)

• C (Cloud VPN) — nối mạng riêng giữa hai điểm, dành cho lưu lượng nội bộ, không phục vụ người dùng cuối trên internet.

• D (Persistent disks) — đĩa gắn vào VM, không liên quan tới phân phối nội dung toàn cầu.

Ghi nhớ

⚠ Cloud CDN — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Bật ở đâu | trên BACKEND SERVICE của Global external HTTP(S) LB | | Origin hỗ trợ | Cloud Storage, instance group, NEG, và backend NGOÀI GCP | | Cache mode | CACHE_ALL_STATIC, USE_ORIGIN_HEADERS, FORCE_CACHE_ALL | | Invalidation | xoá cache khi phát hành bản mới | | Signed URL / cookie | nội dung có kiểm soát truy cập | | Chi phí | dữ liệu ra từ CDN thường rẻ hơn từ origin |

Từ khoá nhận diện:

"người dùng toàn cầu, nội dung tĩnh chậm" → Cloud CDN "TCP/UDP không phải HTTP" → Cloud Load Balancing + Premium tier, hoặc Media CDN "video streaming quy mô lớn" → Media CDN "nối mạng riêng" → Cloud VPN hoặc Interconnect "giảm chi phí lưu trữ" → storage class, không phải CDN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CDN đã bật chưa | gcloud compute backend-services describe <ten> → enableCDN | | Cache có hiệu quả không | chỉ số cache hit ratio trong Cloud Monitoring | | Phản hồi có từ cache không | xem header Age và X-Cache |

Và một chỉ số nên nhìn ngay sau khi bật Cloud CDN: tỉ lệ cache hit. Nếu nó thấp bất thường thì gần như luôn do origin đang gửi header Cache-Control quá ngắn, hoặc do cấu hình chuyển tiếp quá nhiều cookie và query string xuống origin — mỗi biến thể tạo một mục cache riêng, và CDN khi đó chỉ còn là một lớp trung chuyển tốn tiền thay vì thứ giúp người học ở xa xem video mượt hơn.

Đáp án

B — Mỗi Region tự động được gán một dải IP định sẵn nằm trong khối 10.128.0.0/9.

Vì sao đúng

Đó chính là định nghĩa của auto mode VPC: Google tự tạo subnet ở mọi Region với dải IP đã quy định sẵn.

⚠ Điểm mấu chốt — auto mode dùng một khối cố định:

Tạo VPC ở chế độ AUTO MODE
        ↓
    Google tự tạo MỘT subnet ở MỌI Region
        ↓
    Dải IP lấy từ khối 10.128.0.0/9
        ↓
    Mỗi Region một dải /20 định sẵn
      ví dụ: us-central1  → 10.128.0.0/20
             europe-west1 → 10.132.0.0/20
        ↓
    → bạn KHÔNG chọn dải
    → Region mới của Google → tự thêm subnet

⚠ Và đây là lý do auto mode không hợp cho production:

Dải 10.128.0.0/9 là CỐ ĐỊNH
        ↓
    Muốn peer với VPC khác
      → rất dễ CHỒNG LẤN CIDR
        ↓
    Muốn nối với mạng tại chỗ
      → cũng có thể trùng dải
        ↓
    → không kiểm soát được quy hoạch IP
        ↓
    → CUSTOM MODE mới là lựa chọn cho production

⚠ Chuyển đổi một chiều:

AUTO MODE → CUSTOM MODE
        ↓
    Chuyển được
      gcloud compute networks update <ten>
        --switch-to-custom-subnet-mode
        ↓
CUSTOM MODE → AUTO MODE
        ↓
    KHÔNG chuyển được
        ↓
    → cân nhắc trước khi chuyển

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

• C (bạn khai dải CIDR không chồng lấn cho tập Region muốn tạo subnet) — đây là phương án gần nhất và mô tả đúng CUSTOM MODE, không phải auto mode. Ở auto mode bạn không khai gì cả.

• A (bạn khai dải CIDR không chồng lấn cho từng Region) — cùng lý do: đó là hành vi của custom mode.

• D (mỗi Region được gán một dải địa chỉ NGOÀI) — sai loại địa chỉ: subnet dùng dải IP NỘI BỘ. Địa chỉ ngoài được cấp riêng cho từng tài nguyên khi cần.

Ghi nhớ

⚠ Auto mode ↔ Custom mode — bảng phải thuộc: | | Auto mode | Custom mode | |---|---|---| | Subnet ban đầu | một subnet ở MỌI Region | KHÔNG có subnet nào | | Dải IP | định sẵn trong 10.128.0.0/9 | bạn tự chọn | | Region mới của Google | tự thêm subnet | không | | Khuyến nghị | thử nghiệm | PRODUCTION | | Chuyển đổi | auto → custom ĐƯỢC | custom → auto KHÔNG | | Mạng default | là auto mode | |

Từ khoá nhận diện:

"auto mode, dải IP ở đâu ra" → 10.128.0.0/9, định sẵn theo Region "kiểm soát dải IP" → custom mode "VPC của GCP" → TOÀN CẦU, subnet theo REGION "chuẩn bị peer với VPC khác" → custom mode, quy hoạch IP cẩn thận "subnet hết địa chỉ" → mở rộng được, KHÔNG thu nhỏ được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VPC ở chế độ nào | gcloud compute networks describe <ten> → subnetMode | | Có những subnet nào | gcloud compute networks subnets list --network=<ten> | | Dải IP có chồng lấn không | so với sơ đồ IP của tổ chức |

Và một khuyến nghị nên áp dụng ngay từ project đầu tiên: xoá mạng default và tạo VPC ở chế độ custom mode. Mạng default rất tiện để thử nghiệm nhưng đi kèm luật firewall mở SSH và RDP cho toàn bộ internet, cùng một dải IP cố định mà bạn sẽ phải sống chung khi cần peering về sau.