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

Đáp án

D — Cụm REGIONAL (theo Region).

Vì sao đúng

Chỉ cụm regional nhân bản CẢ control plane lẫn node ra nhiều zone — điều kiện của tính sẵn sàng cao thật sự.

⚠ Ba kiểu cụm GKE — khác nhau ở control plane:

SINGLE-ZONE
        ↓
    Control plane: 1 bản, 1 zone
    Node: 1 zone
    → zone hỏng là mất tất cả

MULTI-ZONAL
        ↓
    Control plane: 1 bản, 1 zone   ← điểm yếu
    Node: nhiều zone
    → mất zone của control plane
      → ứng dụng còn chạy nhưng
        KHÔNG QUẢN LÝ ĐƯỢC cụm

REGIONAL                            ← đề này
        ↓
    Control plane: NHIỀU BẢN, nhiều zone
    Node: nhiều zone
    → mất một zone: mọi thứ vẫn hoạt động

⚠ Và một chi tiết về chi phí:

Cụm regional
        ↓
    Số node bạn khai là SỐ NODE MỖI ZONE
        ↓
    Khai 3 node, trải 3 zone → THỰC TẾ 9 node
        ↓
    → tính dự toán phải nhân với số zone

Xem thêm câu #12465 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án regional cluster. Chỉ khác chữ cái — ở đó là C, ở đây là D. Khoá nhất quán.

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

• B (Multi-zonal) — đây là phương án gần nhất và node đúng là trải nhiều zone, nhưng control plane vẫn chỉ có MỘT bản ở MỘT zone. Mất zone đó thì không triển khai, không co giãn, không sửa được gì.

• C ("Multi-regional") — GKE không có kiểu cụm này. Một cụm nằm trong một Region; muốn nhiều Region thì dựng nhiều cụm và dùng Multi Cluster Ingress.

• A (Single zone) — không có dự phòng nào.

Ghi nhớ

⚠ Ba kiểu cụm GKE — bảng phải thuộc: | Kiểu | Control plane | Node | |---|---|---| | Single-zone | 1 bản, 1 zone | 1 zone | | Multi-zonal | 1 bản, 1 zone | nhiều zone | | Regional | nhiều bản, nhiều zone | nhiều zone | | Sẵn sàng cao | chỉ Regional | | | Nâng cấp control plane | zonal có gián đoạn, regional không | |

Từ khoá nhận diện:

"tính sẵn sàng cao cho cụm" → regional cluster "nhiều Region" → nhiều cụm + Multi Cluster Ingress "không muốn quản node" → GKE Autopilot (luôn regional) "node không có IP công cộng" → private cluster "chi phí regional cao bất ngờ" → node × số zone

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm thuộc kiểu nào | gcloud container clusters describe <ten> → location | | Node trải mấy zone | kubectl get nodes -L topology.kubernetes.io/zone | | Pod có trải đều không | kubectl get pods -o wide |

Và một chi tiết chi phí hay gây bất ngờ khi chuyển sang regional: con số node là số node MỖI ZONE. Một cụm "3 node" trải ba zone thực chất chạy chín máy — hãy luôn nhân với số zone trước khi so sánh với cụm zonal hiện tại.

Đáp án

B và D — gcloud auth login và gcloud init.

Vì sao đúng

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

⚠ Hai lệnh, hai mức độ:

gcloud auth login
        ↓
    CHỈ xác thực
    → lưu thông tin đăng nhập 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
    → đăng nhập, chọn project,
      chọn Region và zone mặc định,
      tạo configuration
        ↓
    → lệnh nên dùng khi thiết lập máy LẦN ĐẦU

⚠ Và một điểm rất quan trọng — ADC là thứ TÁCH BIỆT:

gcloud auth login
        ↓
    Cho phép bạn chạy lệnh `gcloud`

gcloud auth application-default login
        ↓
    Cấp Application Default Credentials
    cho THƯ VIỆN CLIENT của ứng dụng
        ↓
    → code Python/Java gọi API Google
      dùng ADC, KHÔNG dùng thông tin của auth login
        ↓
    → hoàn toàn có chuyện gcloud chạy ngon
      mà script bên cạnh báo lỗi xác thực

Xem thêm câu #12481 (CÙNG LÔ): cùng một câu hỏi, cùng hai đáp án. Chỉ khác chữ cái — ở đó là A và C, ở đây là B và D. Khoá nhất quán.

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

• C (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 nhóm ở cấp cao nhất. Đúng là gcloud auth login.

• A (gcloud config login) — nhóm config để đặ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 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 | ADC cho THƯ VIỆN CLIENT | | gcloud auth activate-service-account --key-file | dùng service account | | gcloud auth list | xem tài khoản đã đăng nhập | | 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 lỗi xác thực" → application-default login "CI/CD" → 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 gì | gcloud auth list | | ADC đã có chưa | kiểm tra tệp trong ~/.config/gcloud/ | | Token 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: 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 gcloud, lệnh sau cho phép mã ứng dụng gọi API — nên gcloud chạy ngon lành mà script Python bên cạnh vẫn báo lỗi xác thực là chuyện hoàn toàn bình thường.

Đáp án

D — 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à chỉ Organization Policy áp ở cấp tổ chức mới phủ được mọi nơi.

⚠ Điểm mấu chốt — ràng buộc gcp.resourceLocations:

constraints/gcp.resourceLocations
        ↓
    Khai danh sách vị trí ĐƯỢC PHÉP
      in:northamerica-locations
      in:us-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, mọi project
    → kể cả project TẠO MỚI SAU NÀY

⚠ Vì sao phải TỔ CHỨC chứ không phải folder:

Cấp FOLDER
        ↓
    Chỉ phủ project TRONG folder đó
    → project ở nhánh khác KHÔNG bị ràng buộc
        ↓
Cấp ORGANIZATION
        ↓
    → phủ TOÀN BỘ, không có ngoại lệ
    → đúng yêu cầu "không tài nguyên nào"

Xem thêm câu #12478 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án. Chỉ khác chữ cái — ở đó là A, ở đây là D. Khoá nhất quán.

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

• C (policy ở cấp FOLDER) — đâ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.

• B (tạo Cloud Audit policy ngăn tạo tài nguyên) — audit log chỉ GHI LẠI, không NGĂN CHẶN gì cả.

• A (chính sách quản lý vòng đời dữ liệu) — lifecycle policy quyết định chuyển lớp lưu trữ hay xoá khi nào, 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Ì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ò | | Phạm vi | organization / folder / project | organization → tài nguyên | | Tương đương AWS | ≈ SCP | ≈ IAM policy |

Từ khoá nhận diện:

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

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

Và một việc phải làm ngay sau khi áp: quét 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ỹ vẫn tiếp tục chạy và vẫn 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

D — gsutil mv

Vì sao đúng

Cloud Storage không có thao tác "đổi tên" thật sự, và mv là lệnh làm đúng việc mà người dùng cần.

⚠ Điểm mấu chốt — đổi tên thực chất là COPY rồi DELETE:

Cloud Storage là kho ĐỐI TƯỢNG
        ↓
    Tên đối tượng (key) là BẤT BIẾN
        ↓
    → không có API "rename"
        ↓
gsutil mv gs://bucket/cu.txt gs://bucket/moi.txt
        ↓
    Bên dưới thực hiện:
      1. COPY sang tên mới
      2. DELETE tên cũ
        ↓
    → kết quả là "đổi tên", nhưng cơ chế là hai bước

⚠ Hệ quả cần biết:

Vì là copy + delete:
        ↓
    - Tính phí thao tác GHI và XOÁ
    - Với tệp lớn thì mất thời gian
    - KHÔNG nguyên tử — có khoảng thời gian
      cả hai tên cùng tồn tại, hoặc mất cả hai
      nếu đứt giữa chừng
        ↓
    - Đối tượng mới có THỜI ĐIỂM TẠO MỚI
      → ảnh hưởng lifecycle rule theo tuổi
    - Với bucket bật versioning,
      bản cũ vẫn còn dưới dạng phiên bản

⚠ Đổi tên hàng loạt và công cụ hiện hành:

Nhiều tệp cùng lúc:
    gsutil -m mv gs://bucket/thu-muc/* gs://bucket/moi/
        ↓
    -m → chạy SONG SONG, nhanh hơn nhiều
        ↓
Công cụ mới hơn:
    gcloud storage mv gs://... gs://...
        ↓
    → nhanh hơn gsutil đáng kể với khối lượng lớn
    → Google đang chuyển sang gcloud storage

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

• B (gsutil cp) — đây là phương án gần nhất và thực hiện nửa đầu của việc, nhưng nó chỉ sao chép: tệp cũ vẫn còn nguyên, nên không phải "đổi tên".

• A (gsutil rn) — không có lệnh này.

• C (gsutil rename) — cũng không tồn tại. Trực giác từ hệ thống tệp thông thường, nhưng kho đối tượng không có thao tác đó.

Ghi nhớ

⚠ Các lệnh Cloud Storage — bảng phải thuộc: | Lệnh cũ (gsutil) | Lệnh mới (gcloud storage) | Việc | |---|---|---| | gsutil ls | gcloud storage ls | liệt kê | | gsutil cp | gcloud storage cp | sao chép | | gsutil mv | gcloud storage mv | di chuyển / đổi tên | | gsutil rm | gcloud storage rm | xoá | | gsutil rsync | gcloud storage rsync | đồng bộ thư mục | | gsutil rewrite -s | gcloud storage objects update --storage-class | đổi storage class | | -m | mặc định song song | chạy song song |

Từ khoá nhận diện:

"đổi tên tệp trong bucket" → mv (thực chất là copy + delete) "sao chép" → cp "đồng bộ thư mục" → rsync "đổi storage class" → objects update --storage-class "gsutil rename" → KHÔNG TỒN TẠI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tệp đã đổi tên chưa | gcloud storage ls gs://bucket/ | | Bản cũ còn phiên bản không | gcloud storage ls -a gs://bucket/ | | Thao tác tốn bao nhiêu | Billing report, mục Class A/B operations |

Và một điều nên cân nhắc trước khi đổi tên hàng loạt trong một bucket lớn: mỗi tệp là một lượt copy và một lượt delete. Với vài triệu đối tượng, chi phí thao tác và thời gian chạy đều đáng kể — nên nếu mục đích chỉ là tổ chức lại cho gọn, hãy cân nhắc giữ nguyên tên cũ và dùng prefix mới cho dữ liệu mới thay vì di chuyển toàn bộ quá khứ.

Đáp án

B — Bigtable.

Vì sao đúng

Ba dấu hiệu đều chỉ về Bigtable: dữ liệu cảm biến IoT, ghi khối lượng lớn với độ trễ thấp, và đang dùng HBase.

⚠ Điểm mấu chốt — Bigtable tương thích API với HBase:

Đội đang dùng HBase
        ↓
    Bigtable có HBASE CLIENT LIBRARY
        ↓
    → mã ứng dụng chuyển gần như nguyên vẹn
    → và Bigtable là DỊCH VỤ ĐƯỢC QUẢN LÝ
        ↓
    → đúng yêu cầu "chuyển sang managed service"

⚠ Đặc tính kỹ thuật khớp với IoT:

Dữ liệu cảm biến từ xe
        ↓
    - Khối lượng GHI rất lớn, liên tục
    - Cần độ trễ mili giây
    - Dữ liệu CHUỖI THỜI GIAN
        ↓
Bigtable
        ↓
    - Thông lượng ghi rất cao, mở rộng bằng thêm node
    - Độ trễ ổn định ở mili giây
    - Thiết kế riêng cho chuỗi thời gian

⚠ Nhưng ROW KEY quyết định tất cả:

Bigtable CHỈ có MỘT chỉ mục: row key
        ↓
    Row key bắt đầu bằng DẤU THỜI GIAN
        ↓
    → mọi lượt ghi dồn vào MỘT node
    → HOTSPOT, thông lượng sụp đổ
        ↓
    Mẫu đúng cho IoT:
      <ma-thiet-bi>#<dau-thoi-gian>
      hoặc thêm tiền tố băm

Xem thêm câu #12489 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án Bigtable. Chỉ khác chữ cái — ở đó là A, ở đây là B. Khoá nhất quán.

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

• A (BigQuery) — đây là phương án gần nhất vì cũng xử lý dữ liệu rất lớn, nhưng BigQuery là kho PHÂN TÍCH: tối ưu cho truy vấn quét lớn, không cho ghi từng bản ghi với độ trễ mili giây. (Mô hình phổ biến là Bigtable ghi và đọc nóng, BigQuery phân tích.)

• D (Cloud Spanner) — CSDL quan hệ có giao dịch, chi phí cao hơn nhiều và không tối ưu cho khối lượng ghi chuỗi thời gian.

• C (Cloud Dataproc) — nền tảng Hadoop/Spark, không phải CSDL.

Ghi nhớ

⚠ Bigtable — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Loại | NoSQL cột rộng, được quản lý | | Tương thích | HBase API | | Chỉ mục | CHỈ có ROW KEY | | Độ trễ | mili giây một chữ số | | Mở rộng | thêm node, thông lượng tăng tuyến tính | | Không có | giao dịch nhiều dòng, SQL đầy đủ, join | | Dùng cho | IoT, chuỗi thời gian, tài chính, cá nhân hoá |

Từ khoá nhận diện:

"HBase, IoT, chuỗi thời gian, ghi rất nhiều" → Bigtable "phân tích, SQL, báo cáo" → BigQuery "giao dịch quan hệ" → Cloud SQL hoặc Spanner "ứng dụng di động, offline" → Firestore "cache trong bộ nhớ" → Memorystore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hotspot không | Key Visualizer trong console | | Node có đủ không | chỉ số CPU utilization — nên dưới 70% | | Độ trễ thực tế | chỉ số read/write latency |

Và một việc đáng làm ngay từ giai đoạn thiết kế: thử vài mẫu row key trên dữ liệu mẫu rồi kiểm tra bằng Key Visualizer. Row key không đổi được sau khi đã có dữ liệu, và một thiết kế sai sẽ giới hạn thông lượng của cả cụm bất kể bạn thêm bao nhiêu node.

Đáp án

A — Cloud Data Fusion.

Vì sao đúng

Đề cần đường ống ETL đọc từ nhiều nguồn, biến đổi, ghi vào BigQuery — và không muốn quản máy chủ.

⚠ Điểm mấu chốt — ETL được quản lý, có giao diện kéo thả:

Cloud Data Fusion
        ↓
    Dịch vụ tích hợp dữ liệu ĐƯỢC QUẢN LÝ
    (dựa trên CDAP mã nguồn mở)
        ↓
    Hơn 150 CONNECTOR có sẵn:
      Cloud Storage, Cloud Spanner, BigQuery,
      Cloud SQL, Pub/Sub, JDBC…
        ↓
    Bên dưới chạy trên Dataproc do Google quản
        ↓
    → không dựng máy, không vá

⚠ Đúng ba việc đề mô tả:

Đọc từ Cloud Storage và Cloud Spanner
    → có connector sẵn cho cả hai
        ↓
Gộp dữ liệu hai nguồn
    → có sẵn transform Joiner
        ↓
Ghi vào BigQuery
    → có sink sẵn
        ↓
    → dựng toàn bộ mà không viết mã

Xem thêm câu #12468 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án Cloud Data Fusion. Chỉ khác chữ cái — ở đó là B, ở đây là A. Khoá nhất quán.

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

• C (Cloud Dataprep) — đây là phương án gần nhất và cũng là công cụ dữ liệu không cần mã, nhưng Dataprep hướng tới khám phá và làm sạch dữ liệu trực quan cho nhà phân tích, không phải dựng đường ống sản xuất từ nhiều nguồn hệ thống.

• D (Compute Engine) — đòi tự quản máy chủ, trái yêu cầu.

• B (Cloud Build) — dịch vụ CI/CD, không phải công cụ xử lý dữ liệu.

Ghi nhớ

⚠ Các dịch vụ dữ liệu của GCP — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Cloud Data Fusion | ETL KÉO THẢ, hơn 150 connector | | Dataflow | Apache Beam — luồng và lô, PHẢI VIẾT MÃ | | Dataproc | Hadoop và Spark được quản lý | | Dataprep | làm sạch và khám phá trực quan | | BigQuery | kho dữ liệu, SQL, serverless | | Pub/Sub | hàng đợi tin nhắn | | Composer | điều phối luồng công việc (Airflow) |

Từ khoá nhận diện:

"ETL không viết mã, không quản server" → Cloud Data Fusion "xử lý luồng, logic phức tạp" → Dataflow "đã có job Spark" → Dataproc "làm sạch dữ liệu bằng giao diện" → Dataprep "điều phối nhiều bước theo lịch" → Cloud Composer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline chạy thế nào | giao diện Data Fusion → tab Runs | | Lỗi ở bước nào | log pipeline và Cloud Logging | | Chi phí bao nhiêu | Billing, lọc Data Fusion và Dataproc |

Và một điểm chi phí đáng cân nhắc trước khi chọn Data Fusion: instance tính tiền theo giờ kể cả khi không pipeline nào chạy. Với một đội chỉ có vài đường ống chạy hằng đêm, Dataflow thường rẻ hơn nhiều vì chỉ tính tiền lúc job thực thi.

Đáp án

A — Thêm bản ghi đó vào CÀI ĐẶT DNS CỦA TÊN MIỀN.

Vì sao đúng

Google cần bằng chứng bạn thực sự sở hữu tên miền, và cách chuẩn của toàn ngành là đặt một bản ghi vào DNS của tên miền đó.

⚠ Điểm mấu chốt — chỉ chủ sở hữu mới sửa được DNS:

Google cấp một chuỗi xác minh
        ↓
    Bạn thêm nó vào DNS của tên miền:
      - bản ghi TXT (phổ biến nhất), hoặc
      - bản ghi CNAME
        ↓
    Google truy vấn DNS công khai của tên miền
        ↓
    Thấy đúng chuỗi
        ↓
    → chứng minh bạn kiểm soát tên miền
    → vì chỉ chủ sở hữu mới sửa được DNS

⚠ Vì sao xác minh tên miền lại quan trọng với Cloud Identity:

Cloud Identity quản lý DANH TÍNH
theo tên miền của bạn
        ↓
    Ví dụ: nhanvien@congty.com
        ↓
    Không xác minh sở hữu
        ↓
    → bất kỳ ai cũng có thể tạo tài khoản
      với tên miền của người khác
        ↓
    → xác minh là điều kiện bắt buộc
      trước khi tạo danh tính

⚠ Và đây là bước nền của cả tổ chức Google Cloud:

Xác minh tên miền
        ↓
Tạo Cloud Identity (hoặc Workspace)
        ↓
    → TỰ ĐỘNG sinh ra một ORGANIZATION
      trong Google Cloud
        ↓
    → từ đó mới có phân cấp
      Organization → Folder → Project
    → mới áp được Organization Policy
        ↓
    Không có tổ chức thì project nằm rời rạc,
    không quản trị tập trung được

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

• B (thêm vào cài đặt IAM của từng danh tính) — IAM quyết định AI ĐƯỢC LÀM GÌ, không liên quan tới việc chứng minh sở hữu tên miền.

• C (thêm vào tài khoản thanh toán) — billing account xử lý việc trả tiền, không có chỗ nào cho bản ghi xác minh.

• D (thêm vào metadata của từng tài nguyên) — metadata là dữ liệu gắn kèm một tài nguyên cụ thể (ví dụ startup script của VM), hoàn toàn khác.

Ghi nhớ

⚠ Cloud Identity — bảng phải thuộc: | Nội dung | Chi tiết | |---|---| | Việc | quản lý danh tính và thiết bị cho tổ chức | | Điều kiện | xác minh sở hữu tên miền qua DNS | | Kết quả | tự tạo một ORGANIZATION trong Google Cloud | | Bản miễn phí | Cloud Identity Free — số lượng người dùng có giới hạn | | Bản trả phí | Cloud Identity Premium — thêm quản lý thiết bị, bảo mật nâng cao | | So với Workspace | Workspace bao gồm Cloud Identity + Gmail, Drive… |

Từ khoá nhận diện:

"xác minh tên miền" → bản ghi TXT hoặc CNAME trong DNS "tạo tổ chức trong Google Cloud" → Cloud Identity hoặc Workspace "đồng bộ người dùng từ Active Directory" → Google Cloud Directory Sync (GCDS) "đăng nhập bằng IdP có sẵn" → SAML SSO "ai được làm gì" → IAM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản ghi đã lan truyền chưa | dig TXT congty.com | | Tên miền đã xác minh chưa | Google Admin console → Domains | | Tổ chức đã được tạo chưa | gcloud organizations list |

Và một điều cần kiên nhẫn ở bước này: bản ghi DNS cần thời gian lan truyền. Sau khi thêm, có thể mất từ vài phút tới vài giờ tuỳ TTL của tên miền trước khi Google nhìn thấy — nên nếu xác minh thất bại ngay lập tức, hãy dùng dig để kiểm tra bản ghi đã thực sự công khai chưa trước khi nghi ngờ chuỗi xác minh bị sai.

Đáp án

C — gcloud config configurations create

Vì sao đúng

Cấu trúc lệnh gcloud là nhóm — nhóm con — động từ, và configurations nằm trong nhóm config.

⚠ Điểm mấu chốt:

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
    → "gcloud configurations create" là SAI

⚠ Configuration 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 vào project sản xuất

⚠ Phân biệt create, 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

Xem thêm câu #12480 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án. Chỉ khác chữ cái — ở đó là A, ở đây là C. Khoá nhất quán.

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

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

• A và D (gcloud configurations ...) — thiếu nhóm config.

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 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 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 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 tránh được một loại sự cố rất khó chịu: hiện tên configuration đang hoạt động trong dấu nhắc shell. Phần lớn các lần chạy nhầm lệnh vào production bắt nguồn từ việc quên phiên terminal đang trỏ vào đâu — và một dòng chữ trong dấu nhắc giải quyết triệt để chuyện đó.

Đáp án

B — roles/owner

Vì sao đúng

Người tạo ra một project tự động trở thành chủ sở hữu của project đó — đây là hành vi mặc định của Google Cloud.

⚠ Điểm mấu chốt — người tạo là chủ sở hữu:

Người dùng tạo một project mới
        ↓
    Google Cloud TỰ ĐỘNG gán
      roles/owner
    cho chính người đó
        ↓
    → toàn quyền trên project:
      quản tài nguyên, quản IAM,
      xoá cả project
        ↓
    → hợp lý, vì họ cần cấu hình project vừa tạo

⚠ Nhưng đây là một vai trò BASIC, và rất rộng:

roles/owner
        ↓
    Bao gồm:
      - mọi quyền của editor
      - QUẢN LÝ IAM (thêm, xoá người khác)
      - xoá project
      - cấu hình thanh toán (ở một mức độ)
        ↓
    → cực kỳ rộng
    → không nên là trạng thái lâu dài
      của một dự án production

⚠ Việc nên làm ngay sau khi tạo project:

1. Gán các vai trò PREDEFINED hẹp hơn
   cho từng người và từng nhóm
        ↓
2. Chuyển quyền owner sang một GROUP quản trị
   thay vì một cá nhân
        ↓
3. Gỡ owner của cá nhân đó
        ↓
    → tránh tình trạng "project của một người"
      mà khi họ nghỉ việc thì không ai vào được
        ↓
    Và kiểm soát ở tầng trên:
      Organization Policy + IAM ở cấp folder

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

• D (roles/editor) — đây là phương án gần nhất và cũng là một vai trò rất rộng, nhưng editor KHÔNG quản lý được IAM và không xoá được project. Người tạo project cần cả hai, nên vai trò được gán là owner.

• A (roles/viewer) — chỉ đọc, không đủ để cấu hình bất cứ thứ gì.

• C (roles/browser) — chỉ cho xem phân cấp tài nguyên (project, folder), rất hẹp.

Ghi nhớ

⚠ Bốn vai trò basic của Google Cloud — bảng phải thuộc: | Vai trò | Quyền | |---|---| | roles/owner | mọi thứ của editor + QUẢN LÝ IAM + xoá project | | roles/editor | tạo, sửa, xoá TÀI NGUYÊN — không quản IAM | | roles/viewer | chỉ đọc | | roles/browser | chỉ xem phân cấp (project, folder, organization) | | Khuyến nghị | tránh dùng basic role cho production — quá rộng |

Từ khoá nhận diện:

"người tạo project được vai trò gì" → roles/owner "quản lý tài nguyên nhưng không quản IAM" → roles/editor "chỉ xem" → roles/viewer "thực hành tốt về bảo mật" → predefined role, không dùng basic "predefined vẫn quá rộng" → custom role

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai là owner của project | gcloud projects get-iam-policy <id> | | Có quyền nào thừa không | IAM Recommender | | Project nằm ở đâu trong phân cấp | gcloud projects describe <id> → xem parent |

Và một việc rất nên làm định kỳ ở mọi tổ chức: rà soát danh sách những ai đang giữ roles/owner. Vai trò này thường được gán trong lúc dựng dự án rồi không ai gỡ ra, nên sau vài năm số người có toàn quyền trên các project production thường lớn hơn nhiều so với những gì bất kỳ ai còn nhớ.

Đáp án

B — App Engine.

Vì sao đúng

Bốn ràng buộc của đề: tải rất thấp phần lớn thời gian, có lúc tăng đột biến, chi phí thấp nhất, ít công quản lý.

⚠ Điểm mấu chốt — App Engine Standard co giãn tới KHÔNG:

Không có request → co về 0 instance
        ↓
    → gần như KHÔNG TỐN TIỀN khi nhàn rỗi
        ↓
Có đợt tăng đột biến
        ↓
    → tự khởi chạy thêm instance trong vài giây
    → cold start rất nhanh với runtime Python
        ↓
    Và bạn KHÔNG quản máy chủ, không vá,
    không cấu hình load balancer

⚠ App Engine Standard ↔ Flexible:

STANDARD
        ↓
    Sandbox, runtime dựng sẵn
    CO VỀ 0, khởi động trong GIÂY
    → rẻ nhất khi tải thấp

FLEXIBLE
        ↓
    Container trên Compute Engine
    KHÔNG co về 0 — luôn ≥ 1 instance
    Khởi động chậm hơn (phút)
    → dùng khi cần thư viện hệ thống đặc thù

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

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

• C (Cloud Functions) — đây là phương án gần nhất và cũng co về 0, nhưng nó hướng tới hàm phản ứng với một sự kiện, không phải một ứng dụng có nhiều route. Về mô hình, App Engine sát hơn.

• D (Kubernetes Engine) — rất nhiều công quản lý, và cụm phải chạy liên tục nên tốn tiền cả khi không có tải.

• A (Compute Engine) — tự quản máy hoàn toàn, trái yêu cầu.

Ghi nhớ

⚠ Năm lựa chọn tính toán của GCP — bảng phải thuộc: | Dịch vụ | Đặc điểm | |---|---| | Compute Engine | VM — bạn quản mọi thứ | | GKE | Kubernetes được quản lý | | Cloud Run | container serverless, co về 0 | | App Engine | PaaS — đẩy mã lên là chạy, co về 0 (Standard) | | Cloud Functions | hàm phản ứng với sự kiện | | Thứ tự công sức | Compute Engine > GKE > App Engine Flexible > Cloud Run ≈ App Engine Standard > Cloud Functions |

Từ khoá nhận diện:

"web app, ít công, co về 0" → App Engine Standard hoặc Cloud Run "phản ứng với sự kiện" → Cloud Functions "đã có container" → Cloud Run "microservice phức tạp" → GKE "App Engine Flexible" → KHÔNG co về 0

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang chạy mấy instance | App Engine → Instances | | Cold start bao lâu | Cloud Trace, hoặc log request đầu tiên | | Chi phí thực tế | Billing report, lọc App Engine |

Và một cấu hình đáng cân nhắc nếu độ trễ request đầu tiên là vấn đề: đặt min_instances bằng 1. Nó giữ một instance luôn ấm nên hết cold start, đổi lại trả tiền cho instance đó suốt ngày đêm — đánh đổi rất đáng với API phục vụ người dùng thật.