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

Tìm thấy 395 câu.

Câu 11
As a Blockchain-based payment system company, we are migrating to Google Cloud and want to ensure network security controls are maintained. What solution can we implement to ensure effective network security controls as part of the new shared responsibility model between our company and Google Cloud?
  1. A Configure Cloud Armor to enable centralized management of network security controls for G Suite.
  2. B Google Cloud has a built-in network security solution that is responsible for ensuring the security of SaaS products such as G Suite.
  3. C Make certain that the necessary controls are met by implementing firewall rules.
  4. D Configure a range of Virtual Private Cloud (VPC) networks in compliance with the applicable regulations to manage network security.
Xem giải thích

Đáp án

B — Google Cloud có giải pháp bảo mật mạng tích hợp sẵn, chịu trách nhiệm đảm bảo an toàn cho các sản phẩm SaaS như Google Workspace.

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

⚠ Phương án đúng được diễn đạt vụng và dễ gây hiểu nhầm.

⚠ Ý mà đề muốn nói: trong mô hình trách nhiệm chia sẻ, mức trách nhiệm của khách hàng thay đổi theo loại dịch vụ:

Loại dịch vụ Google lo Khách lo
⚠ SaaS (Workspace) ⚠ gần như TẤT CẢ, gồm bảo mật mạng ⚠ dữ liệu, danh tính, cấu hình chia sẻ
PaaS (App Engine, Cloud Run) ⚠ hạ tầng, runtime ⚠ mã, dữ liệu, IAM
IaaS (Compute Engine) ⚠ hạ tầng vật lý, hypervisor ⚠ HĐH, firewall, vá lỗi, mạng

⚠ KHÔNG sửa khoá. Ba phương án còn lại đều sai rõ hơn.

Vì sao vẫn chọn được B

⚠ Đây là câu hỏi về hiểu mô hình trách nhiệm chia sẻ, và B là phương án duy nhất nói đúng rằng với SaaS, phần bảo mật mạng thuộc về nhà cung cấp.

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

  • C (đảm bảo các kiểm soát cần thiết bằng cách triển khai firewall rules) — ⚠ quá hẹp: ⚠ firewall chỉ là một kiểm soát, ⚠ không phải toàn bộ mô hình trách nhiệm.

  • D (cấu hình nhiều VPC theo quy định để quản lý bảo mật mạng) — ⚠ cũng chỉ là một biện pháp, không trả lời câu hỏi về mô hình trách nhiệm.

  • A (cấu hình Cloud Armor để quản lý tập trung kiểm soát mạng cho Workspace) — ⚠ sai kỹ thuật: ⚠ Cloud Armor bảo vệ ứng dụng sau Load Balancer, ⚠ không áp dụng cho Google Workspace.

Ghi nhớ

⚠ Mô hình trách nhiệm chia sẻ — bảng phải thuộc: | Tầng | Ai lo | |---|---| | ⚠ Hạ tầng vật lý, trung tâm dữ liệu | ⚠ LUÔN là Google | | ⚠ Hypervisor, mạng nền | ⚠ Google | | ⚠ Hệ điều hành khách | ⚠ KHÁCH với IaaS, Google với PaaS/SaaS | | ⚠ Cấu hình mạng (VPC, firewall) | ⚠ KHÁCH với IaaS/PaaS | | ⚠ DỮ LIỆU và DANH TÍNH | ⚠ LUÔN là KHÁCH | | ⚠ Cấu hình IAM | ⚠ LUÔN là KHÁCH |

Từ khoá nhận diện:

"mô hình trách nhiệm chia sẻ" → ⚠ trách nhiệm khác nhau theo IaaS/PaaS/SaaS "Cloud Armor cho Workspace" → ⚠ sai — Armor cho ứng dụng sau LB "chỉ firewall là đủ" → ⚠ quá hẹp

⚠ Hai điều LUÔN là trách nhiệm của khách Điều
⚠ DỮ LIỆU ⚠ phân loại, mã hoá, ai truy cập
⚠ DANH TÍNH và QUYỀN ⚠ IAM cấu hình sai là lỗi của bạn
Dù dùng IaaS, PaaS hay SaaS ⚠ hai thứ này không bao giờ chuyển sang nhà cung cấp
Thực tế ⚠ phần lớn sự cố rò rỉ đến từ cấu hình sai của khách
⚠ Google Cloud gọi là "shared FATE" Khác biệt
⚠ Không chỉ chia trách nhiệm
⚠ Google cung cấp blueprint, công cụ, bảo hiểm
⚠ Giúp khách làm đúng phần của mình
Ý tưởng ⚠ nhà cung cấp không phủi tay ở ranh giới trách nhiệm
⚠ Câu hỏi phải trả lời cho mỗi dịch vụ Câu hỏi
⚠ Ai vá lỗ hổng hệ điều hành
⚠ Ai cấu hình firewall
⚠ Ai quản khoá mã hoá
⚠ Ai chịu trách nhiệm nếu dữ liệu rò rỉ
Nguyên tắc ⚠ đọc tài liệu của ĐÚNG dịch vụ, đừng suy đoán

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dịch vụ đang dùng là IaaS, PaaS hay SaaS | ⚠ quyết định phần trách nhiệm của bạn | | Ai vá hệ điều hành | ⚠ với Compute Engine là BẠN | | Cấu hình IAM có được rà soát không | ⚠ luôn là trách nhiệm của bạn |

Và điều dễ hiểu nhầm nhất về mô hình trách nhiệm chia sẻ: càng dùng dịch vụ được quản lý nhiều thì phần bạn phải lo càng ít, nhưng dữ liệu và danh tính thì không bao giờ chuyển đi đâu cả.

Câu 12
As a member of the security team for a Smart Home Automation company, what steps should you take to reduce the scope of systems subject to PCI audit standards in your GCP project that includes credit card payment processing systems, web applications, and data processing systems?
  1. A It is recommended to utilize VPN to establish connections between your office and cloud environments.
  2. B Separate the GCP project to house the cardholder data environment.
  3. C Utilize solely PA-DSS compliant certified applications.
  4. D It is recommended to implement multi-factor authentication to secure the admin access to the web application.
Xem giải thích

Đáp án

B — Tách riêng một dự án GCP để chứa môi trường dữ liệu chủ thẻ

Vì sao đúng

Nguyên tắc cốt lõi khi đối mặt với PCI DSS là thu hẹp phạm vi kiểm toán. Mọi hệ thống nằm trong hoặc kết nối tới môi trường dữ liệu chủ thẻ đều bị kiểm toán. Đặt phần đó vào một dự án riêng tạo ra ranh giới rõ ràng về IAM, mạng và ghi nhật ký, nên chỉ dự án đó bị soi thay vì cả hạ tầng công ty.

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

  • A. Dùng VPN nối văn phòng — bảo vệ đường truyền nhưng không thu hẹp phạm vi; mạng văn phòng nối vào thì có khi còn bị kéo vào phạm vi.
  • C. Chỉ dùng ứng dụng đạt chứng nhận PA-DSS — là một yêu cầu về phần mềm, không phải cách giới hạn phạm vi hệ thống.
  • D. Bật xác thực đa yếu tố — biện pháp bắt buộc của chuẩn, nhưng không làm phạm vi nhỏ đi.
Câu 13
In an online marketplace for freelancers company that has migrated to Google Cloud Platform, what steps should be taken to maintain a historical record of the instances running across multiple projects managed by different departments?
  1. A Security Command Center can be utilized to access a comprehensive view of all assets present throughout the organization.
  2. B Create a dashboard using Cloud Logging that covers all the projects.
  3. C Automate inventory snapshots using Forseti Security.
  4. D Implement Resource Manager at the organizational level.
Xem giải thích

Đáp án

C — Tự động hoá việc chụp ảnh kiểm kê tài nguyên bằng Forseti Security.

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

⚠ Forseti Security là công cụ MÃ NGUỒN MỞ, nay đã được thay thế bằng dịch vụ tích hợp sẵn.

Thời điểm Công cụ
⚠ Trước đây ⚠ Forseti Security — mã nguồn mở, tự triển khai
⚠ Hiện nay ⚠ Cloud Asset Inventory + Security Command Center

⚠ KHÔNG sửa khoá — vào thời điểm đề được soạn, Forseti là câu trả lời chuẩn cho việc chụp ảnh kiểm kê định kỳ.

⚠ Trong thực tế hôm nay: dùng Cloud Asset Inventory để xuất ảnh chụp tài nguyên theo lịch sang BigQuery — không cần tự triển khai gì.

Vì sao đúng (theo bối cảnh đề)

⚠ Đề nhấn "bản ghi LỊCH SỬ":

⚠ Không chỉ cần biết HIỆN TẠI có gì
⚠ Cần biết THỜI ĐIỂM NÀO có gì
        ↓
⚠ Cần CHỤP ẢNH ĐỊNH KỲ và LƯU LẠI
        ↓
⚠ Forseti làm đúng việc đó

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

  • A (dùng Security Command Center để xem toàn cảnh tài sản) — ⚠ bẫy gần nhất và ngày nay là câu trả lời tốt hơn: nhưng ⚠ SCC thiên về trạng thái HIỆN TẠI và phát hiện bảo mật, ⚠ đề nhấn bản ghi LỊCH SỬ.

  • D (triển khai Resource Manager ở mức tổ chức) — ⚠ nhầm công cụ: Resource Manager quản cây phân cấp project/folder, ⚠ không lưu lịch sử tài nguyên.

  • B (tạo dashboard Cloud Logging cho mọi project) — ⚠ log ghi SỰ KIỆN, không phải TRẠNG THÁI: ⚠ dựng lại danh sách instance từ log là rất khó.

Ghi nhớ

⚠ Công cụ kiểm kê tài nguyên — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Cloud Asset Inventory | ⚠ kiểm kê + LỊCH SỬ 35 ngày, xuất BigQuery — hiện đại | | ⚠ Security Command Center | ⚠ tài sản + phát hiện bảo mật | | ⚠ Forseti Security | ⚠ mã nguồn mở, tiền thân — khoá của đề | | Resource Manager | ⚠ cây phân cấp project/folder | | Cloud Logging | ⚠ sự kiện, không phải trạng thái |

Từ khoá nhận diện:

"kiểm kê tài nguyên, bản ghi lịch sử" → ⚠ Cloud Asset Inventory (hoặc Forseti theo đề cũ) "phát hiện lỗ hổng, cấu hình sai" → ⚠ Security Command Center "cây project/folder" → ⚠ Resource Manager "ai đã làm gì" → ⚠ Audit Logs

⚠ Cloud Asset Inventory làm gì Việc
⚠ Kiểm kê tài nguyên toàn tổ chức
⚠ Giữ lịch sử 35 ngày
⚠ Xuất ảnh chụp sang BigQuery hoặc Cloud Storage
⚠ Theo dõi thay đổi thời gian thực ⚠ feed qua Pub/Sub
Tìm kiếm tài nguyên theo thuộc tính
⚠ Muốn giữ lâu hơn 35 ngày ⚠ xuất định kỳ sang BigQuery
⚠ Vì sao cần bản ghi lịch sử tài nguyên Lý do
⚠ Điều tra sự cố bảo mật ⚠ hôm đó có instance nào
⚠ Kiểm toán tuân thủ
⚠ Phân tích chi phí theo thời gian
⚠ Phát hiện tài nguyên "mọc dại" ⚠ ai tạo, khi nào
Không có lịch sử ⚠ không trả lời được câu hỏi về quá khứ
⚠ Vì sao log không thay được kiểm kê Lý do
⚠ Log ghi SỰ KIỆN: tạo, sửa, xoá
⚠ Muốn biết trạng thái phải phát lại toàn bộ sự kiện
⚠ Log có thời hạn lưu giới hạn
Kiểm kê cho TRẠNG THÁI trực tiếp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có xuất kiểm kê sang BigQuery định kỳ không | ⚠ để giữ lâu hơn 35 ngày | | Trả lời được "tháng trước có bao nhiêu VM" không | | | Có tài nguyên nào không thuộc project nào biết không | |

Và câu hỏi mà mọi tổ chức nên trả lời được nhưng nhiều nơi không: "ba tháng trước, hệ thống của chúng ta gồm những gì?". Không có kiểm kê lịch sử thì mọi cuộc điều tra sự cố đều bắt đầu bằng việc đoán.

Câu 14
As an augmented reality platform company, what options are available on Google Cloud Platform for securely storing sensitive data, instead of keeping plain text secrets in the source-code management system for a customer?
  1. A The suggested approach is to provision local SSDs for the Compute Engine VM where the SCM will be deployed and activate preemptible VMs.
  2. B Utilize the Cloud Data Loss Prevention API for scanning the secrets, and subsequently, save them in Cloud SQL.
  3. C To ensure security, it is recommended to use a Customer-Managed Encryption Key (CMEK) to encrypt the secrets, and store them in Cloud Storage.
  4. D One option is to utilize Cloud Source Repositories while also saving confidential information in Cloud SQL.
Xem giải thích

Đáp án

C — Mã hoá secret bằng Customer-Managed Encryption Key (CMEK) rồi lưu trong Cloud Storage.

Vì sao đúng

Đề nêu vấn đề rõ: không được để secret dạng văn bản thuần trong hệ thống quản lý mã nguồn.

⚠ Vì sao phương án C hợp lý:

⚠ Secret KHÔNG nằm trong mã nguồn
        ↓
⚠ Mã hoá bằng khoá KHÁCH TỰ QUẢN
   → ⚠ Google không nắm khoá
        ↓
⚠ Lưu ở Cloud Storage
   → ⚠ có IAM, có audit log
        ↓
⚠ Xoay vòng khoá được trong KMS

⚠ Lưu ý thực tế: Secret Manager là dịch vụ chuyên cho việc này và là lựa chọn tốt hơn ngày nay — nhưng trong bốn phương án đã cho, C là phương án đúng duy nhất.

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

  • D (dùng Cloud Source Repositories và lưu thông tin nhạy cảm trong Cloud SQL) — ⚠ không giải quyết vấn đề mã hoá: ⚠ lưu trong CSDL mà không mã hoá tầng ứng dụng thì ai đọc được CSDL là đọc được secret.

  • B (dùng DLP API quét secret rồi lưu vào Cloud SQL) — ⚠ nhầm mục đích DLP: ⚠ DLP để phát hiện và che dữ liệu nhạy cảm, không phải để lưu trữ secret an toàn.

  • A (cấp local SSD cho VM chạy SCM và bật preemptible) — ⚠ hoàn toàn lạc đề: ⚠ không liên quan tới bảo vệ secret, và ⚠ preemptible cho hệ thống quản lý mã nguồn là ý tồi.

Ghi nhớ

⚠ Nơi lưu secret — bảng phải thuộc: | Nơi | Đánh giá | |---|---| | ⚠ Secret Manager | ⚠ tốt nhất — chuyên dụng, có xoay vòng, có phiên bản | | ⚠ Cloud Storage + CMEK | ⚠ chấp nhận được — đề này | | Biến môi trường trong CI | ⚠ được nhưng khó xoay vòng | | ⚠ Mã nguồn | ⚠ LUÔN SAI | | ⚠ CSDL không mã hoá tầng ứng dụng | ⚠ không đủ |

Từ khoá nhận diện:

"không để secret trong mã nguồn" → ⚠ Secret Manager hoặc KMS + lưu trữ có kiểm soát "DLP để lưu secret" → ⚠ nhầm mục đích "lưu trong CSDL" → ⚠ chưa đủ nếu không mã hoá riêng

⚠ Ba loại khoá mã hoá trên Google Cloud Loại
⚠ Google-managed (mặc định) ⚠ Google tạo và quản, tự động, miễn phí
⚠ CMEK ⚠ khách tạo và quản TRONG Cloud KMS
⚠ CSEK ⚠ khách CUNG CẤP khoá, Google không lưu
Mức kiểm soát tăng dần ⚠ Google-managed → CMEK → CSEK
Công sức cũng tăng dần
⚠ Vì sao secret trong Git là thảm hoạ Lý do
⚠ Lịch sử Git giữ MÃI ⚠ xoá file không đủ
⚠ Mọi bản clone đều có
⚠ Repo có thể bị công khai nhầm
⚠ Nếu lỡ commit ⚠ phải XOAY VÒNG secret, coi như đã lộ
Phòng ngừa ⚠ quét secret tự động trong CI, pre-commit hook
⚠ Secret Manager cho gì hơn Cloud Storage Ưu điểm
⚠ Quản lý phiên bản secret
⚠ Xoay vòng có hỗ trợ
⚠ IAM ở mức từng secret
⚠ Audit log riêng cho việc truy cập secret
Tích hợp sẵn với Cloud Run, GKE, Cloud Build

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

Và điều bắt buộc phải làm khi phát hiện secret lọt vào mã nguồn: xoay vòng nó ngay, đừng chỉ xoá dòng đó đi. Lịch sử Git đã lan ra mọi máy đã clone — secret đó phải coi như công khai.

Câu 15
An online legal service company is considering moving its data storage to Google Cloud Platform. They want to ensure maximum control over the encryption process of their data stored at rest. What technique should the company use?
  1. A Employ a Cloud HSM for enhanced security.
  2. B Utilize Cloud Storage as a federated source of data.
  3. C CMEK (Customer Managed Encryption Keys).
  4. D CSEK refers to encryption keys that are provided by the customer.
Xem giải thích

Đáp án

C — CMEK (Customer-Managed Encryption Keys).

Vì sao đúng

Đề cần mức kiểm soát TỐI ĐA đối với quá trình mã hoá dữ liệu khi lưu trữ.

⚠ CMEK cho khách hàng những gì:

⚠ TỰ TẠO khoá trong Cloud KMS
⚠ TỰ đặt lịch xoay vòng
⚠ TỰ quyết ai được dùng khoá
⚠ TỰ VÔ HIỆU HOÁ hoặc HUỶ khoá
        ↓
⚠ Huỷ khoá = dữ liệu KHÔNG giải mã
  được nữa
   → ⚠ đòn bẩy kiểm soát mạnh nhất

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

  • D (CSEK — khoá do khách cung cấp) — ⚠ bẫy tinh vi nhất: CSEK cho kiểm soát còn cao hơn về mặt lý thuyết (Google không lưu khoá). ⚠ Nhưng CSEK hỗ trợ RẤT HẠN CHẾ (chủ yếu Cloud Storage và đĩa Compute Engine), ⚠ không có xoay vòng tự động, ⚠ và mất khoá là mất dữ liệu vĩnh viễn. ⚠ Với yêu cầu chung "kiểm soát quá trình mã hoá", CMEK là câu trả lời chuẩn.

  • A (dùng Cloud HSM) — ⚠ là một mức của CMEK, không phải phương án song song: ⚠ Cloud HSM là nơi lưu khoá CMEK trong phần cứng chuyên dụng.

  • B (dùng Cloud Storage làm nguồn dữ liệu liên kết) — ⚠ hoàn toàn lạc đề, không liên quan tới mã hoá.

Ghi nhớ

⚠ Ba mức khoá mã hoá — bảng phải thuộc: | Mức | Ai tạo khoá | Ai lưu khoá | Kiểm soát | |---|---|---|---| | Google-managed | ⚠ Google | ⚠ Google | ⚠ thấp, tự động | | ⚠ CMEK | ⚠ KHÁCH, trong Cloud KMS | ⚠ Google KMS | ⚠ CAO — đề này | | ⚠ CSEK | ⚠ KHÁCH, ngoài Google | ⚠ KHÔNG ai lưu | ⚠ cao nhất, ít dịch vụ hỗ trợ |

Từ khoá nhận diện:

"kiểm soát quá trình mã hoá, tự quản khoá" → ⚠ CMEK "Google không được giữ khoá" → ⚠ CSEK — hỗ trợ hạn chế "khoá trong phần cứng FIPS 140-2 Level 3" → ⚠ Cloud HSM — một mức của CMEK "External Key Manager" → ⚠ khoá nằm ngoài Google Cloud hoàn toàn

⚠ Bốn mức bảo vệ khoá trong Cloud KMS Mức
Software ⚠ khoá trong phần mềm
⚠ Cloud HSM ⚠ phần cứng chuyên dụng, FIPS 140-2 Level 3
⚠ Cloud EKM ⚠ khoá ở nhà cung cấp BÊN NGOÀI
⚠ Chọn theo ⚠ yêu cầu tuân thủ của ngành
⚠ CMEK cho quyền lực gì Quyền lực
⚠ Vô hiệu hoá khoá → dữ liệu không đọc được ⚠ kể cả Google
⚠ Huỷ khoá → mất dữ liệu vĩnh viễn ⚠ cẩn thận
⚠ Xoay vòng theo lịch
⚠ Audit log mọi lần dùng khoá
⚠ Rủi ro đi kèm ⚠ xoá nhầm khoá là mất dữ liệu — không khôi phục được
⚠ Lưu ý vận hành với CMEK Lưu ý
⚠ Khoá và dữ liệu nên CÙNG vùng
⚠ Cấp quyền dùng khoá cho service agent của dịch vụ ⚠ quên là dịch vụ không đọc được dữ liệu
⚠ Đặt thời gian chờ trước khi huỷ khoá ⚠ mặc định 30 ngày
Theo dõi khoá sắp hết hạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá có cùng vùng với dữ liệu không | | | Service agent đã được cấp quyền dùng khoá chưa | ⚠ lỗi phổ biến nhất | | Ai có quyền huỷ khoá | ⚠ nên rất ít người |

Và sức mạnh thật sự của CMEK: bạn có thể làm cho dữ liệu của mình trở nên không đọc được đối với bất kỳ ai, kể cả nhà cung cấp. Đó cũng là rủi ro của nó — một thao tác huỷ khoá nhầm là mất dữ liệu vĩnh viễn.

Câu 16
How can a cybersecurity software provider company ensure that personally identifiable information shared by customers through online chat is not being stored as part of regular chat logs, while still maintaining data utility using Google Cloud Services?
  1. A To ensure security, encrypt customer PII prior to storage for analysis using Cloud Key Management Service.
  2. B Utilize Object Lifecycle Management to ensure that any chat records containing personally identifiable information (PII) are deleted and not retained for analysis.
  3. C Before storing texts for analysis, PII can be redacted using the DLP API solution's generalization and bucketing actions.
  4. D Before storing images for analysis, utilize DLP API's image inspection and redaction capabilities to redact any personally identifiable information.
Xem giải thích

Đáp án

D — Trước khi lưu để phân tích, dùng khả năng kiểm tra và che hình ảnh của DLP API để che thông tin định danh cá nhân.

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

⚠ Đề và khoá KHÔNG khớp nhau.

Vế Nội dung
⚠ ĐỀ hỏi ⚠ PII trong chat TRỰC TUYẾN dạng VĂN BẢN
⚠ KHOÁ D nói ⚠ kiểm tra và che HÌNH ẢNH
⚠ Phương án C nói ⚠ che VĂN BẢN bằng generalization và bucketing — khớp đề hơn

⚠ KHÔNG sửa khoá theo quy ước. Nhưng ⚠ theo logic, C mới là câu trả lời đúng cho đề đã cho.

⚠ Cách nhớ an toàn: nhớ cả hai đều là DLP API, chỉ khác kiểu dữ liệu đầu vào:

  • ⚠ Văn bản → content.deidentify với generalization / bucketing / masking
  • ⚠ Hình ảnh → image.redact

Vì sao ý tưởng chung là đúng

⚠ Điều cả C và D cùng nói đúng:

⚠ Che PII TRƯỚC KHI LƯU
        ↓
⚠ Dữ liệu đã lưu KHÔNG chứa PII
        ↓
⚠ Vẫn phân tích được vì cấu trúc
   dữ liệu còn nguyên
        ↓
⚠ Đó là "giữ được tính hữu dụng"
   mà đề yêu cầu

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

  • A (mã hoá PII trước khi lưu bằng Cloud KMS) — ⚠ mã hoá KHÔNG phải che: ⚠ PII vẫn tồn tại, chỉ ở dạng mã hoá; ⚠ ai có khoá là đọc được, ⚠ và dữ liệu mã hoá thì không phân tích được.

  • B (dùng Object Lifecycle Management để xoá bản ghi chat chứa PII) — ⚠ mất luôn dữ liệu: đề yêu cầu vẫn giữ được tính hữu dụng, ⚠ xoá là mất hết.

Ghi nhớ

⚠ Bốn cách xử lý dữ liệu nhạy cảm — bảng phải thuộc: | Cách | Kết quả | Còn phân tích được | |---|---|---| | ⚠ Che (redact) | ⚠ xoá hẳn giá trị nhạy cảm | ⚠ một phần | | ⚠ Tổng quát hoá / gom nhóm | ⚠ tuổi 34 → nhóm 30-40 | ⚠ CÓ — tốt nhất | | ⚠ Token hoá | ⚠ thay bằng mã, đảo ngược được | ⚠ CÓ, ghép nối được | | Mã hoá | ⚠ dữ liệu vẫn còn nguyên | ⚠ KHÔNG | | Xoá | ⚠ mất hẳn | ⚠ KHÔNG |

Từ khoá nhận diện:

"che PII nhưng vẫn phân tích được" → ⚠ DLP API de-identify "PII trong ẢNH" → ⚠ DLP image redaction "mã hoá là đủ" → ⚠ sai — dữ liệu vẫn còn, chỉ khoá lại

⚠ Sensitive Data Protection (tên mới của Cloud DLP) làm gì Việc
⚠ Phát hiện hơn 150 loại infoType ⚠ email, thẻ tín dụng, số căn cước, số điện thoại
⚠ Che, thay thế, token hoá, tổng quát hoá
⚠ Quét văn bản, ảnh và bảng dữ liệu
⚠ Profile dữ liệu trong BigQuery và Cloud Storage
⚠ Tên cũ ⚠ Cloud DLP — nhiều đề vẫn ghi tên cũ
⚠ Vì sao che TRƯỚC khi lưu quan trọng Lý do
⚠ Dữ liệu đã lưu là dữ liệu phải bảo vệ
⚠ Lưu rồi mới che là đã có cửa sổ rò rỉ
⚠ Bản sao lưu cũng chứa dữ liệu gốc
Log của hệ thống lưu trữ cũng có thể chứa
⚠ Nguyên tắc ⚠ dữ liệu bạn không lưu là dữ liệu không thể rò rỉ
⚠ Ba kỹ thuật giữ tính hữu dụng Kỹ thuật
⚠ Bucketing ⚠ tuổi thành khoảng — thống kê vẫn đúng
⚠ Date shifting ⚠ dịch ngày theo hằng số mỗi người
⚠ Format-preserving tokenization ⚠ thẻ tín dụng thành mã cùng định dạng
Mục tiêu chung ⚠ phân tích được mà không lộ danh tính

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có PII nào lọt vào log không | ⚠ quét bằng DLP | | Che ở tầng nào — trước hay sau khi lưu | ⚠ phải là TRƯỚC | | Dữ liệu sau khi che còn dùng được không | ⚠ thử chạy phân tích thật |

Và điều đáng nhớ nhất: mã hoá và che giấu giải quyết hai bài toán khác nhau. Mã hoá bảo vệ dữ liệu khỏi người ngoài; che giấu loại bỏ dữ liệu khỏi chính hệ thống của bạn.

Câu 17
As an AI-powered chatbot service company, what is the recommended process for a customer to securely transfer Cloud Logging (previously known as Stackdriver) logs from Google Cloud Platform to their on-premises SIEM system?
  1. A Organizational Log Sinks should be set up to export logs to a Cloud Pub/Sub Topic. These logs will then be sent to the SIEM through Dataflow.
  2. B Utilize an established protocol like syslog to transmit all the logs to the SIEM system.
  3. C Develop a linkage that enables the SIEM to fetch all logs in real-time from the GCP RESTful JSON APIs.
  4. D Make sure all logs from each project are exported to a shared BigQuery DataSet, which can be accessed by the SIEM system for querying purposes.
Xem giải thích

Đáp án

A — Thiết lập Log Sink cấp tổ chức xuất log sang Pub/Sub Topic, rồi từ đó đưa vào SIEM qua Dataflow.

Vì sao đúng

⚠ Chuỗi đường ống chuẩn để đưa log Google Cloud ra SIEM tại chỗ:

⚠ Cloud Logging
        ↓ ⚠ Organizational Log Sink
   (⚠ gom log MỌI project một chỗ)
        ↓
⚠ Pub/Sub Topic
   (⚠ đệm, thời gian thực, giữ khi SIEM
     tạm ngừng)
        ↓ ⚠ Dataflow
   (⚠ chuyển đổi định dạng, làm giàu)
        ↓
⚠ SIEM tại chỗ

⚠ Vì sao từng mắt xích cần thiết: | Mắt xích | Vai trò | |---|---| | ⚠ Sink cấp TỔ CHỨC | ⚠ một cấu hình cho mọi project, kể cả project mới | | ⚠ Pub/Sub | ⚠ thời gian thực + ĐỆM khi SIEM chậm hoặc chết | | ⚠ Dataflow | ⚠ đổi định dạng sang thứ SIEM hiểu |

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

  • D (xuất mọi log sang BigQuery dataset chung để SIEM truy vấn) — ⚠ kéo thay vì đẩy, có độ trễ: ⚠ SIEM phải hỏi định kỳ, ⚠ không phát hiện thời gian thực; ⚠ chi phí truy vấn lớn.

  • C (xây liên kết để SIEM gọi RESTful JSON API lấy log thời gian thực) — ⚠ tự dựng và mong manh: ⚠ phải tự quản phân trang, giới hạn tần suất, thử lại; ⚠ mất log nếu SIEM ngừng.

  • B (dùng syslog để truyền toàn bộ log sang SIEM) — ⚠ Cloud Logging không phát syslog ra ngoài: ⚠ phải tự dựng cầu nối, và ⚠ syslog không có cơ chế đệm hay xác nhận nhận được.

Ghi nhớ

⚠ Đích của Log Sink — bảng phải thuộc: | Đích | Dùng cho | |---|---| | ⚠ Pub/Sub | ⚠ đẩy sang hệ thống BÊN NGOÀI, thời gian thực — SIEM | | ⚠ BigQuery | ⚠ phân tích SQL, báo cáo tuân thủ | | ⚠ Cloud Storage | ⚠ lưu trữ dài hạn, giá rẻ | | Logging bucket khác | ⚠ tách theo thời hạn lưu |

Từ khoá nhận diện:

"đưa log ra SIEM ngoài, thời gian thực" → ⚠ Sink → Pub/Sub → (Dataflow) → SIEM "phân tích log bằng SQL" → ⚠ Sink → BigQuery "giữ log 7 năm giá rẻ" → ⚠ Sink → Cloud Storage + Archive class "log của MỌI project" → ⚠ sink cấp TỔ CHỨC (aggregated sink)

⚠ Aggregated sink cấp tổ chức cho gì Ưu điểm
⚠ Một cấu hình cho toàn tổ chức
⚠ Project MỚI tự động được gom ⚠ không cần nhớ thêm sink
⚠ Đặt được ở mức folder ⚠ tách theo đơn vị kinh doanh
⚠ Lọc được bằng biểu thức ⚠ chỉ xuất audit log chẳng hạn
⚠ Quyền cần ⚠ cấp cho service account của sink quyền ghi vào đích
⚠ Vì sao Pub/Sub chứ không nối thẳng Lý do
⚠ Tách rời nguồn và đích ⚠ SIEM chết thì log vẫn được giữ
⚠ Giữ tin nhắn tới 7 ngày
⚠ Nhiều consumer cùng đọc được ⚠ SIEM + kho lưu trữ + cảnh báo
⚠ Co giãn theo lưu lượng
⚠ Bốn loại audit log phải biết Loại
⚠ Admin Activity ⚠ LUÔN bật, KHÔNG tắt được, miễn phí
⚠ Data Access ⚠ phải BẬT, tốn phí, khối lượng rất lớn
⚠ System Event ⚠ Google tự thực hiện, luôn bật
⚠ Policy Denied ⚠ truy cập bị từ chối vì chính sách
⚠ Đưa ra SIEM ⚠ Admin Activity là tối thiểu bắt buộc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sink có ở cấp tổ chức không | ⚠ cấp project sẽ bỏ sót project mới | | Data Access log đã bật chưa | ⚠ mặc định TẮT | | Pub/Sub có bị tồn đọng không | ⚠ theo dõi độ tuổi tin nhắn chưa xử lý |

Và điều dễ bị bỏ quên nhất khi dựng đường ống log: Data Access log mặc định không bật. Đến lúc điều tra sự cố mới phát hiện là không có gì để xem — và log thì không dựng lại được cho quá khứ.

Câu 18
As a Cloud storage provider company, how can you connect to workloads in a dedicated server room that can only be accessed from within a private network, from Compute Engine instances within a Google Cloud Platform project? Which two approaches should be taken to meet these requirements?
  1. A Set up the project using Shared VPC.
  2. B The project should be set up with VPC peering and all Compute Engine instances should be configured to have private access.
  3. C Set up Cloud Interconnect for the project.
  4. D Set up Cloud VPN for the project.
Xem giải thích

Đáp án

D — Thiết lập Cloud VPN cho project.

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

⚠ Đề hỏi "hai cách nào" nhưng chỉ MỘT phương án được đánh dấu đúng.

Vế Nội dung
⚠ Đề yêu cầu ⚠ "Which TWO approaches"
⚠ Khoá đánh dấu ⚠ chỉ D — Cloud VPN
⚠ Đáng lẽ phải có ⚠ C — Cloud Interconnect, cũng nối được tới trung tâm dữ liệu riêng

⚠ KHÔNG sửa khoá. ⚠ Nhớ rằng Cloud VPN và Cloud Interconnect là HAI cách chuẩn nối Google Cloud với hạ tầng tại chỗ.

Vì sao đúng

⚠ Bài toán: VM trên Google Cloud cần gọi tới máy chủ chỉ truy cập được từ mạng riêng tại chỗ.

⚠ Compute Engine trong VPC
        ↓ ⚠ cần đường tới mạng riêng
⚠ Cloud VPN
   (⚠ đường hầm IPsec mã hoá qua Internet)
        ↓
⚠ Phòng máy chủ riêng

⚠ Cloud VPN: ⚠ dựng nhanh, ⚠ chạy trên Internet công cộng, ⚠ mã hoá IPsec, ⚠ tối đa khoảng 3 Gbps mỗi đường hầm.

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

  • C (Cloud Interconnect) — ⚠ thực ra CŨNG ĐÚNG và đáng lẽ là đáp án thứ hai: ⚠ đường vật lý riêng, băng thông cao, độ trễ ổn định. ⚠ Đề chỉ đánh dấu một đáp án.

  • A (Shared VPC) — ⚠ sai phạm vi: ⚠ Shared VPC chia mạng GIỮA CÁC PROJECT trong Google Cloud, ⚠ không nối ra ngoài đám mây.

  • B (VPC peering + private access) — ⚠ cũng chỉ trong Google Cloud: ⚠ VPC Peering nối hai VPC, ⚠ không nối tới mạng tại chỗ.

Ghi nhớ

⚠ Cách nối mạng — bảng phải thuộc: | Cần nối gì với gì | Dùng | |---|---| | ⚠ Google Cloud ↔ TẠI CHỖ, nhanh, rẻ | ⚠ Cloud VPN — IPsec qua Internet | | ⚠ Google Cloud ↔ TẠI CHỖ, băng thông cao, SLA | ⚠ Cloud Interconnect (Dedicated/Partner) | | ⚠ VPC ↔ VPC | ⚠ VPC Network Peering | | ⚠ Nhiều project dùng CHUNG một mạng | ⚠ Shared VPC | | ⚠ Tới API Google mà không ra Internet | ⚠ Private Google Access / Private Service Connect |

Từ khoá nhận diện:

"nối tới trung tâm dữ liệu tại chỗ" → ⚠ VPN hoặc Interconnect "nối hai VPC" → ⚠ Peering "nhiều project chung mạng" → ⚠ Shared VPC "băng thông 10 Gbps, SLA" → ⚠ Dedicated Interconnect

⚠ Cloud VPN so với Interconnect So sánh
⚠ VPN: dựng trong vài giờ ⚠ Interconnect: vài tuần, cần cáp vật lý
⚠ VPN: qua Internet công cộng, mã hoá ⚠ Interconnect: đường riêng, KHÔNG mã hoá mặc định
⚠ VPN: ~3 Gbps mỗi tunnel ⚠ Interconnect: 10 hoặc 100 Gbps
⚠ VPN: SLA 99,99% với HA VPN ⚠ Interconnect: 99,9% hoặc 99,99% tuỳ cấu hình
VPN: trả theo tunnel-giờ + lưu lượng ⚠ Interconnect: phí cổng + lưu lượng rẻ hơn
⚠ HA VPN — bắt buộc biết Đặc điểm
⚠ HAI giao diện, HAI địa chỉ IP ngoài
⚠ SLA 99,99% khi cấu hình đủ hai tunnel
⚠ Dùng BGP với Cloud Router ⚠ định tuyến động
⚠ Classic VPN ⚠ đã ngừng nhận cấu hình mới cho phần lớn ca dùng
⚠ VPC Peering — giới hạn phải nhớ Giới hạn
⚠ KHÔNG bắc cầu ⚠ A-B và B-C không cho A-C
⚠ Dải IP không được chồng lấn
⚠ Không đi qua để tới mạng tại chỗ
Thay thế khi cần bắc cầu ⚠ Network Connectivity Center hoặc Shared VPC

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 nối được | | Có dùng HA VPN với hai tunnel không | ⚠ một tunnel không có SLA | | Firewall rule đã cho phép chiều về chưa | |

Và sai lầm hay gặp nhất khi nối mạng lai: quên rằng dải IP hai bên không được chồng lấn. Phát hiện điều đó sau khi đã đặt địa chỉ cho cả trăm máy chủ là một cuộc đánh số lại rất tốn kém.

Câu 19
As a Social impact investment platform company, which boot disk encryption solution should be used on a Compute Engine-based cluster with Managed Instance Groups (MIGs) to ensure quick completion of bursty sensitive workloads and control key lifecycle?
  1. A Encryption keys provided by the customer are known as customer-managed encryption keys (CMEK).
  2. B The utilization of Cloud Key Management Service (KMS) for managing encryption keys by the customer is known as Customer-managed encryption keys (CMEK).
  3. C Encrypting files prior to transferring them to Google Cloud Platform (GCP) for analysis.
  4. D By default, encryption is enabled.
Xem giải thích

Đáp án

B — Dùng Cloud Key Management Service (KMS) để khách hàng tự quản khoá mã hoá, tức Customer-Managed Encryption Keys (CMEK).

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

⚠ Hai phương án A và B cùng viết chữ "CMEK" nhưng định nghĩa khác nhau — A định nghĩa SAI.

Phương án Viết gì Đúng hay sai
⚠ A ⚠ "khoá do khách CUNG CẤP là CMEK" ⚠ SAI — đó là CSEK
⚠ B ⚠ "khách tự quản khoá TRONG Cloud KMS là CMEK" ⚠ ĐÚNG

⚠ Bẫy nằm ở một chữ: ⚠ "provided" (cung cấp) = CSEK, ⚠ "managed in KMS" (quản trong KMS) = CMEK.

Vì sao đúng

⚠ Đề nêu hai yêu cầu:

⚠ 1. Khối lượng công việc BÙNG PHÁT
   → ⚠ MIG tạo VM liên tục, rất nhanh
   → ⚠ khoá phải có SẴN, tự động
        ↓
⚠ 2. Kiểm soát VÒNG ĐỜI khoá
   → ⚠ tạo, xoay vòng, vô hiệu, huỷ
        ↓
⚠ CMEK trong Cloud KMS đáp ứng cả hai

⚠ Vì sao CMEK hợp với MIG: ⚠ khoá nằm trong KMS, ⚠ mọi VM mới tự lấy khoá qua IAM — ⚠ không cần truyền khoá thủ công cho từng máy.

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

  • A (khoá do khách cung cấp, gọi nhầm là CMEK) — ⚠ định nghĩa sai và không hợp bối cảnh: ⚠ CSEK yêu cầu truyền khoá theo TỪNG lệnh gọi API; ⚠ với MIG tạo VM tự động thì rất khó, ⚠ và không có xoay vòng tự động.

  • D (mặc định đã bật mã hoá) — ⚠ đúng nhưng không đáp ứng yêu cầu: ⚠ mã hoá mặc định do Google quản khoá, ⚠ khách không kiểm soát vòng đời khoá.

  • C (mã hoá file trước khi chuyển lên Google Cloud) — ⚠ lạc đề: đề hỏi về mã hoá đĩa khởi động, ⚠ không phải mã hoá tệp ở tầng ứng dụng.

Ghi nhớ

⚠ CMEK so với CSEK — bảng phải thuộc: | Tiêu chí | ⚠ CMEK | ⚠ CSEK | |---|---|---| | ⚠ Khoá nằm ở | ⚠ Cloud KMS | ⚠ bên khách, Google KHÔNG lưu | | ⚠ Truyền khoá mỗi lần gọi | ⚠ KHÔNG — qua IAM | ⚠ CÓ — trong header | | ⚠ Xoay vòng tự động | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Dịch vụ hỗ trợ | ⚠ rất nhiều | ⚠ rất ít (GCS, PD) | | ⚠ Hợp với tự động hoá (MIG) | ⚠ CÓ — đề này | ⚠ rất khó |

Từ khoá nhận diện:

"khách tự quản khoá, kiểm soát vòng đời" → ⚠ CMEK "khách CUNG CẤP khoá, Google không lưu" → ⚠ CSEK "không cấu hình gì cũng mã hoá" → ⚠ Google-managed, mặc định "MIG, tự động mở rộng" → ⚠ phải là CMEK, CSEK không hợp

⚠ Vì sao CSEK khó dùng với tự động hoá Lý do
⚠ Phải gửi khoá trong MỖI lệnh gọi API
⚠ Hệ thống tự tạo VM phải giữ khoá ở đâu đó ⚠ lại thành bài toán lưu secret
⚠ Không xoay vòng tự động
⚠ Mất khoá là mất dữ liệu vĩnh viễn ⚠ Google không có bản sao
⚠ Vòng đời khoá trong Cloud KMS Giai đoạn
⚠ Tạo key ring và key ⚠ key ring gắn với một vùng, không đổi được
⚠ Xoay vòng theo lịch ⚠ sinh phiên bản mới, phiên bản cũ vẫn giải mã được
⚠ Vô hiệu hoá phiên bản ⚠ đảo ngược được
⚠ Lên lịch huỷ ⚠ chờ 24 giờ tới 120 ngày rồi mới huỷ thật
⚠ Huỷ rồi ⚠ KHÔNG khôi phục được
⚠ Bẫy CMEK với Managed Instance Group Bẫy
⚠ Instance template phải khai khoá CMEK
⚠ Service agent của Compute Engine cần vai trò cryptoKeyEncrypterDecrypter ⚠ thiếu là VM không khởi động được
⚠ Khoá phải cùng vùng với đĩa
⚠ Vô hiệu khoá = mọi VM mới không tạo được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Service agent đã có quyền dùng khoá chưa | ⚠ lỗi số một | | Khoá và đĩa có cùng vùng không | | | Lịch xoay vòng đã đặt chưa | ⚠ thường 90 ngày |

Và điều làm nhiều người mất buổi tối đầu tiên với CMEK: VM không khởi động và thông báo lỗi chẳng nhắc gì tới khoá. Nguyên nhân gần như luôn là service agent của dịch vụ chưa được cấp quyền dùng khoá đó.

Câu 20
For a corporate wellness platform, how can an application running on a Compute Engine instance securely access data from a Cloud Storage bucket while adhering to the principle of least privilege and not allowing global access to the bucket?
  1. A To enable the application to access a Cloud Storage bucket without requiring credentials, while only allowing read-only access from the Compute Engine instance's IP address, you can set up a Cloud Storage ACL.
  2. B To access the Cloud Storage bucket, utilize a service account with only read permissions, and save the service account credentials in the Compute Engine instance's application configuration.
  3. C To obtain the credentials from the instance metadata, utilize a service account that has only read permissions to the Cloud Storage bucket.
  4. D To secure the data in the Cloud Storage bucket, apply encryption via Cloud KMS, and permit the application to perform decryption operations utilizing the KMS key.
Xem giải thích

Đáp án

C — Dùng service account chỉ có quyền đọc bucket, và lấy thông tin xác thực từ metadata của instance.

Vì sao đúng

⚠ Ba yêu cầu của đề và cách C đáp ứng: | Yêu cầu | Cách C giải | |---|---| | ⚠ Quyền tối thiểu | ⚠ service account CHỈ có quyền đọc | | ⚠ Không mở bucket công khai | ⚠ IAM gắn cho đúng service account | | ⚠ An toàn | ⚠ KHÔNG có file khoá nào trên máy |

⚠ Cơ chế metadata server:

⚠ VM có service account gắn sẵn
        ↓
⚠ Ứng dụng gọi metadata server
   ⚠ 169.254.169.254 (chỉ nội bộ VM)
        ↓
⚠ Nhận access token NGẮN HẠN
   (⚠ tự động làm mới, ~1 giờ)
        ↓
⚠ KHÔNG có khoá dài hạn trên đĩa

⚠ Đây là cách Google khuyến nghị: không bao giờ đặt file khoá service account lên máy.

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

  • B (service account chỉ đọc, LƯU credential vào cấu hình ứng dụng) — ⚠ bẫy gần nhất, chỉ sai một chỗ: ⚠ quyền thì đúng, ⚠ nhưng file khoá dài hạn nằm trên đĩa: ⚠ ai vào được VM là lấy được, ⚠ khoá không tự hết hạn, ⚠ phải tự xoay vòng.

  • A (Cloud Storage ACL cho phép đọc từ địa chỉ IP của VM) — ⚠ ACL không lọc theo IP được: ⚠ ACL cấp quyền theo danh tính, không theo địa chỉ; ⚠ và ⚠ Google khuyến nghị dùng IAM thay cho ACL.

  • D (mã hoá dữ liệu bằng Cloud KMS, cho ứng dụng giải mã) — ⚠ giải quyết bài toán khác: ⚠ mã hoá bảo vệ nội dung, ⚠ nhưng không kiểm soát ai truy cập bucket.

Ghi nhớ

⚠ Cách xác thực cho workload — bảng phải thuộc: | Nơi chạy | Cách đúng | |---|---| | ⚠ Compute Engine / GKE / Cloud Run | ⚠ service account gắn sẵn + metadata server | | ⚠ GKE cụ thể | ⚠ Workload Identity | | ⚠ Ngoài Google Cloud (AWS, tại chỗ) | ⚠ Workload Identity Federation | | ⚠ File khoá JSON | ⚠ phương án CUỐI CÙNG, tránh nếu được |

Từ khoá nhận diện:

"ứng dụng trên VM truy cập dịch vụ Google" → ⚠ service account gắn vào VM "lưu khoá trong cấu hình" → ⚠ SAI — luôn là bẫy "ứng dụng ngoài Google Cloud" → ⚠ Workload Identity Federation "lọc theo IP" → ⚠ ACL và IAM đều không làm được

⚠ Vì sao file khoá service account nguy hiểm Lý do
⚠ KHÔNG có hạn dùng ⚠ lộ là lộ vĩnh viễn
⚠ Dễ lọt vào Git, log, ảnh chụp màn hình
⚠ Dùng được từ BẤT KỲ đâu trên Internet
⚠ Khó biết đã bị dùng ở đâu
⚠ Chính sách tổ chức ⚠ disableServiceAccountKeyCreation chặn hẳn việc tạo khoá
⚠ Metadata server cho gì Ưu điểm
⚠ Token ngắn hạn, tự làm mới
⚠ Chỉ gọi được TỪ BÊN TRONG VM
⚠ Không có gì để đánh cắp trên đĩa
⚠ Đổi quyền là đổi ngay ở IAM ⚠ không cần triển khai lại
⚠ Bảo vệ ⚠ đặt header Metadata-Flavor: Google để chống SSRF
⚠ Nguyên tắc quyền tối thiểu với Cloud Storage Nguyên tắc
⚠ Cấp ở mức BUCKET chứ không phải project
⚠ Dùng vai trò storage.objectViewer thay vì storage.admin
⚠ Mỗi ứng dụng một service account riêng ⚠ đừng dùng chung
⚠ KHÔNG dùng service account mặc định của Compute Engine ⚠ nó có quyền Editor toàn project

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM có đang dùng service account mặc định không | ⚠ rất phổ biến và rất rộng quyền | | Có file khoá JSON nào trên máy không | | | Scope của VM có bị đặt cloud-platform không | ⚠ quá rộng |

Và thói quen nguy hiểm nhất trong nhóm phát triển: tải file khoá service account về rồi commit vào repo "chỉ để thử". Khoá đó không hết hạn và dùng được từ bất cứ đâu trên thế giới.