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

Tìm thấy 269 câu.

Câu 11
You are managing an application that exposes an HTTP endpoint without using a load balancer. The latency of the HTTP responses is important for the user experience. You want to understand what HTTP latencies all of your users are experiencing. You use Stackdriver Monitoring. What should you do?
  1. A ג€¢ In your application, create a metric with a metricKind set to DELTA and a valueType set to DOUBLE. ג€¢ In Stackdriver's Metrics Explorer, use a Stacked Bar graph to visualize the metric.
  2. B ג€¢ In your application, create a metric with a metricKind set to CUMULATIVE and a valueType set to DOUBLE. ג€¢ In Stackdriver's Metrics Explorer, use a Line graph to visualize the metric.
  3. C ג€¢ In your application, create a metric with a metricKind set to GAUGE and a valueType set to DISTRIBUTION. ג€¢ In Stackdriver's Metrics Explorer, use a Heatmap graph to visualize the metric.
  4. D ג€¢ In your application, create a metric with a metricKind set to METRIC_KIND_UNSPECIFIED and a valueType set to INT64. ג€¢ In Stackdriver's Metrics Explorer, use a Stacked Area graph to visualize the metric.
Xem giải thích

Đáp án

C — Tạo chỉ số với metricKind là GAUGE và valueType là DISTRIBUTION

Vì sao đúng

Hai thuộc tính này quyết định chỉ số mô tả điều gì:

  • GAUGE — giá trị đo tại một thời điểm, đúng bản chất của độ trễ: mỗi phản hồi có một độ trễ riêng, không phải con số cộng dồn.
  • DISTRIBUTION — lưu phân bố thay vì một con số. Đây mới là điểm quan trọng: với độ trễ, giá trị trung bình che mất phần đuôi, mà phần đuôi mới là thứ người dùng cảm nhận. Distribution cho tính phân vị p50, p95, p99.

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

  • A. DELTA với DOUBLE — DELTA đo mức thay đổi trong một khoảng, hợp cho bộ đếm chứ không hợp cho độ trễ; và một số DOUBLE thì mất hết thông tin phân bố.
  • B. CUMULATIVE — giá trị cộng dồn từ một mốc, dùng cho tổng số yêu cầu chứ không cho độ trễ.
  • D. METRIC_KIND_UNSPECIFIED — giá trị mặc định chưa khai, không hợp lệ khi tạo chỉ số.
Câu 12
You are using Stackdriver to monitor applications hosted on Google Cloud Platform (GCP). You recently deployed a new application, but its logs are not appearing on the Stackdriver dashboard.
You need to troubleshoot the issue. What should you do?
  1. A Confirm that the Stackdriver agent has been installed in the hosting virtual machine.
  2. B Confirm that your account has the proper permissions to use the Stackdriver dashboard.
  3. C Confirm that port 25 has been opened in the firewall to allow messages through to Stackdriver.
  4. D Confirm that the application is using the required client library and the service account key has proper permissions.
Xem giải thích

Đáp án

A — Xác nhận agent đã được cài trên máy ảo đang chạy ứng dụng

Vì sao đúng

Ứng dụng vừa triển khai mà log không lên là tình huống soát lỗi cơ bản, và nguyên nhân thường gặp nhất là agent chưa được cài trên máy mới. Log của Compute Engine không tự chảy về; phải có agent thu và đẩy đi. Kiểm tra điều này trước vì nó rẻ nhất và loại được nguyên nhân phổ biến nhất.

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

  • B. Kiểm quyền tài khoản của bạn — nếu thiếu quyền thì bạn sẽ không thấy log của mọi ứng dụng, không riêng ứng dụng mới.
  • C. Mở cổng 25 trên tường lửa — cổng 25 dành cho SMTP, hoàn toàn không liên quan tới việc gửi log.
  • D. Kiểm thư viện và tài khoản dịch vụ — có thể là nguyên nhân, nhưng đứng sau việc xác nhận agent tồn tại.
Câu 13
You are working with a government agency that requires you to archive application logs for seven years. You need to configure Stackdriver to export and store the logs while minimizing costs of storage. What should you do?
  1. A Create a Cloud Storage bucket and develop your application to send logs directly to the bucket.
  2. B Develop an App Engine application that pulls the logs from Stackdriver and saves them in BigQuery.
  3. C Create an export in Stackdriver and configure Cloud Pub/Sub to store logs in permanent storage for seven years.
  4. D Create a sink in Stackdriver, name it, create a bucket on Cloud Storage for storing archived logs, and then select the bucket as the log export destination.
Xem giải thích

Đáp án

D — Tạo sink trong Cloud Logging, đặt tên, và trỏ tới một bucket Cloud Storage

Vì sao đúng

Lưu trữ log bảy năm vượt xa thời hạn giữ mặc định của Cloud Logging, nên phải xuất ra nơi lưu trữ lâu dài. Sink là cơ chế chính thức: khai bộ lọc chọn log cần giữ và trỏ đích tới bucket Cloud Storage. Từ đó áp chính sách vòng đời để chuyển sang lớp lưu trữ nguội cho rẻ, và bật khoá lưu giữ nếu quy định đòi dữ liệu không được xoá hay sửa.

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

  • A. Sửa ứng dụng để ghi thẳng vào Cloud Storage — bỏ qua toàn bộ hệ thống log, mất khả năng tìm kiếm và phải sửa mọi ứng dụng.
  • B. Viết ứng dụng App Engine kéo log về — tự dựng lại thứ sink làm sẵn, và phải nuôi thêm một dịch vụ.
  • C. Xuất qua Cloud Pub/Sub để lưu trữ — Pub/Sub là kênh truyền thông điệp, không phải nơi lưu trữ; nó chỉ giữ thông điệp trong thời gian ngắn.
Câu 14
You support a trading application written in Python and hosted on App Engine flexible environment. You want to customize the error information being sent to
Stackdriver Error Reporting. What should you do?
  1. A Install the Stackdriver Error Reporting library for Python, and then run your code on a Compute Engine VM.
  2. B Install the Stackdriver Error Reporting library for Python, and then run your code on Google Kubernetes Engine.
  3. C Install the Stackdriver Error Reporting library for Python, and then run your code on App Engine flexible environment.
  4. D Use the Stackdriver Error Reporting API to write errors from your application to ReportedErrorEvent, and then generate log entries with properly formatted error messages in Stackdriver Logging.
Xem giải thích

Đáp án

D — Dùng API của Error Reporting để ghi lỗi thẳng từ ứng dụng

Vì sao đúng

Đề cần tuỳ biến thông tin lỗi gửi đi. Gọi thẳng API cho bạn toàn quyền quyết định nội dung báo cáo: thông điệp, ngăn xếp lời gọi, ngữ cảnh người dùng, mã phiên bản dịch vụ. Thư viện tự động chỉ bắt ngoại lệ chưa xử lý theo khuôn mặc định, không chèn thêm được ngữ cảnh riêng của ứng dụng giao dịch.

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

Cả ba phương án còn lại đều dừng ở việc cài thư viện và chạy theo cách mặc định — chúng gom được lỗi nhưng không cho bạn định hình nội dung, đúng thứ đề yêu cầu.

Câu 15
You are running an application on Compute Engine and collecting logs through Stackdriver. You discover that some personally identifiable information (PII) is leaking into certain log entry fields. You want to prevent these fields from being written in new log entries as quickly as possible. What should you do?
  1. A Use the filter-record-transformer Fluentd filter plugin to remove the fields from the log entries in flight.
  2. B Use the fluent-plugin-record-reformer Fluentd output plugin to remove the fields from the log entries in flight.
  3. C Wait for the application developers to patch the application, and then verify that the log entries are no longer exposing PII.
  4. D Stage log entries to Cloud Storage, and then trigger a Cloud Function to remove the fields and write the entries to Stackdriver via the Stackdriver Logging API.
Xem giải thích

Đáp án

A — Dùng plugin lọc filter-record-transformer của Fluentd để bỏ trường chứa thông tin cá nhân

Vì sao đúng

Nguyên tắc với dữ liệu nhạy cảm là chặn ở khâu sớm nhất. filter-record-transformer là plugin lọc, chạy ngay trong agent trước khi bản ghi được gửi đi, nên thông tin cá nhân không bao giờ rời khỏi máy ảo và không bao giờ được ghi vào hệ thống log.

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

  • B. Dùng plugin record-reformer — đây là plugin output, nó định dạng lại bản ghi ở khâu gửi đi; dùng để lọc dữ liệu nhạy cảm là sai vai và dễ sót.
  • C. Chờ lập trình viên vá ứng dụng — trong lúc chờ thì dữ liệu vẫn rò ra mỗi giây.
  • D. Đưa log qua Cloud Storage rồi dùng Cloud Function dọn — đã muộn: dữ liệu đã được ghi, đã nhân bản và đã vào bản sao lưu.
Câu 16 Chọn nhiều đáp án
You support a service with a well-defined Service Level Objective (SLO). Over the previous 6 months, your service has consistently met its SLO and customer satisfaction has been consistently high. Most of your service's operations tasks are automated and few repetitive tasks occur frequently. You want to optimize the balance between reliability and deployment velocity while following site reliability engineering best practices. What should you do? (Choose two.)
  1. A Make the service's SLO more strict.
  2. B Increase the service's deployment velocity and/or risk.
  3. C Shift engineering time to other services that need more reliability.
  4. D Get the product team to prioritize reliability work over new features.
  5. E Change the implementation of your Service Level Indicators (SLIs) to increase coverage.
Xem giải thích

Đáp án

B và C — tăng tốc độ triển khai hoặc chấp nhận thêm rủi ro, và chuyển thời gian kỹ thuật sang dịch vụ khác

Vì sao đúng

Ý tưởng cốt lõi của ngân sách lỗi: SLO không phải mục tiêu "càng cao càng tốt" mà là mức tin cậy vừa đủ cho người dùng. Liên tục vượt xa SLO trong sáu tháng nghĩa là bạn đang trả giá quá nhiều cho độ tin cậy — ngân sách lỗi chưa dùng hết là tài nguyên bị bỏ phí.

  • B. Dùng ngân sách đó để đẩy nhanh nhịp phát hành, thử nghiệm nhiều hơn.
  • C. Chuyển công sức sang những dịch vụ đang thực sự thiếu độ tin cậy.

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

  • A. Siết SLO chặt hơn — nghe hợp lý nhưng SLO phải bám theo kỳ vọng của người dùng, mà đề nói khách đang hài lòng; siết thêm chỉ tự tạo áp lực không ai cần.
  • D. Ưu tiên việc độ tin cậy hơn tính năng mới — ngược hẳn tín hiệu mà dữ liệu đang cho.
  • E. Đổi cách tính SLI để con số đẹp hơn — sửa thước đo thay vì sửa thực tế.
Câu 17
You manage an application that runs in Google Kubernetes Engine (GKE) and uses the blue/green deployment methodology. Extracts of the Kubernetes manifests are shown below:



The Deployment app-green was updated to use the new version of the application. During post-deployment monitoring, you notice that the majority of user requests are failing. You did not observe this behavior in the testing environment. You need to mitigate the incident impact on users and enable the developers to troubleshoot the issue. What should you do?
  1. A Update the Deployment app-blue to use the new version of the application.
  2. B Update the Deployment app-green to use the previous version of the application.
  3. C Change the selector on the Service app-svc to app: my-app.
  4. D Change the selector on the Service app-svc to app: my-app, version: blue.
Xem giải thích

Đáp án

D — Đổi selector của Service app-svc thành app: my-app, version: blue

Vì sao đúng

Trong triển khai xanh–lam trên Kubernetes, Service là công tắc chuyển lưu lượng. Hai Deployment cùng tồn tại với nhãn phiên bản khác nhau; Service trỏ tới nhóm nào là lưu lượng đi vào nhóm đó. Muốn quay về bản cũ thì chỉ cần sửa selector trỏ về version: blue — chuyển đổi tức thì, không phải build lại hay chờ pod khởi động.

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

  • A và B. Sửa Deployment — kích hoạt một đợt cập nhật pod, mất thời gian và mất luôn ưu điểm quay lui tức thì của mô hình xanh–lam.
  • C. Selector chỉ có app: my-app — khớp cả hai phiên bản, nên lưu lượng chia đôi giữa bản cũ và bản mới; đúng thứ cần tránh khi đang muốn quay lui.
Câu 18
You use Terraform to manage an application deployed to a Google Cloud environment. The application runs on instances deployed by a managed instance group. The Terraform code is deployed by using a CI/CD pipeline. When you change the machine type on the instance template used by the managed instance group, the pipeline fails at the terraform apply stage with the following error message:



You need to update the instance template and minimize disruption to the application and the number of pipeline runs.

What should you do?
  1. A Delete the managed instance group, and recreate it after updating the instance template.
  2. B Add a new instance template, update the managed instance group to use the new instance template, and delete the old instance template.
  3. C Remove the managed instance group from the Terraform state file, update the instance template, and reimport the managed instance group.
  4. D Set the create_before_destroy meta-argument to true in the lifecycle block on the instance template.
Xem giải thích

Đáp án

D — Đặt create_before_destroy = true trong khối lifecycle

Vì sao đúng

Mặc định Terraform huỷ trước rồi tạo sau khi phải thay thế một tài nguyên. Với instance template đang được managed instance group tham chiếu, thứ tự đó gây hai vấn đề: template không xoá được vì còn bị tham chiếu, và nếu xoá được thì có khoảng thời gian nhóm không có template.

create_before_destroy đảo thứ tự: tạo template mới trước, cập nhật tham chiếu, rồi mới xoá template cũ. Nhờ vậy thay đổi diễn ra không gián đoạn.

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

  • A. Xoá nhóm rồi tạo lại — gây gián đoạn dịch vụ, hoàn toàn không cần thiết.
  • B. Thêm template mới rồi cập nhật thủ công — làm ngoài Terraform khiến state lệch khỏi thực tế.
  • C. Gỡ nhóm khỏi state file — Terraform mất dấu tài nguyên, lần chạy sau sẽ tạo trùng.
Câu 19
Your company runs an ecommerce business. The application responsible for payment processing has structured JSON logging with the following schema:



Capture and access of logs from the payment processing application is mandatory for operations, but the jsonPayload.user_email field contains personally identifiable information (PII). Your security team does not want the entire engineering team to have access to PII. You need to stop exposing PII to the engineering team and restrict access to security team members only. What should you do?
  1. A Apply the conditional role binding resource.name.extract("locations/global/buckets/{bucket}/") == "_Default" to the _Default bucket.
  2. B Apply a jsonPayload.user_email restricted field to the _Default bucket. Grant the Log Field Accessor role to the security team members.
  3. C Apply a jsonPayload.user_email exclusion filter to the _Default bucket.
  4. D Modify the application to toggle inclusion of user_email when the LOG_USER_EMAIL environment variable is set to true. Restrict the engineering team members who can change the production environment variable by using the CODEOWNERS file.
Xem giải thích

Đáp án

B — Đặt jsonPayload.user_email làm trường hạn chế trên bucket _Default, rồi cấp quyền riêng

Vì sao đúng

Trường hạn chế (restricted field) là cơ chế của Cloud Logging cho phép giữ lại dữ liệu nhưng che khỏi phần lớn người xem. Trường được đánh dấu sẽ không hiện với người chỉ có quyền xem log thông thường; chỉ ai được cấp quyền riêng mới đọc được. Nhờ vậy thoả cả hai vế: log vẫn đầy đủ cho điều tra sự cố, mà thông tin cá nhân không phơi ra cho cả đội.

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

  • C. Dùng exclusion filter — loại bỏ hẳn trường khỏi log, nên mất luôn dữ liệu cần khi điều tra.
  • D. Sửa ứng dụng để bật tắt việc ghi trường đó — đẩy quyết định bảo mật vào mã ứng dụng, và khi tắt thì cũng mất dữ liệu.
  • A. Ràng buộc vai theo điều kiện tên tài nguyên — kiểm soát ở mức tài nguyên, không lọc được tới từng trường bên trong bản ghi log.
Câu 20
As an AI-powered chatbot service company, what are the two sections that you need to include in your postmortem report after a major incident that affected your users, in order to prevent similar incidents from happening in the future using Google Cloud Services?
  1. A Can you provide your assessment of the severity of the incident in comparison to previous incidents? Additionally, can you share design documentations for all the affected services during the incident?
  2. B A description of the underlying reason behind the occurrence.
  3. C A roster of individuals accountable for the occurrence of the event.
  4. D A checklist of measures to avoid the repetition of the event.
Xem giải thích

Đáp án

B — Mô tả nguyên nhân gốc rễ đằng sau sự cố.

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

⚠ Đề bài hỏi "HAI mục" (two sections) nhưng bộ đề chỉ đánh dấu MỘT phương án đúng.

⚠ Theo thực hành SRE chuẩn, báo cáo hậu sự cố (postmortem) cần CẢ HAI:

Mục Phương án
⚠ Mô tả NGUYÊN NHÂN GỐC ⚠ B — được đánh dấu đúng
⚠ Danh sách HÀNH ĐỘNG phòng ngừa ⚠ D — theo chuẩn cũng đúng, nhưng bộ đề không đánh dấu

⚠ KHÔNG sửa khoá — ghi chú để người ôn biết. Khi làm bài, nếu đề cho chọn nhiều thì chọn B và D; nếu hệ thống chỉ cho chọn một thì chọn B.

⚠ Phương án C là bẫy quan trọng nhất và luôn SAI: danh sách người chịu trách nhiệm — trái với nguyên tắc blameless postmortem.

Vì sao đúng

⚠ Vì sao nguyên nhân gốc là mục bắt buộc:

⚠ Không hiểu vì sao xảy ra
        ↓
⚠ Không ngăn được lần sau
        ↓
⚠ Sự cố lặp lại

⚠ Nguyên nhân gốc phải đi tới lỗi hệ thống, không dừng ở "người X bấm nhầm".

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

  • D (danh sách biện pháp tránh lặp lại) — ⚠ thực tế ĐÚNG theo chuẩn SRE, nhưng bộ đề không đánh dấu. Xem ghi chú chất lượng ở trên.

  • C (danh sách cá nhân chịu trách nhiệm cho sự cố) — ⚠ VI PHẠM nguyên tắc blameless: quy trách nhiệm cá nhân khiến người ta giấu sự cố lần sau.

  • A (đánh giá mức nghiêm trọng so với sự cố trước và tài liệu thiết kế mọi dịch vụ bị ảnh hưởng) — ⚠ tài liệu thiết kế không thuộc báo cáo hậu sự cố; nó là tài liệu tham khảo riêng.

Ghi nhớ

⚠ Các mục của một postmortem chuẩn — bảng phải thuộc: | Mục | Nội dung | |---|---| | Tóm tắt | ⚠ chuyện gì xảy ra, kéo dài bao lâu | | Tác động | ⚠ bao nhiêu người dùng, thiệt hại | | ⚠ Nguyên nhân gốc | ⚠ bắt buộc — đề này | | ⚠ Dòng thời gian | ⚠ phát hiện, phản ứng, khắc phục | | Bài học | ⚠ cái gì tốt, cái gì may mắn, cái gì tệ | | ⚠ Hành động phòng ngừa | ⚠ có chủ sở hữu và hạn |

Từ khoá nhận diện:

"nguyên nhân gốc, hành động phòng ngừa" → ⚠ mục bắt buộc "danh sách người chịu trách nhiệm" → ⚠ VI PHẠM blameless — luôn SAI "tài liệu thiết kế" → ⚠ không thuộc postmortem

⚠ Blameless postmortem — nguyên tắc cốt lõi Nguyên tắc
⚠ Tập trung vào 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 điều đó xảy ra" ⚠ không hỏi "ai làm sai"
⚠ Quy trách nhiệm → người ta GIẤU sự cố ⚠ hậu quả tệ nhất
Kết quả ⚠ văn hoá báo cáo trung thực, học được nhiều hơn
⚠ Hành động phòng ngừa phải thế nào Phải
⚠ Có MỘT chủ sở hữu ⚠ không phải "cả đội"
⚠ Có hạn hoàn thành
⚠ Được theo dõi tới khi xong
Ưu tiên theo mức giảm rủi ro
⚠ Không theo dõi ⚠ postmortem thành bài viết không ai đọc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguyên nhân gốc có dừng ở "người X" không | ⚠ phải đi tiếp tới lỗi hệ thống | | Hành động có chủ sở hữu và hạn chưa | | | Postmortem có được chia sẻ rộng không | ⚠ giấu đi thì đội khác không học được |

Và câu hỏi kiểm tra một postmortem có blameless thật không: nếu người gây ra sự cố đọc bản báo cáo, họ có thấy mình bị buộc tội không? Có thì lần sau họ sẽ không báo cáo nữa.