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

Tìm thấy 269 câu.

Câu 31
As an online grocery delivery service, you want to deploy a new feature of your web application to production in a safe manner. How can you use Google Kubernetes Engine (GKE) to perform a phased rollout to half of the web server pods?
  1. A Implement NoExecute taints on Nodes.
  2. B To manage pods in parallel, utilize a stateful set.
  3. C Implement a rolling update with partitioning.
  4. D Incorporate a replica set into the deployment specifications.
Xem giải thích

Đáp án

C — Thực hiện rolling update có partition (phân vùng).

Vì sao đúng

Đề cần triển khai theo giai đoạn, chỉ tới MỘT NỬA số pod. Partition trong rolling update cho phép đúng điều đó.

⚠ Partition hoạt động thế nào:

⚠ Đặt partition = N
        ↓
⚠ Chỉ các pod có chỉ số >= N
  được cập nhật
        ↓
⚠ Phần còn lại GIỮ NGUYÊN bản cũ
        ↓
⚠ Quan sát, nếu ổn thì hạ partition
  để tiếp tục

⚠ Vì sao hợp với triển khai an toàn:

⚠ Chỉ một phần người dùng chịu rủi ro
⚠ So sánh được bản mới và cũ song song
⚠ Quay lui nhanh nếu có vấn đề

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

  • D (thêm replica set vào cấu hình deployment) — ⚠ hiểu sai cơ chế: ⚠ Deployment đã tự quản lý ReplicaSet; thêm vào không tạo ra triển khai theo giai đoạn.

  • B (dùng StatefulSet để quản lý pod song song) — ⚠ nhầm mục đích: StatefulSet dành cho ứng dụng có trạng thái, cần danh tính ổn định; ⚠ đề nói web server pods — thường là không trạng thái. ⚠ Lưu ý: StatefulSet cũng có partition, nhưng dùng nó chỉ để lấy partition là chọn sai loại workload.

  • A (đặt NoExecute taint lên node) — ⚠ taint dùng để ĐUỔI pod khỏi node, không phải để triển khai phiên bản mới.

Ghi nhớ

⚠ Các chiến lược triển khai trên GKE — bảng phải thuộc: | Chiến lược | Cách làm | |---|---| | ⚠ Rolling update | ⚠ thay dần pod, mặc định của Deployment | | ⚠ Rolling update + partition | ⚠ dừng ở một tỷ lệ để quan sát — đề này | | Blue-green | ⚠ hai môi trường song song, chuyển traffic | | Canary | ⚠ một phần nhỏ traffic sang bản mới | | Recreate | ⚠ xoá hết rồi tạo mới — có downtime |

Từ khoá nhận diện:

"triển khai theo giai đoạn, một nửa pod" → ⚠ rolling update có partition "một phần nhỏ traffic thử trước" → ⚠ canary "hai môi trường, chuyển toàn bộ" → ⚠ blue-green "taint" → ⚠ điều phối pod lên node, không phải triển khai

⚠ Tham số rolling update cần biết Tham số
⚠ maxSurge ⚠ tối đa bao nhiêu pod THÊM trong lúc cập nhật
⚠ maxUnavailable ⚠ tối đa bao nhiêu pod được phép ngừng
⚠ partition ⚠ dừng cập nhật ở chỉ số nào
minReadySeconds ⚠ chờ bao lâu trước khi coi pod là sẵn sàng
⚠ Readiness probe ⚠ quyết định pod có nhận traffic không
⚠ Vì sao readiness probe quan trọng khi rollout Lý do
⚠ Không có probe → pod chưa sẵn sàng đã nhận traffic
⚠ Rolling update tưởng thành công dù pod hỏng
⚠ Probe sai → rollout treo hoặc lỗi lan rộng
Đây là lỗi phổ biến nhất ⚠ khi triển khai trên Kubernetes
⚠ Quy trình triển khai an toàn Bước
⚠ 1. Triển khai một phần nhỏ
⚠ 2. QUAN SÁT chỉ số và log ⚠ tỷ lệ lỗi, độ trễ
⚠ 3. Tiếp tục nếu ổn
⚠ 4. Quay lui NGAY nếu xấu
Cần có sẵn ⚠ quy trình quay lui đã thử trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Readiness probe có đúng không | ⚠ lỗi phổ biến nhất khi rollout | | Quay lui mất bao lâu | ⚠ thử trước khi cần thật | | Có theo dõi chỉ số trong lúc rollout không | |

Và điều quan trọng hơn cả chiến lược triển khai: khả năng QUAY LUI nhanh. Triển khai từng phần chỉ có ý nghĩa nếu bạn phát hiện sớm và lùi được ngay — không thì nó chỉ làm sự cố lan chậm hơn.

Câu 32
As a language translation app company, your application images are built using Cloud Build and pushed to Google Container Registry (GCR). How can you specify a particular version of the app for deployment based on the release version tagged in source control when pushing the image?
  1. A To align the image with the tag in source control, utilize GCR digest versioning.
  2. B Incorporate the release version tag in the application image using Cloud Build.
  3. C Include the source control tag as a parameter in the image name.
  4. D Make a reference to the image digest within the source control tag.
Xem giải thích

Đáp án

B — Đưa tag phiên bản phát hành vào image ứng dụng ngay trong Cloud Build.

Vì sao đúng

Cloud Build có sẵn biến thay thế chứa thông tin từ hệ thống quản lý mã nguồn, trong đó có tag.

⚠ Cách làm:

⚠ Cloud Build cung cấp biến
   → ⚠ $TAG_NAME, $SHORT_SHA,
     $COMMIT_SHA

⚠ Dùng trong cấu hình:
   gcr.io/project/app:$TAG_NAME
        ↓
⚠ Image mang ĐÚNG tag của
  source control
        ↓
⚠ Truy vết được: image này từ
  commit nào

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

  • C (đưa tag của source control thành THAM SỐ trong TÊN image) — ⚠ bẫy rất gần: nghe gần giống B. Nhưng ⚠ tag của image tách biệt với tên image; gộp phiên bản vào TÊN tạo ra hàng loạt repository khác nhau thay vì nhiều tag của cùng một image.

  • A (dùng GCR digest versioning để khớp với tag) — ⚠ hiểu sai: ⚠ digest là mã băm nội dung, do hệ thống sinh ra; ⚠ không thể "khớp" nó với tag của bạn.

  • D (tham chiếu image digest bên trong tag của source control) — ⚠ ngược chiều và bất khả thi: tag mã nguồn được tạo TRƯỚC khi build, nên chưa thể biết digest.

Ghi nhớ

⚠ Biến thay thế của Cloud Build — bảng phải thuộc: | Biến | Nội dung | |---|---| | ⚠ $TAG_NAME | ⚠ tag Git kích hoạt build | | ⚠ $BRANCH_NAME | ⚠ tên nhánh | | ⚠ $COMMIT_SHA | ⚠ mã băm commit đầy đủ | | ⚠ $SHORT_SHA | ⚠ 7 ký tự đầu | | $BUILD_ID | ⚠ id của lần build | | $PROJECT_ID | |

Từ khoá nhận diện:

"gắn phiên bản vào image theo tag mã nguồn" → ⚠ biến thay thế trong Cloud Build "digest" → ⚠ mã băm nội dung, hệ thống sinh, không đặt được "đưa phiên bản vào TÊN image" → ⚠ sai — phiên bản thuộc TAG

⚠ Tag khác Digest thế nào Khác
⚠ TAG ⚠ nhãn người đặt, CÓ THỂ DI CHUYỂN
⚠ DIGEST ⚠ băm nội dung, BẤT BIẾN
⚠ Cùng tag có thể trỏ image khác nhau theo thời gian ⚠ nguy hiểm cho sản xuất
⚠ Digest luôn trỏ đúng một image
Khuyến nghị ⚠ triển khai sản xuất nên GHIM theo DIGEST
⚠ Chiến lược gắn tag tốt Chiến lược
⚠ Gắn NHIỀU tag cho cùng image ⚠ v1.2.3, commit sha, latest
⚠ Tag phiên bản ngữ nghĩa cho phát hành
⚠ Tag commit sha để truy vết chính xác
⚠ Tránh dựa vào tag latest khi triển khai ⚠ không biết đang chạy gì
Nguyên tắc ⚠ luôn truy được image nào từ commit nào
⚠ Vì sao truy vết quan trọng Lý do
⚠ Sự cố xảy ra → cần biết đang chạy code nào
⚠ Quay lui cần biết bản trước là gì
⚠ Kiểm toán bảo mật cần chuỗi nguồn gốc
Binary Authorization ⚠ chỉ cho chạy image đã ký và đã kiểm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Image đang chạy trong sản xuất từ commit nào | ⚠ phải trả lời được ngay | | Có dùng tag latest trong sản xuất không | ⚠ rủi ro | | Có ghim theo digest không | |

Và nguyên tắc bất biến trong triển khai container: tag có thể di chuyển, digest thì không. Với sản xuất, ghim theo digest là cách duy nhất chắc chắn biết chính xác mình đang chạy gì.

Câu 33
As a virtual reality game developer, which application in our organization is suitable for preemptible VM instances on Google Cloud to help reduce VM costs?
  1. A This solution involves a video rendering platform that is accelerated by GPU and utilizes a storage bucket for retrieving and storing videos.
  2. B A NoSQL database cluster that is distributed and eventually consistent, having adequate quorum.
  3. C An in-memory caching system with the ability to scale.
  4. D The website that the organization presents to the public.
Xem giải thích

Đáp án

A — Nền tảng render video tăng tốc bằng GPU, đọc và ghi video vào một storage bucket.

Vì sao đúng

Preemptible VM (và Spot VM) rẻ hơn nhiều nhưng ⚠ có thể bị thu hồi bất cứ lúc nào và ⚠ tối đa 24 giờ. Nên chỉ hợp với việc chịu được gián đoạn.

⚠ Vì sao render video hợp:

⚠ Xử lý theo LÔ, không ai chờ trực tiếp
⚠ Chia được thành nhiều phần nhỏ
⚠ Đọc/ghi qua BUCKET
   → ⚠ trạng thái nằm NGOÀI máy
   → ⚠ máy bị thu hồi thì chạy lại
     phần đó thôi
⚠ Tốn GPU → tiết kiệm rất đáng kể

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

  • D (website công khai của tổ chức) — ⚠ sai nghiêm trọng nhất: dịch vụ đối mặt người dùng ⚠ không chịu được việc máy biến mất đột ngột.

  • C (hệ thống cache trong bộ nhớ có khả năng co giãn) — ⚠ bẫy hợp lý: cache mất thì "chỉ" phải nạp lại. Nhưng ⚠ mất cache đột ngột gây bão truy vấn xuống CSDL, có thể sập cả hệ thống.

  • B (cụm CSDL NoSQL phân tán, nhất quán cuối cùng, có đủ quorum) — ⚠ bẫy tinh vi nhất: có quorum nên nghe như chịu được mất node. Nhưng ⚠ preemptible có thể thu hồi NHIỀU node CÙNG LÚC — mất quorum là mất dữ liệu. ⚠ CSDL là trạng thái, không nên đặt trên máy có thể biến mất.

Ghi nhớ

⚠ Việc nào hợp với preemptible/Spot VM — bảng phải thuộc: | Hợp | Không hợp | |---|---| | ⚠ Render, mã hoá video | ⚠ dịch vụ đối mặt người dùng | | ⚠ Xử lý theo lô, ETL | ⚠ cơ sở dữ liệu | | ⚠ Huấn luyện ML có checkpoint | ⚠ cache trong bộ nhớ | | CI/CD build worker | ⚠ hệ thống có trạng thái | | Phân tích dữ liệu lớn | ⚠ việc cần chạy liên tục quá 24 giờ |

Từ khoá nhận diện:

"xử lý theo lô, chịu được gián đoạn, trạng thái ở ngoài" → ⚠ preemptible hợp "đối mặt người dùng, cơ sở dữ liệu, cache" → ⚠ KHÔNG hợp "có quorum nên an toàn" → ⚠ bẫy — nhiều node có thể mất cùng lúc

⚠ Đặc điểm của preemptible/Spot VM Đặc điểm
⚠ Rẻ hơn rất nhiều ⚠ thường 60–91%
⚠ Có thể bị thu hồi BẤT CỨ LÚC NÀO
⚠ Preemptible: tối đa 24 giờ ⚠ Spot VM không giới hạn 24h nhưng vẫn bị thu hồi
⚠ Báo trước 30 giây ⚠ đủ để lưu checkpoint
Không có SLA
⚠ Thiết kế để chịu được thu hồi Thiết kế
⚠ Lưu CHECKPOINT thường xuyên
⚠ Trạng thái ở NGOÀI máy ⚠ bucket, CSDL quản lý
⚠ Chia việc thành phần nhỏ, idempotent
⚠ Bắt tín hiệu shutdown 30 giây ⚠ lưu nốt rồi thoát sạch
Hàng đợi công việc để chạy lại phần dở
⚠ Kiến trúc hỗn hợp thường dùng Kiến trúc
⚠ Node thường cho phần quan trọng
⚠ Node preemptible cho phần chịu được gián đoạn
Trên GKE: node pool riêng ⚠ kèm taint và toleration
⚠ Lưu ý ⚠ đừng để pod hệ thống chạy trên node preemptible

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mất máy giữa chừng thì mất bao nhiêu công | ⚠ quyết định tần suất checkpoint | | Trạng thái có nằm ngoài máy không | | | Có bắt tín hiệu shutdown không | ⚠ 30 giây đủ để lưu |

Và câu hỏi lọc nhanh cho mọi bài toán preemptible: nếu máy này biến mất trong 30 giây nữa, hệ thống có tự phục hồi được không? Không thì đừng dùng, dù rẻ tới đâu.

Câu 34
As a Healthcare technology company with a set of applications running on a Google Kubernetes Engine (GKE) cluster, how can you use Cloud Kubernetes Engine Monitoring to send log entries from a new third-party containerized application to Cloud Logging if the application writes its log information to /var/log/app_messages.log?
  1. A Deploy your applications on Google Compute Engine (GCE) with Kubernetes and then modify the predefined Cloud Logging configuration to track the log file in the pods of your applications and record it in Cloud Logging.
  2. B Utilize the Monitoring agent configuration for Cloud Kubernetes Engine that comes by default.
  3. C Create a sidecar container that runs a script to tail the log file in the pod and output the entries to standard output. To enable the script to read from /var/log in the application container, set up a shared volume between the two containers.
  4. D To enable logging for the application's pods on GKE, deploy a Fluentd daemonset and configure a customized input and output configuration that tails the log file and writes to Cloud Logging.
Xem giải thích

Đáp án

D — Triển khai một Fluentd daemonset với cấu hình input/output tuỳ chỉnh, đọc theo dõi file log và ghi vào Cloud Logging.

Vì sao đúng

Vấn đề cốt lõi: ứng dụng ghi log vào FILE trong container (/var/log/app_messages.log), không ghi ra stdout.

⚠ Vì sao mặc định không bắt được:

⚠ Agent logging của GKE thu thập
  STDOUT và STDERR của container
        ↓
⚠ Ứng dụng này ghi vào FILE
        ↓
⚠ Agent mặc định KHÔNG thấy

⚠ Fluentd daemonset tuỳ chỉnh giải quyết:

⚠ Chạy trên MỌI node (daemonset)
⚠ Cấu hình input: tail file cụ thể
⚠ Cấu hình output: ghi vào Cloud Logging

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

⚠ Phương án C (sidecar container tail file rồi xuất ra stdout, dùng volume chia sẻ) cũng là MẪU HÌNH KUBERNETES HỢP LỆ và được nhiều tài liệu khuyến nghị.

⚠ Không sửa khoá. Hai cách khác nhau về đánh đổi:

Cách Ưu Nhược
⚠ Fluentd daemonset (khoá) ⚠ một cấu hình cho cả cluster ⚠ phải quản lý daemonset riêng
⚠ Sidecar (phương án C) ⚠ theo từng pod, không đụng cluster ⚠ tốn thêm container mỗi pod

⚠ Cách tốt nhất trong thực tế: sửa ứng dụng ghi thẳng ra stdout — nhưng đây là ứng dụng bên thứ ba nên không sửa được.

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

  • B (dùng cấu hình agent mặc định của GKE) — ⚠ chính là thứ KHÔNG bắt được file log; đó là nguyên nhân của vấn đề.

  • A (chuyển sang chạy Kubernetes trên GCE rồi sửa cấu hình logging) — ⚠ thay đổi quá lớn cho một vấn đề thu thập log, và mất lợi ích của GKE quản lý.

Ghi nhớ

⚠ Ba cách đưa log file vào Cloud Logging — bảng phải thuộc: | Cách | Khi nào | |---|---| | ⚠ Sửa app ghi ra stdout | ⚠ TỐT NHẤT nếu sửa được | | ⚠ Fluentd/Ops Agent tuỳ chỉnh | ⚠ một cấu hình cho cả cluster — đề này | | ⚠ Sidecar tail ra stdout | ⚠ theo từng pod, không đụng cluster |

Từ khoá nhận diện:

"app ghi vào FILE, không thấy log" → ⚠ agent mặc định chỉ đọc stdout "daemonset" → ⚠ chạy trên mọi node "sidecar + shared volume" → ⚠ giải pháp theo pod

⚠ Vì sao ghi ra stdout là chuẩn container Lý do
⚠ Container nên KHÔNG có trạng thái
⚠ File log trong container mất khi pod chết
⚠ Hạ tầng lo việc thu thập
Đây là nguyên tắc 12-factor app
⚠ Ứng dụng bên thứ ba ⚠ thường không tuân thủ, phải xử lý bằng cách khác
⚠ Daemonset là gì Nghĩa
⚠ Đảm bảo MỘT pod chạy trên MỖI node
⚠ Node mới thêm → tự có pod
Dùng cho ⚠ thu thập log, giám sát, mạng, bảo mật
⚠ Phù hợp với agent ⚠ vì agent cần ở mọi node
⚠ Lưu ý khi tuỳ chỉnh logging trên GKE Lưu ý
⚠ Cấu hình sai có thể làm mất log
⚠ Chi phí Cloud Logging tính theo lượng ⚠ lọc bớt log rác
⚠ Cẩn thận log chứa PII
Ghi log quá nhiều làm chậm ứng dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log có thật sự tới Cloud Logging không | ⚠ kiểm sau khi cấu hình | | Chi phí log tăng bao nhiêu | | | Log có chứa dữ liệu nhạy cảm không | |

Và điều nên làm trước mọi giải pháp phức tạp: hỏi xem có sửa được ứng dụng để ghi ra stdout không. Với ứng dụng của mình thì đó là cách sạch nhất; chỉ khi không sửa được mới cần tới daemonset hay sidecar.

Câu 35
How can our Social Impact Investment Platform create development and production environments for each team, while ensuring that costs are minimized and that teams cannot access each other's environments, using Google Kubernetes Engine (GKE)?
  1. A To ensure secure access control, it is recommended to set up a Development and a Production GKE cluster in different projects. Once the clusters are created, create a Kubernetes namespace for each team and configure Kubernetes RBAC to restrict each team's access to only its respective namespace.
  2. B To ensure secure access to the Kubernetes namespaces, it is recommended to set up two separate GKE clusters - one for Development and one for Production - in different projects. Once the clusters are set up, you can create a dedicated namespace for each team and configure Identity Aware Proxy to restrict access to only their respective namespace.
  3. C For every team, initiate a GCP Project and establish two clusters - one for Production and the other for Development. Provide each team with IAM authorization to access their assigned cluster.
  4. D For each team, establish a GCP Project and produce a cluster that contains a Kubernetes namespace for Development and Production. Provide each team with IAM permissions to access their distinct clusters.
Xem giải thích

Đáp án

A — Tạo một cluster GKE cho Development và một cho Production ở HAI PROJECT khác nhau; sau đó tạo namespace Kubernetes cho từng đội và cấu hình RBAC.

Vì sao đúng

Đề có ba ràng buộc, và phương án A cân bằng cả ba:

⚠ Ba ràng buộc:

⚠ Có môi trường DEV và PROD
   → ⚠ tách bằng PROJECT

⚠ TỐI THIỂU CHI PHÍ
   → ⚠ dùng CHUNG cluster giữa các đội
   → ⚠ không tạo cluster riêng mỗi đội

⚠ Đội không truy cập được môi trường
  của nhau
   → ⚠ NAMESPACE + RBAC

⚠ Vì sao tách project cho dev/prod:

⚠ Ranh giới quyền RÕ RÀNG nhất
⚠ Hạn mức và hoá đơn tách riêng
⚠ Sự cố ở dev không chạm tới prod

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

  • C (mỗi đội một project, mỗi project hai cluster) — ⚠ bẫy về bảo mật rất tốt nhưng CHI PHÍ CAO: ⚠ số cluster nhân với số đội. Đề nói rõ tối thiểu chi phí.

  • D (mỗi đội một project, một cluster, namespace cho dev và prod) — ⚠ trộn dev và prod trong CÙNG cluster — ⚠ ranh giới yếu, sự cố dev có thể ảnh hưởng prod.

  • B (hai cluster ở hai project, nhưng dùng cách phân quyền khác) — ⚠ gần đúng về cấu trúc nhưng ⚠ không dùng namespace + RBAC cho từng đội.

Ghi nhớ

⚠ Các mức cách ly trên GKE — bảng phải thuộc: | Mức | Cách ly | Chi phí | |---|---|---| | ⚠ Project riêng | ⚠ MẠNH NHẤT | ⚠ cao nếu nhiều project | | ⚠ Cluster riêng | ⚠ mạnh | ⚠ cao — mỗi cluster tốn control plane | | ⚠ Namespace + RBAC | ⚠ trung bình | ⚠ RẺ — đề này | | Node pool riêng | ⚠ cách ly tài nguyên | trung bình |

Từ khoá nhận diện:

"tách dev/prod + tiết kiệm chi phí + đội không thấy nhau" → ⚠ project cho môi trường, namespace cho đội "mỗi đội một cluster" → ⚠ tốn kém "dev và prod chung cluster" → ⚠ ranh giới yếu

⚠ Vì sao KHÔNG nên chung cluster dev và prod Lý do
⚠ Lỗi cấu hình ở dev lan sang prod
⚠ Tải thử nghiệm ảnh hưởng prod
⚠ Quyền dễ bị cấp nhầm
Nâng cấp cluster ảnh hưởng cả hai
⚠ Namespace KHÔNG phải ranh giới bảo mật mạnh
⚠ Namespace cách ly được gì và không được gì Cách ly
⚠ ĐƯỢC: phạm vi tên, RBAC, hạn mức tài nguyên
⚠ ĐƯỢC: network policy nếu bật
⚠ KHÔNG: cách ly kernel ⚠ container thoát ra vẫn ở cùng node
⚠ KHÔNG: cách ly control plane
Vì thế ⚠ namespace đủ cho đội tin nhau, không đủ cho đa khách hàng
⚠ RBAC trong Kubernetes Thành phần
⚠ Role ⚠ quyền trong MỘT namespace
⚠ ClusterRole ⚠ quyền toàn cluster
⚠ RoleBinding ⚠ gán role cho người/nhóm trong namespace
ClusterRoleBinding ⚠ gán toàn cluster
⚠ Lưu ý ⚠ IAM của Google Cloud và RBAC của Kubernetes là HAI lớp, cần cả hai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội A có xem được namespace của đội B không | ⚠ thử thật | | Ai có quyền cluster-admin | ⚠ nên rất ít người | | Dev có đường nào chạm vào prod không | |

Và điểm hay bị bỏ qua khi phân quyền GKE: có HAI lớp quyền — IAM của Google Cloud và RBAC của Kubernetes. Cấp đúng một lớp mà quên lớp kia là nguyên nhân phổ biến nhất khiến phân quyền không như mong đợi.

Câu 36
As a travel booking company, how can we implement Jenkins on Google Cloud Platform to streamline our release process, lower operational toil, and ensure the security of our user data?
  1. A Deploy Jenkins on virtual machines in Compute Engine.
  2. B Deploy Jenkins on the local machines.
  3. C Deploy Jenkins on Google Cloud Functions.
  4. D Deploy Jenkins on-premises using Kubernetes.
Xem giải thích

Đáp án

A — Triển khai Jenkins trên máy ảo trong Compute Engine.

Vì sao đúng

Đề nêu ba yêu cầu, và Compute Engine là lựa chọn hợp lý nhất trong bốn phương án:

⚠ Ba yêu cầu:

"tinh gọn quy trình phát hành"
    → ⚠ cần Jenkins chạy ổn định, luôn sẵn

"giảm công việc thủ công lặp lại (toil)"
    → ⚠ hạ tầng được quản lý, không tự
      lo máy chủ vật lý

"bảo mật dữ liệu người dùng"
    → ⚠ trong VPC, có IAM và kiểm soát
      truy cập

⚠ Vì sao Compute Engine hợp với Jenkins:

⚠ Jenkins là ứng dụng CÓ TRẠNG THÁI
   → ⚠ cấu hình, plugin, lịch sử build
⚠ Chạy LIÊN TỤC, chờ trigger
⚠ Cần đĩa bền vững
⚠ Cần kiểm soát môi trường và plugin

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

  • C (Cloud Functions) — ⚠ sai kiến trúc căn bản: Functions là serverless, chạy ngắn, không trạng thái, có giới hạn thời gian. ⚠ Jenkins cần chạy thường trực và giữ trạng thái.

  • D (Kubernetes tại chỗ) — ⚠ không phải trên Google Cloud và ⚠ tăng công vận hành thay vì giảm.

  • B (máy cá nhân) — ⚠ tệ nhất: không sẵn sàng, không sao lưu, không bảo mật, phụ thuộc một người.

⚠ Lưu ý thực tế: Google Cloud có Cloud Build là dịch vụ CI/CD được quản lý hoàn toàn — thường là lựa chọn tốt hơn Jenkins nếu bắt đầu mới. Nhưng đề hỏi cách triển khai Jenkins, nên chọn theo bốn phương án đã cho.

Ghi nhớ

⚠ Chọn nền tảng theo đặc tính workload — bảng phải thuộc: | Workload | Nền tảng | |---|---| | ⚠ Có trạng thái, chạy liên tục | ⚠ Compute Engine — đề này | | Không trạng thái, container | ⚠ Cloud Run, GKE | | Sự kiện ngắn, không trạng thái | ⚠ Cloud Functions | | CI/CD được quản lý | ⚠ Cloud Build |

Từ khoá nhận diện:

"Jenkins, cần trạng thái, chạy thường trực" → ⚠ Compute Engine hoặc GKE "chạy ngắn, theo sự kiện" → ⚠ Cloud Functions "CI/CD không muốn tự vận hành" → ⚠ Cloud Build "tại chỗ" → ⚠ tăng toil, ngược yêu cầu

⚠ Nếu vẫn dùng Jenkins — thực hành tốt Thực hành
⚠ Master trên VM hoặc GKE, có sao lưu
⚠ Agent chạy tạm thời ⚠ preemptible VM cho build worker
⚠ Cấu hình dạng mã ⚠ Jenkins Configuration as Code
⚠ Secret trong Secret Manager ⚠ không để trong Jenkins credential thuần
Đặt trong VPC, không mở ra Internet
⚠ "Toil" trong SRE là gì Nghĩa
⚠ Việc thủ công, lặp lại, tự động hoá được
⚠ Không tạo giá trị lâu dài
⚠ Tăng tuyến tính theo quy mô
Mục tiêu SRE ⚠ giữ toil dưới 50% thời gian
⚠ Tự vận hành máy chủ vật lý ⚠ là toil điển hình
⚠ Vì sao cân nhắc Cloud Build thay Jenkins Lý do
⚠ Không phải vận hành máy chủ ⚠ giảm toil trực tiếp
⚠ Tích hợp sẵn IAM, Secret Manager, Artifact Registry
⚠ Trả theo mức dùng
Nhưng ⚠ Jenkins linh hoạt hơn, nhiều plugin, dễ di chuyển

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Jenkins master có sao lưu không | ⚠ mất cấu hình là mất rất nhiều công | | Secret lưu ở đâu | | | Có mở ra Internet không | ⚠ Jenkins là mục tiêu tấn công phổ biến |

Và rủi ro thực tế lớn nhất khi tự vận hành Jenkins: nó thường là hệ thống có quyền cao nhất trong tổ chức — quyền đẩy mã lên sản xuất, quyền truy cập secret. Bảo vệ nó phải ở mức tương xứng.

Câu 37
As a provider of Robotic Process Automation services, you receive an alert that your infrastructure is failing and all of its dependent systems with thousands of users are affected. What steps should you take as part of your incident management protocol to resolve this issue using Google Cloud Services?
  1. A Create a means of communication for incident responders and leads to exchange information with each other.
  2. B Notify the impacted service owners and provide them with the incident status update.
  3. C To begin the post-incident analysis process, include details of the incident and share the initial version within the team, requesting feedback from internal stakeholders.
  4. D Search for methods to reduce the effect on users and apply those measures in the production environment.
Xem giải thích

Đáp án

A — Thiết lập một kênh liên lạc để người ứng cứu sự cố và người chỉ huy trao đổi thông tin với nhau.

Vì sao đúng

Đề mô tả sự cố quy mô lớn, ảnh hưởng hàng nghìn người dùng. Bước đầu trong quy trình quản lý sự cố là thiết lập cơ chế phối hợp.

⚠ Vì sao liên lạc là bước đầu:

⚠ Sự cố lớn → NHIỀU người cùng xử lý
        ↓
⚠ Không có kênh chung
   → ⚠ trùng việc
   → ⚠ mâu thuẫn hành động
   → ⚠ thông tin phân mảnh
        ↓
⚠ Kênh chung = nền tảng cho mọi
  bước sau

⚠ Trong khung IMAG/ICS của Google, thiết lập vai trò và kênh liên lạc là việc đầu tiên khi sự cố vượt quá một người xử lý.

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

  • D (tìm cách giảm ảnh hưởng lên người dùng và áp dụng ngay lên sản xuất) — ⚠ bẫy mạnh nhất: giảm thiểu tác động là mục tiêu chính, nhưng ⚠ áp dụng thay đổi lên sản xuất mà chưa có phối hợp dễ gây hai người sửa cùng lúc và làm tình hình tệ hơn.

  • B (thông báo cho chủ sở hữu dịch vụ bị ảnh hưởng) — ⚠ cần thiết nhưng đến SAU: phải có kênh và người chỉ huy trước đã.

  • C (bắt đầu viết phân tích hậu sự cố) — ⚠ sai thời điểm hoàn toàn: postmortem là việc SAU KHI sự cố đã được khắc phục.

Ghi nhớ

⚠ Ba vai trò trong quản lý sự cố — bảng phải thuộc: | Vai trò | Việc | |---|---| | ⚠ Incident Commander (IC) | ⚠ điều phối, ra quyết định, KHÔNG tự sửa | | ⚠ Operations / Ops Lead | ⚠ người thực sự khắc phục | | ⚠ Communications Lead | ⚠ cập nhật cho bên liên quan | | Nguyên tắc | ⚠ IC KHÔNG được vừa chỉ huy vừa gõ lệnh sửa |

Từ khoá nhận diện:

"sự cố lớn, nhiều người xử lý" → ⚠ lập kênh liên lạc và vai trò trước "áp dụng sửa ngay lên sản xuất" → ⚠ nguy hiểm khi chưa phối hợp "viết postmortem" → ⚠ sau khi khắc phục xong

⚠ Thứ tự xử lý sự cố lớn Bước
⚠ 1. Phát hiện và xác nhận
⚠ 2. Chỉ định IC, lập kênh liên lạc ⚠ đề này
⚠ 3. Đánh giá tác động
⚠ 4. GIẢM THIỂU trước, sửa gốc sau
⚠ 5. Cập nhật bên liên quan định kỳ
6. Khắc phục hoàn toàn
⚠ 7. Postmortem ⚠ sau cùng
⚠ Vì sao "giảm thiểu trước, sửa gốc sau" Lý do
⚠ Người dùng đang bị ảnh hưởng NGAY
⚠ Quay lui bản phát hành thường nhanh nhất
⚠ Tìm nguyên nhân gốc có thể mất hàng giờ
Nguyên tắc ⚠ CẦM MÁU trước, chẩn đoán sau
⚠ Kênh liên lạc nên có gì Có
⚠ Một kênh chat chung cho sự cố
⚠ Tài liệu trạng thái được cập nhật liên tục
⚠ Cầu hội thoại cho quyết định nhanh
⚠ Ghi lại mốc thời gian ⚠ cần cho postmortem sau này
Tách riêng ⚠ kênh kỹ thuật và kênh thông báo bên ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai đóng vai IC chưa | ⚠ sự cố lớn không có IC là hỗn loạn | | Có ghi mốc thời gian không | ⚠ cần cho postmortem | | Có ai đang sửa mà người khác không biết không | |

Và sai lầm phổ biến nhất khi có sự cố lớn: mọi người cùng lao vào sửa mà không ai điều phối. Kết quả là hai người thay đổi hai thứ cùng lúc, và không ai biết thay đổi nào làm tình hình xấu đi.

Câu 38
As a Social impact investment platform company, you are deploying an application that requires access to sensitive information. What measures should you take to ensure that this information is encrypted and the chances of exposure are minimal in case of a breach? Additionally, which Google Cloud Services can be leveraged to achieve this goal?
  1. A Frequently rotate encryption keys and keep them stored in Cloud Key Management Service (KMS).
  2. B Create a continuous build pipeline that generates various versions of the secret for every application instance.
  3. C During the creation of the instance, use an encrypted configuration management system to insert the secret.
  4. D Incorporate a Single sign-on (SSO) system to the application and ensure that no secrets are revealed to the application.
Xem giải thích

Đáp án

A — Xoay vòng khoá mã hoá thường xuyên và lưu chúng trong Cloud Key Management Service (KMS).

Vì sao đúng

Đề nêu hai mục tiêu: mã hoá thông tin nhạy cảm và giảm thiệt hại nếu bị lộ.

⚠ Hai vế của giải pháp:

⚠ LƯU KHOÁ TRONG KMS
   → ⚠ khoá không nằm cùng dữ liệu
   → ⚠ có kiểm soát truy cập và ghi vết
   → ⚠ khoá không bao giờ rời KMS

⚠ XOAY VÒNG THƯỜNG XUYÊN
   → ⚠ khoá lộ chỉ mở được dữ liệu
     trong MỘT khoảng thời gian
   → ⚠ GIỚI HẠN thiệt hại

⚠ Xoay vòng chính là phần trả lời cho "giảm thiểu thiệt hại khi bị lộ" — đó là điểm mấu chốt của câu hỏi.

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

  • C (dùng hệ quản lý cấu hình có mã hoá để chèn secret lúc tạo instance) — ⚠ bẫy hợp lý: làm được, nhưng ⚠ không giải quyết vấn đề xoay vòng, và ⚠ secret gắn vào instance thì đổi rất khó.

  • B (dựng pipeline sinh nhiều phiên bản secret cho từng instance) — ⚠ phức tạp không cần thiết và ⚠ tự dựng cơ chế quản lý khoá là chống chỉ định về bảo mật.

  • D (dùng SSO để ứng dụng không nhận secret nào) — ⚠ giải bài toán khác: SSO lo xác thực người dùng, ⚠ ứng dụng vẫn cần secret để nối CSDL và dịch vụ khác.

Ghi nhớ

⚠ Quản lý khoá và secret trên Google Cloud — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Cloud KMS | ⚠ quản lý KHOÁ mã hoá, xoay vòng — đề này | | ⚠ Secret Manager | ⚠ lưu SECRET: mật khẩu, API key | | CMEK | ⚠ dùng khoá của khách cho dịch vụ Google | | Confidential Computing | ⚠ mã hoá cả khi đang xử lý |

Từ khoá nhận diện:

"khoá mã hoá, xoay vòng" → ⚠ Cloud KMS "mật khẩu, chuỗi kết nối" → ⚠ Secret Manager "giảm thiệt hại khi lộ" → ⚠ XOAY VÒNG "tự dựng cơ chế quản lý khoá" → ⚠ luôn là ý tồi

⚠ Vì sao xoay vòng khoá quan trọng Lý do
⚠ Giả định khoá SẼ bị lộ vào lúc nào đó
⚠ Xoay vòng giới hạn CỬA SỔ thiệt hại
⚠ Dữ liệu cũ vẫn giải mã được bằng phiên bản khoá cũ ⚠ KMS giữ các phiên bản
Dữ liệu mới dùng phiên bản mới
⚠ KMS hỗ trợ ⚠ xoay vòng TỰ ĐỘNG theo lịch
⚠ Ba trạng thái mã hoá Trạng thái
⚠ At rest ⚠ khi lưu trên đĩa — mặc định có
⚠ In transit ⚠ khi truyền qua mạng — TLS
⚠ In use ⚠ khi đang xử lý — Confidential Computing
Lưu ý ⚠ mã hoá at rest KHÔNG chống người có quyền đọc
⚠ Nguyên tắc bất biến về khoá Nguyên tắc
⚠ KHÔNG lưu khoá cạnh dữ liệu mã hoá
⚠ KHÔNG commit khoá vào mã nguồn
⚠ Quyền dùng khoá tách khỏi quyền đọc dữ liệu ⚠ cần cả hai mới giải mã được
⚠ Ghi vết mọi lần dùng khoá
Xoay vòng theo lịch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá xoay vòng bao lâu một lần | ⚠ có tự động không | | Ai có quyền dùng khoá | ⚠ rà IAM trên KeyRing | | Có ghi vết lần dùng khoá không | |

Và nguyên tắc thiết kế bảo mật đáng nhớ: giả định mọi khoá rồi sẽ bị lộ, và thiết kế để thiệt hại khi đó là có giới hạn. Xoay vòng khoá chính là cách biến "thảm hoạ vĩnh viễn" thành "sự cố trong một khoảng thời gian".

Câu 39
As a Green energy technology company, you have deployed a stateless web-based API on a single Compute Engine instance in europe-west2-a zone. However, the Service Level Indicator (SLI) for service availability does not meet the specified Service Level Objective (SLO) due to the API timing out frequently. The API is overwhelmed with requests leading to memory shortage. What steps can you take to improve the service availability of the API using Google Cloud services?
  1. A Deploy more service instances across different zones and distribute the traffic among them using load balancing.
  2. B Revise the indicated SLO to align with the calculated SLI.
  3. C To ensure high availability, configure supplementary service instances in different zones and utilize them as a backup if the primary instance becomes inaccessible.
  4. D Upgrade the compute instances to higher-specification ones that offer more memory for the service.
Xem giải thích

Đáp án

A — Triển khai thêm nhiều instance dịch vụ ở các zone khác nhau và phân phối lưu lượng giữa chúng bằng cân bằng tải.

Vì sao đúng

Đề nêu hai vấn đề, và phương án A giải cả hai:

⚠ Hai vấn đề:

"API bị QUÁ TẢI, thiếu bộ nhớ"
    → ⚠ cần THÊM NĂNG LỰC
    → ⚠ chia tải ra nhiều instance

"chỉ MỘT instance trong MỘT zone"
    → ⚠ điểm hỏng đơn
    → ⚠ cần nhiều ZONE

⚠ API là STATELESS (đề nói rõ) — nên nhân bản theo chiều ngang là hoàn toàn phù hợp.

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

  • D (nâng cấp lên máy cấu hình cao hơn, nhiều bộ nhớ hơn) — ⚠ bẫy mạnh nhất: giải được triệu chứng thiếu bộ nhớ nhưng ⚠ vẫn là MỘT instance trong MỘT zone — điểm hỏng đơn còn nguyên. ⚠ Đây là mở rộng theo chiều dọc, có trần và không tăng tính sẵn sàng.

  • C (thêm instance ở zone khác nhưng chỉ làm DỰ PHÒNG khi instance chính hỏng) — ⚠ bẫy tinh vi: có nhiều zone nhưng ⚠ không chia tải — instance chính vẫn quá tải như cũ.

  • B (sửa lại SLO cho khớp với SLI hiện tại) — ⚠ che giấu vấn đề: hạ mục tiêu để con số trông đẹp, ⚠ người dùng vẫn gặp lỗi như cũ.

Ghi nhớ

⚠ Hai kiểu mở rộng — bảng phải thuộc: | Kiểu | Cách | Hạn chế | |---|---|---| | ⚠ Chiều dọc (vertical) | ⚠ máy to hơn | ⚠ có TRẦN, vẫn một điểm hỏng | | ⚠ Chiều ngang (horizontal) | ⚠ nhiều máy hơn | ⚠ cần ứng dụng stateless — đề này |

Từ khoá nhận diện:

"stateless, quá tải, một zone" → ⚠ nhiều instance + nhiều zone + load balancer "nâng cấp máy to hơn" → ⚠ không tăng tính sẵn sàng "dự phòng, chỉ dùng khi chính hỏng" → ⚠ không chia tải "sửa SLO cho khớp SLI" → ⚠ che giấu vấn đề

⚠ Vì sao nhiều ZONE chứ không chỉ nhiều instance Lý do
⚠ Nhiều instance MỘT zone ⚠ zone hỏng là mất hết
⚠ Nhiều zone MỘT region ⚠ chịu được lỗi zone
Nhiều region ⚠ chịu được thảm hoạ vùng, đắt hơn
Cân bằng phổ biến ⚠ nhiều zone trong một region
⚠ Vì sao "dự phòng chờ" kém hơn "chia tải" Lý do
⚠ Dự phòng chờ KHÔNG giảm tải
⚠ Tài nguyên nằm không, vẫn tốn tiền
⚠ Chuyển đổi khi hỏng có độ trễ
⚠ Không biết bản dự phòng có chạy được không ⚠ chưa từng chịu tải thật
Active-active tốt hơn ⚠ mọi instance đều đang phục vụ
⚠ Bổ sung nên có Bổ sung
⚠ Managed instance group + autoscaling ⚠ tự thêm máy khi tải tăng
⚠ Health check ⚠ loại instance hỏng khỏi load balancer
⚠ Tìm nguyên nhân rò rỉ bộ nhớ ⚠ thêm máy chỉ mua thời gian
Đặt giới hạn tài nguyên
⚠ Vì sao KHÔNG nên sửa SLO cho khớp SLI Lý do
⚠ SLO phản ánh KỲ VỌNG NGƯỜI DÙNG ⚠ không phải hiệu năng hiện tại
⚠ Hạ SLO không làm người dùng bớt khó chịu
⚠ Mất tín hiệu cảnh báo
⚠ Chỉ sửa SLO khi ⚠ chứng minh được kỳ vọng ban đầu đặt sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có thật sự stateless không | ⚠ có phiên lưu trong bộ nhớ không | | Có rò rỉ bộ nhớ không | ⚠ thêm máy chỉ hoãn vấn đề | | Health check có đúng không | ⚠ sai là load balancer gửi traffic vào máy hỏng |

Và điều cần làm song song với việc mở rộng: tìm xem vì sao hết bộ nhớ. Nếu là rò rỉ bộ nhớ thì thêm bao nhiêu máy cũng chỉ kéo dài thời gian tới lần sập tiếp theo.

Câu 40
As an online grocery delivery service company, you have a Node.js application running on Google Kubernetes Engine (GKE) that interacts with several dependent applications via HTTP requests. How can you proactively identify the dependent applications that may impact the performance of your application on GKE?
  1. A Utilize Cloud Debugger for analyzing the logic execution of every application and instrumenting all applications.
  2. B Revise the Node.js application to record the duration of HTTP requests and responses to linked applications. Utilize Cloud Logging to detect linked applications that have suboptimal performance.
  3. C Cloud Trace should be used to instrument all applications, and it is recommended to review HTTP requests between services.
  4. D Make sure to equip all the applications with Cloud Profiler.
Xem giải thích

Đáp án

C — Dùng Cloud Trace để instrument mọi ứng dụng và rà soát các HTTP request giữa các dịch vụ.

Vì sao đúng

Đề cần phát hiện sớm dịch vụ phụ thuộc nào ảnh hưởng hiệu năng. Đó là bài toán distributed tracing.

⚠ Cloud Trace cho gì:

⚠ Theo dõi MỘT request đi qua
  NHIỀU dịch vụ
        ↓
⚠ Mỗi chặng là một SPAN
   → ⚠ dịch vụ nào, mất bao lâu
        ↓
⚠ Nhìn ra ngay CHẶNG NÀO CHẬM

⚠ Vì sao hợp với kiến trúc nhiều dịch vụ:

⚠ Log cho biết "có chuyện gì xảy ra"
⚠ Metric cho biết "có bất thường không"
⚠ TRACE cho biết "chậm Ở ĐÂU"

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

  • B (sửa ứng dụng để tự ghi thời gian request rồi dùng Cloud Logging phân tích) — ⚠ bẫy hợp lý và làm được: nhưng ⚠ tự dựng lại thứ Trace đã có, ⚠ tốn công sửa mã, và ⚠ không nối được các chặng thành một trace hoàn chỉnh.

  • D (trang bị Cloud Profiler cho mọi ứng dụng) — ⚠ sai công cụ: Profiler cho biết hàm nào tốn CPU/bộ nhớ TRONG một dịch vụ, ⚠ không cho biết quan hệ GIỮA các dịch vụ.

  • A (dùng Cloud Debugger để phân tích logic thực thi) — ⚠ sai công cụ: Debugger để xem trạng thái biến tại một điểm trong mã, không phải phân tích hiệu năng liên dịch vụ.

Ghi nhớ

⚠ Bốn công cụ quan sát và câu hỏi chúng trả lời — bảng phải thuộc: | Công cụ | Trả lời | |---|---| | ⚠ Cloud Trace | ⚠ "chậm Ở CHẶNG NÀO" — đề này | | Cloud Monitoring | ⚠ "có bất thường không" | | Cloud Logging | ⚠ "chuyện gì đã xảy ra" | | ⚠ Cloud Profiler | ⚠ "tốn CPU ở HÀM nào" | | Error Reporting | ⚠ "lỗi nào hay xảy ra" |

Từ khoá nhận diện:

"request đi qua nhiều dịch vụ, tìm chặng chậm" → ⚠ Cloud Trace "hàm nào tốn CPU" → ⚠ Profiler "xem giá trị biến trong mã" → ⚠ Debugger "đếm sự kiện theo thời gian" → ⚠ log-based metric

⚠ Distributed tracing hoạt động thế nào Cách
⚠ Mỗi request có TRACE ID duy nhất
⚠ Truyền trace ID qua header giữa các dịch vụ ⚠ context propagation
⚠ Mỗi chặng ghi một SPAN ⚠ thời điểm bắt đầu, kết thúc
Ghép các span thành cây
⚠ Điều kiện ⚠ MỌI dịch vụ phải được instrument
⚠ Vì sao phải instrument TẤT CẢ Lý do
⚠ Thiếu một dịch vụ → đứt chuỗi trace
⚠ Không biết thời gian mất ở đâu trong khoảng đó
⚠ Dịch vụ bên thứ ba không instrument được ⚠ ít nhất đo thời gian gọi từ phía mình
Giải pháp hiện đại ⚠ OpenTelemetry — chuẩn mở, Google Cloud hỗ trợ
⚠ Lấy mẫu trace Lấy mẫu
⚠ Không thể trace 100% ở tải cao ⚠ tốn kém và chậm
⚠ Lấy mẫu một tỷ lệ nhỏ
⚠ Nhưng LUÔN trace request lỗi hoặc chậm ⚠ tail-based sampling
Cân bằng ⚠ đủ dữ liệu để chẩn đoán mà không tốn quá nhiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi dịch vụ đã instrument chưa | ⚠ thiếu một cái là đứt chuỗi | | Trace ID có được truyền qua header không | | | Tỷ lệ lấy mẫu có đủ để chẩn đoán không | |

Và điều Cloud Trace cho thấy mà log và metric không cho: thời gian của MỘT request cụ thể phân bổ ra sao giữa các dịch vụ. Với kiến trúc nhiều dịch vụ, đó thường là thông tin duy nhất chỉ ra được thủ phạm.