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

🧩 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 triển khai containerized microservices trên Google Kubernetes Engine (GKE) với pipeline CI/CD mạnh mẽ. 🔒 Ưu tiên bảo mật cao, công ty cần chiến lược toàn diện và hiệu quả để ngăn chặn lỗ hổng (vulnerabilities) từ container images lan đến môi trường production GKE.

📌 Yêu cầu chọn hai hành động đúng (Choose two) nhằm:

• Phát hiện và chặn vulnerabilities từ sớm (shift-left security).
• Sử dụng các công cụ Google Cloud tích hợp như Artifact Registry (với Artifact Analysis cho vulnerability scanning), base images chính thức từ Google, và các tính năng GKE.
• Tránh các biện pháp thủ công hoặc không liên quan trực tiếp đến scanning images.

🛠️ Bối cảnh cập nhật 2026: Theo tài liệu Google Cloud mới nhất (Artifact Registry Vulnerability Scanning, Binary Authorization for GKE), chiến lược tốt nhất là tích hợp scanning tự động trước/sau build, sử dụng Google-maintained distroless/base images (như distroless, Cloud Run images) để giảm bề mặt tấn công, và block deployment nếu có critical vulns qua CI/CD (như Cloud Build hoặc GitHub Actions).

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

• Artifact Registry Vulnerability Scanning (Google Cloud Docs, cập nhật 2025).
• Hardening GKE with Binary Authorization (Prevent vulns in prod).
• GKE Security Best Practices (2026 edition).

✅ Đáp án đúng (Chọn hai phương án sau)

Các đáp án đúng là:

• Incorporate vulnerability scanning before building container images, and use Google-maintained base images for your container deployments.
• Enable Artifact Analysis for the container images, and stop deployment if critical vulnerabilities are found.

Lý do lựa chọn 📈:

• Hai phương án này tạo chiến lược shift-left toàn diện: Scanning trước build (pre-build) + sử dụng base images an toàn từ Google (giảm 90%+ vulns phổ biến theo báo cáo Google), kết hợp enable Artifact Analysis (tự động scan trong Artifact Registry) và block deployment nếu critical (tích hợp CI/CD như Cloud Build với gcloud artifacts print-settings hoặc Policy Controller).
• Hiệu quả cao, tự động hóa, ngăn vulns từ nguồn trước khi đến GKE prod, phù hợp best practices 2026. ✅

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

• Review the security reports generated by Artifact Analysis for each container image before deployment to GKE.
  ❌ Sai: Phương án này yêu cầu review thủ công reports từ Artifact Analysis (vulnerability scanning tool trong Artifact Registry). Không hiệu quả cho pipeline CI/CD nhanh (rapid deployment), dễ lỗi con người và chậm trễ. Nên dùng tự động block thay vì manual review. 🕒

• Incorporate vulnerability scanning before building container images, and use Google-maintained base images for your container deployments.
  ✅ Đúng: Scanning pre-build (shift-left, ví dụ: Trivy/Skaffold trong CI) + Google-maintained base images (như gcr.io/distroless/* hoặc us.gcr.io/cloudrun/*) giảm đáng kể vulns (không OS bloat, updated regularly). Đây là best practice #1 cho GKE security 2026. 🚀

• Enable Artifact Analysis for the container images, and stop deployment if critical vulnerabilities are found.
  ✅ Đúng: Enable Artifact Analysis (Container Analysis API, scan tự động khi push lên Artifact Registry) + stop deployment (qua Binary Authorization hoặc Attestation/Policy Controller) chặn critical vulns (CVSS >7.0) trước khi đến GKE prod. Tích hợp hoàn hảo CI/CD. 🛡️

• Use a custom security policy within your container image that restricts access to specific network ports and resources.
  ❌ Sai: Đây là security policy runtime (như PodSecurityPolicy hoặc NetworkPolicy trong Kubernetes), không liên quan đến vulnerabilities trong image (pre-runtime). Không ngăn images có lỗ hổng như outdated libraries. 🔒❌

• Enable Shielded GKE Nodes on the production cluster to automatically block the execution of container images with known vulnerabilities.
  ❌ Sai: Shielded GKE Nodes bảo vệ node-level (secure boot, integrity monitoring chống rootkits/malware trên host), không scan/block container images vulns. Vulns vẫn chạy nếu image đã deploy. Shielded chỉ detect post-deployment. 🖥️❌

🧩 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 triển khai một ứng dụng cloud-native mới trên Google Cloud, với yêu cầu đảm bảo tuân thủ khung ISO/IEC 27001 (một tiêu chuẩn quốc tế về hệ thống quản lý an ninh thông tin - ISMS). Tổ chức cần sử dụng các báo cáo và tài liệu bảo mật của Google Cloud để hỗ trợ quy trình kiểm toán ISO/IEC 27001.

📌 Bối cảnh chính:

• ISO/IEC 27001 yêu cầu chứng minh rằng nhà cung cấp đám mây (như Google Cloud) tuân thủ các kiểm soát an ninh.
• Google Cloud cung cấp các báo cáo tuân thủ (compliance reports) để khách hàng hỗ trợ kiểm toán nội bộ hoặc bên thứ ba.
• Mục tiêu là chọn cách đúng đắn, chính thức để truy cập báo cáo này qua tài khoản Google Cloud, tránh các phương pháp không an toàn hoặc không chính thức.

🛠️ Kiến thức cập nhật (đến 2026): Google Cloud duy trì chứng nhận ISO/IEC 27001 (phiên bản mới nhất 2022), và cung cấp Compliance Reports Manager (CRM) trong Google Cloud Console để quản lý truy cập báo cáo. Điều này được hỗ trợ qua các hợp đồng Enterprise Agreement hoặc tương đương, với các báo cáo như SOC, ISO 27001 Statement of Applicability (SOA).

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

• Google Cloud Compliance Resource Center
• Compliance Reports Manager Documentation
• ISO 27001 Certification Details

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

Đáp án đúng: Review the Compliance Reports Manager for information about ISO/IEC 27001 compliance and related documentation on obtaining reports through your Google Cloud account.

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

• Compliance Reports Manager (CRM) là công cụ chính thức trong Google Cloud Console, dành riêng để xem thông tin tuân thủ ISO/IEC 27001 và hướng dẫn tải báo cáo (như ISO 27001 Certificate, SOA).
• Quy trình: Đăng nhập tài khoản Google Cloud → Truy cập CRM (dưới Resource Manager) → Kiểm tra eligibility và yêu cầu báo cáo nếu đủ điều kiện (thường cần Google Workspace hoặc Cloud contract).
• Đây là cách an toàn, được hỗ trợ chính thức, giúp tổ chức tự hỗ trợ kiểm toán mà không cần bên thứ ba ngay lập tức, phù hợp với best practice của Google Cloud Architect.

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

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á với lý do cụ thể dựa trên thực tiễn Google Cloud:

• [SAI] Engage an independent auditor to conduct an ISO/IEC 27001 audit of your organization's Google Cloud implementation.
  ❌ Sai vì: Phương án này tập trung vào kiểm toán toàn bộ implementation của tổ chức (bao gồm code, config), không phải chỉ lấy báo cáo bảo mật từ Google Cloud. Câu hỏi chỉ yêu cầu leverage Google Cloud’s reports để hỗ trợ kiểm toán, không bắt buộc auditor độc lập ngay. Điều này tốn kém và không trực tiếp giải quyết việc truy cập tài liệu GCP.

• [SAI] Download the ISO/IEC 27001 report for Google Cloud through internet search.
  ❌ Sai vì: Tìm kiếm internet có thể dẫn đến tài liệu lỗi thời, giả mạo hoặc không chính thức. Báo cáo ISO 27001 của Google Cloud là confidential, chỉ truy cập qua CRM với tài khoản hợp lệ (không public). Rủi ro bảo mật cao, vi phạm nguyên tắc least privilege.

• [ĐÚNG] Review the Compliance Reports Manager for information about ISO/IEC 27001 compliance and related documentation on obtaining reports through your Google Cloud account.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là cách chính thức và được khuyến nghị. CRM cung cấp dashboard xem compliance status, eligibility checker và hướng dẫn yêu cầu báo cáo ISO 27001 trực tiếp từ tài khoản GCP, hỗ trợ audit process hiệu quả.

• [SAI] Utilize the Cloud Audit Logs service for accessing and requesting the ISO/IEC 27001 reports.
  ❌ Sai vì: Cloud Audit Logs dùng để ghi nhật ký hoạt động (admin/activity logs), không lưu trữ hoặc cung cấp báo cáo tuân thủ như ISO 27001. Nó chỉ theo dõi sự kiện runtime, không liên quan đến compliance documentation. Sử dụng sai công cụ sẽ không đạt mục tiêu.

🧠 Lời khuyên từ Google Cloud Professional Cloud Architect: Để tối ưu, hãy kích hoạt CRM qua IAM roles phù hợp (như Compliance Viewer) và kết hợp với Security Command Center để theo dõi compliance liên tục! 🚀

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

📘 Nội dung câu hỏi:
Câu hỏi tập trung vào tình huống một Site Reliability Engineer (SRE) đang giám sát các cụm Google Kubernetes Engine (GKE) trong một Cloud Monitoring workspace trên Google Cloud Platform (GCP). Nhiệm vụ chính là triage incidents một cách nhanh chóng (tức là phân loại, ưu tiên và xử lý sự cố kịp thời). SRE cần một phương pháp hiệu quả để xem xét metrics ngay lập tức mà không mất thời gian thiết lập phức tạp.
✅ Mục tiêu chính: Sử dụng các công cụ sẵn có trong Cloud Monitoring để truy cập nhanh dữ liệu giám sát GKE, bao gồm dashboards và alerting, giúp giảm thời gian phản ứng với sự cố.
🛠️ Bối cảnh kiến thức GCP (cập nhật đến 2026): Cloud Monitoring (trước đây là Stackdriver) cung cấp predefined dashboards chuyên biệt cho GKE, hiển thị metrics như CPU, memory, pod status, node health... Những dashboard này được tối ưu hóa sẵn, cho phép SRE triage nhanh mà không cần tùy chỉnh ban đầu. Sau đó, có thể mở rộng bằng cách thêm metrics tùy chỉnh và tạo alert policies để tự động hóa.

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

Đáp án đúng: Phương án 1
1. Navigate the predefined dashboards in the Cloud Monitoring workspace.
2. Add metrics and create alert policies.

Lý do chi tiết:
✅ Phương án này là cách nhanh nhất và chuẩn best practice cho SRE trong GCP.

• Bước 1: Sử dụng predefined dashboards (sẵn có trong Cloud Monitoring) để ngay lập tức xem tổng quan metrics GKE như cluster health, workload, autoscaling... Giúp triage incidents chỉ trong vài giây mà không cần build từ đầu.
• Bước 2: Sau khi xác định vấn đề, thêm metrics cụ thể (custom metrics) và tạo alert policies để cảnh báo tự động cho các sự cố tương lai.
  🧩 Điều này phù hợp với nguyên tắc SRE: Observe trước (dùng ready-made tools), rồi Instrument (tùy chỉnh alerting). Không yêu cầu script custom hay infra thêm, giảm MTTR (Mean Time To Recovery).

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

• Cloud Monitoring documentation - GKE dashboards (Google Cloud Docs, cập nhật 2025).
• Best practices for monitoring GKE (Khuyến nghị chính thức GCP).

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

Dưới đây là giải thích từng phương án một cách chi tiết, với nội dung gốc giữ nguyên tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên hiệu quả triage nhanh cho SRE.

• ✅ Phương án ĐÚNG (1):
  1. Navigate the predefined dashboards in the Cloud Monitoring workspace.
  2. Add metrics and create alert policies.
  Giải thích: Như đã nêu ở trên, đây là quy trình tối ưu nhất, tận dụng native tools của Cloud Monitoring. Predefined dashboards cho GKE (như "GKE Cluster Master", "GKE Workloads") hiển thị metrics thời gian thực, giúp SRE nhanh chóng pinpoint vấn đề (ví dụ: pod crash, OOM). Sau đó, alert policies tích hợp Slack/PagerDuty để notify. Hoàn hảo cho tốc độ!

• ❌ Phương án SAI (2):
  1. Write a shell script that gathers metrics from GKE nodes, and publish these metrics to a Pub/Sub topic.
  2. Export the data to BigQuery. and make a Data Studio dashboard.
  Giải thích: Phương án này quá phức tạp và chậm, không phù hợp triage nhanh. Viết shell script custom để thu thập metrics từ nodes rồi push qua Pub/Sub đòi hỏi phát triển, test và maintain – mất hàng giờ/giờ. Export sang BigQuery + Looker Studio (trước là Data Studio) chỉ tốt cho phân tích sâu dài hạn, không phải real-time incident response. Không scale cho SRE!

• ❌ Phương án SAI (3):
  1. Create a custom dashboard in the Cloud Monitoring workspace for each incident.
  2. Add metrics and create alert policies.
  Giải thích: Tạo custom dashboard cho từng incident là lãng phí thời gian – SRE cần hành động ngay, không phải build dashboard mới mỗi lần (có thể mất 10-30 phút). Dù bước 2 tốt, nhưng tổng thể làm chậm triage. Predefined dashboards đã đủ cho hầu hết cases, custom chỉ dùng sau. Không hiệu quả khẩn cấp!

• ❌ Phương án SAI (4):
  1. Navigate the predefined dashboards in the Cloud Monitoring workspace.
  2. Create custom metrics and install alerting software on a Compute Engine instance.
  Giải thích: Bước 1 đúng (predefined dashboards tốt), nhưng bước 2 thêm overhead không cần thiết. Tạo custom metrics ok, nhưng install alerting software (như Prometheus/Zabbix) trên Compute Engine instance yêu cầu setup VM, networking, security – phức tạp và tốn kém. Cloud Monitoring đã có alerting native (uptime checks, anomaly detection), không cần external tools. Làm chậm quy trình SRE!

🛠️ Kết luận: Chọn phương án 1 để đảm bảo tốc độ cao nhất trong monitoring GKE. Nếu áp dụng thực tế, hãy enable GKE monitoring tự động qua control plane để có dashboards sẵn! 🚀