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

Đáp án

B — Dùng bq query với cờ --dry_run.

Vì sao đúng

BigQuery tính tiền theo lượng dữ liệu QUÉT, và dry run cho biết con số đó mà không chạy truy vấn.

⚠ Điểm mấu chốt:

bq query --dry_run --use_legacy_sql=false \
  'SELECT ... FROM ...'
        ↓
    BigQuery PHÂN TÍCH truy vấn
        ↓
    Trả về số BYTE sẽ được quét
        ↓
    → KHÔNG chạy, KHÔNG tính tiền
    → so sánh được nhiều cách viết truy vấn

⚠ Từ số byte ra tiền:

Chi phí = (số byte / 2^40) × đơn giá mỗi TB
        ↓
    → so sánh trực tiếp hai cách viết
        ↓
    Console BigQuery cũng hiện ước tính này
    ở góc phải khi bạn gõ truy vấn

⚠ Và cách giảm dữ liệu quét — quan trọng hơn cả việc ước tính:

1. ĐỪNG DÙNG SELECT *
        ↓
    BigQuery lưu theo CỘT
    → chỉ quét cột được nêu tên

2. PHÂN VÙNG theo ngày + lọc trong WHERE

3. PHÂN CỤM theo cột hay lọc

4. LIMIT KHÔNG giảm chi phí
        ↓
    → vẫn quét toàn bộ rồi mới cắt

Xem thêm câu #12466 và #12500 (lô 131): cùng một câu hỏi, cùng đáp án dry run. Chỉ khác chữ cái — lần lượt là A, C, và ở đây là B. Lưu ý nhỏ: đề này viết --dry_run (gạch dưới) còn hai đề kia viết --dry-run (gạch ngang) — bq chấp nhận cả hai dạng, không mâu thuẫn. Khoá nhất quán.

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

• A (--estimate-cost) — đây là phương án gần nhất và nghe rất hợp lý, nhưng cờ này không tồn tại.

• C (--cost) — cũng không tồn tại.

• D (--limit và --scan) — cả hai đều không phải cờ của bq query, và LIMIT trong SQL cũng không giảm chi phí.

Ghi nhớ

⚠ Hai mô hình tính giá BigQuery — bảng phải thuộc: | Mô hình | Cách tính | |---|---| | On-demand | theo TB dữ liệu QUÉT — có mức miễn phí mỗi tháng | | Capacity (slot) | mua slot — chi phí cố định, đoán trước được | | Lưu trữ | active và long-term (không sửa 90 ngày → rẻ hơn ~50%) | | Chọn capacity khi | khối lượng truy vấn lớn và ổn định |

Từ khoá nhận diện:

"biết chi phí trước khi chạy" → bq query --dry_run "giảm chi phí truy vấn" → partition, cluster, bỏ SELECT * "trần cứng cho một truy vấn" → --maximum_bytes_billed "giới hạn chi tiêu hằng ngày" → custom quota "LIMIT giảm chi phí" → SAI, luôn luôn

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ờ rất đáng đưa vào mọi script chạy truy vấn tự động: --maximum_bytes_billed. Nó biến một truy vấn viết sai — chẳng hạn quên mệnh đề lọc theo phân vùng — thành một lỗi rõ ràng ngay lập tức, thay vì một hoá đơn quét vài trăm terabyte mà bạn chỉ phát hiện vào cuối tháng.

Đáp án

A và C — XOÁ (Delete) và ĐẶT STORAGE CLASS (SetStorageClass).

Vì sao đúng

Object Lifecycle Management của Cloud Storage chỉ có đúng hai loại hành động, và đó là hai hành động này.

⚠ Điểm mấu chốt — chỉ hai hành động, không hơn:

Object Lifecycle Management
        ↓
    ACTION chỉ có hai loại:
        ↓
    Delete
      → xoá đối tượng, hoặc xoá phiên bản cũ
        ↓
    SetStorageClass
      → chuyển sang Nearline, Coldline, Archive…
        ↓
    → KHÔNG có "move", "copy",
      hay "enable versioning"

⚠ Các điều kiện kích hoạt luật:

age                        → tuổi đối tượng (ngày)
createdBefore              → tạo trước một ngày cụ thể
matchesStorageClass        → đang ở class nào
numNewerVersions           → có bao nhiêu phiên bản mới hơn
daysSinceNoncurrentTime    → bao lâu kể từ khi thành phiên bản cũ
isLive                     → là phiên bản hiện tại hay không
matchesPrefix / Suffix     → theo tiền tố hoặc đuôi tên
        ↓
    Nhiều điều kiện trong một luật
      → phải thoả TẤT CẢ

⚠ Một luật vòng đời điển hình:

Quá 30 ngày   → SetStorageClass NEARLINE
Quá 90 ngày   → SetStorageClass COLDLINE
Quá 365 ngày  → SetStorageClass ARCHIVE
Quá 7 năm     → Delete
        ↓
    Với bucket bật versioning:
      numNewerVersions > 3  → Delete
        ↓
    → dọn phiên bản cũ tự động

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

• D (Move files) — đây là phương án gần nhất về trực giác vì "chuyển sang class khác" nghe giống "di chuyển", nhưng lifecycle không di chuyển tệp giữa các bucket. Nó chỉ đổi storage class tại chỗ.

• E (Copy files) — không có hành động sao chép. Muốn nhân bản sang bucket khác thì dùng Storage Transfer Service hoặc bucket replication.

• B (Enable versioning) — versioning là một cài đặt của BUCKET, bật một lần, không phải hành động vòng đời.

Ghi nhớ

⚠ Object Lifecycle Management — bảng phải thuộc: | Thành phần | Nội dung | |---|---| | Hai hành động | Delete và SetStorageClass | | Điều kiện | age, createdBefore, matchesStorageClass, numNewerVersions, isLive, daysSinceNoncurrentTime, matchesPrefix/Suffix | | Áp ở đâu | trên BUCKET, áp cho mọi đối tượng khớp | | Chi phí | KHÔNG tính phí thao tác cho việc chuyển class | | Tần suất chạy | Google đánh giá mỗi ngày một lần | | Khai bằng | tệp JSON, console, hoặc Terraform |

Từ khoá nhận diện:

"tự động chuyển class theo tuổi" → lifecycle SetStorageClass "tự động xoá dữ liệu cũ" → lifecycle Delete "dọn phiên bản cũ" → numNewerVersions hoặc daysSinceNoncurrentTime "sao chép sang bucket khác" → Storage Transfer Service, không phải lifecycle "không đoán được mẫu truy cập" → Autoclass

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket có luật gì | gcloud storage buckets describe gs://<ten> → lifecycle | | Đối tượng đang ở class nào | gcloud storage objects describe gs://<ten>/<tep> | | Chi phí thay đổi ra sao | Billing report, lọc SKU của Cloud Storage |

Và một biện pháp an toàn nên áp dụng trước khi bật luật Delete trên một bucket production: bật versioning trước. Khi đó một luật viết sai sẽ chỉ tạo delete marker chứ không xoá hẳn dữ liệu, và bạn còn cơ hội khôi phục — thay vì phát hiện sai sót vào ngày hôm sau khi Google đã chạy luật và dữ liệu không còn ở đâu cả.

Đáp án

A — gcloud compute images create devimage1 --source-snapshot devsnapshot1

Vì sao đúng

Cấu trúc lệnh gcloud là nhóm — nhóm con — động từ, và image thuộc nhóm compute.

⚠ Điểm mấu chốt — thứ tự của lệnh:

gcloud  compute  images  create  <ten>  --source-snapshot <snapshot>
          ↑         ↑       ↑
        nhóm    nhóm con  động từ
        ↓
    → "gcloud images create" thiếu nhóm compute
    → "gcloud disk images create" sai nhóm con
    → "gcloud disk create" tạo ĐĨA, không tạo image

⚠ Image tạo được từ nhiều nguồn:

--source-snapshot <snapshot>   ← đề này
--source-disk <đĩa>
--source-image <image khác>
--source-uri gs://...          (tệp .tar.gz)
        ↓
    → tất cả đều dùng
      `gcloud compute images create`

⚠ Snapshot ↔ Image ↔ Machine image — phân biệt:

SNAPSHOT
        ↓
    Bản sao lưu của MỘT đĩa
    → dùng để khôi phục, tạo đĩa mới

IMAGE
        ↓
    KHUÔN để TẠO VM MỚI
    → dùng trong instance template của MIG
    → có image family để luôn lấy bản mới nhất

MACHINE IMAGE
        ↓
    TOÀN BỘ VM: mọi đĩa, cấu hình, metadata
    → dùng để nhân bản nguyên một máy

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

• C (gcloud images create ...) — đây là phương án gần nhất và có đúng động từ và cờ, nhưng thiếu nhóm compute. Không có nhóm cấp cao nào tên images.

• B (gcloud disk images create ...) — sai nhóm con: không có gcloud disk, và nhóm con đúng là images trực tiếp dưới compute.

• D (gcloud disk create ...) — tạo ĐĨA, không phải image, và cũng sai nhóm.

Ghi nhớ

⚠ Snapshot ↔ Image ↔ Machine image — bảng phải thuộc: | | Snapshot | Image | Machine image | |---|---|---|---| | Là gì | bản sao lưu một ĐĨA | khuôn tạo VM | toàn bộ VM | | Dùng cho | khôi phục, tạo đĩa | instance template, MIG | nhân bản một máy | | Phạm vi | toàn cầu | toàn cầu | toàn cầu | | Gồm nhiều đĩa | không | không | CÓ | | Tăng dần | có | không | có |

Từ khoá nhận diện:

"tạo khuôn để dựng VM mới" → image "sao lưu một đĩa" → snapshot "nhân bản nguyên một VM nhiều đĩa" → machine image "luôn lấy bản image mới nhất" → image family "gcloud images ..." → SAI — thiếu nhóm compute

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Image đã tạo xong chưa | gcloud compute images describe <ten> → status | | Family đang trỏ vào image nào | gcloud compute images describe-from-family <family> | | Image dựa trên nguồn nào | cùng lệnh describe, xem sourceSnapshot hoặc sourceDisk |

Và một cấu hình rất đáng dùng ngay từ image đầu tiên: gán image vào một image family. Khi đó instance template chỉ cần trỏ tới tên family, và mỗi lần bạn dựng image mới thì mọi máy tạo ra sau đó tự dùng bản mới — không phải sửa template, và lùi lại cũng chỉ là một lệnh deprecate.

Đáp án

B — --ack-deadline

Vì sao đúng

Message bị gửi lặp lại gần như luôn có một nguyên nhân: người tiêu thụ xử lý LÂU HƠN thời hạn xác nhận, nên Pub/Sub tưởng nó thất bại và gửi lại.

⚠ Điểm mấu chốt — ack deadline là đồng hồ đếm ngược:

Pub/Sub gửi một message
        ↓
    Bắt đầu đếm ACK DEADLINE (mặc định 10 giây)
        ↓
    Người tiêu thụ xử lý xong → gửi ACK
        ↓
    → message được coi là đã xử lý, không gửi lại

    Người tiêu thụ CHƯA ack khi hết hạn
        ↓
    → Pub/Sub cho rằng nó thất bại
    → GỬI LẠI message cho một consumer khác
        ↓
    → xử lý mất 30 giây mà deadline 10 giây
      → message bị gửi lại 3 lần
      → đúng hiện tượng trong đề

⚠ Hai cách sửa:

1. TĂNG ack deadline
        ↓
    --ack-deadline=60   (tối đa 600 giây)
        ↓
    → phù hợp khi biết trước thời gian xử lý

2. GIA HẠN ĐỘNG (modifyAckDeadline)
        ↓
    Client library tự động gia hạn
    trong lúc còn đang xử lý
        ↓
    → cách tốt hơn khi thời gian xử lý biến động
    → hầu hết thư viện chính thức đã làm sẵn

⚠ Nhưng phải nhớ một điều nền tảng:

Pub/Sub đảm bảo giao ÍT NHẤT MỘT LẦN
        ↓
    → message CÓ THỂ tới hơn một lần
      ngay cả khi ack deadline hoàn toàn đúng
        ↓
    → người tiêu thụ PHẢI IDEMPOTENT
        ↓
    Muốn đúng một lần thật sự:
      → bật EXACTLY-ONCE DELIVERY
      → hoặc tự khử trùng lặp bằng message ID

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

• A (--dead-letter-topic) — đây là phương án gần nhất vì cũng liên quan tới message xử lý thất bại, nhưng dead letter topic là nơi chứa message đã thử lại quá số lần cho phép. Nó giới hạn số lần lặp, nhưng không sửa nguyên nhân khiến message bị gửi lại.

• C và D (--max-retry-delay, --min-retry-delay) — đây là tham số của retry policy, quyết định chờ bao lâu giữa các lần thử lại, không quyết định có thử lại hay không.

Ghi nhớ

⚠ Pub/Sub — các tham số của subscription: | Tham số | Việc | |---|---| | --ack-deadline | thời gian chờ ack, mặc định 10 giây, tối đa 600 | | --message-retention-duration | giữ message bao lâu (10 phút – 31 ngày) | | --dead-letter-topic | nơi chứa message hỏng sau N lần thử | | --max-delivery-attempts | số lần thử trước khi vào dead letter | | --min-retry-delay / --max-retry-delay | khoảng chờ giữa các lần thử | | --enable-exactly-once-delivery | giao đúng một lần | | --enable-message-ordering | giữ thứ tự theo ordering key |

Từ khoá nhận diện:

"message bị gửi lặp lại" → --ack-deadline quá ngắn "message hỏng kẹt mãi trong hàng đợi" → dead letter topic "cần đúng một lần" → exactly-once delivery, hoặc idempotent "cần giữ thứ tự" → ordering key "tồn đọng tăng" → num_undelivered_messages

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ack deadline hiện tại | gcloud pubsub subscriptions describe <ten> | | Có bao nhiêu lần hết hạn | chỉ số expired_ack_deadlines_count | | Message có bị lặp không | ghi log message_id rồi đếm trùng |

Và một nguyên tắc nên áp dụng bất kể ack deadline được đặt đúng tới đâu: luôn viết consumer idempotent. Pub/Sub chỉ đảm bảo giao ít nhất một lần, nên một message trùng lặp có thể xuất hiện vì lý do hoàn toàn khác — mạng chập chờn, consumer khởi động lại — và một thiết kế phụ thuộc vào việc "mỗi message chỉ tới đúng một lần" sẽ hỏng vào lúc bạn ít mong đợi nhất.

Đáp án

C — Cài CLOUD MONITORING AGENT trên từng máy chủ và theo dõi chỉ số load_15m.

Vì sao đúng

Đề đòi ít công nhất, và Cloud Monitoring agent làm sẵn toàn bộ việc thu thập, truyền tải, lưu trữ và hiển thị.

⚠ Điểm mấu chốt — vì sao phải cần agent:

Cloud Monitoring mặc định thu chỉ số
từ phía HYPERVISOR
        ↓
    Có sẵn: CPU utilization, network, disk I/O
        ↓
    KHÔNG có sẵn:
      - load average (1m, 5m, 15m)
      - bộ nhớ đã dùng
      - dung lượng đĩa đã dùng
      - danh sách tiến trình
        ↓
    → những thứ này nằm BÊN TRONG hệ điều hành
    → phải cài AGENT mới lấy được

⚠ Và agent lo trọn gói phần còn lại:

Cloud Monitoring agent (Ops Agent)
        ↓
    - Thu chỉ số theo chu kỳ
    - Truyền lên Cloud Monitoring
    - Lưu trữ, vẽ biểu đồ, đặt alert
        ↓
    → không phải viết script
    → không phải dựng nơi lưu trữ
    → không phải tự vẽ đồ thị
        ↓
    Cài hàng loạt bằng:
      Ops Agent policy, hoặc
      startup script trong instance template

⚠ Vì sao viết script là cách tệ nhất:

Script chạy `sar -u` rồi ghi vào syslog
        ↓
    - Phải tự triển khai lên từng máy
    - Phải tự thu gom log về một chỗ
    - Phải tự phân tích ra số liệu
    - Phải tự vẽ biểu đồ và đặt cảnh báo
    - Phải tự bảo trì khi máy đổi
        ↓
    → rất nhiều công cho việc đã có sẵn

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

• D (cài Prometheus agent và theo dõi load_15m) — đây là phương án gần nhất và Prometheus là công cụ rất tốt, nhưng nó đòi bạn dựng và vận hành cả một hệ thống Prometheus. (Google có Managed Service for Prometheus làm nhẹ việc này, nhưng với nhu cầu đơn giản trong đề thì Ops Agent vẫn ít công hơn.)

• A (script sar -u ghi vào syslog) — rất nhiều công: triển khai, thu gom, phân tích, vẽ đồ thị đều phải tự làm.

• B (script sar -u ghi ra sysout) — tệ hơn nữa: sysout không phải nơi lưu trữ, dữ liệu sẽ biến mất.

Ghi nhớ

⚠ Chỉ số có sẵn ↔ chỉ số cần agent — bảng phải thuộc: | Có sẵn (hypervisor) | Cần agent | |---|---| | instance/cpu/utilization | load_1m, load_5m, load_15m | | instance/network/received_bytes_count | bộ nhớ đã dùng (memory/percent_used) | | instance/disk/read_bytes_count | dung lượng đĩa đã dùng (disk/percent_used) | | Uptime | swap, số tiến trình | | — | log của hệ điều hành và ứng dụng |

Từ khoá nhận diện:

"load average, bộ nhớ, dung lượng đĩa" → CẦN AGENT "CPU, mạng" → có sẵn, không cần agent "ít công nhất" → dịch vụ được quản lý, đừng viết script "đã có Prometheus" → Managed Service for Prometheus "máy tại chỗ cũng cần giám sát" → Ops Agent chạy được ngoài GCP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có chạy không | sudo systemctl status google-cloud-ops-agent | | Chỉ số đã lên chưa | Metrics Explorer, tìm agent.googleapis.com | | Máy nào cấp phát thừa | Recommender trong console |

Và một công cụ có sẵn rất đáng dùng cho đúng mục đích trong đề: Recommender của Compute Engine. Sau khi Ops Agent thu đủ dữ liệu vài ngày, Google sẽ tự đưa ra gợi ý đổi loại máy cho từng VM kèm ước tính tiết kiệm — nhanh hơn nhiều so với việc tự đọc biểu đồ load_15m của hàng chục máy rồi tự quyết định.

Đáp án

A — roles/iam.roles.create

Vì sao đúng

Trong bốn lựa chọn, đây là phương án duy nhất nhắc tới đúng hành động tạo custom role; ba phương án còn lại đều không liên quan hoặc không tồn tại.

⚠ Điểm mấu chốt — quyền cần để tạo custom role:

Tạo một custom role đòi permission:
        ↓
    iam.roles.create
        ↓
    Kèm theo (để quản lý trọn vẹn):
      iam.roles.get
      iam.roles.list
      iam.roles.update
      iam.roles.delete
        ↓
    Vai trò predefined chứa đủ chúng:
      roles/iam.roleAdmin           (cấp project)
      roles/iam.organizationRoleAdmin (cấp tổ chức)

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

Phương án đáp án viết roles/iam.roles.create — đây là một chuỗi TRỘN HAI ĐỊNH DẠNG:

• iam.roles.create là một PERMISSION (ba phần: dịch vụ, tài nguyên, hành động)
• roles/... là tiền tố của ROLE

Trong Google Cloud thật, không tồn tại vai trò nào tên roles/iam.roles.create. Vai trò đúng để tạo custom role là roles/iam.roleAdmin (ở cấp project) hoặc roles/iam.organizationRoleAdmin (ở cấp tổ chức).

Khoá đáp án không đổi vì trong bốn phương án, A là phương án duy nhất nêu đúng hành động cần thiết (iam.roles.create); ba phương án còn lại nói về service account hoặc là chuỗi bịa hoàn toàn. Khi gặp đề tương tự có đủ lựa chọn, hãy nhớ: roles/iam.roleAdmin là câu trả lời chuẩn.

⚠ Và custom role có vài ràng buộc cần biết:

Custom role tạo được ở
        ↓
    Cấp PROJECT, hoặc cấp ORGANIZATION
    → KHÔNG tạo được ở cấp folder
        ↓
    Chỉ chứa được permission mà
    NGƯỜI TẠO đã có
        ↓
    Bạn phải TỰ BẢO TRÌ khi Google
    thêm permission mới cho dịch vụ

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

• C (roles/iam.serviceAccountUser) — đây là phương án gần nhất vì là một vai trò CÓ THẬT, nhưng nó cho phép dùng một service account (impersonate, gán vào tài nguyên), hoàn toàn không liên quan tới việc tạo custom role.

• B (roles/iam.roles.create.custom) — chuỗi bịa, không phải định dạng hợp lệ của cả role lẫn permission.

• D (roles/iam.serviceAccountUser.create) — cũng bịa: ghép một vai trò có thật với một hậu tố không tồn tại.

Ghi nhớ

⚠ Permission ↔ Role — bảng phải thuộc: | | Permission | Role | |---|---|---| | Định dạng | <dichvu>.<taiNguyen>.<hanhDong> | roles/<dichvu>.<ten> | | Ví dụ | iam.roles.create | roles/iam.roleAdmin | | Gán trực tiếp | KHÔNG | CÓ | | Bẫy | roles/ + chuỗi ba phần = luôn SAI | |

Từ khoá nhận diện:

"tạo custom role" → roles/iam.roleAdmin "dùng một service account" → roles/iam.serviceAccountUser "tạo service account" → roles/iam.serviceAccountAdmin "gán vai trò cho người khác" → roles/resourcemanager.projectIamAdmin "quản lý toàn bộ IAM" → roles/iam.securityAdmin

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Custom role gồm gì | gcloud iam roles describe <ten> --project=<id> | | Có những custom role nào | gcloud iam roles list --project=<id> | | Vai trò predefined gồm gì | gcloud iam roles describe roles/iam.roleAdmin |

Và một cách tiếp cận nên theo trước khi tạo custom role: dùng IAM Recommender để xem Google gợi ý gì. Nó phân tích hành vi thật rồi đề xuất một bộ permission tối thiểu — thường sát hơn nhiều so với việc tự đoán, và tránh được cả việc thiếu quyền lẫn việc phải bảo trì một danh sách permission tự viết.

Đáp án

B — SSL PROXY Load Balancing.

Vì sao đúng

Ba manh mối: client BÊN NGOÀI, lưu lượng TCP có SSL, và muốn GIẢM TẢI xử lý SSL.

⚠ Điểm mấu chốt — "offload SSL" nghĩa là load balancer phải KẾT THÚC TLS:

SSL Proxy Load Balancing
        ↓
    Load balancer KẾT THÚC kết nối TLS
        ↓
    → giải mã tại load balancer
    → backend nhận lưu lượng đã giải mã
      (hoặc mã hoá lại nếu cấu hình)
        ↓
    → máy chủ backend KHÔNG phải
      tốn CPU cho việc bắt tay TLS
    → đây chính là "offload SSL processing"

⚠ Và vì sao không phải HTTP(S) LB:

Đề nói "TCP traffic, including SSL"
        ↓
    → KHÔNG nói là HTTP
        ↓
    HTTP(S) Load Balancing hoạt động ở TẦNG 7
      → cần hiểu giao thức HTTP
        ↓
    Lưu lượng TCP có TLS nhưng KHÔNG PHẢI HTTP
      (ví dụ: SMTPS, IMAPS, giao thức riêng)
        ↓
    → SSL Proxy là lựa chọn đúng

⚠ Bốn load balancer tầng 4 của GCP — phân biệt:

SSL PROXY (ngoài, toàn cầu)        ← đề này
        ↓
    Kết thúc TLS, cho TCP có mã hoá

TCP PROXY (ngoài, toàn cầu)
        ↓
    Kết thúc TCP, KHÔNG xử lý TLS

External passthrough Network LB (ngoài, Region)
        ↓
    KHÔNG kết thúc gì — giữ nguyên IP nguồn

Internal passthrough (TCP/UDP) LB (trong, Region)
        ↓
    Nội bộ VPC, giữ nguyên IP nguồn

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

• C (TCP Proxy) — đây là phương án gần nhất và cùng là proxy ngoài, toàn cầu, nhưng nó không xử lý TLS: nó chỉ kết thúc kết nối TCP và chuyển tiếp. Không thực hiện được việc giảm tải SSL mà đề yêu cầu.

• A (HTTP(S) Load Balancing) — hoạt động ở tầng 7, cần lưu lượng là HTTP. Đề chỉ nói TCP có SSL.

• D (Network TCP/UDP Load Balancing) — là passthrough: nó không kết thúc kết nối nên không giảm tải SSL được, và backend vẫn phải tự xử lý toàn bộ TLS.

Ghi nhớ

⚠ Các load balancer của Google Cloud — bảng phải thuộc: | Loại | Tầng | Trong/Ngoài | Kết thúc TLS | |---|---|---|---| | Global external HTTP(S) | 7 | ngoài | CÓ | | SSL Proxy | 4 | ngoài, toàn cầu | CÓ | | TCP Proxy | 4 | ngoài, toàn cầu | không | | External passthrough Network | 4 | ngoài, Region | không | | Internal passthrough (TCP/UDP) | 4 | trong, Region | không | | Internal HTTP(S) | 7 | trong, Region | có |

Từ khoá nhận diện:

"offload SSL, lưu lượng TCP không phải HTTP" → SSL Proxy "TCP không mã hoá, toàn cầu" → TCP Proxy "HTTP, định tuyến theo URL" → HTTP(S) LB "giữ nguyên IP nguồn client" → passthrough Network LB "lưu lượng trong VPC" → Internal LB

⚠ Passthrough ↔ Proxy — khác biệt cốt lõi: | | Passthrough | Proxy | |---|---|---| | Kết nối | giữ nguyên, không kết thúc | kết thúc rồi mở kết nối mới | | IP nguồn | GIỮ NGUYÊN của client | thay bằng IP của LB | | Giảm tải TLS | KHÔNG | CÓ (với SSL Proxy và HTTP(S)) | | Độ trễ | thấp hơn | cao hơn một chút | | Phạm vi | theo Region | toàn cầu (với proxy ngoài) |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | LB thuộc loại nào | gcloud compute target-ssl-proxies list | | Chứng chỉ trạng thái gì | gcloud compute ssl-certificates describe <ten> | | Backend có khoẻ không | gcloud compute backend-services get-health <ten> |

Và một cấu hình rất đáng đặt cùng lúc với SSL Proxy: SSL policy giới hạn phiên bản TLS tối thiểu. Mặc định load balancer chấp nhận cả các phiên bản TLS cũ, và một chính sách khai rõ TLS 1.2 trở lên là cách nhanh nhất để loại bỏ cả một nhóm điểm yếu mà không cần đụng tới ứng dụng phía sau.

Đáp án

A — Network TCP/UDP Load Balancing.

Vì sao đúng

Đề có hai ràng buộc: lưu lượng TCP NỘI BỘ, và trong MỘT Region. Trong bốn lựa chọn, chỉ phương án A thuộc họ load balancer tầng 4 theo Region phù hợp.

⚠ Điểm mấu chốt — loại trừ ba phương án còn lại:

SSL Proxy và TCP Proxy (B và C)
        ↓
    Là load balancer NGOẠI, TOÀN CẦU
    → phục vụ client từ internet
    → sai cả về "internal" lẫn "một Region"

Internal HTTP(S) Load Balancing (D)
        ↓
    Đúng là NỘI BỘ và theo Region
    → nhưng hoạt động ở TẦNG 7 (HTTP)
    → đề nói rõ là lưu lượng TCP
        ↓
    → còn lại phương án A

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

Tên phương án A là "Network TCP/UDP Load Balancing" — thiếu chữ "Internal". Trong tài liệu hiện hành của Google Cloud, hai loại này được đặt tên rõ ràng:

• External passthrough Network Load Balancer — cho client từ internet
• Internal passthrough Network Load Balancer (tên cũ: Internal TCP/UDP Load Balancing) — cho lưu lượng trong VPC

Đề gộp chúng dưới tên chung "Network TCP/UDP Load Balancing" của danh mục cũ, nên câu chữ có phần mơ hồ. Khoá đáp án vẫn là A vì đó là phương án duy nhất ở tầng 4 và thuộc họ passthrough theo Region — ba phương án còn lại sai rõ ràng về tầng hoặc về phạm vi.

Xem thêm câu #12536 (CÙNG LÔ): cùng bài toán — cân bằng tải TCP nội bộ trong VPC. Ở đó phương án được đặt tên đầy đủ là "Internal TCP/UDP Load Balancing" và khoá là D. Cùng một giải pháp, chỉ khác cách bộ đề đặt tên phương án — không mâu thuẫn. Khi làm bài, hãy nhận diện theo tầng (4 hay 7) và phạm vi (trong hay ngoài VPC), đừng chỉ dựa vào tên gọi.

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

• D (Internal HTTP(S) Load Balancing) — đây là phương án gần nhất và đúng về phạm vi nội bộ, nhưng nó hoạt động ở TẦNG 7: cần lưu lượng là HTTP. Đề nói rõ là TCP.

• B (SSL Proxy) — là load balancer NGOẠI, TOÀN CẦU, dành cho client từ internet với lưu lượng TLS.

• C (TCP Proxy) — cũng là ngoại và toàn cầu, và kết thúc kết nối TCP (proxy) chứ không passthrough.

Ghi nhớ

⚠ Các load balancer của Google Cloud — bảng phải thuộc: | Loại | Tầng | Trong/Ngoài | Phạm vi | |---|---|---|---| | Global external HTTP(S) | 7 | ngoài | toàn cầu | | Internal HTTP(S) | 7 | trong | Region | | SSL Proxy / TCP Proxy | 4 | ngoài | toàn cầu | | External passthrough Network | 4 | ngoài | Region | | Internal passthrough (TCP/UDP) | 4 | trong | Region |

Từ khoá nhận diện:

"TCP nội bộ, một Region" → Internal passthrough Network LB (Internal TCP/UDP LB) "HTTP nội bộ, định tuyến URL" → Internal HTTP(S) LB "từ internet, web" → Global external HTTP(S) LB "từ internet, TCP có TLS, offload SSL" → SSL Proxy "giữ nguyên IP nguồn" → passthrough, không phải proxy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | LB thuộc loại nào | gcloud compute forwarding-rules describe <ten> → loadBalancingScheme | | Backend có khoẻ không | gcloud compute backend-services get-health <ten> --region=<region> | | Firewall đã mở dải probe chưa | gcloud compute firewall-rules list --filter="sourceRanges:130.211.0.0/22" |

Và một mẹo rất hữu ích khi gặp câu hỏi về load balancer trong đề thi: đừng nhớ theo tên gọi, hãy nhớ theo ba thuộc tính — tầng (4 hay 7), phạm vi (trong hay ngoài VPC), và cơ chế (passthrough hay proxy). Google đã đổi tên các sản phẩm này vài lần, nên tên trong đề và tên trong tài liệu hiện hành có thể khác nhau, nhưng ba thuộc tính đó thì không đổi.

Đáp án

B — Cloud Dataproc.

Vì sao đúng

Hai từ khoá: đã có cụm Spark, và muốn dùng dịch vụ được quản lý.

⚠ Điểm mấu chốt — Dataproc là Spark được quản lý:

Cloud Dataproc
        ↓
    Cụm Spark, Hadoop, Hive, Pig, Presto
    do Google quản lý
        ↓
    → mã Spark hiện có CHẠY GẦN NHƯ NGUYÊN VẸN
    → chỉ đổi đường dẫn hdfs:// thành gs://
        ↓
    Google lo: dựng cụm, cấu hình, vá lỗi
        ↓
    → đường ngắn nhất từ cụm tại chỗ lên cloud

⚠ Và mô hình cụm phù du giúp tiết kiệm mạnh:

Cụm khởi tạo trong khoảng 90 giây
        ↓
    Tạo cụm → chạy job → XOÁ cụm
        ↓
    Dữ liệu để ở Cloud Storage, không ở HDFS
        ↓
    → chỉ trả tiền đúng thời gian chạy
        ↓
    Hoặc dùng **Dataproc Serverless**
    → không tạo cụm nào cả

Xem thêm câu #12483 và #12491 (lô 131): cùng một câu hỏi, cùng đáp án Cloud Dataproc. Chỉ khác chữ cái — lần lượt là D, C, và ở đây là B. Khoá nhất quán ở cả ba câu.

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

• C (Cloud Dataflow) — đây là phương án gần nhất và về lâu dài có thể là đích đến tốt hơn (serverless hoàn toàn), nhưng nó dùng Apache Beam, nghĩa là phải viết lại toàn bộ job Spark. Trái yêu cầu dùng dịch vụ được quản lý với ít công chuyển đổi.

• D (Cloud Bigtable) — CSDL NoSQL, không phải nền tảng xử lý phân tán.

• A (Cloud Data Studio) — công cụ trực quan hoá và báo cáo (nay là Looker Studio), không xử lý dữ liệu.

Ghi nhớ

⚠ Các dịch vụ xử lý dữ liệu của GCP — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Dataproc | Hadoop, Spark, Hive được quản lý — CHUYỂN mã có sẵn | | Dataflow | Apache Beam — luồng và lô, serverless, phải viết mã | | Data Fusion | ETL kéo thả, không cần mã | | BigQuery | kho dữ liệu, SQL, serverless | | Pub/Sub | hàng đợi tin nhắn | | Composer | điều phối luồng công việc (Airflow) | | Looker Studio | trực quan hoá và báo cáo (tên cũ: Data Studio) |

Từ khoá nhận diện:

"đã có Spark / Hadoop" → Dataproc "xây mới, serverless, luồng và lô" → Dataflow "ETL không viết mã" → Data Fusion "phân tích SQL" → BigQuery "báo cáo và dashboard" → Looker Studio

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job chạy thế nào | gcloud dataproc jobs list và describe | | Cụm còn sống không | gcloud dataproc clusters list | | Chi phí ra sao | Billing report, lọc Dataproc và Compute Engine |

Và một thay đổi tư duy quan trọng khi chuyển lên Dataproc: đừng lưu dữ liệu trên HDFS của cụm. Để dữ liệu ở Cloud Storage khiến cụm trở thành thứ xoá được bất cứ lúc nào — nền tảng của mô hình cụm phù du, nơi bạn ngừng trả tiền ngay khi job kết thúc thay vì nuôi một cụm nhàn rỗi suốt đêm.

Đáp án

A — Thêm TAG bằng lệnh gcloud container images add-tag.

Vì sao đúng

Trong thế giới container, tag là cách chuẩn để đặt nhãn và nhóm image.

⚠ Điểm mấu chốt — tag là nhãn gắn vào một digest:

Một image được định danh bằng DIGEST
      sha256:a1b2c3...
        ↓
    Digest là bất biến, nhưng khó đọc
        ↓
    TAG là một cái tên trỏ tới digest đó
        ↓
    Một image có thể mang NHIỀU TAG:
      myapp:v1.2.3
      myapp:production
      myapp:latest
        ↓
    → nhóm được theo môi trường, phiên bản,
      thành phần đã cài

⚠ Cú pháp lệnh:

gcloud container images add-tag \
  <image>@sha256:<digest> \
  <image>:<tag-moi>
        ↓
    Hoặc từ tag có sẵn:
      gcloud container images add-tag \
        myapp:v1.2.3 myapp:production
        ↓
    Xem tag hiện có:
      gcloud container images list-tags <image>

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

Đề nhắc tới Google Container Registry (GCR) với nhóm lệnh gcloud container images. Dịch vụ này đã ngừng phát triển và đang được thay thế bằng Artifact Registry; Google đã công bố lộ trình ngừng hoạt động của GCR.

Khoá đáp án không đổi — gcloud container images add-tag vẫn là lệnh đúng cho GCR, và trong bốn phương án chỉ nó tồn tại. Nhưng với dự án mới hôm nay, hãy dùng Artifact Registry với nhóm lệnh gcloud artifacts; việc gắn tag khi đó thường làm bằng chính docker tag và docker push, hoặc gcloud artifacts docker tags add.

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

• D (gcloud container images add-configuration) — đây là phương án gần nhất về hình thức vì cũng thuộc nhóm container images, nhưng động từ add-configuration không tồn tại.

• B (đặt tham số account khi tạo image) — account là tài khoản Google dùng để chạy lệnh, không phải nhãn phân loại image.

• C (đặt tham số billing account khi tạo image) — billing account quyết định ai trả tiền, hoàn toàn không liên quan tới việc nhóm image.

Ghi nhớ

⚠ Tag của container image — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | Digest | sha256:... — BẤT BIẾN, định danh thật của image | | Tag | cái tên trỏ tới một digest — ĐỔI ĐƯỢC | | Một image | mang được NHIỀU tag | | Bẫy | tag latest có thể trỏ image khác nhau theo thời gian | | Production | nên dùng DIGEST hoặc tag bất biến có phiên bản |

Từ khoá nhận diện:

"nhóm image theo môi trường, thành phần" → tag "bảo đảm image không đổi" → dùng DIGEST, hoặc bật immutable tag "Artifact Registry" → gcloud artifacts "Container Registry / GCR" → gcloud container images — dịch vụ cũ "quét lỗ hổng image" → Artifact Analysis

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Image có những tag nào | gcloud container images list-tags <image> | | Tag trỏ tới digest nào | cùng lệnh, cột DIGEST | | Repository dùng cái nào | gcloud artifacts repositories list cho Artifact Registry |

Và một thói quen rất đáng có khi triển khai lên production: tham chiếu image bằng DIGEST, không bằng tag. Tag có thể bị đẩy đè và trỏ sang một image khác lúc nào không hay, còn digest thì bất biến — nên một manifest Kubernetes ghi digest sẽ luôn triển khai đúng thứ bạn đã kiểm thử, kể cả sáu tháng sau.