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

Đáp án

D — Dùng Dataflow FlexRS (Flexible Resource Scheduling).

Vì sao đúng

⚠ Đề nêu ba điều kiện, cả ba đều khớp FlexRS: | Điều kiện | FlexRS | |---|---| | ⚠ Job BATCH lớn | ⚠ FlexRS chỉ dành cho batch | | ⚠ Không cần lịch cố định, chờ được lâu hơn | ⚠ FlexRS xếp hàng, chạy trong 6 giờ tới | | ⚠ Muốn giảm chi phí, ít thay đổi nhất | ⚠ chỉ thêm MỘT cờ khi chạy job |

⚠ Job được gửi với FlexRS
        ↓
⚠ Dataflow XẾP HÀNG, chờ lúc
   có tài nguyên rẻ
        ↓ ⚠ trong vòng 6 giờ
⚠ Chạy chủ yếu bằng VM preemptible
        ↓
⚠ Giảm chi phí đáng kể

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

• B (Dataflow Shuffle) — ⚠ cải thiện HIỆU NĂNG chứ không nhằm giảm giá: ⚠ đưa shuffle ra khỏi worker; ⚠ giúp job chạy nhanh hơn, ⚠ nhưng không phải cơ chế tiết kiệm theo yêu cầu đề.

• C (Dataflow Streaming Engine) — ⚠ chỉ dành cho job STREAMING: ⚠ đề nói rõ là batch.

• A (dùng Apache Beam runner khác) — ⚠ thay đổi rất lớn: ⚠ đề yêu cầu ⚠ "không thay đổi nhiều hơn mức cần thiết"; ⚠ đổi runner là bỏ dịch vụ được quản.

Ghi nhớ

⚠ Các chế độ của Dataflow — bảng phải thuộc: | Tính năng | Dành cho | Mục đích | |---|---|---| | ⚠ FlexRS | ⚠ BATCH | ⚠ giảm CHI PHÍ, chấp nhận chờ tới 6 giờ | | ⚠ Dataflow Shuffle | ⚠ BATCH | ⚠ hiệu năng, shuffle ngoài worker | | ⚠ Streaming Engine | ⚠ STREAMING | ⚠ tách trạng thái khỏi worker, co giãn tốt hơn | | ⚠ Dataflow Prime | ⚠ cả hai | ⚠ tự chọn tài nguyên theo từng bước |

Từ khoá nhận diện:

"batch, không gấp, muốn rẻ" → ⚠ FlexRS "streaming co giãn kém" → ⚠ Streaming Engine "batch shuffle chậm" → ⚠ Dataflow Shuffle "tự động tối ưu tài nguyên" → ⚠ Dataflow Prime

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job có thật sự chờ được 6 giờ không | | | maxNumWorkers có bị để mặc định không | | | Bước nào tốn tài nguyên nhất | ⚠ xem Job Metrics trước khi tối ưu |

Và nguyên tắc chung khi được hỏi giảm chi phí mà "ít thay đổi nhất": tìm cái cờ có sẵn trước khi tìm kiến trúc mới. FlexRS là một cờ; đổi runner là một dự án.

Đáp án

A — Data Loss Prevention và Data Catalog.

Vì sao đúng

⚠ Bài toán chia làm hai việc, mỗi dịch vụ lo một việc:

⚠ Dữ liệu vào Cloud Storage
        ↓ ⚠ Bước 1: DLP
⚠ QUÉT và PHÁT HIỆN PII
   (⚠ email, số thẻ, căn cước…)
        ↓ ⚠ Bước 2: Data Catalog
⚠ GẮN THẺ siêu dữ liệu cho object
   (⚠ "chứa PII", "mức nhạy cảm: cao")
        ↓
⚠ Sau này tìm và quản trị được

⚠ Hai dịch vụ này tích hợp sẵn với nhau — ⚠ kết quả quét DLP xuất được thẳng thành thẻ Data Catalog.

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

• D (DLP và Compute Engine) — ⚠ DLP đúng, Compute Engine sai: ⚠ VM là hạ tầng, ⚠ không phải dịch vụ được quản để gắn thẻ.

• C (Data Catalog và Cloud Firestore) — ⚠ Firestore là CSDL tài liệu: ⚠ không phát hiện PII.

• B (Compute Engine và Data Catalog) — ⚠ thiếu hẳn khâu phát hiện PII.

Ghi nhớ

⚠ Quản trị dữ liệu trên Google Cloud — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | ⚠ Tìm dữ liệu nhạy cảm | ⚠ Sensitive Data Protection (DLP) | | ⚠ Ghi siêu dữ liệu, gắn thẻ, tìm kiếm | ⚠ Data Catalog (trong Dataplex) | | ⚠ Quản trị và tổ chức dữ liệu quy mô lớn | ⚠ Dataplex | | ⚠ Kiểm soát truy cập theo cột/dòng | ⚠ BigQuery policy tag / row-level security | | ⚠ Nguồn gốc dữ liệu (lineage) | ⚠ Dataplex lineage |

Từ khoá nhận diện:

"phát hiện PII" → ⚠ DLP "gắn thẻ, tìm kiếm dataset" → ⚠ Data Catalog "kiểm soát ai đọc được cột nhạy cảm" → ⚠ policy tag + BigQuery column-level security

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có biết PII nằm ở những bảng nào không | | | Thẻ có được cập nhật khi dữ liệu mới vào không | | | Thẻ chỉ mô tả hay có cưỡng chế truy cập | ⚠ policy tag mới cưỡng chế |

Và khoảng cách hay gặp giữa lý thuyết và thực tế quản trị dữ liệu: gắn thẻ không bảo vệ được gì. Một nhãn "chứa PII" chỉ có ích khi có một chính sách thật sự đọc nhãn đó và chặn ai đó lại.

Đáp án

B — Dùng Cloud Data Catalog để tự động trích xuất siêu dữ liệu từ object trong Cloud Storage và dữ liệu trong BigQuery.

Vì sao đúng

⚠ Vấn đề của đề: kỹ sư ML và nhà phân tích ⚠ không tìm được dataset họ cần.

⚠ Dữ liệu nằm rải rác
   ⚠ BigQuery: hàng trăm bảng
   ⚠ Cloud Storage: hàng nghìn tệp
        ↓
⚠ Data Catalog TỰ ĐỘNG thu thập
   siêu dữ liệu
        ↓
⚠ Một chỗ TÌM KIẾM duy nhất
   ⚠ theo tên, mô tả, thẻ, chủ sở hữu
        ↓
⚠ Không phải đi hỏi từng người nữa

⚠ Điểm mạnh: ⚠ TỰ ĐỘNG — ⚠ không ai phải ngồi nhập tay danh mục.

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

• A (tự truy vấn metadata catalog rồi ghi vào một bảng BigQuery) — ⚠ tự dựng lại thứ đã có: ⚠ phải tự bảo trì, ⚠ tự cập nhật, ⚠ không có tìm kiếm toàn văn, ⚠ và ⚠ người dùng phải biết SQL.

• C (dùng Cloud Data Fusion để theo dõi tệp và dataset) — ⚠ Data Fusion là công cụ ETL trực quan: ⚠ để xây đường ống dữ liệu, ⚠ không phải danh mục siêu dữ liệu.

• D (dùng Cloud Logging để theo dõi tệp tải lên và dataset) — ⚠ log ghi SỰ KIỆN, không phải danh mục: ⚠ không tìm kiếm được theo nội dung dữ liệu.

Ghi nhớ

⚠ Data Catalog làm gì — bảng phải thuộc: | Chức năng | Nội dung | |---|---| | ⚠ Tự động thu thập siêu dữ liệu | ⚠ BigQuery, Cloud Storage, Pub/Sub, Bigtable, Spanner | | ⚠ Tìm kiếm toàn văn | ⚠ cùng công nghệ tìm kiếm Google dùng nội bộ | | ⚠ Gắn thẻ tuỳ chỉnh | ⚠ tag template | | ⚠ Policy tag | ⚠ cưỡng chế bảo mật cấp cột | | ⚠ Nay là một phần của | ⚠ Dataplex |

Từ khoá nhận diện:

"không tìm được dữ liệu ở đâu" → ⚠ Data Catalog "xây đường ống ETL bằng giao diện kéo thả" → ⚠ Data Fusion "điều phối nhiều bước công việc" → ⚠ Cloud Composer "quản trị dữ liệu toàn tổ chức, data mesh" → ⚠ Dataplex

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người mới vào mất bao lâu để tìm được dữ liệu cần | | | Bảng quan trọng có ghi chủ sở hữu không | | | Có bảng nào không ai biết dùng để làm gì không | ⚠ ứng viên để xoá |

Và triệu chứng rõ nhất của một tổ chức thiếu danh mục dữ liệu: cùng một bảng được dựng lại ba lần bởi ba nhóm khác nhau, vì không ai biết hai nhóm kia đã làm rồi.

Đáp án

C — Data Catalog.

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

⚠ Ba câu trong cùng lô này xoay quanh Data Catalog (#16207, #16208, và câu này) ⚠ với ba góc khác nhau:

Vì sao đúng

⚠ Đề nêu: lưu kết quả phân tích PII ⚠ để sau này tra lại dễ dàng.

⚠ Kết quả phân tích PII
   = ⚠ "bảng X, cột Y chứa số căn cước"
   = ⚠ THÔNG TIN VỀ dữ liệu
   = ⚠ SIÊU DỮ LIỆU
        ↓
⚠ Data Catalog là nơi dành cho
   siêu dữ liệu
        ↓
⚠ Gắn thành thẻ, tìm kiếm được,
   gắn liền với chính tài nguyên đó

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

• A (Data Loss Prevention) — ⚠ DLP THỰC HIỆN phân tích, không phải nơi LƯU kết quả lâu dài: ⚠ nó là công cụ quét.

• B (BigQuery) — ⚠ lưu được nhưng rời rạc: ⚠ kết quả nằm trong một bảng ⚠ tách rời khỏi tài nguyên nó mô tả; ⚠ phải nhớ mà tra.

• D (Cloud Spanner) — ⚠ CSDL giao dịch toàn cầu: ⚠ đắt và hoàn toàn sai mục đích.

Ghi nhớ

⚠ Dữ liệu và siêu dữ liệu — bảng phải thuộc: | Loại | Ở đâu | |---|---| | ⚠ DỮ LIỆU | ⚠ BigQuery, Cloud Storage, Bigtable… | | ⚠ SIÊU DỮ LIỆU | ⚠ Data Catalog / Dataplex | | ⚠ Kết quả quét bảo mật | ⚠ Data Catalog (thẻ) hoặc SCC (phát hiện) | | ⚠ Log hoạt động | ⚠ Cloud Logging |

Từ khoá nhận diện:

"lưu kết quả phân tích về dữ liệu để tra sau" → ⚠ Data Catalog "thực hiện quét tìm dữ liệu nhạy cảm" → ⚠ DLP "phát hiện bảo mật toàn tổ chức" → ⚠ Security Command Center

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết quả quét PII lần cuối là bao giờ | | | Thẻ có được cập nhật tự động không | | | Có ai thật sự đọc các thẻ đó không | ⚠ hay chỉ để cho có |

Và điều quyết định một chương trình quản trị dữ liệu sống hay chết: nó có tự cập nhật không. Một bản kiểm kê PII chính xác tại thời điểm quét sẽ sai dần mỗi ngày sau đó, cho tới lúc không còn ai tin nó.

Đáp án

A và E — Index cho giá trị đơn theo thứ tự GIẢM DẦN, và index cho giá trị đơn theo thứ tự TĂNG DẦN.

Vì sao đúng

⚠ Firestore tự tạo index cho mỗi trường, theo CẢ HAI chiều:

⚠ Mỗi trường giá trị đơn (atomic)
        ↓ ⚠ TỰ ĐỘNG tạo
   ⚠ index TĂNG DẦN (ascending)
   ⚠ index GIẢM DẦN (descending)
        ↓
⚠ Truy vấn lọc hoặc sắp xếp theo
   MỘT trường chạy được ngay

⚠ Ngoài ra: ⚠ với trường mảng, ⚠ Firestore tạo array-contains index.

⚠ Index TỔNG HỢP (composite) thì KHÔNG tự tạo — ⚠ phải khai bằng tay.

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

• C (composite index, nhiều giá trị) và D (composite index, một giá trị) — ⚠ composite index KHÔNG tự động: ⚠ phải khai trong firestore.indexes.json ⚠ hoặc tạo từ link lỗi mà Firestore gợi ý.

• B (hash index) — ⚠ Firestore không dùng loại index này: ⚠ nó dùng index kiểu B-tree có thứ tự.

Ghi nhớ

⚠ Index trong Firestore — bảng phải thuộc: | Loại | Tự động | |---|---| | ⚠ Trường đơn, tăng dần | ⚠ CÓ | | ⚠ Trường đơn, giảm dần | ⚠ CÓ | | ⚠ Array-contains | ⚠ CÓ | | ⚠ Composite (nhiều trường) | ⚠ KHÔNG — phải khai |

Từ khoá nhận diện:

"index tự động trong Firestore" → ⚠ trường đơn, cả hai chiều "truy vấn nhiều trường bị lỗi" → ⚠ thiếu composite index "Bigtable có index phụ không" → ⚠ KHÔNG có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dung lượng index chiếm bao nhiêu so với dữ liệu | | | Có trường lớn nào bị đánh index vô ích không | ⚠ khai exemption | | Composite index đã khai trong mã nguồn chưa | ⚠ đừng chỉ tạo tay trên Console |

Và đặc tính khiến Firestore rất khác các CSDL khác: truy vấn nhanh chậm phụ thuộc số kết quả trả về, không phụ thuộc tổng lượng dữ liệu. Đổi lại, mọi mẫu truy vấn phải có index tương ứng — không có đường tắt quét bảng.

Đáp án

A — Tạo một schema và gán nó cho TOPIC khi tạo topic.

Vì sao đúng

⚠ Schema của Pub/Sub gắn với TOPIC, không gắn với subscription:

⚠ Publisher gửi tin nhắn
        ↓
⚠ Pub/Sub KIỂM TRA theo schema
   của TOPIC
        ↓
⚠ Không khớp → ⚠ TỪ CHỐI ngay
   lúc publish
        ↓
⚠ Chỉ tin nhắn HỢP LỆ vào được hệ thống

⚠ Vì sao phải ở topic: ⚠ topic là cửa VÀO; ⚠ chặn ở cửa vào thì ⚠ mọi subscriber đều được bảo vệ.

⚠ Lưu ý: ⚠ schema phải gán lúc TẠO topic — ⚠ topic đã có không gán thêm được.

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

• C (gán schema cho subscription) — ⚠ bẫy gần nhất: ⚠ subscription là cửa RA; ⚠ tin nhắn sai đã nằm trong hệ thống rồi, ⚠ và ⚠ Pub/Sub không hỗ trợ schema ở mức subscription.

• B (dùng Cloud Function kiểm tra cấu trúc khi ghi vào Pub/Sub) — ⚠ tự dựng lại tính năng có sẵn: ⚠ thêm độ trễ, thêm chi phí, thêm chỗ hỏng; ⚠ và ⚠ publisher vẫn có thể đi vòng qua hàm đó.

• D (Cloud Function định dạng lại tin nhắn trước khi đọc từ subscription) — ⚠ sửa triệu chứng ở cuối đường ống: ⚠ mỗi subscriber phải tự làm lại.

Ghi nhớ

⚠ Schema trong Pub/Sub — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Gán ở đâu | ⚠ TOPIC, lúc TẠO | | ⚠ Định dạng hỗ trợ | ⚠ Protocol Buffer và Avro | | ⚠ Mã hoá | ⚠ BINARY hoặc JSON | | ⚠ Có phiên bản | ⚠ schema revision, tiến hoá được | | ⚠ Tin nhắn không khớp | ⚠ bị từ chối ngay lúc publish |

Từ khoá nhận diện:

"đảm bảo tin nhắn đúng cấu trúc" → ⚠ schema gán cho TOPIC "định dạng schema Pub/Sub hỗ trợ" → ⚠ Protobuf và Avro "tin nhắn lỗi lặp mãi" → ⚠ dead-letter topic "giữ đúng thứ tự" → ⚠ ordering key

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Topic đã có schema chưa | ⚠ gán được LÚC TẠO thôi | | Publisher xử lý lỗi từ chối thế nào | | | Có kế hoạch tiến hoá schema chưa | |

Và giới hạn cần biết trước khi thiết kế: schema chỉ gán được lúc tạo topic. Nghĩ tới nó sau khi topic đã chạy trong sản xuất nghĩa là phải tạo topic mới và chuyển toàn bộ publisher lẫn subscriber sang.

Đáp án

B — Dùng Cloud Logging, đặt Log Router tạo sink sang Cloud Storage để giữ log 60 ngày, kèm chính sách vòng đời dữ liệu xoá log sau 60 ngày.

Vì sao đúng

⚠ Đề có hai yêu cầu: | Yêu cầu | Cách giải | |---|---| | ⚠ Giữ log ứng dụng 60 ngày | ⚠ sink sang Cloud Storage + lifecycle 60 ngày | | ⚠ Truy cập log từ công cụ BÊN THỨ BA | ⚠ Cloud Storage đọc được từ mọi nơi |

⚠ Cloud Logging
        ↓ ⚠ Log Router (sink)
⚠ Cloud Storage bucket
        ↓ ⚠ Object Lifecycle Management
⚠ Tự động xoá sau 60 ngày

⚠ Vì sao Cloud Storage là đích đúng: ⚠ rẻ nhất cho lưu trữ, ⚠ lifecycle policy có sẵn, ⚠ công cụ bên ngoài truy cập dễ.

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

• C (đưa log qua Pub/Sub topic rồi tự ghi vào Cloud Storage) — ⚠ thêm một chặng không cần thiết: ⚠ Log Router ghi thẳng vào Cloud Storage được; ⚠ Pub/Sub chỉ cần khi ⚠ đưa log tới hệ thống bên ngoài thời gian thực.

• D (sink sang Bigtable) — ⚠ Log Router KHÔNG hỗ trợ Bigtable làm đích: ⚠ đích hợp lệ là Cloud Storage, BigQuery, Pub/Sub, Logging bucket.

• A (giữ log trong Cloud Firestore) — ⚠ Firestore không phải đích của Log Router: ⚠ và ⚠ CSDL tài liệu là nơi đắt đỏ để chứa log.

Ghi nhớ

⚠ Bốn đích của Log Router — bảng phải thuộc: | Đích | Dùng cho | |---|---| | ⚠ Cloud Storage | ⚠ lưu trữ dài hạn, giá rẻ — đề này | | ⚠ BigQuery | ⚠ phân tích log bằng SQL | | ⚠ Pub/Sub | ⚠ đẩy sang hệ thống ngoài, thời gian thực (SIEM) | | ⚠ Logging bucket khác | ⚠ đổi thời hạn lưu, tách theo phạm vi | | ⚠ KHÔNG phải đích | ⚠ Bigtable, Firestore, Spanner |

Từ khoá nhận diện:

"giữ log N ngày, giá rẻ" → ⚠ sink Cloud Storage + lifecycle "phân tích log bằng SQL" → ⚠ sink BigQuery "đưa vào SIEM tại chỗ" → ⚠ sink Pub/Sub → Dataflow → SIEM "chỉ cần đổi thời hạn lưu" → ⚠ đổi retention của Logging bucket, không cần sink

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Service account của sink đã có quyền ghi chưa | | | Lifecycle policy có thật sự chạy không | ⚠ kiểm tra dung lượng bucket theo thời gian | | Sink tạo trước hay sau khi cần log | ⚠ không hồi tố được |

Và sự thật khó chịu nhất về log: sink không hồi tố. Ngày bạn cần log của tháng trước để điều tra sự cố cũng chính là ngày bạn phát hiện mình chưa bao giờ cấu hình việc lưu chúng.

Đáp án

B và E — Protocol Buffer và Avro.

Vì sao đúng

⚠ Pub/Sub chỉ hỗ trợ ĐÚNG HAI định dạng schema: | Định dạng | Đặc điểm | |---|---| | ⚠ Protocol Buffer (protobuf) | ⚠ của Google, nhị phân, rất gọn, sinh mã cho nhiều ngôn ngữ | | ⚠ Avro | ⚠ của Apache, schema đi kèm dữ liệu, mạnh về tiến hoá schema |

⚠ Cả hai đều là định dạng SERIALIZE có schema — ⚠ đúng thứ cần cho việc tách rời hai dịch vụ như đề nêu.

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

• A (Parquet) — ⚠ định dạng lưu trữ theo CỘT: ⚠ dùng cho phân tích trên tệp lớn, ⚠ không phải cho tin nhắn đơn lẻ.

• C (CSV) — ⚠ không có schema thật sự: ⚠ chỉ là văn bản phân tách; ⚠ không có kiểu dữ liệu, không có cấu trúc lồng nhau.

• D (Thrift) — ⚠ của Apache, tương tự protobuf, ⚠ nhưng ⚠ Pub/Sub KHÔNG hỗ trợ.

Ghi nhớ

⚠ Định dạng dữ liệu — bảng phải thuộc: | Định dạng | Dùng cho | |---|---| | ⚠ Protobuf | ⚠ tin nhắn, RPC (gRPC) — nhỏ và nhanh | | ⚠ Avro | ⚠ tin nhắn và tệp, tiến hoá schema tốt | | ⚠ Parquet | ⚠ lưu trữ phân tích, kho cột | | ⚠ ORC | ⚠ tương tự Parquet, hệ sinh thái Hive | | ⚠ JSON | ⚠ dễ đọc, tốn chỗ, không có schema bắt buộc | | ⚠ CSV | ⚠ đơn giản nhất, dễ hỏng nhất |

Từ khoá nhận diện:

"schema cho Pub/Sub" → ⚠ Protobuf hoặc Avro "định dạng cột cho phân tích" → ⚠ Parquet, ORC "nạp vào BigQuery nhanh nhất" → ⚠ Avro (nén tốt, song song được) "dễ đọc bằng mắt" → ⚠ JSON, CSV

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường ống có đang dùng CSV cho dữ liệu quan trọng không | | | Schema có được quản lý ở đâu tập trung không | | | Tiến hoá schema có kế hoạch chưa | |

Và lý do định dạng có schema đáng giá hơn nó có vẻ: nó biến một lỗi dữ liệu thầm lặng thành một lỗi ồn ào. Với CSV, một cột bị lệch chỉ lộ ra ba tuần sau, trong một báo cáo mà không ai kịp nghi ngờ.

Đáp án

D — Cloud Firestore.

Vì sao đúng

⚠ MongoDB là CSDL TÀI LIỆU → ⚠ dịch vụ được quản tương đương trên Google Cloud là ⚠ Firestore.

⚠ Cùng mô hình dữ liệu nghĩa là ⚠ việc thiết kế lại ít nhất.

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

• B (Cloud SQL) — ⚠ CSDL QUAN HỆ: ⚠ chuyển từ tài liệu sang quan hệ đòi ⚠ thiết kế lại lược đồ hoàn toàn.

• A (Cloud Bigtable) — ⚠ NoSQL cột rộng, không phải tài liệu: ⚠ chỉ truy vấn được bằng row key, ⚠ mô hình rất khác MongoDB.

• C (BigQuery) — ⚠ kho PHÂN TÍCH: ⚠ không phải CSDL vận hành cho ứng dụng.

Ghi nhớ

⚠ Di trú CSDL sang Google Cloud — bảng phải thuộc: | Nguồn | Đích | |---|---| | ⚠ MongoDB | ⚠ Firestore (hoặc MongoDB Atlas trên Google Cloud) | | ⚠ MySQL, PostgreSQL, SQL Server | ⚠ Cloud SQL | | ⚠ Oracle | ⚠ Cloud SQL/Spanner hoặc chạy trên Compute Engine | | ⚠ Cassandra, HBase | ⚠ Bigtable | | ⚠ Redis, Memcached | ⚠ Memorystore | | ⚠ Teradata, Redshift, Snowflake | ⚠ BigQuery |

Từ khoá nhận diện:

"MongoDB" → ⚠ Firestore "cần quan hệ nhưng quy mô toàn cầu" → ⚠ Spanner "MySQL nhưng cần co giãn hơn" → ⚠ AlloyDB hoặc Spanner "chỉ cần bộ nhớ đệm" → ⚠ Memorystore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có truy vấn nào Firestore không làm được không | ⚠ kiểm trước khi cam kết di trú | | Có phụ thuộc aggregation pipeline của MongoDB không | | | Chi phí ước tính theo số lần đọc/ghi là bao nhiêu | ⚠ Firestore tính theo thao tác |

Và bước phải làm trước mọi cuộc di trú cơ sở dữ liệu: liệt kê mọi mẫu truy vấn ứng dụng đang dùng. Cùng mô hình dữ liệu không có nghĩa là cùng khả năng truy vấn, và phát hiện điều đó giữa chừng là lúc đắt nhất.

Đáp án

B — Tạo bucket cách ly để tải lên; khi có tệp mới thì kích hoạt Cloud Function gọi DLP API dùng infoType để phát hiện PII; phát hiện thì chuyển tệp sang bucket Classified Data.

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 ở lô trước (#15825).

Vì sao đúng

⚠ Đề nhấn chữ "NGAY LẬP TỨC" (immediately):

⚠ Tệp được tải lên bucket cách ly
        ↓ ⚠ SỰ KIỆN, tức thì
⚠ Cloud Function chạy
        ↓
⚠ Gọi DLP API với infoType
        ↓
⚠ Có PII → ⚠ chuyển sang
   Classified Data bucket

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

• D (Cloud Scheduler chạy mỗi giờ, gọi DLP API) — ⚠ DLP đúng nhưng KHÔNG tức thì: ⚠ tệp có PII nằm ở bucket cách ly ⚠ tới một giờ.

• C (kích hoạt bằng sự kiện nhưng gọi mô hình ML TỰ HUẤN LUYỆN) — ⚠ cơ chế đúng, công cụ sai: ⚠ tự xây mô hình phát hiện PII là ⚠ tốn công vô ích khi DLP đã có hơn 150 infoType sẵn.

• A (Cloud Scheduler mỗi giờ + mô hình ML tự xây) — ⚠ sai cả hai vế.

Ghi nhớ

⚠ Kích hoạt theo sự kiện so với theo lịch — bảng phải thuộc: | Yêu cầu | Cách | |---|---| | ⚠ "ngay lập tức", "khi tệp được tải lên" | ⚠ Cloud Storage trigger / Eventarc | | ⚠ "mỗi giờ", "hằng đêm", "định kỳ" | ⚠ Cloud Scheduler | | ⚠ "khi có tin nhắn" | ⚠ Pub/Sub trigger | | ⚠ Đề nhấn tính tức thì | ⚠ mọi phương án dùng Scheduler đều SAI |

Từ khoá nhận diện:

"ngay khi tệp được tải lên" → ⚠ trigger sự kiện, không phải scheduler "phát hiện PII" → ⚠ DLP API, đừng tự xây mô hình "phân loại tự động rồi chuyển chỗ" → ⚠ Cloud Function + Storage API

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tệp nằm ở bucket cách ly bao lâu | ⚠ đó là cửa sổ rủi ro | | Hàm lỗi thì tệp đi đâu | | | Ai đọc được bucket cách ly | ⚠ phải rất ít người |

Và nhánh mà hầu hết thiết kế kiểu này bỏ quên: tệp mà việc quét thất bại. Nếu nó im lặng nằm lại ở bucket cách ly mà không ai được báo, thì lớp bảo vệ đó có lỗ mà không ai biết.