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

🧩 Giải thích nội dung câu hỏi

Câu hỏi yêu cầu thiết kế một data pipeline serverless trên Google Cloud để xử lý dữ liệu theo các yêu cầu cụ thể:

• Dữ liệu được stream từ Pub/Sub (dịch vụ messaging real-time) và xử lý real-time.
• Dữ liệu được transform (biến đổi) trước khi lưu trữ.
• Lưu trữ ở nơi có thể phân tích bằng SQL qua Looker (công cụ BI hỗ trợ kết nối SQL với các kho dữ liệu).

Pipeline phải serverless (không quản lý server, tự động scale). Hình ảnh minh họa luồng: Pub/Sub → Dịch vụ 1 (xử lý/transform) → Dịch vụ 2 (lưu trữ) → Looker.
Đây là kiến trúc tiêu chuẩn cho streaming ETL (Extract-Transform-Load) trên Google Cloud, cập nhật đến năm 2026 với Dataflow (Apache Beam) hỗ trợ streaming mạnh mẽ và BigQuery làm data warehouse serverless.

📸 Phân tích nội dung hình ảnh

Hình ảnh hiển thị sơ đồ pipeline đơn giản:

• Bên trái: Icon Pub/Sub (biểu tượng các chấm kết nối, nhãn "Pub/Sub") – nguồn dữ liệu streaming.
• Mũi tên chỉ sang: Hộp "?" đầu tiên (vị trí 1, biểu tượng tròn xanh) – dịch vụ xử lý stream + transform real-time.
• Mũi tên tiếp: Hộp "?" thứ hai (vị trí 2, biểu tượng tròn xanh) – dịch vụ lưu trữ hỗ trợ SQL query.
• Bên phải: Icon Looker (biểu tượng vòng tròn xanh với chữ "o", nhãn "Looker") – công cụ visualize và query SQL.
  Sơ đồ nhấn mạnh hai dịch vụ cần chọn (1 và 2) để hoàn thiện pipeline serverless từ Pub/Sub đến Looker.

✅ Đáp án đúng: 1. Dataflow 2. BigQuery

Lý do chọn:

• Dataflow (vị trí 1): Là dịch vụ serverless dựa trên Apache Beam, chuyên stream processing real-time từ Pub/Sub. Nó hỗ trợ transform dữ liệu (ETL) với windowing, aggregation, và auto-scaling. Pipeline: Pub/Sub → Dataflow (transform) → sink.
• BigQuery (vị trí 2): Serverless data warehouse hỗ trợ streaming inserts từ Dataflow, SQL queries native, và tích hợp trực tiếp với Looker qua Looker Studio/BI (Looker Block). Dữ liệu sau transform lưu vào BigQuery tables để analyze SQL dễ dàng.
  Kiến trúc này 100% serverless, real-time, và tối ưu chi phí (pay-per-use). Đáp ứng đầy đủ yêu cầu đến phiên bản 2026 (Dataflow Flex Templates cho streaming Pub/Sub → BigQuery).

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

• 1. Dataproc Serverless 2. Bigtable
  ❌ Sai: Dataproc Serverless dành cho batch/Spark jobs, không phải real-time streaming từ Pub/Sub (thiếu connector native mạnh). Bigtable là NoSQL database (wide-column), không hỗ trợ SQL dễ dàng với Looker (cần connector phức tạp, không serverless hoàn toàn cho analytics SQL). Không phù hợp transform real-time.

• 1. Cloud Composer 2. Cloud SQL for MySQL
  ❌ Sai: Cloud Composer (Apache Airflow) là orchestrator workflow, không xử lý stream real-time (chỉ batch/scheduled). Cloud SQL for MySQL là relational DB managed nhưng không serverless thuần (cần provision instance), và kém hiệu quả cho high-volume streaming inserts. Looker kết nối được nhưng không tối ưu scale.

• 1. BigQuery 2. Analytics Hub
  ❌ Sai: BigQuery là storage/query engine, không phải processing/transform real-time (chỉ batch load hoặc streaming inserts cơ bản, thiếu transform phức tạp). Analytics Hub dùng để chia sẻ data marketplace, không phải lưu trữ chính cho pipeline (không nhận stream trực tiếp từ Pub/Sub/transform). Sai vị trí luồng.

• 1. Dataflow 2. BigQuery
  ✅ Đúng: Như giải thích trên, hoàn hảo khớp sơ đồ (Dataflow xử lý/transform stream → BigQuery lưu + SQL cho Looker). Serverless, real-time, tích hợp native.

📘 Tài liệu tham khảo

• Google Cloud Docs (2026): Dataflow Streaming Pipelines – Pub/Sub → Dataflow → BigQuery.
• BigQuery + Looker Integration: Looker on BigQuery.
• Reference Architecture: Streaming ETL with Dataflow.
• Exam guide: Google Cloud Associate Cloud Engineer/Data Analyst cert (tương tự Practitioner).

🛠️ Khuyến nghị: Sử dụng Dataflow template "Pub/Sub to BigQuery" để triển khai nhanh!

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

Câu hỏi yêu cầu xây dựng một báo cáo hàng tháng để phân tích dữ liệu hàng tồn kho (inventory data), dữ liệu này được cập nhật hàng ngày. Nhiệm vụ chính là tổng hợp (aggregate) số lượng hàng tồn kho chỉ sử dụng dữ liệu của tháng gần nhất, sau đó lưu kết quả để sử dụng trong dashboard Looker Studio.

📌 Yêu cầu cốt lõi:

• Dữ liệu động (daily updates), nên cần cơ chế tự động hoặc hiệu quả.
• Chỉ lấy tháng gần nhất (most recent month).
• Kết quả phải tự động cập nhật hoặc dễ dàng tích hợp với Looker Studio (công cụ visualization của Google Cloud).
• Sử dụng BigQuery (dịch vụ data warehouse của Google Cloud) để xử lý.

🛠️ Bối cảnh kiến thức (cập nhật đến 2026): BigQuery hỗ trợ các tính năng như materialized views (từ 2021, cải tiến mạnh mẽ với auto-refresh), partitioning (_PARTITIONDATE), và các hàm ngày tháng như DATE_SUB(), DATE_DIFF(). Phiên bản mới nhất (BigQuery 2026) nhấn mạnh materialized views cho performance cao trong analytical queries, đặc biệt với Looker Studio integration.

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

Đáp án đúng: Create a materialized view in BigQuery that uses the SUM( ) function and the DATE_SUB( ) function.

Lý do chi tiết 🏆:

• Materialized view trong BigQuery là một view được lưu trữ vật lý (pre-computed), tự động refresh (mặc định hàng giờ hoặc theo schedule tùy chỉnh), rất phù hợp cho aggregate dữ liệu động như inventory daily updates.
• SUM() để tổng hợp inventory counts.
• DATE_SUB() (ví dụ: DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH)) để filter chính xác tháng gần nhất, đảm bảo chỉ dùng dữ liệu mới nhất.
• Kết quả có thể trực tiếp kết nối với Looker Studio dashboard mà không cần chạy thủ công, tiết kiệm chi phí và thời gian.
• Ưu điểm: Hiệu suất cao (query nhanh gấp 10-100x so với view thông thường), tự động update khi base table thay đổi.

📘 Nguồn tham khảo:

• BigQuery Materialized Views Documentation (Google Cloud, cập nhật 2026).
• Looker Studio BigQuery Connector.

📋 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. Mỗi phương án được đánh giá với lý do cụ thể dựa trên tính phù hợp, hiệu suất và tự động hóa.

• Create a materialized view in BigQuery that uses the SUM( ) function and the DATE_SUB( ) function.
  ✅ Đúng (như đã giải thích ở trên). Đây là giải pháp tối ưu nhất vì tự động refresh, filter tháng gần nhất chính xác với DATE_SUB(), và tích hợp seamless với Looker Studio. Không cần can thiệp thủ công hàng tháng.

• Create a saved query in the BigQuery console that uses the SUM( ) function and the DATE_SUB( ) function. Re-run the saved query every month, and save the results to a BigQuery table.
  ❌ Sai. Saved query chỉ là query lưu sẵn, phải chạy thủ công hàng tháng (re-run), không tự động. Điều này vi phạm yêu cầu báo cáo hàng tháng tự động cho dashboard, dễ lỗi nếu quên chạy, và tốn công sức duy trì.

• Create a BigQuery table that uses the SUM( ) function and the _PARTITIONDATE filter.
  ❌ Sai. Không thể tạo table trực tiếp với SUM() và _PARTITIONDATE vì table là dữ liệu thô, không phải aggregate view. _PARTITIONDATE chỉ dùng để filter partitioned table (giả sử table đã partition theo ngày), nhưng vẫn cần query riêng để aggregate và filter tháng gần nhất. Không tự động update cho monthly report, và không hiệu quả cho dashboard real-time.

• Create a BigQuery table that uses the SUM( ) function and the DATE_DIFF( ) function.
  ❌ Sai. Tương tự, table không hỗ trợ SUM() trực tiếp như một định nghĩa (phải dùng CTAS hoặc load data). DATE_DIFF() tính khoảng cách ngày (không filter tháng gần nhất hiệu quả như DATE_SUB()), dẫn đến logic phức tạp và không chính xác cho "most recent month". Không tự động, kém hiệu suất cho daily updates.

🧠 Tóm tắt khuyến nghị: Sử dụng materialized view để đạt best practice trong BigQuery cho analytical workloads như inventory reporting. Nếu dữ liệu lớn, kết hợp partitioning/clustering để tối ưu chi phí! 🚀

🧩 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 quản lý dữ liệu trong BigQuery (dịch vụ kho dữ liệu của Google Cloud):
📊 Bạn có một tập dữ liệu (dataset) chứa dữ liệu bán hàng. Dữ liệu này được truy vấn thường xuyên trong 6 tháng đầu. Sau đó, dữ liệu không còn được truy vấn nhưng phải lưu trữ ít nhất 3 năm để tuân thủ quy định pháp lý (compliance).
🎯 Yêu cầu: Triển khai chiến lược quản lý dữ liệu đáp ứng yêu cầu truy cập (dễ truy vấn ban đầu) và tuân thủ (giữ 3 năm), đồng thời giảm thiểu chi phí (storage và query) và gánh nặng quản trị (administrative overhead).

🛠️ Mục tiêu chính:

• Tối ưu chi phí: BigQuery tính phí dựa trên dữ liệu quét (scanned) khi query, và storage class khác nhau có giá khác nhau.
• Dễ quản lý: Sử dụng partitioning/clustering để query nhanh, lifecycle policy tự động hóa xóa dữ liệu.
• Tuân thủ: Giữ dữ liệu 3 năm, xóa sau đó.

(Kiến thức dựa trên tài liệu Google Cloud cập nhật đến 2026: BigQuery partitioning 📘 BigQuery Table Design, Cloud Storage lifecycle 📘 Lifecycle Management, Coldline Archive storage classes).

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

Đáp án đúng: Partition a BigQuery table by month. After 6 months, export the data to Coldline storage. Implement a lifecycle policy to delete the data from Cloud Storage after 3 years.

Lý do:
🟢 Phương án này tối ưu hoàn hảo:

• Partition by month (chia bảng theo tháng) giúp query chỉ quét dữ liệu cần thiết trong 6 tháng đầu, giảm chi phí query lên đến 90% (theo docs BigQuery).
• Sau 6 tháng, export sang Coldline (lớp lưu trữ giá rẻ cho dữ liệu ít truy cập, ~$0.004/GB/tháng, rẻ hơn BigQuery long-term storage).
• Lifecycle policy trên Cloud Storage tự động xóa sau 3 năm, không cần quản trị thủ công, đảm bảo tuân thủ và giảm overhead.
  🎯 Hoàn toàn phù hợp yêu cầu: Truy cập nhanh ban đầu, lưu trữ rẻ lâu dài, tự động hóa cao.

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

• [SAI] Use BigQuery long-term storage for the entire dataset. Set up a Cloud Run function to delete the data from BigQuery after 3 years.
  ❌ Sai vì: BigQuery long-term storage (dữ liệu >90 ngày không query) rẻ hơn active storage nhưng vẫn đắt hơn Coldline (~$0.01/GB/tháng vs $0.004). Không partition nên query 6 tháng đầu tốn kém (quét toàn bộ bảng). Cloud Run function cần quản trị thủ công (viết code, schedule, monitor), tăng overhead. Không tối ưu chi phí và admin.

• [ĐÚNG] Partition a BigQuery table by month. After 6 months, export the data to Coldline storage. Implement a lifecycle policy to delete the data from Cloud Storage after 3 years.
  ✅ Đúng vì: Như giải thích ở trên – partition tối ưu query ban đầu, export Coldline rẻ cho lưu trữ dài hạn, lifecycle tự động xóa sau 3 năm. Giảm chi phí ~80-90% so với giữ nguyên BigQuery, zero admin sau setup.

• [SAI] Set up a scheduled query to export the data to Cloud Storage after 6 months. Write a stored procedure to delete the data from BigQuery after 3 years.
  ❌ Sai vì: Scheduled query export tốn kém (chạy query định kỳ quét dữ liệu cũ, phí scanned bytes). Stored procedure trong BigQuery cần quản trị phức tạp (viết SQL proc, schedule, handle lỗi), không tự động như lifecycle. Không partition nên query ban đầu kém hiệu quả. Tăng chi phí và overhead cao.

• [SAI] Store all data in a single BigQuery table without partitioning or lifecycle policies.
  ❌ Sai vì: Không partition → query 6 tháng đầu quét toàn bộ bảng cũ, chi phí cao vọt. Giữ mãi trong BigQuery → storage đắt đỏ lâu dài (không chuyển sang Coldline rẻ). Không lifecycle → phải xóa thủ công, vi phạm "minimum administrative overhead" và dễ quên tuân thủ 3 năm.

🏆 Kết luận & Tài liệu tham khảo

🎉 Phương án đúng cân bằng hoàn hảo giữa hiệu suất, chi phí, tuân thủ và tự động hóa – phù hợp best practices Google Cloud Data Platform 2026.

📘 Nguồn tham khảo chính (cập nhật mới nhất):

• BigQuery Partitioning & Clustering
• Cloud Storage Classes & Lifecycle
• BigQuery Storage Pricing
• Google Cloud Data Lifecycle Best Practices

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

Câu hỏi tập trung vào việc triển khai bảo mật dữ liệu dựa trên hàng (row-level security) trong Looker (một nền tảng BI của Google Cloud). Cụ thể:
Bạn đã tạo một LookML model và dashboard hiển thị chỉ số bán hàng hàng ngày cho 5 quản lý khu vực. Yêu cầu là đảm bảo mỗi quản lý chỉ thấy dữ liệu bán hàng của khu vực mình, và giải pháp phải dễ triển khai.
📌 Mục tiêu chính: Áp dụng lọc dữ liệu tự động dựa trên người dùng (user-specific filtering) mà không cần tạo nhiều bản sao thủ công, giúp dễ quản lý và mở rộng. Đây là tính năng cốt lõi của Looker để kiểm soát quyền truy cập dữ liệu nhạy cảm, phù hợp với các thực hành bảo mật hiện đại (cập nhật đến Looker phiên bản 2026, hỗ trợ LookML mạnh mẽ hơn với user attributes).

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

Đáp án đúng: Create a sales_region user attribute, and assign each manager’s region as the value of their user attribute. Add an access_filter Explore filter on the region_name dimension by using the sales_region user attribute.

Lý do chọn:
🛠️ Đây là giải pháp chuẩn và dễ triển khai nhất trong Looker, sử dụng user attributes (thuộc tính người dùng) kết hợp access_filter trên Explore.

• User attribute sales_region được gán giá trị cụ thể cho từng quản lý (ví dụ: "North", "South").
• access_filter tự động lọc dimension region_name dựa trên giá trị user attribute, áp dụng row-level security toàn cục cho model/dashboard.
  ✅ Ưu điểm: Tự động, scalable (dễ thêm user mới), không cần code phức tạp, và chỉ ảnh hưởng đến dữ liệu hiển thị (không thay đổi underlying data). Phù hợp với best practices của Looker cho multi-tenant environments.

📋 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, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm lý do cụ thể dựa trên tài liệu Looker mới nhất (2026).

• Create a sales_region user attribute, and assign each manager’s region as the value of their user attribute. Add an access_filter Explore filter on the region_name dimension by using the sales_region user attribute.
  ✅ Đúng: Như đã giải thích ở trên. Giải pháp này sử dụng access_filter – một tính năng native của LookML Explore, tự động inject filter SQL dựa trên user context. Dễ config qua Looker Admin > User Attributes, và apply một lần cho toàn model. Hoàn hảo cho yêu cầu "easy-to-implement".

• Create five different Explores with the sql_always_filter Explore filter applied on the region_name dimension. Set each region_name value to the corresponding region for each manager.
  ❌ Sai: sql_always_filter là filter cố định toàn cục cho Explore (không dynamic theo user). Bạn phải tạo 5 Explores riêng (một cho mỗi region), rồi assign thủ công cho từng manager qua quyền truy cập. 🧩 Nhược điểm: Không scalable (thêm region/manager mới phải tạo Explore mới), khó quản lý permissions, và vi phạm nguyên tắc "easy-to-implement" vì tốn công code/maintain.

• Create separate Looker dashboards for each regional manager. Set the default dashboard filter to the corresponding region for each manager.
  ❌ Sai: Tạo 5 dashboard riêng và set default filter chỉ lọc UI (không ngăn user thay đổi filter để xem data khác). 🛠️ Nhược điểm: Không phải row-level security thực sự (user vẫn query full data qua Explore), phải duplicate dashboard (khó sync updates), và không an toàn vì filter có thể bị bỏ qua. Không hiệu quả cho production.

• Create separate Looker instances for each regional manager. Copy the LookML model and dashboard to each instance. Provision viewer access to the corresponding manager.
  ❌ Sai: Tạo 5 Looker instances riêng (mỗi instance là môi trường độc lập) là giải pháp quá phức tạp và tốn kém. 📈 Nhược điểm: Chi phí cao (licensing, infra), khó deploy updates (phải copy LookML thủ công), quản lý kém (5 instances riêng lẻ), và không tận dụng multi-tenancy của Looker. Vi phạm hoàn toàn yêu cầu "easy-to-implement".

📘 Tài liệu tham khảo

• Looker Documentation (Google Cloud, cập nhật 2026):
  • Access Filters – Hướng dẫn chính thức về user attributes và access_filter.
  • User Attributes – Cách config và sử dụng.
  • Row-Level Security Best Practices – So sánh các phương pháp.
    ✅ Khuyến nghị: Trong thực tế Google Cloud Associate Data Practitioner, ưu tiên access_filter cho các case tương tự để đảm bảo compliance (ví dụ: GDPR, data isolation).

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

Câu hỏi yêu cầu thiết kế một data pipeline để ingest dữ liệu từ các định dạng file CSV, Avro và Parquet vào Cloud Storage (GCS). Dữ liệu bao gồm raw user input (dữ liệu đầu vào thô từ người dùng), và nhiệm vụ quan trọng là loại bỏ tất cả các SQL injection độc hại (các lệnh SQL độc hại) TRƯỚC KHI lưu trữ dữ liệu vào BigQuery.

📌 Điểm mấu chốt:

• Pipeline phải xử lý dữ liệu thô ngay từ đầu vì có rủi ro bảo mật từ raw user input (SQL injection có thể gây hại khi query BigQuery sau này).
• Quy trình cần transform (chuyển đổi) dữ liệu để sanitize (làm sạch) trước khi load vào đích cuối (BigQuery), sau khi đã ingest tạm vào Cloud Storage làm staging area.
• Chủ đề thuộc Google Cloud Data Processing, liên quan đến các công cụ như Dataflow, Dataprep hoặc Data Fusion để thực hiện data manipulation methodology phù hợp.
• Theo kiến thức cập nhật đến năm 2026 (Google Cloud Dataflow v2.XX và BigQuery ML updates), quy trình nhấn mạnh ETL cho các trường hợp cần transform bảo mật sớm để tránh data pollution trong warehouse.

🛠️ Yêu cầu methodology: Chọn mô hình EL/ELT/ETL/ETLT phù hợp nhất để đảm bảo dữ liệu sạch trước khi vào BigQuery.

✅ Đáp án đúng: ETL

Lý do lựa chọn:

• ETL (Extract - Transform - Load) là methodology lý tưởng vì cần Extract dữ liệu từ files (CSV/Avro/Parquet), Transform ngay lập tức để remove malicious SQL injections (sử dụng Apache Beam/Dataflow với custom UDF hoặc SQL sanitization functions), rồi mới Load vào BigQuery.
• Việc transform sớm đảm bảo dữ liệu sạch, tránh rủi ro bảo mật khi load raw data vào BigQuery (BigQuery không tự động sanitize SQL injection trong dữ liệu đầu vào).
• Trong GCP, Dataflow hỗ trợ ETL full cho batch/streaming pipelines với các connector sẵn cho GCS → BigQuery, phù hợp với yêu cầu "before storing in BigQuery". ✅

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

• EL ❌
  Sai vì: EL chỉ Extract và Load trực tiếp mà không có bước Transform. Nếu dùng EL, dữ liệu raw chứa SQL injection sẽ được load thẳng vào Cloud Storage/BigQuery, dẫn đến rủi ro bảo mật cao (dữ liệu độc hại lưu trữ lâu dài, dễ bị khai thác khi query). Không phù hợp với yêu cầu "remove all malicious SQL injections before storing".

• ELT ❌
  Sai vì: ELT Extract-Load trước (load raw data vào Cloud Storage/BigQuery), rồi Transform sau bằng SQL trong BigQuery. Tuy phổ biến cho analytics (nhờ BigQuery mạnh về ELT), nhưng vi phạm yêu cầu vì SQL injection chưa được remove trước khi storing – raw data sẽ ô nhiễm BigQuery ngay từ đầu, gây vấn đề bảo mật và hiệu suất.

• ETL ✅
  Đúng vì: Như đã giải thích ở trên, ETL transform dữ liệu (sanitize SQL injection) trước khi load vào BigQuery, đảm bảo an toàn. Dataflow hoặc Pub/Sub + Functions hỗ trợ ETL hiệu quả cho multi-format inputs (CSV/Avro/Parquet) vào GCS staging, rồi clean → BigQuery. Hoàn hảo cho raw user input nhạy cảm.

• ETLT ❌
  Sai vì: ETLT không phải là methodology chuẩn (không tồn tại trong tài liệu GCP/AWS đến 2026). Nó có thể ám chỉ Extract-Transform-Load-Transform thừa thãi, gây phức tạp không cần thiết và overhead chi phí, không giải quyết trực tiếp yêu cầu transform bảo mật sớm.

📘 Tài liệu tham khảo

• Google Cloud Dataflow Documentation (cập nhật 2025-2026): Dataflow ETL/ELT pipelines – Hướng dẫn ETL cho sanitization trước BigQuery.
• BigQuery Security Best Practices: Prevent SQL Injection – Nhấn mạnh sanitize input trước load.
• Apache Beam (Dataflow engine): Transforms for Parquet/Avro – Hỗ trợ multi-format với custom SQL sanitizers.

🧩 Kết luận: Chọn ETL để pipeline an toàn, hiệu quả! Nếu triển khai thực tế, dùng Dataflow với Beam SDK cho transform logic (ví dụ: regex hoặc ML-based injection detection).

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

Câu hỏi mô tả tình huống bạn đang làm việc với một tập dữ liệu lớn về đánh giá khách hàng lưu trữ trong Cloud Storage (GCS). Tập dữ liệu có nhiều vấn đề không nhất quán như: giá trị thiếu (missing values), kiểu dữ liệu sai (incorrect data types), và bản ghi trùng lặp (duplicate entries).
Mục tiêu: Làm sạch dữ liệu (clean the data) để đảm bảo tính chính xác và nhất quán trước khi sử dụng cho phân tích (analysis).
📌 Yêu cầu chính: Chọn phương pháp hiệu quả nhất để load dữ liệu vào BigQuery và làm sạch bằng SQL. Đây là kịch bản điển hình trong Google Cloud Data Platform, tận dụng BigQuery – dịch vụ warehouse serverless mạnh mẽ hỗ trợ batch load từ GCS và SQL-based transformation (theo tài liệu BigQuery mới nhất 2024-2026, hỗ trợ external tables, materialized views cho cleaning).

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

Đáp án đúng: Use BigQuery to batch load the data into BigQuery. Use SQL for cleaning and analysis.

🛠️ Lý do chi tiết:

• Batch load trực tiếp từ GCS vào BigQuery rất đơn giản, nhanh chóng và chi phí thấp (sử dụng bq load hoặc console/CLI). BigQuery hỗ trợ load dữ liệu thô mà không cần schema trước (schema auto-detect).
• SQL cho cleaning và analysis: BigQuery có SQL chuẩn ANSI mạnh mẽ để xử lý missing values (e.g., IFNULL, COALESCE), cast data types (e.g., SAFE_CAST), deduplicate (e.g., ROW_NUMBER() OVER() với QUALIFY), ngay trên dataset lớn (hàng TB). Không cần tool ngoài, tận dụng serverless scaling (tự động scale theo query).
• Ưu điểm theo best practices GCP 2026: Tránh overhead orchestration phức tạp, phù hợp ELT (Extract-Load-Transform) pattern.
  📘 Nguồn tham khảo:
• BigQuery Load Jobs (cập nhật 2024).
• Data Cleaning in BigQuery (SQL transformations).

📋 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). Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do cụ thể bằng tiếng Việt:

• ❌ [SAI] Use the PythonOperator in Cloud Composer to clean the data and load it into BigQuery. Use SQL for analysis.
  🧠 Lý do sai: Cloud Composer (dựa Apache Airflow) dùng PythonOperator để orchestrate workflow, không phải tool chính cho data cleaning lớn. Việc clean bằng Python (e.g., Pandas) sẽ T-MAP memory-intensive với dataset lớn (cần cluster lớn, chi phí cao), rồi mới load BigQuery. Phức tạp hơn cần thiết so với SQL native trong BigQuery. Không phải best practice cho batch cleaning (theo Airflow on GCP docs 2026).

• ✅ [ĐÚNG] Use BigQuery to batch load the data into BigQuery. Use SQL for cleaning and analysis.
  🛠️ Lý do đúng: Như đã giải thích ở trên – đơn giản, hiệu quả, serverless. Batch load từ GCS (CSV/JSON/Avro), clean bằng SQL query (e.g., CTAS - CREATE TABLE AS SELECT với transformations). Hỗ trợ partitioning/clustering tự động cho analysis nhanh.

• ❌ [SAI] Use Storage Transfer Service to move the data to a different Cloud Storage bucket. Use event triggers to invoke Cloud Run functions to load the data into BigQuery. Use SQL for analysis.
  🚫 Lý do sai: Storage Transfer Service chỉ chuyển dữ liệu giữa buckets (không clean). Event triggers + Cloud Run là cho real-time/streaming, không phù hợp batch dataset lớn (Cloud Run có limit 4GB memory/request, scale kém cho TB data). Thêm bước thừa, over-engineered và tốn kém (nhiều service invoke).

• ❌ [SAI] Use Cloud Run functions to clean the data and load it into BigQuery. Use SQL for analysis.
  ⚠️ Lý do sai: Cloud Run là serverless containers cho apps/microservices, không lý tưởng cho batch data processing lớn (limit thời gian 60p, memory 8GB/container, cần custom scaling). Clean bằng code (Python/Spark) kém hiệu quả hơn SQL BigQuery, dễ lỗi với inconsistencies. Best cho event-driven nhỏ, không phải ETL batch (theo Cloud Run limits 2026 docs).

🏆 Kết luận & Best Practices

Phương pháp đúng tận dụng BigQuery như data lakehouse (load raw → transform SQL → analyze). Nếu dataset cực lớn, bổ sung Dataflow cho streaming hoặc Dataplex cho governance (cập nhật 2026). Thực hành qua BigQuery Sandbox miễn phí! 🚀

🧩 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 Storage (GCS) (không phải AWS, mặc dù đề cập nhầm – Cloud Storage là dịch vụ lưu trữ đối tượng của Google Cloud, tương đương S3 của AWS). Nội dung: Một tổ chức bán lẻ lưu trữ dữ liệu sử dụng ứng dụng nhạy cảm (sensitive application usage data) trong Cloud Storage. Yêu cầu là mã hóa dữ liệu (encrypt the data) mà không có gánh nặng vận hành quản lý khóa mã hóa (without the operational overhead of managing encryption keys).

📌 Mục tiêu chính: Tìm giải pháp mã hóa tại chỗ (at-rest encryption) đơn giản nhất, nơi Google Cloud tự động xử lý toàn bộ việc quản lý khóa, giúp giảm thiểu công sức cho người dùng. Theo tài liệu Google Cloud cập nhật đến năm 2026, tất cả dữ liệu trong GCS đều được mã hóa mặc định bằng khóa do Google quản lý (Google-managed encryption keys - GMEK), nhưng câu hỏi yêu cầu chỉ rõ hành động cụ thể để đảm bảo không overhead.

Nguồn tham khảo chính:

• 📘 Google Cloud Storage Encryption Documentation (cập nhật 2025-2026).
• 📘 Key Management in Cloud Storage.

✅ Đáp án đúng: Use Google-managed encryption keys (GMEK)

Lý do chọn đáp án này 🛡️:
GMEK là giải pháp lý tưởng vì Google Cloud tự động quản lý toàn bộ vòng đời khóa mã hóa (tạo, xoay vòng, lưu trữ, hủy), không yêu cầu bất kỳ overhead nào từ phía khách hàng. Dữ liệu nhạy cảm sẽ được mã hóa tại chỗ ngay lập tức khi upload vào bucket GCS, hoàn toàn tuân thủ yêu cầu "không quản lý khóa". Đây là tùy chọn mặc định và được khuyến nghị cho hầu hết các trường hợp để đảm bảo bảo mật mà không phức tạp. Không cần cấu hình thêm – chỉ cần upload dữ liệu! ✅

📋 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 một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên yêu cầu "không overhead quản lý khóa" theo docs GCP mới nhất.

• ✅ Use Google-managed encryption keys (GMEK)
  🟢 Đúng: Như đã giải thích, Google chịu trách nhiệm 100% quản lý khóa (quản lý vòng đời tự động, tuân thủ tiêu chuẩn như FIPS 140-2). Không cần tạo KMS key hay cung cấp khóa từ khách hàng. Hoàn hảo cho dữ liệu nhạy cảm mà không tốn công vận hành. 📈 Hiệu suất cao, áp dụng mặc định cho mọi bucket.

• ❌ Use customer-managed encryption keys (CMEK)
  🔴 Sai: CMEK yêu cầu khách hàng tạo và quản lý khóa qua Cloud Key Management Service (Cloud KMS) 🛠️. Bạn phải thiết lập bucket với encryption=default-kms-key-name, theo dõi xoay vòng khóa, kiểm soát quyền truy cập IAM, và chịu trách nhiệm backup/hủy khóa. Điều này tạo overhead vận hành lớn, vi phạm yêu cầu câu hỏi. ❌ (Phù hợp nếu cần kiểm soát cao hơn, nhưng không phải ở đây).

• ❌ Use customer-supplied encryption keys (CSEK)
  🔴 Sai: CSEK đòi hỏi khách hàng tự cung cấp khóa mã hóa (base64-encoded) khi upload/download mỗi object qua API (ví dụ: --encryption-key flag trong gsutil). Overhead cực kỳ cao: Phải quản lý khóa ngoài GCP, mã hóa/giải mã thủ công, rủi ro mất khóa dẫn đến mất dữ liệu vĩnh viễn. Không khuyến nghị cho production, đặc biệt dữ liệu nhạy cảm. 🚫 (Đã deprecated dần từ 2024, thay bằng envelope encryption).

• ❌ Use customer-supplied encryption keys (CSEK) for the sensitive data and customer-managed encryption keys (CMEK) for the less sensitive data
  🔴 Sai: Phương án kết hợp vẫn yêu cầu quản lý kép khóa (CSEK cho dữ liệu nhạy cảm + CMEK cho dữ liệu ít nhạy cảm), tăng complexity và overhead (cấu hình riêng bucket/object classes, quản lý nhiều loại khóa). Không giải quyết vấn đề "không overhead" mà còn phức tạp hóa quy trình. Câu hỏi chỉ tập trung dữ liệu nhạy cảm, không cần phân loại. 🌀 (Không hiệu quả, vi phạm nguyên tắc đơn giản hóa bảo mật).

Kết luận tổng quát 🎯: Chọn GMEK để đạt bảo mật cao nhất với zero-effort quản lý khóa. Nếu cần tùy chỉnh nâng cao (như audit logs), mới xem CMEK. Luôn kiểm tra IAM policies và VPC Service Controls cho dữ liệu nhạy cảm! 🚀

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

Câu hỏi mô tả một tổ chức tài chính lưu trữ dữ liệu giao dịch trong BigQuery (dịch vụ kho dữ liệu của Google Cloud). Họ có yêu cầu quy định pháp lý phải giữ dữ liệu ít nhất 7 năm để phục vụ kiểm toán. Nhiệm vụ là đảm bảo dữ liệu được giữ lại đúng 7 năm theo cách hiệu quả nhất về chi phí (efficient and cost-optimized).

🛠️ Mục tiêu chính: Sử dụng tính năng retention policy (chính sách lưu giữ dữ liệu) trong BigQuery để tự động xóa dữ liệu cũ sau 7 năm, tránh tốn kém lưu trữ lâu dài không cần thiết, đồng thời tuân thủ quy định. Đây là tính năng được cập nhật mới nhất trong BigQuery (phiên bản 2024-2026), hỗ trợ granular control tại mức table hoặc dataset.

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

• BigQuery Table-Level Retention
• BigQuery Dataset-Level Retention
• Cập nhật mới nhất (2024+): BigQuery hỗ trợ retention policy linh hoạt, tối ưu hóa chi phí bằng cách tự động xóa dữ liệu mà không cần export thủ công.

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

Set the table-level retention policy in BigQuery to seven years.

Lý do:

• Retention policy ở mức table-level cho phép áp dụng chính xác trên từng bảng dữ liệu giao dịch cụ thể, đảm bảo dữ liệu chỉ được giữ đúng 7 năm mà không ảnh hưởng đến các bảng khác.
• Đây là cách hiệu quả và tối ưu chi phí nhất vì BigQuery tự động quản lý lifecycle dữ liệu (xóa dữ liệu cũ sau thời hạn), giảm dung lượng lưu trữ và chi phí query/storage mà không cần công cụ ngoài.
• Phù hợp với quy định kiểm toán, hỗ trợ Time Travel và audit logs đầy đủ. Kiến thức cập nhật 2026: Tính năng này được ưu tiên cho các workload tài chính lớn.

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

• ❌ [SAI] Create a partition by transaction date, and set the partition expiration policy to seven years.
  Giải thích sai: Partition expiration chỉ áp dụng cho bảng phân vùng (partitioned table), tự động xóa partition cũ dựa trên ngày giao dịch. Tuy nhiên, nó không phải là retention policy chuẩn cho quy định 7 năm (chỉ hỗ trợ tối đa 1 năm expiration theo mặc định, cần cấu hình thủ công phức tạp). Không cost-optimized bằng retention policy thực thụ vì vẫn tốn query overhead và không granular như table-level. Không khuyến nghị cho auditing dài hạn.

• ✅ [ĐÚNG] Set the table-level retention policy in BigQuery to seven years.
  Giải thích đúng: Như đã nêu ở phần đáp án trên – chính xác, hiệu quả, tối ưu chi phí, áp dụng trực tiếp lên bảng mà không cần export hay partition thủ công. Hỗ trợ tối đa 7 năm (có thể lên 50.000 ngày theo cập nhật mới).

• ❌ [SAI] Set the dataset-level retention policy in BigQuery to seven years.
  Giải thích sai: Dataset-level retention áp dụng toàn bộ dataset (tất cả bảng bên trong), có thể xóa nhầm dữ liệu quan trọng từ các bảng khác không cần giữ 7 năm. Không "efficient" vì thiếu granular control, dẫn đến chi phí lưu trữ cao hơn nếu dataset chứa nhiều dữ liệu tạm thời. Table-level linh hoạt hơn cho trường hợp cụ thể này.

• ❌ [SAI] Export the BigQuery tables to Cloud Storage daily, and enforce a lifecycle management policy that has a seven-year retention rule.
  Giải thích sai: Việc export hàng ngày sang Cloud Storage tốn kém (chi phí export, storage duplicate, và lifecycle rule), không efficient vì tạo bản sao dữ liệu thừa. BigQuery đã có retention built-in tốt hơn, tránh complexity và chi phí vận hành. Lifecycle ở GCS chỉ là workaround kém tối ưu cho auditing.

🧩 Kết luận: Lựa chọn table-level retention là giải pháp best practice trong Google Cloud cho compliance tài chính! Nếu cần demo code SQL để set policy: ALTER TABLE dataset.table SET OPTIONS(retention_period = INTERVAL 7 YEAR).

🧩 Giải thích nội dung câu hỏi

Câu hỏi yêu cầu thiết kế một quy trình hiệu quả bằng Python để tạo báo cáo tổng hợp doanh số hàng tuần (weekly aggregated sales report) từ dữ liệu lớn (large volume of data).

• Mục tiêu chính: Sử dụng Python để xử lý dữ liệu lớn một cách hiệu quả, tập trung vào việc tổng hợp (aggregation) như tính tổng doanh số theo tuần.
• Yêu cầu ngầm: Quy trình phải có thể lập lịch chạy hàng tuần (schedule once a week), scalable cho dữ liệu lớn (không load hết vào memory), và tận dụng các dịch vụ Google Cloud phù hợp với Python.
• Bối cảnh: Đây là bài toán batch processing điển hình trên Google Cloud, ưu tiên thư viện Python hỗ trợ dữ liệu lớn như pandas-style API mà không cần viết code phức tạp từ đầu. Kiến thức cập nhật đến 2026: BigFrames (nay là Google Cloud BigFrames) là thư viện chính thức hỗ trợ pandas API trên BigQuery/Spanner, tích hợp sâu với Colab Enterprise (nay thuộc Vertex AI Workbench).

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

• Google Cloud BigFrames documentation (cập nhật 2024-2026).
• Colab Enterprise scheduling (Vertex AI Workbench features).

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

Đáp án đúng: Create a Colab Enterprise notebook and use the bigframes.pandas library. Schedule the notebook to execute once a week.

Lý do 🛠️:

• bigframes.pandas là thư viện Python mới nhất (ra mắt 2023, cập nhật liên tục đến 2026) cho phép sử dụng API giống pandas để xử lý dữ liệu lớn (terabytes) trên BigQuery mà không cần load toàn bộ dữ liệu vào RAM – lý tưởng cho báo cáo tổng hợp hàng tuần (aggregation như groupby, sum).
• Colab Enterprise (trong Vertex AI) hỗ trợ chạy notebook Python trực tiếp, tích hợp BigFrames out-of-the-box, và có tính năng lập lịch tự động (schedule) qua UI hoặc API, chạy hàng tuần mà không cần code thêm scheduler.
• Hiệu quả cao: Code đơn giản như pandas thông thường, scale tự động, chi phí thấp cho batch job. Phù hợp nhất với "use Python to design an efficient process".

📋 Phân tí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 nội dung 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 kiến thức Google Cloud mới nhất (2026).

• Create a Cloud Run function that uses NumPy. Use Cloud Scheduler to schedule the function to run once a week.
  ❌ Sai: NumPy chỉ phù hợp dữ liệu nhỏ (in-memory), không scale cho "large volume of data" – dễ OOM (out-of-memory) khi tổng hợp dữ liệu lớn. Cloud Run là serverless container tốt cho API ngắn hạn, không tối ưu batch processing dài hơi như báo cáo hàng tuần (có thể timeout 60 phút). Cloud Scheduler chỉ trigger, không giải quyết vấn đề scale Python core.

• Create a Colab Enterprise notebook and use the bigframes.pandas library. Schedule the notebook to execute once a week.
  ✅ Đúng: Như đã giải thích ở trên. BigFrames.pandas xử lý aggregation hiệu quả trên dữ liệu lớn (push-down compute đến BigQuery), Colab Enterprise hỗ trợ schedule native (qua Vertex AI), code Python thuần túy, dễ thiết kế và maintain. Đây là best practice cho data practitioner 2026.

• Create a Cloud Data Fusion and Wrangler flow. Schedule the flow to run once a week.
  ❌ Sai: Cloud Data Fusion (nay là Data Fusion powered by CDAP) và Wrangler là no-code/low-code tool cho ETL pipeline, không sử dụng Python trực tiếp để "design" (chỉ drag-drop hoặc config YAML). Không đáp ứng yêu cầu "use Python", dù có schedule tốt cho flow hàng tuần. Phù hợp data engineer hơn data practitioner dùng Python.

• Create a Dataflow directed acyclic graph (DAG) coded in Python. Use Cloud Scheduler to schedule the code to run once a week.
  ❌ Sai: Dataflow (Apache Beam Python SDK) mạnh cho streaming/batch lớn, nhưng quá phức tạp cho báo cáo tổng hợp đơn giản (cần viết Beam pipeline, transform, I/O đầy đủ). Cloud Scheduler chỉ trigger job (phải deploy template trước), không "efficient" bằng BigFrames cho pandas-style code. Theo docs 2026, Dataflow ưu tiên cho high-throughput, không phải notebook-style report.

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

Câu hỏi mô tả tình huống: Tổ chức của bạn quyết định di chuyển workload dựa trên Apache Spark từ on-premises sang Google Cloud. Yêu cầu chính là quản lý code (các Spark jobs) mà không cần phải provision (cung cấp) và quản lý cluster riêng.

📘 Ý nghĩa cốt lõi:

• Đây là nhu cầu về giải pháp serverless cho Spark, nơi Google Cloud tự động xử lý việc scale, provision tài nguyên, và quản lý hạ tầng.
• Không muốn tự quản lý cluster (như VM, Kubernetes), mà chỉ tập trung vào code/job.
• Dựa trên kiến thức Google Cloud cập nhật đến năm 2026 (phiên bản Dataproc Serverless for Spark 2.1+ và tích hợp Batch mới nhất), giải pháp phải tận dụng các dịch vụ managed/serverless để giảm chi phí vận hành (OPEX) và tăng tốc độ triển khai.

🛠️ Bối cảnh kỹ thuật: Apache Spark dùng cho big data processing (ETL, ML). Trên Google Cloud, Dataproc là dịch vụ managed cho Spark/Hadoop, và phiên bản Serverless (ra mắt 2022, cập nhật liên tục) chính là lựa chọn lý tưởng cho yêu cầu "không quản lý cluster".

✅ Đáp án đúng: Migrate the Spark jobs to Dataproc Serverless

Lý do chọn đáp án này (theo best practices Google Cloud 2026):

• Dataproc Serverless cho phép submit Spark jobs trực tiếp mà không cần tạo hoặc quản lý cluster. Google tự động provision tài nguyên (vCPU, memory) on-demand, scale theo workload, và cleanup sau khi job hoàn thành.
• Phù hợp 100% với yêu cầu: "manage the code without needing to provision and manage your own cluster" ✅.
• Ưu điểm: Tiết kiệm 50-70% chi phí so với cluster always-on, hỗ trợ Spark 3.5+, tích hợp với Cloud Storage/IAM/Logging.
• Nguồn tham khảo: Dataproc Serverless Overview & Migration Guide (cập nhật Q1/2026).

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

• ✅ [ĐÚNG] Migrate the Spark jobs to Dataproc Serverless
  Như đã giải thích ở trên: Đây là giải pháp serverless thuần túy, chỉ cần submit job qua gcloud/CLI/API, không lo cluster. Hoàn hảo cho migration on-premises Spark! 🏆

• ❌ [SAI] Configure a Google Kubernetes Engine cluster with Spark operators, and deploy the Spark jobs
  Phương án này yêu cầu tự provision và quản lý GKE cluster (Kubernetes), cài Spark Operator để deploy jobs. Vi phạm yêu cầu "không cần provision/manage cluster" vì phải scale node pools, monitor autoscaling, upgrade Kubernetes. Phù hợp hơn cho workload custom phức tạp, nhưng tốn công quản lý. 🚫

• ❌ [SAI] Migrate the Spark jobs to Dataproc on Google Kubernetes Engine
  Dataproc on GKE (ra mắt 2023, cập nhật 2026) chạy Spark trên GKE cluster do bạn tự quản lý (qua Dataproc UI nhưng vẫn cần config GKE). Không serverless, vẫn phải handle node provisioning, networking. Không đáp ứng "without needing to provision and manage your own cluster". ❌

• ❌ [SAI] Migrate the Spark jobs to Dataproc on Compute Engine
  Đây là Dataproc truyền thống trên VM Compute Engine. Bạn phải provision cluster thủ công (master/worker nodes), config autoscaling, shutdown/startup. Rất gần với on-premises, hoàn toàn trái yêu cầu serverless/managed. Chi phí cao hơn nếu idle. 🚫

Kết luận 💡: Chọn Dataproc Serverless để migration mượt mà, scale tự động. Nếu workload lớn, kết hợp với Cloud Storage cho data lake! (Tham khảo thêm: Google Cloud Skills Boost - Dataproc Lab).