Ngân hàng đề — Google Cloud Associate Data Practitioner

🧩 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 Platform (GCP): Công ty đang xây dựng một pipeline streaming gần thời gian thực (near real-time) để xử lý dữ liệu telemetry JSON từ các thiết bị nhỏ (small appliances). Dữ liệu đến qua Pub/Sub topic, cần chuyển các chữ cái trong trường serial number thành chữ hoa (capitalize), sau đó ghi kết quả vào BigQuery. Yêu cầu sử dụng dịch vụ managed (quản lý hoàn toàn) và viết code tối thiểu cho các phép biến đổi (transformations).

🛠️ Yêu cầu chính:

• Xử lý tin nhắn từ Pub/Sub một cách nhanh chóng (near real-time).
• Biến đổi đơn giản: Capitalize serial number trong JSON.
• Ghi trực tiếp vào BigQuery.
• Ưu tiên managed service, ít code nhất (minimal code).

📘 Kiến thức cập nhật (GCP phiên bản mới nhất đến 2026): GCP cung cấp các template Dataflow sẵn có cho streaming từ Pub/Sub đến BigQuery, hỗ trợ UDF (User-Defined Function) để tùy chỉnh biến đổi mà không cần viết pipeline phức tạp từ đầu. Điều này phù hợp với Apache Beam/Dataflow 2.58+ (cập nhật 2025-2026), tối ưu cho near real-time với auto-scaling.

Nguồn tham khảo:

• Dataflow Templates: Pub/Sub to BigQuery (Google Cloud Docs, cập nhật 2026).
• BigQuery Streaming Inserts.

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

Đáp án đúng: Use the “Pub/Sub to BigQuery” Dataflow template with a UDF, and write the results to BigQuery.

Lý do 🏆:

• Đây là giải pháp managed hoàn toàn qua Dataflow (dịch vụ serverless cho streaming), sử dụng template có sẵn "Pub/Sub to BigQuery" – chỉ cần cấu hình UDF đơn giản (JavaScript/Python) để capitalize serial number, không cần viết code pipeline phức tạp.
• Đảm bảo near real-time (latency <1 giây), auto-scale, và ghi trực tiếp vào BigQuery mà minimal code (chỉ UDF ~5-10 dòng).
• Phù hợp nhất với yêu cầu, tránh custom code serverless như Cloud Run.

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

• ❌ [SAI] Use a Pub/Sub to BigQuery subscription, write results directly to BigQuery, and schedule a transformation query to run every five minutes.
  Giải thích sai: Không tồn tại "Pub/Sub to BigQuery subscription" trực tiếp (Pub/Sub chỉ hỗ trợ push/pull/Cloud Storage). Việc schedule query BigQuery mỗi 5 phút không near real-time (batch processing, delay cao), và không có biến đổi inline. Phải viết query riêng, vi phạm minimal code.

• ❌ [SAI] Use a Pub/Sub to Cloud Storage subscription, write a Cloud Run service that is triggered when objects arrive in the bucket, performs the transformations, and writes the results to BigQuery.
  Giải thích sai: Pub/Sub to Cloud Storage là subscription hợp lệ, nhưng cần viết full Cloud Run service (containerized code) để trigger từ bucket, xử lý JSON, capitalize, rồi stream vào BigQuery – code nhiều (deploy container, handle errors, scaling), không managed thuần túy và kém near real-time do batch files.

• ✅ [ĐÚNG] Use the “Pub/Sub to BigQuery” Dataflow template with a UDF, and write the results to BigQuery.
  Giải thích đúng: Template Dataflow có sẵn (plug-and-play), hỗ trợ UDF để tùy chỉnh capitalize serial number (code tối thiểu). Managed 100% bởi Google, near real-time, auto-handle schema BigQuery. Hoàn hảo cho streaming JSON từ Pub/Sub.

• ❌ [SAI] Use a Pub/Sub push subscription, write a Cloud Run service that accepts the messages, performs the transformations, and writes the results to BigQuery.
  Giải thích sai: Pub/Sub push subscription hợp lệ, nhưng yêu cầu viết full Cloud Run service (HTTP endpoint nhận message, parse JSON, capitalize, batch insert BigQuery) – code nhiều (auth, retries, scaling), không managed cho transformations, dễ lỗi concurrent và tốn chi phí hơn Dataflow template.

🧠 Tóm tắt lợi ích đáp án đúng: Tiết kiệm 90% code so với custom solutions, chi phí thấp (~0.01$/GB processed), độ tin cậy cao nhờ Dataflow SLAs (99.9% uptime). Khuyến nghị test qua GCP Console! 🚀

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

Câu hỏi yêu cầu xây dựng một data pipeline có khả năng mở rộng (scalable) để xử lý và tải file CSV hàng ngày về doanh số bán hàng (daily sales CSV file) từ Cloud Storage vào BigQuery nhằm phục vụ báo cáo downstream. Các yêu cầu chính bao gồm:

• Xử lý nhanh chóng (quickly build).
• Biến đổi dữ liệu (transforms the data) trong pipeline.
• Cung cấp insights về các vấn đề chất lượng dữ liệu (data quality issues), như kiểm tra lỗi dữ liệu, duplicate, missing values, v.v.

Đây là tình huống điển hình trong Google Cloud Platform (GCP), tập trung vào ETL (Extract, Transform, Load) cho dữ liệu lớn. Pipeline cần batch processing (xử lý theo lô hàng ngày), scalable để xử lý volume tăng, và tích hợp sẵn công cụ kiểm tra data quality mà không cần code phức tạp. Kiến thức dựa trên tài liệu GCP cập nhật đến 2026 (BigQuery 2.0+, Data Fusion 6.10+, Dataflow Flex Templates 2025).

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

• Cloud Data Fusion Documentation (Data Quality features).
• BigQuery External Tables & Loading.
• Dataflow Batch Templates.

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

Đáp án đúng: Create a batch pipeline in Cloud Data Fusion by using a Cloud Storage source and a BigQuery sink.

Lý do 🛠️:

• Cloud Data Fusion là công cụ no-code/low-code ETL lý tưởng để xây dựng pipeline nhanh chóng, hỗ trợ trực tiếp Cloud Storage source (đọc CSV) và BigQuery sink (ghi dữ liệu đã transform).
• Nó cho phép transform data qua drag-and-drop (Wrangler, Spark jobs) và insights data quality qua Data Quality rules tích hợp (kiểm tra schema, nulls, outliers, tự động generate reports/alerts).
• Scalable nhờ chạy trên Dataproc clusters tự động scale. Phù hợp daily batch, deploy chỉ trong vài phút. Đây là best practice cho non-engineers theo GCP Well-Architected Framework 2025.

📋 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:

• ✅ Create a batch pipeline in Cloud Data Fusion by using a Cloud Storage source and a BigQuery sink.
  Giải thích đúng: Phương án này hoàn hảo vì Data Fusion hỗ trợ end-to-end pipeline từ CS → transform (custom logic, joins) → BQ, với built-in data quality monitoring (rules engine, lineage, profiling). Scalable, quick setup qua UI. Không cần load thủ công, tránh duplicate data hàng ngày.

• ❌ Load the CSV file as a table in BigQuery, and use scheduled queries to run SQL transformation scripts.
  Giải thích sai: Cách này chỉ là load raw + SQL scheduled (qua BigQuery Scheduled Queries), thiếu pipeline scalable thực thụ. Không có insights data quality tự động (phải code thủ công trong SQL), dễ lỗi với volume lớn, và không "quickly build" vì cần viết script phức tạp. Không phải pipeline ETL đầy đủ.

• ❌ Load the CSV file as a table in BigQuery. Create a batch pipeline in Cloud Data Fusion by using a BigQuery source and sink.
  Giải thích sai: Bước load raw vào BQ trước là thừa, gây double processing và tốn chi phí lưu trữ/query. Data Fusion BQ source-sink chỉ transform intra-BQ, không tận dụng CS trực tiếp. Vẫn thiếu quick build cho daily ingest, và data quality insights bị muộn (sau load).

• ❌ Create a batch pipeline in Dataflow by using the Cloud Storage CSV file to BigQuery batch template.
  Giải thích sai: Dataflow template CSV to BigQuery (Flex Template 2025) chủ yếu load trực tiếp với schema inference, hỗ trợ basic transform (Beam SQL/ParDo) nhưng không mạnh về data quality insights (phải code custom DoFn, phức tạp). Không "quickly build" cho non-coders, kém linh hoạt hơn Data Fusion cho business users. Phù hợp streaming hơn batch quality checks.

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

Câu hỏi tập trung vào việc quản lý bucket Cloud Storage (Google Cloud Storage - GCS) lưu trữ các file tạm thời được tạo trong quá trình xử lý dữ liệu. Những file này chỉ cần thiết trong 7 ngày, sau đó không còn cần nữa. Mục tiêu là giảm chi phí lưu trữ và giữ bucket gọn gàng bằng cách tự động xóa file cũ hơn 7 ngày.

📌 Yêu cầu chính: Tìm giải pháp tự động, hiệu quả chi phí, không cần code tùy chỉnh phức tạp, và phù hợp với tính năng native của GCS. Đây là tình huống phổ biến trong data processing, nơi lifecycle management giúp tránh lãng phí storage mà không cần can thiệp thủ công.

✅ Đáp án đúng: Configure a Cloud Storage lifecycle rule that automatically deletes objects older than seven days.
Lý do chọn: Đây là tính năng native của GCS, cho phép thiết lập quy tắc lifecycle tự động xóa object dựa trên tuổi thọ (Age), không tốn thêm chi phí, chạy liên tục 24/7 mà không cần scheduler hay code. Hỗ trợ chính xác 7 ngày, tích hợp sâu với bucket, và cập nhật mới nhất (đến 2026) vẫn là recommended best practice cho automatic deletion. 🛡️ Tiết kiệm: Không cần tài nguyên compute, chỉ áp dụng metadata rule.

📋 Giải thích tất cả các phương án (theo thứ tự gốc)

• ❌ [SAI] Set up a Cloud Scheduler job that invokes a weekly Cloud Run function to delete files older than seven days.
  🧩 Giải thích sai: Phương án này dùng Cloud Scheduler (chạy hàng tuần) gọi Cloud Run để xóa file, nhưng không chính xác vì chỉ kiểm tra hàng tuần → file có thể tồn tại đến 14 ngày (vượt 7 ngày). Tốn chi phí compute (Cloud Run invocations + Scheduler), phức tạp setup, và không phải giải pháp native. Không hiệu quả cho yêu cầu "tự động ngay khi >7 ngày".

• ✅ [ĐÚNG] Configure a Cloud Storage lifecycle rule that automatically deletes objects older than seven days.
  🧩 Giải thích đúng: Lifecycle rule của GCS kiểm tra hàng ngày (daily scan), tự động xóa object khi Age > 7 days dựa trên CreateTime. Đơn giản: Chỉ cần JSON rule hoặc Console setup (ví dụ: {"lifecycle": {"rule": [{"action": {"type": "Delete"}, "condition": {"age": 7}}]}}). Zero-cost ngoài storage gốc, scalable cho mọi kích thước bucket. Phù hợp 100% với yêu cầu. 🚀 Best practice theo docs mới nhất.

• ❌ [SAI] Develop a batch process using Dataflow that runs weekly and deletes files based on their age.
  🧩 Giải thích sai: Dataflow (Apache Beam) dùng cho batch/stream processing dữ liệu lớn, không phù hợp cho delete file đơn giản. Chạy hàng tuần → delay xóa (tương tự lựa chọn 1). Tốn chi phí cao (vCPU, memory cho job), cần code custom (scan/list/delete via API), overkill và phức tạp. Không native cho lifecycle management.

• ❌ [SAI] Create a Cloud Run function that runs daily and deletes files older than seven days.
  🧩 Giải thích sai: Cloud Run daily cần scheduler riêng (như Eventarc hoặc Scheduler), vẫn tốn chi phí invocations (~$0.0000025/req + cold start). Phải code logic list/delete objects (dùng Storage API), không scalable cho bucket lớn (quota API calls). Ít hiệu quả hơn lifecycle rule native, dễ lỗi và maintain.

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

• Chính thức Google Cloud: Object Lifecycle Management – Hướng dẫn setup rule Delete với Age condition.
• Best Practices: Managing GCS costs with lifecycle – Xác nhận automatic daily evaluation.
• Console Guide: Lifecycle rules in Console – Age: số ngày từ CreateTime.
• CLI/gcloud: gsutil lifecycle set config.json gs://your-bucket/ (docs 2024-2026 không thay đổi core feature).

🛠️ Lời khuyên: Luôn ưu tiên lifecycle rules cho retention policy để tối ưu chi phí! Nếu bucket lớn, kết hợp với Storage Classes (Standard → Nearline).

🧩 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ông ty y tế sở hữu hệ thống dữ liệu lớn on-premises chứa hồ sơ bệnh nhân với thông tin cá nhân có thể nhận dạng (PII - Personally Identifiable Information) như tên, địa chỉ và chẩn đoán y tế. Yêu cầu là tìm giải pháp managed chuẩn hóa (standardized managed solution) để de-identify (loại bỏ thông tin nhận dạng) PII trên tất cả các data feeds trước khi ingest (nạp dữ liệu) vào Google Cloud.
🛠️ Điểm mấu chốt: Giải pháp phải managed (được Google quản lý hoàn toàn), chuẩn hóa (dễ sử dụng, tích hợp sẵn), xử lý trước ingestion (không nạp dữ liệu thô vào Cloud trước), và phù hợp cho dữ liệu nhạy cảm y tế. Điều này nhấn mạnh nhu cầu về pipeline ETL/ELT tự động, an toàn, tuân thủ quy định như HIPAA.

✅ Đáp án đúng:
Use Cloud Data Fusion to transform the data. Store the cleaned data in BigQuery.

Lý do chọn đáp án này (theo kiến thức Google Cloud cập nhật đến 2026):
Cloud Data Fusion là dịch vụ fully managed, no-code/low-code dựa trên Apache CDAP, chuyên xây dựng pipeline dữ liệu tích hợp (integration pipelines) để transform và de-identify dữ liệu trước khi lưu trữ. Nó hỗ trợ Data Loss Prevention (DLP) API tích hợp sẵn để tự động phát hiện và che giấu PII (như mask tên, địa chỉ), xử lý đa nguồn data feeds on-premises. Dữ liệu sạch sau transform được lưu trực tiếp vào BigQuery. Đây là giải pháp chuẩn hóa nhất cho doanh nghiệp y tế, dễ scale và tuân thủ bảo mật.
📘 Nguồn tham khảo: Google Cloud Data Fusion Documentation (cập nhật 2025: hỗ trợ DLP v2 với AI de-identification); Best practices for healthcare data pipelines.

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

• ❌ Phương án SAI: Use Cloud Run functions to create a serverless data cleaning pipeline. Store the cleaned data in BigQuery.
  Cloud Run là dịch vụ serverless cho containers, phù hợp chạy ứng dụng tùy chỉnh nhưng không phải giải pháp managed chuẩn hóa cho de-identification PII. Người dùng phải tự code pipeline cleaning (không có template sẵn cho DLP), khó scale cho "tất cả data feeds" on-premises, và không đảm bảo standardized cho dữ liệu y tế nhạy cảm. Rủi ro bảo mật cao nếu code sai.

• ✅ Phương án ĐÚNG: Use Cloud Data Fusion to transform the data. Store the cleaned data in BigQuery.
  Như đã giải thích ở trên: Fully managed ETL tool với giao diện kéo-thả, tích hợp DLP để de-identify PII trước ingestion, hỗ trợ connectors on-premises (như JDBC cho hệ thống y tế). Lưu trữ sạch vào BigQuery một cách tự động. Hoàn hảo cho yêu cầu "standardized managed solution".
  🏆 Ưu điểm nổi bật: No-code pipelines, auto-scaling, tích hợp Pub/Sub/Cloud Storage cho data feeds.

• ❌ Phương án SAI: Load the data into BigQuery, and inspect the data by using SQL queries. Use Dataflow để transform the data and remove any errors.
  Phương án này vi phạm yêu cầu cốt lõi: Load dữ liệu thô (có PII) vào BigQuery trước, sau đó mới inspect bằng SQL và transform bằng Dataflow. Điều này rủi ro bảo mật cao (PII đã ingest vào Cloud), không phải "prior to ingestion". Dataflow mạnh cho batch/streaming nhưng cần code Beam, không "standardized managed" đơn giản.

• ❌ Phương án SAI: Use Apache Beam to read the data and perform the necessary cleaning and transformation operations. Store the cleaned data in BigQuery.
  Apache Beam là framework mã nguồn mở (không phải managed service), yêu cầu tự code pipeline cleaning/de-identification. Không có giao diện chuẩn hóa, khó deploy cho on-premises data feeds đa dạng, và phải dùng Dataflow làm runner (nhưng vẫn không "standardized" như Data Fusion). Không phù hợp cho người dùng không chuyên code.

🎯 Kết luận: Cloud Data Fusion là lựa chọn tối ưu nhất theo best practices Google Cloud cho dữ liệu PII y tế (HIPAA-compliant). Các phương án khác thiếu tính managed hoặc vi phạm "prior to ingestion".
📚 Tài liệu bổ sung: Google Cloud DLP for De-identification (2026 update: Enhanced ML models for medical PII); Data Fusion vs. Dataflow comparison.

🧩 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 quản lý dữ liệu lớn trong Google Cloud Storage (GCS), bao gồm dữ liệu thô (raw data), dữ liệu đã xử lý (processed data) và bản sao lưu (backups). Tổ chức phải tuân thủ các quy định nghiêm ngặt về tính bất biến (immutability) cho một số loại dữ liệu cụ thể, nghĩa là dữ liệu không được phép bị xóa hoặc ghi đè trong thời gian giữ (retention period). Mục tiêu là sử dụng quy trình hiệu quả để giảm chi phí lưu trữ (storage costs) trong khi vẫn đáp ứng yêu cầu lưu giữ dữ liệu (retention requirements).

Các yếu tố chính cần giải quyết:

• Immutability: Ngăn chặn việc xóa hoặc thay đổi object.
• Giảm chi phí: Chuyển object sang các lớp lưu trữ rẻ hơn (storage classes) như Standard → Nearline → Coldline → Archive dựa trên tuổi thọ (age) và mô hình truy cập (access patterns).
• Hiệu quả: Sử dụng công cụ tự động, không thủ công để tối ưu hóa.

Đây là chủ đề cốt lõi trong Google Cloud Storage best practices cho compliance và cost optimization (cập nhật đến 2026, theo tài liệu chính thức Google Cloud).

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

• Object holds (enforce immutability).
• Lifecycle management (tự động transition storage classes).
• Storage classes.

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

Đáp án đúng: Use object holds to enforce immutability for specific objects, and configure lifecycle management rules to transition objects to appropriate storage classes based on age and access patterns.

Lý do chọn đáp án này 🛠️:

• Object holds (temporary hoặc event-based) là cách chính thức và hiệu quả nhất để enforce immutability trong GCS. Chúng ngăn object bị xóa hoặc ghi đè cho đến khi hold được remove, hoàn hảo cho compliance (ví dụ: SEC Rule 17a-4, GDPR retention).
• Lifecycle management rules tự động chuyển object sang storage classes rẻ hơn dựa trên age (tuổi object) và access patterns (LiveTime, NoncurrentTime), giảm chi phí mà không cần can thiệp thủ công – rất hiệu quả và scalable cho dữ liệu lớn.
• Kết hợp hai tính năng này đáp ứng toàn bộ yêu cầu: immutability + cost reduction + retention, mà không có overhead thừa.

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

• [SAI] Configure lifecycle management rules to transition objects to appropriate storage classes based on access patterns. Set up Object Versioning for all objects to meet immutability requirements.
  ❌ Sai vì: Lifecycle rules đúng cho việc transition storage classes, nhưng Object Versioning KHÔNG enforce immutability. Versioning chỉ giữ các phiên bản cũ khi overwrite/delete, nhưng vẫn cho phép xóa toàn bộ object hoặc bucket (suspend versioning). Không phù hợp cho strict compliance, và áp dụng cho tất cả objects gây lãng phí chi phí không cần thiết.

• [SAI] Move objects to different storage classes based on their age and access patterns. Use Cloud Key Management Service (Cloud KMS) to encrypt specific objects with customer-managed encryption keys (CMEK) to meet immutability requirements.
  ❌ Sai vì: Việc move thủ công dựa trên age/access không hiệu quả (cần script/custom job, tốn kém cho dữ liệu lớn). Cloud KMS + CMEK chỉ dùng cho encryption (bảo mật dữ liệu), KHÔNG liên quan đến immutability – encryption không ngăn xóa hoặc overwrite object.

• [SAI] Create a Cloud Run function to periodically check object metadata, and move objects to the appropriate storage class based on age and access patterns. Use object holds to enforce immutability for specific objects.
  ❌ Sai vì: Object holds đúng cho immutability, nhưng dùng Cloud Run function để check metadata và move object không hiệu quả. Lifecycle rules đã làm việc này tự động, miễn phí và native, trong khi Cloud Run tốn chi phí invocation, scaling và maintenance – vi phạm yêu cầu "efficient process".

• [ĐÚNG] Use object holds to enforce immutability for specific objects, and configure lifecycle management rules to transition objects to appropriate storage classes based on age and access patterns.
  ✅ Đúng vì: Như đã giải thích ở phần đáp án đúng – kết hợp hoàn hảo, native GCS features, tự động, cost-effective và compliant (cập nhật 2026: vẫn là best practice theo Google Cloud Well-Architected Framework).

🎯 Kết luận: Đáp án đúng tối ưu hóa chi phí lên đến 99% với Archive class, đồng thời đảm bảo immutability mà không phức tạp hóa quy trình!

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

Câu hỏi mô tả một công ty thương mại điện tử (ecommerce) đang sở hữu một dataset trong BigQuery chứa dữ liệu lịch sử mua hàng của khách hàng, thông tin nhân khẩu học (demographics) và tương tác trên website. Nhiệm vụ là xây dựng mô hình machine learning (ML) để dự đoán khách hàng nào có khả năng mua hàng cao nhất trong tháng tới (purchase prediction – một bài toán phân loại nhị phân hoặc đa lớp).

Yêu cầu chính (constraints):

• Tài nguyên kỹ thuật hạn chế (limited engineering resources): Không muốn tốn nhiều công sức phát triển.
• Giảm thiểu kiến thức chuyên môn về ML (minimize the ML expertise required): Cần giải pháp đơn giản, dễ sử dụng cho người không phải chuyên gia ML.

Mục tiêu: Chọn giải pháp tích hợp sẵn trong Google Cloud, tận dụng dữ liệu đã có trong BigQuery, nhanh chóng và ít phức tạp nhất. 📈

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

Đáp án đúng: Use BigQuery ML to create a logistic regression model for purchase prediction.

Lý do:

• 🛠️ BigQuery ML cho phép xây dựng và huấn luyện mô hình ML trực tiếp bên trong BigQuery bằng SQL đơn giản (ví dụ: CREATE MODEL với LOGISTIC_REG), không cần export dữ liệu, không cần di chuyển data ra ngoài, và không yêu cầu môi trường lập trình phức tạp.
• Hoàn hảo cho limited engineering resources vì chỉ cần query SQL quen thuộc, minimize ML expertise – ngay cả data analyst cũng làm được mà không cần code Python/R sâu.
• Logistic regression lý tưởng cho binary classification (dự đoán mua/không mua), nhanh, scalable trên dữ liệu lớn trong BigQuery.
• Phù hợp dữ liệu đã sẵn trong BigQuery, hỗ trợ prediction ngay lập tức. 🚀
• Cập nhật 2026: BigQuery ML hỗ trợ remote models với Vertex AI (từ 2023+), nhưng giải pháp cơ bản này vẫn là lựa chọn tối ưu nhất cho trường hợp đơn giản.

Nguồn tham khảo:

• 📘 BigQuery ML Documentation (Google Cloud, cập nhật 2025).
• 📘 BigQuery ML Logistic Regression Tutorial.

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

• ✅ Use BigQuery ML to create a logistic regression model for purchase prediction.
  Đúng vì: Giải pháp tích hợp sẵn, zero-export data, sử dụng SQL thuần để train model ngay trong BigQuery. Ít tốn tài nguyên nhất, phù hợp limited expertise. Hoàn thành nhanh với lệnh đơn giản như CREATE OR REPLACE MODEL mydataset.purchase_model OPTIONS(model_type='logistic_reg') AS SELECT .... Siêu hiệu quả cho prediction trên terabyte dữ liệu! 🌟

• ❌ Use Vertex AI Workbench to develop a custom model for purchase prediction.
  Sai vì: Vertex AI Workbench là môi trường notebook Jupyter-like (dựa Vertex AI), yêu cầu custom code Python/TensorFlow, setup môi trường, quản lý compute resources. Tốn engineering resources cao và cần ML expertise sâu (preprocessing, hyperparameter tuning), không minimize expertise như yêu cầu. Phù hợp custom model phức tạp hơn, không phải lựa chọn đơn giản. 🖥️

• ❌ Use Colab Enterprise to develop a custom model for purchase prediction.
  Sai vì: Colab Enterprise là notebook-based IDE tích hợp Google Cloud, nhưng vẫn cần viết code custom ML (như scikit-learn hoặc TensorFlow), connect BigQuery data qua API. Yêu cầu engineering để setup pipeline, không in-place như BigQuery ML, và vẫn đòi ML knowledge cao. Không tối ưu cho limited resources. 📝

• ❌ Export the data to Cloud Storage, and use AutoML Tables to build a classification model for purchase prediction.
  Sai vì: AutoML Tables (nay là phần của Vertex AI AutoML, cập nhật 2024+) yêu cầu export dữ liệu từ BigQuery ra Cloud Storage (ETL step phức tạp), sau đó upload schema. Dù AutoML no-code, nhưng thêm overhead export/management data, tốn thời gian/resources hơn BigQuery ML (no export needed). Không phải lựa chọn minimize nhất. 💾

Kết luận tổng quát 🏆: BigQuery ML là "one-stop-shop" lý tưởng cho data-in-BigQuery, giúp accelerate ML adoption mà không cần data scientist full-time. Nếu scale lên, có thể migrate sang Vertex AI sau!

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

Câu hỏi mô tả tình huống thiết kế một pipeline xử lý dữ liệu nhận file dữ liệu từ Cloud Storage hàng ngày trước 3:00 sáng. Pipeline được chia thành các giai đoạn (stages) nối tiếp nhau (output của stage trước là input của stage sau), mỗi stage mất thời gian dài để chạy. Thỉnh thoảng có stage bị lỗi, cần sửa chữa vấn đề (ví dụ: sửa lỗi dữ liệu output của stage đó). Mục tiêu chính là đảm bảo output cuối cùng được tạo ra nhanh nhất có thể sau khi sửa lỗi, tránh lãng phí thời gian rerun toàn bộ pipeline.

📌 Yêu cầu cốt lõi: Cần một giải pháp orchestration (quản lý luồng công việc) hỗ trợ xử lý lỗi linh hoạt, cho phép chỉ rerun task/stage bị lỗi sau khi sửa, mà không phải chạy lại từ đầu toàn bộ pipeline. Điều này phù hợp với các pipeline dài, phức tạp trên Google Cloud Platform (GCP), cập nhật đến năm 2026 với Cloud Composer v3 (dựa trên Apache Airflow 2.x).

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

Đáp án đúng: Design the processing as a directed acyclic graph (DAG) in Cloud Composer. Clear the state of the failed task after correcting any stage output data errors.

Lý do chi tiết 🛠️:

• Cloud Composer (dịch vụ managed Apache Airflow trên GCP) lý tưởng cho việc mô hình hóa pipeline dưới dạng DAG (Directed Acyclic Graph) – một đồ thị các task độc lập, không chu kỳ, dễ quản lý dependencies giữa các stages.
• Khi task fail, bạn có clear state của task đó trong Airflow UI/CLI (lệnh airflow tasks clear), sau đó rerun chỉ task bị lỗi (và các task downstream nếu cần). Điều này tối ưu thời gian vì không rerun các task upstream đã thành công, đặc biệt hữu ích cho pipeline dài (mỗi stage mất lâu).
• Hỗ trợ scheduling hàng ngày (dễ trigger trước 3:00 AM qua cron), retry tự động, monitoring qua UI, và tích hợp sâu với Cloud Storage/GCS.
• Theo tài liệu GCP 2026: Cloud Composer hỗ trợ dynamic task mapping và task-level retries nâng cao, đảm bảo output cuối nhanh nhất.

Nguồn tham khảo 📘:

• Cloud Composer Documentation
• Apache Airflow DAGs & Task Retries

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

• Phương án 1 ❌:
  Design a Spark program that runs under Dataproc. Code the program to wait for user input when an error is detected. Rerun the last action after correcting any stage output data errors.
  Phân tích sai 🚫: Dataproc (Spark/Hadoop managed) phù hợp xử lý batch lớn, nhưng chờ input thủ công từ user khi lỗi làm gián đoạn tự động hóa, không scalable cho pipeline hàng ngày. Phải code thủ công logic wait/rerun, khó quản lý multi-stage (không có DAG native). Không tối ưu thời gian vì rerun action cuối có thể yêu cầu restart job toàn bộ. Không hỗ trợ clear state linh hoạt như Composer.

• Phương án 2 ❌:
  Design the pipeline as a set of PTransforms in Dataflow. Restart the pipeline after correcting any stage output data errors.
  Phân tích sai 🚫: Dataflow (Apache Beam managed) mạnh về streaming/batch với PTransforms (các bước xử lý), auto-scale tốt. Tuy nhiên, restart pipeline sẽ rerun từ đầu toàn bộ (do Dataflow là streaming job immutable), lãng phí thời gian cho stages upstream dài. Không hỗ trợ "clear state" task riêng lẻ; chỉ có checkpoint cho streaming, không lý tưởng cho batch DAG hàng ngày với lỗi occasional.

• Phương án 3 ❌:
  Design the workflow as a Cloud Workflow instance. Code the workflow to jump to a given stage based on an input parameter. Rerun the workflow after correcting any stage output data errors.
  Phân tích sai 🚫: Cloud Workflows (serverless orchestration) hỗ trợ step-based workflow với JSON/YAML, có thể jump stage qua parameter. Nhưng rerun workflow vẫn chạy lại từ đầu hoặc logic phức tạp (không có DAG UI mạnh mẽ), kém linh hoạt cho dependencies sâu và task dài. Không có "clear state" native như Airflow; phù hợp workflow ngắn, đơn giản chứ không phải pipeline data nặng (thiếu monitoring/retry sâu). Theo docs 2026, Workflows ưu tiên lightweight hơn Composer.

• Phương án 4 ✅ (Đã giải thích ở trên):
  Design the processing as a directed acyclic graph (DAG) in Cloud Composer. Clear the state of the failed task after correcting any stage output data errors.
  Tóm tắt đúng 🌟: Hoàn hảo cho yêu cầu, tối ưu tốc độ nhờ task-level rerun sau clear state.

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

Câu hỏi này thuộc lĩnh vực Google Cloud Platform (GCP), cụ thể là BigQuery và các cơ chế chia sẻ dữ liệu an toàn. Tình huống: Một đội khác trong tổ chức yêu cầu truy cập vào một dataset BigQuery. Yêu cầu chính là:

• Chia sẻ dataset với đội đó.
• Giảm thiểu rủi ro sao chép dữ liệu không được phép (tức là ngăn chặn việc export/copy dữ liệu ra ngoài).
• Tạo framework tái sử dụng cho các đội khác trong tương lai.

Mục tiêu là tìm giải pháp an toàn nhất, dễ mở rộng, sử dụng các tính năng GCP hiện đại (cập nhật đến 2026, dựa trên phiên bản BigQuery và Analytics Hub mới nhất). Giải pháp phải hỗ trợ data sharing mà không cần di chuyển dữ liệu, đồng thời kiểm soát chặt chẽ quyền export.

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

• Google Cloud Analytics Hub Documentation (cập nhật 2025-2026: Hỗ trợ private exchange với egress restrictions).
• BigQuery Data Sharing Best Practices (nhấn mạnh Analytics Hub cho sharing reusable).
• BigQuery IAM Roles (Data Viewer cho phép export).

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

Đáp án đúng: Create a private exchange using Analytics Hub with data egress restriction, and grant access to the team members.

Lý do chi tiết 🛠️:

• Analytics Hub là dịch vụ chia sẻ dữ liệu zero-copy (không copy dữ liệu), cho phép tạo private exchange chỉ trong tổ chức (không public).
• Data egress restriction (hạn chế xuất dữ liệu) ngăn chặn hoàn toàn việc query/export/copy dữ liệu ra ngoài BigQuery hoặc GCP – đây là tính năng mới nhất (2024-2026) để minimize unauthorized copying.
• Reusable framework: Exchange có thể dễ dàng grant access cho nhiều đội khác mà không thay đổi dataset gốc.
• Hoàn hảo khớp yêu cầu: An toàn cao, scalable, không di chuyển dữ liệu.

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

• [SAI] Create authorized views in the team’s Google Cloud project that is only accessible by the team.
  ❌ Sai vì: Authorized views chỉ cho phép query read-only, nhưng người dùng vẫn có thể export kết quả query ra Cloud Storage hoặc tải về (không có egress restriction). Không tạo framework reusable (phải tạo views riêng cho từng đội). Rủi ro copy dữ liệu vẫn cao.

• [ĐÚNG] Create a private exchange using Analytics Hub with data egress restriction, and grant access to the team members.
  ✅ Đúng vì: Như giải thích ở trên – zero-copy sharing, egress restriction chặn export/copy 100%, và private exchange dễ tái sử dụng cho nhiều đội. Tính năng chuẩn GCP 2026 cho enterprise data sharing.

• [SAI] Enable domain restricted sharing on the project. Grant the team members the BigQuery Data Viewer IAM role on the dataset.
  ❌ Sai vì: Domain restricted sharing chỉ giới hạn theo domain (không ngăn copy nội bộ). BigQuery Data Viewer cho phép query và export dữ liệu (jobs.export). Không reusable dễ dàng, rủi ro sao chép cao.

• [SAI] Export the dataset to a Cloud Storage bucket in the team’s Google Cloud project that is only accessible by the team.
  ❌ Sai vì: Việc export trực tiếp tạo bản copy đầy đủ vào GCS của đội kia, dẫn đến rủi ro copy không kiểm soát (họ có thể tải về hoặc chia sẻ tiếp). Không an toàn, không reusable (phải export lại mỗi lần), vi phạm yêu cầu minimize copying.

Kết luận 🎯: Giải pháp Analytics Hub là best practice mới nhất của Google Cloud cho data sharing enterprise, đảm bảo tuân thủ GDPR/SOC2 với kiểm soát egress chặt chẽ!

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

Câu hỏi mô tả một tình huống thực tế trên AWS S3: Công ty phát triển website cho phép người dùng upload và chia sẻ file video. Đặc điểm truy cập:

• Tần suất cao nhất ngay sau khi upload (frequently accessed initially).
• Giảm dần theo thời gian (less frequently over time).
• Một số file cũ vẫn rất phổ biến (some old files remain popular). Yêu cầu thiết kế hệ thống lưu trữ đơn giản (simple) và tiết kiệm chi phí (cost-effective). 📌 Mục tiêu chính: Chọn storage class tự động thích ứng với pattern truy cập không đồng đều, tránh quản lý thủ công phức tạp, ưu tiên single-region bucket để giảm chi phí (so với multi-region).

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

Đáp án đúng: Create a single-region bucket with Autoclass enabled.

Lý do 🛠️:

• S3 Intelligent-Tiering với Autoclass (tính năng tự động phân loại storage class dựa trên pattern truy cập thực tế) là giải pháp lý tưởng. Nó tự động di chuyển object giữa các tier: Frequent Access, Infrequent Access, Archive Instant Access, và các tier sâu hơn (như Deep Archive Access Tier - cập nhật mới nhất AWS năm 2024-2025).
• Phù hợp pattern: Access cao ban đầu → Frequent; giảm dần → Infrequent/Archive; file cũ popular → tự động quay về Frequent mà không cần can thiệp.
• Đơn giản: Không cần config lifecycle thủ công hay scheduler, chỉ enable Autoclass là tự động.
• Tiết kiệm chi phí: Phí monitoring thấp (~0.0025$/1000 objects), single-region tránh replication overhead. Cập nhật 2026: Autoclass hỗ trợ AI-driven tiering cho media files như video.
• Nguồn: AWS S3 Intelligent-Tiering Docs & S3 Autoclass Announcement (re:Invent 2023+).

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

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), kèm lý do đúng/sai bằng tiếng Việt:

• ✅ Create a single-region bucket with Autoclass enabled.
  🟢 Đúng vì lý do trên: Tự động, thông minh, phù hợp pattern access không dự đoán được (initial high → gradual low, occasional popular old files). Simple nhất, cost-effective với monitoring fee thấp.

• ❌ Create a single-region bucket. Configure a Cloud Scheduler job that runs every 24 hours and changes the storage class based on upload date.
  🔴 Sai vì:

  • AWS không có "Cloud Scheduler" (đó là Google Cloud; AWS dùng EventBridge Scheduler).
  • Dựa trên upload date (thời gian upload) thay vì access pattern → không xử lý được file cũ vẫn popular (vẫn bị archive sai).
  • Phức tạp (chạy job 24h), tốn compute cost, không simple/cost-effective.

• ❌ Create a single-region bucket with custom Object Lifecycle Management policies based on upload date.
  🔴 Sai vì: Lifecycle policies dựa upload date (ví dụ: sau 30 ngày → IA, 90 ngày → Glacier) không linh hoạt với pattern thực tế. File cũ popular sẽ bị archive → tăng retrieval cost/latency khi truy cập đột ngột. Phải config thủ công phức tạp, không tự động như Autoclass.

• ❌ Create a single-region bucket with Archive as the default storage class.
  🔴 Sai vì: Default Archive (Glacier/Deep Archive) có latency cao và retrieval fee đắt cho access ban đầu frequent (video mới được share nhiều). Không cost-effective cho hot data, vi phạm yêu cầu simple (phải override thủ công cho new uploads).

Kết luận 🎯: Autoclass là best practice AWS cho workload "unknown/fickle access patterns" như video sharing (theo Well-Architected Framework Storage Lens). Nguồn bổ sung: AWS S3 Best Practices.

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

Câu hỏi mô tả tình huống bạn kế thừa nhiệm vụ quản lý các pipeline streaming Dataflow trong tổ chức, nhưng chưa có quyền truy cập phù hợp. Bạn cần yêu cầu một IAM role do Google cung cấp để khởi động lại (restart) các pipeline này, và phải tuân thủ nguyên tắc least privilege (quyền hạn tối thiểu, chỉ cấp quyền cần thiết nhất để thực hiện công việc).

📘 Bối cảnh kỹ thuật:

• Dataflow là dịch vụ managed Apache Beam trên Google Cloud, dùng để xử lý dữ liệu streaming hoặc batch.
• Restart pipeline yêu cầu quyền tạo, cập nhật hoặc quản lý job (không chỉ xem hoặc chạy worker).
• Principle of least privilege: Chọn role có quyền hẹp nhất, tránh cấp quyền admin rộng rãi.
• Dựa trên tài liệu Google Cloud IAM mới nhất (cập nhật đến 2026, phiên bản Dataflow 2.x+), các role được thiết kế cụ thể cho từng nhiệm vụ.

🛠️ Mục tiêu: Xác định role IAM phù hợp nhất để restart pipeline mà không vượt quá quyền cần thiết.

✅ Đáp án đúng: Request the Dataflow Developer role

Lý do lựa chọn:

• Role Dataflow Developer (roles/dataflow.developer) cung cấp quyền tối thiểu cần thiết để quản lý job Dataflow, bao gồm tạo, cập nhật, dừng và khởi động lại pipeline (restart bằng cách update job hoặc tạo job mới).
• Nó tuân thủ least privilege vì chỉ tập trung vào phát triển và vận hành job, không cấp quyền admin toàn diện như quản lý tài nguyên compute hoặc quota.
• Phù hợp cho task "managing Dataflow streaming pipelines" như restart, theo best practice Google Cloud.

Nguồn tham khảo:

• Google Cloud Dataflow IAM Roles (cập nhật 2025).
• Dataflow Security Best Practices (khuyến nghị Developer cho developer/managers).

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

• ✅ Request the Dataflow Developer role
  Đúng 🟢: Role này cấp quyền chính xác cho việc quản lý lifecycle của job (create, update, delete, restart), bao gồm streaming pipelines. Nó bao gồm các permission như dataflow.jobs.create, dataflow.jobs.update, dataflow.jobs.get – đủ để restart mà không dư thừa quyền. Hoàn hảo cho least privilege.

• ❌ Request the Dataflow Viewer role
  Sai 🔴: Role Dataflow Viewer (roles/dataflow.viewer) chỉ cho phép xem read-only (như dataflow.jobs.list, dataflow.jobs.get), không thể restart hoặc modify job. Không đủ quyền cho task quản lý.

• ❌ Request the Dataflow Worker role
  Sai 🔴: Role Dataflow Worker (roles/dataflow.worker) dành cho service account chạy worker VM (permissions như compute và storage cho execution), không dành cho user quản lý job. User không thể dùng để restart pipeline; nó vi phạm least privilege vì không liên quan.

• ❌ Request the Dataflow Admin role
  Sai 🔴: Role Dataflow Admin (roles/dataflow.admin) cấp quyền rộng lớn (tất cả quyền Developer + quản lý service account, quota, compute resources), vi phạm least privilege. Dù có thể restart, nhưng dư thừa quyền không cần thiết cho task đơn giản.

Kết luận 🎯: Luôn ưu tiên Dataflow Developer cho quản lý pipeline theo IAM best practice Google Cloud! Nếu cần thực hành, dùng Google Cloud Console để test roles.