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

Tìm thấy 269 câu.

Câu 21
As a Virtual event platform company, how can you integrate a third-party monitoring platform with a HTTP POST of the build information to a webhook to your multiple step Cloud Build pipeline for building and deploying your application to Google Kubernetes Engine (GKE) using the Google Cloud Services?
  1. A Set up a Cloud Pub/Sub push subscription that will HTTP POST the build details to a webhook for the cloud-builds PubSub topic in Cloud Build.
  2. B To generate a logs-based metric from the Cloud Build logs, employ Cloud Logging. Set up an Alert that uses a Webhook notification type.
  3. C For each step in Cloud Build, implement logic to send the build information to a webhook via HTTP POST.
  4. D Incorporate an additional task to the Cloud Build pipeline that sends the build details to a webhook using HTTP POST method.
Xem giải thích

Đáp án

A — Thiết lập một Cloud Pub/Sub push subscription gửi HTTP POST thông tin build tới webhook, đăng ký trên topic cloud-builds của Cloud Build.

Vì sao đúng

Cloud Build tự động publish sự kiện build vào topic Pub/Sub tên cloud-builds. Chỉ cần đăng ký nhận từ đó.

⚠ Luồng hoạt động:

⚠ Cloud Build chạy pipeline
        ↓
⚠ TỰ ĐỘNG publish trạng thái vào
  topic `cloud-builds`
        ↓
⚠ Push subscription HTTP POST
  tới webhook bên thứ ba
        ↓
⚠ KHÔNG phải sửa pipeline

⚠ Vì sao đây là cách đúng:

⚠ Không xâm lấn pipeline
⚠ Bắt được MỌI trạng thái
   → thành công, thất bại, huỷ
⚠ Pub/Sub tự retry khi webhook lỗi
⚠ Thêm bên nhận mới chỉ cần thêm
  subscription

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

  • D (thêm một bước vào pipeline để POST thông tin build) — ⚠ bẫy mạnh nhất và là cách nhiều người tự nghĩ ra. Nhưng ⚠ bước thêm chỉ chạy khi pipeline chạy tới đó — nếu build THẤT BẠI ở bước trước thì webhook không bao giờ được gọi. Đó chính là lúc cần thông báo nhất.

  • C (thêm logic vào TỪNG bước để POST) — ⚠ tệ hơn nữa: trùng lặp code ở mọi bước, khó bảo trì.

  • B (tạo logs-based metric rồi đặt Alert với kênh Webhook) — ⚠ vòng vèo và mất thông tin: cảnh báo dựa trên chỉ số chỉ báo có sự kiện, ⚠ không mang theo chi tiết build.

Ghi nhớ

⚠ Cách nhận thông báo từ Cloud Build — bảng phải thuộc: | Cách | Ưu / nhược | |---|---| | ⚠ Pub/Sub topic cloud-builds | ⚠ chuẩn, bắt mọi trạng thái — đề này | | Bước trong pipeline | ⚠ KHÔNG chạy khi build hỏng trước đó | | Logs-based metric + Alert | ⚠ mất chi tiết build | | Cloud Build notifiers | ⚠ giải pháp đóng gói sẵn trên nền Pub/Sub |

Từ khoá nhận diện:

"nhận thông báo build, tích hợp bên thứ ba" → ⚠ Pub/Sub topic cloud-builds "thêm bước vào pipeline" → ⚠ không bắt được build thất bại "logs-based metric" → ⚠ mất chi tiết

⚠ Push subscription khác Pull Khác
⚠ PUSH: Pub/Sub gọi endpoint của bạn ⚠ hợp với webhook — đề này
⚠ PULL: dịch vụ của bạn tự lấy ⚠ hợp khi cần kiểm soát tốc độ xử lý
Push cần ⚠ endpoint HTTPS công khai và xác thực
⚠ Push tự retry ⚠ theo backoff luỹ thừa
⚠ Vì sao "thêm bước" là bẫy kinh điển Lý do
⚠ Build hỏng ở bước 2 thì bước 5 không chạy
⚠ Không thông báo được chính lúc cần nhất
⚠ Phải sửa mọi pipeline khi thêm bên nhận
Nguyên tắc ⚠ thông báo về pipeline nên nằm NGOÀI pipeline
⚠ Bảo mật cho webhook Bảo mật
⚠ Xác thực push subscription ⚠ OIDC token
⚠ Xác minh chữ ký ở phía nhận
⚠ Endpoint phải HTTPS
Xử lý trùng lặp ⚠ Pub/Sub đảm bảo ít nhất một lần, có thể gửi lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Build THẤT BẠI có gửi webhook không | ⚠ thử làm hỏng build có chủ ý | | Webhook có xác thực không | | | Xử lý được thông báo trùng chưa | ⚠ Pub/Sub có thể gửi lại |

Và nguyên tắc kiến trúc rút ra: cơ chế thông báo về một hệ thống không nên phụ thuộc vào việc hệ thống đó chạy đúng. Đặt thông báo bên trong pipeline là vi phạm chính nguyên tắc đó.

Câu 22
As a virtual interior design service company, you want to implement Site Reliability Engineering (SRE) culture and principles. One of your services experienced a limited outage and a manager from a different team requests a detailed report of the incident to implement remediations. What is the best way to respond to this request using Google Cloud Services?
  1. A Create a post-incident analysis report that covers the underlying issues, solutions, takeaways, the accountable individuals' names, and a record of tasks for each individual. Publish it on the engineering team's documentation platform.
  2. B Prepare a post-incident analysis report that encompasses the underlying reasons, fixes, takeaways, and a list of measures to be taken in order of importance. Share the report solely with the manager.
  3. C Create a post-incident analysis report that encompasses the underlying reasons, solutions, knowledge gained, and a ranked inventory of to-do items. Disseminate it on the engineering team's documentation platform.
  4. D Prepare a post-incident analysis report that covers the underlying causes, remedies, takeaways, individuals accountable, and actionable steps for each person involved. Limit the access of this report to the manager alone.
Xem giải thích

Đáp án

C — Lập báo cáo hậu sự cố gồm nguyên nhân gốc, giải pháp, bài học rút ra và danh sách hành động được xếp thứ tự ưu tiên; rồi công bố trên nền tảng tài liệu của đội kỹ thuật.

Vì sao đúng

Có hai quyết định trong câu này, và phương án C đúng cả hai:

⚠ Quyết định 1 — NỘI DUNG:

⚠ Nguyên nhân gốc
⚠ Giải pháp
⚠ Bài học
⚠ Danh sách hành động có ưu tiên
        ↓
⚠ KHÔNG có "danh sách người
  chịu trách nhiệm"

⚠ Quyết định 2 — PHẠM VI CHIA SẺ:

⚠ Công bố RỘNG trên nền tảng
  tài liệu đội kỹ thuật
        ↓
⚠ Không chỉ gửi riêng cho quản lý

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

  • B (nội dung đúng nhưng CHỈ chia sẻ với quản lý) — ⚠ bẫy tinh vi nhất: nội dung hoàn toàn ổn, ⚠ sai ở phạm vi. Giấu postmortem là bỏ mất giá trị lớn nhất — đội khác không học được.

  • A và D (đều có "danh sách cá nhân chịu trách nhiệm") — ⚠ VI PHẠM nguyên tắc blameless. ⚠ D còn giới hạn chỉ cho quản lý — sai kép.

⚠ Mẹo chấm: loại theo hai trục — có quy trách nhiệm cá nhân không, và có chia sẻ rộng không.

Ghi nhớ

⚠ Hai nguyên tắc của postmortem SRE — bảng phải thuộc: | Nguyên tắc | Nội dung | |---|---| | ⚠ BLAMELESS | ⚠ tập trung hệ thống, không nêu tên buộc tội | | ⚠ CHIA SẺ RỘNG | ⚠ để cả tổ chức học được |

Từ khoá nhận diện:

"nguyên nhân, giải pháp, bài học, hành động ưu tiên + công bố rộng" → ⚠ đúng chuẩn "danh sách người chịu trách nhiệm" → ⚠ luôn SAI "chỉ gửi cho quản lý" → ⚠ bỏ mất giá trị học tập

⚠ Vì sao chia sẻ rộng quan trọng Lý do
⚠ Đội khác có thể có lỗi tương tự
⚠ Người mới học được từ sự cố cũ
⚠ Xây văn hoá minh bạch
⚠ Tránh lặp lại cùng sai lầm ở nơi khác
Google nổi tiếng với ⚠ kho postmortem nội bộ ai cũng đọc được
⚠ Hành động có thứ tự ƯU TIÊN — vì sao Lý do
⚠ Không phải hành động nào cũng ngang nhau
⚠ Nguồn lực có hạn
⚠ Ưu tiên theo mức GIẢM RỦI RO
Có hạn và chủ sở hữu rõ ràng
⚠ Không ưu tiên ⚠ làm hết những cái dễ, bỏ cái quan trọng
⚠ Blameless không có nghĩa là không ai chịu trách nhiệm Phân biệt
⚠ KHÔNG buộc tội người gây ra sự cố
⚠ NHƯNG hành động khắc phục PHẢI có chủ sở hữu
⚠ Trách nhiệm là VỀ VIỆC SỬA, không phải về việc GÂY RA
Đây là điểm nhiều người hiểu nhầm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Postmortem có nêu tên buộc tội ai không | | | Ai đọc được báo cáo | ⚠ càng rộng càng tốt | | Hành động có được theo dõi tới khi xong không | |

Và giá trị thật của postmortem không nằm ở bản báo cáo, mà ở việc người khác đọc nó trước khi mắc cùng lỗi. Báo cáo hay mà cất trong hộp thư của một quản lý thì gần như vô dụng.

Câu 23
As a cybersecurity training and certification company, you are using a custom Debian image to run an application in a virtual machine (VM) on Google Cloud. The image has the Cloud Logging agent installed, and the VM has the cloud-platform scope. However, you are unable to see syslog in the "All logs" dropdown list of the Logs Viewer in Cloud Logging. What should be your initial action?
  1. A In order to find the agent's test log entry, you should check the Logs Viewer.
  2. B Access the VM via SSH and run the following command on it: ps ax | grep fluentd.
  3. C The Cloud agent should be installed in its latest version.
  4. D Ensure that the monitoring.write scope is included in the access scope of the VM service account.
Xem giải thích

Đáp án

B — Truy cập VM qua SSH và chạy lệnh ps ax | grep fluentd.

Vì sao đúng

Đề nêu rõ hai điều kiện đã đúng: agent đã cài và VM có scope cloud-platform. Vậy bước tiếp theo là kiểm tra agent có ĐANG CHẠY hay không.

⚠ Chuỗi chẩn đoán:

⚠ Agent đã CÀI (đề nói)
⚠ Scope đã ĐỦ (đề nói)
        ↓
⚠ Vậy vấn đề ở đâu?
        ↓
⚠ KIỂM TRA TIẾN TRÌNH CÓ CHẠY KHÔNG
   → ⚠ ps ax | grep fluentd

⚠ Cloud Logging agent chạy trên nền fluentd — nên tìm tiến trình fluentd là cách kiểm nhanh nhất.

⚠ Vì sao là bước ĐẦU TIÊN:

⚠ Rẻ nhất, nhanh nhất
⚠ Loại trừ được nguyên nhân phổ biến nhất
   → ⚠ agent cài rồi nhưng KHÔNG CHẠY
     hoặc đã CRASH

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

  • D (đảm bảo scope monitoring.write có trong access scope) — ⚠ bẫy hợp lý: nhưng ⚠ đề đã nói VM có cloud-platform scope, vốn bao gồm mọi scope cần thiết. Kiểm lại là thừa.

  • C (cài phiên bản mới nhất của agent) — ⚠ nhảy tới giải pháp trước khi chẩn đoán: chưa biết vấn đề là gì mà đã cài lại.

  • A (kiểm Logs Viewer để tìm log thử của agent) — ⚠ vòng tròn: chính vấn đề là không thấy log trong Logs Viewer.

Ghi nhớ

⚠ Thứ tự chẩn đoán khi thiếu log — bảng phải thuộc: | Bước | Kiểm gì | |---|---| | ⚠ 1. Agent có CHẠY không | ⚠ ps ax | grep fluentd — đề này | | 2. Log của chính agent | ⚠ /var/log/google-fluentd/ | | 3. Quyền và scope | ⚠ service account có logging.logWriter | | 4. Cấu hình agent | ⚠ có đọc đúng file syslog không | | 5. Kết nối mạng tới API | |

Từ khoá nhận diện:

"đã cài, đã có scope, vẫn không thấy log" → ⚠ kiểm tiến trình có chạy không "cài lại phiên bản mới" → ⚠ nhảy tới giải pháp quá sớm "kiểm trong Logs Viewer" → ⚠ vòng tròn, chính đó là vấn đề

⚠ Nguyên tắc chẩn đoán Nguyên tắc
⚠ Kiểm thứ RẺ NHẤT trước
⚠ Loại trừ nguyên nhân PHỔ BIẾN NHẤT trước
⚠ Đừng sửa khi chưa biết hỏng gì
⚠ Đọc kỹ điều đề đã cho ⚠ tránh kiểm lại thứ đã biết đúng
⚠ Cloud-platform scope bao gồm gì Bao gồm
⚠ Là scope RỘNG NHẤT ⚠ bao mọi API Google Cloud
⚠ Có nó rồi thì không cần scope riêng lẻ
⚠ Nhưng ⚠ scope KHÁC với quyền IAM
⚠ Vẫn cần service account có ROLE phù hợp ⚠ logging.logWriter
Đây là chỗ hay nhầm ⚠ scope đủ nhưng IAM thiếu vẫn không ghi được log
⚠ Ops Agent thay thế agent cũ Lưu ý
⚠ Google khuyến nghị dùng Ops Agent ⚠ gộp logging và monitoring
⚠ Agent cũ (fluentd riêng) đang được thay dần
Lệnh kiểm với Ops Agent ⚠ systemctl status google-cloud-ops-agent
Đề này ⚠ dùng agent cũ nên tìm fluentd

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tiến trình agent có chạy không | ⚠ ps hoặc systemctl status | | Log của chính agent nói gì | ⚠ /var/log/google-fluentd/ | | Service account có role logging.logWriter chưa | ⚠ scope khác quyền IAM |

Và điểm hay nhầm nhất khi gỡ lỗi ghi log trên VM: scope và quyền IAM là hai thứ khác nhau. Scope quyết định VM được phép gọi API nào; IAM quyết định danh tính đó được làm gì. Thiếu một trong hai đều dẫn tới cùng triệu chứng — không thấy log.

Câu 24
As an online therapy platform company, how can we grant some members of our team access to export logs written to Cloud Logging in Google Cloud?
  1. A On Cloud IAM, provide the team members with the IAM role of logging.configWriter.
  2. B To permit log exports creation, establish an Organizational Policy within Cloud IAM that authorizes only specified members.
  3. C Generate a personalized IAM role that includes logging.sinks.list and logging.sink.get authorizations.
  4. D Set up Access Context Manager in a way that permits solely the designated members to export logs.
Xem giải thích

Đáp án

A — Cấp cho thành viên đội vai trò IAM logging.configWriter trong Cloud IAM.

Vì sao đúng

Xuất log (export logs) trong Cloud Logging thực chất là tạo và quản lý log sink. Vai trò cho việc đó là Logs Configuration Writer.

⚠ Vai trò này cho phép gì:

⚠ Tạo, sửa, xoá log SINK
⚠ Cấu hình đích xuất
   → Cloud Storage, BigQuery, Pub/Sub
⚠ Quản lý bộ lọc loại trừ

⚠ Vì sao không dùng vai trò khác:

⚠ logging.viewer → chỉ ĐỌC log
⚠ logging.logWriter → chỉ GHI log
⚠ logging.configWriter → ⚠ CẤU HÌNH
   xuất log — đúng việc

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

  • C (tạo vai trò tuỳ chỉnh với quyền logging.sinks.list và logging.sinks.get) — ⚠ bẫy mạnh nhất và rất gần đúng: nhưng ⚠ hai quyền đó chỉ cho XEM danh sách sink, ⚠ KHÔNG cho TẠO. Muốn tạo phải có logging.sinks.create.

  • B (đặt Organizational Policy cho phép chỉ vài thành viên tạo log export) — ⚠ nhầm công cụ: Organization Policy đặt ràng buộc ở mức tổ chức, ⚠ không phải cơ chế cấp quyền cho cá nhân.

  • D (cấu hình Access Context Manager) — ⚠ nhầm công cụ: nó kiểm soát truy cập theo ngữ cảnh (IP, thiết bị), không phải cấp quyền chức năng.

Ghi nhớ

⚠ Các vai trò Logging — bảng phải thuộc: | Vai trò | Cho phép | |---|---| | ⚠ logging.viewer | ⚠ ĐỌC log | | ⚠ logging.privateLogViewer | ⚠ đọc cả log truy cập dữ liệu | | ⚠ logging.logWriter | ⚠ GHI log — cho service account của ứng dụng | | ⚠ logging.configWriter | ⚠ tạo và quản lý SINK — đề này | | logging.admin | ⚠ toàn quyền |

Từ khoá nhận diện:

"xuất log, tạo sink" → ⚠ logging.configWriter "đọc log" → logging.viewer "ứng dụng ghi log" → logging.logWriter "Organization Policy" → ⚠ ràng buộc tổ chức, không phải cấp quyền "Access Context Manager" → ⚠ kiểm soát theo ngữ cảnh

⚠ Log sink xuất đi đâu Đích
⚠ Cloud Storage ⚠ lưu trữ dài hạn, rẻ
⚠ BigQuery ⚠ phân tích bằng SQL
⚠ Pub/Sub ⚠ đẩy sang hệ thống bên thứ ba
Log bucket khác ⚠ tách theo dự án hoặc thời hạn lưu
Splunk qua Pub/Sub ⚠ mẫu hình phổ biến
⚠ Nguyên tắc quyền tối thiểu Nguyên tắc
⚠ Dùng vai trò định sẵn HẸP NHẤT đủ dùng
⚠ Đừng cấp logging.admin cho tiện
⚠ Vai trò tuỳ chỉnh khi vai trò sẵn không vừa ⚠ nhưng phải đủ quyền
⚠ Lỗi hay gặp ⚠ vai trò tuỳ chỉnh thiếu một quyền, người dùng gặp lỗi khó hiểu
⚠ Lưu ý về log xuất ra Lưu ý
⚠ Log có thể chứa PII ⚠ kiểm trước khi xuất ra ngoài
⚠ Chi phí lưu trữ và truy vấn ⚠ BigQuery tính theo lượng quét
⚠ Đặt bộ lọc để chỉ xuất thứ cần
Thời hạn lưu ở đích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vai trò có đủ quyền tạo sink không | ⚠ list và get là chưa đủ | | Log xuất ra có chứa dữ liệu nhạy cảm không | | | Chi phí ở đích là bao nhiêu | ⚠ BigQuery có thể rất tốn |

Và lỗi phổ biến khi tự tạo vai trò IAM: liệt kê quyền ĐỌC mà quên quyền GHI hoặc TẠO. Với sink, list và get chỉ cho xem — muốn tạo thì phải có create, và đó chính là cái phương án C thiếu.

Câu 25
As a Healthcare technology company, how can you assign owners and collaborators to action items efficiently using Google Cloud Services to address the root causes of an outage in a postmodern environment?
  1. A To maintain a blameless postmortem, it is recommended to assign collaborators to the items without any specific individual owners.
  2. B Since the team lead is responsible for the SRE team, it is advisable to designate them as the owner of all action items.
  3. C Ensure that every action item has a single owner and any required collaborators.
  4. D To ensure prompt handling of items, it is advisable to designate multiple owners for each item.
Xem giải thích

Đáp án

C — Đảm bảo mỗi hành động khắc phục có MỘT chủ sở hữu duy nhất, cùng những người phối hợp cần thiết.

Vì sao đúng

Nguyên tắc SRE về hành động sau sự cố: một chủ sở hữu rõ ràng để chịu trách nhiệm hoàn thành, cộng tác viên để hỗ trợ.

⚠ Vì sao MỘT chủ sở hữu:

⚠ Nhiều chủ sở hữu = KHÔNG AI chịu
  trách nhiệm
⚠ "Cả đội lo" = không ai lo
        ↓
⚠ Một người có TÊN, có HẠN
   → ⚠ việc mới xong

⚠ Cộng tác viên vẫn cần — công việc phức tạp cần nhiều người, nhưng trách nhiệm phải quy về một đầu mối.

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

  • A (chỉ gán cộng tác viên, KHÔNG có chủ sở hữu cụ thể, để giữ blameless) — ⚠ hiểu sai blameless: blameless là không buộc tội người GÂY RA sự cố, ⚠ không phải bỏ trách nhiệm SỬA.

  • D (gán NHIỀU chủ sở hữu cho mỗi việc để xử lý nhanh) — ⚠ phản tác dụng: nhiều chủ sở hữu dẫn tới ⚠ mỗi người tưởng người kia làm.

  • B (gán trưởng nhóm làm chủ sở hữu MỌI hành động) — ⚠ nút thắt cổ chai: một người không thể là chủ sở hữu của tất cả, và ⚠ người gần vấn đề nhất mới nên sở hữu.

Ghi nhớ

⚠ Hành động sau sự cố phải có gì — bảng phải thuộc: | Yếu tố | Nội dung | |---|---| | ⚠ MỘT chủ sở hữu có tên | ⚠ không phải "đội X" — đề này | | ⚠ Cộng tác viên nếu cần | | | ⚠ Hạn hoàn thành cụ thể | | | ⚠ Được theo dõi tới khi xong | ⚠ đưa vào backlog | | Ưu tiên theo mức giảm rủi ro | |

Từ khoá nhận diện:

"một chủ sở hữu + cộng tác viên" → ⚠ đúng chuẩn SRE "không có chủ sở hữu để giữ blameless" → ⚠ hiểu sai blameless "nhiều chủ sở hữu" → ⚠ không ai chịu trách nhiệm "trưởng nhóm sở hữu tất cả" → ⚠ nút thắt

⚠ Blameless nghĩa là gì — làm rõ Nghĩa
⚠ KHÔNG buộc tội người gây ra sự cố
⚠ Tập trung vào lỗi HỆ THỐNG
⚠ NHƯNG hành động sửa VẪN có chủ sở hữu
⚠ Phân biệt ⚠ trách nhiệm về việc SỬA ≠ đổ lỗi về việc GÂY RA
Hiểu sai phổ biến ⚠ tưởng blameless là không ai chịu trách nhiệm gì cả
⚠ Vì sao hành động không có chủ sở hữu thì không xong Lý do
⚠ Ai cũng bận việc khác
⚠ Không ai nhắc thì không ai nhớ
⚠ Không có tên thì không đo được tiến độ
Hậu quả ⚠ sự cố lặp lại vì hành động chưa làm
⚠ Theo dõi hành động thế nào Cách
⚠ Đưa vào hệ thống theo dõi công việc ⚠ không để trong tài liệu postmortem
⚠ Rà lại định kỳ
⚠ Đo tỷ lệ hoàn thành ⚠ chỉ số sức khoẻ của văn hoá SRE
Dấu hiệu xấu ⚠ postmortem viết đẹp mà hành động không ai làm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi hành động có tên một người không | | | Có hạn hoàn thành chưa | | | Tỷ lệ hành động hoàn thành từ các postmortem trước | ⚠ thấp là dấu hiệu quy trình hình thức |

Và chỉ số đo sức khoẻ thật của quy trình postmortem: bao nhiêu phần trăm hành động khắc phục được hoàn thành đúng hạn. Con số thấp nghĩa là đội đang viết báo cáo cho có, và sự cố sẽ lặp lại.

Câu 26
As a Cloud-based project management tool company, our team of Infrastructure DevOps Engineers is expanding, and we are implementing Terraform to manage infrastructure on Google Cloud. How can we achieve code versioning and collaboration among team members?
  1. A To ensure easy accessibility of Terraform code to all team members, store it in a Cloud Storage bucket with object versioning enabled and grant permission to access the bucket.
  2. B A recommended approach is to keep the Terraform code in a shared Google Drive directory to ensure automatic synchronization across all team members' devices. Additionally, it is advised to use a naming convention that distinguishes every new version.
  3. C To guarantee that different individuals work on distinct files, it is recommended to save the Terraform code in a network shared directory with subdirectories for each version release.
  4. D To ensure proper management of the Terraform code, it is recommended to store it in a version control system and establish a protocol for pushing new versions and merging with the master.
Xem giải thích

Đáp án

D — Lưu mã Terraform trong một hệ thống quản lý phiên bản (version control system) và thiết lập quy trình đẩy phiên bản mới cùng gộp vào nhánh chính.

Vì sao đúng

Terraform là mã hạ tầng (Infrastructure as Code) — nên phải quản lý y hệt như mã ứng dụng.

⚠ VCS cho gì mà cách khác không có:

⚠ Lịch sử thay đổi đầy đủ
   → ai đổi gì, khi nào, vì sao

⚠ Nhánh và pull request
   → ⚠ RÀ SOÁT trước khi áp dụng

⚠ Giải quyết xung đột
   → ⚠ nhiều người sửa cùng lúc

⚠ Quay lui về phiên bản trước
⚠ Tích hợp CI/CD
   → ⚠ terraform plan tự động trên PR

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

  • A (Cloud Storage bucket bật object versioning) — ⚠ bẫy mạnh nhất: có "versioning" nên nghe hợp lý. Nhưng ⚠ không có nhánh, không có pull request, không rà soát, không giải quyết xung đột. ⚠ Object versioning chỉ giữ bản cũ, không phải quản lý mã.

  • C (thư mục mạng chia sẻ, mỗi bản phát hành một thư mục con) — ⚠ thủ công và dễ hỏng: không khoá, không lịch sử, hai người sửa là mất việc của nhau.

  • B (Google Drive, đặt quy ước tên để phân biệt phiên bản) — ⚠ tệ nhất: quy ước tên file là cách quản lý phiên bản thủ công, ⚠ luôn dẫn tới main_final_v2_moi_nhat.tf.

Ghi nhớ

⚠ Thực hành Terraform trong đội — bảng phải thuộc: | Thực hành | Nội dung | |---|---| | ⚠ Mã trong VCS | ⚠ Git — đề này | | ⚠ Pull request bắt buộc | ⚠ rà soát trước khi áp dụng | | ⚠ Remote state có KHOÁ | ⚠ GCS backend với state locking | | ⚠ terraform plan tự động trên PR | ⚠ thấy trước thay đổi | | Tách môi trường | ⚠ dev, staging, prod riêng state | | ⚠ Không commit secret | |

Từ khoá nhận diện:

"quản lý phiên bản, cộng tác nhiều người" → ⚠ VCS "object versioning trong bucket" → ⚠ KHÔNG phải quản lý mã "quy ước đặt tên file" → ⚠ luôn sai "thư mục mạng chia sẻ" → ⚠ không có khoá, không lịch sử

⚠ Vì sao remote state quan trọng ngang mã Lý do
⚠ State là bản ghi hạ tầng THẬT đang có
⚠ Hai người apply cùng lúc → hỏng state ⚠ cần KHOÁ
⚠ State chứa thông tin nhạy cảm ⚠ mã hoá, hạn chế truy cập
Đừng để state trên máy cá nhân
⚠ Trên Google Cloud ⚠ dùng GCS backend, tự có locking
⚠ Quy trình chuẩn cho thay đổi hạ tầng Bước
⚠ 1. Tạo nhánh
⚠ 2. Sửa mã, mở pull request
⚠ 3. CI chạy terraform plan tự động ⚠ hiện diff cho người rà soát
⚠ 4. Đồng nghiệp rà soát và duyệt
⚠ 5. Gộp vào nhánh chính
6. CD chạy terraform apply
⚠ Vì sao rà soát quan trọng với Terraform Lý do
⚠ Một dòng sai có thể XOÁ tài nguyên sản xuất
⚠ terraform plan cho thấy trước điều đó
⚠ Chú ý mọi dòng "destroy" trong plan
Bảo vệ thêm ⚠ prevent_destroy trên tài nguyên quan trọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | State lưu ở đâu, có khoá không | ⚠ máy cá nhân là rủi ro lớn | | PR có chạy plan tự động không | | | Có secret nào bị commit vào mã không | ⚠ quét lịch sử Git |

Và điều đáng sợ nhất khi quản lý Terraform sai cách: terraform apply có thể XOÁ hạ tầng sản xuất. Đó là lý do mọi thay đổi phải qua rà soát, và người rà soát phải thật sự đọc phần "destroy" trong plan.

Câu 27
As a Mobile payment solution company, you want to ensure fast response time for your payment processing. What is the Google Cloud-recommended way of implementing a Service Level Indicator (SLI) to measure the latency of payment processing requests and ensure that the acceptable response time is within 50 ms?
  1. A To calculate the percentage of home page requests that load under 100 ms, you need to determine the number of such requests and divide it by the total number of home page requests.
  2. B A way to calculate percentile at 100 ms is to group the request latencies into different ranges and then bucketize them.
  3. C To calculate, determine the quantity of homepage requests loading within 100 ms and divide it by the overall number of requests for the web application.
  4. D Group the request latencies into specific ranges and then determine the median and 90th percentiles.
Xem giải thích

Đáp án

A — Tính tỷ lệ phần trăm số yêu cầu tải dưới ngưỡng: lấy số yêu cầu đạt ngưỡng chia cho tổng số yêu cầu.

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

⚠ Đề bài và phương án KHÔNG KHỚP NHAU.

Phần Nội dung
⚠ Đề bài ⚠ xử lý thanh toán, ngưỡng 50 ms
⚠ Mọi phương án ⚠ "home page requests", ngưỡng 100 ms

⚠ Rõ ràng bộ đề đã ghép nhầm phương án của một câu khác (về trang chủ web) vào đề bài này (về thanh toán).

⚠ KHÔNG sửa khoá — cách chấm vẫn đúng vì phương án A nêu đúng CÔNG THỨC của một SLI dạng tỷ lệ, chỉ khác con số và bối cảnh.

⚠ Mẹo làm bài: khi đề và phương án lệch nhau, ⚠ chấm theo NGUYÊN LÝ chứ không theo con số.

Vì sao đúng

⚠ SLI độ trễ chuẩn là một TỶ LỆ:

⚠ SLI = (số yêu cầu NHANH HƠN ngưỡng)
        ÷ (TỔNG số yêu cầu)

Ví dụ đề bài lẽ ra phải là:
⚠ số giao dịch thanh toán < 50 ms
   ÷ tổng số giao dịch thanh toán

⚠ Vì sao dùng tỷ lệ chứ không dùng trung bình:

⚠ Trung bình CHE MẤT đuôi phân bố
   → ⚠ 99 request 10ms + 1 request 5s
     = trung bình 60ms, nghe ổn
   → ⚠ nhưng có người chờ 5 giây

⚠ Tỷ lệ "bao nhiêu % đạt ngưỡng"
   → ⚠ phản ánh trải nghiệm thật

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

  • C (chia cho tổng số yêu cầu của TOÀN ứng dụng) — ⚠ bẫy tinh vi nhất và khác A đúng một chi tiết: mẫu số phải là cùng loại yêu cầu, không phải toàn bộ ứng dụng. ⚠ Chia sai mẫu số làm SLI vô nghĩa.

  • B (bucketize độ trễ rồi tính percentile tại 100 ms) — ⚠ lẫn lộn khái niệm: percentile là giá trị độ trễ tại một mốc phần trăm, không phải "percentile tại một mốc thời gian".

  • D (bucketize rồi tính trung vị và percentile 90) — ⚠ là chỉ số hữu ích nhưng KHÔNG phải SLI dạng tỷ lệ mà đề yêu cầu; và percentile 90 quá lỏng cho hệ thanh toán.

Ghi nhớ

⚠ Ba loại SLI thường dùng — bảng phải thuộc: | Loại | Công thức | |---|---| | ⚠ Availability | ⚠ request thành công ÷ tổng request | | ⚠ Latency | ⚠ request nhanh hơn ngưỡng ÷ tổng request — đề này | | Quality | ⚠ request đủ chất lượng ÷ tổng request | | ⚠ Điểm chung | ⚠ đều là TỶ LỆ sự kiện tốt trên tổng sự kiện |

Từ khoá nhận diện:

"phần trăm request dưới ngưỡng" → ⚠ SLI latency đúng chuẩn "trung bình độ trễ" → ⚠ che mất đuôi, không nên dùng làm SLI "mẫu số là toàn bộ ứng dụng" → ⚠ sai mẫu số

⚠ SLI, SLO, SLA — phân biệt Phân biệt
⚠ SLI ⚠ CHỈ SỐ đo được — "99,2% dưới 50ms"
⚠ SLO ⚠ MỤC TIÊU nội bộ — "phải ≥ 99%"
⚠ SLA ⚠ CAM KẾT với khách, có đền bù
Nguyên tắc ⚠ SLO chặt hơn SLA để có biên an toàn
⚠ Chọn ngưỡng và mục tiêu thế nào Cách
⚠ Ngưỡng theo trải nghiệm người dùng ⚠ bao lâu thì khách thấy chậm
⚠ Mục tiêu theo mức chấp nhận được của nghiệp vụ
⚠ Đừng đặt 100% ⚠ không khả thi và cực đắt
Phần chưa đạt = error budget ⚠ ngân sách lỗi để đổi lấy tốc độ phát hành
⚠ Riêng hệ thanh toán Lưu ý
⚠ Độ trễ ảnh hưởng trực tiếp tỷ lệ hoàn tất giao dịch
⚠ Nên đo ở nhiều mốc: p50, p95, p99
⚠ Đo từ phía NGƯỜI DÙNG, không chỉ phía máy chủ
Tách theo loại giao dịch và vùng địa lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mẫu số có đúng loại yêu cầu không | ⚠ lỗi phổ biến nhất khi định nghĩa SLI | | Đo ở phía nào | ⚠ client-side phản ánh trải nghiệm thật hơn | | Ngưỡng có dựa trên dữ liệu thật không | ⚠ đừng chọn số tròn cho đẹp |

Và nguyên tắc quan trọng nhất khi định nghĩa SLI: mẫu số phải là đúng tập sự kiện mà bạn quan tâm. Chia số giao dịch nhanh cho tổng số request của cả ứng dụng sẽ cho ra một con số đẹp nhưng vô nghĩa.

Câu 28
As a Smart home automation company, how can we implement Site Reliability Engineering practices using Google Cloud Services to prevent staff burnout caused by receiving alerts for numerous outages in our production systems?
  1. A For every alert, generate an incident report.
  2. B Get rid of alerts that cannot be acted upon.
  3. C To avoid exhausting the error budget, redefine the Service Level Objective associated with it.
  4. D Send the alerts to engineers located in various time zones.
Xem giải thích

Đáp án

B — Loại bỏ những cảnh báo không hành động được.

Vì sao đúng

Đề nêu vấn đề kiệt sức vì nhận quá nhiều cảnh báo. Nguyên nhân gốc là cảnh báo không đáng báo.

⚠ Nguyên tắc SRE về cảnh báo:

⚠ Mỗi cảnh báo phải:
   → ⚠ HÀNH ĐỘNG ĐƯỢC
   → ⚠ KHẨN CẤP
   → ⚠ có người biết phải làm gì

⚠ Không đủ ba điều đó
   → ⚠ KHÔNG nên là cảnh báo đánh thức người

⚠ Vì sao cảnh báo rác nguy hiểm:

⚠ Quá nhiều cảnh báo
        ↓
⚠ Người trực bắt đầu BỎ QUA
        ↓
⚠ Bỏ qua luôn cảnh báo THẬT
        ↓
⚠ Kiệt sức + sự cố không ai xử lý

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

  • C (định nghĩa lại SLO để không cạn error budget) — ⚠ bẫy nguy hiểm nhất: nới lỏng SLO để con số trông đẹp là ⚠ che giấu vấn đề, không giải quyết. SLO phải phản ánh kỳ vọng thật của người dùng.

  • D (gửi cảnh báo cho kỹ sư ở nhiều múi giờ) — ⚠ phân tán nỗi đau, không giảm nỗi đau: vẫn cùng số cảnh báo rác, chỉ là nhiều người cùng mệt.

  • A (tạo báo cáo sự cố cho MỌI cảnh báo) — ⚠ làm tệ hơn: thêm việc giấy tờ lên trên khối lượng cảnh báo vốn đã quá tải.

Ghi nhớ

⚠ Tiêu chí cho một cảnh báo tốt — bảng phải thuộc: | Tiêu chí | Nội dung | |---|---| | ⚠ Hành động được | ⚠ người nhận biết phải làm gì | | ⚠ Khẩn cấp | ⚠ cần xử lý NGAY, không đợi được | | ⚠ Ảnh hưởng người dùng | ⚠ dựa trên triệu chứng, không dựa nguyên nhân | | Có runbook | ⚠ hướng dẫn xử lý kèm theo | | ⚠ Không đủ | ⚠ chuyển thành ticket hoặc dashboard |

Từ khoá nhận diện:

"quá nhiều cảnh báo, kiệt sức" → ⚠ loại cảnh báo không hành động được "nới lỏng SLO cho đẹp số" → ⚠ che giấu vấn đề "chia cho nhiều múi giờ" → ⚠ phân tán, không giải quyết "báo cáo cho mọi cảnh báo" → ⚠ thêm gánh nặng

⚠ Ba mức phản ứng — bảng phải thuộc Mức
⚠ PAGE (đánh thức người) ⚠ khẩn cấp, ảnh hưởng người dùng
⚠ TICKET ⚠ cần xử lý nhưng đợi được tới giờ làm
⚠ DASHBOARD / LOG ⚠ chỉ để quan sát, không báo ai
⚠ Sai lầm phổ biến ⚠ đưa mọi thứ lên mức PAGE
⚠ Cảnh báo theo TRIỆU CHỨNG, không theo NGUYÊN NHÂN Nguyên tắc
⚠ TỐT: "tỷ lệ lỗi vượt SLO" ⚠ người dùng đang bị ảnh hưởng
⚠ XẤU: "CPU node 3 vượt 80%" ⚠ có thể chẳng ảnh hưởng ai
⚠ Cảnh báo theo SLO giảm nhiễu rất nhiều
Lý do ⚠ một triệu chứng thay cho hàng chục nguyên nhân
⚠ Dấu hiệu mệt mỏi cảnh báo Dấu hiệu
⚠ Người trực bỏ qua cảnh báo không đọc
⚠ Có cảnh báo "luôn nổ", ai cũng biết bỏ qua
⚠ Số cảnh báo mỗi ca trực quá nhiều ⚠ SRE khuyến nghị tối đa 2 sự cố mỗi ca
Nghỉ việc, luân chuyển đội

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi ca trực nhận bao nhiêu cảnh báo | ⚠ quá 2 sự cố là dấu hiệu xấu | | Cảnh báo nào nổ nhiều nhất mà không cần làm gì | ⚠ xoá hoặc hạ mức ngay | | Cảnh báo có kèm runbook không | |

Và bài kiểm tra đơn giản cho mỗi cảnh báo: "nếu cái này nổ lúc 3 giờ sáng, người trực sẽ làm gì?" Nếu câu trả lời là "xem rồi ngủ tiếp" thì nó không nên đánh thức ai cả.

Câu 29
What steps should be taken by a Cybersecurity training and certification company to visualize the frequency of a cache miss over time in an application that stores product information in cached memory and logs every cache miss entry in Google Cloud Logging?
  1. A To set up BigQuery as a destination for Cloud Logging, you need to establish a scheduled query that will sift through the cache miss logs and record them in a distinct table.
  2. B Set up Cloud Profiler to detect and display occurrences of cache misses as per the logs.
  3. C In Cloud Logging, generate a metric that is based on logs and then create a dashboard for that metric in Cloud Monitoring.
  4. D Connect Google Cloud Logging as a data source in Google Data Studio and apply filters to display only the logs related to cache misses.
Xem giải thích

Đáp án

C — Tạo một log-based metric trong Cloud Logging, rồi lập dashboard cho chỉ số đó trong Cloud Monitoring.

Vì sao đúng

Đề cần trực quan hoá TẦN SUẤT cache miss THEO THỜI GIAN từ dữ liệu vốn nằm trong log.

⚠ Luồng chuẩn:

⚠ Log ghi từng lần cache miss
        ↓
⚠ LOG-BASED METRIC
   → ⚠ ĐẾM số dòng log khớp bộ lọc
   → ⚠ biến LOG thành CHỈ SỐ theo thời gian
        ↓
⚠ Dashboard trong Cloud Monitoring
   → ⚠ vẽ biểu đồ, đặt cảnh báo

⚠ Đây là cách chuẩn để chuyển từ "sự kiện rời rạc" sang "chỉ số theo thời gian".

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

  • A (xuất sang BigQuery rồi chạy truy vấn theo lịch) — ⚠ bẫy hợp lý: làm được, nhưng ⚠ phức tạp và tốn kém hơn nhiều, ⚠ không phải thời gian thực, và ⚠ không đặt cảnh báo trực tiếp được.

  • D (nối Cloud Logging làm nguồn dữ liệu trong Data Studio rồi lọc) — ⚠ không phải cách tích hợp chuẩn, và ⚠ Looker Studio hợp cho báo cáo nghiệp vụ hơn là theo dõi vận hành thời gian thực.

  • B (dùng Cloud Profiler để hiện cache miss theo log) — ⚠ sai công cụ hoàn toàn: Profiler phân tích hiệu năng CPU và bộ nhớ trong mã, ⚠ không đọc log.

Ghi nhớ

⚠ Bốn công cụ quan sát và việc của chúng — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Cloud Logging | ⚠ lưu và tìm bản ghi sự kiện | | ⚠ Log-based metric | ⚠ biến log thành CHỈ SỐ — đề này | | ⚠ Cloud Monitoring | ⚠ chỉ số, dashboard, cảnh báo | | Cloud Trace | ⚠ theo dõi độ trễ từng bước request | | ⚠ Cloud Profiler | ⚠ CPU và bộ nhớ trong MÃ NGUỒN | | Error Reporting | ⚠ gom nhóm ngoại lệ |

Từ khoá nhận diện:

"đếm sự kiện trong log theo thời gian" → ⚠ log-based metric "biểu đồ, cảnh báo theo ngưỡng" → ⚠ Cloud Monitoring "chậm ở hàm nào, tốn CPU ở đâu" → ⚠ Profiler "phân tích lịch sử bằng SQL" → ⚠ BigQuery — không phải theo dõi thời gian thực

⚠ Hai loại log-based metric Loại
⚠ Counter ⚠ ĐẾM số dòng log khớp — đề này
⚠ Distribution ⚠ trích GIÁ TRỊ SỐ từ log và phân bố
Ví dụ counter ⚠ số lần cache miss
Ví dụ distribution ⚠ độ trễ trích từ trường trong log
⚠ Lưu ý khi dùng log-based metric Lưu ý
⚠ Chỉ tính từ lúc TẠO metric ⚠ không hồi tố dữ liệu cũ
⚠ Bộ lọc phải chính xác ⚠ lọc sai là đếm sai
⚠ Có giới hạn số metric và nhãn
⚠ Nhãn có cardinality cao rất tốn ⚠ đừng lấy user ID làm nhãn
Chi phí ⚠ tính theo lượng log được xử lý
⚠ Riêng theo dõi cache miss Lưu ý
⚠ Tỷ lệ miss quan trọng hơn số miss tuyệt đối ⚠ cần cả tổng số truy vấn cache
⚠ Miss tăng đột biến ⚠ có thể do cache bị xoá, hoặc dữ liệu mới
⚠ Đặt cảnh báo theo tỷ lệ
Ghi log MỌI lần miss có thể rất tốn ⚠ cân nhắc lấy mẫu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ lọc có bắt đúng dòng log không | ⚠ thử trong Logs Explorer trước | | Có đo được TỶ LỆ miss không | ⚠ cần cả mẫu số | | Chi phí ghi log mỗi lần miss là bao nhiêu | ⚠ hệ tải cao có thể rất tốn |

Và điều cần nhớ về log-based metric: nó chỉ đếm từ thời điểm bạn tạo ra nó. Dữ liệu log cũ vẫn còn đó nhưng chỉ số thì không hồi tố — nên tạo metric càng sớm càng tốt, trước khi cần tới nó.

Câu 30
For an augmented reality platform company that uses Google Cloud services, what is the best approach to securely integrate database credentials and other application secrets into the build pipeline using Cloud Build while minimizing development effort?
  1. A To secure the secrets, encrypt them on the client-side and keep them in a Cloud Storage bucket. Additionally, place a decryption key in the same bucket and provide Cloud Build access to the bucket.
  2. B To secure the secrets, encrypt them and keep them in the application repository. Keep a separate repository for the decryption key and authorize Cloud Build to access it.
  3. C To secure your secrets, you can establish a Cloud Storage bucket and utilize the inbuilt encryption feature. Then, you can save the confidential data in the bucket and allow Cloud Build access to it.
  4. D To encrypt the sensitive information and add it to your Cloud Build deployment configuration, utilize Cloud Key Management Service (Cloud KMS). Also, ensure to give KeyRing access to Cloud Build.
Xem giải thích

Đáp án

D — Dùng Cloud Key Management Service (Cloud KMS) để mã hoá thông tin nhạy cảm và đưa vào cấu hình triển khai Cloud Build; cấp quyền truy cập KeyRing cho Cloud Build.

Vì sao đúng

Đề yêu cầu an toàn và ít công sức phát triển nhất. Cloud KMS tích hợp sẵn với Cloud Build.

⚠ Cách hoạt động:

⚠ Mã hoá secret bằng KMS key
        ↓
⚠ Đưa bản mã hoá vào cloudbuild.yaml
   → ⚠ an toàn khi commit vào repo
        ↓
⚠ Cloud Build TỰ giải mã lúc chạy
   → ⚠ nhờ quyền trên KeyRing
        ↓
⚠ Không phải quản lý khoá thủ công

⚠ Google Cloud có Secret Manager — cũng là lựa chọn tốt và thường được khuyến nghị hơn cho quản lý secret. Trong bốn phương án này, KMS là phương án đúng duy nhất.

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

  • A (mã hoá phía client, lưu trong bucket, ĐỂ LUÔN KHOÁ GIẢI MÃ trong CÙNG bucket) — ⚠ sai nghiêm trọng nhất: ⚠ để khoá cạnh dữ liệu mã hoá thì mã hoá vô nghĩa. Ai vào được bucket là có cả hai.

  • B (mã hoá và lưu trong repo ứng dụng, khoá giải mã ở repo riêng) — ⚠ tốt hơn A nhưng vẫn tệ: ⚠ khoá nằm trong repo là rủi ro lộ, và quản lý thủ công tốn công.

  • C (dùng mã hoá mặc định của Cloud Storage rồi cho Cloud Build truy cập bucket) — ⚠ hiểu sai mã hoá mặc định: ⚠ nó bảo vệ dữ liệu khi lưu trên đĩa, nhưng ⚠ ai có quyền đọc bucket vẫn đọc được nội dung rõ.

Ghi nhớ

⚠ Quản lý secret trong CI/CD — bảng phải thuộc: | Cách | Đánh giá | |---|---| | ⚠ Secret Manager | ⚠ khuyến nghị nhất hiện nay | | ⚠ Cloud KMS mã hoá trong cấu hình | ⚠ đúng, tích hợp sẵn — đề này | | Biến môi trường trong CI | ⚠ được nhưng khó xoay vòng | | ⚠ Secret trong repo | ⚠ LUÔN SAI | | ⚠ Khoá cạnh dữ liệu mã hoá | ⚠ vô nghĩa |

Từ khoá nhận diện:

"mã hoá secret cho pipeline, ít công sức" → ⚠ KMS hoặc Secret Manager "khoá cùng chỗ với dữ liệu" → ⚠ luôn SAI "mã hoá mặc định của bucket là đủ" → ⚠ hiểu sai — không chống được quyền đọc

⚠ Mã hoá khi lưu trữ KHÔNG phải kiểm soát truy cập Phân biệt
⚠ Mã hoá đĩa chống: ai lấy được ổ cứng vật lý
⚠ KHÔNG chống: ai có quyền IAM đọc bucket
⚠ Muốn chống người có quyền đọc → mã hoá TẦNG ỨNG DỤNG
Đây là hiểu lầm rất phổ biến
⚠ Secret Manager cho gì hơn Ưu điểm
⚠ Quản lý PHIÊN BẢN secret
⚠ Xoay vòng secret
⚠ Kiểm soát truy cập từng secret
⚠ Ghi vết ai đọc secret nào
Tích hợp ⚠ Cloud Build, Cloud Run, GKE đều dùng được
⚠ Nguyên tắc bất biến về secret Nguyên tắc
⚠ KHÔNG BAO GIỜ commit secret vào Git ⚠ kể cả repo riêng tư
⚠ Lịch sử Git giữ mãi ⚠ xoá file không đủ, phải xoay vòng secret
⚠ Quét repo tìm secret lộ
Xoay vòng định kỳ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có secret nào trong lịch sử Git không | ⚠ quét toàn bộ lịch sử | | Ai đọc được secret | ⚠ rà quyền IAM | | Secret xoay vòng bao lâu một lần | |

Và sai lầm nghiêm trọng nhất trong bốn phương án: để khoá giải mã cạnh dữ liệu đã mã hoá. Nó biến toàn bộ việc mã hoá thành hình thức — và đáng tiếc là lỗi này xuất hiện trong hệ thống thật thường xuyên hơn ta tưởng.