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

Tìm thấy 269 câu.

Câu 41
As an Event ticketing platform company using Google Cloud Services, following Site Reliability Engineering practices, you are the Incident Commander for a new, customer-impacting incident. Which two incident management roles should you assign immediately for an effective incident response?
  1. A Lead in Communications
  2. B Lead Engineer
  3. C Lead of Operations.
  4. D The position of External Customer Communications Lead can be described as a Customer Impact Assessor.
Xem giải thích

Đáp án

C — Operations Lead (Trưởng bộ phận vận hành).

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

⚠ Đề bài hỏi "HAI vai trò" (which two roles) nhưng bộ đề chỉ đánh dấu MỘT phương án đúng.

⚠ Theo khung IMAG (Incident Management At Google), Incident Commander cần chỉ định NGAY hai vai:

Vai Phương án Trạng thái
⚠ Operations Lead ⚠ C ⚠ được đánh dấu đúng
⚠ Communications Lead ⚠ A ⚠ theo chuẩn cũng đúng, nhưng không được đánh dấu

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

Vì sao đúng

⚠ Operations Lead làm gì:

⚠ Chỉ huy đội KỸ THUẬT khắc phục
⚠ Quyết định thử biện pháp nào
⚠ Báo cáo tiến độ cho IC
        ↓
⚠ Đây là vai KHÔNG THỂ THIẾU
   → không có thì không ai sửa
     một cách phối hợp

⚠ Vì sao IC không kiêm được:

⚠ IC phải giữ TẦM NHÌN TỔNG THỂ
⚠ Nếu IC lao vào gõ lệnh sửa
   → ⚠ mất điều phối
   → ⚠ đây là lỗi phổ biến nhất

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

  • A (Communications Lead) — ⚠ thực tế ĐÚNG theo chuẩn IMAG nhưng bộ đề không đánh dấu. Xem ghi chú ở trên.

  • B (Lead Engineer) — ⚠ không phải vai trò chính thức trong khung quản lý sự cố; kỹ sư trưởng là chức danh tổ chức, không phải vai trong sự cố.

  • D (External Customer Communications Lead mô tả như Customer Impact Assessor) — ⚠ trộn hai vai khác nhau và ⚠ không phải vai cần chỉ định NGAY.

Ghi nhớ

⚠ Các vai trong IMAG — bảng phải thuộc: | Vai | Việc | |---|---| | ⚠ Incident Commander (IC) | ⚠ điều phối, ra quyết định, KHÔNG tự sửa | | ⚠ Operations Lead | ⚠ chỉ huy khắc phục kỹ thuật — đề này | | ⚠ Communications Lead | ⚠ cập nhật bên liên quan | | Planning Lead | ⚠ theo dõi, ghi chép, chuẩn bị bàn giao ca | | ⚠ Sự cố nhỏ | ⚠ một người có thể kiêm nhiều vai |

Từ khoá nhận diện:

"chỉ huy kỹ thuật khắc phục" → ⚠ Operations Lead "cập nhật bên liên quan" → ⚠ Communications Lead "điều phối tổng thể" → ⚠ Incident Commander "Lead Engineer" → ⚠ không phải vai IMAG

⚠ Vì sao tách vai lại quan trọng Lý do
⚠ Một người không thể vừa sửa vừa điều phối
⚠ Vừa sửa vừa trả lời quản lý là không xong việc nào
⚠ Communications Lead che chắn cho đội kỹ thuật ⚠ để họ tập trung sửa
⚠ Ai cũng biết mình đang làm vai gì
⚠ Sai lầm phổ biến của IC Sai lầm
⚠ IC tự lao vào gõ lệnh sửa ⚠ lỗi số một
⚠ Không chỉ định vai rõ ràng
⚠ Không ghi mốc thời gian
Quên cập nhật bên liên quan ⚠ rồi bị hỏi liên tục, mất tập trung
⚠ Khi nào cần chỉ định vai đầy đủ Khi nào
⚠ Sự cố ảnh hưởng KHÁCH HÀNG ⚠ đề này
⚠ Kéo dài hơn một khoảng thời gian
⚠ Cần nhiều đội tham gia
Sự cố nhỏ ⚠ một người xử lý là đủ, không cần bộ máy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IC có đang tự sửa không | ⚠ dấu hiệu quy trình đang hỏng | | Có ai lo cập nhật bên ngoài không | | | Mọi người có biết vai của mình không | |

Và nguyên tắc quan trọng nhất của IC: chỉ huy thì không gõ lệnh. Ngay khi IC bắt đầu tự sửa, không còn ai giữ bức tranh tổng thể — và đó là lúc sự cố kéo dài hơn cần thiết.

Câu 42
How can an event ticketing platform company ensure the security and patch level of all code running through the pipeline when using a container-based workflow for application development on Google Cloud Platform?
  1. A Modify the current vulnerability software of the operating system to be present within the container.
  2. B Set up static code analysis tooling for the Docker files utilized in container creation.
  3. C Configure Container Analysis in order to perform scanning and generate reports on Common Vulnerabilities and Exposures (CVEs).
  4. D Ensure that the containers in the build pipeline are updated prior to releasing.
Xem giải thích

Đáp án

C — Cấu hình Container Analysis để quét và báo cáo về các lỗ hổng đã biết (CVE).

Vì sao đúng

Đề cần đảm bảo bảo mật và mức vá của MỌI mã chạy qua pipeline trong quy trình dựa trên container.

⚠ Container Analysis làm gì:

⚠ Tự động QUÉT image khi đẩy vào
  Artifact Registry
        ↓
⚠ So với cơ sở dữ liệu CVE
        ↓
⚠ Báo cáo lỗ hổng theo mức nghiêm trọng
        ↓
⚠ Bao gồm cả THƯ VIỆN PHỤ THUỘC
   → ⚠ phần hay bị bỏ sót nhất

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

  • D (cập nhật container trong pipeline trước khi phát hành) — ⚠ bẫy hợp lý: cập nhật là tốt, nhưng ⚠ không BIẾT có lỗ hổng nào thì cập nhật mù. ⚠ Quét mới cho biết cái gì cần vá.

  • B (phân tích tĩnh cho Dockerfile) — ⚠ chỉ bắt lỗi cấu hình Dockerfile, ⚠ không phát hiện CVE trong thư viện và gói hệ điều hành bên trong image.

  • A (đưa phần mềm quét lỗ hổng của hệ điều hành vào bên trong container) — ⚠ chống chỉ định: container nên nhỏ và tối giản; ⚠ nhét công cụ quét vào làm TĂNG bề mặt tấn công.

Ghi nhớ

⚠ Bảo mật chuỗi cung ứng container — bảng phải thuộc: | Lớp | Công cụ | |---|---| | ⚠ Quét lỗ hổng image | ⚠ Container Analysis / Artifact Analysis — đề này | | ⚠ Chỉ cho chạy image đã duyệt | ⚠ Binary Authorization | | Ký image | ⚠ chứng thực nguồn gốc | | Quét mã nguồn | ⚠ SAST | | Quét phụ thuộc | ⚠ SCA | | Bảo vệ lúc chạy | ⚠ GKE security posture |

Từ khoá nhận diện:

"quét CVE, lỗ hổng đã biết trong image" → ⚠ Container Analysis "chỉ cho triển khai image đã duyệt" → ⚠ Binary Authorization "lỗi cấu hình Dockerfile" → ⚠ phân tích tĩnh — không bắt CVE "nhét công cụ vào container" → ⚠ chống chỉ định

⚠ Vì sao image base là rủi ro lớn nhất Lý do
⚠ Kế thừa MỌI lỗ hổng của image base
⚠ Image base cũ tích tụ hàng trăm CVE
⚠ Dùng image tối giản ⚠ distroless, alpine — ít gói, ít lỗ hổng
⚠ Ghim phiên bản base rõ ràng ⚠ đừng dùng latest
Xây lại image định kỳ ⚠ để lấy bản vá mới
⚠ Quét là chưa đủ — cần hành động Hành động
⚠ Đặt NGƯỠNG chặn ⚠ CVE mức critical thì không cho phát hành
⚠ Binary Authorization thực thi ngưỡng đó
⚠ Quy trình xử lý CVE mới phát hiện ⚠ image đang chạy cũng có thể có CVE mới
⚠ Chỉ quét mà không chặn ⚠ báo cáo không ai đọc
⚠ Lỗ hổng xuất hiện SAU khi triển khai Vấn đề
⚠ CVE mới được công bố mỗi ngày
⚠ Image sạch hôm qua có thể có lỗ hổng hôm nay
⚠ Cần quét LẠI liên tục, không chỉ lúc build
Có quy trình vá khẩn cấp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ngưỡng chặn phát hành không | ⚠ quét mà không chặn là vô ích | | Image base cũ tới mức nào | | | Image đang chạy có được quét lại không | ⚠ CVE mới xuất hiện liên tục |

Và điểm hay bị bỏ qua nhất trong bảo mật container: quét chỉ có giá trị khi có ai đó hành động theo kết quả. Nhiều tổ chức bật quét, nhận hàng nghìn cảnh báo, rồi không ai xử lý — kết quả không khác gì không quét.

Câu 43
As a digital marketing agency, how can we securely access application secrets and easily rotate them in case of a security breach during the deployment of our applications through a CI/CD pipeline using Google Cloud services?
  1. A To securely manage sensitive information, it is recommended to store secrets in a dedicated configuration file on Git and grant access to the file only to authorized developers.
  2. B Developers should be prompted for secrets during build time and should be instructed to avoid storing secrets while at rest.
  3. C It is recommended to encrypt any confidential information and keep it in the source code repository. Additionally, store the decryption key in a distinct repository and provide access to it for your pipeline.
  4. D To secure your secrets, store them in Cloud Storage and encrypt them using a key from Cloud KMS. Grant access to Cloud KMS through IAM to the CI/CD pipeline.
Xem giải thích

Đáp án

D — Lưu secret trong Cloud Storage và mã hoá bằng khoá từ Cloud KMS; cấp quyền truy cập Cloud KMS cho pipeline CI/CD qua IAM.

Vì sao đúng

Đề nêu hai yêu cầu: truy cập an toàn và dễ xoay vòng khi bị lộ.

⚠ Vì sao cách này đáp ứng:

⚠ Secret mã hoá bằng khoá KMS
   → ⚠ khoá KHÔNG nằm cùng dữ liệu
        ↓
⚠ Quyền qua IAM
   → ⚠ thu hồi được ngay lập tức
   → ⚠ ghi vết ai truy cập
        ↓
⚠ Xoay vòng
   → ⚠ đổi khoá trong KMS
   → ⚠ không phải sửa mã nguồn

⚠ Lưu ý thực tế: Secret Manager là dịch vụ chuyên cho việc này và thường được khuyến nghị hơn. Trong bốn phương án đã cho, D là phương án đúng duy nhất.

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

  • C (mã hoá và lưu trong repo mã nguồn, khoá giải mã ở repo riêng) — ⚠ bẫy gần nhất: tách khoá ra repo khác nghe an toàn hơn, nhưng ⚠ khoá vẫn nằm trong Git — lịch sử Git giữ mãi, và ⚠ xoay vòng phải commit lại.

  • A (lưu secret trong file cấu hình trên Git, chỉ cấp quyền cho lập trình viên được uỷ quyền) — ⚠ VI PHẠM nguyên tắc cơ bản: ⚠ không bao giờ commit secret vào Git, kể cả repo riêng tư.

  • B (hỏi lập trình viên nhập secret lúc build, không lưu ở đâu) — ⚠ phá vỡ tự động hoá: CI/CD phải chạy không cần người; và ⚠ không xoay vòng có kiểm soát được.

Ghi nhớ

⚠ Thang bậc quản lý secret — bảng phải thuộc: | Cách | Đánh giá | |---|---| | ⚠ Secret Manager | ⚠ tốt nhất — chuyên dụng | | ⚠ KMS + lưu trữ có kiểm soát | ⚠ tốt — đề này | | Biến môi trường trong CI | ⚠ chấp nhận được, khó xoay vòng | | ⚠ Secret trong Git | ⚠ LUÔN SAI | | ⚠ Nhập tay lúc build | ⚠ phá tự động hoá |

Từ khoá nhận diện:

"an toàn + dễ xoay vòng" → ⚠ Secret Manager hoặc KMS "lưu trong Git" → ⚠ luôn SAI "khoá ở repo khác" → ⚠ vẫn trong Git, vẫn sai "nhập tay lúc build" → ⚠ không tự động hoá được

⚠ Vì sao secret trong Git nguy hiểm Lý do
⚠ Lịch sử Git giữ MÃI MÃI ⚠ xoá file không đủ
⚠ Ai clone repo là có secret
⚠ Repo có thể bị công khai nhầm
⚠ Fork, mirror lan ra không kiểm soát
⚠ Nếu lỡ commit ⚠ phải XOAY VÒNG secret, không chỉ xoá file
⚠ Xoay vòng secret cần gì Cần
⚠ Đổi được mà không sửa mã
⚠ Ứng dụng đọc secret lúc chạy ⚠ không nhúng lúc build
⚠ Hỗ trợ hai phiên bản cùng lúc ⚠ để chuyển đổi không gián đoạn
Ghi vết lần truy cập
⚠ Xoay vòng tự động theo lịch ⚠ Secret Manager hỗ trợ
⚠ Quyền cho pipeline CI/CD Quyền
⚠ Service account RIÊNG cho pipeline ⚠ không dùng chung
⚠ Quyền tối thiểu ⚠ chỉ đọc secret cần thiết
⚠ Tách theo môi trường ⚠ pipeline dev không đọc secret prod
Ghi vết mọi lần truy cập

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ử, không chỉ bản hiện tại | | Xoay vòng secret mất bao lâu | ⚠ thử một lần trước khi cần thật | | Pipeline dev có đọc được secret prod không | |

Và điều phải làm ngay khi phát hiện secret lọt vào Git: XOAY VÒNG secret đó, đừng chỉ xoá file. Lịch sử Git đã lan ra mọi bản clone — secret đó phải coi như đã lộ vĩnh viễn.

Câu 44
As a provider of home security systems, how can we use Google Cloud Services to export and store application logs for seven years while minimizing the storage costs?
  1. A Create an application on App Engine that retrieves logs from Cloud and stores them in BigQuery.
  2. B Configure Cloud Pub/Sub to store logs in a durable storage for a period of seven years by creating an export in Google Cloud.
  3. C Develop your application to send logs directly to a Cloud Storage bucket that you have created.
  4. D To export logs, first create a Cloud sink, give it a name, create a Cloud Storage bucket for the archived logs, and finally choose the bucket as the destination for log export.
Xem giải thích

Đáp án

D — Tạo một log sink: đặt tên, tạo bucket Cloud Storage cho log lưu trữ, rồi chọn bucket đó làm đích xuất log.

Vì sao đúng

Đề nêu hai yêu cầu: lưu 7 năm và chi phí thấp nhất.

⚠ Vì sao Cloud Storage là đích rẻ nhất:

⚠ Log sink là cơ chế XUẤT chuẩn
        ↓
⚠ Cloud Storage rẻ hơn nhiều so với:
   → ⚠ giữ trong Cloud Logging
   → ⚠ lưu trong BigQuery
        ↓
⚠ Còn có HẠNG LƯU TRỮ rẻ hơn nữa
   → ⚠ Nearline, Coldline, ARCHIVE

⚠ Với lưu trữ 7 năm:

⚠ Đặt quy tắc VÒNG ĐỜI
   → ⚠ tự chuyển sang Archive sau N ngày
   → ⚠ tự xoá sau 7 năm
        ↓
⚠ Chi phí thấp nhất có thể

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

  • A (viết ứng dụng trên App Engine lấy log rồi ghi vào BigQuery) — ⚠ bẫy "tự làm": ⚠ tự viết lại thứ đã có sẵn, và ⚠ BigQuery đắt hơn nhiều cho lưu trữ dài hạn thuần tuý.

  • B (cấu hình Pub/Sub để lưu log 7 năm) — ⚠ hiểu sai bản chất Pub/Sub: nó là hàng đợi truyền tin, ⚠ không phải kho lưu trữ; tin nhắn có thời hạn giữ tối đa rất ngắn.

  • C (sửa ứng dụng ghi thẳng log vào bucket) — ⚠ bỏ qua Cloud Logging: mất khả năng tìm kiếm, cảnh báo, và ⚠ phải tự lo xoay vòng, định dạng, độ tin cậy.

Ghi nhớ

⚠ Chọn đích xuất log theo mục đích — bảng phải thuộc: | Đích | Dùng khi | |---|---| | ⚠ Cloud Storage | ⚠ lưu trữ dài hạn, RẺ NHẤT — đề này | | 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 thời hạn lưu trong Logging |

Từ khoá nhận diện:

"lưu trữ dài hạn, chi phí thấp nhất" → ⚠ Cloud Storage + lifecycle "truy vấn SQL trên log" → ⚠ BigQuery "đẩy sang SIEM bên ngoài" → ⚠ Pub/Sub "Pub/Sub lưu trữ lâu dài" → ⚠ hiểu sai — nó là hàng đợi

⚠ Hạng lưu trữ Cloud Storage — bảng phải thuộc Hạng
Standard ⚠ truy cập thường xuyên
Nearline ⚠ khoảng 1 lần/tháng
Coldline ⚠ khoảng 1 lần/quý
⚠ Archive ⚠ RẺ NHẤT, cho log 7 năm
⚠ Lưu ý ⚠ hạng lạnh có phí lấy dữ liệu ra và thời gian lưu tối thiểu
⚠ Quy tắc vòng đời nên đặt Quy tắc
⚠ Sau 30 ngày → Nearline
⚠ Sau 90 ngày → Coldline
⚠ Sau 365 ngày → Archive
⚠ Sau 7 năm → XOÁ ⚠ đừng giữ quá thời hạn cần thiết
Lý do xoá ⚠ giữ dữ liệu quá lâu là rủi ro pháp lý
⚠ Lưu ý khi lưu log dài hạn Lưu ý
⚠ Log có thể chứa PII ⚠ 7 năm là rất dài với dữ liệu cá nhân
⚠ Lọc bớt log không cần trước khi xuất ⚠ giảm chi phí đáng kể
⚠ Bật Bucket Lock nếu cần bất biến ⚠ yêu cầu tuân thủ
Kiểm quyền truy cập bucket

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có quy tắc vòng đời chưa | ⚠ để Standard 7 năm là rất tốn | | Log xuất ra có chứa PII không | | | Có lọc bớt log rác trước khi xuất không | ⚠ giảm chi phí nhiều nhất |

Và cách tiết kiệm lớn nhất khi lưu log dài hạn không phải chọn hạng rẻ, mà là lọc bớt thứ không cần lưu ngay từ đầu. Phần lớn log debug không có giá trị sau 30 ngày, nhưng vẫn tốn tiền suốt 7 năm nếu không ai lọc.

Câu 45
As a food delivery company, your team uses Cloud Build for all CI/CD pipelines. You want to use the kubectl builder for Cloud Build to deploy new images to Google Kubernetes Engine(GKE). You need to authenticate to GKE while minimizing development effort. What steps should you take?
  1. A To execute Cloud Build, generate a fresh service account with Container Developer privileges.
  2. B In Cloud Build, add a distinct stage to fetch the service account credentials and transfer them to kubectl.
  3. C Grant the Cloud Build service account the role of a Container Developer.
  4. D In the cloudbuild.yaml file, define the role of Container Developer for Cloud Build.
Xem giải thích

Đáp án

C — Cấp cho service account của Cloud Build vai trò Container Developer.

Vì sao đúng

Đề yêu cầu xác thực tới GKE với công sức phát triển tối thiểu. Cloud Build đã có sẵn một service account — chỉ cần cấp đúng quyền.

⚠ Vì sao đơn giản nhất:

⚠ Cloud Build có SẴN service account
        ↓
⚠ Cấp role container.developer cho nó
        ↓
⚠ Bước kubectl TỰ dùng danh tính đó
        ↓
⚠ KHÔNG phải viết code, không phải
  quản lý khoá

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

  • A (tạo service account MỚI với quyền Container Developer để chạy Cloud Build) — ⚠ bẫy gần nhất và làm được: nhưng ⚠ thêm việc quản lý một danh tính nữa, trong khi đề nói tối thiểu công sức. ⚠ Lưu ý: về mặt bảo mật, dùng service account riêng có thể tốt hơn — nhưng đề ưu tiên đơn giản.

  • B (thêm một bước lấy thông tin xác thực service account rồi truyền cho kubectl) — ⚠ nhiều công sức nhất: viết code, xử lý khoá, ⚠ tạo rủi ro lộ khoá.

  • D (khai vai trò Container Developer trong file cloudbuild.yaml) — ⚠ bất khả thi: ⚠ vai trò IAM không khai trong file cấu hình build; IAM được cấp ở mức tài nguyên Google Cloud.

Ghi nhớ

⚠ Service account của Cloud Build — bảng phải thuộc: | Điểm | Nội dung | |---|---| | ⚠ Có sẵn khi bật Cloud Build | | | ⚠ Cấp thêm role qua IAM khi cần | | | ⚠ Dùng được service account tuỳ chỉnh | ⚠ khi cần quyền hẹp hơn | | Không cần quản lý file khoá | ⚠ danh tính gắn với dịch vụ |

Từ khoá nhận diện:

"tối thiểu công sức phát triển" → ⚠ dùng service account có sẵn, chỉ cấp role "tự lấy và truyền credential" → ⚠ nhiều công sức, rủi ro lộ khoá "khai role trong file yaml" → ⚠ bất khả thi

⚠ Vai trò cho triển khai GKE Vai trò
⚠ Kubernetes Engine Developer ⚠ container.developer — triển khai workload
Kubernetes Engine Admin ⚠ quản lý cả cluster — quá rộng
Kubernetes Engine Cluster Viewer ⚠ chỉ xem
⚠ Nguyên tắc ⚠ chọn vai trò HẸP NHẤT đủ dùng
⚠ Vì sao KHÔNG nên dùng file khoá service account Lý do
⚠ File khoá có thể bị lộ
⚠ Phải xoay vòng thủ công
⚠ Khó truy vết ai dùng
Thay bằng ⚠ danh tính gắn với workload — Workload Identity
⚠ Trên GKE ⚠ Workload Identity là cách chuẩn cho pod truy cập API Google
⚠ Lưu ý bảo mật cho pipeline triển khai Lưu ý
⚠ Pipeline có quyền đẩy lên SẢN XUẤT ⚠ là mục tiêu tấn công giá trị cao
⚠ Tách service account theo môi trường ⚠ build dev không đẩy được lên prod
⚠ Yêu cầu duyệt trước khi triển khai prod
Ghi vết mọi lần triển khai
⚠ Binary Authorization ⚠ chỉ cho chạy image đã kiểm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Service account có quyền quá rộng không | ⚠ Admin thay vì Developer là rủi ro | | Pipeline dev có đẩy được lên prod không | | | Có file khoá service account nào đang lưu không | ⚠ nên thay bằng danh tính gắn với dịch vụ |

Và rủi ro thường bị đánh giá thấp: pipeline CI/CD có quyền cao hơn hầu hết nhân viên. Nó đẩy được mã lên sản xuất, đọc được secret — nên quyền của nó phải hẹp và được rà soát như quyền của một quản trị viên.

Câu 46
As a provider of Robotic Process Automation solutions, you are managing the production deployment of your software to a set of Google Kubernetes Engine (GKE) clusters. How can you ensure that only images that are successfully built by your trusted CI/CD pipeline are deployed to production?
  1. A Configure the Kubernetes Engine clusters to utilize Binary Authorization.
  2. B Activate Vulnerability Analysis for the Container Registry.
  3. C Configure the Kubernetes Engine clusters to function as private clusters.
  4. D Activate Cloud Security Scanner for the clusters.
Xem giải thích

Đáp án

A — Cấu hình các cluster Kubernetes Engine sử dụng Binary Authorization.

Vì sao đúng

Đề cần CHẶN việc triển khai image không đến từ pipeline tin cậy. Binary Authorization làm đúng việc đó.

⚠ Cách hoạt động:

⚠ Pipeline CI/CD build image
        ↓
⚠ Tạo ATTESTATION (chứng thực)
   → ⚠ "image này đã qua build và
     kiểm thử của tôi"
        ↓
⚠ Khi triển khai lên GKE:
   → ⚠ Binary Authorization KIỂM tra
     chứng thực
   → ⚠ KHÔNG có → TỪ CHỐI triển khai

⚠ Điểm mấu chốt: nó là cơ chế THỰC THI, không chỉ cảnh báo.

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

  • B (bật Vulnerability Analysis cho Container Registry) — ⚠ bẫy gần nhất: quét lỗ hổng rất hữu ích, nhưng ⚠ chỉ BÁO CÁO, không CHẶN triển khai. Image có CVE vẫn deploy được nếu không có cơ chế thực thi.

  • C (đặt cluster ở chế độ private cluster) — ⚠ giải bài toán MẠNG: node không có IP công khai. ⚠ Không liên quan tới việc image nào được phép chạy.

  • D (bật Cloud Security Scanner cho cluster) — ⚠ sai công cụ: Web Security Scanner quét lỗ hổng ứng dụng web (XSS, injection), không kiểm soát nguồn gốc image.

Ghi nhớ

⚠ Bảo mật chuỗi cung ứng — quét và thực thi — bảng phải thuộc: | Lớp | Công cụ | Loại | |---|---|---| | Quét lỗ hổng image | ⚠ Container/Artifact Analysis | ⚠ BÁO CÁO | | ⚠ Chặn image không tin cậy | ⚠ Binary Authorization | ⚠ THỰC THI — đề này | | Quét web app | ⚠ Web Security Scanner | báo cáo | | Cách ly mạng | ⚠ private cluster | mạng |

Từ khoá nhận diện:

"chỉ cho triển khai image từ pipeline tin cậy" → ⚠ Binary Authorization "quét CVE" → ⚠ Container Analysis — chỉ báo cáo "node không có IP công khai" → ⚠ private cluster "quét XSS, injection" → ⚠ Web Security Scanner

⚠ Binary Authorization hoạt động ra sao Thành phần
⚠ Attestor ⚠ thực thể có quyền chứng thực
⚠ Attestation ⚠ chữ ký xác nhận image đã qua bước nào
⚠ Policy ⚠ quy định image cần chứng thực nào
⚠ Enforcement ⚠ chặn hoặc chỉ ghi log (dry-run)
Nên bắt đầu ⚠ chế độ dry-run để xem sẽ chặn gì
⚠ Chính sách nên đặt thế nào Chính sách
⚠ Yêu cầu chứng thực từ pipeline CI
⚠ Yêu cầu quét lỗ hổng đã qua
⚠ Cho phép ngoại lệ có kiểm soát ⚠ break-glass cho sự cố khẩn
⚠ Ghi vết mọi lần dùng ngoại lệ
Khác nhau theo môi trường ⚠ prod chặt hơn dev
⚠ Vì sao "quét" không đủ mà cần "chặn" Lý do
⚠ Báo cáo chỉ có giá trị nếu có người đọc và hành động
⚠ Áp lực tiến độ → bỏ qua cảnh báo
⚠ Thực thi tự động không phụ thuộc kỷ luật con người
Nguyên tắc ⚠ kiểm soát tự động > quy trình dựa vào ý thức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có triển khai được image tự build lên prod không | ⚠ thử — phải bị chặn | | Ngoại lệ break-glass có được ghi vết không | | | Chính sách prod có chặt hơn dev không | |

Và điểm phân biệt then chốt giữa hai loại công cụ bảo mật: quét cho bạn BIẾT, thực thi khiến bạn KHÔNG THỂ làm sai. Với sản xuất, cái thứ hai đáng tin hơn nhiều.

Câu 47
As a Logistics and Shipping solution company, you experienced a major service outage that affected all users of the service for multiple hours. After several hours of incident management, the service returned to normal, and user access was restored. What would be the first step to provide an incident summary to relevant stakeholders following the Site Reliability Engineering recommended practices using Google Cloud Services?
  1. A Contact each stakeholder individually to provide an explanation of the situation.
  2. B Distribute the Incident State Document to all the concerned parties.
  3. C Create a post-incident report that can be shared with relevant parties.
  4. D The responsible engineer should draft and send an email expressing apologies to all the stakeholders.
Xem giải thích

Đáp án

C — Lập một báo cáo hậu sự cố (post-incident report) có thể chia sẻ với các bên liên quan.

Vì sao đúng

Đề nêu rõ: sự cố đã được khắc phục, dịch vụ đã trở lại bình thường, và cần tổng kết cho bên liên quan.

⚠ Vì sao báo cáo hậu sự cố là bước đầu:

⚠ Sự cố đã xong
        ↓
⚠ Cần MỘT nguồn thông tin THỐNG NHẤT
   → ⚠ chuyện gì xảy ra
   → ⚠ ảnh hưởng tới đâu
   → ⚠ đã sửa thế nào
   → ⚠ sẽ ngăn ngừa ra sao
        ↓
⚠ Chia sẻ cho MỌI bên liên quan

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

  • B (phát tán Incident State Document cho mọi bên liên quan) — ⚠ bẫy gần nhất: tài liệu trạng thái sự cố là bản ghi TRONG LÚC xử lý — ⚠ hỗn độn, kỹ thuật, nhiều thông tin chưa xác nhận. ⚠ Không phải tài liệu để công bố.

  • A (liên hệ RIÊNG từng bên liên quan để giải thích) — ⚠ không mở rộng được và ⚠ thông điệp không nhất quán — mỗi người nghe một kiểu.

  • D (kỹ sư phụ trách viết email xin lỗi gửi mọi bên) — ⚠ sai người và sai nội dung: ⚠ quy trách nhiệm cho một kỹ sư đi ngược blameless, và ⚠ lời xin lỗi không thay được phân tích.

Ghi nhớ

⚠ Ba loại tài liệu trong vòng đời sự cố — bảng phải thuộc: | Tài liệu | Khi nào | Cho ai | |---|---|---| | ⚠ Incident State Document | ⚠ TRONG lúc xử lý | ⚠ đội ứng cứu | | Cập nhật trạng thái | ⚠ trong lúc xử lý | ⚠ bên liên quan, khách hàng | | ⚠ Post-incident report | ⚠ SAU khi khắc phục | ⚠ mọi bên — đề này |

Từ khoá nhận diện:

"tổng kết sau khi khắc phục" → ⚠ post-incident report "tài liệu trạng thái đang xử lý" → ⚠ nội bộ, không công bố "liên hệ riêng từng người" → ⚠ không nhất quán, không mở rộng được "email xin lỗi từ kỹ sư" → ⚠ sai người, đi ngược blameless

⚠ Báo cáo hậu sự cố nên có gì Có
⚠ Tóm tắt ngắn gọn cho người không kỹ thuật
⚠ Mốc thời gian
⚠ Tác động cụ thể ⚠ bao nhiêu người dùng, bao lâu
⚠ Nguyên nhân gốc
⚠ Hành động phòng ngừa có chủ sở hữu và hạn
⚠ KHÔNG có ⚠ tên người bị quy trách nhiệm
⚠ Viết cho hai đối tượng Đối tượng
⚠ Bên liên quan nghiệp vụ ⚠ tác động, thời gian, cam kết ngăn ngừa
⚠ Đội kỹ thuật ⚠ chi tiết kỹ thuật, bài học
Cách làm ⚠ một tài liệu, phần tóm tắt ở đầu cho người bận
⚠ Vì sao MỘT tài liệu tốt hơn nhiều cuộc gọi Lý do
⚠ Thông điệp nhất quán
⚠ Tra cứu lại được
⚠ Không tốn thời gian lặp lại
Đội khác học được
⚠ Vẫn nên có ⚠ buổi trao đổi cho bên liên quan quan trọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo có nêu tên buộc tội ai không | | | Người không kỹ thuật đọc có hiểu không | | | Hành động phòng ngừa có chủ sở hữu chưa | |

Và điều làm nên một báo cáo hậu sự cố tốt: nó trả lời được câu hỏi mà bên liên quan thật sự quan tâm — "chuyện này có xảy ra lại không?". Phân tích kỹ thuật hay tới đâu mà không trả lời được câu đó thì vẫn thiếu.

Câu 48
As an automated financial advisor company, how can you prepare for a predicted 10% month-over-month service user growth rate for the next six months while ensuring minimal negative impact for the users and avoiding unnecessary costs? Your service is fully containerized and runs on Google Cloud Platform (GCP), using a Google Kubernetes Engine(GKE) Standard regional cluster on three zones with cluster autoscaler enabled. You also require resilience against the failure of a zone.
  1. A As you are currently utilizing only 30%, you have a considerable amount of extra capacity available and there won't be any requirement of adding more capacity to accommodate this growth rate.
  2. B To ensure the required resources are met, you should validate the maximum node pool capacity, activate a horizontal pod autoscaler, and conduct a load test.
  3. C Your GKE cluster will automatically scale irrespective of the growth rate since it is using a cluster autoscaler and is deployed on GKE.
  4. D To ensure sufficient capacity, it is recommended to add 60% more node capacity in advance for a 10% growth rate over six months, followed by conducting a load test.
Xem giải thích

Đáp án

B — Kiểm tra sức chứa tối đa của node pool, bật horizontal pod autoscaler, và chạy kiểm thử tải.

Vì sao đúng

Đề nêu tăng trưởng 10% mỗi tháng trong sáu tháng (tổng khoảng +77%), yêu cầu ít ảnh hưởng người dùng và không tốn chi phí thừa.

⚠ Ba việc và lý do:

⚠ KIỂM TRẦN NODE POOL
   → ⚠ cluster autoscaler có GIỚI HẠN TRÊN
   → ⚠ chạm trần là không mở rộng nữa

⚠ BẬT HORIZONTAL POD AUTOSCALER
   → ⚠ cluster autoscaler thêm NODE
   → ⚠ HPA thêm POD
   → ⚠ THIẾU HPA thì thêm node cũng vô ích

⚠ CHẠY LOAD TEST
   → ⚠ xác minh thật, không phỏng đoán

⚠ Điểm mấu chốt: cluster autoscaler và HPA là HAI cơ chế KHÁC NHAU, cần cả hai.

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

  • C (cluster autoscaler tự lo hết bất kể tốc độ tăng trưởng) — ⚠ bẫy mạnh nhất: ⚠ cluster autoscaler chỉ thêm NODE khi có pod PENDING. ⚠ Không có HPA thì số pod không tăng → không có pod pending → không thêm node.

  • D (thêm trước 60% năng lực node cho mức tăng 10% trong sáu tháng) — ⚠ lãng phí lớn: trả tiền cho năng lực chưa dùng suốt nhiều tháng, ⚠ đi ngược yêu cầu "tránh chi phí không cần thiết".

  • A (đang dùng 30% nên còn thừa nhiều, không cần làm gì) — ⚠ nguy hiểm: ⚠ không tính tới lỗi zone. Cluster ba zone mà mất một zone thì chỉ còn hai — mức dùng thực tế tăng vọt.

Ghi nhớ

⚠ Hai loại autoscaler trên GKE — bảng phải thuộc: | Loại | Thêm gì | Kích hoạt bởi | |---|---|---| | ⚠ Horizontal Pod Autoscaler | ⚠ thêm POD | ⚠ CPU, bộ nhớ, chỉ số tuỳ chỉnh | | ⚠ Cluster Autoscaler | ⚠ thêm NODE | ⚠ pod PENDING không xếp được | | Vertical Pod Autoscaler | ⚠ chỉnh request/limit của pod | | | ⚠ Quan hệ | ⚠ HPA tạo pod → pod pending → CA thêm node |

Từ khoá nhận diện:

"chuẩn bị tăng trưởng, không tốn thừa" → ⚠ kiểm trần + HPA + load test "cluster autoscaler tự lo hết" → ⚠ SAI nếu không có HPA "thêm trước thật nhiều" → ⚠ lãng phí "còn thừa nhiều nên không cần làm gì" → ⚠ quên tính lỗi zone

⚠ Vì sao phải tính dư cho lỗi zone Lý do
⚠ Cluster 3 zone, mất 1 zone → còn 2/3 năng lực
⚠ Mức dùng 30% × 1,5 = 45% ngay lập tức
⚠ Cộng thêm tăng trưởng 77% → chạm trần
Nguyên tắc ⚠ luôn tính năng lực còn lại SAU khi mất một zone
⚠ Kiểm thử tải cần gì Cần
⚠ Mô phỏng tải THẬT, không phải tải đều ⚠ có đỉnh, có mẫu hình
⚠ Tăng dần tới mức mục tiêu và hơn
⚠ Quan sát chỉ số trong lúc chạy
⚠ Thử cả kịch bản mất một zone
Mục đích ⚠ tìm điểm gãy TRƯỚC khi người dùng tìm ra
⚠ Cấu hình HPA cho đúng Cấu hình
⚠ Chọn chỉ số phản ánh tải thật ⚠ CPU không phải lúc nào cũng đúng
⚠ Đặt minReplicas đủ cho lỗi zone
⚠ Đặt maxReplicas có tính tới trần node
Chú ý thời gian khởi động pod ⚠ pod chậm khởi động thì HPA phản ứng chậm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trần node pool là bao nhiêu | ⚠ chạm trần là hết co giãn | | Có HPA chưa | ⚠ thiếu nó thì CA vô dụng | | Mất một zone thì còn đủ năng lực không | ⚠ thử thật trong load test |

Và hiểu lầm phổ biến nhất về autoscaling trên Kubernetes: tưởng cluster autoscaler tự lo mọi thứ. Nó chỉ phản ứng khi có pod không xếp được — mà pod chỉ tăng khi có HPA. Thiếu một mắt xích là cả chuỗi không hoạt động.

Câu 49
As a personalized nutrition service company, you use Cloud Build to build your application. How can you minimize the build time while reducing development effort and cost?
  1. A Utilize the machine-type option to employ bigger virtual machines (VMs) in Cloud Build.
  2. B To reduce execution time, it is advisable to employ several smaller build steps.
  3. C Utilize Cloud Storage for caching intermediate artifacts.
  4. D To parallelize the build, execute numerous Jenkins agents.
Xem giải thích

Đáp án

C — Dùng Cloud Storage để cache các artefact trung gian.

Vì sao đúng

Đề cần rút ngắn thời gian build, đồng thời giảm công sức phát triển và chi phí.

⚠ Vì sao cache hiệu quả nhất:

⚠ Phần lớn thời gian build là
  TẢI VÀ DỰNG LẠI thứ KHÔNG ĐỔI
   → ⚠ thư viện phụ thuộc
   → ⚠ lớp image trung gian
        ↓
⚠ Cache lại → lần sau dùng lại
        ↓
⚠ Thời gian giảm mạnh
⚠ Chi phí giảm theo
   → ⚠ Cloud Build tính theo PHÚT

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

  • A (dùng máy ảo lớn hơn qua tuỳ chọn machine-type) — ⚠ bẫy hợp lý: nhanh hơn thật, nhưng ⚠ TỐN TIỀN HƠN — đi ngược yêu cầu giảm chi phí. ⚠ Và nếu nghẽn ở tải phụ thuộc thì máy to cũng không giúp.

  • B (chia thành nhiều bước build nhỏ hơn) — ⚠ không tự nó rút ngắn: chia nhỏ chỉ giúp nếu ⚠ chạy SONG SONG; chia nhỏ mà vẫn tuần tự thì tổng thời gian không đổi.

  • D (chạy nhiều Jenkins agent để song song hoá) — ⚠ đi ngược đề bài: họ đang dùng Cloud Build; ⚠ thêm Jenkins là tăng công sức và chi phí vận hành.

Ghi nhớ

⚠ Cách rút ngắn thời gian build — bảng phải thuộc: | Cách | Đánh giá | |---|---| | ⚠ Cache artefact và lớp image | ⚠ hiệu quả nhất, rẻ — đề này | | ⚠ Chạy các bước song song | ⚠ dùng waitFor trong cloudbuild.yaml | | Máy ảo lớn hơn | ⚠ nhanh hơn nhưng ĐẮT hơn | | Giảm phạm vi build | ⚠ chỉ build phần thay đổi | | ⚠ Image base nhỏ | ⚠ tải nhanh hơn |

Từ khoá nhận diện:

"nhanh hơn + rẻ hơn + ít công sức" → ⚠ cache "máy to hơn" → ⚠ nhanh nhưng đắt hơn "chia nhỏ bước" → ⚠ chỉ giúp nếu chạy song song "thêm Jenkins" → ⚠ tăng công vận hành

⚠ Cache gì trong build Cache
⚠ Thư viện phụ thuộc ⚠ node_modules, .m2, pip cache
⚠ Lớp Docker image ⚠ kaniko cache hoặc --cache-from
⚠ Kết quả biên dịch trung gian
Artefact test
⚠ Lưu ở ⚠ Cloud Storage bucket
⚠ Lưu ý khi dùng cache Lưu ý
⚠ Cache CŨ có thể gây build sai ⚠ phải có khoá cache đúng
⚠ Khoá cache theo hash của file phụ thuộc ⚠ package-lock.json, go.sum
⚠ Dọn cache định kỳ ⚠ tránh phình dung lượng
Build sạch định kỳ ⚠ để phát hiện phụ thuộc ẩn
⚠ Tối ưu Dockerfile cho cache Tối ưu
⚠ Đặt lệnh ÍT THAY ĐỔI lên TRƯỚC
⚠ Copy file phụ thuộc rồi cài, TRƯỚC khi copy mã ⚠ mã đổi không phá cache thư viện
⚠ Dùng multi-stage build ⚠ image cuối nhỏ hơn
Image base nhỏ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thời gian build phân bổ ở bước nào | ⚠ đo trước khi tối ưu | | Cache có thật sự trúng không | ⚠ kiểm tỷ lệ cache hit | | Build sạch có ra kết quả giống không | ⚠ cache cũ có thể che lỗi |

Và bước đầu tiên trước mọi tối ưu build: đo xem thời gian thật sự đi đâu. Rất nhiều đội nâng cấp máy trong khi nghẽn thật nằm ở việc tải lại vài trăm megabyte thư viện mỗi lần build.

Câu 50
In a Personalized Nutrition Service company, the application is running on App Engine and is accessed globally through different devices. Which metric should be used in Cloud Monitoring for App Engine to determine the number of connections?
  1. A The current status of the connections can be viewed at fiex/connections/current.
  2. B The current connections to a specific instance can be found at fiex/instance/connections/current.
  3. C What does "tcp_ssl_proxy/new_connections" refer to?
  4. D The number of open connections for a TCP SSL proxy.
Xem giải thích

Đáp án

A — Chỉ số theo dõi số kết nối hiện tại: flex/connections/current.

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

⚠ Đây là câu bị hỏng nặng về trình bày — cần đọc kỹ trước khi ghi nhớ.

⚠ Ba lỗi trong bộ phương án:

Lỗi Chi tiết
⚠ Sai chính tả tên chỉ số ⚠ "fiex" thay vì "flex" — chữ l bị mất
⚠ Phương án C là CÂU HỎI BỎ LỬNG ⚠ "What does tcp_ssl_proxy/new_connections refer to?"
⚠ Phương án D là mô tả rời rạc ⚠ không phải một lựa chọn hoàn chỉnh

⚠ KHÔNG sửa khoá. Về mặt kiến thức, chỉ số đúng cho App Engine Flexible là appengine.googleapis.com/flex/connections/current.

⚠ Cách chấm khi gặp câu hỏng: loại các phương án không phải là câu trả lời (C và D ở đây), rồi chọn giữa phần còn lại theo kiến thức.

Vì sao đúng

⚠ Phân biệt hai chỉ số kết nối:

⚠ flex/connections/current
   → ⚠ tổng số kết nối hiện tại của
     TOÀN dịch vụ
   → ⚠ đúng câu hỏi "số lượng kết nối"

⚠ flex/instance/connections/current
   → ⚠ số kết nối theo TỪNG instance
   → ⚠ chi tiết hơn mức đề hỏi

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

  • B (flex/instance/connections/current — theo từng instance) — ⚠ bẫy gần nhất: đây là chỉ số có thật và hữu ích, nhưng ⚠ ở mức chi tiết hơn câu hỏi. Đề hỏi số kết nối nói chung.

  • C và D (về tcp_ssl_proxy) — ⚠ đó là chỉ số của TCP/SSL Proxy Load Balancer, ⚠ không phải của App Engine. Và cả hai đều không được viết thành phương án hoàn chỉnh.

Ghi nhớ

⚠ Chỉ số App Engine cần biết — bảng phải thuộc: | Nhóm chỉ số | Nội dung | |---|---| | ⚠ flex/connections/current | ⚠ kết nối hiện tại toàn dịch vụ — đề này | | flex/instance/… | ⚠ chi tiết theo instance | | http/server/response_count | ⚠ số phản hồi theo mã trạng thái | | http/server/response_latencies | ⚠ độ trễ | | flex/cpu/utilization | ⚠ mức dùng CPU |

Từ khoá nhận diện:

"App Engine Flexible" → ⚠ tiền tố flex/ "theo từng instance" → ⚠ thêm instance/ vào đường dẫn "tcp_ssl_proxy" → ⚠ chỉ số của LOAD BALANCER, không phải App Engine

⚠ Mẹo đọc tên chỉ số Google Cloud Mẹo
⚠ Tiền tố là DỊCH VỤ ⚠ appengine, compute, loadbalancing
⚠ Phần giữa là PHẠM VI ⚠ flex, instance, http
⚠ Phần cuối là ĐẠI LƯỢNG ⚠ current, count, latencies
Đọc từ trái sang ⚠ dịch vụ → phạm vi → đại lượng
⚠ Mẹo làm bài với câu hỏng Mẹo
⚠ Loại phương án không phải câu trả lời ⚠ câu hỏi, mô tả rời rạc
⚠ Bỏ qua lỗi chính tả rõ ràng ⚠ "fiex" hiển nhiên là "flex"
⚠ Chọn theo NGUYÊN LÝ, không theo ký tự
Đề thi thật ⚠ ít khi hỏng thế này, nhưng vẫn có thể có typo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng App Engine Standard hay Flexible | ⚠ chỉ số khác nhau | | Cần mức tổng hay mức instance | | | Chỉ số này có sẵn cho môi trường của bạn không | ⚠ tra bảng chỉ số chính thức |

Và kỹ năng cần có khi gặp câu hỏi hỏng: nhận ra đâu là lỗi trình bày và đâu là kiến thức thật. Ở đây "fiex" chỉ là lỗi gõ; điều cần nhớ là App Engine Flexible dùng tiền tố flex/.