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

Tìm thấy 395 câu.

Câu 41
What storage solution can a corporate wellness platform company use on Google Cloud Platform that automatically replicates data over at least two geographic locations to comply with their long-term data retention policy?
  1. A SSD Disk for Compute Engine
  2. B Persistent Disk for Compute Engine
  3. C Bigtable is a fully managed, petabyte-scale, NoSQL database service provided by Google Cloud.
  4. D BigQuery on Google Cloud
Xem giải thích

Đáp án

D — BigQuery trên Google Cloud.

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

⚠ Câu trả lời tự nhiên nhất KHÔNG có trong danh sách phương án.

Phương án Đánh giá
⚠ Cloud Storage multi-region ⚠ câu trả lời tự nhiên nhất — KHÔNG được đưa ra
⚠ BigQuery (khoá) ⚠ ĐÚNG: vị trí multi-region US/EU nhân bản qua nhiều vùng
Ba phương án còn lại ⚠ đều là lưu trữ trong MỘT vùng hoặc một zone

⚠ KHÔNG sửa khoá — trong bốn phương án đã cho, ⚠ chỉ BigQuery có tuỳ chọn multi-region.

Vì sao đúng

⚠ BigQuery có ba mức vị trí: | Mức | Ví dụ | Nhân bản | |---|---|---| | ⚠ Multi-region | ⚠ US, EU | ⚠ qua NHIỀU vùng địa lý — đề này | | ⚠ Region | ⚠ asia-southeast1 | ⚠ trong một vùng | | ⚠ BigQuery luôn nhân bản | ⚠ dữ liệu được lưu ở ít nhất hai zone | |

⚠ Cộng thêm cho chính sách lưu trữ dài hạn: ⚠ long-term storage — ⚠ bảng không sửa trong 90 ngày ⚠ tự động giảm giá lưu trữ khoảng một nửa.

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

  • C (Bigtable) — ⚠ cụm nằm trong MỘT vùng: ⚠ muốn nhiều vùng phải tự cấu hình nhân bản đa cụm, ⚠ không tự động.

  • B (Persistent Disk cho Compute Engine) — ⚠ gắn với zone hoặc region: ⚠ regional PD chỉ nhân bản qua hai zone TRONG một vùng, ⚠ không phải hai vị trí địa lý.

  • A (SSD Disk cho Compute Engine) — ⚠ local SSD còn tệ hơn: ⚠ gắn vật lý vào máy chủ, ⚠ mất dữ liệu khi VM dừng.

Ghi nhớ

⚠ Phạm vi nhân bản của các dịch vụ lưu trữ — bảng phải thuộc: | Dịch vụ | Phạm vi | |---|---| | ⚠ Cloud Storage multi-region | ⚠ nhiều vùng địa lý — bền nhất | | ⚠ BigQuery US/EU | ⚠ nhiều vùng | | ⚠ Cloud Spanner multi-region | ⚠ nhiều vùng, nhất quán mạnh | | ⚠ Regional Persistent Disk | ⚠ hai ZONE trong một vùng | | ⚠ Zonal PD, Local SSD | ⚠ một zone — local SSD mất khi VM dừng |

Từ khoá nhận diện:

"nhân bản qua ít nhất hai vị trí địa lý" → ⚠ multi-region (Cloud Storage hoặc BigQuery) "lưu trữ dài hạn giá rẻ" → ⚠ Cloud Storage Archive/Coldline "CSDL quan hệ toàn cầu nhất quán mạnh" → ⚠ Spanner "mất dữ liệu khi VM dừng" → ⚠ Local SSD

⚠ Độ bền của Cloud Storage Con số
⚠ 99,999999999% (11 số 9) mỗi năm ⚠ mọi lớp lưu trữ
⚠ Khác biệt giữa các lớp là ĐỘ SẴN SÀNG và GIÁ ⚠ không phải độ bền
⚠ Multi-region: 99,95% sẵn sàng
⚠ Archive: 99,9%, phí lấy dữ liệu cao
⚠ BigQuery long-term storage Đặc điểm
⚠ Bảng hoặc phân vùng không sửa 90 ngày
⚠ Giá lưu trữ giảm khoảng 50%
⚠ TỰ ĐỘNG, không phải làm gì
⚠ Hiệu năng truy vấn KHÔNG đổi
⚠ Sửa một dòng ⚠ đồng hồ 90 ngày đếm lại từ đầu cho phân vùng đó
⚠ Chọn vị trí dữ liệu — điều phải cân nhắc Điều
⚠ Quy định chủ quyền dữ liệu ⚠ dữ liệu phải nằm trong lãnh thổ nào
⚠ Độ trễ tới người dùng
⚠ Chi phí lưu trữ và chi phí truyền ra
⚠ Quan trọng ⚠ vị trí của dataset BigQuery KHÔNG đổi được sau khi tạo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dataset đang ở vị trí nào | ⚠ không đổi được, phải tạo mới và chép | | Có ràng buộc pháp lý về nơi lưu dữ liệu không | ⚠ gcp.resourceLocations | | Chi phí lưu trữ dài hạn đã tính chưa | |

Và điều dễ mắc kẹt nhất với BigQuery: vị trí của dataset là quyết định một chiều. Chọn sai vùng rồi thì cách duy nhất là tạo dataset mới và sao chép toàn bộ dữ liệu sang.

Câu 42
As a virtual event platform company, we are planning to move our backup and disaster recovery solutions to Google Cloud Platform (GCP) for analysis. Our production environment will remain on-premises. What GCP solution would you recommend for a scalable and cost-efficient option?
  1. A Continuous updates can be performed on BigQuery through a data pipeline job.
  2. B One approach to utilize Cloud Storage is by using gsutil through a scheduled task.
  3. C Batch upload jobs are scheduled regularly to utilize Cloud Datastore.
  4. D Persistent Disk is utilized by Compute Engine Virtual Machines.
Xem giải thích

Đáp án

B — Dùng Cloud Storage với gsutil chạy trong một tác vụ theo lịch.

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

⚠ Câu này GẦN TRÙNG với một câu khác trong cùng lô (#15823).

Điểm So sánh
⚠ Cùng kịch bản ⚠ chuyển sao lưu và DR lên Google Cloud, production ở lại tại chỗ
⚠ Khoá cùng ý ⚠ Cloud Storage + gsutil theo lịch
⚠ Khác ⚠ #15823 có thêm Cloud Interconnect trong phương án
⚠ Nhớ chung một điều ⚠ sao lưu lên đám mây = Cloud Storage, không phải BigQuery hay Datastore

Vì sao đúng

⚠ Ba yêu cầu và cách Cloud Storage đáp ứng: | Yêu cầu | Cloud Storage | |---|---| | ⚠ Co giãn được (scalable) | ⚠ không giới hạn dung lượng, không cần cấp phát trước | | ⚠ Tiết kiệm chi phí | ⚠ Nearline/Coldline/Archive rất rẻ | | ⚠ Cho sao lưu và DR | ⚠ đúng mục đích thiết kế |

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

  • A (cập nhật liên tục BigQuery qua đường ống dữ liệu) — ⚠ BigQuery là kho PHÂN TÍCH: ⚠ đắt hơn nhiều cho việc chỉ lưu trữ, ⚠ và không phải mô hình sao lưu.

  • C (tải theo lô định kỳ vào Cloud Datastore) — ⚠ Datastore là CSDL NoSQL cho ứng dụng: ⚠ hoàn toàn sai mục đích.

  • D (dùng Persistent Disk của Compute Engine) — ⚠ phải có VM chạy mới dùng được: ⚠ trả tiền cho đĩa liên tục, ⚠ dung lượng cố định, ⚠ đắt hơn nhiều so với kho đối tượng.

Ghi nhớ

⚠ So sánh chi phí lưu trữ (tương đối) — bảng phải thuộc: | Dịch vụ | Chi phí lưu 1 TB/tháng | |---|---| | ⚠ Cloud Storage Archive | ⚠ rẻ nhất | | ⚠ Cloud Storage Coldline | ⚠ rẻ | | ⚠ Cloud Storage Standard | ⚠ trung bình | | ⚠ Persistent Disk | ⚠ đắt hơn nhiều | | ⚠ BigQuery active storage | ⚠ đắt cho việc chỉ lưu trữ |

Từ khoá nhận diện:

"sao lưu, DR, tiết kiệm chi phí" → ⚠ Cloud Storage + lớp lạnh "phân tích SQL" → ⚠ BigQuery "đĩa gắn vào VM" → ⚠ Persistent Disk "chuyển hàng trăm TB một lần" → ⚠ Transfer Appliance

⚠ Công cụ chuyển dữ liệu lên Cloud Storage Công cụ
⚠ gsutil / gcloud storage ⚠ script, tác vụ theo lịch — đề này
⚠ Storage Transfer Service ⚠ từ đám mây khác, từ URL, từ tại chỗ (có agent)
⚠ Transfer Appliance ⚠ thiết bị vật lý, hàng trăm TB
⚠ Chọn theo ⚠ khối lượng và băng thông sẵn có
⚠ Object Lifecycle cho sao lưu Quy tắc
⚠ Sau 30 ngày → Nearline
⚠ Sau 90 ngày → Coldline
⚠ Sau 365 ngày → Archive
⚠ Sau N năm → xoá ⚠ theo chính sách lưu trữ
⚠ Cảnh báo ⚠ mỗi lớp có thời gian lưu TỐI THIỂU, xoá sớm vẫn bị tính phí đủ
⚠ Bảo vệ bản sao lưu Cách
⚠ Retention policy + Bucket Lock ⚠ không ai xoá được trước hạn
⚠ Object versioning
⚠ Project riêng cho bucket sao lưu
⚠ Kịch bản phải phòng ⚠ mã tống tiền xoá cả dữ liệu gốc lẫn bản sao lưu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã thử khôi phục từ bản sao lưu chưa | | | Ai có quyền xoá bucket sao lưu | ⚠ nên là rất ít người, hoặc không ai | | Lifecycle có chuyển lớp tự động không | ⚠ tiết kiệm đáng kể |

Và bài học chung của cả hai câu về sao lưu trong lô này: chọn đúng loại kho lưu trữ quan trọng hơn chọn đúng công cụ chuyển dữ liệu. Đưa bản sao lưu vào một cơ sở dữ liệu phân tích là trả giá cao cho một thứ không ai truy vấn.

Câu 43
An event ticketing platform company allows users to post comments and event reviews. The company needs to ensure that the text does not contain any sensitive information before publishing the comments or reviews. What Google Cloud Service can the company use to accomplish this task?
  1. A The service offered by Google Cloud for managing encryption keys is known as Cloud Key Management Service.
  2. B The Web Security Scanner is a Google Cloud tool that helps identify security vulnerabilities in web applications.
  3. C Could you please provide me with a sentence or question related to BigQuery that needs to be rephrased?
  4. D The API of Cloud Data Loss Prevention
Xem giải thích

Đáp án

D — API của Cloud Data Loss Prevention.

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

⚠ Phương án C là một mảnh vụn văn bản, không phải phương án thật.

Phương án Nội dung
⚠ C ⚠ "Could you please provide me with a sentence or question related to BigQuery..."
⚠ Đây là ⚠ lời nhắc soạn thảo lọt vào bộ đề
⚠ Ảnh hưởng ⚠ không đổi đáp án, nhưng cho thấy đề được sinh tự động và không rà lại

⚠ Khi gặp phương án vô nghĩa như vậy, loại ngay và tập trung vào ba phương án còn lại.

Vì sao đúng

⚠ Bài toán: kiểm tra bình luận và đánh giá của người dùng có chứa thông tin nhạy cảm không, TRƯỚC khi đăng.

⚠ Người dùng gửi bình luận
        ↓
⚠ Gọi DLP API kiểm tra nội dung
        ↓
⚠ Phát hiện infoType nhạy cảm?
   ⚠ CÓ  → ⚠ che đi hoặc từ chối đăng
   ⚠ KHÔNG → ⚠ đăng bình thường

⚠ DLP là dịch vụ duy nhất trong danh sách ĐỌC và HIỂU được nội dung văn bản.

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

  • B (Web Security Scanner) — ⚠ quét LỖ HỔNG của ứng dụng web: ⚠ tìm XSS, ⚠ nội dung hỗn hợp, ⚠ thư viện lỗi thời; ⚠ không đọc nội dung người dùng nhập.

  • A (Cloud Key Management Service) — ⚠ quản khoá mã hoá: ⚠ không phân tích nội dung.

  • C (mảnh vụn về BigQuery) — ⚠ không phải phương án hợp lệ.

Ghi nhớ

⚠ Ai đọc được nội dung — bảng phải thuộc: | Dịch vụ | Đọc gì | |---|---| | ⚠ Sensitive Data Protection (DLP) | ⚠ văn bản, ảnh, bảng — tìm dữ liệu nhạy cảm | | ⚠ Natural Language API | ⚠ cảm xúc, thực thể, phân loại nội dung | | ⚠ Vision API SafeSearch | ⚠ ảnh phản cảm, bạo lực | | ⚠ Web Security Scanner | ⚠ lỗ hổng của ỨNG DỤNG, không phải nội dung | | ⚠ Kiểm duyệt nội dung độc hại | ⚠ Natural Language / Model Armor, không phải DLP |

Từ khoá nhận diện:

"tìm thông tin nhạy cảm trong văn bản" → ⚠ DLP API "quét lỗ hổng ứng dụng web" → ⚠ Web Security Scanner "phát hiện nội dung thù ghét, tục tĩu" → ⚠ Natural Language API "ảnh không phù hợp" → ⚠ Vision API SafeSearch

⚠ Hai chế độ dùng DLP Chế độ
⚠ Inspect ⚠ chỉ PHÁT HIỆN và báo cáo
⚠ De-identify ⚠ PHÁT HIỆN và BIẾN ĐỔI (che, thay, token hoá)
⚠ Với bình luận ⚠ inspect để chặn, hoặc de-identify để vẫn đăng được bản đã che
⚠ Mức tin cậy của DLP Mức
⚠ VERY_LIKELY, LIKELY ⚠ khá chắc chắn
⚠ POSSIBLE ⚠ có thể — nhiều báo động giả
⚠ UNLIKELY, VERY_UNLIKELY
⚠ Đặt ngưỡng ⚠ ngưỡng thấp bắt được nhiều nhưng chặn nhầm bình luận sạch
⚠ Cân bằng ⚠ phải thử trên dữ liệu thật của mình
⚠ Thiết kế thực tế cho kiểm duyệt bình luận Thiết kế
⚠ Quét đồng bộ nếu bình luận ngắn ⚠ độ trễ chấp nhận được
⚠ Quét bất đồng bộ nếu khối lượng lớn ⚠ đăng trước, ẩn nếu phát hiện
⚠ Ghi log các lần phát hiện ⚠ để tinh chỉnh ngưỡng
⚠ Có đường cho người rà soát lại ⚠ máy sẽ bắt nhầm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quét trước hay sau khi đăng | ⚠ quyết định rủi ro lộ dữ liệu | | Tỉ lệ báo động giả bao nhiêu | | | Có infoType tuỳ chỉnh cho dữ liệu riêng của mình không | ⚠ mã khách hàng, mã đơn hàng |

Và điều dễ đánh giá thấp khi lọc nội dung người dùng: ngưỡng đặt quá chặt gây hại không kém đặt quá lỏng. Một hệ thống chặn nhầm bình luận bình thường sẽ nhanh chóng bị người vận hành tắt đi.

Câu 44
As a virtual interior design service company, we want to use Google Cloud Platform (GCP) for certain IT workloads. We already use a well-established directory service to manage user identities and lifecycle management, which must remain the `source of truth` directory for identities. What GCP solution can we use to meet our requirements?
  1. A Pub/Sub is a messaging service provided by Google Cloud.
  2. B GCDS stands for Google Cloud Directory Sync.
  3. C SAML (Security Assertion Markup Language) is a protocol used for exchanging authentication and authorization data between parties, particularly between an identity provider and a service provider.
  4. D Identity and Access Management (IAM) in Google Cloud is known as Cloud Identity.
Xem giải thích

Đáp án

B — GCDS, tức Google Cloud Directory Sync.

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

⚠ Câu này GẦN TRÙNG với #15817 trong cùng lô.

Điểm So sánh
⚠ #15817 ⚠ nhân viên nghỉ việc thì tài khoản tự bị thu hồi
⚠ #15834 (câu này) ⚠ thư mục nội bộ phải là nguồn sự thật
⚠ Cùng khoá ⚠ Google Cloud Directory Sync
⚠ Hai mặt của một cơ chế ⚠ đồng bộ một chiều từ thư mục sang Cloud Identity

Vì sao đúng

⚠ Cụm từ quyết định trong đề: ⚠ "phải vẫn là thư mục NGUỒN SỰ THẬT cho danh tính".

⚠ Thư mục nội bộ (AD/LDAP)
   = ⚠ NGUỒN SỰ THẬT
        ↓ ⚠ GCDS đồng bộ MỘT CHIỀU
⚠ Cloud Identity
   = ⚠ BẢN PHẢN CHIẾU
        ↓
⚠ Mọi thay đổi bắt đầu từ
   thư mục nội bộ

⚠ GCDS được thiết kế đúng cho mô hình này — ⚠ Cloud Identity không bao giờ ghi ngược về thư mục nội bộ.

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

  • C (SAML) — ⚠ bẫy hợp lý nhất: ⚠ SAML lo ĐĂNG NHẬP một lần (SSO), ⚠ nhưng ⚠ KHÔNG tạo hay xoá tài khoản. ⚠ Thực tế thường dùng cả hai: GCDS cấp phát tài khoản, SAML lo đăng nhập.

  • D (Cloud Identity chính là IAM của Google Cloud) — ⚠ mô tả sai: ⚠ Cloud Identity quản danh tính (ai tồn tại), ⚠ IAM quản quyền (ai được làm gì); ⚠ và ⚠ Cloud Identity là đích đến, không phải công cụ đồng bộ.

  • A (Pub/Sub) — ⚠ dịch vụ nhắn tin, hoàn toàn không liên quan.

Ghi nhớ

⚠ Ba mảnh của bài toán danh tính lai — bảng phải thuộc: | Mảnh | Công cụ | |---|---| | ⚠ Cấp phát và thu hồi tài khoản | ⚠ GCDS (đồng bộ từ AD/LDAP) | | ⚠ Đăng nhập một lần | ⚠ SAML SSO với IdP của công ty | | ⚠ Đồng bộ mật khẩu (nếu không dùng SSO) | ⚠ G Suite Password Sync (GSPS) | | ⚠ Phân quyền trên tài nguyên | ⚠ IAM |

Từ khoá nhận diện:

"thư mục nội bộ là nguồn sự thật" → ⚠ GCDS "đăng nhập bằng tài khoản công ty" → ⚠ SAML SSO "ai được làm gì trên project" → ⚠ IAM "quản lý danh tính không dùng Workspace" → ⚠ Cloud Identity (bản miễn phí có sẵn)

⚠ GCDS — chi tiết phải nhớ Chi tiết
⚠ Chạy TẠI CHỖ, không phải dịch vụ đám mây
⚠ Đồng bộ MỘT CHIỀU: LDAP → Google
⚠ Có chế độ mô phỏng (simulated sync) ⚠ xem trước thay đổi
⚠ Chạy theo lịch, thường mỗi giờ
⚠ Đồng bộ người dùng, nhóm, danh bạ, OU
⚠ KHÔNG đồng bộ ⚠ mật khẩu (cần GSPS), quyền IAM
⚠ Vì sao "một nguồn sự thật" quan trọng Lý do
⚠ Hai nơi quản danh tính là hai nơi để quên
⚠ Nghỉ việc chỉ cần thao tác MỘT chỗ
⚠ Kiểm toán chỉ cần nhìn MỘT nơi
⚠ Không có tài khoản mồ côi
⚠ Dấu hiệu xấu ⚠ phải nhớ "còn phải xoá ở chỗ kia nữa"
⚠ Kiến trúc danh tính lai đầy đủ Thành phần
⚠ AD/LDAP tại chỗ ⚠ nguồn sự thật về nhân sự
⚠ GCDS ⚠ đồng bộ tài khoản sang Cloud Identity
⚠ ADFS hoặc IdP khác + SAML ⚠ xác thực khi đăng nhập
⚠ IAM trên Google Cloud ⚠ cấp quyền theo NHÓM, không theo cá nhân
⚠ Mẹo ⚠ cấp quyền cho Google Group đồng bộ từ AD, thêm/bớt người ở AD là đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài khoản nào tạo trực tiếp trên Cloud Identity không | ⚠ là ngoại lệ ngoài nguồn sự thật | | GCDS chạy có lỗi không | ⚠ theo dõi báo cáo mỗi lần chạy | | Quyền IAM cấp cho nhóm hay cho từng người | ⚠ nhóm dễ quản hơn nhiều |

Và cách kiểm tra nhanh xem kiến trúc danh tính có lành mạnh không: hỏi xem cần thao tác ở mấy hệ thống để cho một người nghỉ việc. Nếu câu trả lời lớn hơn một, thì sớm muộn sẽ có người bị bỏ sót.

Câu 45 Chọn nhiều đáp án
Which two security characteristics are related to the use of VPC peering to connect two VPC networks for a digital marketing agency using Google Cloud Platform? (Choose two.)
  1. A The capability to establish network peering between Google Cloud organizations that are distinct from each other.
  2. B In non-transitive peered networks, communication is limited to directly peered networks only.
  3. C It is possible to create firewall rules using a tag, which then applies to traffic between two peered networks. Additionally, specific subnets can be shared between these peered networks.
  4. D The management of routes, firewalls, and VPNs for peered networks is centralized.
Xem giải thích

Đáp án

A và B — nối được giữa các tổ chức khác nhau, và không có tính bắc cầu

Vì sao đúng

Hai đặc điểm quyết định cách thiết kế khi dùng VPC peering:

  • A. Nối được giữa hai tổ chức khác nhau — peering không đòi hai VPC thuộc cùng một tổ chức hay cùng một dự án, nên dùng được cả với đối tác.
  • B. Không bắc cầu — nếu A nối B và B nối C thì A vẫn không thấy C. Đây là điểm quan trọng nhất về mặt bảo mật: mỗi cặp phải khai tường minh, nên không có đường đi ngoài ý muốn.

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

  • C. Luật tường lửa theo tag áp được sang mạng đã peering — sai: network tag không vượt qua ranh giới peering; phải viết luật theo dải địa chỉ.
  • D. Route, tường lửa và VPN được quản lý tập trung cho các mạng đã peering — sai theo hướng ngược lại: mỗi VPC tự quản lý độc lập phần của mình.
Câu 46
For an event ticketing platform company utilizing Google Cloud Services, what is the international compliance standard that gives directives for information security controls related to the usage and provision of cloud services?
  1. A ISO 27001
  2. B ISO 27017
  3. C ISO 27018
  4. D ISO 27002
Xem giải thích

Đáp án

B — ISO 27017.

Vì sao đúng

⚠ Đề hỏi chính xác: tiêu chuẩn quốc tế đưa ra ⚠ hướng dẫn kiểm soát an toàn thông tin RIÊNG cho việc SỬ DỤNG và CUNG CẤP dịch vụ ĐÁM MÂY.

Tiêu chuẩn Phạm vi
⚠ ISO 27017 ⚠ kiểm soát an toàn thông tin cho DỊCH VỤ ĐÁM MÂY — đề này
⚠ ISO 27001 ⚠ hệ thống quản lý an toàn thông tin (ISMS) nói chung
⚠ ISO 27018 ⚠ bảo vệ PII trong đám mây CÔNG CỘNG
⚠ ISO 27002 ⚠ danh mục kiểm soát chung, không riêng đám mây

⚠ Mẹo nhớ: ⚠ 17 → cloud services (dịch vụ đám mây); ⚠ 18 → PII trong đám mây; ⚠ 01 → hệ thống quản lý; ⚠ 02 → danh mục kiểm soát.

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

  • A (ISO 27001) — ⚠ nói về CÁCH XÂY DỰNG hệ thống quản lý an toàn thông tin: ⚠ áp dụng cho mọi tổ chức, ⚠ không riêng đám mây.

  • C (ISO 27018) — ⚠ bẫy gần nhất: ⚠ đúng là về đám mây, ⚠ nhưng chỉ về bảo vệ dữ liệu cá nhân, ⚠ không phải kiểm soát an toàn thông tin nói chung.

  • D (ISO 27002) — ⚠ danh mục các biện pháp kiểm soát: ⚠ bổ trợ cho 27001, ⚠ không dành riêng cho đám mây.

Ghi nhớ

⚠ Họ ISO 27000 — bảng phải thuộc: | Số | Nội dung | |---|---| | ⚠ 27001 | ⚠ yêu cầu cho ISMS — chứng nhận được | | ⚠ 27002 | ⚠ hướng dẫn triển khai các kiểm soát | | ⚠ 27017 | ⚠ kiểm soát cho dịch vụ ĐÁM MÂY | | ⚠ 27018 | ⚠ bảo vệ PII trong đám mây công cộng | | 27701 | ⚠ quản lý quyền riêng tư, mở rộng của 27001 |

Từ khoá nhận diện:

"kiểm soát riêng cho dịch vụ đám mây" → ⚠ 27017 "bảo vệ dữ liệu cá nhân trên đám mây" → ⚠ 27018 "hệ thống quản lý an toàn thông tin" → ⚠ 27001 "dữ liệu thẻ thanh toán" → ⚠ PCI DSS, không phải ISO

⚠ Các khung tuân thủ hay gặp trong đề Google Cloud Khung
⚠ PCI DSS ⚠ thanh toán thẻ
⚠ HIPAA ⚠ y tế Mỹ — cần ký BAA với Google
⚠ GDPR ⚠ dữ liệu cá nhân châu Âu
⚠ SOC 1/2/3 ⚠ báo cáo kiểm soát của nhà cung cấp dịch vụ
⚠ FedRAMP ⚠ cơ quan liên bang Mỹ
⚠ Tìm bằng chứng ⚠ Compliance Reports Manager của Google Cloud
⚠ ISO 27017 nói thêm gì so với 27002 Nội dung thêm
⚠ Trách nhiệm chia sẻ giữa nhà cung cấp và khách
⚠ Gỡ và trả lại tài sản khi kết thúc hợp đồng
⚠ Tách biệt giữa các khách hàng trong môi trường ảo hoá
⚠ Giám sát hoạt động của khách trên đám mây
⚠ Căn chỉnh môi trường mạng ảo
⚠ Điều phải nhớ về chứng nhận của nhà cung cấp Điều
⚠ Google đạt chuẩn cho HẠ TẦNG của Google
⚠ Ứng dụng của bạn KHÔNG tự động đạt chuẩn
⚠ Không phải dịch vụ nào cũng nằm trong phạm vi chứng nhận ⚠ phải tra danh sách
⚠ Cấu hình sai của bạn làm mất tuân thủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dịch vụ đang dùng có nằm trong phạm vi chứng nhận không | | | Đã tải báo cáo kiểm toán từ Compliance Reports Manager chưa | | | Phần "khách chịu" trong ma trận trách nhiệm ai lo | |

Và cái bẫy đắt giá nhất trong tuân thủ đám mây: nhầm chứng nhận của nhà cung cấp với chứng nhận của mình. Google có thể vượt qua mọi cuộc kiểm toán, và bucket cấu hình sai của bạn vẫn khiến bạn trượt.

Câu 47
A patch for a vulnerability has been released and a DevOps team in a healthcare technology company needs to update their running containers in Google Kubernetes Engine (GKE). What steps should the DevOps team take to accomplish this task?
  1. A Utilize Puppet or Chef to deploy the necessary patch to the container that's currently running.
  2. B Confirm whether auto-upgrade is turned on; if enabled, Google will handle node upgrades within a GKE cluster.
  3. C Set up the containers to automatically upgrade when the base image becomes available in the Container Registry.
  4. D Apply a patch or update the application code, construct a new image, and deploy it again.
Xem giải thích

Đáp án

D — Vá hoặc sửa mã ứng dụng, dựng ảnh mới, rồi triển khai lại

Vì sao đúng

Container là bất biến. Cách làm đúng là sửa ở nguồn: cập nhật ảnh nền hoặc mã, build ảnh mới, đẩy lên registry, rồi cho Kubernetes cuốn chiếu thay pod. Nhờ vậy mọi bản đang chạy đều giống hệt nhau và dựng lại được, còn việc quay lui chỉ là trỏ về thẻ ảnh cũ.

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

  • A. Dùng Puppet hoặc Chef vá container đang chạy — vá tại chỗ khiến container đang chạy khác với ảnh của nó; pod bị khởi động lại là mất bản vá, và không ai biết máy nào đã vá.
  • B. Dựa vào tự động nâng cấp — auto-upgrade của GKE nâng cấp node, không đụng tới ảnh ứng dụng của bạn.
  • C. Cho container tự nâng cấp khi ảnh nền có bản mới — không có cơ chế như vậy; ảnh nền đổi thì phải build lại.
Câu 48
A fitness app company is collaborating with a nutrition company to build an application on Compute Engine. The fitness app company is building the application tier in their GCPOrganization, and the nutrition company is building the storage tier in a different GCP Organization. This is a 3-tier web application. Communication between portions of the application must not traverse the public internet by any means. Which connectivity option should be implemented?
  1. A A Shared VPC is a networking feature in Google Cloud platform that enables multiple projects to use the same VPC network resources.
  2. B Peering of VPCs
  3. C A Virtual Private Network (VPN) is a secure and encrypted connection that enables users to access a private network over the internet. In Google Cloud, Cloud VPN is a service that allows users to connect their on-premises network to Google Cloud securely.
  4. D Cloud Interconnect is a service provided by Google Cloud that enables customers to connect their on-premises data centers to Google Cloud.
Xem giải thích

Đáp án

B — VPC Peering.

Vì sao đúng

⚠ Đọc kỹ ba dữ kiện của đề: | Dữ kiện | Suy ra | |---|---| | ⚠ HAI tổ chức Google Cloud KHÁC NHAU | ⚠ không dùng Shared VPC được | | ⚠ Cả hai đều Ở TRONG Google Cloud | ⚠ không cần VPN hay Interconnect | | ⚠ Không được đi qua Internet công cộng | ⚠ cần đường nội bộ của Google |

⚠ VPC của công ty A (tổ chức A)
        ↕ ⚠ VPC Peering
⚠ VPC của công ty B (tổ chức B)
        ↓
⚠ Lưu lượng đi trên MẠNG NỘI BỘ
   của Google
   ⚠ KHÔNG chạm Internet công cộng

⚠ Điểm quan trọng: ⚠ VPC Peering hoạt động qua ranh giới tổ chức — ⚠ chỉ cần hai bên cùng chấp nhận kết nối.

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

  • A (Shared VPC) — ⚠ chỉ dùng được TRONG MỘT tổ chức: ⚠ host project và service project ⚠ phải cùng một tổ chức Google Cloud; ⚠ đề nói rõ là hai tổ chức khác nhau.

  • C (Cloud VPN) — ⚠ hoạt động được nhưng KHÔNG phù hợp: ⚠ VPN dựng để nối tại chỗ với đám mây; ⚠ dùng giữa hai VPC trong cùng Google Cloud là ⚠ thêm chi phí, thêm độ trễ, giới hạn băng thông vô ích.

  • D (Cloud Interconnect) — ⚠ hoàn toàn sai bối cảnh: ⚠ Interconnect nối trung tâm dữ liệu vật lý với Google Cloud; ⚠ ở đây không có trung tâm dữ liệu nào.

Ghi nhớ

⚠ Nối VPC theo bối cảnh — bảng phải thuộc: | Bối cảnh | Giải pháp | |---|---| | ⚠ Nhiều project CÙNG một tổ chức, dùng chung mạng | ⚠ Shared VPC | | ⚠ Hai VPC, kể cả KHÁC tổ chức | ⚠ VPC Peering — đề này | | ⚠ Nhiều VPC cần định tuyến phức tạp | ⚠ Network Connectivity Center | | ⚠ Tại chỗ ↔ đám mây | ⚠ Cloud VPN hoặc Interconnect | | ⚠ Chỉ cần gọi một dịch vụ cụ thể | ⚠ Private Service Connect |

Từ khoá nhận diện:

"hai tổ chức khác nhau, không qua Internet" → ⚠ VPC Peering "nhiều project chung mạng, cùng tổ chức" → ⚠ Shared VPC "nối tới trung tâm dữ liệu" → ⚠ VPN / Interconnect "chỉ mở một dịch vụ cho bên kia" → ⚠ Private Service Connect

⚠ VPC Peering — đặc điểm phải thuộc Đặc điểm
⚠ Hai bên PHẢI CÙNG chấp nhận ⚠ một bên tạo, bên kia tạo đối ứng
⚠ Dải IP KHÔNG được chồng lấn
⚠ KHÔNG bắc cầu (không transitive) ⚠ A-B, B-C không cho A-C
⚠ Lưu lượng đi trên mạng nội bộ Google ⚠ không ra Internet
⚠ Firewall rule mỗi bên vẫn áp dụng riêng
⚠ Không tính phí kết nối ⚠ chỉ tính lưu lượng liên vùng nếu có
⚠ Shared VPC so với VPC Peering So sánh
⚠ Shared VPC: MỘT mạng, nhiều project ⚠ quản trị tập trung ở host project
⚠ Peering: HAI mạng riêng, nối lại ⚠ mỗi bên tự quản mạng của mình
⚠ Shared VPC: phải cùng tổ chức
⚠ Peering: qua được ranh giới tổ chức
⚠ Hợp tác với công ty khác ⚠ luôn là Peering hoặc Private Service Connect
⚠ Bảo mật khi peering với đối tác bên ngoài Lưu ý
⚠ Firewall rule chặt: chỉ mở đúng cổng và đúng tag
⚠ Không chia sẻ route mặc định nếu không cần
⚠ Cân nhắc Private Service Connect thay vì peering toàn mạng ⚠ phơi bày ít hơn nhiều
⚠ Bật VPC Flow Logs để giám sát
⚠ Nguyên tắc ⚠ peering mở cả mạng, PSC chỉ mở một dịch vụ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dải IP hai bên có chồng lấn không | ⚠ chồng là không peering được | | Firewall có giới hạn đúng cổng cần thiết không | | | Có cần mở cả mạng không, hay chỉ một dịch vụ | ⚠ cân nhắc PSC |

Và câu hỏi nên đặt trước mọi lần peering với đối tác: họ có thật sự cần thấy cả mạng của mình không?. Thường thì không — và khi đó Private Service Connect là lựa chọn phơi bày ít hơn rất nhiều.

Câu 49
As a digital product design agency, how can we ensure that data on our Compute Engine disks is encrypted at rest using Cloud Key Management Service (KMS)? Also, how can we manage Cloud Identity and Access Management (IAM) permissions for these keys in a grouped manner for consistency?
  1. A For each persistent disk, generate a KeyRing that includes one Key. Control the IAM authorizations at the Key level.
  2. B For each persistent disk, generate a KeyRing that has one Key, and regulate the IAM privileges at the KeyRing level.
  3. C For persistent disks, establish a unified KeyRing and include all Keys in it. IAM permissions should be managed at the Key level.
  4. D Consolidate all persistent disks and Keys into a solitary KeyRing and administer the IAM authorizations at the level of the KeyRing.
Xem giải thích

Đáp án

D — Gom tất cả persistent disk và các khoá vào MỘT KeyRing duy nhất, và quản lý quyền IAM ở mức KeyRing.

Vì sao đúng

⚠ Đề có hai yêu cầu: | Yêu cầu | Cách D giải | |---|---| | ⚠ Mã hoá đĩa bằng Cloud KMS | ⚠ CMEK cho persistent disk | | ⚠ Quản quyền theo NHÓM, nhất quán | ⚠ cấp IAM ở mức KeyRing, mọi khoá bên trong kế thừa |

⚠ KeyRing "persistent-disks"
   ├── ⚠ key-disk-1
   ├── ⚠ key-disk-2
   └── ⚠ key-disk-3
        ↑
⚠ Cấp IAM Ở ĐÂY một lần
   → ⚠ mọi khoá bên trong đều áp dụng
   → ⚠ khoá MỚI tạo sau cũng tự kế thừa

⚠ Từ khoá của đề là "in a grouped manner for consistency" — ⚠ nghĩa là một chỗ cấp quyền, không lặp lại.

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

  • C (một KeyRing chung, quản IAM ở mức KEY) — ⚠ gần đúng nhưng ngược yêu cầu: ⚠ cấp ở mức key nghĩa là ⚠ phải làm lại cho từng khoá, ⚠ và khoá mới không kế thừa gì.

  • B (mỗi đĩa một KeyRing riêng, quản ở mức KeyRing) — ⚠ phá vỡ tính nhóm: ⚠ mỗi KeyRing một chính sách, ⚠ có bao nhiêu đĩa thì bấy nhiêu chỗ phải quản.

  • A (mỗi đĩa một KeyRing, quản ở mức Key) — ⚠ tệ nhất: ⚠ vừa nhiều KeyRing, ⚠ vừa cấp quyền lẻ từng khoá.

Ghi nhớ

⚠ Cấu trúc phân cấp Cloud KMS — bảng phải thuộc: | Cấp | Đặc điểm | |---|---| | ⚠ Project | | | ⚠ Location (vùng) | ⚠ key ring gắn với một vị trí, KHÔNG đổi được | | ⚠ KeyRing | ⚠ nhóm logic — cấp IAM Ở ĐÂY để kế thừa | | ⚠ CryptoKey | ⚠ khoá thật, cấp IAM riêng được nếu cần | | ⚠ CryptoKeyVersion | ⚠ phiên bản sau mỗi lần xoay vòng | | ⚠ Kế thừa | ⚠ quyền ở cấp trên chảy xuống cấp dưới |

Từ khoá nhận diện:

"quản quyền theo nhóm, nhất quán" → ⚠ cấp IAM ở mức KeyRing "mỗi khoá một chính sách khác nhau" → ⚠ cấp ở mức Key "khoá phải nằm ở vùng nào" → ⚠ cùng vùng với dữ liệu nó mã hoá

⚠ Vai trò IAM của Cloud KMS phải biết Vai trò
⚠ cloudkms.cryptoKeyEncrypterDecrypter ⚠ dùng khoá để mã/giải mã — cấp cho service agent
⚠ cloudkms.admin ⚠ tạo, xoay vòng, huỷ khoá
⚠ cloudkms.viewer ⚠ xem metadata
⚠ Tách quyền quan trọng ⚠ người quản khoá KHÔNG nên là người truy cập dữ liệu
⚠ Nguyên tắc tách nhiệm vụ với KMS Nguyên tắc
⚠ Đội bảo mật quản KHOÁ ⚠ admin của KMS
⚠ Đội ứng dụng dùng DỮ LIỆU ⚠ không có quyền huỷ khoá
⚠ Không ai vừa quản khoá vừa đọc dữ liệu
⚠ Lý do ⚠ một người không được tự mình vừa mở khoá vừa lấy đi
⚠ Bẫy vận hành với CMEK cho persistent disk Bẫy
⚠ Khoá và đĩa phải CÙNG vùng
⚠ Service agent Compute Engine cần quyền dùng khoá ⚠ thiếu là VM không khởi động
⚠ Vô hiệu khoá = đĩa không đọc được ⚠ VM đang chạy vẫn chạy tới khi khởi động lại
⚠ Huỷ khoá = MẤT dữ liệu vĩnh viễn
⚠ Không chuyển đĩa sang khoá khác trực tiếp được ⚠ phải tạo snapshot và tạo đĩa mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyền cấp ở mức KeyRing hay từng Key | | | Ai có quyền huỷ khoá | ⚠ nên đếm được trên một bàn tay | | Lịch xoay vòng đã đặt chưa | |

Và nguyên tắc thiết kế rút ra được từ câu này, áp dụng cho mọi hệ thống phân quyền: cấp quyền ở mức nhóm, không ở mức từng đối tượng. Nếu không, mỗi tài nguyên mới sinh ra là một cơ hội để quên.

Câu 50 Chọn nhiều đáp án
Your team needs to make sure that a Compute Engine instance does not have access to the internet or to any Google APIs or services.
Which two settings must remain disabled to meet these requirements? (Choose two.)
  1. A Public IP
  2. B IP Forwarding
  3. C Private Google Access
  4. D Static routes
  5. E IAM Network User Role
Xem giải thích

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào Google Cloud Platform (GCP), cụ thể là dịch vụ Compute Engine (VM instances). Yêu cầu là đảm bảo một instance không thể truy cập internet hoặc bất kỳ Google APIs/dịch vụ nào (như Storage, BigQuery, v.v.). Để đạt được điều này, cần xác định hai thiết lập phải giữ ở trạng thái disabled (tắt).

📘 Ngữ cảnh kỹ thuật (dựa trên tài liệu GCP cập nhật đến 2024-2026):

✅ Đáp án đúng (Chọn hai):

Public IP và Private Google Access.
Lý do chọn: Hai thiết lập này trực tiếp kiểm soát khả năng outbound của instance đến internet/Google APIs. Giữ chúng disabled sẽ ngăn instance kết nối ra ngoài, đáp ứng yêu cầu cô lập hoàn toàn. Các thiết lập khác không ảnh hưởng trực tiếp đến traffic outbound từ instance.

🛠️ Giải thích chi tiết từng phương án (Đúng/Sai)

  • Public IP ✅ ĐÚNG
    Public IP cho phép instance có địa chỉ IP công khai, từ đó truy cập trực tiếp internet và các dịch vụ bên ngoài. Nếu disabled (không attach public IP), instance chỉ dùng private IP nội bộ VPC, ngăn outbound internet. Đây là thiết lập bắt buộc phải tắt để cô lập.

  • IP Forwarding ❌ SAI
    IP Forwarding cho phép instance chuyển tiếp (forward) traffic giữa các interface, thường dùng cho router/gateway. Thiết lập này không ảnh hưởng đến khả năng instance tự truy cập internet hoặc Google APIs; chỉ liên quan đến routing qua instance.

  • Private Google Access ✅ ĐÚNG
    Private Google Access (PGA) cho phép VM với private IP gọi Google APIs qua internal endpoint (như private.googleapis.com) mà không cần public IP/internet. Nếu disabled trên subnet, instance không thể access Google services dù ở private network. Phải tắt để ngăn hoàn toàn.

  • Static routes ❌ SAI
    Static routes là định tuyến tĩnh trong VPC routing table, dùng để hướng traffic đến đích cụ thể. Không phải thiết lập trên instance và không trực tiếp kiểm soát access internet/APIs từ instance; chỉ định hướng traffic chung.

  • IAM Network User Role ❌ SAI
    Đây là IAM role (roles/compute.networkUser) cho phép principal quản lý network resources (như attach IP). Nó kiểm soát quyền admin, không ảnh hưởng đến khả năng network outbound của chính instance. Instance access dựa trên VPC config, không phải IAM role này.

📚 Lời khuyên bảo mật nâng cao

🔒 Sử dụng VPC Service Controls hoặc Firewall Rules (egress deny-all) để bổ sung. Kiểm tra bằng Network Intelligence Center để verify không leak traffic. Luôn audit VPC/subnet settings qua Cloud Console hoặc gcloud CLI.