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

Đáp án

B — gcloud iam roles describe [ROLE-ID]

Vì sao đúng

Đồng nghiệp muốn biết chi tiết về vài vai trò định sẵn, và describe chính là động từ của gcloud dành cho việc đó.

⚠ Điểm mấu chốt — list ↔ describe:

gcloud iam roles LIST
        ↓
    → DANH SÁCH nhiều vai trò
    → chỉ tên và mô tả ngắn

gcloud iam roles DESCRIBE <ROLE_ID>
        ↓
    → CHI TIẾT MỘT vai trò:
        title, description,
        includedPermissions  ← danh sách permission đầy đủ
        stage, etag
        ↓
    → đây mới là thứ đồng nghiệp cần

⚠ Ví dụ thật:

gcloud iam roles describe roles/storage.objectViewer
        ↓
    description: Read access to GCS objects.
    includedPermissions:
    - resourcemanager.projects.get
    - resourcemanager.projects.list
    - storage.objects.get
    - storage.objects.list
    name: roles/storage.objectViewer
    stage: GA
    title: Storage Object Viewer

⚠ Vai trò ĐỊNH SẴN không cần cờ --project:

Vai trò ĐỊNH SẴN
    → thuộc về Google Cloud, dùng chung
    → gcloud iam roles describe roles/editor

Vai trò TUỲ CHỈNH
    → thuộc về project hoặc organization
    → gcloud iam roles describe <ID> --project=<id>
        ↓
    Đề hỏi về PREDEFINED role
    → không cần cờ nào thêm

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

• C (gcloud iam roles list [ROLE-ID]) — đây là phương án gần nhất và dùng đúng nhóm lệnh, nhưng list không nhận đối số là một ROLE-ID: nó liệt kê nhiều vai trò chứ không mô tả một cái.

• A và D (gcloud roles predefined describe [ROLE-ID]) — không có nhóm gcloud roles và cũng không có nhóm con predefined. Vai trò nằm trong gcloud iam roles.

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

Phương án A và D của câu này TRÙNG NHAU NGUYÊN VĂN — cả hai đều là gcloud roles predefined describe [ROLE-ID]. Đây là lỗi soạn đề của bộ nguồn, gần như chắc chắn một trong hai vốn phải là một biến thể khác (chẳng hạn gcloud iam predefined-roles describe).

Điều này KHÔNG làm thay đổi khoá đáp án: cả hai phương án trùng nhau đều sai, và B vẫn là câu trả lời đúng duy nhất. Gặp câu kiểu này trong bài thi thật thì cứ chọn phương án đúng và bỏ qua sự trùng lặp — nó không phải cái bẫy, chỉ là lỗi biên tập.

Ghi nhớ

⚠ Bốn động từ tra cứu của gcloud — bảng phải thuộc: | Động từ | Trả về | |---|---| | list | NHIỀU tài nguyên, thông tin tóm tắt | | describe | MỘT tài nguyên, thông tin ĐẦY ĐỦ | | create / update / delete | thay đổi | | Bẫy | list không nhận id của một tài nguyên |

Từ khoá nhận diện:

"chi tiết về một vai trò" → gcloud iam roles describe "có những vai trò nào" → gcloud iam roles list "vai trò này gồm quyền gì" → describe, xem includedPermissions "ai đang giữ vai trò này" → gcloud projects get-iam-policy — câu hỏi khác hẳn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vai trò gồm quyền gì | gcloud iam roles describe <id> --format="value(includedPermissions)" | | Vai trò nào chứa một quyền cụ thể | duyệt list rồi describe, hoặc tra tài liệu | | Vai trò có bị khai tử không | xem trường stage |

Và một mẹo nhỏ khi hướng dẫn người mới: bảo họ chạy describe trên roles/editor một lần. Danh sách permission dài tới mức phải cuộn rất lâu — và đó là cách thuyết phục nhất để họ hiểu vì sao "cứ cấp Editor cho nhanh" là thói quen nên bỏ.

Đáp án

C — gcloud compute images list --project windows-cloud --no-standard-images

Vì sao đúng

Ảnh Windows Server do Google cung cấp nằm trong một project ảnh công khai tên windows-cloud, và lệnh này trỏ đúng vào đó.

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

gcloud compute images list
        ↓
    Nhóm compute, nhóm con images, động từ list

--project windows-cloud
        ↓
    ⚠ Trỏ sang PROJECT ẢNH CÔNG KHAI của Google
    → không phải project của bạn

--no-standard-images
        ↓
    KHÔNG kèm danh sách ảnh chuẩn mặc định
    → chỉ còn đúng ảnh của windows-cloud
    → kết quả gọn, đúng thứ cần xem

⚠ Các project ảnh công khai đáng nhớ:

windows-cloud      → Windows Server
debian-cloud       → Debian
ubuntu-os-cloud    → Ubuntu
rocky-linux-cloud  → Rocky Linux
rhel-cloud         → Red Hat Enterprise Linux
cos-cloud          → Container-Optimized OS
suse-cloud         → SUSE Linux
windows-sql-cloud  → Windows Server + SQL Server

⚠ Dùng ảnh đó để tạo máy:

gcloud compute instances create vm-win \
  --image-family=windows-2022 \
  --image-project=windows-cloud \
  --zone=us-central1-a
        ↓
    ⚠ Dùng --image-family, KHÔNG dùng --image
    → luôn lấy bản MỚI NHẤT của dòng ảnh

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

• D (gcloud compute images describe --project windows-cloud --no-standard-images) — đây là phương án gần nhất, nhưng describe mô tả MỘT ảnh cụ thể và cần tên ảnh làm đối số. Muốn xem danh sách thì phải là list.

• A (gcloud compute list windows-cloud) — đảo thứ tự và thiếu nhóm con. Không có gcloud compute list.

• B (gcloud compute instances describe windows-cloud) — mô tả một INSTANCE, không phải ảnh.

Ghi nhớ

⚠ Lệnh về ảnh của Compute Engine — bảng phải thuộc: | Lệnh | Việc | |---|---| | gcloud compute images list | liệt kê ảnh (kèm ảnh chuẩn) | | gcloud compute images list --project <ảnh-project> --no-standard-images | chỉ ảnh của project đó | | gcloud compute images describe <ten> | chi tiết một ảnh | | gcloud compute images create | tạo ảnh tuỳ chỉnh | | gcloud compute images delete / deprecate | xoá, đánh dấu khai tử | | gcloud compute images add-iam-policy-binding | chia sẻ ảnh cho project khác |

Từ khoá nhận diện:

"xem danh sách ảnh Windows" → images list --project windows-cloud "chi tiết một ảnh" → images describe "tạo VM từ ảnh mới nhất" → --image-family + --image-project "ghim đúng một bản ảnh" → --image "xem instance" → instances describe — đối tượng khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những dòng ảnh Windows nào | gcloud compute images list --project windows-cloud --no-standard-images | | Ảnh đó đã khai tử chưa | images describe → trường deprecated | | VM đang chạy ảnh nào | gcloud compute instances describe <vm> --format="value(disks[0].licenses)" |

Và một điều cần tính trước khi chốt Windows trên Compute Engine: phí giấy phép theo giờ cộng vào giá máy và tính theo số vCPU. Với khối lượng công việc lớn, phần giấy phép có thể vượt cả phần tính toán — nên nếu ứng dụng chạy được trên .NET Core, cân nhắc Linux là bài toán kinh tế đáng làm chứ không chỉ là sở thích kỹ thuật.

Đáp án

A — Image families (dòng ảnh).

Vì sao đúng

Đề nêu đúng hai yêu cầu mà image family sinh ra để giải: phát hành phiên bản mới và quay lui về bản trước khi cần.

⚠ Điểm mấu chốt — family luôn trỏ tới bản mới nhất chưa khai tử:

Image family: app-base
        ↓
    app-base-v1  (deprecated)
    app-base-v2  (deprecated)
    app-base-v3  ← family trỏ vào đây
        ↓
    --image-family=app-base
    → luôn lấy v3

⚠ Và quay lui chỉ là một lệnh deprecate:

v3 có lỗi
        ↓
    gcloud compute images deprecate app-base-v3 \
      --state=DEPRECATED \
      --replacement=app-base-v2
        ↓
    → family tự trỏ về v2
    → máy tạo mới dùng lại bản cũ
        ↓
    ⚠ QUAY LUI TỨC THÌ, không phải dựng lại ảnh

⚠ Bốn trạng thái vòng đời của ảnh:

ACTIVE      → dùng bình thường, family có thể trỏ tới
DEPRECATED  → vẫn tạo VM được, có cảnh báo
               family KHÔNG còn trỏ tới
OBSOLETE    → KHÔNG tạo VM mới được nữa
DELETED     → đánh dấu đã xoá
        ↓
    Quay lui = deprecate bản mới,
    để bản cũ ở ACTIVE

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

• B (Managed instance groups) — đây là phương án gần nhất vì MIG cũng có rolling update và rollback, nhưng nó quản lý các INSTANCE đang chạy, không quản lý phiên bản của ẢNH. Trong thực tế hai thứ dùng chung nhau, nhưng thứ trả lời đúng câu hỏi về ảnh là image family.

• C (Unmanaged instance groups) — chỉ là tập hợp VM tuỳ ý, không có khái niệm phiên bản, không tự cập nhật.

• D (Community supported images) — ảnh do cộng đồng đóng góp, không phải cơ chế quản lý phiên bản.

Ghi nhớ

⚠ Image family — bảng phải thuộc: | Điểm | Nội dung | |---|---| | Family trỏ tới | ảnh MỚI NHẤT chưa bị deprecate | | Tạo VM | --image-family=<dòng> --image-project=<project> | | Phát hành bản mới | tạo ảnh mới cùng --family | | Quay lui | images deprecate <bản mới> --replacement=<bản cũ> | | Không cần | sửa script hay template — chúng trỏ vào family |

Từ khoá nhận diện:

"phát hành phiên bản ảnh và quay lui được" → image family "luôn dùng ảnh mới nhất" → --image-family "cập nhật dần các VM đang chạy" → MIG rolling update "khuôn cấu hình VM" → instance template "bản sao lưu đĩa" → snapshot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Family đang trỏ vào ảnh nào | gcloud compute images describe-from-family <dòng> --project=<id> | | Ảnh đã deprecate chưa | images describe <ten> → trường deprecated | | MIG đang dùng template nào | gcloud compute instance-groups managed describe <ten> |

Và một thói quen giúp quay lui thật sự nhanh khi có sự cố: đừng xoá ảnh cũ ngay sau khi phát hành bản mới. Giữ ít nhất hai ba bản trước ở trạng thái ACTIVE hoặc DEPRECATED — chi phí lưu ảnh rất nhỏ so với việc phải dựng lại một ảnh cũ vào lúc hệ thống đang hỏng.

Đáp án

A — Instance template (khuôn máy ảo).

Vì sao đúng

Đề hỏi thứ dùng để đặc tả cấu hình: tạo được nhiều máy giống hệt nhau, và dễ thay đổi. Đó đúng là định nghĩa của instance template.

⚠ Điểm mấu chốt — template là bản khai cấu hình VM:

Instance template chứa:
    machine type (e2-standard-4)
    boot image / image family
    kích thước và loại đĩa
    mạng, subnet, IP
    network tag, label
    service account và scope
    startup script, metadata
        ↓
    Tạo VM từ template
    → mọi máy CẤU HÌNH GIỐNG HỆT

⚠ "Dễ thay đổi" — cách làm đúng:

⚠ Template là BẤT BIẾN — không sửa được
        ↓
    Đổi cấu hình = TẠO TEMPLATE MỚI
        ↓
    gcloud compute instance-templates create app-v2 \
      --source-instance-template=app-v1 \
      --configure-disk=...
        ↓
    → giữ nguyên bản cũ để QUAY LUI
    → đó chính là cái làm nó "dễ thay đổi"

⚠ Vì sao bất biến lại là ưu điểm:

Template không đổi được
        ↓
    → mọi VM tạo từ nó CHẮC CHẮN giống nhau
    → không có chuyện "máy này khác vì
      template bị sửa giữa chừng"
        ↓
    → MIG biết chính xác máy nào
      thuộc phiên bản nào
        ↓
    → rolling update và rollback làm được

Xem thêm câu #12576 (cùng lô): cùng bộ phương án, nhưng ở đó yêu cầu là cụm co giãn và chịu được lỗi zone → đáp án là managed instance group. Quy tắc phân biệt: template là KHUÔN cấu hình; MIG là CỤM MÁY dùng khuôn đó.

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

• B (Managed instance groups) — đây là phương án gần nhất và luôn đi cùng template, nhưng MIG là thứ VẬN HÀNH cụm máy (co giãn, tự chữa, cập nhật dần); thứ đặc tả cấu hình vẫn là template. MIG bắt buộc phải có một template mới hoạt động được.

• C (Unmanaged instance groups) — chỉ là tập hợp VM tuỳ ý, mỗi máy một cấu hình khác nhau cũng được. Không có khuôn.

• D (Snapshot) — bản sao lưu nội dung đĩa, không mô tả loại máy, mạng hay service account.

Ghi nhớ

⚠ Bốn khái niệm hay lẫn — bảng phải thuộc: | Khái niệm | Là gì | |---|---| | Instance template | KHUÔN cấu hình VM — bất biến | | Managed instance group | CỤM máy dùng template, co giãn, tự chữa | | Unmanaged instance group | tập hợp VM tuỳ ý — không có khuôn | | Snapshot | bản sao lưu ĐĨA | | Image | khuôn để tạo ĐĨA khởi động |

Từ khoá nhận diện:

"cấu hình giống hệt nhau, dễ đổi" → instance template "co giãn, tự chữa, nhiều zone" → managed instance group "sao lưu dữ liệu đĩa" → snapshot "phiên bản hệ điều hành, phần mềm cài sẵn" → image / image family "gom vài máy có sẵn sau load balancer" → unmanaged instance group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Template có gì | gcloud compute instance-templates describe <ten> | | MIG đang dùng template nào | gcloud compute instance-groups managed describe <ten> | | Máy nào còn ở phiên bản cũ | ... managed list-instances <ten> → cột INSTANCE_TEMPLATE |

Và một quy ước đặt tên đáng có ngay từ template đầu tiên: gắn số phiên bản vào tên (app-v1, app-v2). Template không sửa được, nên số lượng của chúng chỉ tăng — và một danh sách hai chục template tên na ná nhau, không biết cái nào đang phục vụ, là thứ khiến việc quay lui lúc nửa đêm trở nên đáng sợ hơn mức cần thiết.

Đáp án

B — Managed instance groups (nhóm máy ảo được quản lý).

Vì sao đúng

Đề nêu hai yêu cầu, và MIG là tính năng duy nhất trong bốn phương án đáp ứng được cả hai: co giãn lên xuống theo nhu cầu, và chịu được sự cố của một zone.

⚠ Điểm mấu chốt — MIG làm bốn việc mà nhóm thường không làm:

1. TỰ ĐỘNG CO GIÃN (autoscaling)
    → thêm bớt máy theo CPU, tải cân bằng,
      chỉ số tuỳ chỉnh, hoặc lịch

2. TỰ CHỮA (autohealing)
    → health check hỏng → TẠO LẠI máy

3. PHÂN BỔ NHIỀU ZONE (regional MIG)
    → trải máy qua 3 zone của một Region
    → MẤT MỘT ZONE vẫn còn máy phục vụ

4. CẬP NHẬT DẦN (rolling update)
    → đổi phiên bản không ngừng dịch vụ

⚠ Regional MIG — chính là phần "chịu lỗi zone":

gcloud compute instance-groups managed create app \
  --region=us-central1 \
  --size=6 \
  --template=app-v1
        ↓
    6 máy trải đều 3 zone: 2 + 2 + 2
        ↓
    us-central1-a chết
        ↓
    → còn 4 máy phục vụ
    → MIG tạo bù ở hai zone còn sống

⚠ Zonal MIG ↔ Regional MIG:

ZONAL MIG  (--zone=)
    → toàn bộ máy trong MỘT zone
    → zone chết = MẤT HẾT
    → chỉ hợp với dev/test

REGIONAL MIG  (--region=)     ← đề này
    → trải qua NHIỀU ZONE
    → khuyến nghị cho production
    → mặc định phân bổ ĐỀU

Xem thêm câu #12575 (cùng lô): cùng bộ phương án nhưng hỏi về KHUÔN cấu hình → đáp án là instance template. Hai câu bổ sung cho nhau: MIG cần template mới chạy được, còn template một mình thì không co giãn hay tự chữa gì cả.

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

• A (Unmanaged instance groups) — đây là phương án dễ nhầm nhất, nhưng nhóm không được quản lý KHÔNG có autoscaling, KHÔNG có autohealing, KHÔNG trải zone. Nó chỉ là một danh sách VM để load balancer nhắm tới.

• C (Instance templates) — là khuôn cấu hình, bản thân nó không tạo, không co giãn, không chữa máy nào.

• D (Snapshot) — bản sao lưu đĩa, không liên quan tới tính sẵn sàng hay co giãn.

Ghi nhớ

⚠ MIG ↔ nhóm không được quản lý — bảng phải thuộc: | | Managed (MIG) | Unmanaged | |---|---|---| | Cấu hình máy | từ instance template, giống hệt nhau | tuỳ ý, mỗi máy một kiểu | | Autoscaling | CÓ | KHÔNG | | Autohealing | CÓ | KHÔNG | | Nhiều zone | CÓ (regional MIG) | KHÔNG — một zone | | Rolling update | CÓ | KHÔNG | | Dùng khi | hầu hết mọi trường hợp | máy có sẵn, cấu hình khác nhau |

Từ khoá nhận diện:

"co giãn + chịu lỗi zone" → regional managed instance group "tự tạo lại máy hỏng" → autohealing của MIG "gom vài máy khác nhau sau LB" → unmanaged instance group "khuôn cấu hình" → instance template "chịu lỗi cả REGION" → nhiều MIG ở nhiều Region + global LB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | MIG trải mấy zone | gcloud compute instance-groups managed describe <ten> → distributionPolicy | | Máy nào không khoẻ | ... managed list-instances <ten> → cột HEALTH_STATE | | Autoscaler đang quyết định gì | gcloud compute instance-groups managed describe-autoscaler, và log |

Và một cấu hình rất nên đặt đúng ngay từ đầu: --initial-delay của autohealing phải dài hơn thời gian khởi động thật của ứng dụng. Đặt quá ngắn thì MIG kết luận máy hỏng khi nó còn đang khởi động, tạo lại, rồi lặp mãi — cụm không bao giờ ổn định, và triệu chứng nhìn giống hệt một lỗi ứng dụng.

Đáp án

B — Sole-tenant nodes (máy chủ vật lý dành riêng).

Vì sao đúng

Yêu cầu của khách hàng là chỉ ứng dụng của chính project họ được chạy trên cùng máy chủ vật lý — tức là loại bỏ hoàn toàn việc dùng chung phần cứng với người thuê khác. Đó chính xác là điều sole-tenant node cung cấp.

⚠ Điểm mấu chốt — máy chủ vật lý dành riêng cho một khách hàng:

Compute Engine THÔNG THƯỜNG
        ↓
    Một máy chủ vật lý chạy VM
    của NHIỀU khách hàng khác nhau
    (đã cách ly bằng ảo hoá)

SOLE-TENANT NODE
        ↓
    Máy chủ vật lý CHỈ chạy VM
    của DUY NHẤT project bạn
        ↓
    → không chia sẻ phần cứng
      với bất kỳ ai khác

⚠ Ba lý do thật sự để dùng:

1. TUÂN THỦ
    → quy định ngành yêu cầu
      cách ly vật lý

2. GIẤY PHÉP PHẦN MỀM (BYOL)
    → Windows Server, SQL Server,
      Oracle tính phí theo CORE VẬT LÝ
    → biết rõ máy chủ nào
      = mang giấy phép riêng sang được

3. HIỆU NĂNG ỔN ĐỊNH
    → không có "hàng xóm ồn ào"

⚠ Cách triển khai:

gcloud compute sole-tenancy node-templates create tpl \
  --node-type=n2-node-80-640 --region=us-central1

gcloud compute sole-tenancy node-groups create grp \
  --node-template=tpl --target-size=1 --zone=us-central1-a

gcloud compute instances create vm1 \
  --node-group=grp --zone=us-central1-a
        ↓
    ⚠ Trả tiền cho CẢ NODE, không phải
      theo từng VM → đắt hơn đáng kể

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

• A (Shielded VM) — đây là phương án dễ nhầm nhất vì cũng thuộc nhóm bảo mật, nhưng nó bảo vệ VM khỏi rootkit và bootkit bằng Secure Boot, vTPM, Integrity Monitoring. Nó không ảnh hưởng gì tới việc ai dùng chung máy chủ vật lý.

• C (Managed instance groups) — về co giãn và tự chữa, không liên quan tới cách ly phần cứng.

• D (Preemptible VM) — máy giá rẻ có thể bị thu hồi bất cứ lúc nào, hoàn toàn ngược với yêu cầu.

Ghi nhớ

⚠ Các tính năng bảo mật của Compute Engine — bảng phải thuộc: | Tính năng | Bảo vệ điều gì | |---|---| | Sole-tenant node | CÁCH LY PHẦN CỨNG — không dùng chung máy chủ | | Shielded VM | chống rootkit/bootkit: Secure Boot, vTPM, Integrity Monitoring | | Confidential VM | MÃ HOÁ BỘ NHỚ khi đang dùng (AMD SEV) | | CMEK | tự quản khoá mã hoá đĩa | | OS Login | quản lý SSH bằng IAM | | Private Google Access | VM không cần IP công khai |

Từ khoá nhận diện:

"không dùng chung máy chủ vật lý" → sole-tenant node "mang giấy phép Windows/Oracle sang (BYOL)" → sole-tenant node "chống phần mềm độc hại mức khởi động" → Shielded VM "dữ liệu mã hoá kể cả khi đang xử lý" → Confidential VM "máy giá rẻ, chịu được gián đoạn" → Spot VM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM có nằm trên node riêng không | gcloud compute instances describe <vm> → scheduling.nodeAffinities | | Node group còn chỗ không | gcloud compute sole-tenancy node-groups list-nodes <ten> | | Chi phí thực tế | billing export, lọc theo SKU sole-tenancy |

Và một điều nên tính kỹ trước khi chốt: bạn trả tiền cho cả node dù chỉ chạy một VM nhỏ trên đó. Sole-tenant chỉ kinh tế khi bạn lấp gần đầy node bằng khối lượng công việc thật, hoặc khi phần giấy phép phần mềm tiết kiệm được lớn hơn phần chênh lệch — nếu lý do chỉ là "cho yên tâm", thì đó là một hoá đơn khá đắt cho sự yên tâm.

Đáp án

C — Policy Denied Audit Log.

Vì sao đúng

Triệu chứng trong đề là ứng dụng chạy bằng service account không hoạt động đúng, nghi ngờ do quyền truy cập. Loại log ghi lại những yêu cầu bị chính sách TỪ CHỐI chính là Policy Denied.

⚠ Điểm mấu chốt — mỗi loại log trả lời một câu hỏi khác nhau:

"Ai đã THAY ĐỔI cấu hình?"
    → Admin Activity

"Ai đã ĐỌC/GHI dữ liệu?"
    → Data Access

"Yêu cầu nào BỊ TỪ CHỐI, và vì sao?"
    → POLICY DENIED           ← đề này

"Google đã làm gì với tài nguyên của tôi?"
    → System Event

⚠ Policy Denied log ghi gì:

Bản ghi chứa:
    principalEmail   ← service account nào bị từ chối
    methodName       ← đang gọi API nào
    resourceName     ← trên tài nguyên nào
    status.message   ← lý do từ chối
    violationInfo    ← chính sách nào chặn
        ↓
    → đúng bốn thứ cần để chẩn đoán
      lỗi phân quyền

⚠ Tra bằng Logs Explorer:

logName:"cloudaudit.googleapis.com%2Fpolicy"
protoPayload.authenticationInfo.principalEmail=
  "app-sa@project.iam.gserviceaccount.com"
        ↓
    → thấy ngay service account đang thiếu
      quyền gì trên tài nguyên nào

⚠ Lưu ý: không phải mọi lỗi 403 đều vào Policy Denied log:

Policy Denied log ghi các yêu cầu bị chặn bởi
    VPC Service Controls
    Organization Policy / IAM Deny policy
        ↓
    Còn lỗi 403 do THIẾU VAI TRÒ IAM thông thường
    thì tra bằng
        → POLICY TROUBLESHOOTER
        → gcloud projects get-iam-policy
        ↓
    Trong bốn phương án của đề, Policy Denied
    vẫn là loại log duy nhất dành cho việc
    "yêu cầu bị từ chối"

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

• A (Admin Activity) — đây là phương án dễ chọn nhầm vì nó luôn bật, nhưng nó ghi các thay đổi cấu hình THÀNH CÔNG, không ghi việc bị từ chối.

• B (Data Access) — ghi các thao tác đọc và ghi dữ liệu, và mặc định TẮT — nhiều khả năng còn không có dữ liệu để xem.

• D (Identity Access Audit Log) — không tồn tại loại log này. Đây là tên bịa.

Ghi nhớ

⚠ Bốn loại audit log và câu hỏi tương ứng — bảng phải thuộc: | Loại | Trả lời câu hỏi | |---|---| | Admin Activity | ai đã thay đổi cấu hình | | Data Access | ai đã đọc/ghi dữ liệu | | Policy Denied | yêu cầu nào BỊ TỪ CHỐI | | System Event | Google đã làm gì | | "Identity Access Audit Log" | KHÔNG TỒN TẠI — tên bịa hay gặp trong đề |

Từ khoá nhận diện:

"nghi ngờ lỗi phân quyền, xem log nào" → Policy Denied "ai đã sửa cấu hình" → Admin Activity "ai đã đọc dữ liệu" → Data Access "vì sao người này bị 403" → Policy Troubleshooter — công cụ, không phải log "quyền nào thừa" → Recommender

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có yêu cầu nào bị chặn không | Logs Explorer, lọc logName:".../policy" | | SA có vai trò gì | gcloud projects get-iam-policy <id> --flatten="bindings[].members" --filter="bindings.members:<sa>" | | Vì sao bị từ chối | Policy Troubleshooter |

Và một mẹo tiết kiệm rất nhiều thời gian khi gỡ lỗi quyền: kiểm tra scope của VM trước khi nghi ngờ IAM. Một service account có đủ vai trò nhưng chạy trên VM tạo với scope mặc định hẹp vẫn nhận 403, và thông báo lỗi trông y hệt như thiếu quyền IAM — đó là cái bẫy khiến người ta cấp thêm vai trò mãi mà vẫn không hết lỗi.

Đáp án

B — add-iam-policy-binding với hai cờ --member và --role.

Vì sao đúng

Một binding trong IAM là cặp "ai" + "vai trò gì", nên lệnh thêm binding phải nhận đúng hai thông tin đó.

⚠ Điểm mấu chốt — cú pháp chuẩn:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:an@congty.com" \
  --role="roles/storage.objectViewer"
        ↓
    --member : AI          (bắt buộc)
    --role   : VAI TRÒ GÌ  (bắt buộc)
        ↓
    Thiếu một trong hai → lệnh báo lỗi

⚠ add-iam-policy-binding ↔ set-iam-policy — khác biệt sống còn:

add-iam-policy-binding
        ↓
    1. Đọc chính sách hiện tại (getIamPolicy)
    2. THÊM một binding
    3. Ghi lại kèm ETAG
        ↓
    → AN TOÀN: không đụng binding của người khác

set-iam-policy <file.json>
        ↓
    GHI ĐÈ TOÀN BỘ chính sách bằng nội dung file
        ↓
    ⚠ Không có --member/--role — nó nhận FILE
    ⚠ Sai file = XOÁ SẠCH quyền của mọi người

⚠ Tiền tố của --member — phải viết đúng:

user:an@congty.com
serviceAccount:sa@project.iam.gserviceaccount.com
group:doi-dev@congty.com
domain:congty.com
allAuthenticatedUsers      ← cẩn thận
allUsers                   ← CÔNG KHAI, rất cẩn thận
principalSet://...         ← Workload Identity Federation
        ↓
    ⚠ Thiếu tiền tố → lệnh báo lỗi

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

• C (set-iam-policy với --member và --role) — đây là phương án gần nhất, nhưng set-iam-policy KHÔNG nhận hai cờ đó: nó nhận một file JSON/YAML chứa toàn bộ chính sách và ghi đè tất cả.

• A (add-iam-policy-binding không cờ) — thiếu cả hai thông tin bắt buộc; lệnh không biết cấp gì cho ai.

• D (set-iam-policy không cờ) — sai cả lệnh lẫn cách dùng.

Ghi nhớ

⚠ Bốn lệnh IAM — bảng phải thuộc: | Lệnh | Việc | An toàn? | |---|---|---| | add-iam-policy-binding --member --role | THÊM một binding | AN TOÀN | | remove-iam-policy-binding --member --role | BỚT một binding | AN TOÀN | | get-iam-policy | đọc chính sách | an toàn | | set-iam-policy <file> | GHI ĐÈ TOÀN BỘ | NGUY HIỂM |

Từ khoá nhận diện:

"cấp một vai trò cho một người" → add-iam-policy-binding --member --role "thu hồi một vai trò" → remove-iam-policy-binding "khôi phục toàn bộ chính sách từ bản sao lưu" → set-iam-policy "xem ai có quyền gì" → get-iam-policy "vai trò gồm quyền gì" → gcloud iam roles describe

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Binding đã vào chưa | gcloud projects get-iam-policy <id> | | Một người có quyền gì | get-iam-policy --flatten="bindings[].members" --filter="bindings.members:<email>" | | Vì sao vẫn bị từ chối | Policy Troubleshooter |

Và một thói quen nên có trước mọi lần đụng vào IAM của môi trường thật: xuất chính sách hiện tại ra file trước (get-iam-policy > backup.json). add-iam-policy-binding thì an toàn, nhưng ngày nào đó bạn sẽ cần set-iam-policy để khôi phục — và lúc ấy có sẵn bản chụp là khác biệt giữa năm phút và cả buổi chiều.

Đáp án

D — gcloud compute project-info describe --project [PROJECT ID]

Vì sao đúng

Region và zone mặc định là siêu dữ liệu của project trong dịch vụ Compute Engine, nên lệnh phải nằm trong nhóm compute.

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

gcloud compute project-info describe --project [ID]
       │       │            │
       │       │            └─ ĐỘNG TỪ: mô tả
       │       └─ NHÓM CON: thông tin project
       └─ NHÓM: compute — vì region/zone
          là khái niệm của Compute Engine
        ↓
    Kết quả có:
      commonInstanceMetadata:
        items:
        - key: google-compute-default-region
          value: us-central1
        - key: google-compute-default-zone
          value: us-central1-a

⚠ Còn một cách nữa cho cấu hình PHÍA CLIENT:

gcloud config list
        ↓
    [compute]
    region = us-central1
    zone = us-central1-a
        ↓
    ⚠ Đây là mặc định của MÁY BẠN (gcloud CLI)
    ⚠ Còn project-info describe cho mặc định
      lưu ở PHÍA PROJECT
        ↓
    Hai thứ khác nhau — đề hỏi cái của PROJECT

⚠ Đặt lại giá trị:

Ở phía project:
  gcloud compute project-info add-metadata \
    --metadata google-compute-default-region=asia-southeast1,\
google-compute-default-zone=asia-southeast1-a

Ở phía client:
  gcloud config set compute/region asia-southeast1
  gcloud config set compute/zone asia-southeast1-a

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

• C (gcloud project-info describe --project [ID]) — đây là phương án gần nhất và chỉ thiếu đúng chữ compute. Không có nhóm gcloud project-info ở cấp cao nhất.

• A (gcloud project info describe) — viết project info tách rời thay vì project-info, và cũng thiếu nhóm compute.

• B (gcloud project info list) — sai cả cấu trúc lẫn động từ.

Ghi nhớ

⚠ Ba tầng "mặc định" hay lẫn nhau — bảng phải thuộc: | Tầng | Xem bằng | Đặt bằng | |---|---|---| | Của PROJECT (metadata) | gcloud compute project-info describe | gcloud compute project-info add-metadata | | Của gcloud CLI trên máy bạn | gcloud config list | gcloud config set compute/zone | | Của một lệnh cụ thể | — | cờ --zone / --region | | Thứ tự ưu tiên | cờ → config của CLI → metadata của project |

Từ khoá nhận diện:

"region/zone mặc định của PROJECT" → gcloud compute project-info describe "mặc định trên máy tôi" → gcloud config list "đặt zone mặc định" → gcloud config set compute/zone "thông tin chung của project" → gcloud projects describe — khác, không có region/zone "hạn mức (quota)" → cũng nằm trong compute project-info describe

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mặc định của project | gcloud compute project-info describe --project <id> | | Mặc định của CLI | gcloud config list | | VM thật đang ở đâu | gcloud compute instances list → cột ZONE |

Và một quy tắc đáng áp dụng cho mọi script chạm vào Compute Engine: ghi --zone và --region tường minh, đừng bao giờ dựa vào mặc định. Mặc định nằm ở ba tầng khác nhau và có thể bị đổi bởi bất kỳ ai chạm vào máy hoặc project — còn một máy ảo dựng nhầm châu lục thì vừa tốn tiền truyền dữ liệu vừa mất thời gian dọn.

Đáp án

C — Guest attributes (thuộc tính khách).

Vì sao đúng

SSH host key là thông tin do chính hệ điều hành bên trong VM sinh ra, và guest attributes là loại metadata duy nhất cho phép VM GHI NGƯỢC thông tin ra ngoài.

⚠ Điểm mấu chốt — metadata thường CHỈ ĐỌC, guest attributes thì GHI ĐƯỢC:

METADATA THÔNG THƯỜNG
        ↓
    Bạn đặt từ bên ngoài
    VM chỉ ĐỌC
        ↓
    → không dùng để VM báo cáo
      thông tin của chính nó

GUEST ATTRIBUTES
        ↓
    VM GHI VÀO từ bên trong
    Bên ngoài đọc ra
        ↓
    → đúng cho SSH host key

⚠ Vì sao lưu host key lại cải thiện bảo mật:

Không lưu host key
        ↓
    Lần đầu SSH:
      "The authenticity of host ... can't be
       established. Are you sure?"
        ↓
    → người dùng bấm "yes" theo phản xạ
    → mở cửa cho tấn công
      NGƯỜI ĐỨNG GIỮA

Có host key trong guest attributes
        ↓
    gcloud compute ssh ĐỌC host key từ
    metadata server và XÁC MINH
        ↓
    → không còn câu hỏi mù mờ
    → phát hiện được máy chủ giả mạo

⚠ Bật và tra:

Bật (lúc tạo hoặc trên VM đang có):
  gcloud compute instances create vm1 \
    --metadata=enable-guest-attributes=TRUE

Đọc từ ngoài:
  gcloud compute instances get-guest-attributes vm1 \
    --query-path=hostkeys/ --zone=us-central1-a

Bên trong VM ghi:
  curl -X PUT --data "gia-tri" \
    -H "Metadata-Flavor: Google" \
    "http://metadata.google.internal/computeMetadata/v1/\
instance/guest-attributes/khong-gian/khoa"

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

• A (Shielded VM) — đây là phương án dễ nhầm nhất vì cũng là tính năng bảo mật, nhưng nó bảo vệ quá trình khởi động bằng Secure Boot, vTPM và Integrity Monitoring. Nó không lưu trữ SSH host key.

• B (Sole-tenant nodes) — về cách ly phần cứng, không liên quan.

• D (Labels) — chỉ để tổ chức và phân tích chi phí, không phải kênh dữ liệu từ trong VM ra.

Ghi nhớ

⚠ Ba loại metadata của VM — bảng phải thuộc: | Loại | Ai ghi | Dùng để | |---|---|---| | Metadata thường (custom) | bên ngoài đặt | truyền cấu hình, startup script | | Guest attributes | VM GHI TỪ BÊN TRONG | báo trạng thái ra ngoài, SSH host key | | Metadata mặc định | Google | token, tên máy, zone, project | | Mặc định | guest attributes TẮT — phải bật |

Từ khoá nhận diện:

"lưu SSH host key" → guest attributes "VM báo trạng thái ra ngoài" → guest attributes "truyền cấu hình vào VM" → metadata thường "chống rootkit lúc khởi động" → Shielded VM "quản lý SSH bằng IAM" → OS Login

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Guest attributes đã bật chưa | gcloud compute instances describe <vm> --format="value(metadata)" | | Host key hiện tại | gcloud compute instances get-guest-attributes <vm> --query-path=hostkeys/ | | OS Login đã bật chưa | xem metadata enable-oslogin ở cấp project hoặc VM |

Và một cấu hình đáng đặt ở cấp project ngay từ đầu: enable-oslogin=TRUE. Nó chuyển toàn bộ việc cấp và thu hồi quyền SSH sang IAM, nên khi một người rời đội, gỡ họ khỏi group là đủ — không phải đi lục metadata của từng máy để xoá khoá công khai còn sót lại.