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

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📘 Nội dung câu hỏi:
Câu hỏi xoay quanh việc chia sẻ một biểu đồ Observability (chart) đo lường CPU utilization (sử dụng CPU) trong một dashboard thuộc workspace project trên Google Cloud Monitoring (nay là Observability). Bạn muốn chia sẻ chỉ biểu đồ này với đội ngũ Site Reliability Engineering (SRE), đồng thời tuân thủ nguyên tắc least privilege (quyền hạn tối thiểu) – nghĩa là chỉ cấp quyền cần thiết nhất để xem biểu đồ mà không cho phép truy cập rộng hơn (như toàn bộ project hoặc dashboard).
🛠️ Bối cảnh kỹ thuật: Đây là tính năng trong Cloud Monitoring workspaces (trước đây là Stackdriver), nơi bạn có thể tạo chart từ metrics như CPU. Việc chia sẻ phải an toàn, hạn chế quyền truy cập dữ liệu metrics. Kiến thức dựa trên phiên bản mới nhất Google Cloud Observability đến năm 2026 (Cloud Monitoring API v3, IAM roles cập nhật).

✅ Đáp án đúng:
Click “Share chart by URL” and provide the URL to the SRE team. Assign the SRE team the Monitoring Viewer IAM role in the workspace project.

Lý do chọn đáp án đúng (🟢):
Phương án này tuân thủ least privilege hoàn hảo:

• Share chart by URL chỉ chia sẻ liên kết trực tiếp đến chart cụ thể, không lộ Project ID hoặc toàn bộ dashboard/project. SRE team chỉ xem được chart qua URL mà không cần truy cập project đầy đủ.
• Monitoring Viewer IAM role (roles/monitoring.viewer) cấp quyền đọc metrics data (như CPU utilization) và xem chart/dashboard – đủ để render chart từ dữ liệu Observability, nhưng không cho phép chỉnh sửa hoặc truy cập rộng (ví dụ: không viết metrics, không xem logs chi tiết).
  🛡️ Lợi ích: An toàn cao, chỉ cần quyền viewer trên project/workspace, phù hợp SRE team theo dõi metrics mà không rủi ro bảo mật.

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

• ❌ [SAI] Share the workspace Project ID with the SRE team. Assign the SRE team the Monitoring Viewer IAM role in the workspace project.
  Phương án này sai vì chia sẻ Project ID cho phép SRE team truy cập toàn bộ workspace project (bao gồm tất cả dashboards, metrics, alerts khác), vi phạm least privilege. Dù Monitoring Viewer chỉ đọc, nhưng lộ Project ID vẫn mở rộng quyền truy cập không cần thiết. Không dùng tính năng share URL chuyên biệt cho chart.

• ❌ [SAI] Share the workspace Project ID with the SRE team. Assign the SRE team the Dashboard Viewer IAM role in the workspace project.
  Phương án này sai kép:

  • Chia sẻ Project ID lộ toàn bộ project, không tuân thủ least privilege.
  • Dashboard Viewer (roles/monitoring.dashboardViewer) chỉ xem dashboard tĩnh, không đủ quyền đọc metrics data (như CPU utilization) để render chart động. Chart sẽ không hiển thị dữ liệu, chỉ layout trống.

• ✅ [ĐÚNG] Click “Share chart by URL” and provide the SRE team the Monitoring Viewer IAM role in the workspace project.
  (Như đã giải thích ở trên) – Hoàn hảo cho least privilege: URL giới hạn chart, role viewer đủ quyền đọc metrics.

• ❌ [SAI] Click “Share chart by URL” and provide the URL to the SRE team. Assign the SRE team the Dashboard Viewer IAM role in the workspace project.
  Phương án này sai vì dù share URL đúng cách (giới hạn chart), Dashboard Viewer role không cấp quyền đọc metrics data cần thiết để tải CPU utilization và render chart. SRE team sẽ thấy lỗi "permission denied" hoặc chart trống khi truy cập URL.

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

• 🖥️ Chính thức Google Cloud: Share charts and dashboards – Hướng dẫn share URL cho chart cụ thể.
• 🔑 IAM Roles: Cloud Monitoring roles – So sánh Monitoring Viewer vs. Dashboard Viewer (Viewer đọc metrics, Dashboard chỉ xem UI).
• 📖 Best practices least privilege: Observability security – Nhấn mạnh share URL + minimal roles.
  ⚠️ Lưu ý: Không liên quan AWS (dù đề cập), đây là Google Cloud Observability thuần túy! Nếu cần AWS tương đương (CloudWatch), hãy hỏi thêm. 🚀

🧩 Giải thích nội dung câu hỏi

Câu hỏi xoay quanh việc áp dụng văn hóa và nguyên tắc Site Reliability Engineering (SRE) trong tổ chức. Cụ thể, một dịch vụ mà bạn hỗ trợ vừa gặp sự cố gián đoạn hạn chế (limited outage). Một manager từ team khác yêu cầu bạn cung cấp giải thích chính thức (formal explanation) về sự việc để họ có thể thực hiện các biện pháp khắc phục (action remediations).

Mục tiêu chính là kiểm tra kiến thức về postmortem trong SRE: Đây là tài liệu phân tích sự cố sau khi xảy ra, phải không đổ lỗi cá nhân (blameless), tập trung vào root causes (nguyên nhân gốc rễ), resolution (cách giải quyết), lessons learned (bài học kinh nghiệm), và action items (các hạng mục hành động ưu tiên). Theo nguyên tắc SRE (dựa trên sách SRE của Google, vẫn là tiêu chuẩn đến năm 2026), postmortem phải được chia sẻ rộng rãi trong tổ chức kỹ thuật để thúc đẩy học hỏi chung, tránh lặp lại lỗi, thay vì giữ bí mật hoặc chỉ chia sẻ hạn chế. Điều này phù hợp với AWS Well-Architected Framework (Reliability Pillar, cập nhật 2024-2026), nhấn mạnh SRE practices như error budgets và postmortem công khai để cải thiện độ tin cậy hệ thống.

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

Đáp án đúng:
[ĐÚNG] Develop a postmortem that includes the root causes, resolution, lessons learned, and a prioritized list of action items. Share it on the engineering organization's document portal.

Lý do chi tiết:
🛠️ Phương án này tuân thủ hoàn hảo nguyên tắc SRE cốt lõi: Postmortem phải bao gồm đầy đủ root causes, resolution, lessons learned, prioritized action items (không liệt kê người chịu trách nhiệm để tránh blame culture). Việc chia sẻ trên engineering organization's document portal đảm bảo tính transparency (minh bạch) và learning organization (tổ chức học hỏi), giúp toàn bộ engineering org tiếp cận, theo khuyến nghị từ Google SRE Book (Chapter 9: Postmortem Culture) và AWS DevOps Guidance (2026 updates). Điều này thúc đẩy SRE principles như error budgets và continuous improvement, tránh silo hóa kiến thức chỉ giữa các manager.

📋 Phân tí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á dựa trên SRE best practices (blameless, public sharing) và AWS SRE/DevOps guidelines (Reliability Pillar, Operational Excellence).

• [SAI] Develop a postmortem that includes the root causes, resolution, lessons learned, and a prioritized list of action items. Share it with the manager only.
  ❌ Giải thích sai: Phương án này đúng về nội dung postmortem (root causes, resolution, lessons learned, prioritized actions – phù hợp blameless), nhưng sai ở việc chia sẻ chỉ với manager cá nhân. SRE yêu cầu chia sẻ rộng rãi để toàn tổ chức học hỏi, tránh "knowledge silos" (kho kiến thức cô lập). Theo AWS Well-Architected (2026), postmortem phải public trong team/org để scale reliability, không giới hạn ở một người.

• [ĐÚNG] Develop a postmortem that includes the root causes, resolution, lessons learned, and a prioritized list of action items. Share it on the engineering organization's document portal.
  ✅ Giải thích đúng: Như đã phân tích ở trên, đây là best practice chuẩn SRE: Nội dung đầy đủ, blameless (không blame cá nhân), và chia sẻ công khai trên document portal để thúc đẩy culture học hỏi chung. Điều này align với Google SRE Workbook và AWS Incident Management best practices (cập nhật 2026), giúp prevent future outages toàn tổ chức.

• [SAI] Develop a postmortem that includes the root causes, resolution, lessons learned, the list of people responsible, and a list of action items for each person. Share it with the manager only.
  ❌ Giải thích sai: Hai lỗi lớn: (1) Bao gồm "list of people responsible" và "action items for each person" vi phạm nguyên tắc blameless postmortem – SRE cấm đổ lỗi cá nhân để khuyến khích reporting incidents mà không sợ phạt (Google SRE Book nhấn mạnh điều này). (2) Chia sẻ chỉ với manager hạn chế learning, trái với transparency trong AWS DevOps Guidance. Kết quả: Tạo fear culture thay vì improvement culture.

• [SAI] Develop a postmortem that includes the root causes, resolution, lessons learned, the list of people responsible, and a list of action items for each person. Share it on the engineering organization's document portal.
  ❌ Giải thích sai: Dù chia sẻ công khai trên portal là đúng hướng, nhưng nội dung sai cơ bản với "list of people responsible" và per-person actions – điều này phá hủy blameless culture, dẫn đến ngại chia sẻ incidents (theo SRE principles, cập nhật không đổi đến 2026). AWS khuyến cáo tránh personal blame trong Reliability Pillar để focus vào system/process improvements.

📘 Tài liệu tham khảo

• Google SRE Book (2016, updates qua SRE Workbook 2023-2026): Postmortem Culture Chapter – Nguồn gốc SRE principles về blameless postmortems và public sharing.
• AWS Well-Architected Framework (Reliability Pillar, latest 2024-2026): AWS Documentation – Nhấn mạnh SRE practices, incident response, và knowledge sharing.
• AWS DevOps & SRE Guidance (2026 updates): AWS Blogs on SRE – Áp dụng postmortem cho cloud reliability.

Hy vọng phân tích này giúp bạn nắm vững SRE trong context AWS/Google Cloud! 🚀

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

Câu hỏi này xoay quanh việc thu thập và gửi log từ một ứng dụng containerized mới chạy trên Google Kubernetes Engine (GKE) cluster, sử dụng Observability Kubernetes Engine Monitoring (nay là phần của Google Cloud Observability, bao gồm Logging và Monitoring).

• Bối cảnh cụ thể:

  • Ứng dụng được viết bởi bên thứ ba (third-party), không thể chỉnh sửa hoặc cấu hình lại (cannot be modified or reconfigured).
  • Ứng dụng ghi log vào file /var/log/app_messages.log (không phải stdout/stderr chuẩn).
  • Mục tiêu: Gửi các log entry này đến Observability Logging (Cloud Logging) một cách tự động và hiệu quả.

• Thách thức chính 🛠️:

  • Agent logging mặc định của GKE (dựa trên Fluent Bit hoặc legacy Fluentd trong Ops Agent) chỉ thu thập log từ stdout/stderr của container và một số đường dẫn chuẩn (như /var/log/pods). Nó không tự động tail file log tùy chỉnh như /var/log/app_messages.log.
  • Cần giải pháp không can thiệp vào ứng dụng chính, phù hợp với môi trường production trên GKE.

Kiến thức cập nhật đến 2026 📘: Theo tài liệu Google Cloud mới nhất (GKE version 1.29+ và Cloud Operations Suite v2.x), để xử lý custom log files trong GKE, khuyến nghị sử dụng Fluentd DaemonSet với cấu hình tùy chỉnh hoặc Ops Agent với config metadata. Không dùng default agent cho trường hợp này.

Tài liệu tham khảo:

• Google Cloud Docs: Logging containerized apps on GKE
• Configure custom log collection in GKE
• GKE Logging with Fluentd

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

Đáp án đúng: Deploy a Fluentd daemonset to GKE. Then create a customized input and output configuration to tail the log file in the application's pods and write to Observability Logging.

Lý do chi tiết 🏆:

• Fluentd DaemonSet chạy trên mọi node trong cluster (daemonset pattern), có quyền truy cập vào file log của tất cả pods mà không cần chỉnh sửa ứng dụng.
• Custom input config: Sử dụng plugin @type tail để theo dõi (tail) file /var/log/app_messages.log trong các pod.
• Custom output config: Gửi log đến Cloud Logging qua Google Cloud Logging plugin.
• Đây là best practice cho GKE, scalable, không phụ thuộc vào ứng dụng third-party, và tương thích đầy đủ với Observability. Không ảnh hưởng performance vì chạy ở node level.

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

• ❌ [SAI] Use the default Observability Kubernetes Engine Monitoring agent configuration.
  Phương án này sai vì agent mặc định (Ops Agent/Fluent Bit) chỉ thu thập log từ stdout/stderr và các đường dẫn chuẩn như journald/syslog. Nó không tail file tùy chỉnh /var/log/app_messages.log mà không có config bổ sung. Sử dụng default sẽ bỏ lỡ toàn bộ log, không phù hợp với yêu cầu.

• ✅ [ĐÚNG] Deploy a Fluentd daemonset to GKE. Then create a customized input and output configuration to tail the log file in the application's pods and write to Observability Logging.
  Như đã giải thích ở trên, đây là giải pháp tối ưu, chuẩn theo docs Google Cloud. Fluentd DaemonSet với config tail/input/output đảm bảo thu thập log chính xác, gửi đến Logging mà không modify app.

• ❌ [SAI] Install Kubernetes on Google Compute Engine (GCE) and redeploy your applications. Then customize the built-in Observability Logging configuration to tail the log file in the application's pods and write to Observability Logging.
  Phương án sai hoàn toàn vì: (1) Không cần migrate khỏi GKE sang self-managed K8s trên GCE (phức tạp, tốn kém, mất lợi ích managed của GKE). (2) GCE không có "built-in Observability Logging" tự động như GKE. (3) Redeploy tất cả apps là overkill và rủi ro cao cho production.

• ❌ [SAI] Write a script to tail the log file within the pod and write entries to standard output. Run the script as a sidecar container with the application's pod. Configure a shared volume between the containers to allow the script to have read access to /var/log in the application container.
  Phương án sai vì dù có thể hoạt động (sidecar tail log → stdout → agent mặc định), nó không scalable: Phải inject sidecar vào mọi pod/deployment của app, tăng complexity, resource overhead (CPU/memory per pod), và khó maintain với third-party app. DaemonSet tốt hơn vì chạy once-per-node.

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

Câu hỏi mô tả tình huống một ứng dụng đang chạy trên Virtual Machine (VM) sử dụng custom Debian image trong Google Cloud. Image này đã cài đặt Observability Logging agent (tức là Logging agent thuộc Google Cloud Observability, trước đây gọi là Stackdriver Logging agent hoặc Ops Agent). VM được cấu hình với cloud-platform scope (một service account scope đầy đủ, cho phép truy cập hầu hết các dịch vụ Google Cloud bao gồm Logging và Monitoring). Ứng dụng ghi log thông qua syslog (hệ thống log chuẩn của Linux).

Người dùng muốn sử dụng Observability Logging trong Google Cloud Console (cụ thể là Logs Viewer) để visualize logs, nhưng nhận thấy syslog không xuất hiện trong dropdown "All logs".
Vấn đề cốt lõi: Logs từ syslog không được thu thập hoặc hiển thị, cần xác định bước đầu tiên (first thing) để troubleshoot.
📘 Bối cảnh kiến thức cập nhật đến 2026: Theo tài liệu Google Cloud mới nhất (phiên bản Ops Agent v2.14+ và legacy Fluentd agent), syslog là nguồn log mặc định được agent thu thập trên Linux. Nếu không hiển thị, nguyên nhân phổ biến là agent không chạy, cấu hình sai, hoặc quyền hạn thiếu. Cloud-platform scope đã bao gồm logging.logEntries.create và monitoring.metricDescriptors.create, nên không cần scope riêng.

Nguồn tham khảo:

• Troubleshoot the Logging agent | Google Cloud
• Install the Ops Agent | Google Cloud
• View logs | Google Cloud

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

Đáp án đúng: SSH to the VM and execute the following commands on your VM: ps ax | grep fluentd.

Lý do chi tiết:
🛠️ Đây là bước đầu tiên logic nhất để troubleshoot vì Observability Logging agent (legacy version dựa trên Fluentd) sử dụng process fluentd để thu thập và forward logs từ syslog. Nếu syslog không hiện trong Logs Viewer, rất có thể agent không chạy (do lỗi cài đặt, crash, hoặc chưa start). Lệnh ps ax | grep fluentd sẽ kiểm tra nhanh process fluentd có đang hoạt động không (nên thấy các process như /opt/google-fluent-cloud/bin/fluentd).

• Nếu không thấy process → Agent chưa chạy → Cần restart hoặc reinstall.
• Đây là bước zero-downtime, nhanh chóng qua SSH, phù hợp "first thing you should do".
  Theo docs Google Cloud 2026, troubleshooting luôn bắt đầu bằng check agent status trước khi kiểm tra log test, update, hoặc scope (vì scope đã OK).

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

• [SAI] Look for the agent's test log entry in the Logs Viewer.
  ❌ Sai vì: Bước này giả định agent đã chạy và chỉ kiểm tra output trong Logs Viewer (như log test từ sudo /opt/google-fluent-cloud/bin/google-fluent-cloud-test). Nhưng nếu agent không chạy từ đầu (nguyên nhân phổ biến nhất syslog biến mất), thì không có test log nào xuất hiện. Đây không phải "first thing" vì phải xác nhận agent sống trước (check process), tránh mất thời gian tìm log ảo. Docs khuyên check process trước test log.

• [SAI] Install the most recent version of the Observability agent.
  ❌ Sai vì: Chưa verify nguyên nhân nên không nên update ngay (có thể gây downtime hoặc conflict với custom Debian image). Agent cũ vẫn hỗ trợ syslog tốt nếu chạy đúng; chỉ upgrade nếu confirm version lỗi (qua check process trước). Theo best practice 2026, first step là diagnose (check status), không phải thay đổi hệ thống ngay. Ops Agent mới (v2.14+) khuyến nghị migrate từ legacy, nhưng vẫn cần check fluentd trước.

• [SAI] Verify the VM service account access scope includes the monitoring.write scope.
  ❌ Sai vì: VM đã có cloud-platform scope (bao gồm đầy đủ logging.write, monitoring.write, và monitoring.metrics.write theo IAM scopes list 2026). Không cần verify thêm vì scope này là full access cho Observability. Nếu thiếu quyền, sẽ báo lỗi auth trong agent logs, nhưng syslog biến mất thường do agent side (không phải scope). Docs xác nhận cloud-platform đủ cho Logging agent.

• [ĐÚNG] SSH to the VM and execute the following commands on your VM: ps ax | grep fluentd.
  ✅ Đúng như đã giải thích ở trên: Bước nhanh, trực tiếp check agent daemon (fluentd) – cốt lõi của syslog collection. Nếu process OK → Tiếp tục check config (/etc/google-fluent-cloud/google-fluent-cloud.conf). Hoàn hảo cho "first thing"!
  🧩 Lưu ý cập nhật: Với Ops Agent mới (không dùng fluentd thuần), dùng systemctl status google-cloud-ops-agent; nhưng câu hỏi chỉ định "Observability Logging agent" với syslog + Debian → ám chỉ legacy Fluentd agent.

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

✅ Nội dung câu hỏi:
Câu hỏi mô tả một tình huống trong Google Cloud Platform (GCP), nơi bạn đang sử dụng pipeline Cloud Build đa bước (multiple step) để build và deploy ứng dụng lên Google Kubernetes Engine (GKE). Yêu cầu là tích hợp với nền tảng giám sát bên thứ ba (third-party monitoring platform) bằng cách thực hiện HTTP POST thông tin build (build information) đến một webhook. Mục tiêu chính là giảm thiểu nỗ lực phát triển (minimize the development effort).
🛠️ Bối cảnh kỹ thuật: Cloud Build là dịch vụ CI/CD tự động hóa trên GCP, hỗ trợ pipeline nhiều bước (steps) để build, test, deploy. Thông tin build bao gồm trạng thái (success/fail), metadata, logs, v.v. Việc tích hợp webhook cần phải tự động, không yêu cầu thay đổi code lớn trong pipeline, và tận dụng các tính năng native của GCP để dễ dàng nhất (dựa trên tài liệu GCP cập nhật đến 2024-2026, Cloud Build vẫn hỗ trợ Pub/Sub notifications làm phương pháp chuẩn).

🟢 Đáp án đúng:
Create a Cloud Pub/Sub push subscription to the Cloud Build cloud-builds PubSub topic to HTTP POST the build information to a webhook.

📘 Lý do chọn đáp án này (bằng kiến thức GCP mới nhất):
✅ Đây là cách tối ưu nhất để giảm thiểu dev effort vì Cloud Build tự động publish tất cả sự kiện build (như start, success, failure) đến topic Pub/Sub mặc định tên cloud-builds (global project-level topic). Bạn chỉ cần tạo một Pub/Sub push subscription trỏ đến URL webhook của third-party, GCP sẽ tự động HTTP POST JSON payload chứa đầy đủ build info (build ID, status, source, images, logs link, v.v.). Không cần code thêm vào pipeline, không phụ thuộc vào bước nào cụ thể, và hỗ trợ real-time notifications.
🛠️ Ưu điểm: Scalable, reliable (Pub/Sub retry mechanism), zero dev effort ngoài config IAM và subscription. Áp dụng cho phiên bản Cloud Build mới nhất (và dự kiến đến 2026 không thay đổi core feature này).
📚 Tài liệu tham khảo:

• Cloud Build Pub/Sub notifications (GCP Docs, cập nhật 2024).
• Pub/Sub push subscriptions.

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

• Add logic to each Cloud Build step to HTTP POST the build information to a webhook.
  ❌ Sai: Phương án này yêu cầu thêm code logic HTTP POST vào MỖI bước (step) trong pipeline Cloud Build (ví dụ: dùng curl trong Dockerfile hoặc script). Điều này tăng dev effort cao vì phải chỉnh sửa nhiều nơi, dễ lỗi (nếu bước fail thì không POST), không tự động, và không tận dụng native GCP. Không phù hợp với yêu cầu "minimize development effort".

• Add a new step at the end of the pipeline in Cloud Build to HTTP POST the build information to a webhook.
  ❌ Sai: Thêm một bước mới ở cuối pipeline để POST (qua curl hoặc tool tương tự). Vẫn cần dev effort để viết step đó, chỉ POST khi toàn bộ pipeline thành công (miss info nếu fail sớm), và build info có thể không đầy đủ (phụ thuộc vào việc pass data giữa steps). Không phải cách tự động/minimal effort nhất so với Pub/Sub.

• Use Observability Logging to create a logs-based metric from the Cloud Build logs. Create an Alert with a Webhook notification type.
  ❌ Sai: Sử dụng Cloud Logging để tạo logs-based metric từ logs Cloud Build, rồi set Alerting policy với webhook notifier. Cách này phức tạp, gián tiếp (logs không phải real-time build events đầy đủ), dev effort cao (config metric + alert), và webhook chỉ trigger khi metric threshold vượt (không phải mọi build event). Không chính xác cho "build information" chi tiết như Pub/Sub cung cấp.

🎯 Kết luận: Phương án Pub/Sub push là best practice GCP cho notifications, đảm bảo real-time, full info, zero-code integration. Nếu triển khai, cần grant IAM role roles/pubsub.subscriber cho service account! 🚀

🧩 Giải thích nội dung câu hỏi

Câu hỏi tập trung vào việc cấu hình phân tích canary (canary analysis) trong pipeline triển khai ứng dụng sử dụng Spinnaker trên AWS. Spinnaker là công cụ CI/CD mã nguồn mở phổ biến cho các môi trường cloud như AWS, hỗ trợ các chiến lược triển khai như canary deployment (triển khai thử nghiệm một phần nhỏ traffic để kiểm tra trước khi rollout toàn bộ).

• Bối cảnh cụ thể: Ứng dụng có in-memory cache được load (tải dữ liệu) ngay lúc start time (khi khởi động). Điều này có nghĩa là hiệu suất ban đầu của ứng dụng có thể bị ảnh hưởng bởi việc warm-up cache (tải cache lần đầu thường chậm hơn so với các lần sau).
• Mục tiêu: Tự động hóa so sánh (comparison) giữa phiên bản canary (phiên bản thử nghiệm mới) và phiên bản production (phiên bản đang chạy thực tế). Phân tích này giúp quyết định promote (thăng cấp) canary hay rollback dựa trên metrics như latency, error rate, v.v.
• Vấn đề cốt lõi: Vì cache load lúc start time, việc so sánh cần fair comparison (so sánh công bằng). Phiên bản production hiện tại đã chạy lâu, cache đã warm-up (nhanh hơn), trong khi canary mới deploy sẽ có cache cold (chậm hơn ban đầu). Do đó, cần cấu hình baseline (tiêu chuẩn so sánh) phù hợp để tránh bias (thiên vị).

🛠️ Lưu ý kỹ thuật (dựa trên Spinnaker phiên bản mới nhất 1.30+ và Armory Enterprise 2.20+ đến 2026): Trong stage Canary Analysis của Spinnaker, bạn sử dụng các provider như CloudBees hoặc Prometheus để thu thập metrics. Baseline phải là một deployment mới của production version để simulate điều kiện tương tự canary (cả hai đều có cache cold).

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

• Spinnaker Docs: Canary Deployments (cập nhật 2025).
• Armory Docs (fork enterprise): Best Practices for Canary Analysis with In-Memory Caches.
• AWS Spinnaker Integration: AWS Developer Guide - Spinnaker on EKS (phiên bản 2026).

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

Đáp án đúng: Compare the canary with a new deployment of the current production version.

Lý do 🏆:

• Đây là best practice chuẩn trong Spinnaker Canary Analysis để xử lý ứng dụng có startup effects như in-memory cache.
• New deployment của current production version tạo ra một instance baseline tươi mới (fresh deploy), có cache cold giống hệt canary. Điều này đảm bảo so sánh công bằng về hiệu suất ban đầu (latency, throughput).
• Nếu dùng existing production (đã warm-up), metrics sẽ bias: production nhanh hơn → canary bị đánh giá thấp oan → tăng rủi ro rollback sai.
• Spinnaker hỗ trợ tự động hóa bằng cách thêm stage Bake hoặc Deploy parallel cho baseline trước analysis.

📋 Phân tí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 dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích rõ ràng:

• Compare the canary with a new deployment of the current production version.
  ✅ Đúng. Như đã giải thích ở trên, phương án này đảm bảo cả canary và baseline đều có điều kiện startup giống nhau (cache cold), tránh bias từ warm-up cache. Spinnaker khuyến nghị cấu hình parallel deployment của prod version làm baseline trong pipeline.

• Compare the canary with a new deployment of the previous production version.
  ❌ Sai. Sử dụng previous production version (phiên bản cũ hơn) không công bằng vì có thể khác biệt code/logic/cache structure so với canary (version mới). Dẫn đến so sánh không chính xác, không phản ánh cải tiến thực tế của version mới.

• Compare the canary with the existing deployment of the current production version.
  ❌ Sai. Existing deployment của production đã chạy lâu, cache đã fully warm-up → metrics tốt hơn (nhanh hơn). Canary mới deploy sẽ có cache cold → latency cao hơn → phân tích sai lệch, dễ fail canary dù version mới tốt hơn.

• Compare the canary with the average performance of a sliding window of previous production versions.
  ❌ Sai. Sliding window average (trung bình các phiên bản production trước) hữu ích cho steady-state apps không có startup effects, nhưng với in-memory cache load lúc start time, nó bỏ qua vấn đề cold start → không detect được regression (suy giảm) ở startup phase. Spinnaker hỗ trợ sliding window nhưng không khuyến nghị cho trường hợp này.

🧪 Khuyến nghị thực hành: Trong Spinnaker UI, vào Canary Stage → Analysis Configuration → Set Baseline = "New Prod Deploy" và metrics như request_latency với judge như Kayenta hoặc Optics. Test trên AWS ECS/EKS để validate! 🚀

🧩 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 Service Level Indicator (SLI) để đo lường độ trễ (latency) của trang chủ (home page) trong một ứng dụng web có lưu lượng truy cập cao. Mục tiêu là đảm bảo trang chủ tải trong thời gian chấp nhận được là 100 ms. Đây là cách tiếp cận đầu tiên để theo dõi hiệu suất, và câu hỏi yêu cầu phương pháp tính SLI theo khuyến nghị của Google (dựa trên các thực hành SRE - Site Reliability Engineering của Google).

SLI là chỉ số đo lường cụ thể cho một khía cạnh dịch vụ (ở đây là latency), thường được biểu diễn dưới dạng tỷ lệ phần trăm các yêu cầu "tốt" (good) so với tổng yêu cầu. Google khuyến nghị sử dụng SLI dạng availability-style cho latency: đếm số yêu cầu hoàn thành dưới ngưỡng (threshold) chia cho tổng số yêu cầu liên quan, thay vì sử dụng percentile phức tạp cho SLI đơn giản ban đầu. Điều này giúp dễ triển khai, theo dõi và đặt SLO (Service Level Objective) dựa trên SLI. 📘 Kiến thức dựa trên sách "Site Reliability Engineering" (SRE Book) của Google (phiên bản cập nhật đến 2023-2026, chương 4: Implementing SLOs).

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

Đáp án đúng: Count the number of home page requests that load in under 100 ms, and then divide by the total number of home page requests.

Lý do: 🛠️ Đây chính là cách Google khuyến nghị tính SLI cho latency dưới dạng tỷ lệ yêu cầu tốt (good requests ratio). Cụ thể:

• "Good requests" = số yêu cầu trang chủ tải dưới 100 ms.
• Tổng = tổng số yêu cầu trang chủ (không bao gồm các trang khác).
  Công thức: SLI = (số good requests) / (tổng home page requests).
  Phương pháp này đơn giản, chính xác cho mục tiêu "acceptable page load time 100 ms", dễ tích hợp với monitoring tools như Prometheus hoặc Cloud Monitoring. Nó tránh nhầm lẫn với percentile (dùng cho phân tích sâu hơn, không phải SLI chính). Nguồn: SRE Book - SLIs for Latency.

📋 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 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 nguyên tắc SRE Google (cập nhật 2026):

• ❌ Bucketize the request latencies into ranges, and then compute the percentile at 100 ms.
  Sai vì: Phương pháp này sử dụng histogram bucketing để tính percentile tại 100 ms, nhưng Google không khuyến nghị dùng percentile cho SLI latency cơ bản. Percentile (như P50, P95) dùng để phân tích phân bố latency, không phải định nghĩa SLI với ngưỡng cố định (100 ms). Nó phức tạp hơn và không trực tiếp biểu diễn "acceptable time". Dùng cho alerting nâng cao, không phải SLI đầu tiên. 🧮

• ❌ Bucketize the request latencies into ranges, and then compute the median and 90th percentiles.
  Sai vì: Tương tự phương án trên, đây là cách tính median (P50) và P90 từ histogram, phù hợp cho monitoring tổng quát chứ không phải SLI cụ thể với ngưỡng 100 ms. Google ưu tiên threshold-based ratio cho SLI latency để dễ đặt SLO (ví dụ: SLI > 99%). Median/P90 chỉ là metrics bổ sung, không thay thế SLI. 📊

• ✅ Count the number of home page requests that load in under 100 ms, and then divide by the total number of home page requests.
  Đúng vì: Như đã giải thích ở phần trên, đây là công thức chuẩn Google cho SLI latency: tỷ lệ yêu cầu trang chủ "tốt" (dưới 100 ms) / tổng yêu cầu trang chủ. Đơn giản, tập trung (scoped to home page), và trực tiếp đo lường mục tiêu. Dễ scale với high-traffic. 🎯

• ❌ Count the number of home page request that load in under 100 ms, and then divide by the total number of all web application requests.
  Sai vì: Phương pháp này pha loãng SLI bằng cách chia cho tổng yêu cầu toàn ứng dụng (bao gồm các trang khác có latency khác). Google yêu cầu SLI phải scoped chính xác (chỉ home page requests ở tử và mẫu), tránh "noise" từ traffic khác. Điều này làm SLI không phản ánh đúng hiệu suất trang chủ. 🚫

🛡️ Khuyến nghị bổ sung từ góc nhìn Google Cloud DevOps Engineer

• Triển khai SLI này bằng Cloud Monitoring hoặc Error Budget trong SRE practices. Theo dõi qua SLO (ví dụ: SLI > 99.5%).
• Nguồn tham khảo chính:
  📘 Google SRE Workbook - Chapter 4
  📘 SRE Book on GitHub (cập nhật 2024-2026).
  Nếu cần code sample Prometheus query hoặc Terraform cho Google Cloud, hãy cho tôi biết! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📘 Nội dung câu hỏi:
Câu hỏi mô tả tình huống một ứng dụng nội bộ được triển khai phiên bản mới vào cuối tuần (thời gian bảo trì với ít người dùng - "minimal user traffic"). Sau đó, một tính năng mới không hoạt động đúng trong môi trường production, dẫn đến gián đoạn kéo dài (extended outage). Nhóm đã rollback phiên bản mới và triển khai bản sửa lỗi.
Mục tiêu: Sửa đổi quy trình release để giảm Mean Time to Recovery (MTTR) - tức là thời gian trung bình để khôi phục hệ thống sau sự cố, nhằm tránh outage dài trong tương lai. Đây là câu hỏi multiple choice chọn hai đáp án đúng, tập trung vào các thực hành DevOps tốt nhất trên AWS để tăng tốc độ khôi phục (recovery).
Câu hỏi nhấn mạnh vấn đề ở giai đoạn post-deployment (sau triển khai), nên ưu tiên các chiến lược hỗ trợ rollback nhanh và phát hiện lỗi sớm tự động. (Kiến thức dựa trên AWS Well-Architected Framework - Reliability Pillar, cập nhật đến 2026 với các tính năng CI/CD mới trong AWS CodePipeline và CodeDeploy).

✅ Đáp án đúng (chọn hai):

• Adopt the blue/green deployment strategy when releasing new code via a CD server.
• Configure a CI server. Add a suite of unit tests to your code and have your CI server run them on commit and verify any changes.

🛠️ Lý do chọn hai đáp án đúng (giải thích chi tiết):

• Blue/green deployment giúp giảm MTTR bằng cách duy trì hai môi trường song song (blue: phiên bản cũ ổn định; green: phiên bản mới). Traffic chỉ switch sang green sau khi verify, và rollback chỉ cần switch traffic ngược lại trong vài giây, không cần redeploy. Trên AWS, dùng AWS CodeDeploy với blue/green hỗ trợ zero-downtime và nhanh chóng khôi phục (tích hợp ECS, EC2, Lambda). Điều này trực tiếp giải quyết "extended outage" bằng rollback không gián đoạn.
• CI server với unit tests phát hiện lỗi sớm ngay khi commit code, ngăn chặn việc deploy code lỗi vào production. Sử dụng AWS CodeBuild hoặc CodePipeline chạy unit tests tự động (ví dụ: Jest, JUnit), đảm bảo chỉ code chất lượng cao mới merge/deploy. Giảm MTTR vì lỗi được fix trước khi ảnh hưởng production, phù hợp nguyên tắc "shift-left testing" trong DevOps.

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

• ❌ Before merging new code, require 2 different peers to review the code changes.
  Phương án này tốt cho code quality (peer review là best practice trong GitHub/GitLab pull requests), nhưng không trực tiếp giảm MTTR sau deploy. Nó chỉ kiểm tra trước merge, không test runtime/production behavior, và vẫn có thể có lỗi ẩn sau review thủ công. Không giải quyết outage đã xảy ra.

• ✅ Adopt the blue/green deployment strategy when releasing new code via a CD server.
  Đúng vì chiến lược này cho phép rollback tức thì bằng cách reroute traffic (không cần rollback code), giảm MTTR từ giờ xuống phút. AWS CodeDeploy hỗ trợ full blue/green từ 2016 và cập nhật 2025 với traffic shifting linh hoạt hơn cho serverless.

• ❌ Integrate a code linting tool to validate coding standards before any code is accepted into the repository.
  Linting (như ESLint, SonarQube) chỉ kiểm tra style và syntax, không test logic chức năng hay integration. Không giảm MTTR vì lỗi runtime (như feature không work) vẫn có thể lọt qua. Đây là pre-commit hook tốt nhưng không phải giải pháp cốt lõi cho recovery.

• ❌ Require developers to run automated integration tests on their local development environments before release.
  Tests local không reliable (môi trường dev khác production: data, network, scale). Không tự động hóa đầy đủ, dễ bỏ sót và không tích hợp vào pipeline, dẫn đến lỗi muộn. AWS khuyến nghị chạy integration tests trên CI/CD stages thay vì local để đảm bảo tính nhất quán.

• ✅ Configure a CI server. Add a suite of unit tests to your code and have your CI server run them on commit and verify any changes.
  Đúng vì tự động hóa unit tests trên CI (AWS CodeBuild) catch lỗi sớm (trên commit), ngăn deploy code hỏng. Kết hợp với canary/blue-green, giảm MTTR toàn diện theo AWS DevOps Guru (cập nhật 2026 với AI-driven insights).

📚 Tài liệu tham khảo (AWS cập nhật mới nhất 2026):

• AWS Well-Architected Framework: Reliability Pillar - docs.aws.amazon.com/wellarchitected/latest/reliability-pillar (MTTR metrics).
• AWS CodeDeploy Blue/Green: docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html.
• CI/CD với CodePipeline/CodeBuild: docs.aws.amazon.com/codepipeline/latest/userguide/welcome-introducing.html (unit testing best practices).
• DevOps Guidance: aws.amazon.com/devops (shift-left và error budgets).

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm ví dụ code AWS CDK cho blue/green, hãy hỏi nhé.

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

Câu hỏi mô tả tình huống bạn có một nhóm máy chủ ứng dụng (application servers) chạy trên Compute Engine (dịch vụ máy ảo của Google Cloud Platform - GCP). Yêu cầu là triển khai giải pháp bảo mật, ít cấu hình nhất (least amount of configuration), và cho phép developers dễ dàng truy cập logs ứng dụng để khắc phục sự cố (troubleshooting). Giải pháp phải sử dụng các công cụ GCP, tập trung vào việc thu thập và xem logs một cách đơn giản, an toàn qua IAM roles.
📘 Kiến thức nền tảng (cập nhật đến 2026): GCP sử dụng Cloud Logging (trước đây là Stackdriver Logging) để quản lý logs. Ops Agent (tên mới của Observability agent từ năm 2022) là agent chính thức để thu thập logs và metrics từ VM Compute Engine với cấu hình tối thiểu. IAM roles kiểm soát quyền truy cập, đảm bảo bảo mật theo nguyên tắc least privilege.

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

Đáp án đúng: Phương án đầu tiên

• Deploy the Observability logging agent to the application servers. • Give the developers the IAM Logs Viewer role to access Observability and view logs.

Lý do:

• Ops Agent (Observability logging agent) được deploy đơn giản qua một lệnh cài đặt (hoặc automation như Terraform/Deployment Manager), tự động thu thập logs ứng dụng mà không cần script phức tạp. Đây là giải pháp ít config nhất được GCP khuyến nghị (one-click install trên Compute Engine).
• IAM Logs Viewer role (tức roles/logging.viewer) cho phép developers xem logs trong Cloud Logging mà không cần quyền admin, đảm bảo bảo mật và dễ truy cập qua Console hoặc CLI. Không ảnh hưởng đến metrics hay storage.
  🛠️ Ưu điểm: Tích hợp native với GCP Observability, real-time logs, query dễ dàng qua Logs Explorer. Ít config hơn các cách thủ công như cron jobs.

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

Dưới đây là phân tích từng phương án một cách chi tiết. Tôi giữ nguyên văn bản gốc tiếng Anh của các lựa chọn, chỉ giải thích bằng tiếng Việt với lý do đúng/sai dựa trên best practices GCP (phiên bản mới nhất Ops Agent v2.15+ năm 2026).

• Phương án 1 (Đúng ✅):

  • Deploy the Observability logging agent to the application servers. • Give the developers the IAM Logs Viewer role to access Observability and view logs.
  

  ✅ Đúng vì: Đây là giải pháp chuẩn của GCP cho logs trên Compute Engine. Ops Agent thu thập logs tự động (fluentbit-based), IAM Logs Viewer (roles/logging.viewer) cấp quyền xem logs public/private một cách an toàn, không cần config thêm. Ít bước nhất: deploy agent → assign role → truy cập Logs Explorer. Phù hợp hoàn hảo với yêu cầu "least configuration" và "easy access".

• Phương án 2 (Sai ❌):

  • Deploy the Observability logging agent to the application servers. • Give the developers the IAM Logs Private Logs Viewer role to access Observability and view logs.
  

  ❌ Sai vì: Role roles/logging.privateLogViewer chỉ cho phép xem private logs (như audit logs hệ thống GCP), không đầy đủ cho application logs thông thường. Nó hạn chế hơn Logs Viewer, dẫn đến developers không xem được hết logs cần thiết. Vi phạm nguyên tắc "easy access" và không phải giải pháp tối ưu.

• Phương án 3 (Sai ❌):

  • Deploy the Observability monitoring agent to the application servers. • Give the developers the IAM Monitoring Viewer role to access Observability and view metrics.
  

  ❌ Sai vì: Observability monitoring agent (phần monitoring của Ops Agent) chỉ thu thập metrics (CPU, memory), không phải logs. Role roles/monitoring.viewer chỉ xem metrics trong Cloud Monitoring, không hỗ trợ logs. Câu hỏi tập trung vào "application logs for troubleshooting", nên phương án này lệch hướng hoàn toàn.

• Phương án 4 (Sai ❌):

  • Install the gsutil command line tool on your application servers. • Write a script using gsutil to upload your application log to a Cloud Storage bucket, and then schedule it to run via cron every 5 minutes. • Give the developers the IAM Object Viewer access to view the logs in the specified bucket.
  

  ❌ Sai vì: Giải pháp thủ công, nhiều config cao (cài gsutil, viết script, cron job 5 phút → delay logs, rủi ro mất logs nếu script lỗi). Không real-time, không tích hợp Observability, IAM Object Viewer (roles/storage.objectViewer) chỉ xem files bucket chứ không query logs như Cloud Logging. Không bảo mật bằng (logs public trong bucket) và không "least configuration".

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

• Ops Agent installation: cloud.google.com/stackdriver/docs/solutions/agents/ops-agent 🛠️ (Hướng dẫn deploy nhanh trên Compute Engine).
• IAM roles for Logging: cloud.google.com/logging/docs/access-control 📘 (Chi tiết roles/logging.viewer vs privateLogViewer).
• Best practices logs: cloud.google.com/logging/docs/best-practices ✅ (Khuyến nghị agent native thay vì custom scripts).
• Observability overview: cloud.google.com/observability (Tích hợp Logging + Monitoring).

Giải pháp này đảm bảo DevOps best practices: Automate, secure, observable! 🚀

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

Câu hỏi tập trung vào việc tối ưu hóa chi phí mạng (network cost) cho backend của một trò chơi di động chạy trên Google Kubernetes Engine (GKE) cluster. Ứng dụng đang xử lý các yêu cầu HTTP từ người dùng (có thể từ internet bên ngoài). Mục tiêu là triển khai giải pháp giảm chi phí mạng mà không ảnh hưởng đến chức năng chính.

🔍 Chi tiết vấn đề:

• GKE là dịch vụ Kubernetes managed của Google Cloud, thường xử lý traffic inbound/outbound qua các Load Balancer hoặc Ingress.
• Network cost chủ yếu phát sinh từ egress traffic (dữ liệu ra ngoài VPC, như phản hồi HTTP đến người dùng toàn cầu).
• Google Cloud có hai Network Service Tiers: Premium (mạng toàn cầu cao cấp, nhanh nhưng đắt) và Standard (mạng khu vực, rẻ hơn cho egress).
• Giải pháp cần chọn phải trực tiếp giảm chi phí mà không làm phức tạp hóa kiến trúc.

Dựa trên tài liệu Google Cloud cập nhật đến năm 2026 (phiên bản mới nhất: Cloud Networking Pricing và GKE Networking), việc chọn tier mạng phù hợp là chìa khóa để giảm chi phí lên đến 60-80% cho egress traffic so với Premium Tier mặc định.

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

Đáp án đúng: Configure your network services on the Standard Tier.

Lý do chi tiết 🛠️:

• Standard Tier sử dụng mạng internet công cộng khu vực (regional), giúp giảm đáng kể chi phí egress traffic (dữ liệu gửi ra internet) so với Premium Tier (mạng toàn cầu cao cấp của Google, đắt hơn ~3-5 lần cho cùng lượng data).
• Trong GKE, các dịch vụ như Load Balancer, Ingress tự động dùng Premium Tier mặc định. Việc cấu hình sang Standard Tier (qua gcloud hoặc Terraform: --network-tier=STANDARD) sẽ áp dụng cho toàn bộ network services, trực tiếp giảm cost mà không cần thay đổi cluster.
• Phù hợp hoàn hảo cho ứng dụng game mobile với traffic HTTP cao từ users toàn cầu, vì Standard Tier vẫn đảm bảo hiệu suất tốt ở mức khu vực mà chi phí thấp hơn. Theo pricing 2026, Standard Tier chỉ tính ~$0.01/GB egress so với ~$0.085-0.12/GB của Premium.

📘 Nguồn tham khảo:

• Google Cloud Network Pricing (cập nhật 2026).
• GKE Networking Best Practices (khuyến nghị Standard cho cost-sensitive workloads).

📋 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, với đánh giá đúng/sai dựa trên tác động đến network cost:

• Configure the VPC as a Shared VPC Host project. ❌ Sai
  Shared VPC Host project dùng để chia sẻ VPC giữa nhiều projects, giúp quản lý central hóa và bảo mật. Tuy nhiên, nó không ảnh hưởng trực tiếp đến network cost vì chi phí egress vẫn phụ thuộc vào Network Tier (Premium/Standard). Việc này chỉ phức tạp hóa architecture mà không giảm chi phí traffic HTTP từ GKE.

• Configure your network services on the Standard Tier. ✅ Đúng (như đã giải thích ở trên)
  🛠️ Đây là giải pháp tối ưu, trực tiếp chuyển từ Premium sang Standard để tiết kiệm chi phí egress lớn nhất cho HTTP traffic ra ngoài.

• Configure your Kubernetes cluster as a Private Cluster. ❌ Sai
  Private Cluster ẩn master/control plane và nodes khỏi internet, tăng bảo mật bằng cách dùng Private IPs. Nhưng nó không giảm network cost; ngược lại, có thể tăng nhẹ chi phí do traffic nội bộ VPC. Egress traffic đến users vẫn tính phí theo tier hiện tại (thường Premium), không giải quyết vấn đề chính.

• Configure a Google Cloud HTTP Load Balancer as Ingress. ❌ Sai
  GKE Ingress đã mặc định dùng Google Cloud HTTP(S) Load Balancer (global/regional). Việc cấu hình thêm LB không giảm cost vì LB này thường dùng Premium Tier và có phí riêng (~$0.025/giờ + data processing). Traffic egress từ LB ra users vẫn đắt nếu không đổi tier, thậm chí tăng overhead không cần thiết.

💡 Kết luận và khuyến nghị

✅ Tóm tắt: Chọn Standard Tier là cách đơn giản, hiệu quả nhất để giảm network cost ngay lập tức. Để triển khai: Sử dụng gcloud compute networks subnets update hoặc annotation trong Ingress YAML (networking.gke.io/load-balancer-type: "Internal" kết hợp tier). Theo dõi cost qua Cloud Billing Reports và Network Intelligence Center. Nếu workload cao, kết hợp với Cloud CDN để cache và giảm egress thêm nữa!

📘 Tài liệu bổ sung: Choosing a Network Service Tier & GKE Cost Optimization.