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

Đáp án

D — Tạo SUBNET ở những REGION mà bạn dự định triển khai instance.

Vì sao đúng

Mạng ở chế độ custom mode được tạo ra hoàn toàn TRỐNG — không có subnet nào cả.

⚠ Điểm mấu chốt — hai chế độ mạng của GCP:

AUTO MODE
        ↓
    Tự tạo MỘT subnet ở MỌI Region
    với dải IP định sẵn (10.128.0.0/9)
        ↓
    → tiện cho việc thử nghiệm
    → nhưng không kiểm soát được dải IP

CUSTOM MODE                          ← đề này
        ↓
    KHÔNG có subnet nào
        ↓
    → bạn tự tạo subnet ở đúng Region cần
    → tự chọn dải CIDR
        ↓
    → khuyến nghị cho production

⚠ Và vì sao chỉ tạo ở Region CẦN, không tạo ở MỌI Region:

Tạo subnet ở mọi Region (phương án C)
        ↓
    → tiêu tốn không gian địa chỉ IP
    → tăng bề mặt cần quản lý và bảo mật
    → nhiều subnet không bao giờ dùng tới
        ↓
Chỉ tạo ở Region cần
        ↓
    → quy hoạch IP gọn gàng
    → thêm sau lúc nào cũng được
        ↓
    (Subnet của GCP mở rộng được dải IP,
     nhưng KHÔNG thu nhỏ được)

⚠ Nhắc lại một khác biệt lớn so với AWS:

GCP: VPC là TOÀN CẦU, subnet theo REGION
AWS: VPC theo Region, subnet theo AZ
        ↓
    → ở GCP, MỘT subnet phục vụ được
      VM ở MỌI zone trong Region đó
    → không cần tạo subnet cho từng zone

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

• C (tạo subnet ở TẤT CẢ các Region) — đây là phương án gần nhất và về kỹ thuật thì làm được, nhưng lãng phí không gian IP và tạo ra hàng chục subnet không dùng tới. Thêm subnet khi cần là việc rất nhanh.

• A (tạo firewall rule để cân bằng tải) — firewall rule không cân bằng tải; và chưa có subnet thì cũng chưa có gì để bảo vệ.

• B (tạo VPN giữa custom mode network và các mạng khác trong VPC) — các subnet trong CÙNG một VPC đã thông với nhau sẵn, không cần VPN.

Ghi nhớ

⚠ Auto mode ↔ Custom mode — bảng phải thuộc: | | Auto mode | Custom mode | |---|---|---| | Subnet ban đầu | một subnet ở MỌI Region | KHÔNG có subnet nào | | Dải IP | định sẵn 10.128.0.0/9 | bạn tự chọn | | Region mới của Google | tự thêm subnet | không | | Khuyến nghị | thử nghiệm | PRODUCTION | | Chuyển đổi | auto → custom được | custom → auto KHÔNG được |

Từ khoá nhận diện:

"custom mode network vừa tạo" → bước tiếp theo là TẠO SUBNET "kiểm soát dải IP" → custom mode "VPC của GCP" → TOÀN CẦU, subnet theo REGION "subnet hết địa chỉ" → mở rộng được, không thu nhỏ được "nối hai VPC" → peering hoặc Shared VPC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mạng có subnet nào chưa | gcloud compute networks subnets list --network=<ten> | | Mạng ở chế độ nào | gcloud compute networks describe <ten> → subnetMode | | Dải IP có chồng lấn không | so sánh với sơ đồ IP của tổ chức |

Và một lưu ý phải tính tới ngay khi chọn dải CIDR cho subnet: subnet của GCP mở rộng được nhưng không bao giờ thu nhỏ. Chọn một dải quá hẹp nghĩa là phải tạo subnet mới và di chuyển VM về sau; chọn quá rộng thì chiếm mất không gian địa chỉ mà một VPC khác có thể cần khi peering — nên đây là quyết định đáng dành thời gian ngay từ đầu.

Đáp án

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

Vì sao đúng

Hai điều cần đúng: công cụ là kubectl, và động từ là autoscale.

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

gcloud container clusters ...
        ↓
    Tạo, xoá, nâng cấp CỤM; quản node pool
        ↓
kubectl ...
        ↓
    Pod, deployment, replication controller,
    service, HPA — BÊN TRONG cụm
        ↓
    → co giãn pod là việc bên trong cụm
    → phải dùng kubectl

⚠ kubectl autoscale nhận nhiều loại tài nguyên:

kubectl autoscale rc my-app-rc \
  --min=2 --max=6 --cpu-percent=80
        ↓
    Áp được cho:
      rc          (replication controller)
      deployment
      replicaset
      statefulset
        ↓
    → tạo ra một HorizontalPodAutoscaler

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

HPA tính % CPU SO VỚI `resources.requests.cpu`
        ↓
    Container không khai `requests`
        ↓
    → không có mẫu số
    → kubectl get hpa hiện <unknown>
    → autoscaler KHÔNG hoạt động

Xem thêm câu #12472 (CÙNG LÔ): gần như cùng một câu hỏi (ở đó là deployment, ở đây là rc), cùng đáp án kubectl autoscale. 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

• D (kubectl apply rc ...) — đâ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.

• A và C (gcloud containers ...) — sai hai lần: nhóm đúng là gcloud container (số ít), và gcloud không quản HPA.

Ghi nhớ

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

Từ khoá nhận diện:

"co giãn số POD" → kubectl autoscale (HPA) "thêm NODE" → Cluster Autoscaler "chỉnh tài nguyên mỗi pod" → VPA "áp một tệp YAML" → kubectl apply -f "tạo cụm" → gcloud container clusters create

Ba việc kiểm chứng: | Việc | Cách | |---|---| | HPA có hoạt động không | kubectl get hpa | | Vì sao không co giãn | kubectl describe hpa <ten> — đọc Events | | Pod dùng bao nhiêu | 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. Cột TARGETS hiện <unknown>, autoscaler không có mẫu số để tính, và số pod nằm im ở 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 deployment.

Đáp án

B — roles/bigtable.reader

Vì sao đúng

Nhóm này chỉ cần ĐỌC dữ liệu, và thực hành tốt về bảo mật là quyền tối thiểu.

⚠ Điểm mấu chốt — chọn vai trò hẹp nhất đủ dùng:

Nhu cầu: ĐỌC dữ liệu từ Bigtable
        ↓
    roles/bigtable.reader
        ↓
    → chỉ đọc dữ liệu trong bảng
    → không ghi, không sửa lược đồ,
      không quản instance

⚠ Bốn vai trò Bigtable — thang từ hẹp tới rộng:

roles/bigtable.reader   → ĐỌC dữ liệu      ← đề này
roles/bigtable.user     → đọc VÀ GHI dữ liệu
roles/bigtable.admin    → quản instance, cluster, bảng
roles/bigtable.owner    → toàn quyền, kể cả xoá instance

Xem thêm câu #12469 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án roles/bigtable.reader, và cũng cùng chữ cái B. Khoá nhất quán.

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

• D (roles/bigtable.user) — đây là phương án gần nhất và cũng đọc được, nhưng nó cấp thêm quyền GHI — thừa so với nhu cầu.

• A (roles/bigtable.admin) — cho quản lý instance, cluster và lược đồ, rộng hơn nhiều.

• C (roles/bigtable.owner) — rộng nhất, kể cả xoá instance.

Ghi nhớ

⚠ Ba loại vai trò IAM — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | Basic | viewer / editor / owner — quá rộng, tránh dùng | | Predefined | theo dịch vụ, Google bảo trì — NÊN DÙNG | | Custom | tự chọn permission — bạn tự bảo trì | | Nguyên tắc | bắt đầu từ predefined hẹp nhất đủ dùng |

Từ khoá nhận diện:

"chỉ cần đọc" → reader hoặc viewer "đọc và ghi" → user (với Bigtable) "quản lý tài nguyên" → admin "thực hành tốt về bảo mật" → quyền tối thiểu "predefined vẫn quá rộng" → custom role

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền gì | gcloud projects get-iam-policy <project> | | Vai trò gồm permission nào | gcloud iam roles describe roles/bigtable.reader | | Có quyền nào thừa không | IAM Recommender |

Và một công cụ đáng dùng định kỳ: IAM Recommender. Nó phân tích 90 ngày sử dụng thật rồi gợi ý thay vai trò rộng bằng vai trò hẹp hơn — cách nhanh nhất để siết quyền mà không phải đoán ai còn cần gì.

Đáp án

B — kubectl apply -f my-app.yaml

Vì sao đúng

Triển khai một manifest lên cụm Kubernetes là việc bên trong cụm, nên dùng kubectl, và cờ để chỉ tệp là -f.

⚠ Điểm mấu chốt — cú pháp đầy đủ:

kubectl apply -f my-app.yaml
        ↓
    apply → tạo mới nếu chưa có,
            CẬP NHẬT nếu đã có
        ↓
    -f    → chỉ định tệp (file)
        ↓
    Thiếu -f → kubectl coi "my-app.yaml"
               là TÊN TÀI NGUYÊN, không phải tệp

⚠ apply khác create ở điểm quan trọng:

kubectl create -f tep.yaml
        ↓
    Chỉ TẠO MỚI
    → tài nguyên đã tồn tại → LỖI

kubectl apply -f tep.yaml
        ↓
    Tạo mới HOẶC cập nhật
    → khai báo (declarative)
    → chạy lại nhiều lần được
        ↓
    → đây là cách nên dùng trong CI/CD

⚠ Vài dạng khác của -f rất hữu ích:

kubectl apply -f thu-muc/          → cả thư mục
kubectl apply -f https://...       → từ URL
kubectl apply -k thu-muc/          → Kustomize
kubectl apply -f - <<EOF ... EOF   → từ stdin
        ↓
kubectl diff -f tep.yaml
        ↓
    → XEM TRƯỚC thay đổi mà không áp
    → rất nên dùng trước khi apply lên production

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

• D (kubectl deployment apply my-app.yaml) — đây là phương án gần nhất vì dùng đúng công cụ, nhưng sai cấu trúc: kubectl là kubectl <động từ> <loại tài nguyên>, không phải ngược lại. Và vẫn thiếu cờ -f.

• A (gcloud deployment apply ...) — gcloud không triển khai manifest Kubernetes. (Có gcloud deployment-manager nhưng đó là công cụ hạ tầng dạng mã của GCP, khác hẳn.)

• C (gcloud containers deployment apply ...) — sai nhóm lệnh (container số ít), sai công cụ, và sai cấu trúc.

Ghi nhớ

⚠ Cấu trúc lệnh kubectl — bảng phải thuộc: | Cấu trúc | Ví dụ | |---|---| | kubectl <động từ> <loại> <tên> | kubectl get pod my-pod | | kubectl <động từ> -f <tệp> | kubectl apply -f app.yaml | | Động từ hay dùng | get, describe, apply, delete, logs, exec, scale, rollout | | Loại tài nguyên | pod, deployment, service, configmap, secret, ingress, hpa | | Viết tắt | po, deploy, svc, cm, ns |

Từ khoá nhận diện:

"triển khai manifest" → kubectl apply -f "xem trước thay đổi" → kubectl diff -f "tạo cụm" → gcloud container clusters create "kết nối kubectl với cụm" → gcloud container clusters get-credentials "gcloud triển khai YAML" → luôn SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang trỏ vào cụm nào | kubectl config current-context | | Triển khai xong chưa | kubectl rollout status deployment/<ten> | | Có gì thay đổi | kubectl diff -f app.yaml trước khi apply |

Và một thói quen nên có trước mọi lần apply lên production: chạy kubectl config current-context để xác nhận đang trỏ đúng cụm. Phần lớn các sự cố triển khai nhầm môi trường bắt nguồn từ việc context còn sót lại từ một phiên làm việc trước — và một lệnh mất một giây sẽ tránh được điều đó.

Đáp án

B — Target pool THIẾU HEALTH CHECK.

Vì sao đúng

Target pool bắt buộc phải có health check thì load balancer mới biết gửi lưu lượng tới instance nào.

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

Target pool
        ↓
    Danh sách instance nhận lưu lượng
        ↓
    Health check quyết định instance nào KHOẺ
        ↓
    Không có health check
        ↓
    → load balancer không xác định được
      trạng thái backend
    → hoạt động không như mong đợi

⚠ Và instance ở hai zone KHÔNG phải lỗi:

Target pool có phạm vi THEO REGION
        ↓
    → chứa instance ở NHIỀU ZONE
      trong CÙNG Region là bình thường
        ↓
    → chi tiết "hai zone" trong đề
      là để đánh lạc hướng

⚠ Nguyên nhân số hai — firewall chặn probe:

Health check probe đến từ hai dải:
    130.211.0.0/22
    35.191.0.0/16
        ↓
    Firewall phải cho phép ingress từ hai dải này
        ↓
    → thiếu luật này là MỌI backend
      bị đánh dấu UNHEALTHY

Xem thêm câu #12485 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án thiếu health check. 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 (không gửi log sang Cloud Logging) — đây là phương án gần nhất về hình thức, nhưng log chỉ để chẩn đoán, không ảnh hưởng tới chức năng định tuyến.

• D (không gửi chỉ số sang Cloud Monitoring) — cùng lý do: chỉ số để quan sát, không quyết định định tuyến.

• C (các node có cấu hình bộ nhớ khác nhau) — target pool không đòi instance phải giống nhau về phần cứng.

Ghi nhớ

⚠ Health check của Google Cloud — bảng phải thuộc: | Nội dung | Chi tiết | |---|---| | Dải IP của probe | 130.211.0.0/22 và 35.191.0.0/16 | | Firewall | PHẢI cho phép ingress từ hai dải đó | | Loại | HTTP, HTTPS, HTTP/2, TCP, SSL, gRPC | | Tham số | check-interval, timeout, healthy-threshold, unhealthy-threshold | | Dùng cho | load balancer và autohealing của MIG | | Legacy | chỉ target pool dùng legacy HTTP health check |

Từ khoá nhận diện:

"target pool không hoạt động" → thiếu health check "mọi backend unhealthy" → firewall chưa mở dải probe "tự tạo lại VM hỏng" → autohealing của MIG "định tuyến theo URL" → backend service, không phải target pool "giữ IP nguồn client" → passthrough Network LB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backend khoẻ không | gcloud compute target-pools get-health <ten> --region=<region> | | Firewall đã mở chưa | gcloud compute firewall-rules list --filter="sourceRanges:130.211.0.0/22" | | Ứng dụng trả 200 không | curl tới đường dẫn health check từ trong VPC |

Và một nguyên nhân chiếm phần lớn các ca "mọi backend unhealthy" trên Google Cloud: firewall chưa mở cho hai dải IP của probe. Ứng dụng chạy bình thường, curl từ máy khác trong VPC vẫn trả 200, nhưng probe của Google không tới được — và triệu chứng nhìn từ console giống hệt như ứng dụng đang chết.

Đáp án

A — Tạo SHARED VPC.

Vì sao đúng

Nhiều project trong cùng một tổ chức muốn dùng chung một mạng — đó chính là bài toán Shared VPC giải.

⚠ Điểm mấu chốt — tách quản trị mạng khỏi tải công việc:

HOST PROJECT
        ↓
    Chứa VPC, subnet, firewall rule,
    Cloud Router, Cloud NAT
    → đội hạ tầng quản lý
        ↓
SERVICE PROJECT (nhiều cái)
        ↓
    Chứa VM, GKE, Cloud SQL của từng tầng
    → từng đội phát triển quản lý
        ↓
    Tài nguyên trong service project
    DÙNG TRỰC TIẾP subnet của host project
        ↓
    → cùng dải IP riêng, giao tiếp nội bộ
    → KHÔNG cần peering
    → chi phí và quyền vẫn tách theo project

⚠ Hai vai trò IAM cần nhớ:

roles/compute.xpnAdmin
        ↓
    Gắn ở cấp TỔ CHỨC hoặc FOLDER
    → chỉ định host project, gắn service project

roles/compute.networkUser
        ↓
    Gắn cho người dùng của SERVICE PROJECT
    → cho phép họ tạo tài nguyên trong subnet
      của host project
    → cấp được ở mức TỪNG SUBNET

Xem thêm câu #12467 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án Shared VPC. Chỉ khác chữ cái — ở đó là B, ở đây là A. Và #12470 (cùng lô): nhiều TỔ CHỨC thì khoá là VPC Peering — khoá khác nhau vì phạm vi khác nhau, không mâu thuẫn.

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

• D (tạo route giữa các subnet của từng project) — đây là phương án gần nhất về ý tưởng, nhưng mỗi project có VPC riêng biệt; không có route nào nối thẳng hai VPC mà không qua peering hoặc VPN. Và vẫn không phải "một VPC chung".

• B (tạo VPN giữa các project) — chạy được nhưng rất thừa: thêm chi phí gateway, thêm độ trễ, cho các project trong cùng một tổ chức.

• C (tạo firewall rule để cân bằng tải giữa subnet các project) — firewall không cân bằng tải và không tạo đường đi.

Ghi nhớ

⚠ Ba cách nối mạng của Google Cloud — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Shared VPC | nhiều project CÙNG tổ chức dùng CHUNG một VPC | | VPC Peering | nối hai VPC riêng biệt — kể cả khác tổ chức | | Cloud VPN / Interconnect | nối với mạng TẠI CHỖ | | Network Connectivity Center | trung tâm nối nhiều mạng | | Private Service Connect | gọi dịch vụ bên khác qua IP riêng |

Từ khoá nhận diện:

"nhiều project, một mạng chung, CÙNG tổ chức" → Shared VPC "nhiều TỔ CHỨC" → VPC Peering "nối với trung tâm dữ liệu" → Cloud VPN hoặc Interconnect "quản mạng tập trung" → Shared VPC "nhiều VPC nối chằng chịt" → Network Connectivity Center

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Project có phải host không | gcloud compute shared-vpc get-host-project <project> | | Service project nào đang gắn | gcloud compute shared-vpc list-associated-resources <host> | | Ai được dùng subnet | gcloud compute networks subnets get-iam-policy <subnet> |

Và một cách phân quyền nên áp dụng ngay từ đầu: cấp compute.networkUser ở mức TỪNG SUBNET, không phải cả host project. Khi đó mỗi đội chỉ dựng được máy trong đúng subnet của họ, và bạn giữ được ranh giới mạng rõ ràng mà không cần nhiều VPC.

Đáp án

C — INSTANCE TEMPLATE (mẫu instance).

Vì sao đúng

Managed Instance Group bắt buộc dựa trên một instance template — bản thiết kế để tạo ra mọi VM giống hệt nhau.

⚠ Điểm mấu chốt — template là điều kiện tiên quyết:

Instance template
        ↓
    Khai sẵn: loại máy, image, đĩa, mạng,
    network tag, service account, startup script
        ↓
    → BẤT BIẾN, không sửa được sau khi tạo
        ↓
MIG dùng template đó
        ↓
    → mọi VM sinh ra GIỐNG HỆT NHAU
    → autoscaler thêm máy = tạo từ template
        ↓
    Không có template → không tạo được MIG

⚠ Autoscaler của MIG:

Gắn autoscaling policy vào MIG
        ↓
    Chỉ số: CPU utilization,
            HTTP LB utilization,
            Cloud Monitoring metric,
            số message Pub/Sub
        ↓
    Khai min, max, coolDownPeriod
        ↓
    → MIG tự thêm bớt VM

Xem thêm câu #12484 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án instance template. 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

• D (Load balancer) — đây là phương án gần nhất vì load balancer thường đi kèm MIG, nhưng nó phân phối lưu lượng, không phải thứ MIG dựa vào để tạo máy. MIG hoạt động được cả khi không có load balancer.

• A (Snapshot) — bản sao lưu của một đĩa, dùng để khôi phục hoặc tạo image, không phải bản thiết kế của MIG.

• B (Persistent Disk) — một đĩa lưu trữ, là thành phần của VM.

Ghi nhớ

⚠ Các thành phần của MIG — bảng phải thuộc: | Thành phần | Việc | |---|---| | Instance template | BẢN THIẾT KẾ — bắt buộc, BẤT BIẾN | | Managed Instance Group | quản một nhóm VM giống hệt nhau | | Autoscaling policy | thêm bớt VM theo chỉ số | | Health check | autohealing và cho load balancer | | Update policy | rolling update, canary | | Regional MIG | trải nhiều zone |

Từ khoá nhận diện:

"tự thêm VM khi tải cao" → MIG + autoscaling policy "tự thay VM hỏng" → autohealing với health check "cập nhật không gián đoạn" → rolling update "chịu được mất một zone" → regional MIG "VM khác nhau, không co giãn" → unmanaged instance group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | MIG dùng template nào | gcloud compute instance-groups managed describe <ten> | | Autoscaler có hoạt động không | cùng lệnh, xem trường autoscaler | | VM có bị tạo lại liên tục không | Cloud Logging, tìm sự kiện autohealing |

Và một cấu hình cần đặt cẩn thận khi bật autohealing: initialDelaySec của health check. Nếu ngắn hơn thời gian ứng dụng khởi động, MIG sẽ liên tục đánh dấu VM là hỏng rồi tạo lại — một vòng lặp mà nhìn từ bên ngoài giống hệt một sự cố hạ tầng.

Đáp án

B — SHIELDED VM.

Vì sao đúng

Đề nói rõ mối lo: rootkit và mã độc ở TẦNG NHÂN (kernel). Shielded VM là tính năng của Google Cloud sinh ra đúng cho việc đó.

⚠ Điểm mấu chốt — ba lớp bảo vệ của Shielded VM:

SECURE BOOT
        ↓
    Chỉ cho khởi động phần mềm ĐÃ KÝ
    và có chữ ký hợp lệ
        ↓
    → chặn bootkit và driver nhân không được ký

vTPM (virtual Trusted Platform Module)
        ↓
    Module bảo mật ảo, đo lường trạng thái khởi động
    Lưu khoá và bí mật ở nơi cách ly
        ↓
    → nền tảng cho measured boot

INTEGRITY MONITORING
        ↓
    So SÁNH phép đo khởi động hiện tại
    với BASELINE đã biết là tốt
        ↓
    → thay đổi bất thường ở nhân
      → sinh cảnh báo trong Cloud Monitoring
    → đây chính là cách phát hiện rootkit

⚠ Bật thế nào và điều kiện:

Cần một SHIELDED IMAGE
        ↓
    Hầu hết image công khai của Google
    đã hỗ trợ (có hậu tố hoặc gắn nhãn UEFI)
        ↓
    Bật khi tạo VM, hoặc trong instance template:
      --shielded-secure-boot
      --shielded-vtpm
      --shielded-integrity-monitoring
        ↓
    Ép toàn tổ chức:
      Organization Policy
      constraints/compute.requireShieldedVm

⚠ Phân biệt với Confidential VM:

SHIELDED VM
        ↓
    Bảo vệ TÍNH TOÀN VẸN của quá trình khởi động
    → chống rootkit, bootkit

CONFIDENTIAL VM
        ↓
    MÃ HOÁ BỘ NHỚ khi đang dùng
    → dữ liệu trong RAM cũng được mã hoá
    → chống cả người vận hành hạ tầng
        ↓
    → hai mục tiêu khác nhau, dùng chung được

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

• A ("Hardened VM") — đây là phương án gần nhất vì tên nghe rất hợp lý, nhưng Google Cloud không có loại VM nào tên là "Hardened VM". Đây là phương án bịa.

• C (Preemptible VM) — VM giá rẻ có thể bị thu hồi bất cứ lúc nào, là một mô hình chi phí, không liên quan tới bảo mật.

• D (GPU-enabled VM) — VM có card đồ hoạ, phục vụ tính toán song song, không liên quan tới bảo vệ nhân.

Ghi nhớ

⚠ Các tính năng bảo mật VM của Google Cloud — bảng phải thuộc: | Tính năng | Bảo vệ gì | |---|---| | Shielded VM | TOÀN VẸN khởi động — chống rootkit, bootkit | | Confidential VM | MÃ HOÁ BỘ NHỚ khi đang dùng | | OS Login | quản lý người dùng SSH bằng IAM | | CMEK | mã hoá đĩa bằng khoá của bạn | | Private IP + Cloud NAT | không lộ VM ra internet | | Binary Authorization | (với GKE) chỉ chạy image đã ký |

Từ khoá nhận diện:

"rootkit, mã độc tầng nhân, toàn vẹn khởi động" → Shielded VM "dữ liệu trong BỘ NHỚ phải được mã hoá" → Confidential VM "VM giá rẻ, chịu được bị thu hồi" → Spot / Preemptible VM "quản lý khoá SSH tập trung" → OS Login "ép mọi VM phải là Shielded" → Organization Policy compute.requireShieldedVm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM có phải Shielded không | gcloud compute instances describe <ten> → shieldedInstanceConfig | | Có cảnh báo toàn vẹn nào không | Cloud Logging, lọc integrity monitoring | | Image có hỗ trợ không | gcloud compute images list --filter="guestOsFeatures:UEFI_COMPATIBLE" |

Và một cấu hình rất đáng bật ngay ở cấp tổ chức: constraints/compute.requireShieldedVm. Nó biến việc bật Shielded VM từ một lựa chọn mà mỗi người có thể quên, thành một yêu cầu bắt buộc với mọi máy được tạo ra từ đó về sau — kể cả những máy do tự động hoá dựng lên lúc nửa đêm.

Đáp án

C — Dùng tuỳ chọn --dry-run với lệnh bq query.

Vì sao đúng

BigQuery tính tiền theo lượng dữ liệu QUÉT, và --dry-run cho biết con số đó mà không chạy truy vấn.

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

bq query --dry-run --use_legacy_sql=false \
  'SELECT ... FROM ...'
        ↓
    BigQuery PHÂN TÍCH truy vấn
        ↓
    Trả về số BYTE sẽ được quét
        ↓
    → KHÔNG chạy, KHÔNG tính tiền
    → so sánh được nhiều cách viết truy vấn

⚠ Và những cách giảm dữ liệu quét:

1. ĐỪNG DÙNG SELECT *
        ↓
    BigQuery lưu theo CỘT
    → chỉ quét cột được nêu tên

2. PHÂN VÙNG theo ngày
        ↓
    WHERE ngay BETWEEN ... → chỉ quét phân vùng đó

3. PHÂN CỤM theo cột hay lọc
        ↓
    → bỏ qua khối dữ liệu không khớp

4. LIMIT KHÔNG giảm chi phí
        ↓
    → vẫn quét toàn bộ rồi mới cắt

Xem thêm câu #12466 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án --dry-run. 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 (--estimate-cost với lệnh bq) — đây là phương án gần nhất và nghe rất hợp lý, nhưng cờ này không tồn tại. Cờ đúng là --dry-run.

• D (--estimate-cost với gcloud) — sai cả cờ lẫn công cụ: BigQuery dùng bq.

• A (Pricing Calculator) — ước tính chi phí hạ tầng ở mức tổng quát dựa trên con số bạn tự nhập, không phân tích một truy vấn cụ thể.

Ghi nhớ

⚠ Hai mô hình tính giá BigQuery — bảng phải thuộc: | Mô hình | Cách tính | |---|---| | On-demand | theo TB dữ liệu QUÉT — có mức miễn phí mỗi tháng | | Capacity (slot) | mua slot — chi phí cố định, đoán trước được | | Lưu trữ | active và long-term (không sửa 90 ngày → rẻ hơn) | | Chọn capacity khi | khối lượng truy vấn lớn và ổn định |

Từ khoá nhận diện:

"biết chi phí trước khi chạy" → bq query --dry-run "giảm chi phí truy vấn" → partition, cluster, bỏ SELECT * "chi phí ổn định" → capacity pricing "giới hạn chi tiêu" → custom quota, --maximum_bytes_billed "truy vấn lặp lại" → kết quả được cache 24 giờ, MIỄN PHÍ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu | bq query --dry-run | | Bảng có partition không | bq show <dataset>.<bang> | | Ai tốn nhiều nhất | INFORMATION_SCHEMA.JOBS |

Và một cờ rất đáng đưa vào mọi script chạy truy vấn tự động: --maximum_bytes_billed. Nó biến một truy vấn viết sai — chẳng hạn quên lọc theo phân vùng — thành một lỗi rõ ràng ngay lập tức, thay vì một hoá đơn quét vài trăm terabyte chỉ phát hiện vào cuối tháng.

Đáp án

B — Bật FIREWALL RULE LOGGING cho từng luật firewall.

Vì sao đúng

Đây là tính năng của Google Cloud sinh ra chính xác cho việc chẩn đoán "luật nào đang chặn hay cho phép lưu lượng nào".

⚠ Điểm mấu chốt — mỗi bản ghi cho biết luật nào đã quyết định:

Bật firewall rule logging trên một luật
        ↓
    Mỗi kết nối KHỚP luật đó sinh một bản ghi
        ↓
    Bản ghi chứa:
      - luật nào đã khớp (rule reference)
      - ALLOWED hay DENIED
      - IP nguồn và đích, cổng, giao thức
      - hướng (INGRESS / EGRESS)
      - instance liên quan
        ↓
    → biết CHÍNH XÁC luật nào chặn lưu lượng ra

⚠ Và mẹo chẩn đoán quan trọng:

Lưu lượng ra bị chặn mà KHÔNG có bản ghi nào
        ↓
    → không luật nào khớp
    → rơi vào luật NGẦM ĐỊNH
        ↓
    Google Cloud có hai luật ngầm định
    KHÔNG hiện trong danh sách:
      - implied allow egress  (ưu tiên 65535)
      - implied deny ingress  (ưu tiên 65535)
        ↓
    → nếu bạn đã tạo một luật DENY EGRESS
      với ưu tiên thấp hơn, nó sẽ thắng

⚠ Thứ tự xét luật của GCP:

Mọi luật được xét theo ƯU TIÊN
        ↓
    Số NHỎ HƠN = ưu tiên CAO HƠN
    Khoảng 0 - 65535, mặc định 1000
        ↓
    Luật khớp có ưu tiên cao nhất THẮNG
        ↓
    Cùng ưu tiên mà một DENY một ALLOW
        ↓
    → DENY THẮNG

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

• C (bật Cloud Monitoring cho từng luật firewall) — đây là phương án gần nhất về ý tưởng quan sát, nhưng Cloud Monitoring thu thập CHỈ SỐ, không ghi lại từng kết nối và luật nào đã khớp. Nó cho biết có bao nhiêu, không cho biết cái nào.

• A (bật Cloud Trace cho từng luật) — Cloud Trace theo dõi độ trễ của request trong ứng dụng phân tán, không liên quan tới firewall.

• D (dùng Cloud Debugger) — công cụ gỡ lỗi MÃ NGUỒN đang chạy, không dùng cho cấu hình mạng. (Và Cloud Debugger đã ngừng hoạt động.)

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 | | 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) | | Cùng ưu tiên | DENY thắng ALLOW | | Có trạng thái | CÓ — luật ngược chiều tự động cho gói trả lời | | Hai luật ngầm định | implied allow egress, implied deny ingress |

Từ khoá nhận diện:

"luật nào đang chặn lưu lượng" → firewall rule logging "kết nối bị chặn ở đâu trong VPC" → VPC Flow Logs + firewall logging "đường đi có thông không" → Network Intelligence Center → Connectivity Tests "độ trễ trong ứng dụng" → Cloud Trace "chỉ số tổng hợp" → Cloud Monitoring

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật nào đang áp cho VM | gcloud compute firewall-rules list --filter="targetTags:<tag>" | | Luật nào khớp lưu lượng | Cloud Logging, lọc resource.type="gce_subnetwork" | | Đường đi lý thuyết | Connectivity Tests trong Network Intelligence Center |

Và một công cụ nên dùng trước khi bật logging và ngồi đọc từng dòng: Connectivity Tests. Nó phân tích cấu hình đường đi giữa hai điểm mà không gửi gói tin nào, rồi chỉ thẳng "bị chặn bởi luật firewall tên X" — nhanh hơn nhiều so với việc chờ log tích luỹ đủ để nhìn ra vấn đề.