Lộ trình
Google CloudAssociateTuần 1: Nền tảngBài 2 / 30

Ngày 2: Cấu trúc tài nguyên GCP

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
gcp-acengày 2
hoàn thành2 / 30 bài
Bối cảnh bài học

Thiết kế resource hierarchy GCP bằng Organization, Folder và Project; nối scope với IAM, billing, quota, labels và lifecycle.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Thiết kế resource hierarchy GCP bằng Organization, Folder và Project; nối scope với IAM, billing, quota, labels và lifecycle.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Học Organization, Folder, Project
  • Thực hành tạo 1 Project mới
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một công ty dùng một project cho production, sandbox và nhiều team; quyền IAM, billing attribution và quota trở nên khó kiểm soát. Bài học dạy cách chọn project boundary trước khi tạo resource.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Organization là root resource gắn với identity/domain; Folder nhóm project theo department/environment/policy.
  • Project là boundary cho API enablement, IAM, quota, resource IDs và billing association; project không phải chỉ là một thư mục.
  • IAM policy có inheritance theo hierarchy; role ở organization/folder có blast radius lớn hơn role ở project/resource.
  • Billing account liên kết project để charge usage; labels/tags và naming hỗ trợ attribution nhưng không thay IAM/billing control.

Hierarchy giải quyết boundary

GCP hierarchy thường là Organization → Folder → Project → Resource. Organization là root; Folder nhóm project; Project là boundary quan trọng cho API, IAM, quota, resource IDs và billing association. Resource bên dưới kế thừa một phần policy/permission từ ancestor.

Chọn project boundary

Tách prod/nonprod hoặc team khi cần isolation, billing attribution, quota/lifecycle khác nhau. Đừng tạo project cho mọi resource nếu automation/governance overhead không đáng; cũng đừng gom mọi thứ khiến blast radius quá lớn. Ghi owner, billing, APIs, quota, labels, retention và deletion policy.

IAM inheritance

Role ở organization/folder có thể ảnh hưởng rộng; project-level role thường dễ giới hạn hơn. Effective access phải được review theo inheritance, group membership và service account. Labels hỗ trợ cost/inventory nhưng không cấp quyền.

Bài tập

Thiết kế hierarchy cho prod/nonprod của hai team. Chỉ ra billing/quota/IAM scope và một scenario xóa project nhầm. Dùng gcloud read-only để kiểm tra context, sau đó viết cleanup/approval flow cho project lab.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
gcloud projects list --format="table(projectId,name,parent.type,parent.id)"
gcloud projects describe LAB_PROJECT_ID --format="yaml(projectId,name,parent,labels,projectNumber)"
gcloud resource-manager folders list --organization=ORG_ID
Hands-on lab

Thực hành theo scenario

  1. Vẽ organization → folder (prod/nonprod/team) → project → resource cho công ty có hai môi trường.
  2. Tạo project decision record: owner, billing account, APIs, quota, IAM scope, labels, retention và deletion policy.
  3. Dùng gcloud list/describe read-only để kiểm tra project context; nếu tạo project lab, xác nhận billing/permission và xóa sau khi verify.
  4. Mô phỏng inheritance: role ở folder vs project, ghi resource nào bị ảnh hưởng và cách audit effective access.
Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Phân biệt organization/folder/project/resource.
  • Giải thích project boundary cho IAM/API/quota/billing.
  • Role scope có blast-radius reasoning.
  • Project design có owner/labels/lifecycle/cleanup.
  • Không tạo project/resource ngoài billing-safe target.
Transfer to exam / production

Bẫy thường gặp và trade-off

ACE thường kiểm tra resource hierarchy và IAM inheritance: project không phải organization, folder không phải region, và role scope càng cao càng rộng.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Muốn tách billing, quota và API enablement giữa production và sandbox, boundary nào thường phù hợp nhất?

Kết thúc bài

Checklist trước khi sang Ngày 2