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

Đáp án

C — IAM POLICIES.

Vì sao đúng

Trong Google Cloud, IAM policy được KẾ THỪA từ trên xuống trong phân cấp tài nguyên — nên mọi thứ trong một folder cùng chịu chính sách gắn ở folder đó.

⚠ Điểm mấu chốt — kế thừa và cộng dồn:

Organization
        ↓  (kế thừa)
Folder  ← gắn IAM policy ở đây
        ↓  (kế thừa)
Project
        ↓  (kế thừa)
Resource (VM, bucket…)
        ↓
    Quyền HIỆU LỰC tại một tài nguyên
      = HỢP của mọi policy từ trên xuống
        ↓
    → gắn một vai trò ở FOLDER
      → mọi project và tài nguyên bên dưới
        đều được hưởng

⚠ Và đây là lý do folder rất hữu ích:

Folder "Phòng Kỹ thuật"
        ↓
    Gán roles/compute.viewer cho
    nhóm ky-thuat@congty.com ở CẤP FOLDER
        ↓
    → mọi project của phòng đó,
      kể cả project TẠO MỚI SAU NÀY,
      đều tự động có quyền
        ↓
    → không phải cấu hình lại từng project

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

IAM ROLE (phương án A)
        ↓
    Là một TẬP HỢP QUYỀN — một định nghĩa
    → nó KHÔNG được kế thừa
    → thứ được kế thừa là POLICY (ai giữ vai trò gì)

PERMISSION (phương án B)
        ↓
    Là quyền đơn lẻ trong một role
    → cũng không phải thứ gắn vào tài nguyên

SERVICE ACCOUNT (phương án D)
        ↓
    Là một DANH TÍNH, nằm TRONG một project
    → không lan sang project khác

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

• B (Permissions) — đây là phương án gần nhất về trực giác vì cuối cùng thì người dùng đúng là có thêm quyền, nhưng permission không phải đơn vị được gắn và kế thừa — nó nằm bên trong một role, và role được gắn thông qua policy.

• A (IAM roles) — role là định nghĩa một tập quyền, tồn tại độc lập với tài nguyên. Thứ gắn vào tài nguyên và được kế thừa là policy binding (ai giữ role gì).

• D (Service accounts) — service account là một danh tính thuộc về MỘT project cụ thể, không được chia sẻ tự động qua folder.

Ghi nhớ

⚠ Phân cấp tài nguyên và kế thừa — bảng phải thuộc: | Cấp | Nội dung | |---|---| | Organization | gốc — gắn với tên miền Cloud Identity | | Folder | nhóm project theo phòng ban hoặc môi trường | | Project | ranh giới chính của tài nguyên, quyền, hạn ngạch | | Resource | VM, bucket, bảng… | | IAM policy | KẾ THỪA từ trên xuống, CỘNG DỒN | | Organization Policy | cũng kế thừa, nhưng là ràng buộc cấu hình |

Từ khoá nhận diện:

"tài nguyên trong folder cùng chia sẻ gì" → IAM policy (kế thừa) "cấp quyền cho cả một phòng ban" → gán ở cấp FOLDER "ràng buộc cấu hình cho mọi project" → Organization Policy "từ chối tường minh" → IAM Deny policy "ranh giới tách bạch tuyệt đối" → PROJECT riêng

⚠ IAM policy ↔ Organization policy — đừng lẫn: | | IAM policy | Organization policy | |---|---|---| | Trả lời | "AI được làm GÌ" | "CẤU HÌNH nào được phép" | | Ví dụ | gán roles/compute.viewer cho một nhóm | cấm VM có IP công cộng | | Kế thừa | cộng dồn từ trên xuống | kế thừa, con có thể ghi đè nếu được phép | | Tương đương AWS | ≈ IAM policy | ≈ SCP |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Policy ở folder là gì | gcloud resource-manager folders get-iam-policy <id> | | Quyền hiệu lực của một người | Policy Troubleshooter trong console | | Project nằm ở folder nào | gcloud projects describe <id> → xem parent |

Và một hệ quả rất quan trọng của việc kế thừa cộng dồn: Google Cloud không có cơ chế "từ chối kế thừa" mặc định như SCP của AWS. Một vai trò gán ở cấp organization sẽ áp cho mọi thứ bên dưới mà project con không gỡ được — nên muốn chặn tường minh, bạn cần IAM Deny policy, một cơ chế riêng biệt và thắng mọi Allow.

Đáp án

C — BigQuery.

Vì sao đúng

Ba từ khoá: kho dữ liệu, ít công vận hành, dùng được công cụ SQL sẵn có.

⚠ Điểm mấu chốt — BigQuery là kho dữ liệu serverless:

BigQuery
        ↓
    KHÔNG có máy chủ nào để quản lý
    → không dựng cụm, không chọn cỡ máy
    → không vá, không mở rộng thủ công
        ↓
    Dùng SQL CHUẨN (GoogleSQL)
        ↓
    → kết nối qua JDBC và ODBC
    → Tableau, Looker, Power BI, dbt đều dùng được

⚠ Kiến trúc tách tính toán khỏi lưu trữ:

Lưu trữ (định dạng cột)  → trả tiền theo GB
Tính toán (slot)         → trả tiền theo TB quét,
                           hoặc mua slot
        ↓
    → lưu petabyte mà chỉ trả tiền
      cho phần thực sự truy vấn

Xem thêm câu #12487 (lô 131): cùng một câu hỏi, cùng đáp án BigQuery. Chỉ khác chữ cái — ở đó là B, ở đây là C. Khoá nhất quán.

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

• A (Cloud Spanner) — đây là phương án gần nhất về khả năng SQL, nhưng Spanner là CSDL GIAO DỊCH phân tán toàn cầu. Dùng làm kho phân tích là rất đắt và sai mục đích.

• B (Cloud SQL) — CSDL giao dịch theo Region, không mở rộng cho khối lượng phân tích lớn.

• D (Bigtable) — NoSQL, KHÔNG hỗ trợ SQL đầy đủ, không kết nối được công cụ BI truyền thống.

Ghi nhớ

⚠ Sáu dịch vụ dữ liệu của GCP — bảng phải thuộc: | Dịch vụ | Loại | Dùng khi | |---|---|---| | BigQuery | kho dữ liệu, OLAP, serverless | phân tích, báo cáo, SQL | | Cloud SQL | quan hệ, OLTP, Region | ứng dụng thông thường | | Cloud Spanner | quan hệ, OLTP, toàn cầu | giao dịch quy mô lớn | | Bigtable | NoSQL cột rộng | ghi lớn, chuỗi thời gian, IoT | | Firestore | NoSQL tài liệu | ứng dụng di động | | Memorystore | Redis / Memcached | cache |

Từ khoá nhận diện:

"data warehouse, phân tích, SQL" → BigQuery "ứng dụng giao dịch" → Cloud SQL "toàn cầu, nhất quán mạnh" → Cloud Spanner "HBase, IoT, chuỗi thời gian" → Bigtable "ứng dụng di động, offline" → Firestore

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

Và một quyết định thiết kế nên làm ngay từ ngày đầu: phân vùng bảng theo ngày. Nó quyết định phần lớn chi phí truy vấn về sau, và thêm phân vùng cho một bảng đã có hàng terabyte là công việc tốn kém hơn nhiều so với khai đúng ngay lúc tạo bảng.

Đáp án

A — gsutil rewrite -s nearline gs://free-photos-gcp

Vì sao đúng

Đổi storage class thực chất là ghi lại (rewrite) đối tượng, và gsutil rewrite với cờ -s là lệnh làm đúng việc đó.

⚠ Điểm mấu chốt — cú pháp đúng của rewrite:

gsutil rewrite -s nearline gs://bucket/**
        ↓
    -s <class>  → khai storage class ĐÍCH
        ↓
    Không có cờ `-from` hay `--to`
        ↓
    → chỉ cần biết class ĐÍCH,
      không cần khai class nguồn

⚠ Đổi class là GHI LẠI đối tượng:

Storage class là thuộc tính của TỪNG ĐỐI TƯỢNG
        ↓
    Đổi class = REWRITE đối tượng đó
        ↓
    → tính phí thao tác ghi
    → với Nearline/Coldline/Archive còn có
      THỜI GIAN LƯU TỐI THIỂU
        ↓
    Xoá hoặc đổi class trước thời hạn tối thiểu
      → vẫn bị tính đủ tiền cho thời gian đó

⚠ Cách TỰ ĐỘNG tốt hơn — Object Lifecycle Management:

Đặt luật vòng đời trên bucket
        ↓
    "Quá 30 ngày  → Nearline"
    "Quá 90 ngày  → Coldline"
    "Quá 365 ngày → Archive"
        ↓
    → Google tự chuyển, KHÔNG tốn phí thao tác
    → không phải chạy lệnh thủ công
        ↓
    Hoặc: Autoclass — Google tự chọn class
    theo mẫu truy cập thật

Xem thêm câu #12463 (lô 131): cùng bài toán đổi storage class sang Nearline, nhưng bộ phương án khác nhau — ở đó đáp án là gcloud storage objects update --storage-class (công cụ mới), ở đây là gsutil rewrite -s (công cụ cũ). CẢ HAI LỆNH ĐỀU HỢP LỆ; mỗi đề chỉ đưa ra một trong hai. Khoá nhất quán, không mâu thuẫn.

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

• D (gsutil rewrite -from multiregional --to nearline ...) — đây là phương án gần nhất và dùng đúng lệnh rewrite, nhưng cú pháp sai: không có cờ -from và --to. Cờ đúng là -s.

• B và C (gsutil migrate ...) — không có lệnh gsutil migrate.

Ghi nhớ

⚠ Bốn storage class của Cloud Storage — bảng phải thuộc: | Class | Thời gian lưu tối thiểu | Dùng khi | |---|---|---| | Standard | không có | truy cập thường xuyên | | Nearline | 30 ngày | khoảng 1 lần/tháng | | Coldline | 90 ngày | khoảng 1 lần/quý | | Archive | 365 ngày | dưới 1 lần/năm — rẻ nhất | | Đánh đổi | càng lạnh: lưu càng rẻ, ĐỌC càng đắt | |

Từ khoá nhận diện:

"đổi storage class" → gsutil rewrite -s, hoặc gcloud storage objects update --storage-class "tự động chuyển theo tuổi" → Object Lifecycle Management "không đoán được mẫu truy cập" → Autoclass "gsutil migrate" → KHÔNG TỒN TẠI "lưu trữ dài hạn" → Archive

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Class hiện tại | gcloud storage objects describe gs://bucket/tep | | Bucket có luật vòng đời không | gcloud storage buckets describe gs://bucket | | Chi phí thay đổi ra sao | Billing report, lọc SKU của Cloud Storage |

Và một lời khuyên nên áp dụng thay cho việc chạy lệnh đổi class bằng tay: đặt Object Lifecycle Management ngay từ khi tạo bucket. Nó không tốn phí thao tác chuyển class, chạy tự động mãi mãi, và tránh được tình huống ai đó đổi class hàng loạt cho hàng triệu đối tượng rồi nhận một hoá đơn thao tác ghi ngoài dự kiến.

Đáp án

C — UNMANAGED INSTANCE GROUP (nhóm instance không được quản lý).

Vì sao đúng

Từ khoá quyết định là "heterogeneous" — các node trong cụm KHÔNG giống nhau.

⚠ Điểm mấu chốt — MIG đòi mọi VM PHẢI GIỐNG HỆT NHAU:

Managed Instance Group (MIG)
        ↓
    Mọi VM tạo từ MỘT instance template
        ↓
    → cùng loại máy, cùng image,
      cùng cấu hình đĩa và mạng
        ↓
    Cụm cũ có node KHÔNG ĐỒNG NHẤT
        ↓
    → không thể mô tả bằng một template duy nhất
    → MIG không dùng được

Unmanaged Instance Group
        ↓
    Bạn TỰ THÊM từng VM vào nhóm
        ↓
    → VM có thể khác nhau hoàn toàn
    → đúng cho ứng dụng cũ đang chuyển lên

⚠ Đánh đổi khi dùng unmanaged group:

KHÔNG có:
    - autoscaling
    - autohealing
    - rolling update
    - regional (nhiều zone)
        ↓
CÓ:
    - dùng làm backend cho load balancer
    - nhóm các VM không đồng nhất lại
        ↓
    → chỉ là một "danh sách VM" để load balancer
      biết gửi lưu lượng tới đâu

⚠ Và đây nên là bước TRUNG GIAN, không phải đích đến:

Giai đoạn 1: LIFT AND SHIFT
        ↓
    Dựng VM giống cụm cũ
    Gom vào unmanaged instance group
    → chạy được ngay, ít rủi ro
        ↓
Giai đoạn 2: CHUẨN HOÁ
        ↓
    Làm cho các node giống nhau
    Dựng custom image hoặc startup script
        ↓
Giai đoạn 3: HIỆN ĐẠI HOÁ
        ↓
    Chuyển sang MIG với instance template
    → có autoscaling, autohealing, rolling update

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

• B (Managed instance groups) — đây là phương án gần nhất và là lựa chọn tốt hơn về lâu dài, nhưng MIG đòi mọi VM phải giống hệt nhau (tạo từ một template). Cụm có node không đồng nhất không dùng được ngay.

• A (Network load balancer) — phân phối lưu lượng, không phải cách để nhóm các VM lại. (Nó dùng instance group làm backend, nên đây là hai thứ khác cấp.)

• D (Autoscaler) — chỉ hoạt động với MIG, và cụm không đồng nhất thì không co giãn tự động được.

Ghi nhớ

⚠ Managed ↔ Unmanaged instance group — bảng phải thuộc: | | Managed (MIG) | Unmanaged | |---|---|---| | VM | giống hệt nhau, từ một template | khác nhau, bạn tự thêm | | Autoscaling | CÓ | KHÔNG | | Autohealing | CÓ | KHÔNG | | Rolling update | CÓ | KHÔNG | | Regional (nhiều zone) | CÓ | không — chỉ một zone | | Làm backend cho LB | có | có | | Dùng khi | ứng dụng hiện đại, co giãn | hệ thống CŨ, máy không đồng nhất |

Từ khoá nhận diện:

"node không đồng nhất", "hệ thống cũ" → unmanaged instance group "tự co giãn, tự thay máy hỏng" → MIG "lift and shift từ tại chỗ" → unmanaged trước, MIG sau "cập nhật không gián đoạn" → MIG với rolling update "chịu được mất một zone" → regional MIG

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhóm thuộc loại nào | gcloud compute instance-groups list — cột MANAGED | | Có những VM nào trong nhóm | gcloud compute instance-groups unmanaged list-instances <ten> | | Backend có khoẻ không | gcloud compute backend-services get-health <ten> |

Và một điều nên nói rõ khi chọn unmanaged instance group: đây là bước đệm, không phải đích đến. Nó cho phép chuyển hệ thống cũ lên cloud nhanh và ít rủi ro, nhưng bạn mất toàn bộ khả năng tự chữa và tự co giãn — nên lộ trình chuẩn hoá để tiến tới MIG nên được lên kế hoạch ngay từ đầu, thay vì để hệ thống dừng lại ở trạng thái tạm này nhiều năm.

Đáp án

A, B và D — bigquery.tables.create, bigquery.tables.updateData và bigquery.jobs.create.

Vì sao đúng

Nạp dữ liệu vào BigQuery là chạy một JOB ghi vào một BẢNG — nên cần quyền ở cả hai phía.

⚠ Điểm mấu chốt — nạp dữ liệu cần ba quyền:

bigquery.jobs.create
        ↓
    Mọi thao tác của BigQuery (truy vấn, nạp,
    xuất, sao chép) đều chạy dưới dạng JOB
        ↓
    → không có quyền này thì không làm được gì

bigquery.tables.create
        ↓
    Tạo bảng đích nếu chưa tồn tại

bigquery.tables.updateData
        ↓
    GHI DỮ LIỆU vào bảng
        ↓
    → ba quyền này gộp lại là đủ để `bq load`

⚠ Và đừng quên quyền ở phía Cloud Storage:

Dữ liệu nguồn nằm trong Cloud Storage
        ↓
    Danh tính nạp dữ liệu còn cần:
      storage.objects.get
      storage.objects.list
        ↓
    → thường cấp bằng roles/storage.objectViewer
        ↓
    Thiếu vế này → job thất bại với
      lỗi "Access Denied" trên bucket,
      không phải trên BigQuery

⚠ Vai trò predefined tương ứng:

roles/bigquery.dataEditor
        ↓
    Tạo, sửa, xoá bảng và dữ liệu trong dataset
        ↓
roles/bigquery.jobUser
        ↓
    CHẠY JOB trong project
        ↓
    → cấp CẢ HAI là đủ cho việc nạp dữ liệu
    → đây là cách gán chuẩn, thay vì
      liệt kê từng permission

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

• C (bigquery.jobs.list) — đây là phương án gần nhất vì cùng thuộc nhóm jobs, nhưng nó chỉ cho XEM DANH SÁCH job, không cho tạo job. Không cần cho việc nạp dữ liệu.

• E (bigquery.tables.list) — chỉ cho liệt kê bảng trong dataset, không cho tạo hay ghi.

Ghi nhớ

⚠ Các vai trò BigQuery — bảng phải thuộc: | Vai trò | Việc | |---|---| | roles/bigquery.jobUser | CHẠY JOB — truy vấn, nạp, xuất | | roles/bigquery.dataViewer | đọc dữ liệu và siêu dữ liệu | | roles/bigquery.dataEditor | tạo, sửa, xoá bảng và DỮ LIỆU | | roles/bigquery.dataOwner | thêm quyền quản trị dataset | | roles/bigquery.user | jobUser + tạo dataset + xem siêu dữ liệu | | roles/bigquery.admin | toàn quyền | | Kết hợp phổ biến | dataEditor + jobUser để nạp dữ liệu |

Từ khoá nhận diện:

"nạp dữ liệu vào BigQuery" → jobs.create + tables.create + tables.updateData "chỉ chạy truy vấn" → jobUser + dataViewer "đọc dữ liệu" → dataViewer "job thất bại vì quyền trên bucket" → thiếu storage.objectViewer "phân quyền tới từng CỘT" → column-level security với policy tag

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền gì trên dataset | bq show --format=prettyjson <dataset> | | Vì sao job thất bại | bq show -j <job_id> — đọc errorResult | | Vai trò gồm permission nào | gcloud iam roles describe roles/bigquery.dataEditor |

Và một nguyên nhân rất hay gây bối rối khi job nạp dữ liệu thất bại: thiếu quyền ở phía Cloud Storage chứ không phải phía BigQuery. Thông báo lỗi xuất hiện trong job BigQuery nên người gỡ lỗi thường soi đi soi lại quyền trên dataset — trong khi thứ còn thiếu là roles/storage.objectViewer trên bucket chứa tệp nguồn.

Đáp án

A — NEARLINE Storage.

Vì sao đúng

Đề cho một con số rất cụ thể: truy cập trung bình khoảng một lần mỗi 30 ngày. Đó chính là ngưỡng thiết kế của Nearline.

⚠ Điểm mấu chốt — mỗi class có một tần suất truy cập mục tiêu:

Standard   → truy cập THƯỜNG XUYÊN
Nearline   → khoảng 1 lần mỗi THÁNG    ← đề này
Coldline   → khoảng 1 lần mỗi QUÝ
Archive    → dưới 1 lần mỗi NĂM
        ↓
    Đề nói "khoảng 30 ngày một lần"
        ↓
    → khớp chính xác với Nearline

⚠ Vì sao chọn class quá lạnh lại TỐN HƠN:

Class càng lạnh
        ↓
    Phí LƯU TRỮ càng rẻ
    Nhưng phí ĐỌC càng ĐẮT
    Và thời gian lưu tối thiểu càng dài
        ↓
Chọn Coldline cho dữ liệu đọc hằng tháng
        ↓
    → tiết kiệm một chút tiền lưu
    → nhưng trả nhiều hơn cho phí đọc
    → và bị ràng buộc 90 ngày tối thiểu
        ↓
    → tổng chi phí có thể CAO HƠN Nearline

⚠ Thời gian lưu tối thiểu — điểm rất hay bị bỏ qua:

Nearline  → 30 ngày
Coldline  → 90 ngày
Archive   → 365 ngày
        ↓
    Xoá hoặc đổi class TRƯỚC thời hạn
        ↓
    → VẪN BỊ TÍNH ĐỦ tiền cho khoảng đó
        ↓
    → dữ liệu thay đổi thường xuyên
      thì không hợp với class lạnh

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

• D (Coldline Storage) — đây là phương án gần nhất và rẻ hơn về phí lưu trữ, nhưng nó thiết kế cho tần suất một lần mỗi quý. Với dữ liệu đọc hằng tháng, phí truy xuất cao hơn thường xoá sạch khoản tiết kiệm, và thời gian tối thiểu 90 ngày cũng chặt hơn.

• C (Multi-regional storage) — đây là vị trí lưu trữ, không phải class dành cho dữ liệu ít truy cập. Nó đắt hơn Standard một Region, hoàn toàn sai hướng khi mục tiêu là giảm chi phí.

• B (Persistent Disks) — đĩa gắn vào VM, đắt hơn nhiều so với Cloud Storage và không phải nơi để lưu trữ dữ liệu lưu trữ dài hạn.

Ghi nhớ

⚠ Bốn storage class — bảng phải thuộc: | Class | Tần suất truy cập | Thời gian lưu tối thiểu | |---|---|---| | Standard | thường xuyên | không có | | Nearline | ~1 lần/tháng | 30 ngày | | Coldline | ~1 lần/quý | 90 ngày | | Archive | <1 lần/năm | 365 ngày | | Đánh đổi | càng lạnh: lưu rẻ hơn, ĐỌC đắt hơn | | | Độ bền và độ trễ | giống nhau ở mọi class — đều truy cập tức thì | |

Từ khoá nhận diện:

"khoảng 1 lần/tháng" → Nearline "khoảng 1 lần/quý" → Coldline "lưu trữ, hầu như không đọc" → Archive "không đoán được mẫu truy cập" → Autoclass "tự chuyển theo tuổi" → Object Lifecycle Management

⚠ Class ↔ Vị trí — hai chiều KHÁC NHAU: | Chiều | Lựa chọn | |---|---| | Storage class | Standard / Nearline / Coldline / Archive | | Vị trí | Region / Dual-region / Multi-region | | Ví dụ | có thể là Nearline ở một Region, hoặc Standard đa Region | | Bẫy | "Multi-regional" KHÔNG phải một storage class — đó là vị trí | | Chọn vị trí theo | nơi người dùng và nơi tính toán, và yêu cầu tuân thủ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Class hiện tại của bucket | gcloud storage buckets describe gs://<ten> | | Chi phí theo class | Billing report, lọc SKU của Cloud Storage | | Dữ liệu thực sự được đọc bao nhiêu | bật usage log, hoặc chỉ số request trong Cloud Monitoring |

Và một cách tiếp cận thực tế khi chưa chắc chắn về tần suất truy cập: bật Autoclass và để Google tự quyết. Nó tránh được rủi ro lớn nhất của việc chọn tay — đặt dữ liệu vào một class quá lạnh rồi phải trả phí truy xuất cao hơn cả khoản tiết kiệm được, một sai lầm rất khó phát hiện cho tới khi đọc kỹ hoá đơn.

Đáp án

B — --enable-stackdriver-kubernetes

Vì sao đúng

Đây là cờ chính thức của gcloud container clusters create để bật bộ giám sát và ghi log tích hợp cho GKE.

⚠ Điểm mấu chốt — cờ này bật cả hai thứ cùng lúc:

--enable-stackdriver-kubernetes
        ↓
    Bật Cloud Monitoring cho GKE
    + Bật Cloud Logging cho GKE
        ↓
    → thay thế bộ giám sát và ghi log kiểu cũ
        ↓
    Cụm GKE mới ngày nay đã BẬT SẴN
    → cờ này dùng khi cần khai tường minh,
      hoặc bật lại cho cụm cũ

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

Tên cờ chứa chữ "stackdriver" — đây là tên CŨ của bộ sản phẩm giám sát. Google đã đổi tên Stackdriver thành Google Cloud Operations suite từ năm 2020, với các thành phần là Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, Error Reporting.

Bản thân tên cờ vẫn giữ chữ stackdriver vì lý do tương thích ngược, nên khoá đáp án không đổi. Nhưng với cụm tạo mới hôm nay, cách khai hiện hành là dùng --logging và --monitoring để chọn chính xác thành phần nào được thu thập:

--logging=SYSTEM,WORKLOAD
--monitoring=SYSTEM

Khi gặp đề nhắc tới "Stackdriver", hãy hiểu đó là Cloud Operations dưới tên cũ.

⚠ Cách khai hiện hành — chi tiết hơn:

--logging=<danh sách>
        ↓
    NONE | SYSTEM | WORKLOAD | API_SERVER
    | SCHEDULER | CONTROLLER_MANAGER
        ↓
    → chọn đúng thứ cần, giảm chi phí log

--monitoring=<danh sách>
        ↓
    NONE | SYSTEM | và các thành phần control plane
        ↓
    → SYSTEM là mức tối thiểu nên có

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

• C (--disable-legacy-monitoring) — đây là phương án gần nhất về ý nghĩa vì đề có nhắc tới "thay vì bộ giám sát kiểu cũ", nhưng cờ này không tồn tại. Việc chuyển đổi được thực hiện bằng cách BẬT bộ mới, không phải bằng một cờ tắt riêng.

• A (--enable-cloud-operations) — nghe rất hợp lý theo tên sản phẩm hiện hành, nhưng không phải tên cờ thật.

• D (--enable-gke-monitor) — hoàn toàn bịa.

Ghi nhớ

⚠ Bộ Cloud Operations (tên cũ: Stackdriver) — bảng phải thuộc: | Thành phần | Việc | |---|---| | Cloud Monitoring | chỉ số, dashboard, alert, uptime check | | Cloud Logging | thu thập, lưu trữ, truy vấn log | | Cloud Trace | vết truy tìm phân tán — chặng nào chậm | | Cloud Profiler | hồ sơ CPU và bộ nhớ của ứng dụng đang chạy | | Error Reporting | gom và phân loại lỗi | | Tên cũ | Stackdriver — vẫn xuất hiện trong một số tên cờ và API |

Từ khoá nhận diện:

"Stackdriver" → Cloud Operations dưới tên cũ "bật giám sát cho GKE" → --enable-stackdriver-kubernetes, hoặc --logging và --monitoring "chỉ số và alert" → Cloud Monitoring "log ứng dụng" → Cloud Logging "chặng nào trong microservice chậm" → Cloud Trace

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm đã bật giám sát chưa | gcloud container clusters describe <ten> → loggingConfig, monitoringConfig | | Log có lên không | Logs Explorer, lọc resource.type="k8s_container" | | Chi phí bao nhiêu | Billing, mục Cloud Logging và Cloud Monitoring |

Và một cấu hình rất đáng cân nhắc cho cụm production: khai tường minh --logging=SYSTEM,WORKLOAD thay vì bật tất cả. Log của control plane rất hữu ích khi gỡ lỗi nhưng khối lượng lớn và ít khi được đọc tới — nên bật chúng theo nhu cầu thay vì mặc định sẽ giữ hoá đơn quan sát ở mức hợp lý mà không mất khả năng chẩn đoán ứng dụng.

Đáp án

D — gcloud projects describe <PROJECT_ID>

Vì sao đúng

Hai điều cần đúng: cấu trúc lệnh (nhóm trước, động từ sau), và định danh nên dùng (PROJECT_ID).

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

gcloud  projects  describe  <PROJECT_ID>
           ↑          ↑
         nhóm     động từ
        ↓
    → NHÓM đứng TRƯỚC, ĐỘNG TỪ đứng SAU
    → "gcloud describe projects" là SAI thứ tự

⚠ Vì sao PROJECT_ID là định danh chuẩn:

PROJECT_ID
        ↓
    DUY NHẤT TOÀN CẦU
    KHÔNG đổi được sau khi tạo
        ↓
    → định danh ổn định, dùng trong
      hầu hết lệnh, API và tài liệu

PROJECT_NAME
        ↓
    Tên hiển thị, ĐỔI ĐƯỢC,
    KHÔNG cần duy nhất
        ↓
    → hai project có thể trùng tên
    → không dùng làm định danh đáng tin

⚠ Ba định danh của một project:

PROJECT_ID      → duy nhất toàn cầu, bất biến
PROJECT_NAME    → tên hiển thị, đổi được
PROJECT_NUMBER  → số do Google sinh, bất biến
                  (xuất hiện trong service account mặc định)

Xem thêm câu #12462 (lô 131): cùng cấu trúc lệnh gcloud projects describe. Ở đó bộ phương án nhấn vào việc lệnh nhận được cả PROJECT_ID lẫn PROJECT_NAME, còn ở đây bộ phương án chỉ có PROJECT_ID. Cùng một lệnh, cách diễn đạt đáp án khác nhau vì phương án khác nhau — không mâu thuẫn.

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

• A (gcloud projects describe <PROJECT_NAME>) — đây là phương án gần nhất và cấu trúc lệnh hoàn toàn đúng, nhưng PROJECT_NAME không phải định danh đáng tin: nó đổi được và không cần duy nhất. PROJECT_ID mới là lựa chọn chuẩn.

• B và C (gcloud describe projects ...) — sai thứ tự: gcloud luôn là nhóm trước, động từ sau. Không có nhóm nào tên describe.

Ghi nhớ

⚠ Cấu trúc lệnh gcloud — bảng phải thuộc: | Thành phần | Ví dụ | |---|---| | Cấu trúc | gcloud <nhóm> [<nhóm con>] <động từ> [tham số] | | Ví dụ | gcloud compute instances list | | Ví dụ | gcloud projects describe my-proj | | Động từ thường gặp | list, describe, create, delete, update | | Trợ giúp | gcloud <nhóm> --help |

Từ khoá nhận diện:

"thông tin chi tiết một tài nguyên" → describe "liệt kê nhiều" → list "gcloud describe ..." → SAI thứ tự, luôn luôn "đổi tên project" → PROJECT_NAME đổi được, PROJECT_ID KHÔNG "định danh dùng trong lệnh" → PROJECT_ID

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Project hiện tại là gì | gcloud config get-value project | | Có những project nào | gcloud projects list | | Project nằm ở folder nào | gcloud projects describe <id> → xem parent |

Và một thói quen nên có khi viết script: luôn dùng PROJECT_ID, không dùng PROJECT_NAME. Tên hiển thị có thể bị ai đó đổi trong lúc dọn dẹp và script sẽ hỏng lặng lẽ — trong khi PROJECT_ID là bất biến từ lúc tạo cho tới khi project bị xoá.

Đáp án

B — URL MAPS.

Vì sao đúng

Với HTTP(S) Load Balancing của Google Cloud, URL map là thành phần quyết định request đi tới backend service nào.

⚠ Điểm mấu chốt — URL map là bộ định tuyến tầng 7:

URL map chứa:
        ↓
    Host rule    → theo TÊN MIỀN
      api.example.com  → path matcher A
        ↓
    Path matcher → theo ĐƯỜNG DẪN
      /api/users/*   → backend-service-users
      /api/orders/*  → backend-service-orders
      /*             → backend-service-default
        ↓
    → đúng thứ đề mô tả

⚠ Các thành phần của HTTP(S) Load Balancer:

Forwarding rule       → IP + cổng
        ↓
Target HTTP(S) proxy  → kết thúc TLS
        ↓
URL MAP               → định tuyến      ← đề này
        ↓
Backend service       → health check, thuật toán
        ↓
Backend               → instance group hoặc NEG

Xem thêm câu #12464 (lô 131): cùng một câu hỏi, cùng đáp án URL maps. Chỉ khác chữ cái — ở đó là A, ở đây là B. Khoá nhất quán.

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

• C (Routes) — đây là phương án gần nhất về tên gọi, nhưng route trong VPC là bảng định tuyến ở TẦNG 3: quyết định gói tin IP đi đâu, không đọc được URL.

• D (Firewall rules) — cho phép hoặc chặn theo IP, cổng, giao thức. Là kiểm soát truy cập, không phải định tuyến ứng dụng.

• A (Traces) — Cloud Trace theo dõi độ trễ phân tán, không định tuyến gì.

Ghi nhớ

⚠ Các loại load balancer của GCP — bảng phải thuộc: | Loại | Tầng | Đặc điểm | |---|---|---| | Global external HTTP(S) | 7 | URL map, anycast toàn cầu, Cloud CDN, Cloud Armor | | SSL Proxy / TCP Proxy | 4 | toàn cầu, có kết thúc kết nối | | External passthrough Network LB | 4 | giữ nguyên IP nguồn, theo Region | | Internal HTTP(S) | 7 | trong VPC, có URL map | | Internal passthrough Network LB | 4 | trong VPC |

Từ khoá nhận diện:

"định tuyến theo URL / đường dẫn" → URL map "cân bằng tải toàn cầu cho web" → Global external HTTP(S) LB "giữ IP nguồn client" → passthrough Network LB "chặn theo IP, cổng" → firewall rule "gói tin đi đâu trong VPC" → route

Ba việc kiểm chứng: | Việc | Cách | |---|---| | URL map định tuyến ra sao | gcloud compute url-maps describe <ten> | | Backend có khoẻ không | gcloud compute backend-services get-health <ten> | | Request đi tới đâu | Cloud Logging với log của load balancer |

Và một công cụ hữu ích khi cấu hình URL map phức tạp: gcloud compute url-maps validate. Nó kiểm tra bộ quy tắc trước khi áp và chỉ ra những quy tắc bị che khuất bởi quy tắc rộng hơn đứng trước — đúng loại lỗi khiến một đường dẫn cụ thể im lặng đi nhầm backend mà không có thông báo nào.

Đáp án

C — Chỉ VM thuộc CÙNG MỘT PROJECT mới chạy trên node đó.

Vì sao đúng

Sole-tenant node là máy chủ vật lý dành riêng cho MỘT project, không chia sẻ với bất kỳ khách hàng nào khác.

⚠ Điểm mấu chốt — cô lập ở tầng phần cứng vật lý:

Máy chủ Compute Engine thông thường
        ↓
    Chạy VM của NHIỀU khách hàng khác nhau
    (vẫn cô lập an toàn bởi hypervisor)
        ↓
SOLE-TENANT NODE
        ↓
    Một máy chủ VẬT LÝ dành riêng
        ↓
    → chỉ VM của CHÍNH PROJECT đó được chạy
    → không có VM của khách hàng khác
    → không có VM của project khác
        ↓
    (Chia sẻ được sang project khác nếu
     dùng node group với sharing policy)

⚠ Vì sao người ta cần sole-tenant node:

1. TUÂN THỦ và QUY ĐỊNH
        ↓
    Một số ngành đòi "phần cứng chuyên dụng"
    → tài chính, y tế, chính phủ

2. GIẤY PHÉP PHẦN MỀM theo lõi vật lý
        ↓
    Windows Server, SQL Server, Oracle
    → "bring your own license" tính theo
      số lõi vật lý
    → sole-tenant cho biết chính xác phần cứng

3. HIỆU NĂNG ỔN ĐỊNH
        ↓
    Không có "hàng xóm ồn ào"
    → độ trễ và thông lượng ít dao động

⚠ Nhưng vẫn KHÔNG phải "chỉ một VM":

Một sole-tenant node có nhiều lõi và nhiều RAM
        ↓
    → chạy được NHIỀU VM cùng lúc
    → miễn là tất cả thuộc project được phép
        ↓
    Điều khiển bằng NODE AFFINITY LABEL:
      VM khai affinity → được xếp lên node đó

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

• B (chỉ một VM chạy trên node đó) — đây là phương án gần nhất về trực giác "dành riêng", nhưng sole-tenant node chạy được nhiều VM: nó dành riêng ở mức project, không phải ở mức từng máy ảo.

• A (chỉ VM cùng tổ chức) — quá rộng: mặc định là theo project, không phải theo tổ chức. (Chia sẻ rộng hơn được, nhưng phải cấu hình tường minh.)

• D (chỉ VM cùng hệ điều hành) — không có ràng buộc nào về hệ điều hành.

Ghi nhớ

⚠ Sole-tenant node — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Định nghĩa | máy chủ VẬT LÝ dành riêng cho một project | | Số VM | nhiều VM, miễn là cùng project | | Dùng khi | tuân thủ, giấy phép theo lõi vật lý, hiệu năng ổn định | | Node group | nhóm các node, có autoscaling | | Node affinity label | điều khiển VM nào lên node nào | | Chi phí | trả tiền cho CẢ NODE, không theo VM | | Bảo trì | chọn được chính sách khi Google bảo trì phần cứng |

Từ khoá nhận diện:

"phần cứng chuyên dụng, tuân thủ" → sole-tenant node "giấy phép theo lõi vật lý (BYOL)" → sole-tenant node "mã hoá bộ nhớ khi đang dùng" → Confidential VM "chống rootkit, toàn vẹn khởi động" → Shielded VM "VM rẻ, chịu được thu hồi" → Spot VM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có node group nào | gcloud compute sole-tenancy node-groups list | | VM chạy trên node nào | gcloud compute instances describe <ten> → scheduling.nodeAffinities | | Node còn chỗ không | gcloud compute sole-tenancy node-groups list-nodes <ten> |

Và một lý do rất thực tế khiến nhiều tổ chức chọn sole-tenant node dù đắt hơn: giấy phép phần mềm tính theo lõi vật lý. Với Windows Server hoặc Oracle mang giấy phép sẵn có, việc biết chính xác mình đang chạy trên bao nhiêu lõi vật lý là điều kiện bắt buộc để tuân thủ hợp đồng — và đó là thứ mà máy chủ dùng chung không cung cấp được.