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

Đáp án

A — kubectl autoscale deployment my-app-rc --min=2 --max=6 --cpu-percent=80

Vì sao đúng

Đây là lệnh tạo Horizontal Pod Autoscaler (HPA) — đúng công cụ cho việc co giãn số pod theo CPU.

⚠ Điểm mấu chốt — kubectl quản lý bên trong cụm, gcloud quản lý chính cụm:

gcloud container clusters ...
        ↓
    Tạo, xoá, nâng cấp CỤM
    Quản node pool
        ↓
kubectl ...
        ↓
    Quản lý TÀI NGUYÊN BÊN TRONG cụm:
      pod, deployment, service, HPA, configmap…
        ↓
    → co giãn pod là việc BÊN TRONG cụm
    → phải dùng kubectl

⚠ Cú pháp lệnh khớp đúng ba tham số của đề:

kubectl autoscale deployment my-app-rc \
  --min=2 --max=6 --cpu-percent=80
        ↓
    --min=2         → không bao giờ dưới 2 pod
    --max=6         → không bao giờ trên 6 pod
    --cpu-percent=80 → mục tiêu CPU trung bình 80%
        ↓
    → tạo ra một đối tượng HorizontalPodAutoscaler

⚠ Một điều kiện bắt buộc để HPA hoạt động:

HPA tính phần trăm CPU SO VỚI `requests`
        ↓
    Container KHÔNG khai resources.requests.cpu
        ↓
    → HPA không có mẫu số để tính
    → chỉ số hiện <unknown>
    → autoscaler KHÔNG hoạt động
        ↓
    → luôn phải đặt `requests` cho container

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

• B (kubectl apply deployment ...) — đây là phương án gần nhất vì dùng đúng công cụ kubectl, nhưng apply dùng để áp một tệp manifest (kubectl apply -f tep.yaml), không nhận các cờ --min, --max, --cpu-percent.

• C và D (gcloud containers ...) — sai hai lần: nhóm lệnh đúng là gcloud container (số ít), và gcloud không quản lý HPA — đó là tài nguyên bên trong cụm.

Ghi nhớ

⚠ gcloud ↔ kubectl — bảng phải thuộc: | Công cụ | Quản lý gì | |---|---| | gcloud container clusters | tạo, xoá, nâng cấp CỤM; node pool | | kubectl | pod, deployment, service, HPA, ingress — BÊN TRONG cụm | | Lấy thông tin đăng nhập | gcloud container clusters get-credentials <ten> | | Bẫy | gcloud không tạo được HPA, deployment hay service |

Từ khoá nhận diện:

"co giãn số POD theo CPU" → kubectl autoscale (HPA) "thêm NODE khi pod Pending" → Cluster Autoscaler "chỉnh CPU/RAM cho mỗi pod" → VPA "tạo hoặc nâng cấp cụm" → gcloud container clusters "kết nối kubectl với cụm" → get-credentials

Ba việc kiểm chứng: | Việc | Cách | |---|---| | HPA có hoạt động không | kubectl get hpa — xem cột TARGETS và REPLICAS | | Vì sao không co giãn | kubectl describe hpa <ten> — đọc phần Events | | Pod dùng bao nhiêu tài nguyên | kubectl top pods |

Và một nguyên nhân chiếm phần lớn các ca "HPA không hoạt động": container quên khai resources.requests.cpu. Khi đó kubectl get hpa hiện <unknown> ở cột TARGETS, autoscaler không có mẫu số để tính phần trăm, và số pod nằm im mãi ở mức tối thiểu — một triệu chứng rất dễ bị đổ nhầm cho cấu hình HPA thay vì cho manifest của chính deployment.

Đáp án

B — gcloud datastore export gs://my-datastore-backup --async

Vì sao đúng

Đề đòi hai thứ: sao lưu ra Cloud Storage, và lệnh trả về ngay trong khi việc chạy nền.

⚠ Điểm mấu chốt — động từ là EXPORT, không phải backup:

Datastore / Firestore
        ↓
    Không có lệnh "backup"
        ↓
    Cơ chế sao lưu là XUẤT DỮ LIỆU (export)
    ra một bucket Cloud Storage
        ↓
    gcloud datastore export gs://bucket
        ↓
    Và khôi phục bằng:
      gcloud datastore import gs://bucket/...

⚠ Và --async là phần thứ hai của yêu cầu:

Không có --async
        ↓
    Lệnh CHỜ tới khi export xong
    → với dữ liệu lớn có thể mất hàng giờ
        ↓
Có --async
        ↓
    Lệnh trả về NGAY, kèm một OPERATION ID
        ↓
    → theo dõi bằng:
      gcloud datastore operations list
      gcloud datastore operations describe <id>
        ↓
    → đúng yêu cầu "trả về ngay, chạy nền"

⚠ Cờ --async là mẫu chung của gcloud:

Rất nhiều lệnh gcloud chạy lâu đều có --async
        ↓
    gcloud compute instances create --async
    gcloud container clusters create --async
    gcloud sql backups create --async
        ↓
    → trả về operation, theo dõi riêng
    → rất hữu ích trong script và CI/CD

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

• D (gcloud datastore export gs://my-datastore-backup) — đây là phương án gần nhất và lệnh hoàn toàn đúng, nhưng thiếu --async: nó sẽ chờ cho tới khi export xong, trái với yêu cầu "trả về ngay".

• A (gcloud datastore backup ...) — không có động từ backup trong nhóm gcloud datastore.

• C (gsutil datastore export ...) — sai công cụ: gsutil chỉ làm việc với Cloud Storage, không quản lý Datastore.

Ghi nhớ

⚠ Sao lưu và khôi phục Datastore/Firestore — bảng phải thuộc: | Việc | Lệnh | |---|---| | Sao lưu | gcloud datastore export gs://bucket | | Khôi phục | gcloud datastore import gs://bucket/<duong-dan> | | Chạy nền | --async | | Theo dõi | gcloud datastore operations list / describe | | Xuất một phần | --kinds và --namespaces | | Bucket | nên CÙNG Region với database để tránh phí và độ trễ |

Từ khoá nhận diện:

"sao lưu Datastore/Firestore" → export ra Cloud Storage "lệnh trả về ngay" → --async "theo dõi việc đang chạy nền" → operations list / describe "gsutil quản lý dịch vụ khác" → luôn SAI — gsutil chỉ cho Cloud Storage "khôi phục về thời điểm" → Firestore PITR (7 ngày), Datastore mode không có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Export xong chưa | gcloud datastore operations list | | Bản xuất nằm ở đâu | gcloud storage ls gs://my-datastore-backup | | Import có chạy được không | thử import vào một project THỬ NGHIỆM |

Và một việc rất nên làm định kỳ với mọi cơ chế sao lưu, không riêng Datastore: thử khôi phục thật vào một project thử nghiệm. Một bản xuất tồn tại trong bucket không chứng minh được điều gì cho tới khi bạn nạp nó trở lại thành công — và thời điểm để phát hiện bản xuất bị hỏng chắc chắn không phải là lúc dữ liệu thật đã mất.

Đáp án

A — gcloud artifacts repositories list

Vì sao đúng

Câu này kiểm tra cấu trúc lệnh gcloud và tên dịch vụ đúng.

⚠ Điểm mấu chốt — nhóm lệnh là artifacts, không phải container:

Artifact Registry (dịch vụ HIỆN HÀNH)
        ↓
    gcloud artifacts ...
        ↓
Container Registry (GCR — dịch vụ CŨ, đã ngừng)
        ↓
    gcloud container images ...
        ↓
    → đề nói rõ "Artifact Registry"
    → nhóm lệnh phải là `artifacts`

⚠ Và cấu trúc nhóm trước, động từ sau:

gcloud  artifacts  repositories  list
          ↑            ↑          ↑
        nhóm       nhóm con    động từ
        ↓
    → "gcloud repositories container list" sai thứ tự
    → "gcloud container metadata list" sai cả nhóm

⚠ Artifact Registry lưu được nhiều hơn container image:

Định dạng hỗ trợ:
        ↓
    Docker / OCI image
    Maven, npm, Python, Go
    Apt, Yum
    Helm chart
        ↓
    → đây là lý do nó thay thế Container Registry:
      một nơi cho MỌI loại artifact
        ↓
    Mỗi repository khai một ĐỊNH DẠNG và một VỊ TRÍ

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

• B (gcloud reposoitories container list) — sai chính tả (reposoitories), sai thứ tự, và không có nhóm lệnh nào như vậy.

• C (gcloud container metadata list) — nhóm gcloud container dành cho GKE, và không có nhóm con metadata.

• D (gcloud container list metadata) — sai thứ tự (động từ phải đứng sau nhóm) và cũng sai nhóm lệnh.

Ghi nhớ

⚠ Các lệnh Artifact Registry hay dùng — bảng đáng thuộc: | Lệnh | Việc | |---|---| | gcloud artifacts repositories list | liệt kê repository | | gcloud artifacts repositories describe <ten> | xem chi tiết một repository | | gcloud artifacts repositories create | tạo mới — khai --repository-format và --location | | gcloud artifacts docker images list <repo> | liệt kê image | | gcloud artifacts docker images delete | xoá image | | gcloud auth configure-docker <location>-docker.pkg.dev | cấu hình Docker để push/pull |

Từ khoá nhận diện:

"Artifact Registry" → gcloud artifacts "GKE, cụm Kubernetes" → gcloud container clusters "Container Registry (GCR)" → dịch vụ CŨ, đã ngừng — chuyển sang Artifact Registry "quét lỗ hổng image" → Artifact Analysis (tên cũ: Container Analysis) "chặn image chưa duyệt chạy trên GKE" → Binary Authorization

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những repository nào | gcloud artifacts repositories list | | Image trong repo | gcloud artifacts docker images list <location>-docker.pkg.dev/<proj>/<repo> | | Docker đã cấu hình chưa | gcloud auth configure-docker <location>-docker.pkg.dev |

Và một tính năng rất nên bật ngay khi tạo repository cho môi trường production: immutable tag. Nó ngăn việc đẩy đè lên một tag đã tồn tại, nên v1.2.3 hôm nay và v1.2.3 sáu tháng sau chắc chắn là cùng một image — thứ khiến việc điều tra sự cố và việc kiểm toán trở nên đáng tin cậy thay vì phải đoán.

Đáp án

B — Kiểm tra firewall rule có cho phép lưu lượng tới CỔNG 22 để SSH kết nối được không.

Vì sao đúng

gcloud compute scp chạy trên nền SSH, nên mọi thứ chặn SSH cũng chặn nó.

⚠ Điểm mấu chốt — scp dùng đúng đường của SSH:

gcloud compute scp
        ↓
    Bên dưới là SSH (cổng 22)
        ↓
    Firewall của GCP MẶC ĐỊNH CHẶN mọi ingress
        ↓
    Không có luật cho phép cổng 22
        ↓
    → kết nối không thiết lập được
    → lệnh copy thất bại

⚠ Luật firewall cần có:

Direction: INGRESS
Source:    35.235.240.0/20   (nếu dùng IAP)
           hoặc IP của người dùng
Protocol:  tcp:22
Target:    network tag của VM, hoặc service account
        ↓
    Mạng "default" của GCP có sẵn luật
      default-allow-ssh
        ↓
    → VPC tự tạo thì KHÔNG có luật này
    → phải tự thêm

⚠ Và cách hiện đại hơn — IAP TCP forwarding:

Identity-Aware Proxy (IAP) cho SSH
        ↓
    Kết nối đi qua hạ tầng của Google
        ↓
    → VM KHÔNG cần IP công cộng
    → chỉ mở cổng 22 cho dải 35.235.240.0/20
      (dải của IAP), không mở cho internet
        ↓
    gcloud compute ssh <vm> --tunnel-through-iap
    gcloud compute scp <tep> <vm>: --tunnel-through-iap
        ↓
    → phân quyền bằng IAM
      (roles/iap.tunnelResourceAccessor)

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

• C và D (cấp roles/compute.admin hoặc quyền compute.admin) — đây là các phương án gần nhất vì quyền cũng có thể là nguyên nhân, nhưng compute.admin quá rộng cho việc chỉ cần SSH, và quyền IAM không mở được đường mạng. (Quyền tối thiểu để SSH là roles/compute.osLogin hoặc compute.instanceAdmin.v1.)

• A (thêm danh tính vào "administrator group" của VM) — không có khái niệm nhóm quản trị của VM trong Google Cloud. Quyền được cấp bằng IAM, và đăng nhập hệ điều hành quản bằng OS Login.

Ghi nhớ

⚠ Firewall của Google Cloud — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Mặc định | CHẶN mọi ingress, CHO PHÉP mọi egress | | Phạm vi | áp cho cả VPC, không gắn vào từng máy | | Nhắm mục tiêu | network tag, service account, hoặc mọi instance | | Ưu tiên | 0-65535, số NHỎ HƠN thắng (mặc định 1000) | | Chiều | ingress và egress khai riêng | | Mạng default | có sẵn default-allow-ssh, default-allow-icmp, default-allow-internal |

Từ khoá nhận diện:

"scp hoặc ssh thất bại" → firewall cổng 22, trước tiên "không muốn VM có IP công cộng" → IAP TCP forwarding "quản lý người dùng SSH tập trung" → OS Login "VM ra internet mà không có IP công cộng" → Cloud NAT "VM gọi API Google mà không ra internet" → Private Google Access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có luật SSH không | gcloud compute firewall-rules list --filter="allowed.ports=22" | | VM có tag gì | gcloud compute instances describe <ten> --format="value(tags.items)" | | Vì sao không kết nối được | gcloud compute ssh <vm> --troubleshoot |

Và một lệnh rất đáng nhớ khi gặp sự cố loại này: gcloud compute ssh <vm> --troubleshoot. Nó tự kiểm tra firewall, quyền IAM, trạng thái VM, cấu hình OS Login và dải IAP rồi báo cáo chính xác mắt xích nào đang thiếu — nhanh hơn nhiều so với việc lần lượt kiểm tra từng thứ bằng tay.

Đáp án

B — 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 và chia nhỏ chi phí theo các chiều do bạn định nghĩa.

⚠ Điểm mấu chốt — label xuất hiện trong dữ liệu thanh toán:

Gắn label lên tài nguyên:
    team = data-platform
    env  = production
    cost-center = 4021
        ↓
    Label được đưa vào BILLING EXPORT
        ↓
    → xuất dữ liệu thanh toán sang BigQuery
    → truy vấn: chi phí GROUP BY label
        ↓
    → biết đội nào tốn bao nhiêu
    → đúng thứ người quản lý trong đề cần

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

LABEL
        ↓
    Cặp khoá-giá trị, dùng cho
    TỔ CHỨC và PHÂN TÍCH CHI PHÍ
    → xuất hiện trong billing export

TAG (Resource Manager tag)
        ↓
    Dùng cho ĐIỀU KIỆN IAM và
    ORGANIZATION POLICY
    → quản lý tập trung, có phân quyền

NETWORK TAG
        ↓
    Chỉ dùng để FIREWALL RULE nhắm mục tiêu
    → không liên quan tới chi phí

⚠ Quy tắc của label:

Tối đa 64 label mỗi tài nguyên
Khoá: chữ thường, số, gạch dưới, gạch ngang
Giá trị: cũng vậy, được để rỗng
        ↓
    → KHÔNG có chữ hoa
    → khác với tag của AWS (phân biệt hoa thường)
        ↓
    Nên chốt bộ label chuẩn từ đầu:
      team, env, app, cost-center, owner

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

• A (Audit logs) — đây là phương án gần nhất vì audit log cho biết AI đã tạo tài nguyên, nhưng nó không có thông tin chi phí và cũng không phải công cụ để phân loại chi tiêu. Muốn ra con số tiền vẫn phải tự đối chiếu thủ công.

• C (Trace logs) — Cloud Trace theo dõi độ trễ của request, phục vụ chẩn đoán hiệu năng, không liên quan tới chi phí.

• D (IAM policies) — quyết định AI ĐƯỢC LÀM GÌ, không phân loại tài nguyên theo đội và không đưa gì vào hoá đơn.

Ghi nhớ

⚠ Ba loại "nhãn" trong Google Cloud — bảng phải thuộc: | Loại | Dùng để | |---|---| | Label | tổ chức và PHÂN TÍCH CHI PHÍ — vào billing export | | 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, đừng lẫn |

Từ khoá nhận diện:

"chi phí theo đội / theo dự án" → label + billing export "ai đã tạo tài nguyên" → Cloud Audit Logs "điều kiện IAM theo thuộc tính tài nguyên" → tag "firewall nhắm vào nhóm máy" → network tag hoặc service account "cảnh báo khi vượt ngân sách" → Budget và alert

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, GROUP BY label | | Tài nguyên nào thiếu label | lọc --filter="-labels.team:*" |

Và một điểm cần lưu ý khi bắt đầu dùng label để chia chi phí: label chỉ áp cho chi phí phát sinh SAU khi gắn. Dữ liệu thanh toán của tháng trước sẽ không tự có label mới, nên càng gắn sớm càng tốt — và với những khoản chi phí không gắn label được, cách tách bạch tuyệt đối vẫn là mỗi đội một project riêng.

Đáp án

A, B và D — ADMIN ACTIVITY, DATA ACCESS và SYSTEM EVENT.

Vì sao đúng

Cloud Audit Logs của Google Cloud có bốn loại, và ba loại được nêu trong đáp án là những loại có ở mọi project, folder và organization.

⚠ Bốn loại audit log — bảng cần thuộc:

ADMIN ACTIVITY                      ← luôn có
        ↓
    Thao tác GHI làm THAY ĐỔI cấu hình
      hoặc siêu dữ liệu
    Ví dụ: tạo VM, sửa IAM policy
        ↓
    → LUÔN BẬT, KHÔNG TẮT ĐƯỢC, MIỄN PHÍ
    → giữ 400 ngày

DATA ACCESS                         ← luôn có
        ↓
    Thao tác ĐỌC dữ liệu, và ghi do người dùng
    Ví dụ: đọc đối tượng trong Cloud Storage
        ↓
    → PHẢI BẬT THỦ CÔNG (trừ BigQuery)
    → CÓ PHÍ, khối lượng rất lớn
    → giữ 30 ngày mặc định

SYSTEM EVENT                        ← luôn có
        ↓
    Hành động do CHÍNH GOOGLE thực hiện
    Ví dụ: live migration của VM
        ↓
    → LUÔN BẬT, MIỄN PHÍ, giữ 400 ngày

POLICY DENIED
        ↓
    Bị từ chối do vi phạm chính sách bảo mật
    (VPC Service Controls…)
        ↓
    → luôn bật, có phí

⚠ Vì sao Data Access cần chú ý nhất:

Khối lượng RẤT LỚN
        ↓
    Mỗi lượt đọc một đối tượng là một bản ghi
        ↓
    → bật cho toàn bộ dịch vụ có thể rất tốn kém
        ↓
    Nên: bật chọn lọc cho dịch vụ và
    tài nguyên NHẠY CẢM
    → cấu hình trong IAM → Audit Logs

⚠ Kiểm toán viên cần gì thì lấy ở đâu:

"Ai đã đổi quyền IAM"      → Admin Activity
"Ai đã đọc dữ liệu nhạy cảm" → Data Access (phải bật trước)
"Google đã làm gì với VM"   → System Event
"Ai bị chặn bởi chính sách" → Policy Denied

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

• C (Policy Access) — đây là phương án gần nhất vì tên gần giống, nhưng loại log đúng tên là Policy DENIED, không phải "Policy Access".

• E (User Login) — không phải một loại Cloud Audit Log. Việc đăng nhập được ghi ở Google Workspace audit log hoặc Cloud Identity, một hệ thống khác.

• F (Performance Metrics) — chỉ số hiệu năng thuộc Cloud Monitoring, không phải audit log.

Ghi nhớ

⚠ Bốn loại Cloud Audit Log — bảng phải thuộc: | Loại | Ghi gì | Bật sẵn | Chi phí | |---|---|---|---| | Admin Activity | thay đổi cấu hình và siêu dữ liệu | LUÔN BẬT, không tắt được | miễn phí | | Data Access | ĐỌC dữ liệu, ghi do người dùng | phải bật (trừ BigQuery) | CÓ PHÍ | | System Event | hành động của Google | luôn bật | miễn phí | | Policy Denied | bị chặn bởi chính sách bảo mật | luôn bật | có phí | | Thời gian giữ | Admin và System 400 ngày; Data Access 30 ngày | | |

Từ khoá nhận diện:

"ai đã thay đổi cấu hình" → Admin Activity "ai đã ĐỌC dữ liệu" → Data Access — phải bật trước "Google đã tự làm gì" → System Event "bị chặn bởi VPC Service Controls" → Policy Denied "giữ log lâu hơn mặc định" → sink sang Cloud Storage hoặc BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Data Access đã bật chưa | IAM → Audit Logs, xem từng dịch vụ | | Tìm một hành động cụ thể | Logs Explorer với logName chứa cloudaudit.googleapis.com | | Log có được lưu lâu dài không | gcloud logging sinks list |

Và một cấu hình rất nên dựng sớm cho mục đích kiểm toán: aggregated sink ở cấp organization đổ vào một bucket trong project log riêng, có Bucket Lock. Khi đó log của mọi project được gom về một nơi, không ai trong các project thành viên xoá được — và đó chính là điều kiện để một bản ghi kiểm toán có giá trị chứng minh.

Đáp án

A — Tạo policy ở cấp TỔ CHỨC với ràng buộc RESOURCE LOCATION RESTRICTION.

Vì sao đúng

Yêu cầu là không tài nguyên nào được tạo ngoài Bắc Mỹ, và Organization Policy là cơ chế duy nhất ép được điều đó ở mọi nơi.

⚠ Điểm mấu chốt — ràng buộc vị trí là một Organization Policy:

constraints/gcp.resourceLocations
        ↓
    Khai danh sách vị trí ĐƯỢC PHÉP
      ví dụ: in:us-locations,
             in:northamerica-locations
        ↓
    → mọi lời gọi tạo tài nguyên ở vị trí khác
      BỊ TỪ CHỐI
        ↓
    Áp ở cấp ORGANIZATION
        ↓
    → KẾ THỪA xuống mọi folder và mọi project
    → kể cả project TẠO MỚI SAU NÀY

⚠ Vì sao phải ở cấp TỔ CHỨC, không phải folder:

Áp ở cấp FOLDER (phương án C)
        ↓
    Chỉ phủ các project TRONG folder đó
        ↓
    → project nằm ngoài folder KHÔNG bị ràng buộc
    → project tạo mới ở nhánh khác cũng vậy
        ↓
Áp ở cấp ORGANIZATION
        ↓
    → phủ TOÀN BỘ, không có ngoại lệ ngoài ý muốn
    → đúng yêu cầu "không tài nguyên nào"

⚠ Vì sao IAM policy không làm được:

IAM trả lời câu hỏi "AI được làm GÌ"
        ↓
    Không có khái niệm "ở ĐÂU"
        ↓
    → không diễn đạt được ràng buộc vị trí
        ↓
Organization Policy trả lời
    "CẤU HÌNH nào được phép tồn tại"
        ↓
    → đây mới là công cụ đúng

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

• C (tạo policy ở cấp FOLDER với cùng ràng buộc) — đây là phương án gần nhất và dùng đúng ràng buộc, chỉ sai phạm vi: folder không phủ được mọi project trong tổ chức, nên vẫn có chỗ lọt.

• B (tạo IAM policy ngăn tạo tài nguyên ngoài Bắc Mỹ) — IAM không có điều kiện theo vị trí tài nguyên theo cách này. Đây là việc của Organization Policy.

• D (chính sách quản lý vòng đời dữ liệu) — lifecycle policy quyết định dữ liệu được chuyển lớp lưu trữ hay xoá khi nào, hoàn toàn không kiểm soát vị trí địa lý.

Ghi nhớ

⚠ Organization Policy ↔ IAM — bảng phải thuộc: | | Organization Policy | IAM | |---|---|---| | Trả lời câu hỏi | "CẤU HÌNH nào được phép" | "AI được làm GÌ" | | Ví dụ | giới hạn vị trí, cấm IP công cộng | cấp vai trò cho người dùng | | Phạm vi | organization / folder / project | organization → tài nguyên | | Kế thừa | từ trên xuống, con có thể ghi đè nếu được phép | từ trên xuống, cộng dồn | | Tương đương AWS | ≈ SCP | ≈ IAM policy |

Từ khoá nhận diện:

"tài nguyên chỉ được ở khu vực X" → gcp.resourceLocations "cấm VM có IP công cộng" → compute.vmExternalIpAccess "cấm chia sẻ công khai" → iam.allowedPolicyMemberDomains "ai được làm gì" → IAM "phủ mọi project kể cả project mới" → áp ở cấp ORGANIZATION

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Policy đang áp là gì | gcloud resource-manager org-policies describe gcp.resourceLocations --organization=<id> | | Có chặn đúng không | thử tạo một VM ở Region bị cấm — phải bị từ chối | | Còn tài nguyên nào sai chỗ không | Cloud Asset Inventory, lọc theo location |

Và một việc phải làm ngay sau khi áp chính sách này: quét lại toàn bộ tài nguyên đã tồn tại bằng Cloud Asset Inventory. Organization Policy chỉ chặn việc tạo mới — mọi tài nguyên đã nằm ngoài Bắc Mỹ từ trước vẫn tiếp tục chạy và vẫn đang lưu dữ liệu ở đó, và chính chúng mới là phần vi phạm mà kiểm toán viên sẽ tìm thấy.

Đáp án

C — billing.accounts.create

Vì sao đúng

Câu này kiểm tra sự phân biệt giữa PERMISSION và ROLE — hai khái niệm rất hay bị lẫn trong IAM của Google Cloud.

⚠ Điểm mấu chốt — permission và role đặt tên khác nhau:

PERMISSION (quyền đơn lẻ)
        ↓
    Định dạng: <dichvu>.<taiNguyen>.<hanhDong>
        ↓
    billing.accounts.create
    compute.instances.list
    storage.objects.get
        ↓
    → KHÔNG có tiền tố "roles/"

ROLE (vai trò — tập hợp permission)
        ↓
    Định dạng: roles/<dichvu>.<tenVaiTro>
        ↓
    roles/billing.creator
    roles/compute.admin
    roles/storage.objectViewer
        ↓
    → LUÔN có tiền tố "roles/"

⚠ Đề hỏi PERMISSION, nên đáp án không có roles/:

"What PERMISSION must an identity have..."
        ↓
    → cần một permission, không phải role
        ↓
    billing.accounts.create   ✓
        ↓
    Vai trò CHỨA permission này là:
      roles/billing.creator
      (Billing Account Creator)

⚠ Và vai trò này gán ở cấp TỔ CHỨC:

roles/billing.creator
        ↓
    Gán ở cấp ORGANIZATION
        ↓
    → tạo billing account mới
        ↓
    Các vai trò billing khác:
      roles/billing.admin   → quản lý billing account
      roles/billing.user    → GẮN project vào billing account
      roles/billing.viewer  → chỉ xem
        ↓
    Muốn tạo project VÀ gắn billing:
      cần cả resourcemanager.projectCreator
      và billing.user

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

• D (roles/billing.accounts.create) — đây là phương án gần nhất và là bẫy chính: nó trộn hai định dạng. Tiền tố roles/ chỉ dùng cho vai trò, và không có vai trò nào tên như vậy.

• A (billing.create) — thiếu phần tài nguyên: định dạng permission phải có ba phần — dịch vụ, tài nguyên, hành động.

• B (roles/billing.create) — cũng trộn định dạng, và không có vai trò nào tên này.

Ghi nhớ

⚠ Permission ↔ Role — bảng phải thuộc: | | Permission | Role | |---|---|---| | Định dạng | <dichvu>.<taiNguyen>.<hanhDong> | roles/<dichvu>.<ten> | | Ví dụ | compute.instances.create | roles/compute.instanceAdmin | | Gán trực tiếp cho người dùng | KHÔNG | CÓ | | Quan hệ | một role chứa NHIỀU permission | | | Bẫy | roles/ đứng trước permission là luôn SAI | |

Từ khoá nhận diện:

"permission nào" → không có tiền tố roles/, có ba phần "role nào" → có tiền tố roles/ "tạo billing account" → roles/billing.creator "gắn project vào billing account" → roles/billing.user "xem chi phí" → roles/billing.viewer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền billing | gcloud beta billing accounts get-iam-policy <id> | | Vai trò gồm permission nào | gcloud iam roles describe roles/billing.creator | | Project gắn billing nào | gcloud beta billing projects describe <project> |

Và một cách rất nhanh để không bao giờ nhầm hai định dạng này: permission luôn có ba phần và không có dấu gạch chéo, còn role luôn bắt đầu bằng roles/. Bất kỳ chuỗi nào vừa có roles/ vừa trông như một permission ba phần — như roles/billing.accounts.create — đều là phương án bịa trong đề thi.

Đáp án

A — gcloud config configurations create

Vì sao đúng

Câu này kiểm tra cấu trúc nhóm — nhóm con — động từ của gcloud, và tên nhóm con đúng.

⚠ Điểm mấu chốt — configurations nằm TRONG nhóm config:

gcloud  config  configurations  create
          ↑          ↑            ↑
        nhóm     nhóm con      động từ
        ↓
    → không có nhóm nào tên "configurations"
      ở cấp trên cùng
    → nên "gcloud configurations create" là SAI

⚠ Configuration là gì và giải quyết vấn đề gì:

Một configuration lưu một BỘ cài đặt:
        ↓
    project, account, region, zone
        ↓
    Nhiều configuration song song:
      gcloud config configurations create prod
      gcloud config configurations create dev
        ↓
    Chuyển qua lại:
      gcloud config configurations activate prod
        ↓
    → không phải gõ --project mỗi lệnh
    → không sợ chạy nhầm lệnh vào project sản xuất
        ↓
    Đúng nhu cầu "cấu trúc thanh toán phức tạp,
    nhiều project" của đề

⚠ Phân biệt create với activate và set:

gcloud config configurations create <ten>
        ↓
    TẠO một configuration mới

gcloud config configurations activate <ten>
        ↓
    CHUYỂN sang dùng configuration đó

gcloud config set <thuoc-tinh> <gia-tri>
        ↓
    ĐẶT một thuộc tính trong configuration
    ĐANG HOẠT ĐỘNG
        ↓
    → ba việc khác nhau, đừng lẫn

Xem thêm câu #12462 (cùng lô): cùng nguyên tắc — gcloud luôn là nhóm trước, động từ sau. Khoá nhất quán.

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

• C (gcloud config configurations set) — đây là phương án gần nhất vì nhóm và nhóm con hoàn toàn đúng, nhưng động từ sai: configurations không có động từ set. Để tạo là create, để chuyển là activate.

• B và D (gcloud configurations create/set) — thiếu nhóm config. Không có nhóm cấp cao nào tên configurations.

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 đang IS_ACTIVE | | gcloud config configurations delete <ten> | xoá | | gcloud config set project <id> | đặ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 một configuration cho ĐÚNG một lệnh |

Từ khoá nhận diện:

"nhiều bộ cấu hình CLI" → gcloud config configurations "đặt project mặc định" → gcloud config set project "xem cấu hình hiện tại" → gcloud config list "gcloud configurations ..." → SAI — thiếu nhóm config "nhiều tài khoản đăng nhập" → gcloud auth list, và --account

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng configuration nào | gcloud config configurations list | | Project hiện tại | gcloud config get-value project | | Tài khoản hiện tại | gcloud auth list |

Và một thói quen giúp tránh một loại sự cố rất khó chịu: hiện tên configuration đang hoạt động ngay trong dấu nhắc shell. Phần lớn các lần chạy nhầm lệnh vào môi trường sản xuất bắt nguồn từ việc quên rằng phiên terminal hiện tại đang trỏ vào project nào — và một dòng chữ trong dấu nhắc giải quyết triệt để chuyện đó.

Đáp án

A và C — gcloud init và gcloud auth login.

Vì sao đúng

Cả hai lệnh đều mở trình duyệt để đăng nhập tài khoản Google và cấp quyền cho gcloud, chỉ khác nhau ở phạm vi công việc.

⚠ Điểm mấu chốt — hai lệnh, hai mức độ:

gcloud auth login
        ↓
    CHỈ xác thực
        ↓
    Mở trình duyệt → đăng nhập →
    lưu thông tin xác thực vào máy
        ↓
    → không đụng tới project hay Region

gcloud init
        ↓
    Xác thực VÀ cấu hình trọn gói
        ↓
    Chạy một hướng dẫn từng bước:
      1. đăng nhập (gọi auth login bên dưới)
      2. chọn project
      3. chọn Region và zone mặc định
      4. tạo hoặc chọn configuration
        ↓
    → lệnh nên dùng khi thiết lập máy LẦN ĐẦU

⚠ Ba loại thông tin xác thực của gcloud:

Tài khoản người dùng
        ↓
    gcloud auth login
    → cho làm việc thủ công trên máy cá nhân

Application Default Credentials (ADC)
        ↓
    gcloud auth application-default login
    → cho THƯ VIỆN CLIENT của ứng dụng
      chạy trên máy local
        ↓
    → hai loại này TÁCH BIỆT
    → đăng nhập cái này không cấp cho cái kia

Service account
        ↓
    gcloud auth activate-service-account
      --key-file=key.json
    → cho máy chủ và CI/CD

⚠ Và một điểm rất quan trọng về ADC:

Ứng dụng Python/Java/Go dùng thư viện client
        ↓
    Chúng tìm ADC, KHÔNG dùng thông tin
    của `gcloud auth login`
        ↓
    → chạy code local mà báo lỗi xác thực
      dù đã `gcloud auth login`
        ↓
    → phải chạy thêm:
      gcloud auth application-default login

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

• B (gcloud login) — đây là phương án gần nhất và rất dễ gõ nhầm, nhưng login không phải một nhóm ở cấp cao nhất. Đúng phải là gcloud auth login.

• D (gcloud config login) — nhóm config dùng để đặt thuộc tính cấu hình, không có động từ login.

Ghi nhớ

⚠ Các lệnh xác thực của gcloud — bảng phải thuộc: | Lệnh | Việc | |---|---| | gcloud init | thiết lập trọn gói: đăng nhập + project + Region | | gcloud auth login | chỉ đăng nhập tài khoản người dùng | | gcloud auth application-default login | cấp ADC cho THƯ VIỆN CLIENT | | gcloud auth activate-service-account --key-file | dùng service account | | gcloud auth list | xem các tài khoản đã đăng nhập | | gcloud auth revoke | thu hồi thông tin xác thực | | gcloud auth print-access-token | in token để dùng với curl |

Từ khoá nhận diện:

"thiết lập máy lần đầu" → gcloud init "chỉ cần đăng nhập" → gcloud auth login "code local gọi API Google mà lỗi xác thực" → application-default login "CI/CD, máy chủ" → service account, hoặc Workload Identity Federation "gcloud login" → SAI — thiếu nhóm auth

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang đăng nhập bằng tài khoản nào | gcloud auth list | | ADC đã có chưa | kiểm tra tệp trong ~/.config/gcloud/ | | Token hiện tại là của ai | gcloud auth print-access-token rồi tra tokeninfo |

Và một nguyên nhân gây bối rối rất phổ biến với người mới: gcloud auth login và gcloud auth application-default login là hai thứ tách biệt. Lệnh đầu cho phép bạn chạy lệnh gcloud, lệnh sau cho phép mã ứng dụng của bạn gọi API — nên hoàn toàn có chuyện gcloud chạy ngon lành trong khi script Python ngay bên cạnh lại báo lỗi không tìm thấy thông tin xác thực.