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

Đáp án

C và D — GDPR và Chuẩn bảo mật dữ liệu PCI (PCI DSS).

Vì sao đúng

⚠ Ghép từng dữ kiện của đề với từng quy định: | Dữ kiện | Quy định | |---|---| | ⚠ Mở rộng sang Tây Ban Nha, Pháp, Bỉ, Đức | ⚠ GDPR — dữ liệu cá nhân của cư dân EU | | ⚠ Tạo HỒ SƠ CHI TIẾT về sở thích khách hàng | ⚠ GDPR — lập hồ sơ (profiling) bị quản chặt | | ⚠ Là nhà BÁN LẺ — nhận thanh toán thẻ | ⚠ PCI DSS |

⚠ GDPR áp dụng theo NƠI CƯ TRÚ của người dùng, ⚠ không phải nơi đặt trụ sở công ty.

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

• A (HIPAA) — ⚠ dữ liệu Y TẾ tại Mỹ: ⚠ nhà bán lẻ không xử lý hồ sơ sức khoẻ.

• B (SOX) — ⚠ báo cáo TÀI CHÍNH của công ty đại chúng Mỹ: ⚠ về kiểm soát nội bộ và kế toán, ⚠ không liên quan dữ liệu khách hàng.

• E (Expedited Funds Availability Act) — ⚠ quy định về thời gian ngân hàng Mỹ giải ngân séc: ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Các quy định hay gặp trong đề — bảng phải thuộc: | Quy định | Về cái gì | Ai chịu | |---|---|---| | ⚠ GDPR | ⚠ dữ liệu cá nhân | ⚠ ai xử lý dữ liệu cư dân EU | | ⚠ PCI DSS | ⚠ dữ liệu thẻ thanh toán | ⚠ ai nhận thanh toán thẻ | | ⚠ HIPAA | ⚠ dữ liệu y tế | ⚠ tổ chức y tế Mỹ | | ⚠ SOX | ⚠ báo cáo tài chính | ⚠ công ty đại chúng Mỹ | | ⚠ CCPA | ⚠ dữ liệu cá nhân | ⚠ cư dân California |

Từ khoá nhận diện:

"khách hàng ở châu Âu" → ⚠ GDPR "thanh toán bằng thẻ" → ⚠ PCI DSS "hồ sơ bệnh nhân" → ⚠ HIPAA — cần ký BAA với Google "báo cáo tài chính công ty niêm yết" → ⚠ SOX

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu cư dân EU có nằm ngoài EU không | | | Có xoá được toàn bộ dữ liệu của một người khi họ yêu cầu không | ⚠ kể cả trong bản sao lưu | | Có thu thập dữ liệu nào không thật sự cần không | |

Và yêu cầu GDPR khó nhất về mặt kỹ thuật: quyền được xoá. Dữ liệu một người thường nằm rải rác trong CSDL chính, kho phân tích, log, bản sao lưu và bộ nhớ đệm — và phải xoá được ở tất cả những nơi đó.

Đáp án

D — Dialogflow.

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

⚠ Sản phẩm đã được đổi tên và mở rộng.

⚠ KHÔNG sửa khoá.

Vì sao đúng

⚠ Đề cần chatbot ĐỊNH TUYẾN khách tới đúng đội hỗ trợ:

⚠ Khách hàng đặt câu hỏi
        ↓ ⚠ Dialogflow
⚠ Nhận diện Ý ĐỊNH (intent)
   ⚠ "hỏi về bồi thường"
   ⚠ "hỏi về hợp đồng"
   ⚠ "hỏi về thanh toán"
        ↓
⚠ Chuyển tới đúng đội hỗ trợ

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

• B (Speech-to-Text API) — ⚠ chỉ chuyển GIỌNG NÓI thành chữ: ⚠ là một thành phần nếu chatbot qua điện thoại, ⚠ không phải cả chatbot.

• A (Text-to-Speech API) — ⚠ chỉ chuyển chữ thành giọng nói: ⚠ cũng chỉ là một mảnh.

• C (AutoML Tables) — ⚠ học máy trên dữ liệu BẢNG: ⚠ không xử lý hội thoại.

Ghi nhớ

⚠ API AI của Google Cloud — bảng phải thuộc: | API | Việc | |---|---| | ⚠ Dialogflow / Conversational Agents | ⚠ chatbot, hội thoại | | ⚠ Speech-to-Text | ⚠ giọng nói → chữ | | ⚠ Text-to-Speech | ⚠ chữ → giọng nói | | ⚠ Natural Language API | ⚠ cảm xúc, thực thể, phân loại văn bản | | ⚠ Translation API | ⚠ dịch | | ⚠ Vision API | ⚠ phân tích ảnh | | ⚠ Document AI | ⚠ trích xuất dữ liệu từ tài liệu |

Từ khoá nhận diện:

"chatbot, trợ lý hội thoại" → ⚠ Dialogflow "tổng đài thoại tự động" → ⚠ Dialogflow + Speech-to-Text + Text-to-Speech "phân tích cảm xúc bình luận" → ⚠ Natural Language API "phân loại yêu cầu hỗ trợ từ dữ liệu bảng" → ⚠ AutoML / BigQuery ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đường chuyển sang người thật không | | | Tỉ lệ nhận diện đúng ý định là bao nhiêu | | | Log hội thoại có chứa PII không | ⚠ cần DLP |

Và điều quyết định một chatbot hỗ trợ khách hàng có được chấp nhận hay không: nó thoát ra dễ đến mức nào. Một bot định tuyến sai mà không cho gặp người thật gây bực bội hơn hẳn việc không có bot.

Đáp án

B — Cloud Storage lớp Nearline.

Vì sao đúng

⚠ Ghép yêu cầu với đặc điểm lớp lưu trữ: | Yêu cầu của đề | Lớp phù hợp | |---|---| | ⚠ Truy cập khoảng MỘT LẦN MỖI THÁNG | ⚠ Nearline — đúng thiết kế | | ⚠ Tối thiểu chi phí lưu trữ | ⚠ rẻ hơn Standard đáng kể | | ⚠ Đáng tin cậy, sẵn sàng cao | ⚠ 11 số 9 độ bền như mọi lớp | | ⚠ 200 TB, dùng ở us-central1 | ⚠ một vùng là đủ |

⚠ Nearline có thời gian lưu tối thiểu 30 ngày — ⚠ khớp với nhịp truy cập hằng tháng.

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

• A (Cloud Storage Multi-Region) — ⚠ đắt hơn mà không cần thiết: ⚠ kỹ sư ⚠ đều ở us-central1; ⚠ trả tiền cho nhân bản đa vùng là lãng phí.

• C (SSD Persistent Disk) — ⚠ đắt nhất trong bốn lựa chọn: ⚠ 200 TB trên SSD là chi phí khổng lồ; ⚠ và ⚠ phải gắn vào VM mới dùng được.

• D (Balanced Persistent Disk) — ⚠ rẻ hơn SSD nhưng vẫn đắt hơn kho đối tượng nhiều lần.

Ghi nhớ

⚠ Bốn lớp Cloud Storage — bảng phải thuộc: | Lớp | Tần suất truy cập | Lưu tối thiểu | |---|---|---| | ⚠ Standard | ⚠ thường xuyên | ⚠ không có | | ⚠ Nearline | ⚠ ~1 lần/tháng | ⚠ 30 ngày | | ⚠ Coldline | ⚠ ~1 lần/quý | ⚠ 90 ngày | | ⚠ Archive | ⚠ dưới 1 lần/năm | ⚠ 365 ngày |

Từ khoá nhận diện:

"một lần mỗi tháng" → ⚠ Nearline "một lần mỗi quý" → ⚠ Coldline "gần như không bao giờ đọc" → ⚠ Archive "đọc liên tục" → ⚠ Standard

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tần suất truy cập thật sự là bao nhiêu | ⚠ đo bằng log, đừng đoán | | Dữ liệu có cùng vùng với nơi tính toán không | | | Lifecycle đã đặt để tự chuyển lớp chưa | |

Và cái bẫy chi phí ngược đời của các lớp lưu trữ lạnh: chọn lớp quá lạnh cho dữ liệu đọc thường xuyên sẽ đắt hơn Standard. Phí lấy dữ liệu tích luỹ nhanh hơn khoản tiết kiệm ở phí lưu trữ.

Đáp án

A — Nearline Storage.

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

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

Vì sao đúng

⚠ Con số "30 ngày" trong đề khớp CHÍNH XÁC với Nearline:

⚠ Nearline
   ⚠ thiết kế cho truy cập ~1 lần/tháng
   ⚠ thời gian lưu tối thiểu 30 ngày
        ↓
⚠ Đề nói "trung bình 30 ngày một lần"
        ↓
⚠ Khớp hoàn hảo

⚠ Chữ "lưu trữ dài hạn" (archive) trong đề dễ đánh lừa — ⚠ nhưng ⚠ tần suất truy cập mới là thứ quyết định, không phải cái tên.

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

• B (Coldline) — ⚠ bẫy vì đề có chữ "archive": ⚠ Coldline dành cho ⚠ ~1 lần mỗi QUÝ; ⚠ đọc hằng tháng trên Coldline ⚠ phí lấy dữ liệu sẽ vượt khoản tiết kiệm.

• C (Multi-regional) — ⚠ là cấu hình VỊ TRÍ, không phải lớp lưu trữ lạnh: ⚠ và ⚠ đắt hơn cho nhu cầu này.

• D (Persistent Disk) — ⚠ đắt hơn kho đối tượng nhiều lần và ⚠ phải có VM.

Ghi nhớ

⚠ Chọn lớp theo tần suất — bảng phải thuộc: | Tần suất đọc | Lớp | Lưu tối thiểu | |---|---|---| | ⚠ Hằng ngày, liên tục | ⚠ Standard | ⚠ không có | | ⚠ ~1 lần/tháng | ⚠ Nearline | ⚠ 30 ngày | | ⚠ ~1 lần/quý | ⚠ Coldline | ⚠ 90 ngày | | ⚠ ~1 lần/năm hoặc ít hơn | ⚠ Archive | ⚠ 365 ngày |

Từ khoá nhận diện:

"30 ngày một lần" → ⚠ Nearline "90 ngày một lần" → ⚠ Coldline "chỉ giữ để tuân thủ, hầu như không đọc" → ⚠ Archive "chữ archive trong đề" → ⚠ KHÔNG tự động nghĩa là lớp Archive

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tần suất đọc thật sự đo được không | ⚠ bật usage log | | Đã tính cả phí lấy dữ liệu chưa | | | Có nên bật Autoclass không | ⚠ khi mẫu truy cập không đoán được |

Và bài học chung của cả hai câu về lớp lưu trữ trong lô này: tên gọi trong đề bài không quyết định, tần suất truy cập mới quyết định. Một kho "lưu trữ dài hạn" được đọc hằng tháng vẫn thuộc về Nearline.

Đáp án

A — Đặt chính sách tổ chức Resource Location Restriction để mọi topic chỉ được lưu ở các vùng được chấp nhận.

Vì sao đúng

⚠ Vấn đề của đề: dữ liệu có thể vô tình bị ghi ra vùng ngoài EU, ⚠ vi phạm GDPR.

⚠ constraints/gcp.resourceLocations
        ↓ ⚠ đặt ở cấp TỔ CHỨC
⚠ Chỉ cho tạo tài nguyên ở
   ⚠ europe-west1, europe-west4…
        ↓
⚠ Ai đó cố tạo topic ở us-central1
        ↓
⚠ BỊ TỪ CHỐI ngay lúc tạo

⚠ Vì sao là TOPIC: ⚠ trong Pub/Sub, ⚠ dữ liệu tin nhắn được lưu ở topic; ⚠ đó là nơi cần ràng buộc vị trí.

⚠ Chính sách tổ chức là hàng rào CỨNG — ⚠ chặn cả người có quyền admin, ⚠ khác với việc dựa vào kỷ luật của con người.

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

• B (ràng buộc vị trí cho BUCKET) — ⚠ đúng cơ chế nhưng sai đối tượng: ⚠ đề nói về Pub/Sub, không phải Cloud Storage.

• C (chỉ khai endpoint ở vùng được phép khi tạo topic) — ⚠ dựa vào kỷ luật con người: ⚠ ai đó quên là ⚠ vi phạm; ⚠ không có gì cưỡng chế.

• D (khai endpoint khi tạo subscription) — ⚠ cùng vấn đề với C, ⚠ và ⚠ dữ liệu lưu ở topic chứ không phải subscription.

Ghi nhớ

⚠ gcp.resourceLocations — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Loại ràng buộc | ⚠ danh sách (list constraint) | | ⚠ Đặt ở | ⚠ tổ chức, folder, hoặc project | | ⚠ Cưỡng chế | ⚠ từ chối TẠO tài nguyên ngoài vùng cho phép | | ⚠ Giá trị nhóm | ⚠ in:eu-locations, in:us-locations | | ⚠ Lưu ý | ⚠ KHÔNG di chuyển tài nguyên đã có — chỉ chặn cái mới |

Từ khoá nhận diện:

"dữ liệu phải ở trong EU" → ⚠ gcp.resourceLocations cấp tổ chức "chặn dữ liệu bị mang ra ngoài ranh giới" → ⚠ VPC Service Controls "ai được truy cập" → ⚠ IAM "khoá phải nằm ngoài Google" → ⚠ Cloud EKM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài nguyên nào đã nằm ngoài EU không | ⚠ chính sách không hồi tố | | Chính sách đặt ở cấp tổ chức hay project | | | Dịch vụ nào bị ảnh hưởng khi áp | ⚠ thử ở folder nhỏ trước |

Và khác biệt cốt lõi giữa hai cách tiếp cận tuân thủ: một bên viết vào tài liệu quy trình, một bên viết vào chính sách mà hệ thống cưỡng chế. Chỉ cái thứ hai còn hiệu lực vào lúc 2 giờ sáng khi có người đang vội xử lý sự cố.

Đáp án

B và C — Dùng Cloud Storage cho lưu trữ bền, và dùng không quá 30% VM preemptible cho secondary worker.

Vì sao đúng

⚠ Hai thực hành tốt của Dataproc: | Thực hành | Lý do | |---|---| | ⚠ B — Cloud Storage thay HDFS | ⚠ tách lưu trữ khỏi tính toán, xoá cụm không mất dữ liệu | | ⚠ C — preemptible ≤ khoảng 30% | ⚠ quá nhiều thì job hay phải làm lại khi VM bị thu hồi |

⚠ Preemptible quá nhiều
        ↓
⚠ Nhiều worker biến mất giữa chừng
        ↓
⚠ Spark phải tính lại phần đã mất
        ↓
⚠ Job chậm hơn, có khi ĐẮT HƠN
   so với dùng VM thường

⚠ Tiết kiệm chi phí có điểm bão hoà — ⚠ vượt qua đó thì càng rẻ càng chậm.

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

• A (dùng HDFS trên persistent disk) — ⚠ ngược thực hành tốt: ⚠ giữ dữ liệu trong cụm khiến ⚠ không dám xoá cụm.

• D (chỉ dùng preemptible cho worker chạy HDFS) — ⚠ NGƯỢC HOÀN TOÀN: ⚠ worker chạy HDFS phải là worker ⚠ ỔN ĐỊNH; ⚠ preemptible bị thu hồi là mất dữ liệu HDFS.

• E (tắt autoscaling) — ⚠ bỏ một tính năng có ích: ⚠ autoscaling giúp co giãn theo tải; ⚠ vấn đề của nó (mất shuffle) chữa bằng EFM và graceful decommission, không phải bằng cách tắt.

Ghi nhớ

⚠ Thực hành tốt Dataproc — bảng phải thuộc: | Thực hành | Nội dung | |---|---| | ⚠ Cụm ngắn hạn | ⚠ tạo → chạy → xoá | | ⚠ Dữ liệu ở Cloud Storage | ⚠ không phải HDFS | | ⚠ Preemptible cho SECONDARY worker | ⚠ không quá ~30% | | ⚠ Primary worker luôn ổn định | ⚠ chạy HDFS DataNode | | ⚠ --max-idle tự xoá cụm rảnh | | | ⚠ EFM khi bật autoscaling | ⚠ bảo vệ dữ liệu shuffle |

Từ khoá nhận diện:

"thực hành tốt Dataproc" → ⚠ Cloud Storage + cụm ngắn hạn + preemptible có giới hạn "preemptible cho HDFS" → ⚠ LUÔN SAI "FetchFailedException" → ⚠ autoscaling thu nhỏ lúc shuffle → bật EFM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ preemptible hiện tại là bao nhiêu | | | Job có hay thất bại vì mất worker không | | | Cụm có bị để chạy khi rảnh không | |

Và điều hay bị bỏ qua khi tối ưu chi phí bằng VM giá rẻ: thời gian chạy lâu hơn cũng là tiền. Một cụm rẻ hơn 60% nhưng chạy lâu gấp ba lần thì không tiết kiệm được gì cả.

Đáp án

A — L2 Regularization.

Vì sao đúng

⚠ Dấu hiệu quá khớp trong đề: ⚠ mô hình tốt trên tập kiểm định nhưng ⚠ tệ trong sản xuất.

⚠ Quá khớp = ⚠ mô hình HỌC THUỘC
   dữ liệu huấn luyện
        ↓
⚠ Học cả nhiễu, không phải quy luật
        ↓ ⚠ L2 regularization
⚠ Phạt trọng số LỚN
        ↓
⚠ Mô hình đơn giản hơn, mượt hơn
        ↓
⚠ Tổng quát hoá tốt hơn

⚠ L2 thêm hạng λ × Σw² vào hàm mất mát — ⚠ mô hình bị "kéo" về phía trọng số nhỏ.

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

• B (gradient descent) và C (backpropagation) — ⚠ là cơ chế HUẤN LUYỆN chuẩn: ⚠ luôn được dùng; ⚠ không phải kỹ thuật chống quá khớp.

• D ("label engineering") — ⚠ không phải thuật ngữ chuẩn: ⚠ có feature engineering, ⚠ không có "label engineering".

Ghi nhớ

⚠ Các cách chống quá khớp — bảng phải thuộc: | Cách | Nội dung | |---|---| | ⚠ L2 (Ridge) | ⚠ phạt bình phương trọng số — thu nhỏ, không về 0 | | ⚠ L1 (Lasso) | ⚠ phạt trị tuyệt đối — đưa về 0, chọn đặc trưng | | ⚠ Dropout | ⚠ tắt ngẫu nhiên nơ-ron khi huấn luyện | | ⚠ Early stopping | ⚠ dừng khi lỗi kiểm định bắt đầu tăng | | ⚠ Thêm dữ liệu | ⚠ hiệu quả nhất nếu làm được | | ⚠ Data augmentation | ⚠ tạo biến thể từ dữ liệu có sẵn | | ⚠ Giảm độ phức tạp mô hình | |

Từ khoá nhận diện:

"tốt trên train/validation, tệ trong sản xuất" → ⚠ quá khớp → regularization "tệ trên cả hai" → ⚠ chưa khớp → thêm đặc trưng, mô hình lớn hơn "muốn loại bỏ đặc trưng vô ích" → ⚠ L1

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu sản xuất có khác dữ liệu huấn luyện không | ⚠ kiểm tra trước khi đổ lỗi cho quá khớp | | Có rò rỉ dữ liệu trong tập kiểm định không | | | Lambda đã dò bằng cross-validation chưa | |

Và câu hỏi nên hỏi trước khi vội thêm regularization: dữ liệu sản xuất hôm nay có còn giống dữ liệu huấn luyện hôm qua không?. Rất thường xuyên, mô hình không quá khớp — thế giới chỉ đơn giản đã thay đổi.

Đáp án

C — Key Visualizer.

Vì sao đúng

⚠ Key Visualizer là công cụ CHUYÊN cho việc này:

⚠ Bản đồ nhiệt (heatmap)
   ⚠ trục ngang: THỜI GIAN
   ⚠ trục dọc: DẢI ROW KEY
   ⚠ màu: mức độ truy cập
        ↓
⚠ VỆT SÁNG DỌC = ⚠ điểm nóng
⚠ Màu đều = ⚠ phân bố tốt

⚠ Tự động sinh cho bảng đủ lớn — ⚠ không phải bật gì.

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

• A (Cloud Monitoring) — ⚠ cho chỉ số TỔNG THỂ: ⚠ CPU, thông lượng, độ trễ; ⚠ không phân tích theo row key.

• B (Cloud Logging) — ⚠ ghi sự kiện và lỗi: ⚠ không phân tích mẫu truy cập.

• D ("Cloud Key Trace") — ⚠ dịch vụ KHÔNG TỒN TẠI: ⚠ tên bịa.

Ghi nhớ

⚠ Chẩn đoán hiệu năng Bigtable — bảng phải thuộc: | Triệu chứng | Công cụ | |---|---| | ⚠ Nghi row key gây điểm nóng | ⚠ Key Visualizer | | ⚠ CPU cụm cao | ⚠ Cloud Monitoring | | ⚠ Lỗi truy cập, quyền | ⚠ Cloud Logging | | ⚠ Độ trễ tăng dần | ⚠ Monitoring + Key Visualizer |

Từ khoá nhận diện:

"xem mẫu truy cập theo row key" → ⚠ Key Visualizer "CPU, thông lượng, độ trễ tổng thể" → ⚠ Cloud Monitoring "request chậm ở dịch vụ nào" → ⚠ Cloud Trace (ứng dụng, không phải Bigtable)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Key Visualizer có vệt sáng dọc nào không | | | CPU node nóng nhất so với trung bình chênh bao nhiêu | | | Thêm node có tăng thông lượng không | |

Và giá trị lớn nhất của Key Visualizer: nó biến một giả thuyết thành một bức ảnh. Bạn không còn phải tranh luận xem row key có gây điểm nóng hay không — chỉ cần nhìn.

Đáp án

B — job/system_lag.

Vì sao đúng

⚠ Hai chỉ số về thời gian của Dataflow rất dễ lẫn: | Chỉ số | Ý nghĩa | |---|---| | ⚠ job/system_lag | ⚠ thời gian chờ TỐI ĐA của một phần tử đang trong pipeline — đề này | | ⚠ job/data_watermark_age | ⚠ tuổi của watermark — dữ liệu đã xử lý tới mốc thời gian nào |

⚠ system_lag
   ⚠ "phần tử chờ lâu nhất
      đã chờ bao lâu rồi?"
        ↓
⚠ Tăng dần = ⚠ pipeline không theo kịp
        ↓
⚠ Đúng câu hỏi đề đặt ra

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

• A (job/data_watermark_age) — ⚠ bẫy gần nhất: ⚠ đo tiến độ theo thời gian SỰ KIỆN, ⚠ không phải thời gian một phần tử chờ trong pipeline.

• C (job/elapsed_time) — ⚠ tổng thời gian JOB đã chạy: ⚠ không nói gì về từng phần tử.

• D (job/element_count) — ⚠ ĐẾM số phần tử: ⚠ không phải thời gian.

Ghi nhớ

⚠ Chỉ số giám sát Dataflow — bảng phải thuộc: | Chỉ số | Cho biết | |---|---| | ⚠ job/system_lag | ⚠ độ trễ xử lý — chỉ số SỨC KHOẺ quan trọng nhất cho streaming | | ⚠ job/data_watermark_age | ⚠ tiến độ theo thời gian sự kiện | | ⚠ job/elapsed_time | ⚠ job đã chạy bao lâu | | ⚠ job/element_count | ⚠ số phần tử qua từng bước | | ⚠ job/current_num_vcpus | ⚠ quy mô worker hiện tại |

Từ khoá nhận diện:

"phần tử chờ lâu nhất bao lâu" → ⚠ system_lag "đã xử lý tới mốc thời gian nào" → ⚠ data_watermark_age "tồn đọng ở Pub/Sub" → ⚠ subscription/num_undelivered_messages

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cảnh báo trên system_lag chưa | | | Bước nào tốn nhiều thời gian nhất | ⚠ xem Job Graph | | Dữ liệu có bị lệch theo khoá không | |

Và chỉ số nên đặt cảnh báo đầu tiên cho mọi pipeline streaming: system_lag. Nó trả lời đúng câu hỏi mà người dùng cuối quan tâm — dữ liệu tôi thấy đang cũ bao nhiêu?

Đáp án

A — Một chính sách đã được áp lên cây phân cấp tài nguyên, cưỡng chế ràng buộc constraints/iam.disableServiceAccountKeyCreation.

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

⚠ Tên ràng buộc trong khoá KHÔNG khớp chính xác với hành động bị chặn.

⚠ KHÔNG sửa khoá — ⚠ trong bốn phương án, ⚠ A vẫn là phương án duy nhất nêu đúng cơ chế: ⚠ chính sách tổ chức áp lên cây phân cấp tài nguyên.

⚠ Cách nhớ an toàn: ⚠ nhớ cả hai ràng buộc và phân biệt được chúng.

Vì sao đúng (về cơ chế)

⚠ Organization Policy đặt ở
   ⚠ tổ chức / folder / project
        ↓ ⚠ KẾ THỪA xuống dưới
⚠ Chặn một hành động cụ thể
        ↓
⚠ Lập trình viên dù có quyền IAM
   ⚠ VẪN không thực hiện được
        ↓
⚠ Thông báo lỗi thường không rõ ràng

⚠ Đây là lý do phổ biến nhất khiến một thao tác thất bại dù IAM đã đủ quyền.

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

• D (chính sách áp lên IAM GROUP tắt quyền tạo service account) — ⚠ IAM không hoạt động theo kiểu "tắt quyền": ⚠ IAM chỉ CẤP quyền, ⚠ không có "chính sách từ chối" gắn vào group theo cách này; ⚠ (có IAM Deny policy nhưng gắn theo tài nguyên, không phải group).

• B (thiếu file deployment.yaml) — ⚠ tạo service account không cần file YAML nào.

• C (chưa cấu hình bản ghi DNS A) — ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Ràng buộc IAM hay gặp — bảng phải thuộc: | Ràng buộc | Chặn | |---|---| | ⚠ iam.disableServiceAccountCreation | ⚠ tạo service account | | ⚠ iam.disableServiceAccountKeyCreation | ⚠ tạo KHOÁ service account | | ⚠ iam.disableServiceAccountKeyUpload | ⚠ tải khoá tự tạo lên | | ⚠ iam.allowedPolicyMemberDomains | ⚠ chỉ cho phép danh tính từ miền nhất định | | ⚠ iam.automaticIamGrantsForDefaultServiceAccounts | ⚠ tắt việc tự cấp Editor cho SA mặc định |

Từ khoá nhận diện:

"có quyền IAM mà vẫn không làm được" → ⚠ Organization Policy chặn "không tạo được khoá service account" → ⚠ disableServiceAccountKeyCreation "chỉ người trong công ty được cấp quyền" → ⚠ allowedPolicyMemberDomains

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách tổ chức nào đang áp cho project này | | | Có thật sự cần khoá service account không | ⚠ thường là không | | Policy Troubleshooter nói gì | |

Và nguồn gốc của rất nhiều giờ gỡ lỗi lãng phí trên Google Cloud: thông báo lỗi khi bị Organization Policy chặn thường không nói rõ chính sách nào. Khi IAM trông có vẻ đủ mà thao tác vẫn hỏng, hãy nhìn lên cây phân cấp tài nguyên trước tiên.