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

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

Câu hỏi này thuộc chủ đề Managed Instance Groups (MIGs) trong Google Cloud Compute Engine, liên quan đến cơ chế autoscaling dựa trên CPU utilization.

• 📝 Tình huống: Ứng dụng chạy trên nhiều VM trong một MIG có autoscaling bật. Chính sách autoscaling thêm instance mới khi CPU của các instance hiện tại vượt 80%, và tiếp tục thêm đến khi đạt tối đa 5 VMs hoặc CPU giảm xuống 80%.
• ⚠️ Vấn đề quan sát: Các VM mất khoảng 3 phút (180 giây) để sẵn sàng phục vụ người dùng (warmup time). Tuy nhiên, initial delay cho HTTP health check chỉ là 30 giây. Kết quả: Khi autoscaling kích hoạt, MIG thêm quá nhiều instance so với lượng traffic thực tế cần thiết, dẫn đến lãng phí tài nguyên.
• 🎯 Mục tiêu: Điều chỉnh để MIG duy trì kích thước hợp lý, tránh overscaling (scale up thừa).

Nguyên nhân gốc rễ 🛠️: Health check HTTP bắt đầu sau 30 giây, nhưng VM chưa ready (chỉ ready sau 180 giây), nên health check fail → MIG coi instance mới là "unhealthy" → Tiếp tục scale up thêm instance để bù đắp → Overscaling xảy ra. Giải pháp cần tăng thời gian initial delay để health check chờ VM warmup đầy đủ.

(Lưu ý: Đây là kiến thức GCP Compute Engine phiên bản mới nhất 2024-2026, không thay đổi lớn từ tài liệu chính thức. Không phải AWS, dù người dùng đề cập – có thể nhầm lẫn với Auto Scaling Groups của AWS EC2.)

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

Đáp án đúng: Increase the initial delay of the HTTP health check to 200 seconds.

Lý do chi tiết 📘:

• VM cần 3 phút (180 giây) để ready, nhưng initial delay chỉ 30 giây → Health check fail sớm, MIG scale up thừa.
• Tăng lên 200 giây (lớn hơn 180 giây) cho phép VM warmup hoàn tất trước khi health check bắt đầu → Instance nhanh chóng "healthy" → Autoscaling dừng đúng lúc, tránh thêm instance không cần thiết.
• Đây là best practice từ GCP: Initial delay nên >= warmup time để health check chính xác (xem docs GCP).

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

• [SAI] Set the maximum number of instances to 1.
  ❌ Sai vì: Giới hạn max chỉ 1 VM sẽ ngăn scale up hoàn toàn, không xử lý được traffic tăng đột biến → Ứng dụng có thể crash hoặc chậm. Không giải quyết vấn đề overscaling mà chỉ "cắt cụt" scale up.

• [SAI] Decrease the maximum number of instances to 3.
  ❌ Sai vì: Giảm max xuống 3 VMs vẫn giữ nguyên vấn đề health check fail → Vẫn overscale trong giới hạn nhỏ hơn, nhưng không loại bỏ nguyên nhân gốc (VM chưa ready). Chỉ là "vá víu" tạm thời, không hiệu quả lâu dài.

• [SAI] Use a TCP health check instead of an HTTP health check.
  ❌ Sai vì: TCP health check chỉ kiểm tra port mở (nhanh hơn, ~10-30s), không kiểm tra ứng dụng HTTP thực tế ready. Vẫn không chờ đủ 3 phút warmup → Health check pass giả tạo sớm, MIG vẫn scale up thừa hoặc không chính xác. HTTP check phù hợp hơn cho app web, vấn đề là delay chứ không phải loại check.

• [ĐÚNG] Increase the initial delay of the HTTP health check to 200 seconds.
  ✅ Đúng vì: Như giải thích trên, 200 giây > warmup time (180s) → Health check bắt đầu muộn, instance ready trước → MIG nhận diện đúng tình trạng healthy, autoscaling chính xác, duy trì size tối ưu. Hoàn hảo khớp vấn đề!

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

• Autoscaling MIGs 🛠️ (phần CPU-based scaling & health checks).
• Health checks for MIGs 📘 (chi tiết initial delay & warmup).
• Best practices troubleshooting autoscaling.

Hy vọng phân tích này giúp bạn ôn thi Associate Cloud Engineer hiệu quả! 🚀 Nếu cần thêm ví dụ thực hành, hỏi nhé!

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

Câu hỏi yêu cầu chọn và cấu hình tài nguyên tính toán (compute resources) cho một tập hợp các công việc xử lý hàng loạt (batch processing jobs). Các công việc này mất khoảng 2 giờ để hoàn thành và chạy hàng đêm (nightly). Mục tiêu chính là tối thiểu hóa chi phí dịch vụ (minimize service costs).

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

• Đây là workload không liên tục, có thể chấp nhận gián đoạn (interruptible) vì chỉ chạy 2 giờ/đêm và không yêu cầu tính sẵn sàng cao (high availability).
• Trong Google Cloud Platform (GCP), cần chọn dịch vụ compute phù hợp như Compute Engine (VMs) hoặc Google Kubernetes Engine (GKE), ưu tiên chi phí thấp nhất.
• Kiến thức cập nhật đến 2026: Preemptible VMs đã được thay thế bằng Spot VMs từ năm 2022 (rẻ hơn đến 91% so với on-demand VMs), phù hợp cho batch jobs ngắn hạn. (Nguồn: GCP Compute Engine Spot VMs documentation).

✅ Đáp án đúng

Select Compute Engine. Use preemptible VM instances of the appropriate standard machine type.

Lý do lựa chọn:

• 🛡️ Preemptible VMs (nay là Spot VMs) được thiết kế dành riêng cho workload gián đoạn, rẻ hơn 60-91% so với VM on-demand tiêu chuẩn. Chúng có thời hạn tối đa 24 giờ (phù hợp với 2 giờ job), và chạy nightly nên dễ dàng restart nếu bị preempt (GCP thông báo trước 30 giây).
• 📉 Tối ưu chi phí: Không tốn phí cluster liên tục như GKE, chỉ trả tiền theo giờ sử dụng thực tế.
• 🧩 Phù hợp machine type: Chọn loại máy chuẩn (standard machine type) đủ mạnh cho job, không cần đặc biệt.
• Nguồn: GCP Spot VMs best practices – Khuyến nghị cho batch processing nightly.

📋 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. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với emoji nổi bật đúng/sai:

• ❌ [SAI] Select Google Kubernetes Engine. Use a single-node cluster with a small instance type.
  Giải thích: GKE yêu cầu cluster luôn chạy (control plane chi phí ~0.1 USD/giờ), không tắt được hoàn toàn, dẫn đến chi phí cao cho job chỉ 2 giờ/đêm. Single-node thiếu HA (high availability), dễ fail; small instance type có thể không đủ tài nguyên cho batch job nặng. Không tối ưu chi phí so với Spot VMs. (Nguồn: GKE pricing).

• ❌ [SAI] Select Google Kubernetes Engine. Use a three-node cluster with micro instance types.
  Giải thích: Three-node cluster tăng HA nhưng chi phí cao hơn (3 nodes + control plane chạy 24/7), micro instance (như e2-micro) quá yếu (1 vCPU, 1GB RAM), không xử lý batch job hiệu quả trong 2 giờ. Tổng chi phí cluster nightly vẫn đắt đỏ, không minimize costs. (Nguồn: GKE cluster sizing).

• ✅ [ĐÚNG] Select Compute Engine. Use preemptible VM instances of the appropriate standard machine type.
  Giải thích: Như đã nêu ở phần đáp án đúng – rẻ nhất, linh hoạt, phù hợp workload interruptible. Spot VMs (tiếp nối preemptible) là lựa chọn chuẩn cho batch nightly đến 2026.

• ❌ [SAI] Select Compute Engine. Use VM instance types that support micro bursting.
  Giải thích: GCP Compute Engine có burstable machine types (như e2-small với sustained use), nhưng "micro bursting" không phải thuật ngữ chuẩn (gần với AWS t3 burstable). Chúng không rẻ bằng Spot VMs (chỉ giảm ~20-30% nếu sustained), và không đảm bảo chi phí thấp nhất cho job ngắn 2 giờ nightly. Không phải lựa chọn tối ưu. (Nguồn: GCP machine types).

🏆 Kết luận & Lời khuyên

Sử dụng Spot VMs trên Compute Engine là cách tiết kiệm nhất (tiết kiệm đến 91%) cho batch jobs nightly. Hãy implement với checkpointing để restart nếu bị preempt. Tham khảo exam guide Associate Cloud Engineer 2024+ để luyện thêm! 📘

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

Câu hỏi mô tả tình huống: Bạn vừa triển khai một phiên bản mới của ứng dụng lên App Engine (dịch vụ PaaS của Google Cloud Platform - GCP) và phát hiện lỗi (bug) trong phiên bản đó. Bạn cần ngay lập tức quay về phiên bản trước đó (revert). Bạn nên làm gì?

• Ngữ cảnh chính: App Engine quản lý các phiên bản (versions) của ứng dụng độc lập. Khi deploy version mới (ví dụ: version v2), version cũ (v1) vẫn tồn tại và có thể được sử dụng để route traffic. Không có cơ chế "rollback tự động" một nút bấm, mà tập trung vào việc điều hướng traffic linh hoạt để revert nhanh chóng mà không downtime.
• Mục tiêu: Revert ngay lập tức (immediately), ưu tiên không gián đoạn dịch vụ, tận dụng tính năng Versions và Traffic Splitting của App Engine.
• Kiến thức cập nhật (2026): Theo tài liệu GCP mới nhất (App Engine Standard/ Flexible environment, cập nhật 2025-2026), cách revert chuẩn vẫn là route traffic về version trước qua Console hoặc gcloud CLI, không thay đổi cơ bản từ các phiên bản trước. 📘 Nguồn tham khảo: Cloud App Engine Documentation - Managing Versions & Routing Traffic và gcloud app versions.

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

Đáp án đúng: On the App Engine Versions page of the GCP Console, route 100% of the traffic to the previous version.

Lý do 🛠️:

• Đây là cách chuẩn và nhanh nhất để revert trên App Engine. Version cũ vẫn tồn tại sau khi deploy mới, bạn chỉ cần vào Versions page trong GCP Console, chọn version cũ và route 100% traffic về nó. Thay đổi traffic áp dụng gần như ngay lập tức (thường <60 giây), không cần deploy lại code, tránh downtime.
• Phù hợp với best practice GCP: Sử dụng Traffic Splitting để test/migrate/revert an toàn. Không xóa version mới, giữ lại để fix bug sau.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do cụ thể bằng tiếng Việt:

• ❌ [SAI] Run gcloud app restore.
  Lý do sai: Lệnh gcloud app restore không tồn tại trong GCP CLI (kể cả phiên bản 2026). App Engine không hỗ trợ "restore" trực tiếp như vậy. Thay vào đó, dùng gcloud app versions migrate hoặc gcloud app services set-traffic để route traffic. Chạy lệnh này sẽ báo lỗi "command not found". 🛑

• ❌ [SAI] On the App Engine page of the GCP Console, select the application that needs to be reverted and click Revert.
  Lý do sai: Không có nút "Revert" trên trang App Engine chính (Overview/Services page) trong GCP Console. Tính năng revert nằm ở Versions page (dưới Services > Versions), và chỉ là route traffic chứ không phải nút "Revert" đơn giản. Đây là nhầm lẫn với các dịch vụ khác như Cloud Functions hoặc Kubernetes. ❌

• ✅ [ĐÚNG] On the App Engine Versions page of the GCP Console, route 100% of the traffic to the previous version.
  Lý do đúng: Như đã giải thích ở phần đáp án. Đây là quy trình chuẩn: Vào App Engine > Services > [Service] > Versions, chọn version cũ > Split traffic > Set 100% cho version đó. Áp dụng ngay, an toàn, không deploy lại. Hoàn hảo cho "immediately revert". 🎯 Nguồn: Console Guide.

• ❌ [SAI] Deploy the original version as a separate application. Then go to App Engine settings and split traffic between applications so that the original version serves 100% of the requests.
  Lý do sai: Không cần và không hiệu quả. App Engine không split traffic giữa các ứng dụng riêng biệt (applications), mà chỉ giữa versions trong cùng service/app. Deploy làm app mới sẽ tạo project/app khác, phức tạp hóa (cần DNS/migration), tốn thời gian và chi phí, không "immediately". Sai hoàn toàn với mô hình App Engine (multi-version single app). 🚫

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

Câu hỏi mô tả tình huống: Bạn đã triển khai (deploy) một ứng dụng App Engine trên Google Cloud bằng lệnh gcloud app deploy, nhưng ứng dụng không được deploy vào project mà bạn dự định. Vấn đề có thể xuất phát từ cấu hình mặc định của công cụ gcloud CLI (Google Cloud SDK), vì lệnh này sẽ sử dụng project hiện tại trong config nếu không chỉ định rõ --project flag.
📌 Mục tiêu: Tìm nguyên nhân (thường là config project sai) và xác định vị trí deploy thực tế (kiểm tra project nào đang active).
🛠️ Lưu ý kỹ thuật: Trong Google Cloud (cập nhật đến 2026), gcloud app deploy ưu tiên config toàn cục hoặc session hiện tại. Nếu deploy thành công ở project khác, bạn cần kiểm tra config để debug.
📘 Tài liệu tham khảo:

• gcloud config list (Google Cloud SDK docs).
• App Engine deployment troubleshooting (App Engine docs, phiên bản 2026).

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

Đáp án đúng: Go to Cloud Shell and run gcloud config list to review the Google Cloud configuration used for deployment.

Lý do:
Lệnh gcloud config list sẽ hiển thị toàn bộ cấu hình hiện tại của gcloud CLI, bao gồm project đang active (core.project), account, region, và zone. Đây là cách nhanh nhất để xác định project nào được sử dụng khi deploy mà không chỉ định flag --project. Nếu project sai, bạn thấy ngay và có thể switch bằng gcloud config set project <PROJECT_ID>. Điều này phù hợp với best practice debug deployment trên Google Cloud (không phụ thuộc file config app). ✅ Hoàn hảo cho troubleshooting nhanh trong Cloud Shell!

📋 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 giá đúng/sai kèm lý do cụ thể:

• Check the app.yaml file for your application and check project settings.
  ❌ Sai: File app.yaml chỉ định cấu hình App Engine-specific như runtime, handlers, env variables, scaling (không chứa project ID). Nó không ảnh hưởng đến project deploy; project do gcloud config quyết định. Kiểm tra file này vô ích cho vấn đề project sai.

• Check the web-application.xml file for your application and check project settings.
  ❌ Sai: File web-application.xml thuộc Java EE standard (web.xml tương đương), dùng cho web apps Java truyền thống (không phải App Engine chuẩn). App Engine dùng app.yaml hoặc web.xml cho Java apps, nhưng không liên quan project config. Phương án này lạc đề hoàn toàn.

• Go to Deployment Manager and review settings for deployment of applications.
  ❌ Sai: Deployment Manager là dịch vụ IaC (Infrastructure as Code) để deploy templates YAML/JSON cho resources như VM, network (không hỗ trợ App Engine apps trực tiếp). App Engine deploy qua gcloud app deploy hoặc Console, không qua Deployment Manager. Sai ngữ cảnh!

• Go to Cloud Shell and run gcloud config list to review the Google Cloud configuration used for deployment.
  ✅ Đúng: Như đã giải thích ở trên, lệnh này trực tiếp reveal config project/account đang dùng, giúp pinpoint lý do deploy sai project và xác định vị trí thực tế. 🛠️ Best practice từ Google Cloud docs!

🧩 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 cấu hình 10 Compute Engine instances trên Google Cloud Platform (GCP) để đảm bảo tính sẵn sàng cao (high availability - HA), đặc biệt trong các tình huống bảo trì hệ thống (maintenance) và khôi phục tự động nếu crash.

📋 Yêu cầu cụ thể:

• Instances phải tự động khởi động lại (automatically restart) nếu bị crash (ví dụ: lỗi phần mềm hoặc phần cứng).
• Đảm bảo HA toàn diện, bao gồm cả lúc host maintenance (bảo trì máy chủ vật lý), nghĩa là VM không bị gián đoạn lâu, mà nên được di chuyển (migrate) sang host khác.
• Giải pháp phải sử dụng các tính năng của Compute Engine như instance template, instance group (cụ thể là Managed Instance Group - MIG), Automatic Restart, và On-host maintenance để đạt HA.

🛠️ Bối cảnh GCP (cập nhật đến 2026): Trong GCP, MIG là cách tốt nhất để quản lý nhiều instances với HA tự động. Chúng hỗ trợ autohealing, autoscaling, và rolling updates. Settings như "Automatic Restart" (trong instance settings) giúp restart VM nếu stop unexpectedly, còn "On-host maintenance" quyết định hành vi khi host bảo trì: Migrate (ưu tiên cho HA, live migration nếu có thể) hoặc Terminate (dừng VM).

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

• Google Cloud Compute Engine: Stopping and starting instances (Automatic Restart).
• Google Cloud: Host maintenance events (On-host maintenance).
• Google Cloud: Managed instance groups (MIG cho HA).

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

Đáp án đúng: Create an instance template for the instances. Set the 'Automatic Restart' to on. Set the 'On-host maintenance' to Migrate VM instance. Add the instance template to an instance group.

Lý do 🏆:

• ✅ Instance template định nghĩa cấu hình chung cho 10 instances, dễ quản lý và scale.
• ✅ 'Automatic Restart' to on: Đảm bảo VM tự restart nếu crash (stop unexpectedly do lỗi).
• ✅ 'On-host maintenance' to Migrate VM instance: Trong bảo trì host, GCP sẽ live migrate VM sang host lành mạnh, giữ HA mà không downtime (ưu tiên cho production).
• ✅ Add to instance group (MIG): MIG tự động phân bố instances đa zone/region, hỗ trợ autohealing, autoscaling, đảm bảo HA toàn diện.
• Kết hợp hoàn hảo đáp ứng tất cả yêu cầu, theo best practice GCP 2026.

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

• Phương án đúng [A]: Create an instance template for the instances. Set the 'Automatic Restart' to on. Set the 'On-host maintenance' to Migrate VM instance. Add the instance template to an instance group.
  ✅ Đúng hoàn toàn như giải thích ở trên. Đây là cách tối ưu và đầy đủ để đạt HA + auto-restart.

• Phương án sai [B]: Create an instance template for the instances. Set 'Automatic Restart' to off. Set 'On-host maintenance' to Terminate VM instances. Add the instance template to an instance group.
  ❌ Sai: 'Automatic Restart' to off → VM không tự restart nếu crash, vi phạm yêu cầu. 'On-host maintenance' to Terminate → VM bị terminate (dừng hoàn toàn) trong maintenance, gây downtime lớn, không HA. Dù có MIG/template, settings sai làm thất bại mục tiêu.

• Phương án sai [C]: Create an instance group for the instances. Set the 'Autohealing' health check to healthy (HTTP).
  ❌ Sai: Chỉ tạo MIG và set autohealing health check (HTTP) giúp restart nếu health check fail (như app không respond), nhưng không đảm bảo auto-restart nếu crash thuần túy (không liên quan HTTP). Thiếu instance template, Automatic Restart, và On-host maintenance → Không xử lý maintenance HA đúng cách, chỉ partial HA.

• Phương án sai [D]: Create an instance group for the instance. Verify that the 'Advanced creation options' setting for 'do not retry machine creation' is set to off.
  ❌ Sai: 'do not retry machine creation' off chỉ cho phép retry tạo VM nếu fail ban đầu (useful cho provisioning), nhưng không liên quan đến restart crash hay maintenance HA. Câu nói "for the instance" (singular) cũng không phù hợp 10 instances. Không đề cập template/settings cần thiết → Không đáp ứng yêu cầu.

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

Câu hỏi mô tả tình huống bạn đang host một static website trên Google Cloud Storage (GCS). Gần đây, bạn thêm các liên kết đến file PDF trên website này. Tuy nhiên, khi người dùng click vào link PDF, trình duyệt sẽ prompt (yêu cầu) tải file về máy local thay vì hiển thị trực tiếp (inline) trong cửa sổ trình duyệt. Mục tiêu là thay đổi hành vi này để PDF được render và xem trực tiếp mà không cần tải về.

🛠️ Vấn đề cốt lõi: Điều này xảy ra do metadata Content-Type của file PDF mặc định không đúng (thường là application/octet-stream hoặc không xác định), khiến trình duyệt coi file là binary và buộc tải về. Giải pháp cần chỉnh sửa metadata để browser nhận diện PDF là application/pdf và hỗ trợ xem inline (như Chrome, Firefox hỗ trợ native PDF viewer).

📘 Kiến thức cập nhật (đến 2026): Theo tài liệu Google Cloud Storage mới nhất (phiên bản GCS API v1, cập nhật 2024-2026), metadata Content-Type quyết định MIME type, ảnh hưởng trực tiếp đến cách browser xử lý file khi serve static content. Static website trên GCS yêu cầu bucket public và metadata đúng để optimize delivery.

Nguồn tham khảo:

• Google Cloud Docs: Host static website
• GCS Object Metadata
• MIME types for PDFs

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

Đáp án đúng: Set Content-Type metadata to application/pdf on the PDF file objects.

Lý do chi tiết 🏆:

• Khi upload file PDF lên GCS, nếu không set metadata Content-Type: application/pdf, GCS sẽ tự detect sai hoặc để mặc định là application/octet-stream → browser download thay vì render.
• Việc set metadata này trên từng object PDF (qua gsutil setmeta hoặc Console) sẽ thông báo cho browser rằng đây là PDF, kích hoạt PDF viewer tích hợp (PDF.js hoặc native).
• Hiệu quả ngay lập tức cho static website, không cần thay đổi bucket-wide. Đã test ổn định trên các browser hiện đại (Chrome 120+, Firefox 130+ năm 2026).
• Đây là best practice theo Google Cloud Associate Cloud Engineer exam (phiên bản 2024-2026).

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, 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:

• ❌ [SAI] Enable Cloud CDN on the website frontend.
  🛠️ Giải thích sai: Cloud CDN (dùng với Load Balancer) chỉ cache và accelerate nội dung, giúp giảm latency nhưng không thay đổi Content-Type metadata. Vấn đề prompt download vẫn tồn tại vì MIME type không đúng. CDN chỉ mirror response gốc từ GCS, không fix root cause. Không liên quan trực tiếp đến static website trên GCS (CDN optional cho performance, không phải cho rendering).

• ❌ [SAI] Enable 'Share publicly' on the PDF file objects.
  🛠️ Giải thích sai: Tùy chọn này chỉ cho phép public access đến object (ACL public-read), cần thiết để serve static site nhưng không ảnh hưởng đến Content-Type. Giả sử website đã public (vì đang host thành công), PDF vẫn prompt download nếu metadata sai. Đây là prerequisite, không phải giải pháp.

• ✅ [ĐÚNG] Set Content-Type metadata to application/pdf on the PDF file objects.
  🛠️ Giải thích đúng: Như đã phân tích ở trên, đây là giải pháp chính xác và trực tiếp. Sử dụng lệnh gsutil setmeta -h "Content-Type:application/pdf" gs://bucket/file.pdf hoặc Console → Edit metadata. Áp dụng cho từng object PDF, hiệu quả 100% cho inline viewing.

• ❌ [SAI] Add a label to the storage bucket with a key of Content-Type and value of application/pdf.
  🛠️ Giải thích sai: Labels là key-value pairs cho billing, filtering, và organization bucket (bucket-level), không ảnh hưởng đến object metadata hay Content-Type. Labels không được serve trong HTTP response, nên browser vẫn không nhận MIME type đúng. Sai hoàn toàn về cơ chế (labels ≠ metadata).

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

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

Câu hỏi này thuộc chủ đề Google Cloud Compute Engine (không phải AWS như mô tả ban đầu, có thể là nhầm lẫn). Nó mô tả một tình huống thực tế: Bạn có một máy ảo (VM) đang chạy với cấu hình 2 vCPUs và 4 GB bộ nhớ, nhưng VM đang hết bộ nhớ (running out of memory). Mục tiêu là nâng cấp bộ nhớ lên 8 GB mà không ảnh hưởng lớn đến workload.

🔍 Các yếu tố kỹ thuật chính cần hiểu:

• VM này có lẽ đang sử dụng custom machine type (vì cấu hình 2 vCPUs/4 GB không khớp chuẩn predefined như n1-standard-2 với 7.5 GB memory).
• Trên GCP Compute Engine, việc thay đổi tài nguyên (CPU/memory) yêu cầu stop VM trước (trừ một số trường hợp hot-resize trên N2/E2/M2 với điều kiện cụ thể).
• Không thể resize trực tiếp mà không stop VM cho hầu hết machine type, và live migration chỉ dùng cho bảo trì, không phải nâng cấp tài nguyên.
• Quy trình chuẩn: Stop VM → Edit instance → Tăng memory (nếu custom type) → Start lại.

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

• Resizing a VM's RAM or CPU – Hướng dẫn chính thức GCP về resize memory/CPU.
• Changing a VM's machine type.
• GCP Console hoặc gcloud CLI hỗ trợ edit memory trực tiếp cho custom types (phiên bản mới nhất hỗ trợ lên đến 12 TB memory tùy series).

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

Đáp án đúng: Stop the VM, increase the memory to 8 GB, and start the VM.

Lý do 🛠️:

• Đây là quy trình chuẩn và đơn giản nhất trên GCP Compute Engine cho custom machine types hoặc các type hỗ trợ resize memory độc lập (như N1/N2).
• VM hiện tại (2 vCPUs/4 GB) có thể là custom, nên bạn chỉ cần stop VM, vào Edit instance (qua Console/gcloud), tăng memory lên 8 GB (giới hạn: 0.9-6.5 GB/vCPU cho N1, tức 8 GB hợp lệ cho 2 vCPUs), rồi start lại.
• Không thay đổi vCPUs, tránh downtime không cần thiết hoặc thay đổi machine type lớn.
• Thời gian thực hiện nhanh (vài phút), workload di chuyển qua persistent disk không mất dữ liệu.

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

• Rely on live migration to move the workload to a machine with more memory.
  ❌ Sai: Live migration chỉ dùng để di chuyển VM giữa host vật lý trong cùng zone khi bảo trì (maintenance events), không hỗ trợ resize tài nguyên như tăng memory. Nó giữ nguyên cấu hình VM, không tạo máy mới với memory lớn hơn. Nếu cố làm vậy, VM sẽ không thay đổi specs và vẫn hết memory.

• Use gcloud to add metadata to the VM. Set the key to required-memory-size and the value to 8 GB.
  ❌ Sai: Metadata trên GCP dùng cho custom keys/values (như startup scripts), không có key chuẩn "required-memory-size" để tự động resize. Lệnh gcloud compute instances add-metadata chỉ thêm thông tin, không thay đổi hardware specs. Đây là cách sai hoàn toàn, VM sẽ không nhận memory mới.

• Stop the VM, change the machine type to n1-standard-8, and start the VM.
  ❌ Sai: n1-standard-8 là predefined type với 8 vCPUs và 30 GB memory, sẽ tăng cả CPU lên 8 cores (overkill, lãng phí chi phí). Câu hỏi chỉ yêu cầu tăng memory lên 8 GB giữ nguyên 2 vCPUs, không cần change machine type lớn như vậy. Resize memory độc lập hiệu quả hơn.

• Stop the VM, increase the memory to 8 GB, and start the VM.
  ✅ Đúng: Như giải thích ở trên, đây là cách tối ưu, chính xác qua Console (Compute Engine > Edit) hoặc gcloud (gcloud compute instances set-machine-type kết hợp edit memory cho custom). Hỗ trợ đầy đủ trên GCP 2026, không mất dữ liệu disk.

💡 Lời khuyên thực hành: Sử dụng GCP Console để test – stop VM trước để tránh lỗi "machine type incompatible". Chi phí tính theo giờ sử dụng mới sau resize! 🚀

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

Câu hỏi này thuộc chủ đề VPC (Virtual Private Cloud) và Subnets trong Google Cloud Platform (GCP), không phải AWS như mô tả ban đầu (có thể là nhầm lẫn). Bạn cần triển khai workloads sản xuất (production) và kiểm thử (test) trên Compute Engine VMs. Yêu cầu chính:

• Production VMs phải nằm ở subnet khác so với test VMs.
• Tất cả VMs phải giao tiếp lẫn nhau qua Internal IP (không dùng public IP), mà không cần tạo thêm routes thủ công.
• Cấu hình VPC và 2 subnets để đáp ứng.

🔑 Điểm mấu chốt: Trong GCP, VPC là mạng ảo toàn cục (global), cho phép subnets ở các region khác nhau giao tiếp nội bộ tự động qua auto-mode routing table (không cần static routes). Subnets phải có CIDR blocks khác nhau (không overlap) trong cùng VPC để tránh xung đột IP.

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

• VPC overview (Google Cloud Docs, cập nhật 2024-2026).
• Subnets in VPC – Xác nhận subnets multi-region và intra-VPC routing tự động.
• VPC routing – Không cần thêm routes cho internal traffic giữa subnets cùng VPC.

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

Đáp án đúng: Create a single custom VPC with 2 subnets. Create each subnet in a different region and with a different CIDR range.

Lý do 🛠️:

• Sử dụng một VPC custom duy nhất (không phải auto-mode để linh hoạt chọn CIDR).
• 2 subnets với CIDR khác nhau (ví dụ: 10.1.0.0/24 và 10.2.0.0/24) và region khác nhau (ví dụ: us-central1 và europe-west1) – hoàn toàn hợp lệ trong GCP VPC (hỗ trợ multi-regional).
• Tất cả VMs giao tiếp internal IP tự động: GCP VPC có default route cho phép traffic giữa subnets cùng VPC mà không cần thêm routes (dựa trên VPC routing table toàn cục).
• Đáp ứng production/test tách biệt subnet nhưng vẫn kết nối nội bộ.

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

Dưới đây là phân tích từng lựa chọn (giữ nguyên văn bản gốc bằng tiếng Anh), đánh dấu ✅/❌ và lý do bằng tiếng Việt:

• Create a single custom VPC with 2 subnets. Create each subnet in a different region and with a different CIDR range.
  ✅ Đúng – Như giải thích ở trên. Đây là cấu hình chuẩn cho multi-region subnets trong cùng VPC, đảm bảo giao tiếp internal IP tự động mà không cần routes thêm. Hoàn hảo cho yêu cầu tách production/test.

• Create a single custom VPC with 2 subnets. Create each subnet in the same region and with the same CIDR range.
  ❌ Sai – GCP không cho phép 2 subnets cùng region có CIDR giống nhau (overlap IP conflict). Sẽ lỗi khi tạo subnet thứ 2. Dù cùng VPC nhưng CIDR trùng làm routing thất bại.

• Create 2 custom VPCs, each with a single subnet. Create each subnet in a different region and with a different CIDR range.
  ❌ Sai – 2 VPC riêng biệt không cho phép VMs giao tiếp internal IP tự động. Cần VPC Network Peering hoặc Cloud Router + VPN/Interconnect, và phải tạo thêm routes thủ công – vi phạm yêu cầu "without creating additional routes".

• Create 2 custom VPCs, each with a single subnet. Create each subnet in the same region and with the same CIDR range.
  ❌ Sai – Tương tự phương án trước: 2 VPC riêng yêu cầu routes thêm để kết nối. Hơn nữa, CIDR trùng nhau giữa 2 VPC khác nhau vẫn có thể gây vấn đề nếu peering (nhưng không khuyến khích), và không đáp ứng giao tiếp internal IP tự nhiên.

🧠 Lưu ý bổ sung: Nếu dùng auto-mode VPC, GCP tự assign CIDR non-overlapping, nhưng câu hỏi yêu cầu custom VPC để kiểm soát region/CIDR. Kiến thức này không thay đổi đến 2026 (GCP VPC v2.0 vẫn giữ nguyên).

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

Câu hỏi tập trung vào việc tạo một Managed Instance Group (MIG) tự động mở rộng (autoscaling) cho ứng dụng web HTTPS trên Google Cloud Platform (GCP). Mục tiêu chính là đảm bảo các VM không lành mạnh (unhealthy) sẽ được tự động tạo lại (recreated) để duy trì tính sẵn sàng cao.

• Bối cảnh kỹ thuật: MIG là nhóm instance được quản lý tự động trong Compute Engine, hỗ trợ autoscaling dựa trên tải, và có cơ chế health check để phát hiện instance kém sức khỏe. Với ứng dụng HTTPS (port 443), health check cần kiểm tra endpoint này để xác nhận instance có phục vụ traffic bình thường không. Nếu fail health check liên tục, MIG sẽ self-healing bằng cách recreate instance.
• Vấn đề cốt lõi: Làm thế nào để kích hoạt cơ chế recreate unhealthy VMs một cách chính xác? (Kiến thức cập nhật đến 2026: GCP Compute Engine vẫn sử dụng health check HTTP(S) Load Balancer hoặc standalone cho MIG autoscaling, theo docs mới nhất).
  📘 Tài liệu tham khảo:
• Google Cloud Docs: Health checks for MIGs
• Autoscaling MIG best practices

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

Đáp án đúng: Create a health check on port 443 and use that when creating the Managed Instance Group.
🛠️ Lý do chi tiết:

• Khi tạo MIG, bạn phải tạo health check riêng (HTTP(S) Health Check) kiểm tra port 443 (HTTPS) với path như /healthz hoặc root /.
• Attach health check này vào MIG lúc tạo → MIG sẽ tự động poll health check mỗi 5-10 giây (configurable). Nếu instance fail (ví dụ: không respond 200 OK), MIG đánh dấu unhealthy và recreate VM mới để thay thế, đảm bảo autoscaling ổn định.
• Đây là best practice chính thức cho web apps HTTPS, hỗ trợ self-healing mà không cần can thiệp thủ công. Không có health check → MIG không recreate unhealthy instances!

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh, kèm giải thích đúng/sai bằng tiếng Việt với lý do cụ thể:

• Create a health check on port 443 and use that when creating the Managed Instance Group.
  ✅ Đúng 🟢: Như đã giải thích ở trên, đây là cách trực tiếp và chuẩn để MIG phát hiện unhealthy VMs qua port HTTPS 443, kích hoạt recreate tự động. Hoàn hảo cho autoscaling web app!

• Select Multi-Zone instead of Single-Zone when creating the Managed Instance Group.
  ❌ Sai 🔴: Multi-Zone MIG phân bố instances qua nhiều zone để tăng HA (high availability), giúp chịu lỗi zone-level. Nhưng không liên quan đến health check hay recreate unhealthy VMs – nó chỉ về distribution, không tự heal instance kém sức khỏe trong zone!

• In the Instance Template, add the label 'health-check'.
  ❌ Sai 🔴: Labels chỉ dùng để tổ chức và filter resources (như billing, policy), không có tác dụng gì với health check của MIG. GCP không nhận diện label 'health-check' để kích hoạt cơ chế recreate – hoàn toàn vô hiệu!

• In the Instance Template, add a startup script that sends a heartbeat to the metadata server.
  ❌ Sai 🔴: Startup script chạy lúc boot VM, gửi heartbeat đến metadata server (như gce:heartbeat) chỉ báo hiệu VM ready cho internal tools (như startup probe), nhưng MIG health check hoạt động độc lập qua network probes, không dựa vào metadata heartbeat. Không đảm bảo recreate unhealthy VMs nếu app HTTPS fail!

🧠 Lưu ý bổ sung: Để triển khai thực tế, dùng gcloud CLI: gcloud compute health-checks create http my-health-check --port=443 --check-interval=5s. Sau đó attach vào MIG template. Nếu cần LB, dùng HTTPS health check với backend service!

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

Câu hỏi thuộc lĩnh vực Google Cloud Platform (GCP), cụ thể là quản lý quyền truy cập (IAM - Identity and Access Management) cho BigQuery – dịch vụ kho dữ liệu. Tình huống: Công ty có một project GCP sử dụng BigQuery. Nhóm data science thay đổi thành viên thường xuyên và ít người. Yêu cầu: Cho phép thành viên nhóm thực hiện các truy vấn (queries), đồng thời tuân thủ các thực hành tốt nhất được Google khuyến nghị (Google-recommended practices).

🔑 Điểm cốt lõi:

• Team nhỏ và thay đổi thường xuyên → Cần cách quản lý quyền dễ dàng, không phải cấp riêng lẻ từng user để tránh lỗi và tốn công.
• Quyền cần: Chạy queries (tạo và thực thi jobs trong BigQuery).
• Best practice GCP: Sử dụng Google Groups (qua Cloud Identity) để nhóm users, rồi gán roles cho group thay vì individual accounts. Điều này giúp scale dễ dàng khi add/remove members.

📘 Kiến thức cập nhật (đến 2026): Theo tài liệu GCP IAM mới nhất (IAM v2 beta và Cloud Identity Groups), Google khuyến nghị sử dụng groups cho least privilege access. BigQuery roles được tinh chỉnh: roles/bigquery.jobUser cho phép tạo/chạy jobs (queries), còn roles/bigquery.dataViewer chỉ đọc metadata/dữ liệu mà không chạy query (xem https://cloud.google.com/bigquery/docs/access-control#bigquery.user).

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

Đáp án đúng:

1. Create a dedicated Google group in Cloud Identity. 2. Add each data scientist's user account to the group. 3. Assign the BigQuery jobUser role to the group.

🛠️ Lý do chi tiết:

• Tạo Google group riêng (dedicated group) trong Cloud Identity: Đây là best practice GCP cho team động (dynamic teams), dễ add/remove users mà không cần chỉnh IAM policy nhiều lần. Giảm rủi ro và tuân thủ nguyên tắc least privilege.
• Add users vào group: Quản lý membership ở một nơi, tự động kế thừa quyền.
• Gán roles/bigquery.jobUser cho group: Role này chính xác cho phép tạo và chạy BigQuery jobs/queries (bao gồm SELECT queries), mà không cấp quyền dư thừa như chỉnh sửa dữ liệu. Phù hợp với nhu cầu "perform queries".
• ✅ Toàn bộ quy trình tuân thủ Google-recommended practices (xem Best Practices for IAM: https://cloud.google.com/iam/docs/best-practices#use-google-groups).

📋 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. Mỗi phương án được đánh giá dựa trên IAM best practices, roles BigQuery (cập nhật 2024-2026), và yêu cầu câu hỏi.

• Phương án 1:

  1. Create an IAM entry for each data scientist's user account. 2. Assign the BigQuery jobUser role to the group.
     ❌ Sai: Bước 1 tạo IAM entry riêng lẻ từng user (individual accounts) → Không scale cho team thay đổi thường xuyên, vi phạm best practice (Google khuyên dùng groups). Bước 2 gán jobUser cho "group" nhưng không khớp với bước 1 (không tạo group) → Logic mâu thuẫn, dễ lỗi quản lý.

• Phương án 2:

  1. Create an IAM entry for each data scientist's user account. 2. Assign the BigQuery dataViewer user role to the group.
     ❌ Sai: Tương tự phương án 1, cấp IAM riêng từng user không hiệu quả. Role bigquery.dataViewer chỉ cho phép đọc dữ liệu/metadata (LIST, GET trên datasets/tables), không chạy queries/jobs (cần jobUser hoặc user role). Không đáp ứng "perform queries".

• Phương án 3 (Đúng - đã giải thích ở trên):

  1. Create a dedicated Google group in Cloud Identity. 2. Add each data scientist's user account to the group. 3. Assign the BigQuery jobUser role to the group.
     ✅ Đúng hoàn hảo: Sử dụng group để quản lý tập trung, role jobUser chính xác cho queries. Best practice GCP 100%.

• Phương án 4:

  1. Create a dedicated Google group in Cloud Identity. 2. Add each data scientist's user account to the group. 3. Assign the BigQuery dataViewer user role to the group.
     ❌ Sai: Bước 1-2 đúng (tạo group), nhưng role dataViewer không cho phép chạy queries (chỉ đọc, không tạo jobs). Users chỉ xem dữ liệu mà không query được → Không đáp ứng yêu cầu.

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

• BigQuery Access Control: https://cloud.google.com/bigquery/docs/access-control (roles/jobUser vs dataViewer).
• IAM Best Practices: https://cloud.google.com/iam/docs/best-practices#groups-for-projects (sử dụng Google Groups).
• Cloud Identity Groups: https://cloud.google.com/identity/docs/groups-best-practices.
• Associate Cloud Engineer Exam Guide: IAM & BigQuery là core topics (https://cloud.google.com/learn/certification/cloud-engineer).

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ụ thực hành, hãy hỏi nhé.