Ngân hàng đề — Google Cloud Professional Cloud Developer

🧩 Phân tích nội dung câu hỏi

Câu hỏi này xoay quanh việc xây dựng một pipeline CI/CD hoàn chỉnh trên Google Cloud Platform (GCP), sử dụng các dịch vụ quen thuộc như version control system (hệ thống quản lý mã nguồn), Cloud Build (dịch vụ xây dựng và CI/CD tự động), và Container Registry (kho lưu trữ container image). Quy trình hiện tại đã được thiết lập như sau:

• Mỗi khi push một tag mới vào repository, Cloud Build sẽ tự động trigger job để:
  • Chạy unit tests trên code mới.
  • Build Docker container image mới.
  • Push image vào Container Registry.

Bước cuối cùng cần hoàn thiện là deploy container mới vào production GKE cluster (Google Kubernetes Engine). Yêu cầu cụ thể phải đáp ứng 4 tiêu chí nghiêm ngặt:
✅ Zero downtime: Không gây gián đoạn dịch vụ (không downtime).
✅ Testing fully automated: Kiểm thử hoàn toàn tự động hóa.
✅ Allows for testing before being rolled out to users: Cho phép test trước khi triển khai thực sự đến người dùng (không expose traffic thực tế ngay).
✅ Quick rollback if needed: Có thể rollback nhanh chóng nếu có vấn đề.

🛠️ Deployment strategy phù hợp: Cần chọn công cụ và chiến lược deploy hỗ trợ blue-green, canary, A/B, hoặc shadow testing trên GKE, thường kết hợp với kubectl (Kubernetes CLI) hoặc công cụ nâng cao như Spinnaker, Istio (service mesh). Shadow testing đặc biệt lý tưởng vì nó mirror traffic production sang version mới mà không ảnh hưởng người dùng, đảm bảo test real-world trước rollout.

📘 Tài liệu tham khảo:

• Google Cloud Documentation: Cloud Build Triggers (cập nhật 2024).
• GKE Deployment Strategies (bao gồm shadow testing với Istio, phiên bản 2025-2026).
• Istio Shadowing (hỗ trợ GKE Autopilot, cập nhật Q1/2026).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Trigger another Cloud Build job that uses the Kubernetes CLI tools to deploy your new container to your GKE cluster, where you can perform a shadow test.

Lý do chọn đáp án này 🏆:

• Zero downtime: Shadow test (hay dark/mirror traffic) gửi duplicate traffic từ production sang container mới mà không thay đổi response trả về user, nên không gián đoạn.
• Testing fully automated: Có thể tự động hóa qua Cloud Build step với kubectl + Istio VirtualService để config shadow rules, tích hợp kiểm tra metrics (Prometheus/Grafana).
• Testing before rollout to users: Test với real production traffic (mirror 100%) nhưng ẩn hoàn toàn khỏi user, phát hiện issue sớm.
• Quick rollback: Chỉ cần xóa shadow config hoặc scale down pod mới (kubectl delete/scale), không ảnh hưởng deployment chính.
• Phù hợp native GCP: Cloud Build trigger tiếp theo bằng tag, dùng gke-deploy builder hoặc kubectl apply YAML với Istio (hỗ trợ GKE 1.29+ đến 2026). Không cần tool ngoài như Spinnaker.

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên 4 yêu cầu, với kiến thức GCP mới nhất (GKE 1.30+, Cloud Build v2026 hỗ trợ Istio-native).

• ❌ Phương án SAI: Trigger a Spinnaker pipeline configured as an A/B test of your new code and, if it is successful, deploy the container to production.
  Lý do sai: A/B test chia traffic (ví dụ 50/50) giữa old/new version trực tiếp expose đến user, vi phạm "testing before being rolled out to users". Spinnaker cần setup riêng (không native trigger từ Cloud Build), phức tạp hơn, và A/B chủ yếu cho experimentation chứ không ưu tiên zero-downtime thuần túy (có risk nếu test fail).

• ❌ Phương án SAI: Trigger a Spinnaker pipeline configured as a canary test of your new code and, if it is successful, deploy the container to production.
  Lý do sai: Canary release deploy dần dần đến subset user/pod (ví dụ 10% traffic), expose một phần user ngay từ đầu, không đáp ứng "testing before rollout". Spinnaker hỗ trợ tốt zero-downtime và rollback, nhưng vẫn cần pipeline riêng (không seamless với Cloud Build hiện tại), và testing chưa "ẩn" hoàn toàn.

• ❌ Phương án SAI: Trigger another Cloud Build job that uses the Kubernetes CLI tools to deploy your new container to your GKE cluster, where you can perform a canary test.
  Lý do sai: Canary test qua kubectl cần tool bổ sung (Istio/Flagger), nhưng deploy trực tiếp bằng kubectl thường là rolling update expose traffic dần đến user, không đảm bảo "testing before rollout". Cloud Build job thứ hai là tốt (native), nhưng canary vẫn có rủi ro partial exposure và rollback chậm hơn shadow (phải scale traffic thủ công).

• ✅ Phương án ĐÚNG: Trigger another Cloud Build job that uses the Kubernetes CLI tools to deploy your new container to your GKE cluster, where you can perform a shadow test.
  Lý do đúng (tóm tắt lại): Hoàn hảo khớp tất cả 4 yêu cầu, native với Cloud Build + kubectl + Istio trên GKE (hỗ trợ từ 2023, tối ưu 2026 với GKE Autopilot). Shadow test là "testing bí mật" tốt nhất cho production traffic validation.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi yêu cầu tạo một script để liệt kê các cơ sở dữ liệu (databases) từ ba dịch vụ Google Cloud sau trong một project cụ thể:

• Cloud Bigtable (dịch vụ NoSQL wide-column store, tương tự HBase).
• Memorystore (dịch vụ managed Redis cho in-memory caching/database).
• Cloud SQL (dịch vụ managed relational database như MySQL/PostgreSQL/SQL Server).

Script phải hỗ trợ filter expression (biểu thức lọc) do người dùng cung cấp để giới hạn kết quả hiển thị. Mục tiêu là retrieve data (lấy dữ liệu) một cách hiệu quả, phù hợp với môi trường Google Cloud, sử dụng công cụ CLI chuẩn như gcloud (Google Cloud CLI).

Vấn đề chính: Làm thế nào để lấy danh sách các instances/databases từ ba dịch vụ này, áp dụng filter, và hiển thị kết quả? Câu hỏi nhấn mạnh vào cách tối ưu, native với GCP, tránh sử dụng API thấp cấp không phù hợp (như HBase/Redis/MySQL trực tiếp).

📘 Tài liệu tham khảo:

• gcloud bigtable instances list (hỗ trợ --filter từ phiên bản gcloud 2023+).
• gcloud redis instances list (hỗ trợ --filter).
• gcloud sql databases list (hỗ trợ --filter, cập nhật đến 2026).
• Google Cloud CLI docs: Filtering results (phiên bản mới nhất 2026 hỗ trợ filter expression mạnh mẽ như CEL - Common Expression Language).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng:
Run gcloud bigtable instances list, gcloud redis instances list, and gcloud sql databases list. Use --filter flag with each command, and then display the results

🛠️ Lý do chi tiết:

• Đây là cách native và hiệu quả nhất trong Google Cloud: Sử dụng gcloud CLI để liệt kê trực tiếp instances/databases từ từng dịch vụ (Bigtable dùng instances list, Memorystore Redis dùng instances list, Cloud SQL dùng databases list).
• --filter flag cho phép áp dụng filter expression tại server-side (trên Google Cloud), giảm dữ liệu truyền về client, tiết kiệm băng thông và thời gian xử lý. Filter hỗ trợ syntax CEL (ví dụ: --filter="name=example*").
• Script chỉ cần chạy 3 lệnh với filter người dùng cung cấp, sau đó combine và hiển thị – tối ưu performance, phù hợp operations team. Phiên bản gcloud 2026 hỗ trợ filter phức tạp hơn cho multi-resource.
• Không cần code filter trong app, tránh lỗi và phức tạp.

❌ Phân tích tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên best practices GCP (cập nhật 2026):

• [SAI] Use the HBase API, Redis API, and MySQL connection to retrieve database lists. Combine the results, and then apply the filter to display the results
  ❌ Sai vì: HBase API (cho Bigtable), Redis API, và MySQL connection không phải cách native GCP. Bigtable dùng gRPC API riêng, không phải HBase thuần; Memorystore cấm kết nối Redis trực tiếp mà không auth GCP; Cloud SQL cần IAM/Service Account. Cách này phức tạp, không scalable, filter client-side tốn tài nguyên, vi phạm security (exposed credentials). Không dùng CLI chuẩn cho operations script.

• [SAI] Use the HBase API, Redis API, and MySQL connection to retrieve database lists. Filter the results individually, and then combine them to display the results
  ❌ Sai vì: Tương tự phương án trên, sử dụng API thấp cấp không phù hợp với managed services GCP. Filter individual rồi combine vẫn inefficient (client-side processing), dễ lỗi auth/network, không hỗ trợ project-level listing dễ dàng. GCP khuyến nghị gcloud/REST API cao cấp hơn (2026 update ưu tiên gcloud cho ops teams).

• [SAI] Run gcloud bigtable instances list, gcloud redis instances list, and gcloud sql databases list. Use a filter within the application, and then apply the filter to display the results
  ❌ Sai vì: Dùng gcloud đúng nhưng filter trong application (client-side) là không tối ưu. Lấy full list trước rồi filter local → tốn bandwidth nếu project lớn (hàng nghìn instances), chậm và không scale. gcloud có --filter flag native server-side, best practice từ docs GCP.

• [ĐÚNG] Run gcloud bigtable instances list, gcloud redis instances list, and gcloud sql databases list. Use --filter flag with each command, and then display the results
  ✅ Đúng hoàn toàn (như giải thích ở phần trên): Server-side filtering với --filter trên từng lệnh gcloud → nhanh, tiết kiệm, dễ script (ví dụ: gcloud bigtable instances list --filter="$USER_FILTER"). Hoàn hảo cho operations team, tuân thủ GCP best practices 2026.

🧠 Lời khuyên thêm: Trong script thực tế (Bash/Python), dùng biến $FILTER để pass filter động, handle JSON output với jq cho combine results. Test với gcloud alpha nếu cần features mới 2026!

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào việc triển khai một phiên bản website mới dành cho châu Âu trên Google Kubernetes Engine (GKE), trong khi website hiện tại đã tồn tại. Yêu cầu chính là cả hai website (hiện tại và mới) phải được truy cập qua cùng một địa chỉ IP external của HTTP(S) Load Balancer, nhưng sử dụng domain names khác nhau (ví dụ: www.example.com cho hiện tại và eu.example.com cho mới).

📌 Bối cảnh kỹ thuật:

• Website hiện tại sử dụng Ingress resource để expose qua Google Cloud HTTP(S) Load Balancer (global, hỗ trợ host-based routing).
• Phiên bản mới cần backend riêng (có lẽ Deployment/Service mới), nhưng không thay đổi IP LB hiện tại.
• GKE Ingress controller tự động tạo và quản lý một HTTP(S) LB chung cho tất cả Ingress resources trong cluster (mặc định IngressClass "gce"), hỗ trợ nhiều host rules trên cùng LB.
• Kiến thức cập nhật đến 2026: Ingress vẫn là chuẩn (dù Gateway API đang được khuyến nghị dần thay thế từ GKE 1.27+), với hỗ trợ static IP qua annotation và multiple hosts/paths trong một resource. Không có thay đổi lớn về cơ chế share LB (theo docs GKE 1.31+).

Mục tiêu là thêm routing cho domain mới mà không tạo LB mới hoặc thay đổi IP.

✅ Đáp án đúng

Modify the existing Ingress resource with a host rule matching the new domain

Lý do lựa chọn (chi tiết):
🛠️ Đây là cách tối ưu và chuẩn best practice trong GKE. Một Ingress resource có thể chứa nhiều host rules (ví dụ: host: "www.example.com" → backend cũ; host: "eu.example.com" → backend mới). Chỉnh sửa Ingress hiện tại bằng lệnh kubectl edit hoặc kubectl apply với YAML cập nhật sẽ:

• Thêm rule mới mà không tạo LB mới.
• Giữ nguyên IP external (ephemeral hoặc static).
• LB tự động cập nhật rules qua reconciliation loop của Ingress controller.
• Tránh phức tạp từ multiple Ingress resources (dù hỗ trợ, nhưng có thể tăng kích thước config LB).
  Ví dụ YAML snippet:

rules:
- host: www.example.com  # Giữ nguyên
  http:
    paths: [...]
- host: eu.example.com   # Thêm mới
  http:
    paths: [...]

Kết quả: Cùng IP LB route dựa trên domain (Host header).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên cơ chế GKE Ingress (HTTP(S) LB với host routing).

• Define a new Ingress resource with a host rule matching the new domain ❌ [SAI]
  🧩 Tạo Ingress mới sẽ merge rules vào LB hiện tại (vì cùng Ingress controller), giữ IP same và hỗ trợ domain mới. Tuy nhiên, phương án này không phải lựa chọn tối ưu vì khuyến khích multiple Ingress resources không cần thiết, có thể gây conflict nếu rule trùng host/path sau này, và làm config LB phức tạp hơn (dù không tạo LB mới). Best practice là consolidate vào một Ingress duy nhất.

• Modify the existing Ingress resource with a host rule matching the new domain ✅ [ĐÚNG]
  (Xem lý do ở phần trên). Phương án đơn giản, hiệu quả, tuân thủ docs.

• Create a new Service of type LoadBalancer specifying the existing IP address as the loadBalancerIP ❌ [SAI]
  🛠️ Service type LoadBalancer tạo LB riêng biệt (TCP/UDP proxy LB, không phải HTTP(S) LB), không hỗ trợ host-based routing (không đọc Host header). Dù spec loadBalancerIP: "existing-ip" reuse static IP, nó vẫn tạo instance LB mới (không share với Ingress LB), dẫn đến IP có thể conflict hoặc không route đúng domain. Không phù hợp cho web apps cần L7 routing.

• Generate a new Ingress resource and specify the existing IP address as the kubernetes.io/ingress.global-static-ip-name annotation value ❌ [SAI]
  📌 Annotation kubernetes.io/ingress.global-static-ip-name yêu cầu tên resource static IP (ví dụ: "my-static-ip-name"), KHÔNG phải địa chỉ IP (như "34.120.1.2"). Đặt IP string sẽ bị ignore hoặc error, không attach đúng IP. Hơn nữa, dù annotate đúng, multiple Ingress vẫn share LB nhưng không cần thiết so với modify.

📘 Tài liệu tham khảo (cập nhật 2026)

• Official GKE Ingress docs: cloud.google.com/kubernetes-engine/docs/concepts/ingress – Chi tiết host rules & multiple hosts.
• Load balancing with Ingress: cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress – Static IP annotation & share LB.
• Multiple Ingress objects: cloud.google.com/kubernetes-engine/docs/concepts/ingress#multiple_hosts – Xác nhận merge rules nhưng recommend single resource.
• GKE release notes 1.31+: Không thay đổi core Ingress, Gateway API là optional.

Hy vọng phân tích giúp bạn nắm vững! 🚀 Nếu cần ví dụ YAML đầy đủ, hỏi thêm nhé.

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả tình huống phát triển backend cho một trò chơi di động single-player với mẫu traffic không dự đoán được (dao động suốt ngày đêm do người dùng tương tác bất kỳ lúc nào). Mục tiêu chính là:

• Tối ưu chi phí: Đảm bảo đủ tài nguyên xử lý request, nhưng tránh over-provisioning (cung cấp thừa tài nguyên).
• Xử lý spike traffic hiệu quả: Hệ thống tự động scale up/down linh hoạt. Câu hỏi yêu cầu chọn nền tảng compute phù hợp nhất trên Google Cloud Platform (GCP) để đáp ứng các yêu cầu này. 📱🎮 Đây là kịch bản điển hình cho workload serverless với traffic biến động cao, ưu tiên scale-to-zero để tiết kiệm chi phí khi idle.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Cloud Run
🛠️ Lý do: Cloud Run là nền tảng serverless container (dựa trên Knative), tự động scale từ 0 đến hàng nghìn instances chỉ trong vài giây, lý tưởng cho traffic unpredictable và spike. Nó scale-to-zero (không tốn chi phí khi không có request), giúp tối ưu chi phí tối đa mà không cần quản lý infrastructure. Phù hợp hoàn hảo cho backend game mobile với request bursty (ví dụ: login, leaderboard). Theo tài liệu GCP 2024-2026, Cloud Run hỗ trợ concurrent requests, cold start <1s với optimizations mới, và tích hợp dễ dàng với Firebase/Cloud Functions cho game dev.
📘 Nguồn tham khảo: Cloud Run Documentation - Autoscaling (cập nhật 2025).

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai kèm lý do cụ thể dựa trên đặc tính GCP mới nhất (2026):

• Cloud Run
  ✅ Đúng. Như đã giải thích ở trên, đây là lựa chọn tối ưu nhất với autoscaling serverless, zero provisioning, và chi phí pay-per-use (chỉ tính request duration + CPU). Hoàn hảo cho game backend không steady traffic. 🏆

• Compute Engine with managed instance groups
  ❌ Sai. Managed Instance Groups (MIGs) hỗ trợ autoscaling dựa trên metrics (CPU, load balancer), nhưng yêu cầu provision VM trước (không scale-to-zero), dẫn đến over-provisioning và chi phí idle cao. Phù hợp hơn cho steady workload, không lý tưởng cho unpredictable spikes của game (cold start chậm ~1-5 phút).
  📘 Nguồn: Compute Engine MIG Autoscaling (2025 updates).

• Compute Engine with unmanaged instance groups
  ❌ Sai. Unmanaged instance groups không hỗ trợ autoscaling tự động, bạn phải manual scale hoặc script, rất kém hiệu quả cho traffic spikes. Không tối ưu chi phí, dễ over-provision, và không phù hợp workload biến động cao như game backend. 🛑
  📘 Nguồn: Instance Groups Overview (legacy, không khuyến nghị 2026).

• Google Kubernetes Engine using cluster autoscaling
  ❌ Sai. GKE cluster autoscaling scale nodes/pods tốt cho containerized apps phức tạp, nhưng overhead cao (quản lý cluster, minimum nodes chạy 24/7), chi phí baseline lớn ngay cả khi idle. Không scale-to-zero hoàn toàn, kém tối ưu cho single-player game backend đơn giản với traffic bursty. Phù hợp multi-tenant hoặc steady apps hơn. ⚠️
  📘 Nguồn: GKE Cluster Autoscaler (2026 enhancements for node pools).

Tóm tắt khuyến nghị 🚀: Chọn Cloud Run để deploy containerized backend (Docker) nhanh chóng, tích hợp Pub/Sub cho events game, và monitor qua Cloud Monitoring. Nếu cần stateful, kết hợp Cloud SQL/Firestore!

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào việc cấp quyền truy cập cho các đội phát triển (development teams) quản lý tài nguyên Google Cloud từ môi trường local (như sử dụng gcloud CLI hoặc các công cụ tương tự). Yêu cầu chính là tối ưu hóa hiệu quả và tuân thủ best practices của Google Cloud.

• Bối cảnh: Mỗi đội có các Google Cloud projects riêng. Cần cấp quyền cho developers truy cập project đó từ local mà không làm phức tạp quy trình quản lý.
• Mục tiêu: Sử dụng IAM (Identity and Access Management) hiệu quả, tránh cấp quyền trực tiếp cho từng user (dễ gây lộn xộn khi team thay đổi), và cung cấp thông tin cần thiết để developers kết nối (như Project ID hoặc Number).
• Best practices Google Cloud (cập nhật đến 2026):
  • Sử dụng Google Groups để gán roles cho nhóm thay vì individual users 🛡️️ (dễ scale, quản lý tập trung).
  • Cung cấp Project ID (dạng user-friendly như "my-project-123") để developers dùng lệnh gcloud config set project PROJECT_ID từ local 🔧.
  • Tránh Project Number (dạng số nội bộ như "123456789012") vì không tiện cho CLI local và không phải best practice cho developers.

📘 Tài liệu tham khảo:

• Google Cloud IAM Best Practices (nhấn mạnh sử dụng groups).
• Managing Access with Groups.
• Project Identifiers (Project ID cho CLI).

✅ Đáp án đúng

Create groups, add the users to their groups, assign the relevant roles to the groups, and then provide the users with each relevant Project ID.

Lý do lựa chọn:

• ✅ Sử dụng groups: Tuân thủ best practice IAM, giúp quản lý quyền tập trung (thêm/xóa user chỉ cần chỉnh group, không bind IAM trực tiếp vào user). Hiệu quả cao khi team lớn hoặc thay đổi thường xuyên 🛡️️.
• ✅ Cung cấp Project ID: Developers dùng để auth từ local qua gcloud projects list hoặc gcloud config set project, an toàn và tiện lợi 🔧.
• Kết hợp hoàn hảo: Tối ưu efficiency + security, đúng theo khuyến nghị Google Cloud 2026.

📋 Phân tích tất cả các phương án

Dưới đây là giải thích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên best practices IAM và project identifiers.

• Add the users to their projects, assign the relevant roles to the users, and then provide the users with each relevant Project ID.
  ❌ Sai: Mặc dù cung cấp đúng Project ID (tốt cho CLI local), nhưng gán roles trực tiếp vào individual users vi phạm best practice. Dẫn đến khó quản lý khi team scale (phải chỉnh IAM bindings thủ công cho từng user), không hiệu quả và tăng rủi ro security 🛑.

• Add the users to their projects, assign the relevant roles to the users, and then provide the users with each relevant Project Number.
  ❌ Sai kép: Gán roles trực tiếp vào users (như trên, không scale). Ngoài ra, Project Number không phù hợp cho developers local – họ cần Project ID cho gcloud CLI; Number chỉ dùng nội bộ API, gây khó khăn và không theo best practice 🔒.

• Create groups, add the users to their groups, assign the relevant roles to the groups, and then provide the users with each relevant Project ID.
  ✅ Đúng: Hoàn hảo! Groups cho IAM bindings (best practice quản lý), Project ID cho truy cập local. Tối ưu efficiency, dễ maintain, an toàn theo Google Cloud IAM guidelines 2026 🏆.

• Create groups, add the users to their groups, assign the relevant roles to the groups, and then provide the users with each relevant Project Number.
  ❌ Sai: Groups tốt (đúng hướng), nhưng Project Number sai – developers không dùng Number cho gcloud config, dẫn đến khó kết nối local và không hiệu quả. Best practice yêu cầu Project ID 📍.

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào việc tự động mở rộng (autoscale) một dịch vụ stateless (không trạng thái) và distributed (phân tán) đang chạy trên Google Kubernetes Engine (GKE) cluster. Đội ngũ sản phẩm cần triển khai tính năng này nhanh chóng trong 2 tuần, đồng thời giảm thiểu thay đổi (minimize changes) để tránh ảnh hưởng đến hệ thống hiện tại.

✅ Yêu cầu chính: Tìm giải pháp autoscaling đơn giản, dễ áp dụng ngay, phù hợp với dịch vụ stateless (có thể scale ngang bằng cách tăng số lượng pods mà không lo về trạng thái dữ liệu).
🛠️ Bối cảnh GKE: GKE hỗ trợ các công cụ autoscaling từ Kubernetes như Horizontal Pod Autoscaler (HPA) và Vertical Pod Autoscaler (VPA), với phiên bản cập nhật mới nhất đến 2026 (Kubernetes 1.29+ trên GKE 1.29+, tích hợp Cluster Autoscaler cho node scaling). Giải pháp phải ưu tiên ít config nhất, không cần metric tùy chỉnh phức tạp.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Deploy a Horizontal Pod Autoscaler, and scale based on the CPU toad.
Lý do:

• HPA là giải pháp scale ngang (horizontal scaling) bằng cách tăng/giảm số lượng pods, lý tưởng cho dịch vụ stateless và distributed (có thể replicate dễ dàng).
• Scale dựa trên CPU load là metric built-in mặc định của Kubernetes/GKE, không cần setup thêm (chỉ cần enable metrics-server và định nghĩa Deployment với resource requests).
• Minimize changes: Triển khai nhanh (YAML đơn giản, apply trong phút), phù hợp deadline 2 tuần. Không evict pods đột ngột như VPA.
• 📘 Nguồn: GKE Autoscaling Docs & Kubernetes HPA (cập nhật 2024-2026).

❌ Phân tích tất cả các phương án

Dưới đây là giải thích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên yêu cầu stateless/distributed, minimize changes, và triển khai nhanh.

• Deploy a Vertical Pod Autoscaler, and scale based on the CPU load.
  ❌ Sai: VPA chỉ scale dọc (vertical) bằng cách điều chỉnh CPU/memory requests/limits của từng pod hiện có, không tăng số lượng pods. Không phù hợp cho dịch vụ distributed cần scale out (thêm replicas). Ngoài ra, VPA có thể evict pods khi downscale, gây gián đoạn và yêu cầu nhiều config (recommendation mode → auto mode), không minimize changes. Phù hợp hơn cho stateful apps.

• Deploy a Vertical Pod Autoscaler, and scale based on a custom metric.
  ❌ Sai: Tương tự trên, VPA vẫn chỉ scale dọc, không scale ngang. Custom metric còn phức tạp hơn (cần Prometheus Adapter + setup metrics pipeline), vi phạm yêu cầu minimize changes và deadline 2 tuần. Không lý tưởng cho stateless service.

• Deploy a Horizontal Pod Autoscaler, and scale based on the CPU toad.
  ✅ Đúng: HPA scale số lượng pods dựa trên CPU load (lưu ý: "toad" là lỗi chính tả của "load" – metric chuẩn). Built-in, dễ deploy (kubectl apply HPA YAML), hỗ trợ stateless/distributed hoàn hảo. GKE tự động thu thập CPU metrics từ metrics-server (mặc định enabled). Ít thay đổi nhất!

• Deploy a Horizontal Pod Autoscaler, and scale based on a custom metric.
  ❌ Sai: HPA đúng hướng (scale ngang), nhưng custom metric yêu cầu setup thêm như Custom Metrics Adapter, Prometheus, hoặc Google Cloud Monitoring integration – tốn thời gian config (1-2 ngày+), không minimize changes. CPU load đơn giản hơn nhiều cho trường hợp này.

🛠️ Khuyến nghị bổ sung: Kết hợp HPA với Cluster Autoscaler để scale nodes tự động. Test bằng kubectl autoscale deployment <name> --cpu-percent=50 --min=1 --max=10.
📘 Tài liệu tham khảo chính (cập nhật 2026):

• GKE HPA Guide
• Kubernetes Autoscalers
• VPA Limitations

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả một ứng dụng loosely coupled (lỏng lẻo, các dịch vụ độc lập) được orchestrated (điều phối) bởi code chạy trên Compute Engine (dịch vụ máy ảo của Google Cloud Platform - GCP). Mục tiêu là dễ dàng khởi tạo các instance Compute Engine mới, và các instance này phải tự động tìm và sử dụng phiên bản cụ thể của một dịch vụ (service version).

🛠️ Vấn đề cốt lõi: Cần một cơ chế dynamic (động), cho phép instance mới retrieve thông tin endpoint của service (như IP, port, version) tại runtime (khi chạy), mà không hardcode hoặc phụ thuộc vào config tĩnh. Điều này phù hợp với kiến trúc microservices trên GCP, nơi Compute Engine hỗ trợ metadata để instances tự khám phá dịch vụ (service discovery) mà không cần external registry phức tạp như Consul hay etcd.

📘 Kiến thức cập nhật (GCP 2026): Theo tài liệu GCP mới nhất (Compute Engine Metadata Server v2, hỗ trợ project/instance metadata querying qua HTTP API tại http://metadata.google.internal), đây là cách chuẩn để handle service discovery trong môi trường tự động scale.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Define your service endpoint information as metadata that is retrieved at runtime and used to connect to the desired service.

Lý do:

• Compute Engine cung cấp Instance Metadata (metadata của instance) và Project Metadata (metadata dự án), có thể truy cập tại runtime qua Metadata Server mà không cần auth (chỉ cần User-Agent header đặc biệt).
• Bạn có thể set endpoint info (IP, port, version) làm custom metadata key-value trên project hoặc instance/group (qua gcloud compute instances add-metadata hoặc Instance Groups).
• Khi instance mới boot up, code orchestration query metadata (ví dụ: curl "http://metadata.google.internal/computeMetadata/v1/project/attributes/service-endpoint?recursive=true" -H "Metadata-Flavor: Google"), lấy endpoint và connect động.
• ✅ Linh hoạt cao: Dễ update version mà không restart instances, hỗ trợ autoscaling với Managed Instance Groups (MIGs). Đây là best practice cho service discovery nội bộ GCP (không cần Cloud Endpoints hay Service Directory cho trường hợp đơn giản).

Nguồn tham khảo:

• GCP Compute Engine Metadata (cập nhật 2025-2026).
• Querying Metadata .

🔍 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích chi tiết từng lựa chọn giữ nguyên văn bản gốc tiếng Anh, với lý do đúng/sai dựa trên GCP best practices:

• ✅ Đúng: Define your service endpoint information as metadata that is retrieved at runtime and used to connect to the desired service.
  Như đã giải thích ở trên: Metadata Server cho phép retrieve động tại runtime, lý tưởng cho loosely coupled services và easy spin-up instances mới. Hỗ trợ versioning qua key như service-v1-endpoint: 10.0.0.1:8080.

• ❌ Sai: Define your service endpoint information as label data that is retrieved at runtime and used to connect to the desired service.
  Labels là metadata cho quản lý/filtering (ví dụ: gcloud compute instances list --filter="labels.env:prod"), không được thiết kế để retrieve tại runtime từ instance. Không có API trực tiếp query labels như metadata; phải dùng Cloud API (cần IAM), chậm và không phù hợp cho discovery real-time.

• ❌ Sai: Define your service endpoint information to be retrieved from an environment variable at runtime and used to connect to the desired service.
  Environment variables (env vars) phải set lúc khởi tạo instance (qua startup script hoặc MIG template), không dynamic. Để update version, phải recreate instances/group – vi phạm yêu cầu "easily bring up new instances". Env vars cũng không shared cross-instances dễ dàng.

• ❌ Sai: Define your service to use a fixed hostname and port to connect to the desired service. Replace the service at the endpoint with your new version.
  Fixed hostname/port là hardcode tĩnh, không hỗ trợ "find and use a specific version" động. Phải manually replace (downtime cao), không scale với autoscaling Compute Engine. Không loosely coupled, dễ break nếu service di chuyển (ví dụ: Internal Load Balancer IP thay đổi).

🧩 Tóm tắt: Phương án metadata là optimal cho GCP Compute Engine orchestration, đảm bảo zero-downtime discovery và tuân thủ nguyên tắc 12-factor app (config externalized). Nếu phức tạp hơn, có thể kết hợp Service Directory (GCP 2026) nhưng không cần thiết ở đây!

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào việc thiết lập xác thực (authentication) cho các microservice chạy trên Google Kubernetes Engine (GKE), cụ thể là cách các service trong cluster truy cập các Google Cloud APIs (như Cloud Storage, BigQuery, v.v.). Đây là tình huống phổ biến trong ứng dụng microservice-based, nơi các pod cần quyền truy cập tài nguyên GCP mà không lộ thông tin nhạy cảm.

Yêu cầu chính: Theo best practices được Google khuyến nghị (cập nhật đến năm 2026, dựa trên GKE version 1.29+ và Workload Identity 1.0+), chọn hai phương án đúng. Best practice nhấn mạnh sử dụng Workload Identity để tránh lưu trữ service account keys (rủi ro bảo mật cao), thay vào đó sử dụng federated identity giữa Kubernetes Service Account (KSA) và Google Service Account (GSA). Điều này tuân thủ nguyên tắc "least privilege" và tích hợp IAM tự động.

📘 Tài liệu tham khảo chính:

• Google Cloud Docs: Workload Identity
• GKE Best Practices: Authentication
• IAM Roles for Workload Identity

✅ Đáp án đúng và lý do lựa chọn

Hai đáp án đúng là:
Enable Workload Identity in the cluster via the gcloud command-line tool.
Use gcloud to bind the Kubernetes service account and the Google service account using roles/iam.workloadIdentity.

Lý do:
🛠️ Đây là quy trình chuẩn hai bước của Workload Identity (tính năng mặc định khuyến nghị từ GKE Autopilot và Standard clusters năm 2023+):

1. Bật Workload Identity trên cluster bằng lệnh gcloud container clusters update CLUSTER_NAME --workload-pool=PROJECT_ID.svc.id.goog để kích hoạt OIDC provider, cho phép pods impersonate GSA mà không cần keys.
2. Bind KSA với GSA bằng lệnh gcloud iam service-accounts add-iam-policy-binding GSA@project.iam.gserviceaccount.com --member="serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" --role=roles/iam.workloadIdentityUser (lưu ý: role chính xác là workloadIdentityUser, nhưng câu hỏi dùng roles/iam.workloadIdentity như shorthand phổ biến trong docs).
   ✅ Phương pháp này an toàn, không cần quản lý keys, tự động rotate token, và hỗ trợ fine-grained IAM policies. Tránh các rủi ro như key rotation thủ công hoặc secret leakage.

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên best practices GKE 2026.

• Use the service account attached to the GKE node.
  ❌ Sai. Service account gắn với node (node SA) cấp quyền cho toàn bộ node, không phải pod cụ thể. Điều này vi phạm least privilege (các pod thừa quyền), dễ bị tấn công lateral movement. Google không khuyến nghị từ 2019, thay bằng Workload Identity. (Rủi ro cao trong multi-tenant clusters).

• Enable Workload Identity in the cluster via the gcloud command-line tool.
  ✅ Đúng. Đây là bước đầu tiên bắt buộc để kích hoạt tính năng. Lệnh gcloud tạo workload pool (project.svc.id.goog), cho phép KSA federate với GSA. Bắt buộc cho mọi cluster mới (Autopilot tự enable), đảm bảo pods dùng short-lived tokens thay vì long-lived keys.

• Access the Google service account keys from a secret management service.
  ❌ Sai. Truy cập keys từ Secret Manager (hoặc Vault) vẫn yêu cầu lưu trữ keys JSON, dễ bị lộ nếu secret bị hack. Google cấm best practice này vì rủi ro cao (keys không rotate tự động), khuyến nghị Workload Identity thay thế hoàn toàn.

• Store the Google service account keys in a central secret management service.
  ❌ Sai. Lưu keys trong central secret (như Secret Manager) là anti-pattern cũ kỹ. Vẫn tồn tại vấn đề key management (rotation, revocation thủ công), không scale cho microservices. Google deprecated cách này từ GKE 1.21+, ưu tiên zero-key model.

• Use gcloud to bind the Kubernetes service account and the Google service account using roles/iam.workloadIdentity.
  ✅ Đúng. Bước thứ hai quan trọng: Bind KSA → GSA qua IAM policy với role workloadIdentityUser (hoặc shorthand workloadIdentity). Kết hợp annotation trên KSA (iam.gke.io/gcp-service-account), pods tự động dùng identity GSA để gọi APIs. Hoàn hảo cho security và compliance (SOC2, PCI-DSS).

🛡️ Tóm tắt lợi ích Workload Identity: Giảm 100% key management, audit logs tự động qua Cloud Audit Logs, tích hợp với External Secrets Operator cho hybrid setups. Nếu triển khai sai, pods báo lỗi "permission denied" – kiểm tra bằng kubectl describe pod.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc duy trì một ứng dụng legacy viết bằng .NET trong môi trường Google Cloud Platform (GCP). Ứng dụng này chỉ thay đổi thỉnh thoảng (occasional changes) và vừa được cập nhật gần đây. Mục tiêu chính là:

• Đảm bảo kết quả nhất quán (consistent results) khi ứng dụng di chuyển qua các môi trường trong CI/CD pipeline (từ dev, staging đến production).
• Giảm thiểu chi phí triển khai (minimize the cost of deployment).
• Tránh các yếu tố bên ngoài và phụ thuộc giữa các môi trường hosting (external factors and dependencies between hosting environments).
• Quan trọng: Containers chưa được phê duyệt (Containers are not yet approved) trong tổ chức, nên không thể sử dụng Docker hoặc các công nghệ container-based.

Vấn đề cốt lõi là cần một cách triển khai immutable và reproducible (không thay đổi, có thể tái tạo) cho ứng dụng .NET legacy trên Compute Engine VM, sử dụng Cloud Build làm công cụ CI/CD chính, mà không phụ thuộc vào cấu hình môi trường khác nhau.

📘 Tài liệu tham khảo:

• Cloud Build documentation (cập nhật 2024-2026: Hỗ trợ build custom VM images cho Compute Engine).
• Compute Engine best practices for CI/CD (Immutable infrastructure).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Use Cloud Build to deploy the application as a new Compute Engine image for each build. Use this image in each environment.

Lý do 🛠️:

• Phương án này tạo ra một image Compute Engine mới (VM image immutable) cho mỗi build trong Cloud Build, đảm bảo ứng dụng .NET legacy được đóng gói hoàn chỉnh (bao gồm code, dependencies, runtime) mà không phụ thuộc vào môi trường hosting. Mỗi môi trường (dev/staging/prod) chỉ cần deploy instance từ cùng một image, dẫn đến kết quả nhất quán 100%.
• Tiết kiệm chi phí: Cloud Build chỉ tính phí theo thời gian build (rẻ), và image lưu trữ trên Artifact Registry hoặc Compute Engine Image storage với chi phí thấp. Không cần containers, phù hợp quy định tổ chức.
• Tái tạo dễ dàng: Mỗi build tạo artifact độc lập, tránh "works on my machine" issues.
• Đây là best practice cho legacy apps trên GCP mà không dùng containers (Immutable Infrastructure pattern).

❌ Phân tích tất cả các phương án (đúng/sai)

• [SAI] Rewrite the application using .NET Core, and deploy to Cloud Run. Use revisions to separate the environments.
  ❌ Sai vì: Yêu cầu rewrite toàn bộ app legacy sang .NET Core là tốn kém và không cần thiết (app chỉ thay đổi occasional). Cloud Run bắt buộc dùng containers (container-based serverless), vi phạm quy định "Containers are not yet approved". Revisions chỉ giúp rollback nhưng không giải quyết consistency giữa envs mà không container.

• [ĐÚNG] Use Cloud Build to deploy the application as a new Compute Engine image for each build. Use this image in each environment.
  ✅ Đúng như đã giải thích ở trên: Immutable VM images từ Cloud Build đảm bảo consistency, low-cost, no containers, no env dependencies. Hoàn hảo cho .NET legacy trên Windows/Linux VMs.

• [SAI] Deploy the application using MS Web Deploy, and make sure to always use the latest, patched MS Windows Server base image in Compute Engine.
  ❌ Sai vì: MS Web Deploy (IIS-based deployment) không đảm bảo immutability – mỗi deploy có thể thay đổi file trên VM đang chạy, dẫn đến phụ thuộc env (config drift giữa dev/prod). Dùng latest base image vẫn có rủi ro patching không đồng bộ, và không dùng CI/CD tự động như Cloud Build. Chi phí cao hơn do manual patching.

• [SAI] Use Cloud Build to package the application, and deploy to a Google Kubernetes Engine cluster. Use namespaces to separate the environments.
  ❌ Sai vì: GKE là container orchestrator (dùng Kubernetes với Docker images), vi phạm nghiêm trọng quy định "Containers not approved". Namespaces chỉ tách logic envs nhưng không giải quyết consistency nếu packaging không immutable, và chi phí cao (GKE cluster luôn chạy).

🧠 Kết luận: Phương án đúng tận dụng Cloud Build + Compute Engine images – giải pháp chuẩn GCP cho legacy apps đến 2026, theo nguyên tắc "Bake once, deploy everywhere"! 🚀

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào việc triển khai ứng dụng containerized mới lên môi trường production trên Google Kubernetes Engine (GKE). Ứng dụng đã được test nhưng chưa load-test đầy đủ ở pre-production, nên cần đảm bảo không có vấn đề performance khi deploy. Yêu cầu chính:

• Deployment phải tự động hóa (automated).
• Phát hiện và xử lý vấn đề performance một cách an toàn, tránh ảnh hưởng toàn bộ production.
  📘 Bối cảnh chính: Sử dụng các tính năng của Google Cloud như Cloud Monitoring để giám sát metrics (CPU, latency, error rate...), và các chiến lược deployment trên GKE để kiểm soát traffic dần dần (progressive rollout). Kiến thức cập nhật đến 2026: GKE hỗ trợ Canary, Blue/Green qua Knative hoặc Cloud Run, nhưng Canary deployments qua continuous delivery pipeline (như Cloud Build + GKE) là best practice cho testing performance với traffic ramp-up tự động dựa trên metrics (theo docs GKE 1.29+ và Anthos Service Mesh).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Deploy the application via a continuous delivery pipeline using canary deployments. Use Cloud Monitoring to look for performance issues. and ramp up traffic as the metrics support it.

Lý do:

• Canary deployments trên GKE (qua Deployment hoặc Knative Serving) cho phép deploy phiên bản mới cho một phần nhỏ traffic (ví dụ 5-10%), sau đó tự động ramp up traffic dựa trên metrics từ Cloud Monitoring (như error rate <1%, latency ổn định). Điều này lý tưởng khi chưa load-test đầy đủ, giúp phát hiện performance issues sớm mà không rủi ro toàn bộ production.
• Continuous delivery pipeline (Cloud Build + GitOps) đảm bảo tự động hóa hoàn toàn, phù hợp yêu cầu "automated".
• 🛠️ Ưu điểm: Metrics-driven promotion (tích hợp với Cloud Monitoring alerts), rollback tự động nếu fail. Đây là recommended practice trong Google Cloud Best Practices (2024-2026).

Nguồn tham khảo:

• GKE Canary Deployments
• Cloud Monitoring for GKE
• Progressive Delivery with GKE.

📋 Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể:

• Use Cloud Load Balancing to slowly ramp up traffic between versions. Use Cloud Monitoring to look for performance issues.
  ❌ Sai: Cloud Load Balancing (HTTP(S) LB) hỗ trợ traffic splitting giữa backend services/INGRESS, nhưng không tự động hóa deployment trên GKE (chỉ control traffic sau khi deploy thủ công). Không giải quyết "deploy automated" và thiếu progressive rollout dựa trên metrics realtime. Phù hợp hơn cho VM-based apps, không phải containerized trên GKE.

• Deploy the application via a continuous delivery pipeline using canary deployments. Use Cloud Monitoring to look for performance issues. and ramp up traffic as the metrics support it.
  ✅ Đúng: Như đã giải thích ở trên. Đây là cách tối ưu nhất, kết hợp pipeline tự động (Cloud Build/Spinnaker), Canary (GKE native hoặc Istio), và Monitoring để ramp-up an toàn. Hoàn hảo cho scenario chưa load-test đầy đủ.

• Deploy the application via a continuous delivery pipeline using blue/green deployments. Use Cloud Monitoring to look for performance issues, and launch fully when the metrics support it.
  ❌ Sai: Blue/Green deploy (qua GKE Deployment hoặc Job) tạo 2 môi trường song song, test green trước khi switch 100% traffic sang. Tuy automated qua pipeline, nhưng không ramp up dần dần (all-or-nothing switch), rủi ro cao nếu performance issues chỉ lộ ra dưới full load. Không lý tưởng cho testing incremental traffic.

• Deploy the application using kubectl and set the spec.updateStrategv.type to RollingUpdate. Use Cloud Monitoring to look for performance issues, and run the kubectl rollback command if there are any issues.
  ❌ Sai: RollingUpdate là default strategy của Kubernetes Deployment (kubectl apply/set), tự động replace pods dần dần. Tuy dùng Cloud Monitoring, nhưng không automated ramp-up traffic dựa trên metrics (chỉ fixed maxUnavailable/maxSurge), và rollback thủ công (kubectl rollout undo) vi phạm yêu cầu "automated". Lỗi chính tả "updateStrategv" cũng chỉ ra không chính xác. Không an toàn cho performance testing mà chưa load-test.

🧠 Kết luận: Canary là lựa chọn best fit cho progressive delivery trên GKE, giúp minimize downtime và detect issues sớm! Nếu cần implement, dùng kubectl apply -f canary.yaml với traffic weights hoặc Istio VirtualService.