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

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

Câu hỏi tập trung vào việc sử dụng Google Cloud Build (một dịch vụ CI/CD của Google Cloud Platform - GCP) để xây dựng một Docker image. Yêu cầu cụ thể là sửa đổi quy trình build để thực thi unit tests (kiểm thử đơn vị) và integration tests (kiểm thử tích hợp). Quan trọng nhất, khi có lỗi thất bại (failure), lịch sử build (build history) phải hiển thị rõ ràng giai đoạn (stage) nào gây ra lỗi.

🛠️ Mục tiêu chính:

• Tích hợp tests vào pipeline build mà không làm gián đoạn quy trình chính.
• Đảm bảo tính minh bạch và dễ debug trong Cloud Build console, nơi mỗi bước (step) được ghi log riêng biệt và đánh dấu fail rõ ràng nếu lỗi xảy ra.
• Cloud Build sử dụng file cấu hình cloudbuild.yaml để định nghĩa các steps (bước xây dựng), mỗi step chạy trong container riêng và có thể tùy chỉnh builder (như gcr.io/cloud-builders/docker hoặc custom).

📘 Kiến thức cập nhật (đến 2026): Theo tài liệu GCP mới nhất (Cloud Build v1.0+ với hỗ trợ BuildMatrix, Substitution Variables cải tiến), các steps riêng biệt là best practice để granular visibility vào failures, hỗ trợ parallel execution và caching tốt hơn.

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

Đáp án đúng: Create a Cloud Build build config file with separate cloud builder steps to compile and execute unit and integration tests.

Lý do 🏆:

• File cloudbuild.yaml cho phép định nghĩa nhiều steps riêng biệt (ví dụ: một step compile code, step chạy unit tests, step chạy integration tests). Mỗi step là một giai đoạn độc lập, chạy trong container riêng với builder cụ thể (như gcr.io/cloud-builders/go hoặc gcr.io/cloud-builders/npm).
• Khi failure xảy ra, Cloud Build history sẽ hiển thị chính xác step nào fail (với log chi tiết, status "FAILURE" và timestamp), giúp debug nhanh chóng. Điều này phù hợp hoàn hảo với yêu cầu "clearly display the stage".
• Không ảnh hưởng đến việc build Docker image chính, và hỗ trợ trigger tự động qua Git repo hoặc Pub/Sub.

🔍 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do bằng tiếng Việt:

• ❌ [SAI] Add RUN commands in the Dockerfile to execute unit and integration tests.
  Lý do sai: Thêm RUN vào Dockerfile sẽ chạy tests trong quá trình build image (layer baked vào image), không tạo stages riêng biệt. Nếu fail, build history chỉ hiển thị lỗi tổng quát từ Docker build step, không rõ ràng stage cụ thể (khó debug vì log bị lẫn với các layer khác). Không khuyến khích vì tests nên chạy ngoài image production để tránh bloat image và dễ fail silent.

• ❌ [SAI] Create a Cloud Build build config file with a single build step to compile unit and integration tests.
  Lý do sai: Sử dụng một step duy nhất trong cloudbuild.yaml để compile và chạy tất cả tests sẽ làm toàn bộ step fail nếu bất kỳ test nào lỗi, không phân biệt stage cụ thể (unit hay integration). Build history chỉ báo "Step #X failed" mà không granular, vi phạm yêu cầu "clearly display the stage".

• ❌ [SAI] Create a Cloud Build build config file that will spawn a separate cloud build pipeline for unit and integration tests.
  Lý do sai: Tạo pipeline con riêng biệt (sử dụng trigger hoặc gcloud builds submit trong step) sẽ chạy tests ngoài build chính, dẫn đến history phân tán (không hiển thị trong cùng một build log). Failure ở pipeline con không tự động reflect rõ ràng vào build gốc, làm phức tạp theo dõi và không đáp ứng "build history clearly display the stage" trong cùng pipeline.

• ✅ [ĐÚNG] Create a Cloud Build build config file with separate cloud builder steps to compile and execute unit and integration tests.
  Lý do đúng: Như đã giải thích ở trên, separate steps (ví dụ: step1: compile, step2: unit tests, step3: integration tests) đảm bảo mỗi giai đoạn độc lập. Cloud Build tự động log và highlight step fail trong UI/console, hỗ trợ waitFor và timeout để kiểm soát flow. Best practice theo GCP.

📘 Tài liệu tham khảo

• Chính thức GCP: Cloud Build Configuration File (cập nhật 2025: Hỗ trợ dynamic substitutions và matrix builds).
• Best Practices: Testing in Cloud Build – Khuyến nghị separate steps cho tests.
• Ví dụ cloudbuild.yaml:

  steps:
  - name: 'gcr.io/cloud-builders/go'
    args: ['test', './unit']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/myimage', '.']
  

• Console Demo: Cloud Build dashboard hiển thị steps với màu đỏ/xanh cho failures (xem tại console.cloud.google.com/cloud-build).

Hy vọng phân tích này giúp bạn ôn tập hiệu quả! 🚀 Nếu cần ví dụ code chi tiết, hãy hỏi thêm.

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

Câu hỏi thuộc chủ đề Google Cloud Platform (GCP), cụ thể là về IAM (Identity and Access Management) và quyền truy cập giữa các project khi sử dụng Cloud Functions và Cloud Storage.

📖 Tình huống chi tiết:

• Code đang chạy trên Cloud Functions thuộc project A.
• Code này cố gắng ghi (write) một object vào Cloud Storage bucket thuộc project B (bucket do project B sở hữu).
• Lỗi gặp phải: "403 Forbidden" – nghĩa là yêu cầu bị từ chối do thiếu quyền truy cập (permission denied).
• Vấn đề cốt lõi: Cloud Functions chạy dưới quyền của một service account đặc biệt (không phải tài khoản người dùng), nên cần cấp quyền đúng cho service account đó để truy cập tài nguyên cross-project.
• Mục tiêu: Xác định hành động chính xác để khắc phục lỗi, dựa trên nguyên tắc least privilege (quyền tối thiểu cần thiết) trong IAM GCP (cập nhật đến phiên bản mới nhất 2024-2026, Cloud Functions 1st gen sử dụng service account mặc định gcf-admin-robot).

🛠️ Nguyên tắc GCP liên quan (dựa trên docs mới nhất):

• Cloud Functions (1st gen) chạy với service account: PROJECT_ID@gcf-admin-robot.iam.gserviceaccount.com.
• Để ghi object vào bucket, cần role roles/storage.objectCreator (cho phép tạo object mới).
• Quyền phải cấp trên bucket ở project B cho service account từ project A.

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

Đáp án đúng: Grant the service-PROJECTA@gcf-admin-robot.iam.gserviceaccount.com service account the roles/storage.objectCreator role for the Cloud Storage bucket.

Lý do chi tiết 🏆:

• Cloud Functions ở project A chạy dưới service account mặc định service-PROJECTA@gcf-admin-robot.iam.gserviceaccount.com (thay PROJECTA bằng ID thực của project A).
• Lỗi 403 xảy ra vì service account này không có quyền ghi vào bucket của project B.
• Cấp roles/storage.objectCreator cho service account này trên bucket cụ thể sẽ cho phép tạo object (write), mà không ảnh hưởng quyền khác.
• Đây là cách chuẩn GCP cho cross-project access, tuân thủ IAM best practices (không cấp quyền user account vì function không dùng user credentials).
• ✅ Hiệu quả ngay lập tức sau khi grant quyền (propagate trong vài phút).

📋 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, giữ nguyên văn bản gốc tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do dựa trên kiến thức GCP mới nhất (2024-2026).

• Grant your user account the roles/storage.objectCreator role for the Cloud Storage bucket.
  ❌ Sai.
  Lý do: Cloud Functions không chạy dưới user account (tài khoản người dùng của bạn), mà dưới service account của function. Cấp quyền cho user account chỉ ảnh hưởng khi bạn truy cập thủ công qua gsutil/console, không sửa lỗi runtime của function. Đây là lỗi phổ biến nhầm lẫn identity (user vs service account).

• Grant your user account the roles/iam.serviceAccountUser role for the service-PROJECTA@gcf-admin-robot.iam.gserviceaccount.com service account.
  ❌ Sai.
  Lý do: Role roles/iam.serviceAccountUser cho phép user impersonate (giả mạo) service account, nhưng không cấp quyền truy cập Storage cho service account. Function vẫn thiếu quyền objectCreator trên bucket project B. Hơn nữa, impersonation chỉ hữu ích cho dev/testing, không phải production fix cho function runtime.

• Grant the service-PROJECTA@gcf-admin-robot.iam.gserviceaccount.com service account the roles/storage.objectCreator role for the Cloud Storage bucket.
  ✅ Đúng (như đã giải thích ở phần đáp án).
  Lý do: Trực tiếp cấp quyền cần thiết cho service account chạy function. Role này cho phép tạo object (storage.objects.create), khớp với "write an object". Áp dụng cho cross-project, bucket-level binding là optimal (không cần project-wide).

• Enable the Cloud Storage API in project B.
  ❌ Sai.
  Lý do: Cloud Storage API mặc định enabled ở mọi project GCP (không cần bật thủ công như một số API khác). Lỗi 403 là vấn đề IAM, không phải API disabled. Kiểm tra bằng gcloud services list --project=B sẽ thấy storage.googleapis.com đã active.

📘 Tài liệu tham khảo (GCP docs mới nhất 2024-2026)

• Cloud Functions service accounts: docs.cloud.google.com/functions/docs/securing/function-identity (xác nhận gcf-admin-robot SA).
• IAM roles for Storage: cloud.google.com/storage/docs/access-control/iam-roles (roles/storage.objectCreator).
• Troubleshoot 403 in cross-project: cloud.google.com/storage/docs/troubleshooting.
• Best practices IAM: cloud.google.com/iam/docs/best-practices-service-accounts.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần demo lệnh gcloud, hãy hỏi thêm.

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

Câu hỏi thuộc phần case study của kỳ thi chứng chỉ Google Cloud (cụ thể là liên quan đến Professional Cloud Developer hoặc tương tự), mô tả tình huống thực tế của công ty HipLocal – một ứng dụng cộng đồng hyper-local đang mở rộng toàn cầu.

Tổng quan case study:

• Môi trường hiện tại: Ứng dụng chạy trên Compute Engine VM ở GCP, database MySQL đơn lẻ, export data sang on-premises (Teradata/Vertica và Hadoop), không có logging, chỉ có chỉ số uptime cơ bản và alert thường xuyên khi API unresponsive.
• Yêu cầu kinh doanh: Mở rộng vùng địa lý, tăng concurrent users, trải nghiệm nhất quán, metrics user activity, tuân thủ quy định (GDPR), giảm quản lý infra, áp dụng best practices GCP.
• Yêu cầu kỹ thuật: Cung cấp metrics/monitoring, auth mạnh mẽ, tăng logging lưu vào cloud analytics, chuyển sang serverless để elastic scaling, truy cập nội bộ an toàn.
• Vấn đề cụ thể của câu hỏi: HipLocal's .net-based auth service fails under intermittent load (Dịch vụ xác thực dựa trên .NET của HipLocal bị lỗi dưới tải ngắt quãng). Họ cần giải pháp xử lý tải biến động, phù hợp với hướng serverless và autoscaling.

Mục tiêu câu hỏi: Tìm giải pháp thay thế cho auth service .NET hiện tại để chịu tải intermittent (tải đột ngột, không liên tục), đảm bảo elastic scaling, giảm quản lý, và phù hợp serverless theo technical requirements. Giải pháp phải tận dụng GCP services cập nhật đến 2024-2026 (App Engine vẫn là lựa chọn serverless hàng đầu cho apps full-stack như .NET).

📘 Nguồn tham khảo:

• Google Cloud App Engine Documentation (2024)
• GCP Serverless Best Practices
• HipLocal Case Study - Google Cloud Skills Boost (case study mẫu trong training).

✅ Đáp án đúng: Use App Engine for autoscaling

Lý do lựa chọn:

• App Engine là nền tảng serverless hoàn hảo cho ứng dụng .NET-based, hỗ trợ autoscaling tự động (automatic scaling) dựa trên traffic/load, xử lý tốt intermittent load mà không cần quản lý VM/infra.
• App Engine Flexible environment hỗ trợ .NET runtime (ASP.NET Core), deploy dễ dàng từ container/Docker, tích hợp IAM cho auth mạnh mẽ, metrics/monitoring qua Cloud Monitoring/Logging.
• Phù hợp technical requirements: Serverless elastic scaling, giảm chi phí quản lý, tuân thủ Google-recommended practices. Dưới tải ngắt quãng, App Engine scale từ 0 instances lên nhanh chóng (cold start ~giây), đảm bảo uptime cao.
• Cập nhật 2024-2026: App Engine hỗ trợ .NET 8+, multi-region deployment cho global scale, tích hợp AlloyDB/Cloud SQL cho state.

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

• ✅ Use App Engine for autoscaling
  Đúng vì: Như phân tích trên, đây là giải pháp serverless lý tưởng cho .NET auth service, autoscaling tự động xử lý intermittent load hiệu quả, không cần quản lý server, phù hợp yêu cầu migrate sang serverless và global scale. Giảm thời gian quản lý infra xuống mức thấp nhất.

• ❌ Use Cloud Functions for autoscaling
  Sai vì: Cloud Functions là serverless cho event-driven functions (nhỏ, stateless), không phù hợp full auth service .NET-based phức tạp (cần state/session, HTTP server liên tục). Không hỗ trợ .NET đầy đủ như App Engine (chỉ Node.js/Python/Go/Java/.NET hạn chế), cold start chậm hơn dưới tải intermittent, và khó integrate logging/metrics toàn diện cho service lớn.

• ❌ Use a Compute Engine cluster for the service
  Sai vì: Compute Engine (với MIG - Managed Instance Groups) hỗ trợ autoscaling nhưng không serverless, đòi hỏi quản lý OS/patches/security (vi phạm yêu cầu "reduce infrastructure management time and cost"). Không elastic như App Engine, khó scale global nhanh, và hiện tại họ đã gặp vấn đề với Compute Engine APIs unresponsive.

• ❌ Use a dedicated Compute Engine virtual machine instance for the service
  Sai vì: Dedicated VM không autoscaling, chỉ scale thủ công/fixed size, dễ fail dưới intermittent load (như vấn đề hiện tại). Tăng chi phí quản lý cao, không tuân thủ serverless requirement, và không giải quyết alerting/uptime issues.

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

Câu hỏi thuộc case study về công ty HipLocal, một ứng dụng cộng đồng hyper-local đang mở rộng toàn cầu trên Google Cloud Platform (GCP). Môi trường hiện tại bao gồm:

• APIs chạy trên Compute Engine (VM instances).
• Không có logging, chỉ có chỉ số uptime cơ bản và alert khi API unresponsive.
• Vấn đề cụ thể: APIs gặp occasional application failures (lỗi ứng dụng thỉnh thoảng xảy ra).
• Mục tiêu: Thu thập thông tin ứng dụng (application information) để troubleshoot (khắc phục sự cố).

📘 Bối cảnh kinh doanh & kỹ thuật: HipLocal cần mở rộng quy mô, tuân thủ quy định (như GDPR), chuyển sang serverless, tăng logging/monitoring, và áp dụng best practices GCP. Câu hỏi tập trung vào việc collect logs hoặc dữ liệu ứng dụng từ VMs để debug failures, không phải performance bottlenecks hay backup.

🛠️ Yêu cầu chính: Chọn giải pháp tối ưu nhất để thu thập dữ liệu chi tiết về lỗi ứng dụng trên Compute Engine VMs, phù hợp với Technical Requirements (tăng logging, lưu vào cloud analytics).

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

Đáp án đúng: Install the Cloud Logging agent on the virtual machines.

Lý do (🧩 Phân tích sâu):

• APIs chạy trên Compute Engine VMs, gặp application failures (lỗi ứng dụng như crash, exception). Để troubleshoot, cần logs chi tiết từ ứng dụng (application logs, error messages, stack traces).
• Cloud Logging agent (nay là phần của Ops Agent từ 2022, cập nhật đến 2026) được thiết kế để thu thập logs từ VMs (syslog, application logs), gửi về Cloud Logging để query, filter, và phân tích realtime.
• Phù hợp Technical Requirements: "Logging must be increased, and data should be stored in a cloud analytics platform." Giúp debug nhanh, tích hợp với Cloud Monitoring và Cloud Operations Suite.
• Best practice GCP (Google-recommended): Dễ cài đặt qua Metadata hoặc gcloud, hỗ trợ elastic scaling khi mở rộng regions.

Nguồn tham khảo 📘:

• Google Cloud Logging Agent Documentation (cập nhật 2025: Khuyến nghị Ops Agent logging).
• Troubleshoot Compute Engine with Logging.
• GCP Professional Cloud Developer Exam Guide (2024-2026).

❌ Phân tí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 một cách chi tiết, giữ nguyên nội dung tiếng Anh gốc. Mỗi phương án được đánh giá dựa trên mục tiêu troubleshoot application failures (không phải backup, metrics, hay performance).

• ❌ Take frequent snapshots of the virtual machines.
  Sai vì: Snapshots chỉ dùng để backup disk images của VMs (Persistent Disk), giúp restore trạng thái máy ảo, không thu thập application information realtime. Không có logs hay error details để troubleshoot failures. Tốn storage, không scalable cho debugging thường xuyên. (Không khớp Business/Technical Requirements về logging/analytics).

• ✅ Install the Cloud Logging agent on the virtual machines.
  Đúng vì: Như giải thích ở trên – chính xác thu thập logs ứng dụng từ VMs, gửi về Cloud Logging để search/filter errors. Hỗ trợ structured logging, alerting, và integration với BigQuery cho analytics. Giải pháp trực tiếp, hiệu quả nhất cho occasional failures.

• ❌ Install the Cloud Monitoring agent on the virtual machines.
  Sai vì: Cloud Monitoring agent (phần Ops Agent) tập trung vào metrics/uptime (CPU, memory, network), không phải application logs. Chỉ báo hiệu failures (như alert hiện tại), nhưng không cung cấp chi tiết lỗi ứng dụng để troubleshoot sâu (ví dụ: không có stack traces hay custom app logs).

• ❌ Use Cloud Trace to look for performance bottlenecks.
  Sai vì: Cloud Trace dùng để trace latency/performance (distributed tracing cho RPCs, bottlenecks), không phải collect application information chung cho failures (như crashes không liên quan performance). Phù hợp nếu vấn đề là slow APIs, nhưng câu hỏi nhấn application failures (có thể là logic errors, không phải bottlenecks).

🛠️ Tóm tắt so sánh: | Phương án | Phù hợp troubleshoot app failures? | Loại dữ liệu chính | |-----------|------------------------------------|---------------------| | Logging agent | ✅ (Logs chi tiết) | Application logs, errors | | Các sai khác | ❌ | Backup/metrics/trace |

Lời khuyên thi cử 🎯: Trong GCP exams (như Professional Cloud Developer), ưu tiên Cloud Logging cho debugging apps trên Compute Engine. Nếu chuyển serverless (như yêu cầu case), dùng Cloud Run/Functions logging tự động.

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

Câu hỏi thuộc phần case study của kỳ thi chứng chỉ Google Cloud (cụ thể là liên quan đến Professional Cloud Architect hoặc Developer), mô tả tình huống thực tế của công ty HipLocal – một ứng dụng cộng đồng hyper-local đang mở rộng toàn cầu. Họ đang sử dụng môi trường lai (hybrid): phần lớn hạ tầng trên Google Cloud Platform (GCP) (như Compute Engine VMs cho API, MySQL database, Persistent Disks), và phần on-premises (Hadoop cho analytics, Teradata/Vertica warehouse).

HipLocal đã kết nối hạ tầng Hadoop on-premises với GCP qua Cloud Interconnect (một dịch vụ kết nối dedicated cao tốc, low-latency giữa on-prem và GCP VPC) để query dữ liệu lưu trữ trên Persistent Disks (PDs – các đĩa lưu trữ block trong GCP).

Vấn đề cốt lõi: Cần chọn chiến lược IP (IP strategy) phù hợp cho VPC trong GCP để đảm bảo kết nối hybrid mượt mà, tránh xung đột địa chỉ IP giữa mạng on-prem (Hadoop) và GCP, đồng thời hỗ trợ scaling toàn cầu, tuân thủ Google-recommended practices (như serverless, monitoring, security).

Câu hỏi tập trung vào chế độ subnet trong VPC (VPC subnet modes), vì Cloud Interconnect yêu cầu quản lý IP ranges chính xác để route traffic giữa on-prem và cloud mà không overlap CIDR blocks. Đây là best practice cho môi trường hybrid connectivity. (Lưu ý: Chủ đề chính là GCP, không phải AWS như đề cập ban đầu – có thể là nhầm lẫn).

✅ Đáp án đúng: Create manual subnets

Lý do lựa chọn:
Trong GCP VPC (tính đến phiên bản mới nhất 2026, không thay đổi lớn từ docs 2024-2025), khi sử dụng Cloud Interconnect cho hybrid cloud (on-prem Hadoop query PDs trên GCP), manual subnets (hay custom mode subnets) là chiến lược IP được khuyến nghị mạnh mẽ. Lý do:

• Cho phép tùy chỉnh CIDR blocks thủ công cho từng subnet/region, tránh overlap IP với mạng on-prem (rất phổ biến trong legacy Hadoop setups).
• Hỗ trợ private connectivity an toàn, routing chính xác VLAN attachments qua Interconnect.
• Phù hợp với technical requirements: scaling elastic, reduce infra management, Google best practices cho global expansion (multi-region subnets).
• Auto mode không linh hoạt, dễ gây conflict IP khi migrate/hybrid.
  ✅ Kết quả: Đảm bảo Hadoop on-prem truy cập PDs mà không cần public IPs hay NAT phức tạp, uptime cao, metrics rõ ràng.

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

• ✅ Create manual subnets:
  Phương án đúng như đã phân tích. Manual (custom mode) subnets cho phép architect kiểm soát primary/secondary IP ranges, thiết kế non-overlapping CIDR (ví dụ: on-prem dùng 10.0.0.0/8, GCP dùng 192.168.0.0/16). Hỗ trợ Cloud Interconnect VLAN attachments trực tiếp đến VPC, query PDs hiệu quả. Tuân thủ GCP best practices cho hybrid (docs: Hybrid Connectivity).

• ❌ Create an auto mode subnet:
  Phương án sai. Auto mode tự động tạo subnets ở tất cả regions với CIDR /20 fixed (ví dụ: us-central1: 10.128.0.0/20). Không tùy chỉnh được, dễ overlap IP với on-prem Hadoop (legacy networks thường dùng private RFC 1918 ranges). Không phù hợp hybrid Interconnect, vi phạm requirement "reduce infrastructure management" vì khó predict/control. (GCP chỉ recommend auto cho workloads đơn giản, non-hybrid).

• ❌ Create multiple peered VPCs:
  Phương án sai. VPC Peering dùng cho kết nối GCP-to-GCP (shared VPC hoặc cross-project), không trực tiếp hỗ trợ on-prem Interconnect. Tạo multiple peered VPCs sẽ phức tạp hóa routing (cần Transit Gateway-like, nhưng GCP dùng Shared VPC thay thế), tăng cost/latency, không giải quyết IP strategy cho Persistent Disks query từ Hadoop. Không cần thiết cho single hybrid connection.

• ❌ Provision a single instance for NAT:
  Phương án sai. NAT Instance (Cloud NAT hoặc self-managed VM) dùng cho outbound internet access từ private subnets, không phải IP strategy cho Interconnect. Interconnect là private peering (Layer 2/3), không cần NAT để query PDs nội bộ GCP. Sử dụng single instance sẽ tạo single point of failure, tăng management overhead, trái với serverless/elastic scaling requirements.

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

• GCP VPC Subnets Docs: cloud.google.com/vpc/docs/subnets#subnet-modes – Giải thích custom vs auto mode, recommend custom cho production/hybrid.
• Cloud Interconnect Best Practices: cloud.google.com/network-connectivity/docs/interconnect/how-to/plan-ip-addressing – Nhấn mạnh custom subnets để avoid overlap.
• Hybrid Connectivity Guide: cloud.google.com/architecture/best-practices-vpc-design#custom-mode – Google-recommended cho workloads như HipLocal.
• Exam Prep (A Cloud Guru/Whizlabs): Case studies tương tự trong Professional Cloud Architect exam.

Hy vọng phân tích giúp bạn nắm vững! 🚀 Nếu cần thêm chi tiết, hỏi nhé!

🧩 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 thuộc case study về công ty HipLocal – một ứng dụng cộng đồng hyper-local đang mở rộng toàn cầu trên Google Cloud Platform (GCP). Họ có môi trường hiện tại kết hợp on-premises và GCP (API trên Compute Engine, MySQL single instance, export dữ liệu ra on-premises, không logging đầy đủ). Yêu cầu kinh doanh bao gồm mở rộng vùng địa lý, tăng user concurrent, trải nghiệm nhất quán, metrics hoạt động, tuân thủ quy định (như GDPR), giảm quản lý infra. Yêu cầu kỹ thuật nổi bật: Cung cấp metrics/monitoring, auth mạnh cho API, tăng logging vào cloud analytics, chuyển serverless để scale elastic, và "Provide authorized access to internal apps in a secure manner" (Cung cấp truy cập được ủy quyền an toàn vào các ứng dụng nội bộ).

Câu hỏi cụ thể: "Which service should HipLocal use to enable access to internal apps?" (Dịch: HipLocal nên sử dụng dịch vụ nào để kích hoạt truy cập vào các ứng dụng nội bộ?). Đây là yêu cầu về bảo mật truy cập an toàn, không cần VPN, phù hợp với best practices GCP cho zero-trust access đến apps nội bộ như Compute Engine hoặc App Engine.

✅ Đáp án đúng: Cloud Identity-Aware Proxy
Lý do lựa chọn: Cloud Identity-Aware Proxy (IAP) là dịch vụ GCP lý tưởng để cung cấp truy cập an toàn, dựa trên identity (Google Cloud Identity hoặc Google Workspace) cho các ứng dụng nội bộ mà không cần mở port SSH/RDP hoặc VPN toàn cục. IAP kiểm tra user identity trước khi proxy traffic đến backend (như Compute Engine VMs chứa API của HipLocal), hỗ trợ OAuth 2.0, Context-Aware Access (dựa trên device, location, thời gian), tích hợp logging/monitoring qua Cloud Audit Logs và Cloud Monitoring. Điều này giúp HipLocal giảm quản lý infra, tuân thủ GDPR (fine-grained access), và scale global mà không expose apps trực tiếp. Phù hợp hoàn hảo với yêu cầu "authorized access to internal apps in a secure manner" và Google-recommended practices (zero-trust model). Cập nhật đến 2026: IAP hỗ trợ IAP TCP forwarding cho non-HTTP apps và tích hợp VPC Service Controls (docs GCP 2024+).

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

• GCP IAP Overview
• IAP for Secure App Access
• GCP Security Best Practices (cập nhật 2025).

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

• ❌ Cloud VPN
  Sai vì Cloud VPN (nay là Cloud VPN with HA) dùng để kết nối mạng an toàn giữa on-premises và GCP VPC qua IPsec tunnels, phù hợp cho hybrid connectivity (như export data của HipLocal ra Teradata on-prem). Không dành cho truy cập granular đến internal apps; nó expose toàn bộ subnet, tăng rủi ro và không hỗ trợ identity-based access (không zero-trust).

• ❌ Cloud Armor
  Sai vì Cloud Armor là Web Application Firewall (WAF) và DDoS protection cho Load Balancers (HTTP(S)/TCP/UDP), bảo vệ apps public-facing khỏi attacks (L3/L4/L7). Không liên quan đến truy cập nội bộ; HipLocal cần access control cho internal apps, không phải defense cho public traffic.

• ❌ Virtual Private Cloud
  Sai vì VPC là mạng ảo cơ bản trong GCP để isolate resources (subnets, firewalls, routes), đã có sẵn trong môi trường HipLocal (Compute Engine). VPC không cung cấp authentication/authorization cho apps; chỉ là nền tảng mạng, không giải quyết "authorized access" mà cần layer bảo mật cao hơn như IAP.

• ✅ Cloud Identity-Aware Proxy
  Đúng như giải thích trên: Cung cấp proxy-based access control dựa trên user identity, không cần VPN/client, tích hợp IAM policies, phù hợp serverless/scale global cho HipLocal. Giảm cost quản lý, hỗ trợ metrics qua Cloud Logging/Monitoring.

💡 Lưu ý cuối: Câu hỏi nhấn mạnh chuyển sang serverless và best practices GCP, IAP là lựa chọn tối ưu giúp HipLocal mở rộng nhanh mà an toàn (không vi phạm chính sách core).

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

Câu hỏi thuộc dạng case study trong kỳ thi chứng chỉ Google Cloud (cụ thể là liên quan đến Professional Cloud Developer hoặc tương tự), mô tả tình huống thực tế của công ty HipLocal – một ứng dụng cộng đồng hyper-local đang mở rộng toàn cầu. Họ đang chạy môi trường hỗn hợp on-premises và Google Cloud Platform (GCP), với:

• API trên Compute Engine VM.
• Database MySQL single instance.
• Data warehouse on-premises (Teradata/Vertica), analytics trên Hadoop on-premises.
• Không có logging đầy đủ, chỉ có basic uptime indicators, thường alert khi API unresponsive.

Yêu cầu kinh doanh (Business Requirements): Mở rộng vùng, tăng concurrent users, trải nghiệm nhất quán, metrics user activity, tuân thủ quy định (GDPR), giảm quản lý infra, áp dụng best practices GCP.
Yêu cầu kỹ thuật (Technical Requirements):

• Cung cấp metrics/monitoring.
• AuthZ mạnh cho API.
• Tăng logging, lưu vào cloud analytics.
• Chuyển sang serverless architecture để elastic scaling.
• Authorized access secure cho internal apps.
• Giảm on-call engineers, loại bỏ manual scaling.

Câu hỏi cụ thể: "Which two services should they choose? (Choose two.)" – Nghĩa là chọn hai dịch vụ phù hợp nhất để đáp ứng nhu cầu serverless + automated deployments + giảm manual scaling, dựa trên existing environment (VMs trên GCP) và mục tiêu scale global.
📘 Nguồn tham khảo: Google Cloud Case Studies (HipLocal từ kỳ thi cũ), docs chính thức GCP: Serverless on GCP, Knative docs, GKE Autoscaling (cập nhật 2024-2026, hỗ trợ Knative 1.12+ với GKE 1.28+).

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

Hai đáp án đúng là:

• Use Knative to build and deploy serverless applications.
• Use Google Kubernetes Engine for automated deployments.

Lý do chọn:

• HipLocal cần serverless architecture để elastic scaling tự động, giảm manual scaling và on-call engineers. Knative (chạy trên GKE) là nền tảng serverless Kubernetes-native, hỗ trợ build/deploy apps containerized một cách tự động scale-to-zero, phù hợp migrate từ Compute Engine VMs.
• GKE cung cấp automated deployments qua Autopilot mode (từ 2021, cập nhật 2026 với AI autoscaling), tích hợp Knative để serverless, đảm bảo high availability global, metrics/monitoring via Cloud Operations, và giảm quản lý infra (Google-managed).
• Combo này tuân thủ Google-recommended practices cho cloud-native apps, hỗ trợ multi-region, authZ (Istio/IAP), logging (Cloud Logging), analytics (BigQuery). Không cần VM lớn/manual cluster.
  🛠️ Ưu điểm nổi bật: Scale theo traffic real-time, cost-effective (pay-per-use), dễ train team mới với K8s skills.

📋 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 mộ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 Technical Requirements (serverless, automated scaling, giảm manual mgmt).

• Use Google App Engine services.
  ❌ Sai: App Engine là serverless (standard/flex), hỗ trợ auto-scale tốt, nhưng không phù hợp vì HipLocal có existing APIs trên Compute Engine (containerized dễ migrate sang Knative/GKE hơn). App Engine yêu cầu refactor code lớn (Python/Node/etc.), không hỗ trợ "automated deployments" Kubernetes-style, và kém linh hoạt cho global custom authZ/compliance so với K8s-native. Không giảm on-call triệt để nếu cần custom infra.

• Use serverless Google Cloud Functions.
  ❌ Sai: Cloud Functions là serverless event-driven (2nd gen 2024+ hỗ trợ VPC/scale), nhưng chỉ cho functions nhỏ (không phải full APIs/app như HipLocal). Không hỗ trợ stateful workloads, migrate từ VM khó, thiếu "automated deployments" container-based, và không scale concurrent users lớn như K8s. Phù hợp micro-tasks, không phải toàn bộ backend.

• Use Knative to build and deploy serverless applications.
  ✅ Đúng: Knative (open-source, tích hợp GKE) cho phép build/deploy serverless apps trên K8s, auto-scale-to-zero, serving/knative-eventing lý tưởng cho APIs. Giảm manual scaling 100%, metrics via Prometheus, logging Cloud Logging. Phù hợp Google-recommended cho migrate VM-to-serverless (2026: hỗ trợ WebAssembly). Hoàn hảo cho elastic global scale.

• Use Google Kubernetes Engine for automated deployments.
  ✅ Đúng: GKE (Autopilot/Standard) hỗ trợ automated deployments qua Horizontal Pod Autoscaler, Cluster Autoscaler, và integration Knative cho serverless. Google-managed nodes giảm on-call, multi-region federation, Istio service mesh cho authZ. Cập nhật 2026: AI-optimized scaling (GKE Enterprise). Lý tưởng cho team có kinh nghiệm VM, scale 10k+ users.

• Use a large Google Compute Engine cluster for deployments.
  ❌ Sai: Compute Engine (VM cluster lớn) là scale-up manual (MIGs giúp nhưng vẫn cần on-call tuning), trái ngược serverless requirement. Không elastic real-time, chi phí cao idle time, không giảm infra mgmt (patch/update manual). Existing env đã dùng VM nhưng cần migrate away để best practices.

🧩 Tóm tắt insight: Lựa chọn Knative + GKE là cloud-native serverless tối ưu, giúp HipLocal scale global mà không refactor lớn, tuân thủ tất cả reqs. Tránh các option cũ/manual như VM/App Engine/Functions.
📘 Tài liệu thêm: GCP Serverless Migration Guide (tương tự cho Knative), Knative on GKE Quickstart.

🧩 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 thuộc phần case study về công ty HipLocal – một ứng dụng cộng đồng hyper-local dùng để giao tiếp, lập kế hoạch sự kiện và kết nối doanh nghiệp với cộng đồng địa phương. HipLocal đang mở rộng toàn cầu từ Dallas, với yêu cầu kinh doanh chính:

• Mở rộng ứng dụng đến các vùng mới (expand availability to new regions).
• Tăng số lượng người dùng đồng thời (increase concurrent users).
• Đảm bảo trải nghiệm nhất quán khi người dùng di chuyển giữa các vùng (consistent experience across regions).
• Thu thập metrics hoạt động người dùng để kiếm tiền hóa sản phẩm.
• Tuân thủ quy định mới (như GDPR).
• Giảm thời gian và chi phí quản lý hạ tầng.
• Áp dụng best practices của Google Cloud.

Môi trường hiện tại: APIs trên Compute Engine VM, state lưu trên single instance MySQL trong GCP (không scale toàn cầu), dữ liệu export ra on-premises, thiếu logging/monitoring.

🛠️ Yêu cầu kỹ thuật liên quan đến state storage:

• Chuyển sang serverless architecture để scale elastic.
• Cung cấp metrics/monitoring cho app và backend.
• APIs cần auth mạnh mẽ.
• Tăng logging và lưu vào cloud analytics.

Câu hỏi cụ thể: "In order to meet their business requirements, how should HipLocal store their application state?" – Nghĩa là, để đáp ứng yêu cầu kinh doanh, HipLocal nên lưu trữ application state (trạng thái ứng dụng, như dữ liệu phiên người dùng, session, dữ liệu động cần consistency cao) như thế nào?

State hiện tại trên single MySQL không hỗ trợ scale global, multi-region, elastic scaling. Cần giải pháp globally distributed, strongly consistent, horizontally scalable để hỗ trợ tăng users, consistency across regions, và serverless.

✅ Đáp án đúng: Move the state storage to Cloud Spanner

Lý do lựa chọn:
Cloud Spanner là cơ sở dữ liệu quan hệ phân tán toàn cầu (globally distributed relational database) của Google Cloud, hỗ trợ strong consistency (ACID transactions), horizontal scaling tự động lên hàng nghìn nodes, và multi-region replication với low latency. Nó hoàn hảo cho HipLocal vì:

• Scale elastic & concurrent users cao: Tự động scale theo nhu cầu, hỗ trợ hàng triệu requests/giây mà không cần quản lý server (serverless-like).
• Consistent experience across regions: TrueTime công nghệ đảm bảo consistency toàn cầu, ngay cả khi users di chuyển giữa regions (ví dụ: Dallas sang Europe).
• Giảm quản lý hạ tầng: Managed service, tích hợp monitoring/metrics (Cloud Monitoring), logging (Cloud Logging), và tuân thủ GDPR (data residency controls).
• Best practice GCP: Khuyến nghị cho global apps cần relational data với high availability (99.999% uptime).
  Phiên bản mới nhất (2026): Spanner hỗ trợ c2/h3 machines cho performance cao hơn, integration với AlloyDB cho hybrid workloads, và generative AI features cho analytics.

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

• ❌ Use local SSDs to store state.
  Sai vì local SSD chỉ là temporary storage gắn với VM (như Compute Engine), dữ liệu mất khi VM restart/shutdown. Không phù hợp cho application state cần persistence, durability, và global replication. Sẽ vi phạm yêu cầu scale regions và consistency, tăng rủi ro downtime – trái với business reqs giảm quản lý và high availability.

• ❌ Put a memcache layer in front of MySQL.
  Sai vì Memcached chỉ là caching layer (in-memory, non-persistent), không thay thế storage chính cho state. Vẫn phụ thuộc single MySQL instance (không scale global), chỉ giảm load tạm thời chứ không giải quyết vấn đề core: elastic scaling multi-region và strong consistency. Không phải serverless, vẫn cần quản lý MySQL thủ công.

• ✅ Move the state storage to Cloud Spanner.
  (Như giải thích trên) – Đáp ứng đầy đủ: global scale, consistency, serverless, metrics, compliance.

• ❌ Replace the MySQL instance with Cloud SQL.
  Sai vì Cloud SQL là managed MySQL/PostgreSQL với high availability trong 1 region (primary/replica setup), không hỗ trợ true global distribution như multi-region strong consistency. Scale có giới hạn (vertical + read replicas), không elastic ngang như Spanner cho concurrent users cao toàn cầu. Phù hợp migrate dễ dàng nhưng không meet reqs expand regions/consistency.

📘 Tài liệu tham khảo

• Cloud Spanner Documentation: Google Cloud Spanner Overview – Xác nhận global distribution, strong consistency (cập nhật 2025: Regional/Global configs với interleaving tables).
• GCP Best Practices for Global Apps: Google Cloud Architecture Center - Scaling Relational Databases – Khuyến nghị Spanner cho stateful global workloads.
• HipLocal Case Study (GCP Professional Cloud Developer Exam): Dựa trên sample questions từ Google Cloud Certification Learning Path (phiên bản 2024-2026).

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm case study khác, hãy hỏi nhé!

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

Câu hỏi thuộc phần case study của kỳ thi chứng chỉ Google Cloud (không phải AWS như đề cập ban đầu, mà rõ ràng là về môi trường Google Cloud Platform - GCP của công ty HipLocal). Case study mô tả HipLocal là ứng dụng cộng đồng hyper-local, đang mở rộng toàn cầu từ Dallas. Họ có môi trường hỗn hợp: APIs chạy trên Compute Engine VM trong GCP, database MySQL đơn lẻ, export data sang on-premises warehouse (Teradata/Vertica), analytics trên Hadoop on-premises, thiếu logging và monitoring đầy đủ, chỉ có alert cơ bản về uptime.

Yêu cầu kinh doanh: Mở rộng vùng địa lý, tăng concurrent users, trải nghiệm nhất quán khi di chuyển vùng, metrics hoạt động người dùng, tuân thủ quy định (GDPR), giảm quản lý infra, áp dụng best practices GCP.

Yêu cầu kỹ thuật: Cung cấp metrics/monitoring cho app/backend, APIs cần strong authentication & authorization, tăng logging lưu vào cloud analytics, chuyển sang serverless cho elastic scaling, truy cập nội bộ an toàn.

Câu hỏi cụ thể: "Which service should HipLocal use for their public APIs?" – Nghĩa là HipLocal nên dùng dịch vụ nào cho các public APIs hiện đang chạy trên Compute Engine, để đáp ứng auth mạnh, monitoring, logging, scaling, và các yêu cầu khác trong bối cảnh mở rộng global/serverless.

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

• Google Cloud Endpoints docs (cập nhật 2024-2026): https://cloud.google.com/endpoints/docs
• GCP API Management best practices: https://cloud.google.com/architecture/best-practices-api-management
• HipLocal case study từ Google Cloud certification exams (dựa trên nội dung thi thực tế).

✅ Đáp án đúng: Cloud Endpoints

Lý do lựa chọn: Cloud Endpoints là dịch vụ quản lý API chuyên dụng trên GCP, lý tưởng cho public APIs của HipLocal. Nó cung cấp:

• Strong authentication & authorization (OAuth 2.0, JWT, API keys, service accounts) 🛡️.
• Metrics, monitoring & logging tích hợp với Cloud Monitoring/Logging, lưu vào cloud analytics (BigQuery/Cloud Operations) 📊.
• Hỗ trợ serverless scaling qua Extensible Service Proxy (ESP) trên Cloud Run, App Engine, GKE, hoặc Compute Engine (dễ migrate từ VM hiện tại).
• Analytics người dùng để monetize, quota/throttling cho concurrent users cao, global distribution qua multi-region.
• Tuân thủ GDPR/compliance qua audit logs và access controls. Điều này khớp hoàn hảo với Technical Requirements (APIs auth, metrics, logging, serverless), giúp giảm infra management theo Google-recommended practices. Không cần viết code phức tạp, deploy nhanh cho global expansion.

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

• Cloud Armor ❌
  Sai: Đây là dịch vụ bảo vệ DDoS và Web Application Firewall (WAF) trên GCP, dùng để chống tấn công layer 7 (SQLi, XSS) và adaptive protection cho load balancers/HTTP(S). Không phải cho quản lý public APIs, thiếu auth/monitoring/logging toàn diện. HipLocal cần API management chứ không chỉ security layer ngoài.

• Cloud Functions ❌
  Sai: Đây là nền tảng serverless compute chạy functions theo event (FaaS), phù hợp backend logic ngắn gọn. Không chuyên quản lý public APIs (thiếu built-in auth gateway, OpenAPI spec, analytics chi tiết). HipLocal cần gateway cho APIs hiện có trên VM, không phải rewrite toàn bộ thành functions.

• Cloud Endpoints ✅
  Đúng: Như giải thích trên, là lựa chọn tối ưu cho public APIs với full lifecycle management (design, secure, monitor, scale). Tích hợp ESPv2 cho serverless/global, hỗ trợ gRPC/REST, chính xác đáp ứng mọi yêu cầu kỹ thuật của case study.

• Shielded Virtual Machines ❌
  Sai: Tính năng bảo mật VM trên Compute Engine (secure boot, vTPM, integrity monitoring) để chống rootkit/malware trong VM. Chỉ bảo vệ instance-level, không liên quan quản lý public APIs, auth, monitoring hay scaling. HipLocal đang migrate khỏi VM truyền thống, không cần shielded cho APIs.

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

Câu hỏi thuộc phần case study về công ty HipLocal, một ứng dụng cộng đồng hyper-local đang mở rộng toàn cầu. Họ đang sử dụng môi trường hỗn hợp on-premises và Google Cloud Platform (GCP), với MySQL single instance chạy trên Compute Engine VM. Các yêu cầu kinh doanh bao gồm: mở rộng vùng địa lý, tăng concurrent users, trải nghiệm nhất quán, metrics sử dụng, tuân thủ quy định (như GDPR), giảm quản lý hạ tầng. Yêu cầu kỹ thuật: metrics/monitoring, auth mạnh, logging vào cloud analytics, chuyển sang serverless, truy cập nội bộ an toàn.

🛠️ Vấn đề cụ thể: HipLocal muốn cải thiện độ resilient (khả năng phục hồi) của deployment MySQL hiện tại (single instance dễ fail), đồng thời đáp ứng tất cả yêu cầu trên. Câu hỏi yêu cầu chọn cấu hình tốt nhất để thay thế, tập trung vào Cloud SQL (dịch vụ managed database của GCP cho MySQL).

📘 Bối cảnh kiến thức (cập nhật đến 2026): Theo tài liệu GCP mới nhất (Cloud SQL for MySQL v2+), single instance MySQL trên Compute Engine thiếu HA tự động, dễ downtime. Cloud SQL hỗ trợ High Availability (HA) qua regional HA configuration với primary + standby instance, automatic failover (RPO < 1 phút, RTO ~60 giây), multi-zone replication. Điều này phù hợp serverless scaling, monitoring (Cloud Monitoring), logging (Cloud Logging), và tuân thủ (VPC, encryption).
Nguồn tham khảo:

• Cloud SQL High Availability
• Cloud SQL Best Practices (cập nhật 2025).

✅ Đáp án đúng

Replace the current single instance MySQL instance with Cloud SQL, and configure high availability.

Lý do chọn (chi tiết):

• ✅ Thay thế hoàn toàn single instance bằng Cloud SQL (managed service) giúp giảm quản lý hạ tầng (auto patching, backup, scaling), phù hợp yêu cầu serverless và Google-recommended practices.
• ✅ Configure HA explicitly tạo failover tự động (primary + standby ở khác zone/region), đảm bảo resilience cao (99.99% uptime), nhất quán trải nghiệm đa vùng, metrics qua Cloud Monitoring (usage/activity), logging vào Cloud Logging/BigQuery.
• ✅ Đáp ứng tất cả yêu cầu: Scaling elastic, auth (IAM/Cloud SQL Auth Proxy), compliance (private IP, encryption at rest/transit), hỗ trợ global (cross-region replicas). Không giữ legacy single instance, tránh rủi ro downtime.
• 🏆 Đây là giải pháp tối ưu nhất cho global scale theo best practices GCP 2026.

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

• Use the current single instance MySQL on Compute Engine and several read-only MySQL servers on Compute Engine.
  ❌ Sai: Giữ single master trên Compute Engine (self-managed) chỉ thêm read replicas → không resilient nếu master fail (manual failover phức tạp, downtime cao). Không managed, tốn công quản lý patching/backup/scaling, vi phạm yêu cầu serverless, monitoring/logging đầy đủ, và giảm chi phí. Không scale global mượt mà.

• Use the current single instance MySQL on Compute Engine, and replicate the data to Cloud SQL in an external master configuration.
  ❌ Sai: External master nghĩa là Compute Engine VM làm master, Cloud SQL chỉ replica (read-only) → master vẫn vulnerable (single point failure). Replication lag có thể gây inconsistent data đa vùng. Không thay thế hoàn toàn, vẫn tốn quản lý VM, không HA tự động cho write traffic, không đáp ứng serverless/resilience đầy đủ.

• Replace the current single instance MySQL instance with Cloud SQL, and configure high availability.
  ✅ Đúng (như giải thích ở trên): Toàn diện, resilient, managed, scale global.

• Replace the current single instance MySQL instance with Cloud SQL, and Google provides redundancy without further configuration.
  ❌ Sai: Cloud SQL không tự động HA – phải explicitly enable HA configuration khi tạo instance (chọn regional, v.v.). Default là single zone (không redundant). Sai lầm này dẫn đến downtime nếu zone fail, không đáp ứng resilience yêu cầu. GCP docs nhấn mạnh cần config thủ công cho HA.