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

Tìm thấy 269 câu.

Câu 61
As an Electric vehicle manufacturer company, you recently faced an outage caused by a new release that exhausted the memory resources of your service. After successfully rolling back the release, you are now responsible for conducting a post-mortem of the outage. As per Site Reliability Engineering practices, what steps should you take for the post-mortem? Also, how can Google Cloud Services help in this scenario?
  1. A Emphasize the development of novel functionalities instead of preventing the recurrence of outages.
  2. B The related code commit can be identified by utilizing the Git history, and it is recommended to restrict the engineer responsible for that commit from accessing production services.
  3. C Instead of blaming the individual for the cause, concentrate on recognizing the contributing factors of the incident.
  4. D Schedule separate meetings with each engineer who was involved in the process and identify the person responsible for authorizing and deploying the latest release to the production environment.
Xem giải thích

Đáp án

C — Thay vì quy trách nhiệm cho cá nhân, hãy tập trung nhận diện các yếu tố góp phần gây ra sự cố.

Vì sao đúng

Đây là nguyên tắc blameless postmortem — nền tảng của văn hoá SRE.

⚠ Vì sao tập trung vào yếu tố góp phần:

⚠ Sự cố hiếm khi do MỘT nguyên nhân
        ↓
⚠ Thường là NHIỀU yếu tố cộng lại:
   → ⚠ thiếu giới hạn bộ nhớ
   → ⚠ thiếu kiểm thử tải
   → ⚠ thiếu cảnh báo sớm
   → ⚠ quay lui chậm
        ↓
⚠ Sửa hệ thống mới ngăn được lần sau

⚠ Trong ca này: bản phát hành làm cạn bộ nhớ. ⚠ Câu hỏi đúng không phải "ai viết đoạn mã đó" mà "vì sao hệ thống cho phép một bản như vậy lên sản xuất".

Vì sao các phương án khác sai

  • B (dùng lịch sử Git tìm commit rồi HẠN CHẾ quyền truy cập sản xuất của kỹ sư đó) — ⚠ vi phạm blameless nghiêm trọng nhất: ⚠ trừng phạt cá nhân khiến người ta giấu sự cố và né trách nhiệm lần sau.

  • D (họp riêng từng kỹ sư để tìm ai đã duyệt và triển khai bản đó) — ⚠ săn tìm thủ phạm, ⚠ tạo không khí sợ hãi.

  • A (ưu tiên phát triển tính năng mới thay vì ngăn sự cố tái diễn) — ⚠ bỏ qua mục đích của postmortem.

Ghi nhớ

⚠ Blameless postmortem — nguyên tắc — bảng phải thuộc: | Nguyên tắc | Nội dung | |---|---| | ⚠ Tập trung HỆ THỐNG, không vào NGƯỜI | | | ⚠ Giả định mọi người làm tốt nhất với thông tin họ có | | | ⚠ Hỏi "vì sao hệ thống cho phép" | ⚠ không hỏi "ai làm sai" | | ⚠ Nhiều yếu tố góp phần, không một nguyên nhân | | | Chia sẻ rộng để cả tổ chức học | |

Từ khoá nhận diện:

"yếu tố góp phần, không quy trách nhiệm" → ⚠ blameless "tìm ai viết commit đó" → ⚠ luôn SAI "hạn chế quyền của kỹ sư" → ⚠ trừng phạt, phản tác dụng "họp riêng tìm người duyệt" → ⚠ săn thủ phạm

⚠ Vì sao trừng phạt cá nhân phản tác dụng Lý do
⚠ Người ta GIẤU sự cố ⚠ hậu quả tệ nhất
⚠ Không ai dám báo cáo lỗi nhỏ ⚠ lỗi nhỏ tích thành lỗi lớn
⚠ Mất thông tin để cải thiện hệ thống
⚠ Người giỏi rời đi
⚠ Và quan trọng nhất ⚠ người tiếp theo cũng sẽ mắc lỗi đó nếu hệ thống không đổi
⚠ Hỏi "5 lần vì sao" cho ca này Chuỗi
⚠ Vì sao dịch vụ sập? ⚠ hết bộ nhớ
⚠ Vì sao hết bộ nhớ? ⚠ bản mới dùng nhiều RAM hơn
⚠ Vì sao không phát hiện trước? ⚠ không kiểm thử tải
⚠ Vì sao không kiểm thử tải? ⚠ không có trong quy trình phát hành
⚠ Vì sao không có trong quy trình? ⚠ ← ĐÂY mới là chỗ cần sửa
⚠ Hành động khắc phục cho ca này Hành động
⚠ Đặt resource limit cho container
⚠ Kiểm thử tải bắt buộc trước phát hành
⚠ Cảnh báo mức dùng bộ nhớ
⚠ Canary để phát hiện sớm
Quay lui tự động khi vượt ngưỡng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Postmortem có nêu tên buộc tội ai không | | | Đã hỏi tới lớp hệ thống chưa | ⚠ dừng ở "người X làm sai" là chưa đủ sâu | | Hành động khắc phục có nhắm vào hệ thống không | |

Và cách kiểm tra một postmortem có blameless thật hay không: thay tên người gây ra sự cố bằng "một kỹ sư bất kỳ" và đọc lại. Nếu phân tích vẫn đứng vững thì nó blameless; nếu sụp đổ thì nó đang buộc tội.

Câu 62
As an Language translation app company, you have a CI/CD pipeline that uses Cloud Build to build new Docker images and push them to Docker Hub. You use Git for code versioning. After making a change in the Cloud Build YAML configuration, you notice that no new artifacts are being built by the pipeline. What steps should you take to resolve the issue in line with Site Reliability Engineering practices?
  1. A Switch to manual artifact building and pushing by disabling the CI pipeline.
  2. B To identify and resolve the issue, perform a Git comparison of the past and present Cloud Build Configuration files.
  3. C Modify the CI pipeline to push the artifacts to Container Registry instead of Docker Hub.
  4. D The suggested solution would be to transfer the configuration YAML file to Cloud Storage and then utilize Error Reporting to detect and resolve the problem.
Xem giải thích

Đáp án

B — Thực hiện so sánh Git giữa file cấu hình Cloud Build trước đây và hiện tại để tìm và khắc phục vấn đề.

Vì sao đúng

Đề nêu chuỗi sự kiện rất rõ: thay đổi file YAML → pipeline ngừng tạo artefact.

⚠ Suy luận nhân quả:

⚠ Trước khi sửa: pipeline chạy tốt
⚠ Sau khi sửa: không tạo artefact
        ↓
⚠ Nguyên nhân gần như chắc chắn
  nằm trong THAY ĐỔI ĐÓ
        ↓
⚠ So sánh trước/sau = cách nhanh nhất

⚠ Đây là ứng dụng trực tiếp của việc quản lý cấu hình bằng Git: có lịch sử thì có thể so sánh.

Vì sao các phương án khác sai

  • A (tắt CI pipeline, chuyển sang build và đẩy artefact thủ công) — ⚠ đi ngược mọi thực hành DevOps: ⚠ né tránh vấn đề, ⚠ tăng toil, ⚠ mất tính lặp lại.

  • C (đổi pipeline để đẩy artefact vào Container Registry thay vì Docker Hub) — ⚠ thay đổi không liên quan tới nguyên nhân: đích đẩy không phải lý do pipeline ngừng chạy.

  • D (chuyển file YAML lên Cloud Storage rồi dùng Error Reporting để tìm lỗi) — ⚠ sai công cụ và sai nơi: ⚠ Cloud Build đọc cấu hình từ repo, ⚠ Error Reporting gom lỗi ứng dụng, không phải lỗi cấu hình build.

Ghi nhớ

⚠ Chẩn đoán sự cố sau thay đổi — bảng phải thuộc: | Bước | Việc | |---|---| | ⚠ 1. Xác định thay đổi gần nhất | ⚠ Git log | | ⚠ 2. So sánh trước và sau | ⚠ git diff — đề này | | ⚠ 3. Đọc log build để biết lỗi cụ thể | | | ⚠ 4. Quay lui nếu cần gấp | | | 5. Sửa và kiểm thử | |

Từ khoá nhận diện:

"vừa sửa cấu hình xong thì hỏng" → ⚠ so sánh Git "chuyển sang làm thủ công" → ⚠ né tránh, tăng toil "đổi thứ không liên quan" → ⚠ không giải quyết nguyên nhân "Error Reporting cho lỗi cấu hình" → ⚠ sai công cụ

⚠ Lỗi thường gặp trong cloudbuild.yaml Lỗi
⚠ Sai thụt lề YAML ⚠ YAML rất nhạy với khoảng trắng
⚠ Sai tên trigger hoặc điều kiện lọc nhánh ⚠ pipeline không chạy vì không khớp
⚠ Sai biến thay thế ⚠ $_MY_VAR chưa khai báo
Sai tên bước hoặc waitFor
⚠ Thiếu quyền cho service account
⚠ Vì sao "không tạo artefact" khác "build lỗi" Phân biệt
⚠ Build LỖI ⚠ có chạy, có log lỗi
⚠ KHÔNG chạy gì cả ⚠ trigger không khớp, không có log
⚠ Kiểm đầu tiên ⚠ có bản build nào được kích hoạt không
Nếu không có ⚠ vấn đề ở TRIGGER, không ở các bước
⚠ Giá trị của cấu hình dạng mã Giá trị
⚠ Có lịch sử để so sánh ⚠ đề này
⚠ Quay lui được
⚠ Rà soát trước khi áp dụng
Tái tạo được môi trường
⚠ Ngược lại ⚠ cấu hình bấm tay trên giao diện thì không so được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bản build nào được kích hoạt không | ⚠ phân biệt "không chạy" với "chạy lỗi" | | Thay đổi gần nhất là gì | ⚠ git diff | | Cấu hình mới có được rà soát trước khi merge không | |

Và lợi ích lớn nhất của việc để mọi cấu hình trong Git: khi có sự cố, câu hỏi "gần đây có gì thay đổi" luôn trả lời được trong ba mươi giây. Đó thường là con đường ngắn nhất tới nguyên nhân.

Câu 63
As a DevOps Engineer for an online marketplace for freelancers, you are taking over the management of a new freelance matching service from the Development Team. After conducting a Production Readiness Review (PRR) using Google Cloud services, you determine that the service cannot meet its Service Level Objectives (SLOs). What steps should you take to ensure that the service can meet its SLOs in production?
  1. A The development team needs to be informed that they are responsible for providing support for the service in production.
  2. B Start running the service without any Service Level Objectives (SLOs) and construct them later on after gathering operational information.
  3. C Make sure that the SLO targets are realistic for the service to be able to meet before deploying it.
  4. D Before the handover, recognize the reliability enhancements that are suggested for the service.
Xem giải thích

Đáp án

D — Trước khi bàn giao, xác định các cải thiện về độ tin cậy được khuyến nghị cho dịch vụ.

Vì sao đúng

Đề nêu tình huống: Production Readiness Review (PRR) kết luận dịch vụ KHÔNG đạt SLO. Bàn giao trong tình trạng đó là bàn giao một vấn đề.

⚠ Mục đích của PRR:

⚠ Kiểm TRƯỚC khi đội SRE nhận vận hành
        ↓
⚠ Không đạt → ⚠ liệt kê việc phải sửa
        ↓
⚠ Đội phát triển sửa
        ↓
⚠ Kiểm lại rồi mới bàn giao

⚠ Nguyên tắc: đội SRE không nhận vận hành một dịch vụ chưa đủ độ tin cậy — nếu nhận, họ sẽ dành toàn bộ thời gian chữa cháy thay vì cải thiện hệ thống.

Vì sao các phương án khác sai

  • C (đảm bảo mục tiêu SLO thực tế để dịch vụ có thể đạt được trước khi triển khai) — ⚠ bẫy tinh vi nhất: nghe hợp lý, nhưng ⚠ hạ SLO cho vừa năng lực hiện tại là ⚠ che giấu vấn đề. SLO phải phản ánh kỳ vọng của người dùng, không phải hiệu năng hiện có.

  • A (thông báo đội phát triển tự chịu trách nhiệm hỗ trợ dịch vụ trên sản xuất) — ⚠ đẩy trách nhiệm, không giải quyết; và ⚠ phá vỡ mô hình hợp tác giữa dev và SRE.

  • B (chạy dịch vụ không có SLO rồi xây SLO sau khi có dữ liệu vận hành) — ⚠ mất tiêu chuẩn: ⚠ không có SLO thì không biết thế nào là chấp nhận được, và ⚠ SLO xây từ hiệu năng thực tế lại rơi vào bẫy của phương án C.

Ghi nhớ

⚠ Production Readiness Review kiểm gì — bảng phải thuộc: | Hạng mục | Nội dung | |---|---| | ⚠ SLI/SLO đã định nghĩa và đo được | | | ⚠ Giám sát và cảnh báo đầy đủ | | | ⚠ Runbook cho các sự cố thường gặp | | | ⚠ Quy trình quay lui đã thử | | | ⚠ Kiểm thử tải và kế hoạch năng lực | | | Kiến trúc chịu lỗi | | | Bảo mật và tuân thủ | |

Từ khoá nhận diện:

"PRR không đạt, chuẩn bị bàn giao" → ⚠ liệt kê cải thiện, sửa rồi mới bàn giao "hạ SLO cho vừa" → ⚠ che giấu vấn đề "chạy trước, làm SLO sau" → ⚠ mất tiêu chuẩn "đội dev tự lo" → ⚠ đẩy trách nhiệm

⚠ Vì sao SRE có quyền từ chối nhận Lý do
⚠ Nhận dịch vụ kém = SRE chỉ chữa cháy
⚠ Không còn thời gian làm việc có giá trị lâu dài
⚠ Tạo động lực sai cho đội phát triển ⚠ cứ đẩy sang là xong
Cơ chế này ⚠ buộc chất lượng phải đạt TRƯỚC khi bàn giao
⚠ SLO phải dựa trên gì Dựa trên
⚠ KỲ VỌNG người dùng ⚠ bao nhiêu lỗi thì họ khó chịu
⚠ Yêu cầu nghiệp vụ
⚠ KHÔNG dựa trên hiệu năng hiện tại
⚠ Nếu không đạt được SLO hợp lý ⚠ phải CẢI THIỆN hệ thống, không hạ mục tiêu
Chỉ hạ SLO khi ⚠ chứng minh được kỳ vọng ban đầu đặt sai
⚠ Mô hình hợp tác dev và SRE Mô hình
⚠ SRE nhận vận hành khi dịch vụ đạt chuẩn
⚠ SRE có thể TRẢ LẠI dịch vụ nếu chất lượng tụt ⚠ cơ chế bảo vệ quan trọng
⚠ Dev vẫn tham gia trực sự cố
Cùng nhìn một bộ SLO

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Danh sách cải thiện có cụ thể và đo được không | | | Ai chịu trách nhiệm từng mục | | | Có tiêu chí rõ để kiểm lại không | ⚠ bàn giao khi nào thì được coi là đạt |

Và giá trị thật của PRR không nằm ở việc chặn bàn giao, mà ở chỗ nó buộc câu hỏi "dịch vụ này đã sẵn sàng chưa" được đặt ra một cách có hệ thống — thay vì phát hiện câu trả lời vào lúc 3 giờ sáng.

Câu 64
As a food delivery company, your team has recently deployed an application that uses NGINX into Google Kubernetes Engine (GKE) and has exposed it to the public through an HTTP Google Cloud Load Balancer (GCLB) ingress. You want to ensure that your customers can access your application without any issues. What steps would you take to scale the application's frontend using an appropriate Service Level Indicator (SLI)?
  1. A To utilize the number of requests provided by the Google Cloud Load Balancer (GCLB), one must install the Cloud custom metrics adapter and set up a horizontal pod autoscaler.
  2. B In GKE, set up the vertical pod autoscaler and activate the cluster autoscaler to adjust the size of the cluster when pods increase.
  3. C Set up the horizontal pod autoscaler to utilize the mean response time derived from the Liveness and Readiness probes.
  4. D You need to make the NGINX stats endpoint available and then set up the horizontal pod autoscaler to utilize the request metrics obtained from the NGINX deployment.
Xem giải thích

Đáp án

A — Cài Cloud custom metrics adapter và cấu hình horizontal pod autoscaler dùng số lượng request do Google Cloud Load Balancer cung cấp.

Vì sao đúng

Đề cần co giãn frontend theo một SLI phù hợp. Với ứng dụng web sau load balancer, chỉ số phản ánh tải thật nhất là số request tại GCLB.

⚠ Vì sao chỉ số từ GCLB tốt nhất:

⚠ GCLB thấy TOÀN BỘ traffic vào
        ↓
⚠ Số request = tải thật người dùng tạo ra
        ↓
⚠ Không phụ thuộc CPU
   → ⚠ CPU có thể thấp mà vẫn nghẽn
     ở I/O hoặc kết nối
        ↓
⚠ Custom metrics adapter đưa chỉ số
  Cloud Monitoring vào HPA

Vì sao các phương án khác sai

  • D (phơi endpoint thống kê của NGINX rồi HPA dùng chỉ số request từ deployment NGINX) — ⚠ bẫy gần nhất và làm được: nhưng ⚠ tốn công hơn (phải cấu hình exporter, service monitor), và ⚠ chỉ thấy traffic đã tới pod, không thấy phần bị nghẽn ở tầng trên.

  • C (HPA dùng thời gian phản hồi trung bình từ Liveness và Readiness probe) — ⚠ sai mục đích của probe: ⚠ probe để kiểm tra sức khoẻ, không phải để đo hiệu năng; ⚠ và trung bình che mất đuôi phân bố.

  • B (dùng vertical pod autoscaler cùng cluster autoscaler) — ⚠ sai loại co giãn: ⚠ VPA chỉnh kích thước pod, không tăng số pod; ⚠ frontend web cần co giãn theo chiều ngang.

Ghi nhớ

⚠ Chọn chỉ số cho HPA — bảng phải thuộc: | Chỉ số | Dùng khi | |---|---| | ⚠ Số request (từ LB) | ⚠ frontend web — đề này | | CPU | ⚠ tải tính toán, mặc định | | Bộ nhớ | ⚠ cẩn thận: bộ nhớ ít giảm xuống | | ⚠ Độ sâu hàng đợi | ⚠ worker xử lý job | | Chỉ số tuỳ chỉnh | ⚠ cần custom metrics adapter |

Từ khoá nhận diện:

"co giãn frontend theo tải người dùng" → ⚠ số request từ LB "vertical pod autoscaler" → ⚠ chỉnh kích thước pod, không tăng số pod "dùng probe để đo hiệu năng" → ⚠ sai mục đích probe "chỉ số tuỳ chỉnh cho HPA" → ⚠ cần custom metrics adapter

⚠ Ba loại autoscaler — nhắc lại Loại
⚠ HPA ⚠ tăng SỐ pod — đề này
⚠ VPA ⚠ chỉnh request/limit của pod
⚠ Cluster Autoscaler ⚠ tăng số NODE
⚠ Lưu ý ⚠ HPA và VPA trên cùng chỉ số sẽ XUNG ĐỘT
⚠ Vì sao CPU không phải lúc nào cũng đúng Lý do
⚠ Ứng dụng nghẽn I/O có CPU thấp ⚠ HPA không kích hoạt dù đang quá tải
⚠ Ứng dụng chờ CSDL cũng vậy
⚠ Số request phản ánh tải thật hơn
Nguyên tắc ⚠ chọn chỉ số phản ánh ĐIỀU khiến dịch vụ chậm
⚠ Lưu ý khi cấu hình HPA Lưu ý
⚠ Đặt minReplicas đủ cho lỗi zone
⚠ maxReplicas tính tới trần node và quota
⚠ Chú ý thời gian khởi động pod ⚠ pod chậm khởi động thì phản ứng chậm
⚠ Tránh dao động liên tục ⚠ cấu hình stabilization window
Readiness probe đúng ⚠ pod chưa sẵn sàng không nên nhận traffic

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số có phản ánh nghẽn thật không | ⚠ CPU thấp mà vẫn chậm là dấu hiệu chọn sai chỉ số | | Pod mất bao lâu để sẵn sàng | ⚠ quyết định HPA phản ứng kịp hay không | | HPA có dao động liên tục không | |

Và câu hỏi nên đặt trước khi chọn chỉ số cho autoscaler: "khi dịch vụ quá tải, con số nào tăng lên đầu tiên?" Chọn đúng con số đó thì autoscaler phản ứng đúng lúc; chọn sai thì nó ngồi im trong khi người dùng đang chờ.

Câu 65
As an event ticketing platform company, how can we reduce costs for a stable, business-critical workload running on a fixed set of Compute Engine instances for several months without affecting its performance, while using Google Cloud Services?
  1. A For the instances utilized to execute the workload, generate an Unmanaged Instance Group.
  2. B Invest in Committed Use Discounts.
  3. C Transform the instances into preemptible VMs.
  4. D Move the instances to a Managed Instance Group.
Xem giải thích

Đáp án

B — Mua Committed Use Discounts (chiết khấu cam kết sử dụng).

Vì sao đúng

Đề nêu ba đặc điểm, và cả ba đều khớp điều kiện của CUD:

⚠ Ba đặc điểm:

"tải ỔN ĐỊNH"
    → ⚠ nhu cầu dự đoán được

"chạy nhiều THÁNG"
    → ⚠ đủ dài để cam kết

"KHÔNG được ảnh hưởng hiệu năng"
    → ⚠ CUD KHÔNG đổi gì về máy
    → ⚠ chỉ đổi cách TÍNH TIỀN

⚠ CUD là chiết khấu thuần tuý về giá — máy vẫn y nguyên, không có rủi ro bị thu hồi.

Vì sao các phương án khác sai

  • C (chuyển sang preemptible VM) — ⚠ bẫy mạnh nhất về giá: rẻ hơn nhiều nhưng ⚠ có thể bị thu hồi bất cứ lúc nào. ⚠ Đề nói "business-critical" — không chấp nhận được.

  • D (chuyển sang Managed Instance Group) — ⚠ MIG là công cụ quản lý và co giãn, ⚠ tự nó KHÔNG giảm giá. Với tải cố định thì cũng không cần co giãn.

  • A (tạo Unmanaged Instance Group) — ⚠ chỉ là cách nhóm các instance, ⚠ không liên quan gì tới chi phí.

Ghi nhớ

⚠ Các cách giảm chi phí Compute Engine — bảng phải thuộc: | Cách | Điều kiện | |---|---| | ⚠ Committed Use Discount | ⚠ tải ổn định, cam kết 1–3 năm — đề này | | Sustained Use Discount | ⚠ TỰ ĐỘNG khi chạy nhiều trong tháng | | ⚠ Spot/Preemptible VM | ⚠ chịu được gián đoạn | | Right-sizing | ⚠ chọn đúng cỡ máy | | Tắt máy nhàn rỗi | |

Từ khoá nhận diện:

"ổn định, nhiều tháng, không ảnh hưởng hiệu năng" → ⚠ CUD "chịu được gián đoạn" → ⚠ Spot/Preemptible "cần co giãn tự động" → ⚠ MIG — nhưng không giảm giá trực tiếp "nhóm instance" → ⚠ không liên quan chi phí

⚠ CUD — chi tiết cần biết Chi tiết
⚠ Cam kết 1 năm hoặc 3 năm ⚠ 3 năm chiết khấu sâu hơn
⚠ Cam kết theo vCPU và bộ nhớ ⚠ resource-based CUD
⚠ Trả tiền dù có dùng hay không ⚠ rủi ro nếu tải giảm
⚠ Áp dụng tự động cho tài nguyên khớp
Cũng có CUD cho ⚠ Cloud SQL, GKE Autopilot, một số dịch vụ khác
⚠ CUD khác SUD thế nào Khác
⚠ SUD (Sustained Use) ⚠ TỰ ĐỘNG, không cam kết gì
⚠ CUD (Committed Use) ⚠ phải CAM KẾT, chiết khấu sâu hơn
SUD áp khi chạy phần lớn tháng
⚠ Kết hợp ⚠ CUD cho phần nền, để phần đột biến hưởng SUD
⚠ Rủi ro của CUD Rủi ro
⚠ Tải giảm nhưng vẫn phải trả
⚠ Đổi loại máy có thể không khớp cam kết
⚠ Cam kết 3 năm là rất dài với công nghệ
Cách giảm rủi ro ⚠ cam kết cho phần TẢI NỀN chắc chắn, không cam kết cho phần đỉnh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải nền chắc chắn là bao nhiêu | ⚠ chỉ cam kết cho phần đó | | Có kế hoạch đổi kiến trúc trong 1–3 năm không | ⚠ có thì cân nhắc kỹ | | Đã right-size máy chưa | ⚠ cam kết cho máy quá to là lãng phí gấp đôi |

Và thứ tự đúng khi tối ưu chi phí: right-size TRƯỚC, cam kết SAU. Mua chiết khấu ba năm cho những máy vốn đã lớn hơn nhu cầu là khoá chặt sự lãng phí đó lại trong ba năm.

Câu 66
As a Language translation app company, you have multiple production systems running on Compute Engine within one Google Cloud Platform (GCP) project. Each system contains its own dedicated Compute Engine instances. How can you determine the total cost of running each system?
  1. A Make sure to label all instances with the name of the system they are running. Then, set up BigQuery billing export and query costs to be charged per label.
  2. B Visualize the costs per system by utilizing the Cost Breakdown section in the Google Cloud Platform Console.
  3. C Add system-specific metadata to all instances, set up Cloud Logging to export logs to BigQuery, and use the metadata to calculate costs through querying.
  4. D It is recommended to assign each virtual machine (VM) a name that corresponds to the system it operates. Additionally, you can establish a usage report export to a Cloud Storage bucket and configure the bucket as a source in BigQuery. This allows you to analyze costs associated with VM names.
Xem giải thích

Đáp án

A — Gắn label cho mọi instance theo tên hệ thống mà nó chạy; sau đó bật xuất dữ liệu billing sang BigQuery và truy vấn chi phí theo label.

Vì sao đúng

Đề cần tách chi phí theo từng hệ thống trong cùng một project.

⚠ Vì sao label là cơ chế đúng:

⚠ Label là cặp khoá–giá trị gắn
  vào tài nguyên
        ↓
⚠ Dữ liệu billing MANG THEO label
        ↓
⚠ Xuất sang BigQuery
        ↓
⚠ GROUP BY label → chi phí từng hệ thống

⚠ Đây là cách chuẩn để phân bổ chi phí khi không thể tách project.

Vì sao các phương án khác sai

  • C (gắn METADATA cho instance, xuất LOG sang BigQuery rồi tính chi phí) — ⚠ bẫy gần nhất: nhưng ⚠ metadata KHÔNG xuất hiện trong dữ liệu billing — chỉ label mới có. ⚠ Và log không chứa thông tin chi phí.

  • D (đặt TÊN VM theo hệ thống, xuất usage report sang bucket rồi nối vào BigQuery) — ⚠ dựa vào quy ước đặt tên: ⚠ mong manh, dễ sai, ⚠ và phức tạp hơn cách dùng label.

  • B (dùng mục Cost Breakdown trên giao diện Console) — ⚠ không đủ chi tiết: ⚠ giao diện phân tích chi phí không tách được theo hệ thống trong cùng project một cách linh hoạt như truy vấn SQL.

Ghi nhớ

⚠ Ba cơ chế gắn nhãn tài nguyên — bảng phải thuộc: | Cơ chế | Xuất hiện trong billing | |---|---| | ⚠ Label | ⚠ CÓ — dùng để phân bổ chi phí | | ⚠ Metadata | ⚠ KHÔNG — chỉ cho ứng dụng đọc | | ⚠ Network tag | ⚠ KHÔNG — dùng cho firewall | | Tên tài nguyên | ⚠ có nhưng không nên dựa vào |

Từ khoá nhận diện:

"phân bổ chi phí theo hệ thống, cùng project" → ⚠ label + billing export "metadata" → ⚠ KHÔNG vào billing "đặt tên theo quy ước" → ⚠ mong manh "xem trên Console" → ⚠ không đủ linh hoạt

⚠ Chiến lược gắn label tốt Chiến lược
⚠ Thống nhất bộ khoá label trong tổ chức ⚠ env, team, system, cost-center
⚠ Bắt buộc gắn label khi tạo tài nguyên ⚠ Organization Policy
⚠ Gắn label bằng Terraform ⚠ không làm tay
Rà tài nguyên thiếu label định kỳ
⚠ Không có label ⚠ chi phí rơi vào "không phân bổ được"
⚠ Vì sao billing export sang BigQuery Lý do
⚠ Truy vấn SQL linh hoạt
⚠ Ghép với dữ liệu nghiệp vụ ⚠ chi phí trên mỗi khách hàng
⚠ Dựng dashboard trong Looker Studio
Lưu lịch sử dài hạn
⚠ Lưu ý ⚠ chỉ có dữ liệu TỪ khi bật export
⚠ Khi nào nên tách PROJECT thay vì dùng label Khi nào
⚠ Cần ranh giới quyền mạnh
⚠ Cần hạn mức riêng
⚠ Cần hoá đơn riêng cho từng đơn vị
Label phù hợp khi ⚠ chia sẻ hạ tầng nhưng cần biết ai tốn bao nhiêu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bao nhiêu phần trăm chi phí không có label | ⚠ chỉ số sức khoẻ của quản trị chi phí | | Label có được gắn tự động khi tạo tài nguyên không | | | Billing export bật từ khi nào | ⚠ không hồi tố dữ liệu cũ |

Và điều nên làm ngay từ ngày đầu dự án cloud: bật billing export và bắt buộc gắn label. Cả hai đều không hồi tố — bật muộn nghĩa là mất vĩnh viễn khả năng phân tích chi phí giai đoạn trước đó.

Câu 67
As a Pet care service company, how can we minimize development effort while building an automated pipeline that deploys our application when the image is updated in Google Container Registry (GCR)?
  1. A Cloud Build can be configured to initiate a Jenkins pipeline by utilizing a custom builder.
  2. B Trigger a Spinnaker pipeline using Cloud Build.
  3. C Leverage Cloud Pub/Sub for initiating a Spinnaker pipeline.
  4. D Utilize Cloud Pub/Sub for the activation of a personalized deployment service that is operational on Google Kubernetes Engine (GKE).
Xem giải thích

Đáp án

C — Dùng Cloud Pub/Sub để kích hoạt pipeline Spinnaker.

Vì sao đúng

Đề cần tự động triển khai khi image được cập nhật trong GCR, với công sức phát triển tối thiểu.

⚠ Vì sao Pub/Sub là cách chuẩn:

⚠ GCR TỰ ĐỘNG publish sự kiện vào
  topic Pub/Sub `gcr`
   → ⚠ khi image được đẩy lên
        ↓
⚠ Spinnaker CÓ SẴN trigger kiểu Pub/Sub
        ↓
⚠ Chỉ cần NỐI hai thứ có sẵn
        ↓
⚠ KHÔNG phải viết code

Vì sao các phương án khác sai

  • B (dùng Cloud Build để kích hoạt pipeline Spinnaker) — ⚠ bẫy gần nhất: làm được nhưng ⚠ thêm một mắt xích không cần thiết, và ⚠ Cloud Build phải được kích hoạt bởi gì đó trước đã.

  • D (dùng Pub/Sub kích hoạt một dịch vụ triển khai TỰ VIẾT chạy trên GKE) — ⚠ nhiều công sức nhất: ⚠ tự viết lại thứ Spinnaker đã có.

  • A (cấu hình Cloud Build khởi động pipeline Jenkins bằng custom builder) — ⚠ thêm cả Jenkins lẫn custom builder: ⚠ nhiều thành phần, nhiều công bảo trì, và ⚠ đề không nhắc gì tới Jenkins.

Ghi nhớ

⚠ Sự kiện tự động từ dịch vụ Google Cloud — bảng phải thuộc: | Nguồn | Topic Pub/Sub | |---|---| | ⚠ Container Registry | ⚠ topic gcr — đề này | | ⚠ Cloud Build | ⚠ topic cloud-builds | | Artifact Registry | ⚠ qua Eventarc | | Cloud Storage | ⚠ thông báo đối tượng qua Pub/Sub | | ⚠ Điểm chung | ⚠ dịch vụ TỰ publish, không cần cấu hình thêm |

Từ khoá nhận diện:

"tự động khi image cập nhật, ít công sức" → ⚠ Pub/Sub topic gcr "tự viết dịch vụ triển khai" → ⚠ nhiều công nhất "thêm Jenkins vào chuỗi" → ⚠ thêm thành phần không cần

⚠ Vì sao dùng sự kiện có sẵn tốt hơn tự dựng Lý do
⚠ Không phải viết và bảo trì code
⚠ Không bỏ sót sự kiện ⚠ dịch vụ tự publish, không phụ thuộc pipeline chạy đúng
⚠ Pub/Sub tự retry
Thêm bên nhận mới chỉ cần thêm subscription
⚠ Mẫu hình GitOps thay thế Mẫu hình
⚠ Image mới → cập nhật manifest trong Git
⚠ Công cụ GitOps đồng bộ về cluster ⚠ Config Sync, Argo CD, Flux
⚠ Trạng thái mong muốn nằm trong Git
Ưu điểm ⚠ lịch sử, rà soát, quay lui bằng git revert
⚠ Đề này ⚠ hỏi cách kích hoạt pipeline nên trả lời theo Pub/Sub
⚠ Lưu ý khi tự động triển khai theo image mới Lưu ý
⚠ Không phải image nào cũng nên tự deploy ⚠ lọc theo tag hoặc repository
⚠ Prod nên có bước duyệt
⚠ Kết hợp Binary Authorization ⚠ chỉ image đã kiểm mới chạy được
Xử lý sự kiện trùng ⚠ Pub/Sub gửi ít nhất một lần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có lọc chỉ triển khai image đúng tag không | ⚠ tránh deploy nhầm image test | | Prod có bước duyệt không | | | Sự kiện trùng có gây triển khai hai lần không | |

Và nguyên tắc thiết kế đáng nhớ: dùng sự kiện mà nền tảng đã phát ra sẵn, đừng tự dựng cơ chế phát hiện. Dịch vụ tự publish thì không bao giờ bỏ sót; cơ chế tự viết thì hỏng lúc nào không biết.

Câu 68
What Google Cloud service can a Cybersecurity software provider use for automated deployment of infrastructure and applications?
  1. A Bigtable is a managed NoSQL database service provided by Google Cloud.
  2. B The managed service for running Kubernetes clusters on Google Cloud is known as Google Kubernetes Engine.
  3. C Storage provided by Google Cloud
  4. D SQL on Google Cloud.
Xem giải thích

Đáp án

B — Google Kubernetes Engine: dịch vụ được quản lý để chạy cụm Kubernetes trên Google Cloud.

Ghi nhớ về chất lượng câu hỏi

⚠ Đề bài và khoá không khớp hoàn toàn.

Phần Nội dung
⚠ Đề hỏi ⚠ "triển khai TỰ ĐỘNG hạ tầng và ứng dụng"
⚠ Khoá ⚠ GKE — nền tảng chạy container

⚠ Theo kiến thức chuẩn, công cụ chuyên cho triển khai tự động là:

  • ⚠ Cloud Build / Cloud Deploy cho CI/CD
  • ⚠ Terraform / Deployment Manager cho hạ tầng dạng mã

⚠ KHÔNG sửa khoá — trong bốn phương án đã cho, GKE là phương án hợp lý duy nhất vì ba cái còn lại là dịch vụ lưu trữ dữ liệu, hoàn toàn không liên quan tới triển khai.

⚠ Mẹo làm bài: khi đề và khoá lệch, loại các phương án sai hiển nhiên rồi chọn cái còn lại.

Vì sao vẫn chọn được B

⚠ GKE có liên quan tới triển khai tự động:

⚠ Kubernetes tự động hoá:
   → ⚠ triển khai (Deployment)
   → ⚠ co giãn (HPA)
   → ⚠ tự phục hồi pod hỏng
   → ⚠ rolling update
        ↓
⚠ Đó là "triển khai tự động" theo
  nghĩa rộng

Vì sao các phương án khác sai

  • A (Bigtable) — ⚠ CSDL NoSQL, không liên quan triển khai.
  • C (Cloud Storage) — ⚠ lưu trữ đối tượng.
  • D (Cloud SQL) — ⚠ CSDL quan hệ.

⚠ Cả ba đều là dịch vụ dữ liệu, không cái nào triển khai được gì.

Ghi nhớ

⚠ Công cụ triển khai tự động trên Google Cloud — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Cloud Build | ⚠ CI: build, test, đóng gói | | ⚠ Cloud Deploy | ⚠ CD: triển khai theo môi trường | | ⚠ Terraform | ⚠ hạ tầng dạng mã — chuẩn ngành | | Config Connector | ⚠ quản lý tài nguyên GCP bằng Kubernetes | | ⚠ GKE | ⚠ NƠI chạy, tự động hoá vận hành container |

Từ khoá nhận diện:

"CI/CD, pipeline triển khai" → ⚠ Cloud Build, Cloud Deploy "hạ tầng dạng mã" → ⚠ Terraform "chạy container, tự phục hồi, co giãn" → ⚠ GKE "Bigtable, Cloud SQL, Cloud Storage" → ⚠ dịch vụ DỮ LIỆU

⚠ Kubernetes tự động hoá những gì Tự động
⚠ Giữ đúng số pod mong muốn
⚠ Khởi động lại pod hỏng
⚠ Rolling update và rollback
⚠ Co giãn theo tải
Cân bằng tải nội bộ
⚠ Nhưng ⚠ vẫn cần CI/CD để ĐƯA mã tới Kubernetes
⚠ Chuỗi công cụ đầy đủ Chuỗi
⚠ Git ⚠ quản lý mã và cấu hình
⚠ Cloud Build ⚠ build image
⚠ Artifact Registry ⚠ lưu image
⚠ Cloud Deploy hoặc GitOps ⚠ triển khai
⚠ GKE ⚠ chạy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang hỏi về NƠI CHẠY hay CÁCH ĐƯA LÊN | ⚠ hai câu hỏi khác nhau | | Hạ tầng có được quản lý bằng mã không | | | Có tự động hoá từ commit tới sản xuất chưa | |

Và điều đáng nhớ dù câu hỏi có vấn đề: GKE tự động hoá VẬN HÀNH container, Cloud Build và Terraform tự động hoá việc ĐƯA thứ đó lên. Hai lớp khác nhau, và một hệ thống hoàn chỉnh cần cả hai.

Câu 69
As a virtual reality game developer company, how can you use Google Cloud Workspaces to monitor your production environment and prevent false alerts from development and staging projects? How can you ensure that you follow the principle of least privilege while granting access to relevant team members?
  1. A To provide necessary access, allow pertinent team members to read all GCP production projects and establish cloud workspaces within each project.
  2. B To set up monitoring for GCP, initiate a fresh monitoring project and establish a Cloud Workspace within it. Connect the production projects to this workspace, and provide appropriate personnel with access to read the Cloud Workspace.
  3. C To ensure proper access, assign the Project Viewer IAM role to the respective team members for all GCP production projects and establish Cloud workspaces within each project.
  4. D Select a pre-existing Google Cloud Platform production project for the monitoring workspace and associate the production projects with it. Provide appropriate team members with read access to the Cloud Workspace.
Xem giải thích

Đáp án

B — Tạo một project giám sát MỚI, lập Cloud Monitoring workspace trong đó, liên kết các project sản xuất vào workspace này, rồi cấp quyền đọc workspace cho những người phù hợp.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án B đáp ứng cả ba:

⚠ Ba yêu cầu:

"giám sát môi trường SẢN XUẤT"
    → ⚠ chỉ liên kết project sản xuất

"tránh cảnh báo GIẢ từ dev và staging"
    → ⚠ KHÔNG liên kết các project đó

"quyền tối thiểu"
    → ⚠ chỉ cấp quyền đọc WORKSPACE
    → ⚠ KHÔNG cấp quyền vào project
      sản xuất

⚠ Điểm mấu chốt: tách workspace ra project riêng cho phép cấp quyền XEM GIÁM SÁT mà không cấp quyền vào chính hệ thống sản xuất.

Vì sao các phương án khác sai

  • D (dùng một project sản xuất SẴN CÓ làm nơi đặt workspace) — ⚠ bẫy gần nhất: hoạt động được, nhưng ⚠ ai xem giám sát cũng phải có quyền trên project sản xuất đó — vi phạm quyền tối thiểu.

  • C (cấp vai trò Project Viewer trên MỌI project sản xuất và lập workspace trong từng project) — ⚠ cấp quyền quá rộng: ⚠ Project Viewer cho xem mọi tài nguyên, không chỉ giám sát.

  • A (cho phép đọc mọi project sản xuất và lập workspace trong từng project) — ⚠ cùng vấn đề, và còn phân mảnh: ⚠ mỗi project một workspace thì không có cái nhìn tổng thể.

Ghi nhớ

⚠ Thiết kế monitoring workspace — bảng phải thuộc: | Nguyên tắc | Nội dung | |---|---| | ⚠ Project riêng cho workspace | ⚠ tách quyền giám sát khỏi quyền hệ thống — đề này | | ⚠ Chỉ liên kết project cùng môi trường | ⚠ prod riêng, dev riêng | | ⚠ Cấp quyền ở mức workspace | ⚠ monitoring.viewer | | Một nơi xem tất cả | ⚠ dashboard tổng hợp |

Từ khoá nhận diện:

"tránh nhiễu từ dev/staging" → ⚠ chỉ liên kết project sản xuất "quyền tối thiểu cho người xem giám sát" → ⚠ project workspace riêng "Project Viewer trên project sản xuất" → ⚠ quá rộng "workspace trong từng project" → ⚠ phân mảnh, không tổng thể

⚠ Vì sao trộn dev vào giám sát prod gây hại Lý do
⚠ Dev hỏng liên tục là chuyện bình thường
⚠ Cảnh báo từ dev làm nhiễu ⚠ người trực bắt đầu bỏ qua
⚠ Bỏ qua rồi thì bỏ qua luôn cảnh báo prod
Nguyên tắc ⚠ cảnh báo prod phải LUÔN đáng tin
⚠ Vai trò Monitoring — bảng phải thuộc Vai trò
⚠ monitoring.viewer ⚠ xem chỉ số và dashboard
monitoring.editor ⚠ tạo dashboard, cảnh báo
monitoring.admin ⚠ toàn quyền
⚠ Nguyên tắc ⚠ người xem dashboard chỉ cần viewer
⚠ Lưu ý về Monitoring workspace Lưu ý
⚠ Một workspace liên kết nhiều project
⚠ Project chỉ thuộc MỘT workspace
⚠ Quyền được đánh giá ở project chứa workspace
Nay gọi là ⚠ "metrics scope" trong tài liệu mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người xem dashboard có quyền gì trên project prod | ⚠ lý tưởng là không có gì | | Có project dev nào lọt vào workspace prod không | | | Cảnh báo prod có bị nhiễu không | ⚠ đếm số cảnh báo giả mỗi tuần |

Và lợi ích ít ai để ý của việc tách workspace ra project riêng: bạn có thể cho lãnh đạo và bên liên quan xem tình trạng hệ thống mà không cấp cho họ bất kỳ quyền nào trên hệ thống thật.

Câu 70
You support a Node.js application running on Google Kubernetes Engine (GKE) in production. The application makes several HTTP requests to dependent applications. You want to anticipate which dependent applications might cause performance issues. What should you do?
  1. A Instrument all applications with Observability Profiler.
  2. B Instrument all applications with Observability Trace and review inter-service HTTP requests.
  3. C Use Observability Debugger to review the execution of logic within each application to instrument all applications.
  4. D Modify the Node.js application to log HTTP request and response times to dependent applications. Use Observability Logging to find dependent applications that are performing poorly.
Xem giải thích

🧩 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 hỗ trợ một ứng dụng Node.js đang chạy trên Google Kubernetes Engine (GKE) trong môi trường production. Ứng dụng này thực hiện nhiều HTTP requests đến các dependent applications (các ứng dụng phụ thuộc). Mục tiêu là dự đoán trước (anticipate) những ứng dụng phụ thuộc nào có thể gây ra vấn đề hiệu suất (performance issues).

🛠️ Bối cảnh chính: Trong hệ thống microservices trên GKE, các HTTP requests giữa các service có thể gây độ trễ (latency), dẫn đến bottleneck. Cần một công cụ Observability của Google Cloud để theo dõi và phân tích inter-service communication mà không cần thay đổi code lớn, giúp phát hiện sớm các service chậm.

📘 Kiến thức liên quan (cập nhật đến 2026): Google Cloud Observability (trước đây là Stackdriver) bao gồm các công cụ như Cloud Trace (cho distributed tracing), Profiler, Debugger, và Logging. Phiên bản mới nhất nhấn mạnh OpenTelemetry cho instrumentation tự động trên GKE, hỗ trợ Node.js qua agent tự động (Auto-instrumentation) để trace HTTP requests mà không cần code thủ công.

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

Đáp án đúng: Instrument all applications with Observability Trace and review inter-service HTTP requests.

Lý do:

  • Observability Trace (dựa trên Cloud Trace) là công cụ lý tưởng để theo dõi distributed traces cho các HTTP requests giữa các service. Nó tự động thu thập span (đoạn trace) cho từng request, hiển thị latency, error rate, và dependency graph, giúp dự đoán service nào chậm (ví dụ: p95 latency cao).
  • Trên GKE, chỉ cần enable Cloud Trace agent hoặc OpenTelemetry Collector để instrument toàn bộ ứng dụng (bao gồm Node.js), không cần modify code. Review traces sẽ hiển thị rõ inter-service HTTP requests và bottleneck.
  • Điều này phù hợp nhất với yêu cầu anticipate performance issues từ dependent apps, theo best practice DevOps trên Google Cloud.

Nguồn tham khảo:

📋 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 tiếng Anh. Mỗi phương án được đánh giá với emoji và lý do chi tiết bằng tiếng Việt:

  • Instrument all applications with Observability Profiler.
    ❌ Sai: Observability Profiler (Cloud Profiler) dùng để phân tích CPU và memory usage trong code (sampling profiles), không theo dõi HTTP requests giữa services. Nó không giúp dự đoán latency từ dependent apps, chỉ phù hợp debug nội bộ ứng dụng, không phải inter-service.

  • Instrument all applications with Observability Trace and review inter-service HTTP requests.
    ✅ Đúng: Như đã giải thích ở trên, đây là lựa chọn tối ưu để trace toàn bộ HTTP chain, phát hiện service chậm qua trace waterfalls và metrics tự động trên GKE.

  • Use Observability Debugger to review the execution of logic within each application to instrument all applications.
    ❌ Sai: Observability Debugger (Cloud Debugger) dùng để snapshot code execution tại breakpoint mà không dừng app, chủ yếu debug logic nội bộ. Nó không trace HTTP requests giữa services, và không dùng để "instrument" (thêm monitoring) – debugger chỉ hỗ trợ production debugging, không dự đoán performance inter-service.

  • Modify the Node.js application to log HTTP request and response times to dependent applications. Use Observability Logging to find dependent applications that are performing poorly.
    ❌ Sai: Phương án này yêu cầu thay đổi code (modify Node.js để log thủ công), vi phạm nguyên tắc zero-code-change instrumentation trên GKE. Observability Logging (Cloud Logging) chỉ thu thập logs, khó phân tích distributed requests (không có correlation ID tự động như Trace), và không hiệu quả để anticipate issues quy mô lớn.

🧠 Kết luận: Sử dụng Trace là best practice DevOps cho microservices trên GKE, giúp proactive monitoring và giảm MTTR (Mean Time To Resolution). Nếu triển khai, khuyến nghị enable Google Cloud Operations Suite trên cluster! 🚀