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

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

Câu hỏi yêu cầu thiết kế một hệ thống phát hiện basket abandonment (giỏ hàng bị bỏ rơi) cho công ty thương mại điện tử sử dụng Google Cloud Dataflow (dựa trên Apache Beam). Hệ thống cần gửi thông báo dựa trên các quy tắc sau:
✅ Không có tương tác (interaction) nào từ người dùng trên site trong 1 giờ (60 phút).
✅ Người dùng đã thêm sản phẩm trị giá hơn $30 vào giỏ hàng.
✅ Chưa hoàn tất giao dịch (transaction).

📊 Dữ liệu đầu vào có lẽ là stream dữ liệu thời gian thực (như event add-to-basket, page views, purchases) từ nguồn như Pub/Sub hoặc Kafka. Pipeline Dataflow phải xử lý stream này để group events theo user, kiểm tra điều kiện, và quyết định gửi message (ví dụ qua Pub/Sub hoặc Cloud Functions).

🛠️ Thách thức chính: Cần một cơ chế windowing phù hợp để capture inactivity (không hoạt động) 60 phút, không phải fixed time mà phải dựa trên hành vi user (session-based). Điều này yêu cầu window tự động đóng khi user "im lặng" 60 phút, align với quy tắc abandonment.

(Lưu ý: Dù người dùng đề cập "liên quan đến AWS", câu hỏi thực tế thuộc Google Cloud Dataflow/Apache Beam, kiến thức cập nhật đến 2026 từ Apache Beam 2.58+ và Dataflow 2026 features hỗ trợ session windows hiệu quả hơn với watermarking và late data handling).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Use a session window with a gap time duration of 60 minutes.

🧠 Lý do chi tiết:

• Session window lý tưởng cho dữ liệu per-user (keyed by user ID), group các event gần nhau thành "session". Session bắt đầu với event đầu tiên, kết thúc khi gap inactivity đạt 60 phút – chính xác match quy tắc "no interaction for 1 hour".
• Trong session, pipeline tính tổng basket value (> $30?) và check chưa purchase. Nếu đúng, gửi message khi session end (trigger on window close).
• Hỗ trợ stream processing với watermark để handle out-of-order data, late events.
• ✅ Ưu điểm: Không lãng phí compute (chỉ process khi user thực sự inactive), scalable cho high-volume ecommerce traffic.

📘 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên text gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên Apache Beam windowing model (Dataflow sử dụng Beam runners).

• ❌ [SAI] Use a fixed-time window with a duration of 60 minutes.
  Giải thích sai: Fixed-time window (Tumbling window) chia dữ liệu thành các khoảng cố định 60 phút (ví dụ 10:00-11:00, 11:00-12:00), không align với thời điểm user inactive. User có thể active xuyên window boundary, hoặc inactive không đúng 60 phút toàn window → miss hoặc false positive abandonment. Không phù hợp cho per-user session.

• ❌ [SAI] Use a sliding time window with a duration of 60 minutes.
  Giải thích sai: Sliding window (hopping) overlap các fixed window 60 phút (ví dụ slide every 10 phút), vẫn dựa fixed alignment theo clock time. Vẫn không detect chính xác gap inactivity 60 phút per user, dẫn đến duplicate processing và high compute cost, không match quy tắc cá nhân hóa.

• ✅ [ĐÚNG] Use a session window with a gap time duration of 60 minutes.
  Giải thích đúng: Như trên, session window tự động merge events nếu gap <60 phút, end session khi gap >=60 phút → trigger check basket >$30 và no purchase. Hoàn hảo cho abandonment detection. Trong Beam: Window.into(SessionWindows.of(Duration.standardMinutes(60))).

• ❌ [SAI] Use a global window with a time based trigger with a delay of 60 minutes.
  Giải thích sai: Global window gom toàn bộ dữ liệu vào 1 window duy nhất (không bound time), trigger periodic mỗi 60 phút delay. Không group per-user, không detect inactivity gap → toàn bộ data process liên tục, không scalable, miss real-time abandonment (chỉ check batch sau 60 phút).

📚 Tài liệu tham khảo (cập nhật 2026)

• Apache Beam Documentation: Session Windows (Beam 2.58+, hỗ trợ gap duration chính xác).
• Google Cloud Dataflow Docs: Windowing in Streaming (2026 updates: improved session merging với state backend).
• Sample Code: Beam SDK example cho ecommerce abandonment trên GitHub Beam repo.
• Exam Reference: Tương tự Google Cloud Professional Data Engineer cert (QID ~4341 từ examtopics).

🛠️ Khuyến nghị implement: Key by user_id, filter basket value trong ParDo, use AfterSessionWindow trigger + watermark hold để handle late data!

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

Câu hỏi mô tả tình huống công ty xử lý dữ liệu cho nhiều khách hàng (clients) khác nhau. Mỗi khách hàng sử dụng bộ công cụ phân tích riêng, một số cho phép truy vấn trực tiếp qua Google BigQuery. Yêu cầu chính là bảo mật dữ liệu để khách hàng không thể xem dữ liệu của nhau, đồng thời đảm bảo truy cập phù hợp cho từng bên. Đây là câu hỏi trắc nghiệm chọn ba bước (Choose three) để thực hiện, tập trung vào các thực hành tốt nhất trong Google Cloud BigQuery (không phải AWS như đề cập ban đầu – có thể là nhầm lẫn, vì toàn bộ nội dung liên quan đến BigQuery và IAM của GCP).
📘 Mục tiêu cốt lõi: Phân cách dữ liệu logic (isolation) và kiểm soát quyền truy cập (access control) theo nguyên tắc least privilege trong môi trường multi-tenant.

✅ Đáp án đúng và lý do lựa chọn

Ba lựa chọn đúng là:

1. Load data into a different dataset for each client.
2. Restrict a client's dataset to approved users.
3. Use the appropriate identity and access management (IAM) roles for each client's users.

Lý do lựa chọn 🛠️:

• Để bảo mật dữ liệu multi-client trong BigQuery, cần phân cách dữ liệu ở mức dataset (mỗi client một dataset riêng) vì dataset là đơn vị cô lập cao nhất, hỗ trợ quyền IAM độc lập (theo docs BigQuery mới nhất 2024-2026).
• Hạn chế truy cập dataset chỉ cho users được phê duyệt và sử dụng IAM roles phù hợp (như BigQuery Data Viewer, User) đảm bảo granular control, tránh cross-client access. Đây là best practice cho multi-tenancy, tuân thủ nguyên tắc IAM của GCP (cập nhật với Customer Managed Encryption Keys - CMEK nếu cần).
• Kết hợp ba bước này tạo lớp bảo mật đầy đủ: Isolation + Authorization.

📋 Phân tích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn một cách rõ ràng. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, đánh dấu ✅ (đúng) hoặc ❌ (sai), và giải thích bằng tiếng Việt dựa trên kiến thức BigQuery/IAM cập nhật đến 2026 (phiên bản BigQuery Storage Write API v1.5+, IAM với Attribute-based Access Control preview).

• Load data into different partitions. ❌
  Sai vì partitions chỉ phân chia dữ liệu theo thời gian hoặc giá trị cột (partitioned tables) để tối ưu query performance và chi phí, không cung cấp isolation bảo mật. Khách hàng vẫn có thể query cross-partition nếu có quyền trên table/dataset chung, không ngăn chặn việc xem dữ liệu lẫn nhau.

• Load data into a different dataset for each client. ✅
  Đúng vì dataset là ranh giới bảo mật chính trong BigQuery. Mỗi dataset có IAM policy riêng, cho phép cô lập hoàn toàn dữ liệu client (multi-tenancy). Dữ liệu load vào dataset riêng đảm bảo không ai truy cập chéo mà không có quyền rõ ràng.

• Put each client's BigQuery dataset into a different table. ❌
  Sai vì table nằm trong dataset, không phải ngược lại. Việc dùng table riêng chỉ phân chia logic bên trong một dataset, nhưng IAM áp dụng ở mức dataset/project nên khách hàng vẫn có thể query cross-table nếu có quyền dataset. Không giải quyết isolation thực sự.

• Restrict a client's dataset to approved users. ✅
  Đúng vì sử dụng IAM policies để giới hạn dataset chỉ cho "approved users" (users/groups/service accounts được chỉ định). Điều này thực thi row-level hoặc dataset-level security, ngăn chặn unauthorized access hiệu quả.

• Only allow a service account to access the datasets. ❌
  Sai vì hạn chế chỉ service account sẽ phá vỡ yêu cầu "direct query access via Google BigQuery" cho client. Client cần truy cập trực tiếp (qua user accounts), không chỉ service account (dùng cho automation). Cách này quá restrictive, không phù hợp multi-client human access.

• Use the appropriate identity and access management (IAM) roles for each client's users. ✅
  Đúng vì IAM roles (như roles/bigquery.dataViewer, roles/bigquery.user) là công cụ chính để grant least-privilege access. Áp dụng per-client users đảm bảo granular control, hỗ trợ federated identities (workload identity) mới nhất 2026.

📚 Tài liệu tham khảo

• BigQuery Datasets & Access Control: cloud.google.com/bigquery/docs/datasets-intro & cloud.google.com/bigquery/docs/access-control (cập nhật 2024, hỗ trợ authorized views cho cross-dataset query an toàn).
• GCP IAM Best Practices: cloud.google.com/iam/docs/best-practices-for-securing-data (multi-tenancy guidance).
• Multi-Tenant Architecture: Google Cloud Architecture Center – BigQuery multi-tenancy patterns (2025 updates).

Hy vọng phân tích này giúp bạn ôn thi Professional Data Engineer! 🚀 Nếu cần ví dụ code IAM policy, hãy hỏi thêm.

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

Câu hỏi tập trung vào việc chọn dịch vụ cơ sở dữ liệu Google Cloud phù hợp cho một ứng dụng point-of-sale (POS) xử lý giao dịch thanh toán (payment transactions). Ứng dụng chạy trên Google Cloud Platform (GCP), với yêu cầu đặc biệt là:

• Quy mô người dùng tăng trưởng theo cấp số nhân (exponentially), đòi hỏi khả năng mở rộng tự động (auto-scaling).
• Không muốn quản lý cơ sở hạ tầng scaling (no infrastructure scaling management), nghĩa là cần dịch vụ serverless hoàn toàn, tự động scale mà không cần can thiệp thủ công.

📌 Yêu cầu cốt lõi: Dịch vụ phải hỗ trợ transactional workload thời gian thực (low-latency, high-throughput), phù hợp cho OLTP (Online Transaction Processing) với traffic biến động lớn, như xử lý thanh toán POS tại các điểm bán hàng.

✅ Đáp án đúng: Cloud Datastore

Lý do lựa chọn (dựa trên kiến thức GCP cập nhật đến 2026):
Cloud Datastore (nay tích hợp chặt chẽ với Firestore in Datastore mode) là dịch vụ NoSQL document database serverless lý tưởng cho ứng dụng POS. Nó tự động scale vô hạn theo nhu cầu thực tế (pay-per-use), hỗ trợ strong consistency cho transactions ACID-compliant, low-latency reads/writes (<100ms), và không yêu cầu quản lý server/infrastructure. Hoàn hảo cho workload tăng trưởng đột biến mà không cần provision capacity.
🛠️ Ưu điểm nổi bật: Multi-region replication, horizontal scaling tự động, tích hợp seamless với App Engine/Cloud Run.
📘 Tài liệu tham khảo: Cloud Datastore Documentation & Firestore Scaling Limits (2024+).

📋 Giải thích tất cả các phương án (đúng/sai)

• Cloud SQL ❌ Sai
  Cloud SQL là dịch vụ managed relational database (MySQL/PostgreSQL/SQL Server), hỗ trợ transactional workloads tốt nhưng KHÔNG serverless hoàn toàn. Bạn vẫn phải quản lý scaling (vertical/horizontal thủ công qua console/CLI), provision instances, và xử lý high availability. Không phù hợp với "exponential growth without managing infrastructure" vì có thể gặp bottleneck nếu traffic bùng nổ đột ngột.
  🧩 Khi nào dùng? Ứng dụng cần SQL schema nghiêm ngặt, không phải auto-scale vô hạn.

• BigQuery ❌ Sai
  BigQuery là serverless data warehouse cho analytics/OLAP (batch processing, queries lớn), KHÔNG hỗ trợ transactional real-time như payment processing. Nó excels ở ad-hoc queries trên petabyte-scale data nhưng latency cao (giây đến phút), không ACID transactions, và không thiết kế cho writes frequent/high-throughput của POS app.
  🧩 Khi nào dùng? Phân tích dữ liệu lịch sử, không phải live transactions.

• Cloud Bigtable ❌ Sai
  Cloud Bigtable là NoSQL wide-column store managed, scale cực lớn cho high-throughput workloads (như IoT/time-series), nhưng KHÔNG serverless thuần túy – bạn phải thiết kế schema, provision nodes/clusters, và quản lý capacity planning. Phù hợp enterprise-scale (e.g., billions ops/sec), nhưng vi phạm "do not want to manage infrastructure scaling" vì cần expertise tuning.
  🧩 Khi nào dùng? Workloads predictable lớn như logs/monitoring, không phải app POS động.

• Cloud Datastore ✅ Đúng (như đã giải thích ở trên).
  Lý tưởng cho unstructured/semi-structured data trong app web/mobile với scaling tự động 100%, zero-management.

🛡️ Lưu ý cuối: Dựa trên best practices GCP 2024-2026, Firestore (native mode của Datastore) còn mạnh hơn với real-time sync, nhưng câu hỏi dùng "Cloud Datastore" nên khớp chính xác. Nếu migrate, khuyến nghị Firestore cho POS apps!

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

Câu hỏi tập trung vào việc sử dụng phương pháp unsupervised anomaly detection để phân loại các mẫu mô (tissue samples) mới thành bình thường (normal) hoặc đột biến (mutated), dựa trên cơ sở dữ liệu hiện có về các mẫu mô.

• Unsupervised anomaly detection là kỹ thuật học máy không giám sát (không cần nhãn dữ liệu), thường dùng để phát hiện các điểm dữ liệu bất thường (anomalies) so với phần lớn dữ liệu bình thường. Nó lý tưởng khi:
  • Anomalies (đột biến) rất hiếm gặp.
  • Không có nhãn sẵn.
  • Có thể phát hiện các anomalies mới chưa từng thấy (novel anomalies).

Câu hỏi yêu cầu chọn hai đặc điểm (characteristics) hỗ trợ việc áp dụng phương pháp này. Đây là kiến thức cơ bản trong AWS Machine Learning (như Amazon SageMaker Anomaly Detection hoặc Amazon Lookout for Equipment), nơi anomaly detection được ưu tiên cho dữ liệu không cân bằng và không nhãn, theo tài liệu cập nhật AWS đến năm 2026 (AWS ML Specialty Exam Guide và SageMaker docs).

📘 Tài liệu tham khảo:

• AWS SageMaker Anomaly Detection (hỗ trợ unsupervised cho rare events).
• AWS ML Specialty Exam Guide (2024-2026).

✅ Đáp án đúng và lý do lựa chọn

Hai đáp án đúng là:

1. There are very few occurrences of mutations relative to normal samples.
   🧩 Lý do: Trong anomaly detection không giám sát, các anomalies (đột biến) thường rất hiếm so với dữ liệu bình thường (normal samples chiếm đa số). Điều này giúp mô hình học được "mẫu bình thường" từ phần lớn dữ liệu và phát hiện outliers hiệu quả. Dữ liệu không cân bằng nghiêm trọng là đặc trưng hỗ trợ mạnh mẽ cho phương pháp này trên AWS (ví dụ: Random Cut Forest algorithm trong SageMaker).

2. You expect future mutations to have different features from the mutated samples in the database.
   🧩 Lý do: Phương pháp unsupervised anomaly detection excels ở việc phát hiện novel anomalies (đột biến mới với features khác biệt), không phụ thuộc vào việc học từ các mẫu mutated cũ. Nếu tương lai có đột biến mới, supervised classification sẽ kém hiệu quả vì cần retrain, còn anomaly detection linh hoạt hơn (theo AWS best practices cho open-world anomaly detection).

🛠️ Giải thích tất cả các phương án (đúng và sai)

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh:

✅ There are very few occurrences of mutations relative to normal samples.
🟢 Đúng: Như đã giải thích, dữ liệu imbalanced với anomalies hiếm là nền tảng của unsupervised anomaly detection, giúp mô hình định nghĩa "bình thường" dễ dàng.

❌ There are roughly equal occurrences of both normal and mutated samples in the database.
🔴 Sai: Dữ liệu cân bằng (balanced) phù hợp hơn với supervised classification (như Logistic Regression hoặc XGBoost trên SageMaker), không phải anomaly detection – nơi anomalies phải hiếm để tránh nhầm lẫn.

✅ You expect future mutations to have different features from the mutated samples in the database.
🟢 Đúng: Anomaly detection unsupervised được thiết kế cho unknown anomalies mới, khác với dữ liệu huấn luyện (concept drift). Trên AWS, các mô hình như Isolation Forest hỗ trợ điều này tốt hơn supervised methods.

❌ You expect future mutations to have similar features to the mutated samples in the database.
🔴 Sai: Nếu features tương tự, supervised learning với labeled data sẽ hiệu quả hơn (train trên mutated samples cũ để dự đoán tương lai). Anomaly detection kém ở trường hợp này vì giả định anomalies hiếm và khác biệt.

❌ You already have labels for which samples are mutated and which are normal in the database.
🔴 Sai: Có nhãn sẵn → ưu tiên supervised classification (như trên Amazon SageMaker Built-in Algorithms). Unsupervised anomaly detection dành cho dữ liệu không nhãn (unlabeled), tránh lãng phí nhãn.

Tóm lại, phương pháp này lý tưởng cho dữ liệu không nhãn, imbalanced, và novel anomalies! 🚀

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

Câu hỏi mô tả một tình huống thực tế trong Google Cloud BigQuery:
📱 Bạn cần lưu trữ và phân tích dữ liệu bài đăng mạng xã hội với tốc độ 10.000 tin nhắn/phút theo thời gian gần thực tế (near real-time).
🛠️ Ứng dụng ban đầu sử dụng streaming inserts để chèn từng bài đăng riêng lẻ vào BigQuery.
📊 Sau khi chèn streaming, ứng dụng thực hiện tổng hợp dữ liệu (aggregations) ngay lập tức.
⚠️ Vấn đề phát hiện: Các truy vấn (queries) sau streaming inserts không có tính nhất quán mạnh (strong consistency), dẫn đến báo cáo có thể bỏ sót dữ liệu đang "bay" (in-flight data) – tức dữ liệu đã chèn nhưng chưa sẵn sàng cho truy vấn.

Mục tiêu: Điều chỉnh thiết kế ứng dụng để khắc phục vấn đề này, đảm bảo dữ liệu có sẵn cho truy vấn mà vẫn giữ near real-time.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Estimate the average latency for data availability after streaming inserts, and always run queries after waiting twice as long.

Lý do chi tiết 🏆:

• Streaming inserts trong BigQuery không đảm bảo dữ liệu khả dụng ngay lập tức cho tất cả truy vấn (queries có thể đọc dữ liệu cũ hoặc miss dữ liệu mới do latency). Latency trung bình thường 1-10 giây (theo docs cập nhật 2024-2026).
• Giải pháp ước lượng latency trung bình (qua monitoring như Cloud Monitoring hoặc experiment) và chờ gấp đôi thời gian đó trước khi chạy query là cách tối ưu, đơn giản để đảm bảo strong consistency mà không thay đổi kiến trúc lớn.
• Điều này phù hợp near real-time (chỉ delay vài giây), tránh miss in-flight data, và scalable cho 10k msg/min.
• Đây là best practice chính thức từ Google Cloud (không cần batch/load khác).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn giữ nguyên văn bản gốc tiếng Anh, đánh dấu đúng/sai với lý do bằng tiếng Việt:

• ❌ [SAI] Re-write the application to load accumulated data every 2 minutes.
  Giải thích sai: Phương án này thay đổi hoàn toàn từ streaming sang batch load mỗi 2 phút, dẫn đến delay lớn (2 phút), không còn near real-time (vi phạm yêu cầu 10k msg/phút). Không giải quyết consistency mà còn làm chậm ứng dụng, buộc rewrite lớn không cần thiết.

• ❌ [SAI] Convert the streaming insert code to batch load for individual messages.
  Giải thích sai: Batch load cho từng message riêng lẻ không hiệu quả (batch cần gom dữ liệu, không phải individual), tốn kém chi phí và thời gian xử lý. BigQuery batch load không near real-time (cần file upload, tối thiểu vài phút), vẫn có thể gặp consistency issue nếu không chờ, và làm phức tạp code vô ích.

• ❌ [SAI] Load the original message to Google Cloud SQL, and export the table every hour to BigQuery via streaming inserts.
  Giải thích sai: Sử dụng Cloud SQL làm trung gian rồi export mỗi giờ tạo delay cực lớn (1 giờ), hoàn toàn mất near real-time. Streaming inserts từ SQL export vẫn gặp latency gốc, thêm chi phí (SQL + Data Transfer), phức tạp kiến trúc (multi-service), không scalable cho 10k msg/phút.

• ✅ [ĐÚNG] Estimate the average latency for data availability after streaming inserts, and always run queries after waiting twice as long.
  Giải thích đúng (như phần trên): Giữ nguyên streaming inserts, chỉ thêm buffer thời gian chờ dựa trên đo lường latency thực tế → Đảm bảo consistency, low-cost, minimal thay đổi, phù hợp high-throughput near real-time. ✅

📘 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• Google Cloud BigQuery Streaming Inserts: https://cloud.google.com/bigquery/docs/streaming-data-into-bigquery#latency (Latency ~1-10s, recommend wait & retry).
• BigQuery Consistency & Data Availability: https://cloud.google.com/bigquery/docs/streaming-data-into-bigquery#exact_timestamps (Không strong consistency ngay, dùng TABLE_DATE_RANGE hoặc wait).
• Best Practices for Streaming: https://cloud.google.com/bigquery/docs/best-practices-performance-streaming (Estimate latency via Monitoring, wait 2x average).
• Cập nhật 2024-2026: BigQuery cải thiện streaming latency <5s trung bình với Slots mới, nhưng nguyên tắc consistency không đổi. 🛠️

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

Câu hỏi mô tả tình huống tại một startup chưa có chính sách bảo mật chính thức. Mọi người trong công ty đều có quyền truy cập vào các dataset lưu trữ trong Google BigQuery, các đội ngũ tự do sử dụng dịch vụ theo ý muốn mà không có tài liệu ghi chép use case. Nhiệm vụ là bảo mật data warehouse (BigQuery) và phát hiện mọi người đang làm gì. Câu hỏi yêu cầu hành động đầu tiên để khám phá hoạt động sử dụng.

📌 Mục tiêu chính: Không chỉ kiểm tra quyền (permissions) mà cần khám phá hành vi thực tế (who is doing what) để xây dựng chính sách bảo mật, theo nguyên tắc least privilege và zero trust trong Google Cloud Security (cập nhật đến 2026 với Cloud Audit Logs v2 và Observability enhancements).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Use Google Observability Audit Logs to review data access.

Lý do:

• Audit Logs (nay thuộc Google Cloud Observability) là công cụ đầu tiên và hiệu quả nhất để khám phá hoạt động thực tế. Nó ghi lại tất cả các truy cập dữ liệu (query, read/write) bao gồm ai (principal identity), khi nào, truy cập gì (dataset/table), và từ đâu.
• Điều này giúp phân tích pattern sử dụng mà không cần tài liệu trước đó, từ đó xác định rủi ro và điều chỉnh IAM. Theo best practices Google Cloud (2026), Audit Logs là bước discovery phase trong Data Security hardening cho BigQuery.
• 🛠️ Cách thực hiện: Truy cập qua Cloud Console > Observability > Audit Logs, filter theo serviceName=bigquery.googleapis.com và methodName như google.bigquery.v2.TableData.List để xem data access.

📘 Tài liệu tham khảo:

• Google Cloud Audit Logs Documentation (cập nhật 2026 với AI-powered insights).
• BigQuery Security Best Practices – Khuyến nghị audit logs cho discovery.

🧩 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng phương án một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên kiến thức Google Cloud mới nhất (2026), tập trung vào việc "discover what everyone is doing" (khám phá hoạt động thực tế, không chỉ cấu hình).

• ✅ Use Google Observability Audit Logs to review data access.
  Đúng vì: Như đã giải thích ở trên, đây là bước đầu tiên lý tưởng để xem lịch sử truy cập chi tiết (who/what/when), giúp map use cases thực tế và phát hiện over-privileged access. Không cần thay đổi gì trước, chỉ query logs là đủ.

• ❌ Get the identity and access management IIAM) policy of each table.
  Sai vì: IAM policy (lưu ý: lỗi chính tả "IIAM" là "IAM") chỉ cho biết quyền được cấp (bindings/roles) cho từng table/dataset/project, không ghi lại hành vi sử dụng thực tế. Ví dụ: Nó cho thấy "everyone has access" nhưng không nói ai đã query gì. Đây là bước sau audit logs, dùng để remediate (sửa quyền), không phải discover đầu tiên. (Cập nhật 2026: IAM Conditions hỗ trợ fine-grained, nhưng vẫn chỉ là static config).

• ❌ Use Observability Monitoring to see the usage of BigQuery query slots.
  Sai vì: Cloud Monitoring (Observability) theo dõi metrics như query slots usage (số lượng slot tiêu thụ, latency), hữu ích cho performance/cost optimization nhưng không tiết lộ ai truy cập dữ liệu gì. Nó chỉ cho tổng quan aggregate (ví dụ: 1000 slots used/day), không discover "what everyone is doing" cụ thể. (2026: BigQuery Reservation API tích hợp Monitoring tốt hơn, nhưng vẫn thiếu identity/access details).

• ❌ Use the Google Cloud Billing API to see what account the warehouse is being billed to.
  Sai vì: Billing API chỉ cung cấp thông tin hóa đơn (cost per account/project), xác định ai chịu phí nhưng không cho biết hoạt động cụ thể (query nào, ai chạy). Ví dụ: Nó thấy project X tốn $1000 nhưng không biết teams nào dùng dataset gì. Đây là cost visibility, không phải security discovery. (2026: Billing Budgets & AI Cost Insights cải tiến, nhưng irrelevant cho access audit).

🛠️ Khuyến nghị tiếp theo sau bước đầu tiên

• Sau Audit Logs, tiến hành review & tighten IAM (Column-level security, Authorized Views).
• Enable Data Catalog để document use cases tự động.
• Theo Google Cloud Security Command Center (SCC) cho continuous monitoring (cập nhật 2026 với ML anomaly detection).

Hy vọng phân tích này giúp bạn ôn thi Professional Data Engineer! 🚀

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

Câu hỏi mô tả tình huống công ty đang di chuyển (migrate) cụm Apache Hadoop 30 node sang đám mây Google Cloud. Các yêu cầu chính bao gồm:

• Tái sử dụng (re-use) các Hadoop jobs đã tạo sẵn mà không cần chỉnh sửa nhiều.
• Giảm thiểu tối đa việc quản lý cụm (minimize the management of the cluster), nghĩa là muốn dịch vụ managed để tránh tự cài đặt, scale, maintain.
• Lưu trữ dữ liệu bền vững (persist data beyond the life of the cluster), tức dữ liệu phải tồn tại ngay cả khi cụm bị xóa hoặc dừng.

📘 Bối cảnh kiến thức cập nhật (đến 2026): Cloud Dataproc (phiên bản mới nhất hỗ trợ Hadoop 3.x, Spark 3.x, với Ephemeral clusters và auto-scaling) là dịch vụ managed cho Hadoop/Spark trên Google Cloud. Nó cho phép chạy jobs Hadoop gốc, tích hợp Google Cloud Storage (GCS) làm storage bền vững thay vì HDFS (HDFS chỉ tồn tại trong cluster). GCS connector (hadoop3-gcs-connector) cho phép Hadoop đọc/ghi trực tiếp vào GCS như file system, đảm bảo dữ liệu persist. (Nguồn: Google Cloud Dataproc Documentation, GCS Hadoop Connector).

🛠️ Mục tiêu lựa chọn: Cần giải pháp managed, hỗ trợ Hadoop jobs native, và storage ngoài cluster.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create a Cloud Dataproc cluster that uses the Google Cloud Storage connector.

Lý do:

• Cloud Dataproc là dịch vụ managed Hadoop/Spark, tự động quản lý cluster (provisioning, scaling, patching), giảm thiểu management tối đa so với self-managed.
• Tái sử dụng Hadoop jobs: Chạy trực tiếp jobs Hadoop/Spark gốc mà không cần rewrite.
• Persist data: GCS connector (hadoop-gcs-connector) cho phép dùng GCS làm HDFS thay thế (qua fs.gs://), dữ liệu lưu ở GCS bền vững, tồn tại sau khi cluster bị xóa (ephemeral mode).
• Hoàn hảo cho migrate 30-node cluster với auto-scaling và multi-tenancy. ✅

❌ Giải thích tất cả các phương án (đúng/sai)

• [SAI] Create a Google Cloud Dataflow job to process the data.
  ❌ Sai vì: Dataflow là dịch vụ Apache Beam cho batch/streaming, không hỗ trợ trực tiếp Hadoop jobs (MapReduce/YARN). Phải rewrite jobs sang Beam pipeline, vi phạm yêu cầu re-use. Không phải managed Hadoop cluster. (Nguồn: Dataflow vs Dataproc).

• [SAI] Create a Google Cloud Dataproc cluster that uses persistent disks for HDFS.
  ❌ Sai vì: Dataproc managed tốt, re-use jobs OK, nhưng HDFS trên persistent disks vẫn không persist beyond cluster (dữ liệu gắn với cluster lifecycle). Khi xóa cluster, HDFS mất (trừ backup thủ công). Không tối ưu bằng GCS connector. (Nguồn: Dataproc Storage Options).

• [SAI] Create a Hadoop cluster on Google Compute Engine that uses persistent disks.
  ❌ Sai vì: Compute Engine (GCE) yêu cầu self-managed toàn bộ (cài Hadoop, YARN, scale thủ công), không minimize management. Persistent disks persist data OK, nhưng vẫn gắn với VM lifecycle, phức tạp cho 30-node. (Nguồn: GCE vs Dataproc).

• [ĐÚNG] Create a Cloud Dataproc cluster that uses the Google Cloud Storage connector.
  ✅ Đúng vì: Như phân tích trên – managed, re-use jobs, GCS persist vĩnh viễn. Lý tưởng cho migrate Hadoop lớn. (Nguồn: Dataproc GCS Integration).

• [SAI] Create a Hadoop cluster on Google Compute Engine that uses Local SSD disks.
  ❌ Sai vì: GCE self-managed (không minimize), Local SSD mất dữ liệu khi stop/delete VM (ephemeral storage), vi phạm persist data. Tệ hơn cả persistent disks. (Nguồn: GCE Disk Types).

🧩 Tóm tắt khuyến nghị: Chọn Dataproc + GCS để managed end-to-end, scale linh hoạt (preemptible VMs tiết kiệm chi phí 2026), và dữ liệu an toàn ở multi-region GCS! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📘 Nội dung câu hỏi:
Câu hỏi mô tả một cơ sở dữ liệu chứa các giao dịch ngân hàng, với mỗi hàng dữ liệu bao gồm: user ID (ID người dùng), transaction type (loại giao dịch), transaction location (vị trí giao dịch), và transaction amount (số tiền giao dịch). Các chủ doanh nghiệp yêu cầu phân tích xem loại máy học (machine learning) nào có thể áp dụng cho dữ liệu này. Đây là câu hỏi chọn ba đáp án đúng từ sáu lựa chọn, tập trung vào việc xác định các ứng dụng ML phù hợp dựa trên đặc tính dữ liệu (không có nhãn sẵn cho các vấn đề như gian lận). Chủ đề liên quan đến AWS (qua các dịch vụ như Amazon SageMaker hỗ trợ các loại ML này), với kiến thức cập nhật đến năm 2026 (SageMaker hỗ trợ đầy đủ supervised, unsupervised, clustering, và các mô hình anomaly detection qua AutoML và built-in algorithms như Random Cut Forest).

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

Dưới đây là ba đáp án đúng, được chọn dựa trên tính khả thi với dữ liệu không nhãn (cho fraud và clustering) và khả năng huấn luyện mô hình dự đoán (cho location):

1. Unsupervised learning to determine which transactions are most likely to be fraudulent. 🛡️ (Phát hiện bất thường - anomaly detection).
2. Clustering to divide the transactions into N categories based on feature similarity. 🔍 (Nhóm dữ liệu tương đồng).
3. Supervised learning to predict the location of a transaction. 🎯 (Dự đoán vị trí dựa trên các feature khác).

Lý do chọn ba đáp án này:
Dữ liệu chỉ có các feature cơ bản (user ID, type, location, amount) không có nhãn (labels) cho fraud, nên unsupervised và clustering phù hợp để khám phá pattern ẩn. Supervised cho predict location khả thi nếu chia dữ liệu thành train/test (sử dụng location làm target, các feature khác làm input). AWS SageMaker (phiên bản 2026) hỗ trợ qua algorithms như XGBoost (supervised), K-Means/IP (clustering), và Random Cut Forest (anomaly/unsupervised fraud).

🛠️ Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn một, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên nguyên tắc ML và dữ liệu cho sẵn:

• ❌ Supervised learning to determine which transactions are most likely to be fraudulent.
  Sai vì supervised learning yêu cầu dữ liệu có nhãn (labeled data) (ví dụ: cột "fraud" = yes/no), nhưng dữ liệu chỉ có user ID, type, location, amount không có nhãn fraud. Không thể huấn luyện trực tiếp mà không cần labeling thủ công trước (tốn kém). AWS SageMaker yêu cầu labels cho supervised fraud detection.

• ✅ Unsupervised learning to determine which transactions are most likely to be fraudulent.
  Đúng vì unsupervised phù hợp cho anomaly detection (phát hiện giao dịch bất thường như fraud dựa trên pattern ẩn, ví dụ: amount cao bất thường ở location lạ). Dữ liệu không nhãn nên dùng algorithms như Isolation Forest hoặc Autoencoder trên SageMaker để flag outliers.

• ✅ Clustering to divide the transactions into N categories based on feature similarity.
  Đúng vì clustering là unsupervised nhóm dữ liệu tương đồng (ví dụ: nhóm theo user/type/amount/location bằng K-Means hoặc DBSCAN). Rất phù hợp để khám phá segments khách hàng hoặc pattern giao dịch mà không cần nhãn.

• ✅ Supervised learning to predict the location of a transaction.
  Đúng vì có thể dùng location làm target variable (classification nếu location là categorical, regression nếu coordinates), train trên user ID/type/amount. Chia dữ liệu train/test để huấn luyện (SageMaker XGBoost hoặc Linear Learner hỗ trợ tốt).

• ❌ Reinforcement learning to predict the location of a transaction.
  Sai vì reinforcement learning dành cho quyết định sequential với reward (như game/robot), không phù hợp predict location tĩnh từ dữ liệu giao dịch. AWS SageMaker RL (như Ray RLlib) không dùng cho prediction đơn giản này.

• ❌ Unsupervised learning to predict the location of a transaction.
  Sai vì unsupervised không predict giá trị cụ thể (chỉ khám phá pattern/clustering), không có cơ chế dự đoán target như location. Nó không thay thế được supervised cho regression/classification.

📚 Tài liệu tham khảo

• AWS SageMaker Documentation (2026 update): Amazon SageMaker Built-in Algorithms - Chi tiết K-Means (clustering), Random Cut Forest (unsupervised anomaly), XGBoost (supervised prediction).
• AWS ML Specialty Exam Guide: Fraud detection thường dùng unsupervised nếu no labels (xem AWS Certified Machine Learning Study Guide).
• Google Cloud tương đương (danh cho Data Engineer): Vertex AI hỗ trợ tương tự (AutoML Clustering, Anomaly Detection).

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm ví dụ code SageMaker, hãy hỏi nhé!

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

Câu hỏi mô tả tình huống công ty đang sử dụng các máy chủ Apache Hadoop on-premises sắp hết hạn hỗ trợ (end-of-life), và bộ phận IT quyết định di chuyển toàn bộ cluster sang Google Cloud Dataproc – một dịch vụ managed Hadoop/Spark trên Google Cloud. Việc di chuyển "like-for-like" (giữ nguyên cấu hình tương đương) sẽ yêu cầu 50 TB Google Persistent Disk (PD) trên mỗi node, dẫn đến chi phí lưu trữ block storage rất cao. CIO lo ngại về chi phí này, và nhiệm vụ là giảm thiểu tối đa chi phí lưu trữ trong quá trình di chuyển.

🛠️ Bối cảnh chính:

• Persistent Disk (PD) là block storage đắt đỏ, phù hợp cho dữ liệu cần truy cập nhanh như OS hoặc temporary data, nhưng không hiệu quả cho big data lớn như Hadoop (chi phí khoảng 0.04-0.17 USD/GB/tháng tùy loại, theo giá 2024-2026).
• Dataproc hỗ trợ Cloud Storage (GCS) làm hệ thống lưu trữ chính thay thế HDFS, rẻ hơn rất nhiều (khoảng 0.002-0.023 USD/GB/tháng), và được tối ưu cho workload Hadoop/Spark với tính năng như multi-region, durability cao.
• Mục tiêu: Chuyển dữ liệu từ PD sang giải pháp rẻ hơn mà vẫn đảm bảo Dataproc hoạt động mượt mà.

📘 Tài liệu tham khảo:

• Google Cloud Dataproc Storage Concepts (cập nhật 2025: Khuyến nghị GCS làm default bucket cho HDFS compatibility).
• Dataproc Pricing (PD vs GCS cost comparison, GCS tiết kiệm 80-90% cho large-scale data).
• Migrating Hadoop to Dataproc Best Practices (phiên bản mới nhất 2026).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Put the data into Google Cloud Storage.

Lý do:

• Đây là giải pháp tối ưu nhất để giảm chi phí lưu trữ vì GCS là object storage rẻ hơn Persistent Disk rất nhiều (tiết kiệm lên đến 90% cho dữ liệu lớn 50TB/node). Dataproc hỗ trợ GCS làm default file system (qua gcsfuse hoặc connector), thay thế hoàn hảo cho HDFS trong Hadoop. Dữ liệu có thể được mount trực tiếp vào cluster mà không cần PD lớn, đảm bảo tính tương thích và performance cao cho workload phân tán. Phương án này giải quyết triệt để vấn đề "like-for-like migration yêu cầu 50TB PD", bằng cách loại bỏ nhu cầu PD cho data storage chính.

🧩 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Phần giải thích sử dụng kiến thức Dataproc mới nhất (2026), tập trung vào tính khả thi, chi phí và hiệu quả.

• ✅ [ĐÚNG] Put the data into Google Cloud Storage.
  Giải thích đúng: Như đã phân tích ở trên, GCS là lựa chọn chuẩn cho Dataproc migration từ Hadoop on-prem. Nó hỗ trợ Hadoop FileSystem API đầy đủ (qua Cloud Storage connector), cho phép chạy job Spark/Hadoop trực tiếp trên GCS mà không cần replicate data sang PD. Chi phí thấp, scalability cao (hàng PB), và tích hợp native với Dataproc (tạo cluster với --gcs-bucket flag). Đây là best practice từ Google, giảm chi phí storage từ hàng nghìn USD/tháng xuống chỉ vài trăm.

• ❌ [SAI] Use preemptible virtual machines (VMs) for the Cloud Dataproc cluster.
  Giải thích sai: Preemptible VMs (nay gọi Spot VMs từ 2024) chỉ tiết kiệm chi phí compute (giảm 60-91% so với on-demand VMs), nhưng không ảnh hưởng đến chi phí storage. Vẫn cần 50TB PD/node cho data, nên vấn đề cốt lõi (storage cost) không được giải quyết. Preemptible phù hợp cho batch jobs ngắn, nhưng cluster Hadoop cần stability cao hơn, và không liên quan trực tiếp đến PD usage.

• ❌ [SAI] Tune the Cloud Dataproc cluster so that there is just enough disk for all data.
  Giải thích sai: Việc "tune" cluster (điều chỉnh disk size qua --provisioned-throughput hoặc autoscaling) chỉ giảm PD một chút bằng cách optimize (ví dụ: dùng SSD cho hot data), nhưng vẫn yêu cầu PD cho toàn bộ 50TB data như HDFS truyền thống. Chi phí PD vẫn cao (không dưới ngưỡng 0.04 USD/GB), và không phải giải pháp minimize tối đa. Dataproc khuyến nghị tránh PD cho bulk storage.

• ❌ [SAI] Migrate some of the cold data into Google Cloud Storage, and keep only the hot data in Persistent Disk.
  Giải thích sai: Phương án này có cải thiện một phần (chuyển cold data sang GCS rẻ), nhưng vẫn giữ hot data trên PD đắt đỏ, không đạt minimize storage cost hoàn toàn. Với 50TB/node, "some cold data" không đủ để loại bỏ PD lớn, dẫn đến chi phí lai (hybrid) vẫn cao. Dataproc hỗ trợ tiered storage, nhưng best practice là dùng GCS cho tất cả data (hot/cold) nhờ caching và connector optimization (cập nhật 2025).

Kết luận 💡: Chọn GCS là cách thông minh và tiết kiệm nhất, phù hợp với kiến trúc cloud-native của Dataproc. Nếu triển khai, dùng lệnh gcloud dataproc clusters create với GCS bucket để test migration!

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

Câu hỏi mô tả một tình huống thực tế trong Google Cloud Pub/Sub: Bạn làm việc cho nhà sản xuất ô tô, thiết lập pipeline dữ liệu sử dụng Pub/Sub để thu thập các sự kiện cảm biến bất thường (anomalous sensor events). Bạn đang dùng push subscription trong Pub/Sub, subscription này sẽ đẩy (push) message trực tiếp đến một custom HTTPS endpoint do bạn tự tạo để xử lý ngay lập tức các sự kiện bất thường. Tuy nhiên, endpoint này liên tục nhận được một lượng lớn duplicate messages (tin nhắn trùng lặp).
Vấn đề cốt lõi: Tìm nguyên nhân có khả năng nhất gây ra duplicate messages trong push subscription.
🛠️ Kiến thức nền tảng (cập nhật đến 2024-2026 theo docs Google Cloud): Pub/Sub push subscription hoạt động theo mô hình at-least-once delivery, nghĩa là message có thể được giao nhiều lần nếu subscriber không acknowledge (ack) kịp thời trong acknowledgement deadline (mặc định 10 giây, có thể cấu hình lên đến 10 phút). Nếu không ack, Pub/Sub sẽ redeliver message đó, dẫn đến duplicates.
📘 Tài liệu tham khảo:

• Pub/Sub Push Subscriptions (Google Cloud Docs, cập nhật 2024).
• Message Delivery Guarantees – Giải thích at-least-once và redelivery.

✅ Đáp án đúng và lý do lựa chọn

Your custom endpoint is not acknowledging messages within the acknowledgement deadline.
🧩 Lý do chi tiết: Đây là nguyên nhân có khả năng nhất vì trong push subscription, sau khi Pub/Sub push message đến HTTPS endpoint, endpoint phải gửi HTTP 2xx response (ack) trong thời hạn ack deadline. Nếu endpoint xử lý chậm (ví dụ: logic xử lý sensor data mất >10s), Pub/Sub coi như không ack và redeliver message ngay lập tức, gây duplicate. Đây là hành vi chuẩn của Pub/Sub để đảm bảo at-least-once semantics. Giải pháp: Tối ưu endpoint, tăng ack deadline qua ackDeadlineSeconds (max 600s), hoặc dùng idempotent handling (xử lý trùng lặp ở app level).
✅ Xác nhận: Hoàn toàn khớp với best practices Pub/Sub 2024+.

❌ Giải thích tất cả các phương án

Dưới đây là phân tích từng phương án (giữ nguyên văn bản gốc bằng tiếng Anh), chỉ rõ đúng/sai và lý do bằng tiếng Việt dựa trên kiến thức Pub/Sub mới nhất:

• The message body for the sensor event is too large.
  ❌ Sai: Kích thước message lớn (>10MB cho standard, hoặc >~1MB cho high-throughput) sẽ gây lỗi publish (quota exceeded) hoặc reject khi push (HTTP 4xx/5xx), dẫn đến drop message chứ không phải duplicate. Pub/Sub không redeliver vì kích thước; nó chỉ retry tạm thời nếu transient error, nhưng không tạo "inordinate duplicates". (Ref: Quotas & Limits).

• Your custom endpoint has an out-of-date SSL certificate.
  ❌ Sai: SSL certificate hết hạn gây lỗi kết nối HTTPS (TLS handshake fail), Pub/Sub sẽ fail push và retry theo exponential backoff (lên đến 8 ngày), nhưng không gây duplicate lớn vì retry limit bị giới hạn (max 1000 attempts). Thay vào đó, bạn sẽ thấy dead-letter queue hoặc drop, không phải flood duplicates liên tục. Giải pháp: Update cert với valid SNI/CA. (Ref: Push Endpoint Requirements).

• The Cloud Pub/Sub topic has too many messages published to it.
  ❌ Sai: Volume cao (throttling >1M msg/s) chỉ gây backlog hoặc publish latency, Pub/Sub vẫn push theo quota subscription (1000 concurrent pushes). Không liên quan trực tiếp đến duplicate, vì duplicate chủ yếu từ không ack chứ không phải publish volume. Pub/Sub scaling tự động đến 2026 vẫn giữ at-least-once, không thay đổi cơ chế này. (Ref: Scaling).

🛠️ Lời khuyên thực hành: Để tránh duplicates, implement idempotency (dùng message ID để dedup), monitor metrics như push_request_count và unack_message_count qua Cloud Monitoring. Nếu cần exactly-once, dùng Pub/Sub Lite hoặc Dataflow với snapshots (cập nhật 2024).