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

Đáp án

A — Tạo một SERVICE ACCOUNT và gán cho nó một VAI TRÒ có quyền đọc ghi.

Vì sao đúng

Hai điểm cần đúng: danh tính cho tiến trình tự động là service account, và quyền được cấp bằng VAI TRÒ, không phải permission rời.

⚠ Điểm mấu chốt thứ nhất — service account là danh tính của MÁY:

Tiến trình tự động chạy hằng đêm
        ↓
    Không nên dùng danh tính CÁ NHÂN
        ↓
    → người đó nghỉ việc → tiến trình chết
    → không rõ ai chịu trách nhiệm
    → quyền của cá nhân thường quá rộng
        ↓
SERVICE ACCOUNT
        ↓
    Danh tính riêng cho tiến trình
    → quyền tối thiểu, đúng việc nó cần
    → tồn tại độc lập với nhân sự
    → audit log ghi rõ service account nào đã làm gì

⚠ Điểm mấu chốt thứ hai — IAM chỉ gán được VAI TRÒ:

Google Cloud IAM
        ↓
    Bạn gán ROLE cho một MEMBER
        ↓
    KHÔNG gán permission trực tiếp được
        ↓
    → permission nằm BÊN TRONG role
        ↓
    Vai trò cho việc này:
      roles/storage.objectAdmin
        (đọc, ghi, xoá đối tượng)
      hoặc kết hợp
      roles/storage.objectViewer + objectCreator

⚠ Và cách cho tiến trình dùng service account — theo thứ tự an toàn:

1. GẮN service account vào tài nguyên chạy nó
        ↓
    VM, Cloud Run, Cloud Functions, GKE
    → thông tin xác thực lấy từ metadata server
    → KHÔNG có khoá nào để lộ

2. WORKLOAD IDENTITY (GKE)
        ↓
    Pod dùng service account Google, không cần khoá

3. WORKLOAD IDENTITY FEDERATION
        ↓
    Cho CI/CD ngoài GCP — cũng không cần khoá

4. Khoá JSON
        ↓
    → CÁCH CUỐI CÙNG, phải xoay và bảo vệ

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

• B (tạo service account và gán PERMISSION trực tiếp) — đây là phương án gần nhất và danh tính hoàn toàn đúng, nhưng IAM của Google Cloud không gán permission trực tiếp: bạn chỉ gán role. Đây chính là điểm phân biệt giữa A và B.

• D (tạo federated identity và gán permission trực tiếp) — sai cả hai vế: federated identity dành cho NGƯỜI DÙNG từ IdP ngoài, và vẫn không gán permission trực tiếp được.

• C (tạo Cloud Identity và gán role) — Cloud Identity tạo danh tính NGƯỜI DÙNG, không phải danh tính cho tiến trình tự động.

Ghi nhớ

⚠ Các loại danh tính trong Google Cloud — bảng phải thuộc: | Loại | Dùng cho | |---|---| | Google Account | người dùng thật | | Service account | ứng dụng, VM, tiến trình tự động | | Google Group | gom người dùng — nên gán role cho GROUP | | Cloud Identity domain | mọi người dùng trong một tên miền | | Federated identity | người dùng từ IdP ngoài (SAML, OIDC) | | Bẫy | IAM chỉ gán ROLE, không gán permission |

Từ khoá nhận diện:

"tiến trình tự động cần quyền" → service account + role "gán permission trực tiếp" → luôn SAI trong GCP "CI/CD ngoài GCP" → Workload Identity Federation "pod GKE gọi API Google" → Workload Identity "không muốn quản khoá JSON" → gắn service account vào tài nguyên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Service account có quyền gì | gcloud projects get-iam-policy <id> lọc theo email | | Tài nguyên đang dùng SA nào | gcloud compute instances describe <ten> → serviceAccounts | | Có khoá JSON nào không | gcloud iam service-accounts keys list --iam-account=<email> |

Và một cấu hình rất nên bật ở cấp tổ chức: constraints/iam.disableServiceAccountKeyCreation. Khoá JSON của service account là nguồn rò rỉ phổ biến nhất trong các sự cố bảo mật trên cloud — chặn việc tạo chúng ngay từ đầu buộc mọi người dùng những cơ chế an toàn hơn, thay vì chỉ khuyến nghị rồi hy vọng ai cũng nhớ.

Đáp án

B, C và D — ZONE, REGION và LOẠI ĐĨA (disk type) phải giống nhau.

Vì sao đúng

Clone (nhân bản) đĩa là thao tác tại chỗ trong cùng hạ tầng, nên vị trí và loại đĩa phải khớp; chỉ có kích thước là được phép khác.

⚠ Điểm mấu chốt — ba thứ phải khớp, một thứ được linh hoạt:

ZONE và REGION phải giống nhau
        ↓
    Clone là thao tác nội bộ trong cùng vị trí
    → không phải cơ chế sao chép liên vùng
        ↓
    Muốn sang zone hoặc Region khác
      → dùng SNAPSHOT, không dùng clone

DISK TYPE phải giống nhau
        ↓
    pd-standard, pd-balanced, pd-ssd,
    pd-extreme, hyperdisk
    → clone giữ nguyên loại
        ↓
KÍCH THƯỚC được phép LỚN HƠN
        ↓
    → đĩa clone có thể to hơn đĩa nguồn
    → nhưng KHÔNG được nhỏ hơn
        ↓
    → đây là lý do phương án A (Size) sai

⚠ Clone khác snapshot ở điểm nào:

CLONE
        ↓
    Tạo NGAY một đĩa mới dùng được liền
    → nhanh hơn nhiều so với khôi phục snapshot
    → CÙNG zone, CÙNG loại đĩa
    → dùng cho: nhân bản môi trường thử,
      tách bản để phân tích

SNAPSHOT
        ↓
    Bản sao lưu, lưu riêng
    → TOÀN CẦU — tạo đĩa ở MỌI Region
    → tăng dần (incremental), rẻ hơn để giữ lâu
    → dùng cho: sao lưu, khôi phục thảm hoạ

⚠ Và một lưu ý về tính nhất quán:

Clone một đĩa ĐANG ĐƯỢC GHI
        ↓
    → dữ liệu có thể không nhất quán
      ở mức file system
        ↓
    Nên: tạm dừng ghi, hoặc flush và freeze
         file system trước khi clone
        ↓
    Với CSDL: dùng cơ chế sao lưu của
    chính CSDL đó thì an toàn hơn

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

• A (Size) — đây là phương án gần nhất và dễ nhầm vì trực giác "bản sao phải giống hệt", nhưng kích thước KHÔNG cần giống: đĩa clone được phép lớn hơn đĩa nguồn. Chỉ không được nhỏ hơn.

Ghi nhớ

⚠ Clone ↔ Snapshot ↔ Image — bảng phải thuộc: | | Clone | Snapshot | Image | |---|---|---|---| | Việc | tạo đĩa mới NGAY | bản sao lưu | khuôn tạo VM | | Phạm vi | CÙNG zone | TOÀN CẦU | toàn cầu | | Tốc độ | nhanh nhất | phải khôi phục | phải khởi chạy | | Lưu trữ riêng | không | có, tăng dần | có | | Dùng cho | nhân bản môi trường, phân tích | sao lưu, DR | instance template |

Từ khoá nhận diện:

"nhân bản đĩa ngay trong cùng zone" → clone "sao lưu, khôi phục ở Region khác" → snapshot "khuôn để tạo VM mới" → custom image "toàn bộ VM gồm nhiều đĩa" → machine image "đĩa clone nhỏ hơn nguồn" → KHÔNG được phép

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đĩa thuộc loại nào | gcloud compute disks describe <ten> --zone=<zone> | | Clone bằng lệnh gì | gcloud compute disks create <moi> --source-disk=<cu> --zone=<zone> | | Đĩa có đang gắn vào VM nào | cùng lệnh describe, xem users |

Và một điều cần lưu ý về tính nhất quán khi clone một đĩa đang được ghi: clone không đóng băng dữ liệu ở mức ứng dụng. Với một cơ sở dữ liệu đang chạy, bản clone có thể ở trạng thái giống như máy vừa bị mất điện — nên nếu dữ liệu quan trọng, hãy dùng cơ chế sao lưu của chính CSDL đó, hoặc ít nhất là flush và tạm khoá file system trước khi thực hiện.

Đáp án

D — billing.accounts.create

Vì sao đúng

Câu này kiểm tra sự phân biệt giữa PERMISSION và ROLE.

⚠ Điểm mấu chốt — hai định dạng khác nhau:

PERMISSION (quyền đơn lẻ)
        ↓
    <dichvu>.<taiNguyen>.<hanhDong>
        ↓
    billing.accounts.create
    compute.instances.list
        ↓
    → KHÔNG có tiền tố "roles/"

ROLE (tập hợp permission)
        ↓
    roles/<dichvu>.<tenVaiTro>
        ↓
    roles/billing.creator
    roles/compute.admin
        ↓
    → LUÔN có tiền tố "roles/"

⚠ Đề hỏi PERMISSION nên đáp án không có roles/:

"What PERMISSION must an identity have..."
        ↓
    billing.accounts.create   ✓
        ↓
    Vai trò CHỨA permission này:
      roles/billing.creator
      (Billing Account Creator)
      → gán ở cấp TỔ CHỨC

Xem thêm câu #12479 (lô 131): cùng một câu hỏi, cùng đáp án. Chỉ khác chữ cái — ở đó là C, ở đây là D. Khoá nhất quán.

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

• C (roles/billing.accounts.create) — đây là phương án gần nhất và là bẫy chính: nó trộn hai định dạng. Tiền tố roles/ chỉ dùng cho vai trò.

• A (billing.create) — thiếu phần tài nguyên: permission phải có ba phần.

• B (roles/billing.create) — cũng trộn định dạng, và không có vai trò nào tên này.

Ghi nhớ

⚠ Permission ↔ Role — bảng phải thuộc: | | Permission | Role | |---|---|---| | Định dạng | <dichvu>.<taiNguyen>.<hanhDong> | roles/<dichvu>.<ten> | | Ví dụ | compute.instances.create | roles/compute.instanceAdmin | | Gán trực tiếp cho member | KHÔNG | CÓ | | Quan hệ | một role chứa NHIỀU permission | | | Bẫy | roles/ đứng trước permission là luôn SAI | |

Từ khoá nhận diện:

"permission nào" → ba phần, không có roles/ "role nào" → có tiền tố roles/ "tạo billing account" → roles/billing.creator "gắn project vào billing account" → roles/billing.user "xem chi phí" → roles/billing.viewer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền billing | gcloud beta billing accounts get-iam-policy <id> | | Vai trò gồm permission nào | gcloud iam roles describe roles/billing.creator | | Project gắn billing nào | gcloud beta billing projects describe <project> |

Và một cách rất nhanh để không bao giờ nhầm hai định dạng: permission luôn có ba phần và không có dấu gạch chéo, còn role luôn bắt đầu bằng roles/. Bất kỳ chuỗi nào vừa có roles/ vừa trông như permission ba phần đều là phương án bịa trong đề thi.

Đáp án

D — Cloud Functions.

Vì sao đúng

Đề mô tả đúng mô hình của Cloud Functions: phản ứng với một sự kiện, xử lý rất ngắn, tải lúc có lúc không.

⚠ Điểm mấu chốt — kích hoạt trực tiếp từ sự kiện Cloud Storage:

Người dùng tải ảnh lên Cloud Storage
        ↓
    Sự kiện object finalized
        ↓
    Cloud Function được gọi NGAY
        ↓
    Xử lý ~1 giây rồi kết thúc
        ↓
    → "phân tích ngay khi ảnh được tải lên"

⚠ Mô hình chi phí khớp với tải trong đề:

Không có ảnh nào
    → 0 instance, KHÔNG tốn tiền
        ↓
Rất nhiều ảnh cùng lúc
    → tự chạy nhiều instance song song
        ↓
    Trả tiền theo: số lần gọi × thời gian chạy

Xem thêm câu #12486 (lô 131): cùng một câu hỏi, cùng đáp án Cloud Functions. Chỉ khác chữ cái — ở đó là C, ở đây là D. Khoá nhất quán.

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

• C (App Engine Flexible) — đây là phương án gần nhất về mức độ "được quản lý", nhưng nó KHÔNG co về 0: luôn có ít nhất một instance chạy, nên tốn tiền trong những khoảng không có ảnh nào.

• A (Kubernetes Engine) — rất nhiều công quản lý, và cụm chạy liên tục.

• B (Compute Engine) — tự quản máy hoàn toàn, và máy chạy 24/7.

Ghi nhớ

⚠ Chọn dịch vụ theo mô hình kích hoạt — bảng phải thuộc: | Mô hình | Dịch vụ | |---|---| | Phản ứng với SỰ KIỆN, xử lý ngắn | Cloud Functions | | Container, HTTP hoặc sự kiện, co về 0 | Cloud Run | | Ứng dụng web nhiều route | App Engine | | Microservice phức tạp | GKE | | Cần kiểm soát hệ điều hành | Compute Engine |

Từ khoá nhận diện:

"khi có tệp mới trong Cloud Storage" → Cloud Functions "API chạy liên tục" → App Engine hoặc Cloud Run "đã có container" → Cloud Run "tải lúc có lúc không, rẻ nhất" → dịch vụ co về 0 "App Engine Flexible" → KHÔNG co về 0

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có được gọi không | Cloud Logging, lọc theo tên hàm | | Xử lý mất bao lâu | chỉ số execution time | | Có lỗi không | chỉ số error rate, và log của hàm |

Và một tính chất phải tính tới ngay khi viết hàm loại này: sự kiện có thể được gửi hơn một lần. Cloud Storage đảm bảo giao ít nhất một lần, nên hãy làm cho thao tác ghi kết quả idempotent — chẳng hạn đặt tên tệp kết quả theo tên tệp gốc — để một ảnh xử lý hai lần không tạo ra hai bản ghi khác nhau.

Đáp án

D — INTERNAL TCP/UDP Load Balancing.

Vì sao đúng

Ba từ khoá trong đề: lưu lượng từ tài nguyên TRONG CÙNG VPC, TCP, IPv4.

⚠ Điểm mấu chốt — "internal" vì nguồn nằm trong VPC:

Lưu lượng đến từ tài nguyên TRONG CÙNG VPC
        ↓
    → không đến từ internet
        ↓
    → cần load balancer NỘI BỘ (internal)
        ↓
    Load balancer NGOẠI (external)
      có IP công cộng → sai mô hình,
      và lưu lượng phải đi vòng ra ngoài

⚠ Và "TCP/UDP" vì đây là tầng 4:

Đề nói "tất cả lưu lượng là TCP"
        ↓
    → không nói gì về HTTP
        ↓
    → dùng load balancer TẦNG 4
        ↓
Internal TCP/UDP Load Balancing
        ↓
    - Passthrough: GIỮ NGUYÊN IP nguồn
    - Không kết thúc kết nối
    - Độ trễ rất thấp
    - Theo REGION

⚠ Kiến trúc điển hình dùng nó:

Tầng web (nhiều VM)
        ↓
    gọi tới tầng ứng dụng nội bộ
        ↓
Internal TCP/UDP LB (IP riêng cố định)
        ↓
    Phân phối tới nhóm VM tầng ứng dụng
        ↓
    → tầng web chỉ cần biết MỘT địa chỉ IP riêng
    → thêm bớt VM phía sau không ảnh hưởng gì

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

• C (Network TCP/UDP Load Balancing) — đây là phương án gần nhất và cùng tầng 4, cùng passthrough, nhưng đây là load balancer NGOẠI: nó có IP công cộng và phục vụ lưu lượng từ internet. Đề nói rõ nguồn nằm trong cùng VPC.

• A (TCP Proxy Load Balancing) — là load balancer NGOẠI, toàn cầu, và kết thúc kết nối TCP (proxy) nên không giữ IP nguồn.

• B (SSL Proxy Load Balancing) — cũng là ngoại và toàn cầu, dành cho lưu lượng TLS không phải HTTP. Đề không nhắc tới TLS.

Ghi nhớ

⚠ Các load balancer của Google Cloud — bảng phải thuộc: | Loại | Tầng | Trong/Ngoài | Đặc điểm | |---|---|---|---| | Global external HTTP(S) | 7 | ngoài | URL map, anycast, CDN, Cloud Armor | | Internal HTTP(S) | 7 | trong | URL map, trong VPC | | External passthrough Network | 4 | ngoài | giữ IP nguồn, theo Region | | Internal passthrough (TCP/UDP) | 4 | trong | giữ IP nguồn, IP riêng, theo Region | | TCP Proxy / SSL Proxy | 4 | ngoài | toàn cầu, kết thúc kết nối |

Từ khoá nhận diện:

"lưu lượng từ trong VPC, TCP" → Internal TCP/UDP LB "lưu lượng từ trong VPC, HTTP có định tuyến URL" → Internal HTTP(S) LB "từ internet, web" → Global external HTTP(S) LB "từ internet, TCP/UDP, giữ IP nguồn" → External passthrough Network LB "TLS không phải HTTP, toàn cầu" → SSL Proxy LB

⚠ Passthrough ↔ Proxy — khác biệt quan trọng: | | Passthrough | Proxy | |---|---|---| | Kết nối | giữ nguyên, không kết thúc | kết thúc rồi mở kết nối mới | | IP nguồn | GIỮ NGUYÊN của client | thay bằng IP của LB | | Độ trễ | thấp hơn | cao hơn một chút | | Tính năng | ít | nhiều: TLS, header, định tuyến | | Ví dụ | Network LB, Internal TCP/UDP LB | HTTP(S) LB, TCP/SSL Proxy |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | LB thuộc loại nào | gcloud compute forwarding-rules describe <ten> → loadBalancingScheme | | Backend có khoẻ không | gcloud compute backend-services get-health <ten> --region=<region> | | Firewall đã mở dải health check chưa | gcloud compute firewall-rules list --filter="sourceRanges:130.211.0.0/22" |

Và một cấu hình rất đáng bật khi kiến trúc trải nhiều Region: global access cho Internal TCP/UDP Load Balancer. Mặc định chỉ client trong cùng Region gọi được; bật tuỳ chọn này cho phép client ở Region khác trong cùng VPC cũng truy cập được — thứ rất hay cần khi hệ thống mở rộng mà không ai muốn dựng thêm một load balancer nữa.

Đáp án

B — gsutil iam ch allUsers:objectViewer gs://free-photos-on-gcp

Vì sao đúng

Ba điều cần đúng: công cụ là gsutil, nhóm con là iam ch, và vai trò là objectViewer.

⚠ Điểm mấu chốt — cú pháp gsutil iam ch:

gsutil iam ch <MEMBER>:<ROLE> gs://<bucket>
        ↓
    iam ch  → "change IAM policy"
        ↓
    allUsers → mọi người trên internet,
               kể cả không đăng nhập
        ↓
    objectViewer → ĐỌC ĐỐI TƯỢNG
        ↓
    → đúng nhu cầu "cho mọi người đọc ảnh"

⚠ Vì sao là objectViewer chứ không phải Viewer:

roles/storage.objectViewer
        ↓
    ĐỌC nội dung ĐỐI TƯỢNG trong bucket
        ↓
    → đây là thứ cần để xem ảnh

Không có vai trò nào tên đơn giản là "Viewer"
trong ngữ cảnh này
        ↓
    (roles/viewer là BASIC ROLE cấp project,
     hoàn toàn khác và quá rộng)

⚠ Nhưng phải nói rõ về rủi ro của allUsers:

allUsers = CÔNG KHAI HOÀN TOÀN
        ↓
    Bất kỳ ai có URL đều đọc được
    Không cần đăng nhập
        ↓
    Cần cân nhắc:
      - Public Access Prevention có đang bật không
        (Organization Policy có thể CHẶN việc này)
      - chi phí dữ liệu ra nếu bị tải nhiều
      - đặt Cloud CDN trước để giảm chi phí
        ↓
    Chia sẻ CÓ KIỂM SOÁT hơn:
      - signed URL (hết hạn theo thời gian)
      - allAuthenticatedUsers (phải đăng nhập Google)

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

• A (gsutil ch allUsers:Viewer ...) — đây là phương án gần nhất và dùng đúng công cụ, nhưng thiếu nhóm con iam: cú pháp đúng là gsutil iam ch. (gsutil acl ch là lệnh khác, thao tác trên ACL kiểu cũ.)

• C (gcloud iam ch ...) — sai công cụ: gcloud iam quản lý vai trò và service account, không thao tác trên bucket. Với gcloud thì lệnh đúng là gcloud storage buckets add-iam-policy-binding.

• D (gcloud ch ...) — không có cấu trúc lệnh nào như vậy.

Ghi nhớ

⚠ Ba cách cấp quyền công khai cho bucket — bảng phải thuộc: | Công cụ | Lệnh | |---|---| | gsutil (cũ) | gsutil iam ch allUsers:objectViewer gs://<bucket> | | gcloud storage (mới) | gcloud storage buckets add-iam-policy-binding gs://<bucket> --member=allUsers --role=roles/storage.objectViewer | | Console | Permissions → Grant access | | Gỡ quyền | gsutil iam ch -d allUsers:objectViewer gs://<bucket> |

Từ khoá nhận diện:

"cho mọi người đọc" → allUsers + objectViewer "chỉ người đã đăng nhập Google" → allAuthenticatedUsers "chia sẻ tạm thời, có hạn" → signed URL "chia sẻ cho cả tổ chức" → domain:congty.com "gsutil acl ch" → ACL kiểu CŨ — nên dùng IAM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket có công khai không | gsutil iam get gs://<bucket> — tìm allUsers | | Đọc thử không cần đăng nhập | mở URL công khai trong cửa sổ ẩn danh | | Có bị chặn bởi policy không | gcloud storage buckets describe → publicAccessPrevention |

Và một điều nên kiểm tra trước khi chạy lệnh này trong môi trường doanh nghiệp: Organization Policy có đang bật Public Access Prevention hay không. Nhiều tổ chức bật nó ở cấp tổ chức để tránh rò rỉ dữ liệu, và khi đó lệnh sẽ bị từ chối — một hành vi đúng đắn, và câu trả lời không phải là gỡ chính sách mà là dùng signed URL hoặc Cloud CDN cho nhu cầu chia sẻ.

Đáp án

D — Cloud Pub/Sub.

Vì sao đúng

Đề mô tả chính xác vai trò của một hàng đợi tin nhắn: nhận dữ liệu tốc độ cao, lưu tạm cho tới khi bên xử lý sẵn sàng, và là dịch vụ được quản lý.

⚠ Điểm mấu chốt — Pub/Sub là bộ đệm giữa hai tốc độ khác nhau:

Thiết bị IoT gửi dữ liệu RẤT NHANH
        ↓
    Ứng dụng xử lý chỉ tiêu thụ được
    ở tốc độ nhất định
        ↓
    Không có bộ đệm
        ↓
    → mất dữ liệu khi có đợt tăng đột biến
        ↓
PUB/SUB
        ↓
    Nhận và LƯU TRỮ tin nhắn
    → mặc định giữ tới 7 NGÀY
        ↓
    Bên xử lý tiêu thụ theo tốc độ của mình
        ↓
    → tách rời hoàn toàn nhà sản xuất
      và người tiêu thụ

⚠ Và nó co giãn tự động, không cần cấu hình:

Pub/Sub
        ↓
    KHÔNG có shard, không có partition
    KHÔNG cần cấp phát năng lực
        ↓
    → tự co giãn tới hàng triệu message mỗi giây
    → đúng nghĩa "dịch vụ được quản lý"
        ↓
    (Khác Kafka hay Kinesis, nơi bạn phải
     tính số partition hoặc shard)

⚠ Kiến trúc IoT điển hình trên GCP:

Thiết bị
    ↓
PUB/SUB          ← nhận và đệm      ← đề này
    ↓
DATAFLOW         ← xử lý luồng
    ↓
BIGTABLE         ← dữ liệu nóng, độ trễ thấp
    +
BIGQUERY         ← dữ liệu lịch sử, phân tích
    ↓
LOOKER           ← báo cáo

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

• A (Cloud Dataflow) — đây là phương án gần nhất vì nó thường đứng ngay sau Pub/Sub trong kiến trúc luồng, nhưng Dataflow là công cụ XỬ LÝ, không phải hàng đợi lưu trữ tạm. Đề nói rõ cần "một hàng đợi có thể lưu dữ liệu".

• C (Bigtable) — CSDL để lưu dữ liệu lâu dài, không phải hàng đợi tách rời nhà sản xuất và người tiêu thụ.

• B (Cloud Dataproc) — nền tảng Hadoop/Spark, không phải hàng đợi.

Ghi nhớ

⚠ Pub/Sub — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Mô hình | publish/subscribe — nhiều người đăng ký cùng một topic | | Co giãn | tự động, không cấu hình shard | | Giữ tin nhắn | mặc định 7 ngày (cấu hình 10 phút – 31 ngày) | | Đảm bảo giao | ít nhất một lần — hoặc đúng một lần với exactly-once | | Thứ tự | không đảm bảo mặc định — bật ordering key nếu cần | | Hai kiểu nhận | pull và push | | Dead letter topic | tin nhắn xử lý hỏng nhiều lần được chuyển sang đây |

Từ khoá nhận diện:

"hàng đợi, đệm dữ liệu, tách rời" → Pub/Sub "xử lý luồng" → Dataflow "lưu dữ liệu IoT, độ trễ thấp" → Bigtable "phân tích lịch sử" → BigQuery "cần thứ tự tin nhắn" → ordering key

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tồn đọng không | num_undelivered_messages trong Cloud Monitoring | | Subscription cấu hình ra sao | gcloud pubsub subscriptions describe <ten> | | Tin nhắn có tới không | gcloud pubsub subscriptions pull <ten> --auto-ack |

Và một chỉ số nên đặt cảnh báo ngay từ ngày đầu: oldest_unacked_message_age. Nó cho biết tin nhắn cũ nhất chưa được xử lý đã nằm trong hàng đợi bao lâu — dấu hiệu sớm và rõ ràng nhất cho việc người tiêu thụ đang không theo kịp, thường xuất hiện trước khi bất kỳ ai nhận ra dữ liệu đang bị chậm trễ.

Đáp án

A, C và E — ADMIN ACTIVITY, SYSTEM EVENT và DATA ACCESS.

Vì sao đúng

Cloud Audit Logs có bốn loại, và ba loại này có ở mọi project, folder và organization.

⚠ Bốn loại audit log — bảng cần thuộc:

ADMIN ACTIVITY                      ← luôn có
        ↓
    Thao tác GHI làm THAY ĐỔI cấu hình
    Ví dụ: tạo VM, sửa IAM policy
        ↓
    → LUÔN BẬT, KHÔNG TẮT ĐƯỢC, MIỄN PHÍ
    → giữ 400 ngày

DATA ACCESS                         ← luôn có
        ↓
    Thao tác ĐỌC dữ liệu
    Ví dụ: đọc đối tượng Cloud Storage
        ↓
    → PHẢI BẬT THỦ CÔNG (trừ BigQuery)
    → CÓ PHÍ, khối lượng rất lớn
    → giữ 30 ngày mặc định

SYSTEM EVENT                        ← luôn có
        ↓
    Hành động do CHÍNH GOOGLE thực hiện
    Ví dụ: live migration của VM
        ↓
    → LUÔN BẬT, MIỄN PHÍ, giữ 400 ngày

POLICY DENIED
        ↓
    Bị từ chối do vi phạm chính sách bảo mật
    → luôn bật, có phí

⚠ Kiểm toán viên cần gì thì lấy ở đâu:

"Ai đã đổi quyền IAM"        → Admin Activity
"Ai đã đọc dữ liệu nhạy cảm" → Data Access (phải bật trước)
"Google đã làm gì với VM"    → System Event
"Ai bị chặn bởi chính sách"  → Policy Denied

Xem thêm câu #12477 (lô 131): cùng một câu hỏi, cùng ba loại log. Chỉ khác chữ cái — ở đó là A, B và D, ở đây là A, C và E. Khoá nhất quán.

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

• D (Policy Access) — đây là phương án gần nhất vì tên gần giống, nhưng loại log đúng tên là Policy DENIED.

• B (User Login) — không phải một loại Cloud Audit Log. Việc đăng nhập được ghi ở Google Workspace audit log hoặc Cloud Identity.

• F (Performance Metrics) — chỉ số hiệu năng thuộc Cloud Monitoring, không phải audit log.

Ghi nhớ

⚠ Bốn loại Cloud Audit Log — bảng phải thuộc: | Loại | Ghi gì | Bật sẵn | Chi phí | |---|---|---|---| | Admin Activity | thay đổi cấu hình | LUÔN BẬT, không tắt được | miễn phí | | Data Access | ĐỌC dữ liệu | phải bật (trừ BigQuery) | CÓ PHÍ | | System Event | hành động của Google | luôn bật | miễn phí | | Policy Denied | bị chặn bởi chính sách | luôn bật | có phí | | Thời gian giữ | Admin và System 400 ngày; Data Access 30 ngày | | |

Từ khoá nhận diện:

"ai đã thay đổi cấu hình" → Admin Activity "ai đã ĐỌC dữ liệu" → Data Access — phải bật trước "Google đã tự làm gì" → System Event "bị chặn bởi VPC Service Controls" → Policy Denied "giữ log lâu hơn" → sink sang Cloud Storage hoặc BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Data Access đã bật chưa | IAM → Audit Logs | | Tìm một hành động | Logs Explorer, logName chứa cloudaudit.googleapis.com | | Log có lưu lâu dài không | gcloud logging sinks list |

Và một cấu hình rất nên dựng sớm cho mục đích kiểm toán: aggregated sink ở cấp organization đổ vào một bucket trong project log riêng, có Bucket Lock. Khi đó log của mọi project gom về một nơi, không ai trong các project thành viên xoá được — điều kiện để một bản ghi kiểm toán có giá trị chứng minh.

Đáp án

D — CLUSTERIP.

Vì sao đúng

Đề nói rõ hai điều: client NỘI BỘ trong cụm, và một địa chỉ IP nội bộ ỔN ĐỊNH.

⚠ Điểm mấu chốt — ClusterIP là kiểu service mặc định:

ClusterIP
        ↓
    Cấp một IP ẢO ỔN ĐỊNH trong cụm
        ↓
    → chỉ truy cập được TỪ BÊN TRONG cụm
    → không lộ ra ngoài
        ↓
    Pod phía sau bị thay, IP pod đổi
        ↓
    → IP của service KHÔNG ĐỔI
    → client nội bộ luôn gọi vào một địa chỉ
        ↓
    Và có DNS nội bộ:
      <ten-service>.<namespace>.svc.cluster.local

⚠ Bốn kiểu service của Kubernetes:

ClusterIP     ← mặc định
        ↓
    IP nội bộ ổn định, chỉ trong cụm

NodePort
        ↓
    Mở một cổng (30000-32767) trên MỌI node
    → truy cập được từ ngoài qua <node-ip>:<port>

LoadBalancer
        ↓
    Tạo một load balancer của nhà cung cấp cloud
    → có IP ngoài (hoặc IP nội bộ nếu khai annotation)

ExternalName
        ↓
    Ánh xạ tên service tới một tên miền BÊN NGOÀI
    → chỉ là bản ghi CNAME, không có proxy

⚠ Và headless service là một biến thể riêng:

Headless service (clusterIP: None)
        ↓
    KHÔNG cấp IP ảo nào
        ↓
    DNS trả về TRỰC TIẾP IP của TỪNG POD
        ↓
    → dùng cho StatefulSet, CSDL phân tán
      nơi client cần biết từng thành viên
    → KHÔNG cho "một IP ổn định" như đề yêu cầu

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

• A (Headless) — đây là phương án gần nhất và cũng là service nội bộ, nhưng nó cố ý KHÔNG cấp IP ổn định: DNS trả về IP của từng pod. Trái thẳng yêu cầu "một địa chỉ IP nội bộ ổn định".

• B (NodePort) — mở cổng trên mọi node để truy cập TỪ NGOÀI, không phải cách chuẩn cho giao tiếp nội bộ.

• C (LoadBalancer) — tạo một load balancer của cloud, mặc định có IP ngoài. Thừa và tốn kém cho giao tiếp trong cụm. (Có thể khai annotation để thành internal LB, nhưng vẫn phức tạp hơn ClusterIP.)

Ghi nhớ

⚠ Bốn kiểu Service của Kubernetes — bảng phải thuộc: | Kiểu | Truy cập từ | Đặc điểm | |---|---|---| | ClusterIP | CHỈ trong cụm | mặc định — IP ảo ổn định | | NodePort | ngoài, qua <node-ip>:<port> | cổng 30000-32767 | | LoadBalancer | ngoài, qua LB của cloud | tự tạo Google Cloud LB | | ExternalName | — | CNAME tới tên miền ngoài | | Headless (clusterIP: None) | trong cụm | DNS trả IP TỪNG POD |

Từ khoá nhận diện:

"client nội bộ, IP ổn định" → ClusterIP "lộ ra internet" → LoadBalancer, hoặc Ingress "StatefulSet, cần biết từng pod" → headless service "định tuyến theo đường dẫn HTTP" → Ingress (dùng Global HTTP(S) LB) "nội bộ nhưng cần load balancer thật" → internal LoadBalancer qua annotation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Service thuộc kiểu nào | kubectl get svc — cột TYPE và CLUSTER-IP | | Service có tìm thấy pod không | kubectl get endpoints <ten> — trống là selector sai | | Gọi thử từ trong cụm | kubectl run -it --rm test --image=busybox -- wget -O- <service> |

Và một nguyên nhân rất phổ biến khi service "không hoạt động": selector không khớp nhãn của pod. Lệnh kubectl get endpoints <ten> sẽ hiện danh sách trống — dấu hiệu rõ ràng nhất, và nhanh hơn nhiều so với việc đi kiểm tra mạng hay firewall khi vấn đề thực ra chỉ là một nhãn viết sai một ký tự.

Đáp án

D — Không cần làm gì cả, đây là hành vi MẶC ĐỊNH.

Vì sao đúng

Google Cloud mã hoá mọi dữ liệu khi lưu trữ theo mặc định, ở mọi dịch vụ, không cần bật gì.

⚠ Điểm mấu chốt — mã hoá khi lưu là mặc định, không tắt được:

Cloud Storage (và mọi dịch vụ lưu trữ của GCP)
        ↓
    Dữ liệu được mã hoá TRƯỚC KHI ghi xuống đĩa
        ↓
    Thuật toán AES-256
    Khoá do Google quản lý mặc định
        ↓
    → KHÔNG có tuỳ chọn để TẮT
    → không tốn thêm chi phí
    → hoàn toàn trong suốt với ứng dụng

⚠ Ba mức kiểm soát khoá — bạn chọn mức nào:

GOOGLE-MANAGED (mặc định)
        ↓
    Google tạo, xoay và quản lý khoá
    → không cần làm gì

CMEK — Customer-Managed Encryption Keys
        ↓
    Khoá của bạn trong Cloud KMS
    → kiểm soát xoay khoá, thu hồi, ghi log dùng khoá
    → dùng khi có yêu cầu tuân thủ

CSEK — Customer-Supplied Encryption Keys
        ↓
    Bạn cung cấp khoá TRONG MỖI REQUEST
    → Google KHÔNG lưu khoá
    → mất khoá là MẤT DỮ LIỆU VĨNH VIỄN

⚠ Và mã hoá KHI TRUYỀN cũng mặc định:

Truy cập Cloud Storage
        ↓
    Qua HTTPS/TLS
        ↓
    Muốn ÉP chỉ dùng HTTPS
        ↓
    → bucket policy hoặc Organization Policy
    → thực ra Cloud Storage đã yêu cầu TLS
      cho mọi API request

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

• C (dựng CMEK và dùng khoá đó mã hoá dữ liệu trước khi lưu) — đây là phương án gần nhất và CMEK là tính năng có thật, rất hữu ích, nhưng câu hỏi chỉ yêu cầu "bảo đảm dữ liệu được mã hoá" — điều đó đã có sẵn. CMEK là để kiểm soát khoá, không phải để bật mã hoá.

• A (dùng cờ --encrypt với gsutil) — không có cờ này.

• B (đặt lifecycle policy khai bật mã hoá) — lifecycle policy quyết định chuyển lớp lưu trữ hay xoá theo tuổi, hoàn toàn không liên quan tới mã hoá.

Ghi nhớ

⚠ Mã hoá trên Google Cloud — bảng phải thuộc: | Loại | Trạng thái | |---|---| | Khi lưu (at rest) | MẶC ĐỊNH, mọi dịch vụ, AES-256, không tắt được | | Khi truyền (in transit) | MẶC ĐỊNH qua TLS | | Khi đang dùng (in use) | Confidential Computing — phải chọn | | Kiểm soát khoá | Google-managed → CMEK → CSEK | | Chi phí | mặc định miễn phí; CMEK trả phí Cloud KMS |

Từ khoá nhận diện:

"bảo đảm dữ liệu được mã hoá" → đã có sẵn, mặc định "cần KIỂM SOÁT khoá, xoay khoá, ghi log dùng khoá" → CMEK "khoá không được lưu ở Google" → CSEK "mã hoá BỘ NHỚ khi đang xử lý" → Confidential VM "khoá phải nằm trong HSM" → Cloud HSM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket dùng khoá nào | gcloud storage buckets describe gs://<ten> → defaultKmsKeyName | | Đối tượng mã hoá bằng gì | gcloud storage objects describe gs://<ten>/<tep> | | Ai đã dùng khoá KMS | Cloud Audit Logs, lọc cloudkms.googleapis.com |

Và một điều đáng nhớ khi đọc đề thi: câu hỏi "cần làm gì để dữ liệu được mã hoá" trên Google Cloud thường có đáp án là "không cần làm gì". Mã hoá khi lưu là mặc định ở mọi dịch vụ, nên khi một câu hỏi vẫn đòi hành động, hãy đọc kỹ xem yêu cầu thật sự có phải là kiểm soát khoá hay không.