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

Câu 41 Data management

You work for a game developer that is using Cloud Firestore and needs to regularly create backups. You'd like to issue a command and have it return immediately while the backup runs in the background. You want the backup file to be stored in a Cloud Storage bucket named game-ds-backup. What command would you use?

A gsutil datastore export gs://game-ds-backup
B gcloud datastore backup gs://game-ds-backup
C gsutil datastore export gs://game-ds-backup --async
D gcloud datastore export gs://game-ds-backup --async

Xem giải thích

Đáp án

D — gcloud datastore export gs://game-ds-backup --async.

Vì sao đúng

⚠ Ba phần của câu trả lời: | Phần | Vì sao | |---|---| | ⚠ gcloud | ⚠ CLI điều khiển dịch vụ; gsutil chỉ làm việc với Cloud Storage | | ⚠ datastore export | ⚠ động từ đúng — Firestore ở Datastore mode dùng nhóm lệnh này | | ⚠ --async | ⚠ trả về NGAY, việc chạy nền — đúng yêu cầu đề |

gcloud datastore export gs://game-ds-backup --async
        ↓
⚠ Lệnh trả về ngay kèm mã operation
        ↓
⚠ Theo dõi bằng
   gcloud datastore operations list

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

C (gsutil datastore export ... --async) — ⚠ gsutil KHÔNG điều khiển Datastore: ⚠ nó chỉ thao tác với Cloud Storage.
B (gcloud datastore backup ...) — ⚠ động từ sai VÀ thiếu --async: ⚠ lệnh đúng là export, không phải backup.
A (gsutil datastore export ...) — ⚠ sai cả CLI lẫn thiếu --async.

Ghi nhớ

⚠ Sao lưu Firestore/Datastore — bảng phải thuộc: | Lệnh | Việc | |---|---| | ⚠ gcloud datastore export gs://bucket | ⚠ xuất dữ liệu (Datastore mode) | | ⚠ gcloud datastore import gs://bucket/... | ⚠ nhập lại | | ⚠ gcloud firestore export gs://bucket | ⚠ cho Native mode | | ⚠ gcloud datastore operations list | ⚠ theo dõi tiến độ | | ⚠ Cờ --async | ⚠ trả về ngay, không chờ |

Từ khoá nhận diện:

"trả về ngay, chạy nền" → ⚠ --async "sao lưu Firestore" → ⚠ export sang Cloud Storage "thao tác với bucket" → ⚠ gsutil hoặc gcloud storage "điều khiển dịch vụ" → ⚠ gcloud

⚠ Điều phải nhớ về export Firestore	Điều
⚠ KHÔNG phải ảnh chụp tại một thời điểm	⚠ dữ liệu ghi trong lúc export có thể không nhất quán
⚠ Tính phí theo số thực thể đọc	⚠ export bảng lớn tốn tiền
⚠ Import ghi ĐÈ theo khoá	⚠ không xoá dữ liệu đang có
⚠ Export/import cùng chế độ	⚠ Native không import vào Datastore mode
⚠ Muốn nhất quán	⚠ dừng ghi, hoặc chấp nhận sai lệch nhỏ

⚠ Cờ `--async` — dùng ở đâu	Dùng ở đâu
⚠ Thao tác chạy lâu	⚠ export, import, tạo cụm, di trú
⚠ Trong script tự động	⚠ không muốn chặn tiến trình
⚠ Theo dõi bằng `operations describe`
⚠ Không có `--async`	⚠ terminal treo tới khi xong — hỏng nếu mất kết nối

⚠ Chiến lược sao lưu Firestore	Chiến lược
⚠ Export định kỳ bằng Cloud Scheduler + Cloud Function
⚠ Lưu ở bucket TÁCH BIỆT, quyền riêng
⚠ Lifecycle xoá bản cũ
⚠ Định kỳ THỬ import vào project thử nghiệm	⚠ kiểm chứng bản sao lưu dùng được
⚠ Firestore cũng có	⚠ point-in-time recovery cho 7 ngày gần nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản sao lưu gần nhất là bao giờ | | | Đã thử import lại chưa | ⚠ bước hay bị bỏ qua nhất | | Bucket sao lưu có tách quyền khỏi production không | |

Và điều cần nhớ về export của Firestore mà nhiều người hiểu nhầm: nó không phải ảnh chụp nhất quán tại một thời điểm. Nếu ứng dụng vẫn đang ghi, bản sao lưu có thể chứa trạng thái của các thực thể ở những thời điểm hơi khác nhau.

Câu 42 Compliance

A team of socio-economic researchers is analyzing documents as part of a research study. The documents have had personally identifying information redacted. The researchers are concerned that someone with access to the data may be able to use quasi-identifiers, such as age and postal code, to re-identify some individuals. How can the researchers quantify that risk?

A Run a custom machine learning model trained to estimate the re-identification risk.
B Apply the re-identification infotype to each document with quasi-identifiers to calculate the level of risk.
C Use counts of the number of occurrences of quasi-identifiers identified using Data Loss Prevention infotypes.
D Run a re-identification risk analysis using the Data Loss Prevention service.

Xem giải thích

Đáp án

D — Chạy phân tích rủi ro tái định danh (re-identification risk analysis) bằng dịch vụ Data Loss Prevention.

Vì sao đúng

⚠ Vấn đề đề nêu: PII đã bị che, ⚠ nhưng ⚠ các bán định danh (quasi-identifier) như tuổi + mã bưu chính vẫn có thể ghép lại để nhận ra người cụ thể.

⚠ Tuổi = 34
⚠ Mã bưu chính = 70000
⚠ Giới tính = nữ
        ↓
⚠ Chỉ có 1 người khớp cả ba
        ↓
⚠ TÁI ĐỊNH DANH thành công
   dù đã che tên và số căn cước

⚠ DLP có sẵn công cụ ĐO rủi ro này — ⚠ không phải tự xây gì.

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

C (đếm số lần xuất hiện của các bán định danh) — ⚠ gần đúng về ý tưởng nhưng thô sơ: ⚠ đếm thủ công không cho ra thước đo chuẩn; ⚠ DLP đã có phép đo chính thức.
B (áp "re-identification infoType" cho từng tài liệu) — ⚠ KHÔNG có infoType tên như vậy: ⚠ infoType để phát hiện dữ liệu, ⚠ không phải đo rủi ro.
A (tự huấn luyện mô hình ML ước lượng rủi ro) — ⚠ tốn công vô ích: ⚠ đây là bài toán thống kê có công thức rõ ràng, ⚠ không cần học máy.

Ghi nhớ

⚠ Bốn phép đo rủi ro tái định danh của DLP — bảng phải thuộc: | Phép đo | Ý nghĩa | |---|---| | ⚠ k-anonymity | ⚠ mỗi tổ hợp bán định danh xuất hiện ít nhất k lần | | ⚠ l-diversity | ⚠ mỗi nhóm có ít nhất l giá trị nhạy cảm khác nhau | | ⚠ k-map | ⚠ ước lượng dựa trên dân số thống kê bên ngoài | | ⚠ δ-presence | ⚠ xác suất một người có mặt trong tập dữ liệu |

Từ khoá nhận diện:

"đo rủi ro tái định danh" → ⚠ DLP risk analysis "tìm dữ liệu nhạy cảm" → ⚠ DLP inspection với infoType "che hoặc biến đổi dữ liệu" → ⚠ DLP de-identification "tuổi, mã bưu chính, giới tính" → ⚠ bán định danh — nguy hiểm khi ghép

⚠ k-anonymity — hiểu bằng ví dụ	Ví dụ
⚠ k = 1	⚠ có người là DUY NHẤT — nhận ra được ngay
⚠ k = 5	⚠ mỗi tổ hợp có ít nhất 5 người — khó chỉ đích danh
⚠ k càng cao càng an toàn	⚠ nhưng dữ liệu càng ít hữu dụng
⚠ Cách tăng k	⚠ gom nhóm: tuổi thành khoảng, mã bưu chính bớt số cuối

⚠ Vì sao che PII trực tiếp là chưa đủ	Lý do
⚠ Nghiên cứu kinh điển: ngày sinh + giới tính + mã bưu chính	⚠ định danh được phần lớn dân số Mỹ
⚠ Ghép với dữ liệu công khai khác là ra tên
⚠ Dữ liệu hiếm gặp tự nó là định danh	⚠ một nghề nghiệp hiếm trong một xã
⚠ Kết luận	⚠ ẩn danh là một PHỔ, không phải trạng thái có/không

⚠ Kỹ thuật giảm rủi ro tái định danh	Kỹ thuật
⚠ Gom nhóm (bucketing)	⚠ tuổi 34 → nhóm 30–39
⚠ Tổng quát hoá mã bưu chính	⚠ 70000 → 70xxx
⚠ Chặn giá trị cực đoan	⚠ tuổi trên 90 gộp thành "90+"
⚠ Thêm nhiễu (differential privacy)
⚠ Luôn đánh đổi	⚠ riêng tư hơn ↔ dữ liệu kém chi tiết hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giá trị k thấp nhất trong tập dữ liệu là bao nhiêu | ⚠ k=1 là báo động đỏ | | Có bao nhiêu bản ghi duy nhất | | | Dữ liệu sau khi gom nhóm còn dùng được không | |

Và điều làm ẩn danh hoá khó hơn người ta tưởng: không có thông tin nào tự nó là định danh, nhưng đủ nhiều mẩu ghép lại thì luôn là. Xoá tên chỉ là bước đầu tiên, và thường là bước dễ nhất.

Câu 43 Access control

You are developing a data pipeline that will run several data transformation programs on Compute Engine virtual machines. You do not want to use your credentials for authenticating and authorizing these programs. You want to follow Google Cloud recommended practices, how would you authenticate and authorize the data transformation programs?

A Create a service account and assign roles to the service account that are needed to execute the data transformation programs. Use Secret Manager to store service account keys.
B Create a Gmail account and use that account to create an IAM user. Store the password for the account in Secret Manager.
C Create a Gmail account and use that account to create an IAM group. Store the password for the group in Secret Manager.
D Create a service account and assign roles to the service account that are needed to execute the data transformation programs. Use Google managed keys to store both public and private portion of the service account keys.

Xem giải thích

Đáp án

D — Tạo service account, gán các vai trò cần thiết cho chương trình biến đổi dữ liệu, và dùng khoá do Google quản lý.

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

⚠ Phương án đúng diễn đạt vụng.

Vế	Nội dung
⚠ Đề viết	⚠ "Google managed keys để lưu cả phần công khai và riêng tư của khoá service account"
⚠ Ý thật sự	⚠ KHÔNG tải file khoá về — để Google quản khoá, VM lấy token từ metadata
⚠ Đối lập với	⚠ phương án A: tải khoá về và lưu trong Secret Manager

⚠ KHÔNG sửa khoá — ⚠ nguyên tắc đằng sau là đúng: ⚠ khoá do người dùng quản là thứ nên tránh.

Vì sao đúng

⚠ Thực hành Google khuyến nghị:

⚠ Tạo service account
        ↓
⚠ Gán ĐÚNG vai trò cần thiết
        ↓
⚠ GẮN service account vào VM
        ↓
⚠ Chương trình lấy token từ
   metadata server
        ↓
⚠ KHÔNG có file khoá nào tồn tại

⚠ Không có khoá thì không có gì để lộ, để xoay vòng, hay để quên xoá.

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

A (service account + lưu khoá trong Secret Manager) — ⚠ bẫy tinh vi nhất: ⚠ Secret Manager tốt hơn nhiều so với để khoá trên đĩa, ⚠ nhưng ⚠ vẫn tạo ra một khoá dài hạn không hết hạn; ⚠ với VM trên Google Cloud thì ⚠ không cần khoá nào cả.
B (tạo tài khoản Gmail làm IAM user, lưu mật khẩu trong Secret Manager) — ⚠ dùng tài khoản NGƯỜI cho chương trình: ⚠ sai nguyên tắc; ⚠ người đó nghỉ việc là hỏng, ⚠ audit log ghi nhầm chủ thể.
C (tài khoản Gmail làm IAM group, lưu mật khẩu của group) — ⚠ group KHÔNG đăng nhập được: ⚠ group không có mật khẩu.

Ghi nhớ

⚠ Thứ tự ưu tiên cách xác thực workload — bảng phải thuộc: | Ưu tiên | Cách | |---|---| | ⚠ 1. Service account GẮN vào tài nguyên | ⚠ VM, GKE, Cloud Run — TỐT NHẤT | | ⚠ 2. Workload Identity Federation | ⚠ cho workload NGOÀI Google Cloud | | ⚠ 3. Mạo danh service account | ⚠ --impersonate-service-account | | ⚠ 4. File khoá + Secret Manager | ⚠ CUỐI CÙNG, chỉ khi bắt buộc | | ⚠ Không bao giờ | ⚠ tài khoản người thật cho chương trình |

Từ khoá nhận diện:

"chương trình chạy trên VM cần xác thực" → ⚠ service account gắn vào VM "lưu khoá ở đâu cho an toàn" → ⚠ câu hỏi sai — đừng tạo khoá "chạy ngoài Google Cloud" → ⚠ Workload Identity Federation

⚠ Vì sao file khoá service account nguy hiểm	Lý do
⚠ KHÔNG hết hạn
⚠ Dùng được từ bất kỳ đâu trên Internet
⚠ Dễ lọt vào Git, log, ảnh chụp
⚠ Khó biết đã bị dùng ở đâu
⚠ Chính sách tổ chức	⚠ `iam.disableServiceAccountKeyCreation` chặn hẳn

⚠ Nguyên tắc quyền tối thiểu cho service account	Nguyên tắc
⚠ MỖI workload một service account RIÊNG
⚠ KHÔNG dùng service account MẶC ĐỊNH của Compute Engine	⚠ nó có quyền Editor toàn project
⚠ Gán vai trò predefined hẹp nhất
⚠ Đặt scope của VM hợp lý	⚠ đừng để `cloud-platform`
⚠ Rà soát bằng IAM Recommender

⚠ Secret Manager vẫn dùng cho gì	Dùng cho
⚠ Mật khẩu CSDL bên thứ ba
⚠ Khoá API của dịch vụ ngoài
⚠ Chứng chỉ, khoá mã hoá ứng dụng
⚠ KHÔNG cần cho	⚠ xác thực với chính Google Cloud từ trong Google Cloud

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM có đang dùng service account mặc định không | | | Có file khoá JSON nào tồn tại không | | | Mỗi workload có service account riêng không | |

Và cách hiểu gọn nhất về toàn bộ chủ đề này: khoá tốt nhất là khoá không tồn tại. Mọi câu hỏi về việc lưu khoá ở đâu cho an toàn đều nên bắt đầu bằng việc hỏi liệu có cần khoá đó hay không.

Câu 44 Chọn nhiều đáp án Data management

You are in the process of creating lifecycle policies to manage objects stored in Cloud storage. Which of the following are lifecycle conditions you can use in your policies? (Choose 3)

A Age
B Is Live
C File size
D File type
E Matches Storage Class

Xem giải thích

Đáp án

A, B và E — Age (tuổi), Is Live (là phiên bản hiện hành), và Matches Storage Class (khớp lớp lưu trữ).

Vì sao đúng

⚠ Lifecycle của Cloud Storage làm việc với SIÊU DỮ LIỆU, không đọc nội dung: | Điều kiện | Ý nghĩa | |---|---| | ⚠ Age | ⚠ object đã tồn tại bao nhiêu ngày | | ⚠ Is Live | ⚠ là phiên bản hiện hành hay phiên bản cũ (noncurrent) | | ⚠ Matches Storage Class | ⚠ đang ở lớp Standard, Nearline, Coldline hay Archive | | ⚠ Created Before | ⚠ tạo trước một ngày cụ thể | | ⚠ Number of Newer Versions | ⚠ có bao nhiêu phiên bản mới hơn | | ⚠ Matches Prefix / Suffix | ⚠ theo TÊN object |

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

C (kích thước tệp) — ⚠ KHÔNG phải điều kiện lifecycle: ⚠ dù kích thước là siêu dữ liệu, ⚠ Cloud Storage không cho lọc theo nó trong lifecycle.
D (loại tệp) — ⚠ KHÔNG có điều kiện theo kiểu MIME: ⚠ chỉ lọc được theo hậu tố tên (matchesSuffix), ⚠ khác hẳn với "loại tệp".

Ghi nhớ

⚠ Hai hành động của lifecycle — bảng phải thuộc: | Hành động | Việc | |---|---| | ⚠ Delete | ⚠ xoá object | | ⚠ SetStorageClass | ⚠ chuyển sang lớp rẻ hơn | | ⚠ Chỉ có hai | ⚠ không có "nén", "di chuyển sang bucket khác", "gắn thẻ" |

Từ khoá nhận diện:

"xoá sau N ngày, chuyển lớp tự động" → ⚠ Object Lifecycle Management "xử lý theo NỘI DUNG file" → ⚠ KHÔNG phải lifecycle — cần DLP + Cloud Function "chuyển sang bucket khác" → ⚠ lifecycle KHÔNG làm được

⚠ Quy tắc lifecycle điển hình	Quy tắc
⚠ Age > 30 → Nearline
⚠ Age > 90 → Coldline
⚠ Age > 365 → Archive
⚠ Age > 2555 → Delete	⚠ 7 năm
⚠ Is Live = false và có 3 phiên bản mới hơn → Delete	⚠ dọn phiên bản cũ

⚠ Bẫy chi phí của lifecycle	Bẫy
⚠ Mỗi lớp có THỜI GIAN LƯU TỐI THIỂU	⚠ Nearline 30, Coldline 90, Archive 365 ngày
⚠ Xoá hoặc chuyển lớp SỚM vẫn bị tính phí đủ
⚠ Chuyển liên tiếp qua nhiều lớp là tự phạt tiền
⚠ Cách đúng	⚠ đặt ngưỡng LỚN HƠN thời gian lưu tối thiểu

⚠ Điều phải nhớ về lifecycle	Điều
⚠ Chạy bất đồng bộ, có thể trễ tới 24 giờ
⚠ Không có xác nhận, không hoàn tác được
⚠ Bucket Lock CHẶN được cả lifecycle xoá sớm
⚠ Nhiều quy tắc thì tất cả đều được xét	⚠ hành động xoá thắng chuyển lớp
⚠ Trước khi bật	⚠ thử trên bucket không quan trọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngưỡng có lớn hơn thời gian lưu tối thiểu không | | | Có quy tắc nào xoá dữ liệu còn cần không | ⚠ không hoàn tác được | | Versioning có bật không | ⚠ nếu có thì cần quy tắc dọn phiên bản cũ |

Và điều làm lifecycle vừa hữu ích vừa nguy hiểm: nó làm việc âm thầm và không hỏi lại. Một quy tắc viết sai ngày sẽ xoá dữ liệu đúng như bạn bảo nó làm, và không có nút hoàn tác nào.

Câu 45 Data management

As a consultant to a multi-national company, you are tasked with helping design a service to support an inventory management system that is strongly consistent, supports SQL, and can scale to support hundreds of users in North America, Asia, and Europe. What Google Cloud service would you recommend for this service?

A Cloud Firestore
B Cloud Spanner
C Cloud SQL
D BigQuery

Xem giải thích

Đáp án

B — Cloud Spanner.

Vì sao đúng

⚠ Đề nêu bốn yêu cầu, chỉ Spanner thoả cả bốn: | Yêu cầu | Spanner | |---|---| | ⚠ Nhất quán MẠNH | ⚠ CÓ — nhất quán ngoại tại toàn cầu | | ⚠ Hỗ trợ SQL | ⚠ CÓ — SQL chuẩn ANSI | | ⚠ Co giãn | ⚠ CÓ — thêm node theo chiều ngang | | ⚠ Người dùng ở BA CHÂU LỤC | ⚠ CÓ — cấu hình multi-region |

⚠ Nhất quán mạnh + SQL + toàn cầu
        ↓
⚠ Đây chính là bài toán Spanner
   được tạo ra để giải
        ↓
⚠ Dùng TrueTime (đồng hồ nguyên tử
  và GPS) để sắp thứ tự giao dịch
  trên toàn cầu

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

C (Cloud SQL) — ⚠ bẫy gần nhất: ⚠ có SQL và nhất quán mạnh, ⚠ nhưng ⚠ chỉ co giãn theo chiều DỌC (máy to hơn), ⚠ và ⚠ read replica xuyên vùng là nhất quán CUỐI CÙNG.
A (Cloud Firestore) — ⚠ co giãn toàn cầu tốt nhưng KHÔNG có SQL đầy đủ: ⚠ không JOIN, ⚠ không truy vấn phân tích phức tạp.
D (BigQuery) — ⚠ kho PHÂN TÍCH, không phải CSDL vận hành: ⚠ độ trễ tính bằng giây, ⚠ không hợp cho hệ thống quản lý tồn kho theo giao dịch.

Ghi nhớ

⚠ Chọn CSDL quan hệ trên Google Cloud — bảng phải thuộc: | Nhu cầu | Dịch vụ | |---|---| | ⚠ Quan hệ, một vùng, quy mô vừa | ⚠ Cloud SQL | | ⚠ Quan hệ, hiệu năng cao hơn Postgres | ⚠ AlloyDB | | ⚠ Quan hệ, TOÀN CẦU, nhất quán mạnh | ⚠ Spanner — đề này | | ⚠ Phân tích khối lượng lớn | ⚠ BigQuery |

Từ khoá nhận diện:

"nhất quán mạnh + SQL + nhiều châu lục" → ⚠ Spanner "MySQL/PostgreSQL được quản" → ⚠ Cloud SQL "khối lượng lớn, không cần SQL" → ⚠ Bigtable "tài liệu linh hoạt" → ⚠ Firestore

⚠ Spanner — điều đặc biệt phải nhớ	Điều
⚠ Nhất quán ngoại tại (external consistency)	⚠ mạnh hơn cả serializable
⚠ TrueTime	⚠ đồng hồ nguyên tử + GPS ở mọi trung tâm dữ liệu
⚠ Co giãn NGANG	⚠ thêm node, không phải máy to hơn
⚠ SLA 99,999% với cấu hình multi-region	⚠ khoảng 5 phút mất kết nối mỗi năm
⚠ Interleaved table	⚠ đặt bảng con nằm cạnh bảng cha để JOIN nhanh

⚠ Đánh đổi khi chọn Spanner	Đánh đổi
⚠ CHI PHÍ cao	⚠ trả theo node, tối thiểu đáng kể
⚠ Cần thiết kế khoá chính cẩn thận	⚠ khoá tuần tự gây điểm nóng như Bigtable
⚠ Một số cú pháp SQL khác biệt
⚠ Chỉ chọn khi	⚠ thật sự cần quy mô toàn cầu — nếu không, Cloud SQL rẻ hơn nhiều

⚠ Cấu hình vùng của Spanner	Cấu hình
⚠ Regional	⚠ một vùng, SLA 99,99%, rẻ hơn
⚠ Multi-region	⚠ nhiều châu lục, SLA 99,999%, đắt hơn
⚠ Đề này	⚠ Bắc Mỹ, châu Á, châu Âu → phải multi-region

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần nhất quán mạnh xuyên châu lục không | ⚠ quyết định chi phí | | Khoá chính có gây điểm nóng không | | | Cloud SQL với read replica có đủ không | ⚠ rẻ hơn rất nhiều |

Và câu hỏi nên đặt trước khi chọn Spanner: hệ thống này có chịu được nhất quán cuối cùng không?. Nếu có, thì một kiến trúc rẻ hơn nhiều lần đang chờ; nếu không, thì Spanner gần như là lựa chọn duy nhất.

Câu 46 Databases

A global transportation company is using Cloud Spanner for managing shipping orders. They have migrated an Oracle database to Cloud Spanner with minimal changes and are experiencing similar performance problems with joins. In particular, a one-to-many join between an orders table and an order items table is not performing as needed. What would you recommend?

A Use interleaved hashes
B Use Cloud SQL for better join performance
C Use Cloud Bigtable for better join performance
D Use interleaved tables

Xem giải thích

Đáp án

D — Dùng bảng lồng nhau (interleaved tables).

Vì sao đúng

⚠ Interleaved table đặt dòng con NẰM VẬT LÝ CẠNH dòng cha:

⚠ Cách thường: hai bảng riêng
   ⚠ orders ở một nơi
   ⚠ order_items ở nơi khác
        ↓
⚠ JOIN phải đọc từ NHIỀU máy
   → ⚠ chậm

⚠ Interleaved:
   Orders(1)
     ├── OrderItems(1,1)
     ├── OrderItems(1,2)
   Orders(2)
     ├── OrderItems(2,1)
        ↓
⚠ JOIN đọc TẠI CHỖ, một lần
   → ⚠ nhanh hơn nhiều

⚠ Đúng cho quan hệ MỘT-NHIỀU như orders và order_items trong đề.

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

A (interleaved hashes) — ⚠ khái niệm KHÔNG tồn tại: ⚠ Spanner chỉ có interleaved TABLE.
B (dùng Cloud SQL để JOIN nhanh hơn) — ⚠ từ bỏ quy mô toàn cầu: ⚠ đề nói công ty toàn cầu, ⚠ Cloud SQL không co giãn ngang được.
C (dùng Bigtable để JOIN nhanh hơn) — ⚠ Bigtable KHÔNG có JOIN: ⚠ hoàn toàn không phải hướng giải.

Ghi nhớ

⚠ Interleaved table — quy tắc phải thuộc: | Quy tắc | Nội dung | |---|---| | ⚠ Khoá chính bảng con PHẢI bắt đầu bằng khoá chính bảng cha | | | ⚠ Khai INTERLEAVE IN PARENT | ⚠ lúc TẠO bảng | | ⚠ ON DELETE CASCADE tuỳ chọn | ⚠ xoá cha là xoá con | | ⚠ Lồng được tới 7 cấp | | | ⚠ Không đổi được sau | ⚠ phải tạo lại bảng |

Từ khoá nhận diện:

"JOIN cha-con chậm trong Spanner" → ⚠ interleaved table "điểm nóng khi ghi trong Spanner" → ⚠ khoá chính tuần tự — dùng UUID hoặc bit-reverse "đọc không cần nhất quán tuyệt đối" → ⚠ stale read, nhanh hơn

⚠ Khi nào KHÔNG nên interleave	Khi nào
⚠ Bảng con rất lớn so với cha	⚠ một cha có hàng triệu con → split khó
⚠ Truy vấn thường không JOIN hai bảng đó
⚠ Bảng con được truy cập độc lập là chính
⚠ Giới hạn	⚠ tổng dữ liệu của một "cây" nên dưới vài GB

⚠ Tối ưu hiệu năng Spanner	Tối ưu
⚠ Interleaved table cho quan hệ cha-con
⚠ Secondary index cho truy vấn không theo khoá chính	⚠ Spanner CÓ index phụ, khác Bigtable
⚠ `STORING` clause để index chứa luôn cột cần	⚠ tránh phải đọc bảng gốc
⚠ Tránh khoá chính tuần tự	⚠ điểm nóng
⚠ Dùng stale read khi chấp nhận dữ liệu hơi cũ

⚠ Vì sao khoá chính tuần tự gây vấn đề	Lý do
⚠ Spanner chia dữ liệu theo KHOẢNG khoá	⚠ giống Bigtable
⚠ Khoá tăng dần → mọi ghi vào một split
⚠ Cách chữa	⚠ UUID, hoặc đảo bit của số tuần tự
⚠ Chủ đề lặp lại	⚠ cùng nguyên lý với row key Bigtable

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn có dùng query plan hiệu quả không | ⚠ xem execution plan | | Khoá chính có tuần tự không | | | Bảng con có quá lớn cho một cha không | |

Và điều đáng nhớ khi mang lược đồ Oracle nguyên vẹn sang Spanner: cùng SQL không có nghĩa là cùng cách lưu trữ. Spanner phân tán dữ liệu theo khoá, nên thiết kế khoá quyết định hiệu năng nhiều hơn mọi việc tối ưu truy vấn.

Câu 47 Data pipelines

You have developed a DoFn function for a Cloud Dataflow workflow. You discover that the PCollection does not have all the data needed to perform a necessary computation. You want to provide additional input each time an element of a PCollection is processed. What kind of Apache Beam construct would you use?

A Side input
B Watermark
C Partition
D Custom window

Xem giải thích

Đáp án

A — Side input.

Vì sao đúng

⚠ Side input cung cấp dữ liệu BỔ SUNG cho mỗi phần tử được xử lý:

⚠ PCollection chính
   (⚠ dữ liệu giao dịch)
        ↓ ⚠ DoFn xử lý từng phần tử
⚠ Cần thêm bảng tra cứu
   (⚠ tỉ giá, danh mục sản phẩm)
        ↓
⚠ SIDE INPUT
   ⚠ mọi worker đều truy cập được
   ⚠ trong lúc xử lý từng phần tử

Đặc điểm	Nội dung
⚠ Dạng	⚠ View của một PCollection khác
⚠ Dùng cho	⚠ bảng tra cứu, cấu hình, giá trị tổng hợp
⚠ Truy cập	⚠ trong `processElement` của DoFn

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

C (Partition) — ⚠ CHIA một PCollection thành nhiều phần: ⚠ không thêm dữ liệu vào.
D (custom window) — ⚠ nhóm phần tử theo thời gian: ⚠ không liên quan tới việc bổ sung dữ liệu.
B (watermark) — ⚠ ước lượng tiến độ thời gian sự kiện: ⚠ dùng để quyết định khi nào cửa sổ đóng, ⚠ không phải nguồn dữ liệu.

Ghi nhớ

⚠ Khái niệm Apache Beam — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | ⚠ PCollection | ⚠ tập dữ liệu phân tán | | ⚠ PTransform | ⚠ phép biến đổi | | ⚠ DoFn | ⚠ hàm xử lý từng phần tử (trong ParDo) | | ⚠ Side input | ⚠ dữ liệu bổ sung — đề này | | ⚠ Side output | ⚠ nhiều luồng ra từ một transform | | ⚠ Window | ⚠ nhóm theo thời gian | | ⚠ Watermark | ⚠ đã nhận đủ dữ liệu tới mốc nào | | ⚠ Trigger | ⚠ khi nào phát kết quả |

Từ khoá nhận diện:

"cần dữ liệu bổ sung khi xử lý mỗi phần tử" → ⚠ side input "tách luồng ra nhiều đích" → ⚠ side output / tagged output "chia dữ liệu thành nhiều tập" → ⚠ Partition "dữ liệu tới muộn" → ⚠ watermark + allowed lateness

⚠ Side input — lưu ý khi dùng	Lưu ý
⚠ Phải VỪA bộ nhớ của worker	⚠ không hợp với bảng rất lớn
⚠ Với streaming: side input CÓ THỂ cập nhật theo cửa sổ
⚠ Bảng lớn thì nên dùng CoGroupByKey thay vì side input
⚠ Ca dùng điển hình	⚠ bảng ánh xạ mã sang tên, ngưỡng cấu hình, tỉ giá

⚠ Side input so với CoGroupByKey	So sánh
⚠ Side input: một bên NHỎ, phát tới mọi worker
⚠ CoGroupByKey: cả hai bên LỚN, join theo khoá
⚠ Chọn sai	⚠ side input với bảng lớn gây hết bộ nhớ worker

⚠ Side output — cặp đôi hay bị lẫn	Đặc điểm
⚠ Một DoFn phát ra NHIỀU PCollection
⚠ Dùng TupleTag để gắn nhãn
⚠ Ca dùng: tách bản ghi hợp lệ và bản ghi lỗi	⚠ dead-letter pattern
⚠ Thực hành tốt	⚠ đừng để bản ghi lỗi làm chết cả pipeline

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Side input có vừa bộ nhớ worker không | | | Bản ghi lỗi được đưa đi đâu | ⚠ cần side output | | Side input có cần cập nhật theo thời gian không | |

Và mẫu thiết kế đáng học nhất trong Beam: dùng side output để tách bản ghi hỏng ra một luồng riêng. Một bản ghi xấu không nên có quyền làm sập một pipeline đang xử lý hàng triệu bản ghi tốt.

Câu 48 Compliance

To comply with industry regulations, you will need to capture logs of all changes made to IAM roles and identities. Logs must be kept for 3 years. How would you meet this requirement?

A
Use Cloud Audit Logs and keep the logs in Cloud Monitoring. Specify a three year retention policy in Cloud Logging that automatically deletes the logs after three years.
B Use Cloud Audit Logs and export them to Bigtable. Create a retention policy and retention policy lock to prevent the logs from being deleted prior to them reaching 3 years of age. Define a lifecycle policy to delete the logs after three years.
C
Use Cloud Audit Logs and keep the logs in Cloud Logging. Specify a three year retention policy in Cloud Logging that automatically deletes the logs after three years.
D Use Cloud Audit Logs and export them to Cloud Storage. Create a retention policy and retention policy lock to prevent the logs from being deleted prior to them reaching 3 years of age. Define a lifecycle policy to delete the logs after three years.

Xem giải thích

Đáp án

D — Dùng Cloud Audit Logs, xuất sang Cloud Storage, tạo retention policy và retention policy LOCK để không ai xoá được trước 3 năm, kèm lifecycle policy xoá sau 3 năm.

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

⚠ Câu này gần giống #16212 trong cùng lô nhưng KHÁC một điểm quyết định.

Câu	Yêu cầu thêm
⚠ #16212	⚠ giữ log 60 ngày — chỉ cần sink + lifecycle
⚠ #16233 (câu này)	⚠ TUÂN THỦ NGÀNH — cần CHỐNG XOÁ (retention lock)
⚠ Điểm khác	⚠ "comply with industry regulations" ⇒ phải có Bucket Lock

Vì sao đúng

⚠ Ba lớp bảo vệ trong phương án D:

⚠ Cloud Audit Logs
        ↓ ⚠ Log sink
⚠ Cloud Storage bucket
        ↓ ⚠ Retention policy: 3 năm
   ⚠ không xoá được trước hạn
        ↓ ⚠ Retention policy LOCK
   ⚠ KHÔNG GỠ được policy đó
   ⚠ kể cả người có quyền admin
        ↓ ⚠ Lifecycle
   ⚠ tự xoá sau 3 năm

⚠ Lock là điểm mấu chốt: ⚠ không có nó thì ⚠ admin (hoặc kẻ tấn công chiếm quyền admin) xoá log được.

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

C (giữ log trong Cloud Logging với retention 3 năm) — ⚠ làm được nhưng ĐẮT và KHÔNG chống xoá: ⚠ Logging tính phí lưu trữ cao hơn Cloud Storage nhiều; ⚠ và ⚠ không có cơ chế khoá kiểu Bucket Lock.
B (xuất sang Bigtable) — ⚠ Bigtable KHÔNG phải đích của Log Router: ⚠ và ⚠ không có retention lock.
A (giữ log trong Cloud Monitoring) — ⚠ Cloud Monitoring giữ CHỈ SỐ, không giữ log: ⚠ nhầm dịch vụ.

Ghi nhớ

⚠ Bucket Lock — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | ⚠ Retention policy | ⚠ object không xoá được trước N thời gian | | ⚠ Lock policy | ⚠ KHÔNG GỠ, KHÔNG GIẢM được nữa — VĨNH VIỄN | | ⚠ Tăng thời gian giữ | ⚠ vẫn làm được sau khi lock | | ⚠ Xoá bucket | ⚠ chỉ được khi mọi object đã hết hạn giữ | | ⚠ Cảnh báo | ⚠ lock là KHÔNG THỂ ĐẢO NGƯỢC — cân nhắc rất kỹ |

Từ khoá nhận diện:

"tuân thủ, không ai được xoá log" → ⚠ Bucket Lock (retention policy lock) "giữ log lâu, giá rẻ" → ⚠ sink sang Cloud Storage "phân tích log bằng SQL" → ⚠ sink sang BigQuery "WORM storage" → ⚠ write once read many = Bucket Lock

⚠ Bốn loại Audit Log — đề này cần loại nào	Loại
⚠ Admin Activity	⚠ thay đổi IAM nằm ở đây — LUÔN bật, không tắt được
⚠ Data Access	⚠ truy cập dữ liệu — mặc định TẮT
⚠ System Event
⚠ Policy Denied
⚠ Đề hỏi thay đổi vai trò IAM	⚠ Admin Activity — đã có sẵn

⚠ Vì sao phải xuất log ra ngoài Logging	Lý do
⚠ `_Required` chỉ giữ 400 ngày	⚠ không đủ 3 năm
⚠ Chi phí lưu trong Logging cao hơn
⚠ Logging KHÔNG có cơ chế chống xoá kiểu WORM
⚠ Kiểm toán viên thường muốn bằng chứng bất biến

⚠ Cân nhắc trước khi khoá retention policy	Cân nhắc
⚠ Không gỡ được — kể cả khi hết cần
⚠ Phải trả tiền lưu trữ suốt thời hạn
⚠ Lỡ ghi nhầm dữ liệu vào bucket là kẹt luôn
⚠ Thực hành	⚠ bucket riêng CHỈ để chứa log kiểm toán, không dùng chung

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sink đã tạo trước khi cần log chưa | ⚠ không hồi tố | | Retention policy đã lock chưa | | | Ai có quyền vào bucket log kiểm toán | ⚠ phải rất hạn chế |

Và lý do khoá thời hạn lưu trữ quan trọng hơn nghe có vẻ: kẻ tấn công thành công thường xoá log để che dấu vết. Một bản ghi mà chính admin cũng không xoá được là thứ duy nhất còn đáng tin sau một cuộc xâm nhập.

Câu 49 Databases

A developer is deploying a Cloud SQL database to production and wants to follow Google Cloud recommended best practices. What should the developer use for authentication?

A Cloud Identity
B Strong encryption
C IAM
D Cloud SQL Auth proxy

Xem giải thích

Đáp án

D — Cloud SQL Auth proxy.

Vì sao đúng

⚠ Cloud SQL Auth proxy là cách kết nối Google khuyến nghị:

⚠ Ứng dụng
        ↓ ⚠ kết nối tới proxy chạy CỤC BỘ
⚠ Cloud SQL Auth proxy
   ⚠ xác thực bằng IAM
   ⚠ mã hoá TLS tự động
        ↓
⚠ Cloud SQL instance

Lợi ích	Nội dung
⚠ Xác thực bằng IAM	⚠ không cần quản lý danh sách IP
⚠ Mã hoá TLS tự động	⚠ không phải tự quản chứng chỉ
⚠ Không cần IP công khai	⚠ giảm bề mặt tấn công
⚠ Không cần mở firewall theo IP	⚠ IP ứng dụng thay đổi cũng không sao

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

C (IAM) — ⚠ đúng một phần nhưng chưa đủ: ⚠ IAM là nền tảng mà proxy dựa vào, ⚠ nhưng ⚠ IAM một mình không giải quyết chuyện kết nối và mã hoá đường truyền; ⚠ đề hỏi dùng gì để xác thực khi kết nối.
A (Cloud Identity) — ⚠ quản danh tính NGƯỜI DÙNG của tổ chức: ⚠ không phải cơ chế kết nối CSDL.
B (mã hoá mạnh) — ⚠ không phải cơ chế xác thực: ⚠ mã hoá bảo vệ nội dung, ⚠ không xác định ai được kết nối.

Ghi nhớ

⚠ Cách kết nối Cloud SQL — bảng phải thuộc: | Cách | Đánh giá | |---|---| | ⚠ Cloud SQL Auth proxy | ⚠ KHUYẾN NGHỊ — IAM + TLS tự động | | ⚠ Private IP trong VPC | ⚠ tốt, kết hợp được với proxy | | ⚠ Public IP + danh sách IP cho phép | ⚠ phải tự quản, IP đổi là hỏng | | ⚠ Public IP không giới hạn | ⚠ KHÔNG BAO GIỜ |

Từ khoá nhận diện:

"kết nối Cloud SQL an toàn" → ⚠ Cloud SQL Auth proxy "không muốn IP công khai" → ⚠ private IP + proxy "đăng nhập CSDL bằng tài khoản Google" → ⚠ IAM database authentication "chỉ ứng dụng frontend gọi được CSDL" → ⚠ firewall rule với tag/service account

⚠ Cloud SQL IAM database authentication	Đặc điểm
⚠ Đăng nhập CSDL bằng danh tính IAM	⚠ không cần mật khẩu CSDL
⚠ Dùng được cho cả người dùng và service account
⚠ Bỏ được việc quản mật khẩu trong ứng dụng
⚠ Kết hợp với proxy	⚠ là cấu hình an toàn nhất

⚠ Thực hành bảo mật Cloud SQL	Thực hành
⚠ Dùng private IP, tắt public IP
⚠ Bật Cloud SQL Auth proxy
⚠ Bật sao lưu tự động và point-in-time recovery
⚠ Bật cấu hình HA nếu quan trọng
⚠ CMEK nếu cần kiểm soát khoá
⚠ Chính sách tổ chức `sql.restrictPublicIp`	⚠ cấm hẳn IP công khai toàn tổ chức

⚠ Proxy chạy ở đâu	Nơi chạy
⚠ Sidecar container trong GKE	⚠ phổ biến nhất
⚠ Tiến trình riêng trên VM
⚠ Tích hợp sẵn trong Cloud Run và App Engine
⚠ Quyền cần	⚠ vai trò `cloudsql.client` cho service account

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có IP công khai không | ⚠ nếu có thì vì sao | | Mật khẩu CSDL nằm ở đâu | ⚠ cân nhắc IAM auth để bỏ hẳn | | Sao lưu tự động đã bật chưa | |

Và cấu hình nguy hiểm mà vẫn rất phổ biến: Cloud SQL có IP công khai và danh sách IP cho phép là 0.0.0.0/0. Nó thường bắt đầu như một cách "để thử cho nhanh", rồi ở lại vĩnh viễn.

Câu 50 Data management

A multi-national financial services company is creating a new service to facilitate cross-currency transactions. The database must provide strong consistency for transactions that may be initiated by any customer. Customers are initially located in Europe but the company plans to expand to Asia, Africa, North America and South America within a year. The database must support normalized data models. What Google Cloud managed database service would you use?

A Cloud Bigtable
B BigQuery
C Cloud SQL
D Cloud Spanner

Xem giải thích

Đáp án

D — Cloud Spanner.

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

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

Câu	Bối cảnh
⚠ #16230	⚠ quản lý tồn kho, nhất quán mạnh, SQL, ba châu lục
⚠ #16235 (câu này)	⚠ giao dịch ngoại tệ, nhất quán mạnh, mô hình chuẩn hoá, mở rộng ra bốn châu lục
⚠ Cùng khoá	⚠ Spanner
⚠ Nhớ bộ ba từ khoá	⚠ nhất quán MẠNH + SQL/chuẩn hoá + TOÀN CẦU ⇒ Spanner

Vì sao đúng

⚠ Bốn yêu cầu của đề: | Yêu cầu | Spanner | |---|---| | ⚠ Nhất quán mạnh cho giao dịch | ⚠ nhất quán ngoại tại toàn cầu | | ⚠ Bất kỳ khách hàng nào cũng khởi tạo được | ⚠ ghi từ mọi vùng | | ⚠ Mở rộng ra bốn châu lục trong một năm | ⚠ multi-region | | ⚠ Mô hình dữ liệu CHUẨN HOÁ | ⚠ quan hệ, SQL, khoá ngoại |

⚠ Giao dịch ngoại tệ là ca dùng không cho phép sai lệch — ⚠ nhất quán cuối cùng là ⚠ không chấp nhận được với tiền.

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

C (Cloud SQL) — ⚠ không co giãn ngang và không đa vùng ghi được: ⚠ read replica xuyên vùng chỉ nhất quán cuối cùng; ⚠ mở rộng ra bốn châu lục là bất khả.
A (Cloud Bigtable) — ⚠ KHÔNG hỗ trợ mô hình chuẩn hoá, không có SQL đầy đủ, không có giao dịch nhiều dòng.
B (BigQuery) — ⚠ kho phân tích, không phải CSDL giao dịch.

Ghi nhớ

⚠ Nhất quán mạnh so với nhất quán cuối cùng — bảng phải thuộc: | Kiểu | Nghĩa | Dịch vụ | |---|---|---| | ⚠ Nhất quán MẠNH | ⚠ đọc luôn thấy ghi mới nhất | ⚠ Spanner, Cloud SQL (primary), Firestore | | ⚠ Nhất quán CUỐI CÙNG | ⚠ có độ trễ lan truyền | ⚠ Bigtable đa cụm, read replica xuyên vùng | | ⚠ Với tiền bạc | ⚠ LUÔN cần nhất quán mạnh |

Từ khoá nhận diện:

"giao dịch tài chính, toàn cầu, SQL" → ⚠ Spanner "một vùng, MySQL/PostgreSQL" → ⚠ Cloud SQL "phân tích lịch sử giao dịch" → ⚠ BigQuery "nhật ký giao dịch khối lượng cực lớn" → ⚠ Bigtable, nhưng không phải sổ cái

⚠ Vì sao nhất quán mạnh khó khi phân tán toàn cầu	Lý do
⚠ Ánh sáng mất thời gian đi giữa các châu lục	⚠ vật lý, không lách được
⚠ Phải đồng thuận giữa nhiều bản sao
⚠ Định lý CAP: mất mạng thì phải chọn nhất quán hoặc sẵn sàng
⚠ Spanner làm được nhờ	⚠ TrueTime — đồng hồ nguyên tử và GPS, sai số biết trước
⚠ Cái giá	⚠ độ trễ ghi cao hơn ở cấu hình multi-region

⚠ Thiết kế lược đồ Spanner cho tài chính	Thiết kế
⚠ Khoá chính KHÔNG tuần tự	⚠ UUID hoặc bit-reverse để tránh điểm nóng
⚠ Interleave bảng chi tiết vào bảng giao dịch
⚠ Secondary index cho truy vấn theo khách hàng
⚠ Dùng giao dịch đọc-ghi cho thao tác tiền
⚠ Tránh	⚠ giao dịch giữ lâu — gây tranh chấp khoá

⚠ Chi phí Spanner — cần lường trước	Chi phí
⚠ Trả theo node hoặc processing unit
⚠ Multi-region đắt hơn regional đáng kể
⚠ Có mức tối thiểu ngay cả khi tải thấp
⚠ Bắt đầu	⚠ processing unit cho phép khởi điểm nhỏ hơn một node đầy đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần ghi từ nhiều châu lục không | ⚠ hay chỉ cần ĐỌC ở nhiều nơi | | Khoá chính có tuần tự không | | | Đã ước tính chi phí multi-region chưa | |

Và điều đáng phân biệt trước khi chọn kiến trúc toàn cầu: đọc ở nhiều nơi rẻ hơn ghi ở nhiều nơi rất nhiều. Nếu khách hàng chỉ cần xem nhanh còn ghi thì tập trung, thì bài toán đã đơn giản đi hẳn một bậc.

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

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

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

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

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

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

Vì sao đúng

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

Ghi nhớ