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

Đáp án

B — Dùng PREEMPTIBLE VM instances.

Vì sao đúng

Ba manh mối của đề khớp hoàn hảo với mô hình VM giá rẻ có thể bị thu hồi: mỗi mô phỏng chỉ ~10 phút, thất bại thì chạy lại trên máy khác, và muốn giảm chi phí mà không kéo dài thời gian.

⚠ Điểm mấu chốt — tải chịu được gián đoạn thì dùng máy giá rẻ:

Preemptible / Spot VM
        ↓
    Giảm giá RẤT SÂU (tới 60-91%)
        ↓
    Đánh đổi: Google có thể THU HỒI bất cứ lúc nào
    (báo trước 30 giây)
        ↓
    Mô phỏng chỉ 10 phút
        ↓
    → xác suất bị thu hồi giữa chừng thấp
    → và nếu bị thu hồi thì đã có cơ chế
      chạy lại trên máy khác
        ↓
    → giảm chi phí mà KHÔNG kéo dài
      thời gian hoàn thành

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

Đề dùng thuật ngữ "Preemptible VM". Google đã giới thiệu Spot VM làm thế hệ kế tiếp và khuyến nghị dùng Spot VM cho mọi triển khai mới:

Khoá đáp án không đổi: preemptible VM vẫn hoạt động và vẫn là phương án đúng duy nhất trong bốn lựa chọn. Nhưng khi triển khai thật hôm nay, hãy dùng --provisioning-model=SPOT.

⚠ Thiết kế để chịu được việc bị thu hồi:

Nhận thông báo 30 giây trước
        ↓
    Metadata server, hoặc shutdown script
        ↓
    → lưu trạng thái, gỡ khỏi hàng đợi
        ↓
Kiến trúc nên có:
    - Công việc CHIA NHỎ (như 10 phút của đề)
    - Hàng đợi việc (Pub/Sub, Cloud Tasks)
    - Tự chạy lại khi thất bại
    - MIG với Spot VM + autoscaling

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

• A (dùng nhiều VM hơn) — đây là phương án gần nhất vì rút ngắn được tổng thời gian, nhưng nó TĂNG chi phí chứ không giảm. Trái thẳng yêu cầu của đề.

• C (Shielded VM) — tính năng bảo mật (secure boot, vTPM, integrity monitoring), không giảm chi phí.

• D (sole-tenant VM) — máy chủ vật lý dành riêng, ĐẮT HƠN đáng kể. Dùng cho tuân thủ và giấy phép theo lõi vật lý.

Ghi nhớ

⚠ Các mô hình mua VM của GCP — bảng phải thuộc: | Mô hình | Giảm giá | Đánh đổi | |---|---|---| | On-demand | không | linh hoạt nhất | | Spot VM | tới 91% | có thể bị thu hồi bất cứ lúc nào | | Preemptible VM | tới 80% | bị thu hồi, tối đa 24 giờ — thế hệ cũ | | Committed use discount | tới 70% | cam kết 1 hoặc 3 năm | | Sustained use discount | tự động | chạy nhiều trong tháng thì tự giảm | | Sole-tenant | ĐẮT HƠN | phần cứng dành riêng |

Từ khoá nhận diện:

"chịu được gián đoạn, muốn rẻ nhất" → Spot VM "tải ổn định, cam kết dài hạn" → committed use discount "phần cứng dành riêng, tuân thủ" → sole-tenant node "chống rootkit" → Shielded VM "mã hoá bộ nhớ khi đang dùng" → Confidential VM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM có phải Spot không | gcloud compute instances describe <ten> → scheduling.provisioningModel | | Bị thu hồi bao nhiêu lần | Cloud Logging, tìm sự kiện preemption | | Tiết kiệm được bao nhiêu | Billing report, so trước và sau |

Và một lựa chọn rất đáng cân nhắc cho đúng bài toán trong đề: Cloud Batch với Spot VM. Nó lo giúp toàn bộ phần xếp hàng, cấp phát máy và tự chạy lại khi một mô phỏng bị gián đoạn — thay vì đội nghiên cứu phải tự viết cơ chế đó, thứ vốn không phải chuyên môn của họ.

Đáp án

C — Cloud Spanner.

Vì sao đúng

Đề có ba ràng buộc, và chỉ Spanner thoả cả ba cùng lúc: CSDL quan hệ được quản lý, người dùng ở NHIỀU REGION, và dữ liệu phải NHẤT QUÁN MỌI LÚC.

⚠ Điểm mấu chốt — nhất quán mạnh trên phạm vi toàn cầu:

Cloud Spanner
        ↓
    CSDL quan hệ, có giao dịch, có SQL
        ↓
    + Mở rộng NGANG không giới hạn
    + Nhân bản ĐỒNG BỘ qua nhiều Region
        ↓
    NHẤT QUÁN MẠNH (strong consistency)
    ở phạm vi TOÀN CẦU
        ↓
    → mọi người đọc đều thấy cùng một dữ liệu
    → đúng yêu cầu "consistent at all times"

⚠ Cơ chế đằng sau — TrueTime:

Spanner dùng TRUETIME
        ↓
    Đồng hồ nguyên tử và GPS trong
    trung tâm dữ liệu của Google
        ↓
    → cho phép sắp xếp thứ tự giao dịch
      một cách toàn cục
        ↓
    → nhất quán mạnh mà vẫn mở rộng ngang
    → đây là thứ khiến Spanner khác biệt

⚠ Vì sao Cloud SQL không đủ ở đây:

Cloud SQL
        ↓
    Mở rộng theo chiều DỌC
    Nhân bản sang Region khác là BẤT ĐỒNG BỘ
        ↓
    → read replica cross-Region CÓ ĐỘ TRỄ
    → người dùng ở Region khác có thể đọc
      dữ liệu CŨ
        ↓
    → không thoả "nhất quán mọi lúc"

Xem thêm câu #12488 (lô 131) và #12517 (lô 132): cùng dạng câu hỏi chọn CSDL quan hệ được quản lý, nhưng khoá là Cloud SQL vì ở đó thị trường giới hạn ở MỘT khu vực — không cần phân tán toàn cầu. Khoá khác nhau vì ràng buộc trong đề khác nhau, không mâu thuẫn. Quy tắc phân biệt: một Region → Cloud SQL; nhiều Region + nhất quán mạnh → Spanner.

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

• D (Cloud SQL) — đây là phương án gần nhất và là lựa chọn đúng cho quy mô một khu vực, nhưng nó không nhân bản đồng bộ qua nhiều Region: replica cross-Region là bất đồng bộ, nên có độ trễ và không bảo đảm nhất quán mọi lúc.

• A (Cloud Bigtable) — NoSQL, không có giao dịch nhiều dòng, không có SQL đầy đủ. Không hợp với hệ thống quản lý tồn kho quan hệ.

• B (BigQuery) — kho dữ liệu PHÂN TÍCH, không phải CSDL giao dịch. Không phục vụ được các thao tác đọc ghi nhỏ, liên tục của hệ thống tồn kho.

Ghi nhớ

⚠ Cloud SQL ↔ Cloud Spanner — bảng phải thuộc: | | Cloud SQL | Cloud Spanner | |---|---|---| | Động cơ | MySQL, PostgreSQL, SQL Server | riêng của Google (tương thích GoogleSQL và PostgreSQL) | | Mở rộng | DỌC + read replica | NGANG, không giới hạn | | Phạm vi | theo Region | nhiều Region, TOÀN CẦU | | Nhất quán đa Region | bất đồng bộ — có độ trễ | ĐỒNG BỘ, nhất quán MẠNH | | Chi phí tối thiểu | thấp | cao hơn nhiều | | Dùng khi | hầu hết ứng dụng, một Region | quy mô lớn, nhiều Region, nhất quán mạnh |

Từ khoá nhận diện:

"nhiều Region + nhất quán mọi lúc" → Cloud Spanner "một khu vực, ứng dụng thông thường" → Cloud SQL "PostgreSQL hiệu năng cao, một Region" → AlloyDB "phân tích, kho dữ liệu" → BigQuery "NoSQL, chuỗi thời gian, ghi lớn" → Bigtable

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance cấu hình thế nào | gcloud spanner instances describe <ten> → config | | Có hotspot không | Key Visualizer trong console | | CPU có đủ không | chỉ số cpu/utilization — nên dưới 65% với multi-region |

Và một điều nên cân nhắc kỹ trước khi chốt Spanner: chi phí tối thiểu cao hơn Cloud SQL rất nhiều. Yêu cầu "nhất quán ở nhiều Region" trong đề biện minh được cho lựa chọn này, nhưng nếu thực tế phần lớn người dùng tập trung ở một khu vực và chỉ một nhóm nhỏ ở nơi khác, thì Cloud SQL với read replica thường là cân bằng hợp lý hơn nhiều về chi phí.

Đáp án

A — Tạo một CONFIGURATION cho mỗi khách hàng và dùng gcloud config configurations activate để chuyển qua lại.

Vì sao đúng

Đây chính là bài toán mà tính năng configuration của gcloud sinh ra để giải.

⚠ Điểm mấu chốt — mỗi configuration là một bộ cài đặt độc lập:

Một configuration lưu:
    project, account, region, zone
        ↓
    Tạo một cái cho mỗi khách hàng:
      gcloud config configurations create khach-a
      gcloud config configurations create khach-b
        ↓
    Chuyển qua lại:
      gcloud config configurations activate khach-a
        ↓
    → không phải gõ --project mỗi lệnh
    → không phải đăng nhập lại
    → không sợ chạy nhầm sang khách hàng khác

⚠ Và mỗi configuration nhớ cả TÀI KHOẢN đăng nhập:

Tư vấn viên thường có nhiều danh tính:
    email@congty-a.com
    email@congty-b.com
        ↓
    Configuration lưu cả `account`
        ↓
    → activate một configuration
      = đổi cả project LẪN tài khoản
        ↓
    Xem tài khoản đã đăng nhập:
      gcloud auth list

⚠ Dùng cho một lệnh duy nhất mà không đổi hẳn:

gcloud compute instances list \
  --configuration=khach-b
        ↓
    → chạy đúng lệnh này với configuration đó
    → configuration đang hoạt động KHÔNG đổi
        ↓
    Hoặc biến môi trường:
      CLOUDSDK_ACTIVE_CONFIG_NAME=khach-b

Xem thêm câu #12480 và #12509 (lô 131): cùng chủ đề gcloud config configurations. Ở đó câu hỏi là lệnh nào TẠO configuration (create); ở đây là lệnh nào CHUYỂN sang dùng (activate). Khoá nhất quán.

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

• B (tạo configuration nhưng dùng gcloud auth để kích hoạt) — đây là phương án gần nhất và vế đầu hoàn toàn đúng, nhưng sai ở động từ: gcloud auth quản lý việc ĐĂNG NHẬP, không chuyển configuration. Lệnh đúng là gcloud config configurations activate.

• C và D (tạo "policy" cho mỗi khách hàng) — không có khái niệm "policy" nào của gcloud CLI dùng cho việc này. gcloud policy cũng không phải nhóm lệnh hợp lệ trong ngữ cảnh này.

Ghi nhớ

⚠ Các lệnh về configuration — bảng phải thuộc: | Lệnh | Việc | |---|---| | gcloud config configurations create <ten> | tạo mới | | gcloud config configurations activate <ten> | CHUYỂN sang dùng | | gcloud config configurations list | liệt kê, thấy cái nào IS_ACTIVE | | gcloud config configurations delete <ten> | xoá | | gcloud config set <thuộc tính> <giá trị> | đặt thuộc tính trong configuration hiện tại | | gcloud config list | xem cấu hình đang dùng | | --configuration=<ten> | dùng cho ĐÚNG một lệnh |

Từ khoá nhận diện:

"chuyển giữa nhiều khách hàng / môi trường" → configurations activate "tạo bộ cấu hình mới" → configurations create "đặt project mặc định" → gcloud config set project "nhiều tài khoản đăng nhập" → gcloud auth list, và --account "gcloud auth để chuyển configuration" → SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng configuration nào | gcloud config configurations list | | Project và tài khoản hiện tại | gcloud config list | | Tài khoản nào đã đăng nhập | gcloud auth list |

Và một thói quen rất đáng có với người làm tư vấn cho nhiều khách hàng: hiện tên configuration đang hoạt động ngay trong dấu nhắc shell. Chạy nhầm một lệnh sang project của khách hàng khác là loại sự cố vừa khó giải thích vừa khó khắc phục — và một dòng chữ trong dấu nhắc loại bỏ hoàn toàn rủi ro đó.

Đáp án

A — LABELS (nhãn).

Vì sao đúng

Label là cơ chế của Google Cloud để gắn siêu dữ liệu vào tài nguyên, giúp nhóm và quản lý chúng theo các chiều do bạn định nghĩa.

⚠ Điểm mấu chốt — label là cặp khoá-giá trị gắn vào tài nguyên:

Gắn label:
    env  = production
    team = data-platform
    app  = inventory
        ↓
    → lọc tài nguyên theo label
    → phân tích chi phí theo label
    → viết script quản lý theo nhóm
        ↓
    Hầu hết dịch vụ của GCP đều hỗ trợ label

⚠ Và label đi vào dữ liệu thanh toán:

Label được đưa vào BILLING EXPORT
        ↓
    Xuất sang BigQuery
        ↓
    SELECT ... GROUP BY labels
        ↓
    → biết môi trường nào, đội nào tốn bao nhiêu

⚠ Label ↔ Tag ↔ Network tag — ba thứ KHÁC NHAU:

LABEL
    → TỔ CHỨC và PHÂN TÍCH CHI PHÍ

TAG (Resource Manager tag)
    → ĐIỀU KIỆN IAM và ORGANIZATION POLICY

NETWORK TAG
    → chỉ để FIREWALL RULE nhắm mục tiêu

Xem thêm câu #12476 (lô 131) và #12520 (lô 132): cùng một câu hỏi, cùng đáp án Labels. Chỉ khác chữ cái — lần lượt là B, C, và ở đây là A. Khoá nhất quán.

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

• D (Managed instance groups) — đây là phương án gần nhất vì cũng "nhóm" tài nguyên lại, nhưng MIG nhóm các VM GIỐNG HỆT NHAU để co giãn và tự chữa, không phải công cụ để phân loại tài nguyên đa dạng theo môi trường và theo đội.

• B (Images) — khuôn để tạo VM mới, không phải cơ chế phân loại.

• C (Snapshots) — bản sao lưu của đĩa, cũng không liên quan.

Ghi nhớ

⚠ Ba loại "nhãn" trong Google Cloud — bảng phải thuộc: | Loại | Dùng để | |---|---| | Label | tổ chức, lọc, và PHÂN TÍCH CHI PHÍ | | Tag (Resource Manager) | điều kiện IAM và Organization Policy | | Network tag | firewall rule nhắm mục tiêu | | Bẫy | ba thứ hoàn toàn khác nhau |

Từ khoá nhận diện:

"nhóm tài nguyên theo môi trường, theo đội" → label "chi phí theo đội" → label + billing export "điều kiện IAM theo thuộc tính" → tag "firewall nhắm vào nhóm máy" → network tag hoặc service account "nhóm VM để co giãn" → managed instance group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên có label gì | gcloud compute instances describe <ten> --format="value(labels)" | | Chi phí theo đội | truy vấn billing export trong BigQuery | | Tài nguyên nào thiếu label | Cloud Asset Inventory, hoặc --filter="-labels.env:*" |

Và một điều nên chốt trước khi gắn label hàng loạt: quy ước về tên khoá và danh sách giá trị hợp lệ. Label của Google Cloud chỉ nhận chữ thường, nhưng vẫn có thể chẻ thành team=data, team=data-platform, team=dataplatform nếu mỗi người gõ một kiểu — và một báo cáo chi phí chẻ thành ba nhánh vô nghĩa còn tệ hơn là không có báo cáo nào.

Đáp án

A — roles/logging.privateLogsViewer

Vì sao đúng

Đề yêu cầu đọc được AUDIT LOG với quyền tối thiểu, và đây là vai trò duy nhất cho phép đọc loại log riêng tư đó.

⚠ Điểm mấu chốt — log của GCP chia thành hai nhóm quyền:

LOG THÔNG THƯỜNG
        ↓
    Log ứng dụng, log hệ thống,
    Admin Activity audit log
        ↓
    → roles/logging.viewer đọc được

LOG RIÊNG TƯ (private logs)
        ↓
    DATA ACCESS audit log
    Policy Denied audit log
        ↓
    → chứa thông tin nhạy cảm về việc
      AI ĐÃ ĐỌC DỮ LIỆU GÌ
        ↓
    → cần roles/logging.privateLogsViewer

⚠ Và vai trò này bao gồm cả quyền của viewer thường:

roles/logging.privateLogsViewer
        ↓
    = roles/logging.viewer
      + quyền đọc Data Access và Policy Denied log
        ↓
    → đủ để xem TOÀN BỘ audit log
    → và KHÔNG có quyền ghi hay cấu hình
        ↓
    → đúng nghĩa "quyền tối thiểu để đọc log"

⚠ Bốn vai trò Logging thường gặp:

roles/logging.viewer
    → đọc log thông thường

roles/logging.privateLogsViewer      ← đề này
    → thêm Data Access và Policy Denied log

roles/logging.configWriter
    → tạo và sửa SINK, log bucket, exclusion
    → KHÔNG đọc log

roles/logging.admin
    → toàn quyền: đọc, ghi, cấu hình, xoá

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

• B (roles/logging.admin) — đây là phương án gần nhất và chắc chắn đọc được audit log, nhưng nó cấp toàn quyền: tạo, sửa, xoá sink và log bucket. Quá rộng so với nhu cầu chỉ đọc.

• C (roles/logging.configWriter) — cho phép cấu hình sink và bucket, nhưng KHÔNG cho đọc nội dung log.

• D (roles/logging.bucketWriter) — cho phép ghi log vào bucket, cũng không phải quyền đọc.

Ghi nhớ

⚠ Các vai trò Cloud Logging — bảng phải thuộc: | Vai trò | Quyền | |---|---| | roles/logging.viewer | đọc log THÔNG THƯỜNG và Admin Activity | | roles/logging.privateLogsViewer | thêm Data Access và Policy Denied log | | roles/logging.configWriter | cấu hình sink, bucket, exclusion — KHÔNG đọc log | | roles/logging.logWriter | ghi log — dành cho service account của ứng dụng | | roles/logging.admin | toàn quyền | | roles/logging.bucketWriter | ghi vào log bucket |

Từ khoá nhận diện:

"đọc AUDIT LOG, quyền tối thiểu" → roles/logging.privateLogsViewer "đọc log thường" → roles/logging.viewer "ứng dụng GHI log" → roles/logging.logWriter "tạo sink chuyển log đi" → roles/logging.configWriter "xem chỉ số" → roles/monitoring.viewer — dịch vụ khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đọc được audit log | gcloud projects get-iam-policy <id>, tìm vai trò logging | | Vai trò gồm permission nào | gcloud iam roles describe roles/logging.privateLogsViewer | | Data Access log đã bật chưa | IAM → Audit Logs |

Và một cách phân quyền nên áp dụng cho đội mới vào: bắt đầu bằng roles/logging.viewer, chỉ nâng lên privateLogsViewer khi công việc thật sự đòi hỏi. Data Access log tiết lộ mẫu truy cập dữ liệu của toàn tổ chức — nó là thông tin nhạy cảm ngang với chính dữ liệu mà nó ghi lại việc truy cập.

Đáp án

B — Data Access Audit Log.

Vì sao đúng

Đề cho ba manh mối và cả ba đều chỉ về một loại log duy nhất: chi phí lưu trữ tăng mạnh, vừa bật một audit log, và loại log đó mặc định TẮT với hầu hết dịch vụ.

⚠ Điểm mấu chốt — chỉ Data Access log vừa mặc định tắt vừa sinh khối lượng lớn:

Data Access audit log
        ↓
    Ghi lại MỌI thao tác ĐỌC và GHI dữ liệu
        ↓
    Mỗi lần đọc một đối tượng Cloud Storage
    Mỗi truy vấn BigQuery
    Mỗi lần gọi API đọc dữ liệu
        ↓
    → khối lượng log GẤP NHIỀU LẦN
      các loại log khác
        ↓
    → mặc định TẮT chính vì lý do này
    → bật lên là hoá đơn tăng

⚠ So sánh khối lượng — vì sao ba loại kia không thể là thủ phạm:

Admin Activity
    → chỉ ghi khi ai đó THAY ĐỔI cấu hình
    → vài chục tới vài trăm bản ghi mỗi ngày
    → LUÔN BẬT, KHÔNG TẮT ĐƯỢC, MIỄN PHÍ

System Event
    → hành động do Google thực hiện
    → rất ít, LUÔN BẬT, MIỄN PHÍ

Policy Denied
    → chỉ ghi khi bị chính sách chặn
    → ít, và mặc định BẬT

Data Access
    → mỗi thao tác đọc/ghi dữ liệu
    → có thể HÀNG TRIỆU bản ghi mỗi ngày   ← thủ phạm
    → mặc định TẮT, CÓ PHÍ

⚠ Cách xác nhận và xử lý:

Xác nhận:
    Logs Explorer, lọc:
      logName:"cloudaudit.googleapis.com%2Fdata_access"
        ↓
    Xem dịch vụ nào sinh nhiều nhất

Xử lý:
    Chỉ bật Data Access log cho DỊCH VỤ CẦN THIẾT
    (không bật cho toàn bộ)
        ↓
    Dùng EXEMPTED MEMBER để loại trừ
    service account sinh nhiều log máy móc
        ↓
    Dùng EXCLUSION FILTER trong log sink

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

• C (Admin Activity) — đây là phương án dễ nhầm nhất, nhưng nó LUÔN BẬT, không tắt được, và MIỄN PHÍ. Không thể là log "vừa mới bật", cũng không sinh chi phí.

• A (System Event) — cũng luôn bật và miễn phí, khối lượng rất nhỏ.

• D (Policy Denied) — mặc định BẬT, và chỉ ghi khi có yêu cầu bị chính sách từ chối — khối lượng nhỏ.

Ghi nhớ

⚠ Bốn loại audit log — bảng phải thuộc: | Loại | Mặc định | Phí | Ghi gì | |---|---|---|---| | Admin Activity | LUÔN BẬT, không tắt được | miễn phí | thay đổi cấu hình | | Data Access | TẮT (trừ BigQuery) | CÓ PHÍ | đọc và ghi DỮ LIỆU | | System Event | LUÔN BẬT | miễn phí | hành động của Google | | Policy Denied | BẬT | có phí | yêu cầu bị chính sách chặn | | Thời gian giữ | Admin và System 400 ngày | | Data Access 30 ngày |

Từ khoá nhận diện:

"chi phí log tăng vọt sau khi bật" → Data Access audit log "mặc định tắt" → Data Access "không tắt được, miễn phí" → Admin Activity, System Event "ai đã thay đổi cấu hình" → Admin Activity "ai đã ĐỌC dữ liệu" → Data Access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dịch vụ nào sinh nhiều log nhất | Logs Explorer, hoặc bảng Log Analytics | | Đã nạp bao nhiêu GiB | Monitoring, chỉ số logging.googleapis.com/billing/bytes_ingested | | Ai bật Data Access log | Admin Activity log — chính nó ghi lại việc này |

Và một điều nên làm trước khi bật Data Access log cho toàn tổ chức: bật thử cho một project trong một tuần rồi ngoại suy. Chi phí log của Data Access có thể lớn hơn chi phí của chính dịch vụ mà nó theo dõi — với những hệ thống đọc dữ liệu liên tục, đây là loại hoá đơn gây bất ngờ nhiều nhất trên Google Cloud.

Đáp án

C — gcloud compute instances set-service-account

Vì sao đúng

Đây là lệnh gắn service account cho một VM đã tồn tại, đúng tình huống trong đề.

⚠ Điểm mấu chốt — cú pháp và điều kiện:

gcloud compute instances set-service-account VM_NAME \
  --service-account=ten@project.iam.gserviceaccount.com \
  --scopes=cloud-platform \
  --zone=us-central1-a
        ↓
    ⚠ VM phải ở trạng thái DỪNG (TERMINATED)
        ↓
    gcloud compute instances stop VM_NAME
    gcloud compute instances set-service-account ...
    gcloud compute instances start VM_NAME

⚠ Vì sao phải dừng máy:

Danh tính của VM gắn vào
    METADATA SERVER của instance
        ↓
    Metadata server cấp token cho
    mọi tiến trình trong VM
        ↓
    → đổi danh tính khi máy đang chạy
      = đổi quyền dưới chân ứng dụng
        ↓
    → Compute Engine bắt DỪNG máy trước

⚠ Cấu trúc nhóm lệnh gcloud — cách loại trừ ba phương án kia:

gcloud <NHÓM> <NHÓM CON> <ĐỘNG TỪ>
        ↓
    gcloud compute instances set-service-account
      nhóm    nhóm con      động từ
        ↓
    Đối tượng bị tác động là INSTANCE
    → nhóm con phải là `instances`
        ↓
    Không có nhóm `gcloud compute service-accounts`
    Không có động từ `assign`
    Không có nhóm `gcloud instances`

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

• B (gcloud compute instances assign) — đây là phương án gần nhất vì nhóm con đúng, nhưng không có động từ assign trong nhóm này. Động từ đúng là set-service-account.

• A (gcloud compute service-accounts assign) — không có nhóm gcloud compute service-accounts. Service account do IAM quản lý: gcloud iam service-accounts.

• D (gcloud instances set-service-account) — thiếu nhóm compute. Không có gcloud instances.

Ghi nhớ

⚠ Lệnh về service account của VM — bảng phải thuộc: | Lệnh | Việc | |---|---| | gcloud compute instances set-service-account <vm> | gắn/đổi service account — máy phải DỪNG | | --service-account=<email> | chỉ định tài khoản | | --no-service-account --no-scopes | gỡ hoàn toàn | | --scopes=cloud-platform | phạm vi khuyến nghị | | gcloud compute instances create --service-account=... | gắn ngay lúc tạo | | gcloud iam service-accounts create/list/describe | quản lý chính service account |

Từ khoá nhận diện:

"gắn service account cho VM ĐANG CÓ" → instances set-service-account + phải dừng máy "tạo service account" → gcloud iam service-accounts create "cấp quyền cho service account" → gcloud projects add-iam-policy-binding "người dùng được chạy VM dưới danh nghĩa SA" → roles/iam.serviceAccountUser

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM đang dùng SA nào | gcloud compute instances describe <vm> --format="value(serviceAccounts)" | | Bên trong VM thấy gì | curl -H "Metadata-Flavor: Google" metadata.google.internal/computeMetadata/v1/instance/service-accounts/ | | SA có quyền gì | gcloud projects get-iam-policy <id> --flatten="bindings[].members" --filter="bindings.members:<email>" |

Và một điều đáng cân nhắc khi phải đổi service account cho nhiều VM đang phục vụ: thay bằng instance template mới và rolling update của managed instance group thay vì dừng từng máy. Cách đó không có thời gian chết, và nó cũng ép bạn ghi lại cấu hình mới vào template — nơi lần sau tạo máy sẽ đọc tới.

Đáp án

B và D — roles/compute.instanceAdmin.v1 và roles/iam.serviceAccountUser.

Vì sao đúng

Cả ba việc trong đề — tạo instance chạy dưới danh nghĩa service account, gắn đĩa cho instance đó, đặt metadata cho instance đó — đều là thao tác trên VM có gắn service account, nên cần đúng hai vai trò.

⚠ Điểm mấu chốt — vì sao phải có ĐỦ HAI:

roles/compute.instanceAdmin.v1
        ↓
    Toàn quyền trên INSTANCE:
      tạo, xoá, sửa, gắn đĩa,
      đặt metadata, khởi động, dừng
        ↓
    Nhưng KHÔNG cho phép
    "chạy dưới danh nghĩa service account"

roles/iam.serviceAccountUser
        ↓
    Cho phép ĐÍNH KÈM service account
    vào tài nguyên
        ↓
    = "được hành động dưới danh nghĩa SA đó"
        ↓
    THIẾU vai này → tạo VM có SA bị TỪ CHỐI

⚠ Vì sao Google tách riêng serviceAccountUser — chống leo thang đặc quyền:

Giả sử KHÔNG có vai này
        ↓
    Ai có quyền tạo VM
        ↓
    → tạo VM gắn service account có roles/owner
    → SSH vào VM
    → lấy token từ metadata server
        ↓
    → CHIẾM quyền owner của cả project
        ↓
    ⚠ serviceAccountUser chính là chốt chặn
      cho lỗ hổng leo thang này

⚠ Ba việc trong đề ánh xạ vào permission nào:

Tạo instance chạy như SA
    → compute.instances.create
    + iam.serviceAccounts.actAs

Gắn persistent disk
    → compute.instances.attachDisk
    + compute.disks.use

Đặt instance metadata
    → compute.instances.setMetadata
        ↓
    Ba cái đầu nằm trong instanceAdmin.v1
    actAs nằm trong serviceAccountUser

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

• E (roles/iam.serviceAccountCreator) — đây là phương án dễ nhầm nhất, nhưng nó chỉ cho phép TẠO service account mới, không cho phép dùng một service account đã có. Đề không nói gì tới việc tạo tài khoản.

• A (roles/compute.storageAdmin) — quản lý đĩa, ảnh, snapshot ở mức tài nguyên lưu trữ, không phải quyền gắn đĩa vào instance — quyền đó nằm trong instanceAdmin.v1.

• C (roles/compute.imageUser) — chỉ cho phép dùng ảnh (image) để tạo máy, không đủ cho ba việc kể trên.

Ghi nhớ

⚠ Bộ đôi kinh điển của Compute Engine — bảng phải thuộc: | Vai trò | Cho phép | |---|---| | roles/compute.instanceAdmin.v1 | toàn quyền trên VM: tạo, xoá, gắn đĩa, metadata | | roles/iam.serviceAccountUser | actAs — đính kèm service account | | Phải có CẢ HAI | để tạo VM có gắn service account | | Thiếu vai thứ hai | lỗi quyền, dù có toàn quyền compute |

Từ khoá nhận diện:

"tạo VM CHẠY NHƯ service account" → instanceAdmin.v1 + serviceAccountUser "tạo service account mới" → roles/iam.serviceAccountCreator "cấp quyền CHO service account" → roles/resourcemanager.projectIamAdmin "tạo và quản lý KHOÁ của SA" → roles/iam.serviceAccountKeyAdmin "chỉ xem VM" → roles/compute.viewer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có actAs trên SA | gcloud iam service-accounts get-iam-policy <sa> | | Vai trò gồm permission nào | gcloud iam roles describe roles/compute.instanceAdmin.v1 | | Vì sao một người bị từ chối | Policy Troubleshooter trong console |

Và một điểm hay bị bỏ sót khi phân quyền lần đầu: roles/iam.serviceAccountUser nên cấp trên chính service account cụ thể, chứ không cấp ở cấp project. Cấp ở cấp project nghĩa là người đó dùng được mọi service account trong project — kể cả tài khoản mặc định vốn mang roles/editor, và như vậy là mở lại đúng cái cửa mà vai trò này sinh ra để đóng.

Đáp án

C — resourcemanager.projects.get, resourcemanager.projects.getIamPolicy, và resourcemanager.projects.setIamPolicy.

Vì sao đúng

"Quản lý project" cần đủ ba việc: nhìn thấy project, đọc chính sách IAM hiện tại, và thay đổi chính sách đó. Thiếu bất kỳ cái nào là công việc quản lý bị đứt.

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

resourcemanager.projects.get
        ↓
    Nhìn thấy project, đọc siêu dữ liệu
    → THIẾU: không liệt kê được project
      để mà quản lý

resourcemanager.projects.getIamPolicy
        ↓
    Đọc chính sách IAM hiện tại
    → THIẾU: không biết ai đang có quyền gì

resourcemanager.projects.setIamPolicy
        ↓
    GHI chính sách IAM
    → THIẾU: chỉ xem được, không sửa được

⚠ Và có một lý do KỸ THUẬT khiến get + set phải đi cùng nhau:

IAM policy được ghi theo kiểu ĐỌC – SỬA – GHI
        ↓
    setIamPolicy GHI ĐÈ TOÀN BỘ chính sách
        ↓
    Muốn thêm một binding mà không xoá
    binding của người khác
        ↓
    → phải getIamPolicy trước
    → sửa trong bộ nhớ
    → rồi setIamPolicy
        ↓
    ⚠ Có setIamPolicy mà không có getIamPolicy
      = mỗi lần ghi là XOÁ SẠCH quyền của
        mọi người khác

⚠ add-iam-policy-binding che giấu chu trình này:

gcloud projects add-iam-policy-binding PROJ \
  --member=user:a@b.com --role=roles/viewer
        ↓
    Bên trong lệnh này:
      1. getIamPolicy
      2. thêm binding
      3. setIamPolicy với ETAG
        ↓
    → nên nó vẫn CẦN CẢ HAI quyền
    → etag chống ghi đè khi hai người
      sửa cùng lúc

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

• D (get và setIamPolicy only) — đây là phương án gần nhất và nghe hợp lý, nhưng thiếu getIamPolicy: không đọc được chính sách hiện tại thì mỗi lần ghi là xoá sạch quyền của người khác.

• A (getIamPolicy và setIamPolicy only) — thiếu resourcemanager.projects.get, nên không nhìn thấy hay liệt kê được project.

• B (get only) — chỉ xem, không sửa được gì.

Ghi nhớ

⚠ Ba permission quản lý project — bảng phải thuộc: | Permission | Cho phép | |---|---| | resourcemanager.projects.get | nhìn thấy project, đọc siêu dữ liệu | | resourcemanager.projects.getIamPolicy | đọc chính sách IAM | | resourcemanager.projects.setIamPolicy | GHI chính sách IAM | | Vì sao phải đủ ba | IAM ghi theo chu trình đọc – sửa – ghi |

Từ khoá nhận diện:

"quản lý quyền của project" → ba permission trên, hoặc roles/resourcemanager.projectIamAdmin "tạo project mới" → resourcemanager.projects.create ở cấp folder/organization "xoá project" → resourcemanager.projects.delete "chỉ xem" → roles/viewer "toàn quyền kể cả IAM" → roles/owner

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền gì trên project | gcloud projects get-iam-policy <id> | | Vai trò gồm permission nào | gcloud iam roles describe roles/resourcemanager.projectIamAdmin | | Vì sao ai đó bị từ chối | Policy Troubleshooter |

Và một thói quen rất đáng có trước khi đụng vào IAM của project đang chạy: gcloud projects get-iam-policy <id> > backup.json. Một lệnh set-iam-policy với file sai có thể gỡ quyền của toàn bộ đội trong một giây — và nếu người chạy lệnh cũng mất quyền theo, việc khôi phục sẽ phải nhờ tới organization admin.

Đáp án

A — gcloud iam roles list --project=[PROJECT]

Vì sao đúng

Cấu trúc lệnh của gcloud luôn theo thứ tự nhóm → nhóm con → động từ, và vai trò IAM thuộc nhóm iam.

⚠ Điểm mấu chốt — phân tích từng phần:

gcloud iam roles list --project=[PROJECT]
       │    │     │        │
       │    │     │        └─ giới hạn ở một project
       │    │     └─ ĐỘNG TỪ: liệt kê
       │    └─ NHÓM CON: đối tượng là roles
       └─ NHÓM: dịch vụ IAM
        ↓
    → liệt kê VAI TRÒ TUỲ CHỈNH của project đó

⚠ Điều mà cờ --project thật sự làm:

gcloud iam roles list
        ↓
    KHÔNG có --project
    → liệt kê VAI TRÒ ĐỊNH SẴN (predefined)
      của toàn Google Cloud — hàng nghìn cái

    CÓ --project=[PROJECT]
    → chỉ liệt kê VAI TRÒ TUỲ CHỈNH
      tạo trong project đó

    CÓ --organization=[ORG_ID]
    → vai trò tuỳ chỉnh ở cấp tổ chức

⚠ Vì sao ba phương án kia sai — hai lỗi mẫu:

LỖI 1 — đảo thứ tự động từ và nhóm con
    gcloud iam list roles       ✗
    gcloud iam roles list       ✓
        ↓
    gcloud LUÔN đặt động từ ở CUỐI

LỖI 2 — dùng nhầm công cụ
    gsutil = công cụ cho CLOUD STORAGE
        ↓
    gsutil iam ... chỉ làm việc với
    IAM CỦA BUCKET và OBJECT
        ↓
    → không liệt kê được vai trò của project

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

• B (gcloud iam list roles --project=[PROJECT]) — đây là phương án gần nhất và dùng đúng công cụ, nhưng đảo thứ tự: gcloud luôn đặt động từ ở cuối, phải là roles list.

• C (gsutil iam list roles --project=...) — gsutil là công cụ cho Cloud Storage, gsutil iam chỉ làm việc với chính sách của bucket và object.

• D (gsutil list iam roles [PROJECT]) — sai cả công cụ lẫn cú pháp.

Ghi nhớ

⚠ Các lệnh về vai trò IAM — bảng phải thuộc: | Lệnh | Việc | |---|---| | gcloud iam roles list | liệt kê vai trò ĐỊNH SẴN | | gcloud iam roles list --project=<id> | vai trò TUỲ CHỈNH của project | | gcloud iam roles list --organization=<id> | vai trò tuỳ chỉnh cấp tổ chức | | gcloud iam roles describe <ROLE_ID> | chi tiết một vai trò | | gcloud iam roles create | tạo vai trò tuỳ chỉnh | | gcloud iam roles update / delete / undelete | sửa, xoá, khôi phục | | gcloud iam list-grantable-roles <tài nguyên> | vai trò gắn được vào tài nguyên đó |

Từ khoá nhận diện:

"liệt kê vai trò của một project" → gcloud iam roles list --project= "chi tiết một vai trò" → gcloud iam roles describe "ai có quyền gì" → gcloud projects get-iam-policy — khác hẳn "quyền của bucket" → gcloud storage buckets get-iam-policy "gsutil cho vai trò project" → SAI công cụ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Project có vai trò tuỳ chỉnh nào | gcloud iam roles list --project=<id> | | Vai trò gồm permission nào | gcloud iam roles describe <id> --project=<id> | | Vai trò nào gắn được vào tài nguyên | gcloud iam list-grantable-roles |

Và một điều nên cân nhắc trước khi tạo vai trò tuỳ chỉnh: bạn nhận luôn trách nhiệm bảo trì nó. Khi Google thêm permission mới cho một dịch vụ, vai trò định sẵn tự có; vai trò tuỳ chỉnh thì không, và triệu chứng sẽ là một tính năng mới bỗng báo lỗi quyền mà chẳng ai nhớ ra lý do.