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

Đáp án

D — Customer-Managed Encryption Keys (CMEK) dùng Cloud Key Management Service (KMS).

Vì sao đúng

Yêu cầu tuân thủ là toàn quyền kiểm soát việc XOAY và QUẢN LÝ khoá, đồng thời dùng một dịch vụ được quản lý của Google Cloud để tạo và quản lý chúng. Đó chính xác là CMEK với Cloud KMS.

⚠ Điểm mấu chốt — ba mức quản lý khoá:

GMEK (mặc định)
    → Google tạo, Google xoay
    → bạn không phải làm gì, cũng
      không kiểm soát gì

CMEK  ← đề này
    → BẠN tạo khoá trong CLOUD KMS
    → BẠN đặt lịch xoay
    → BẠN thu hồi hoặc vô hiệu hoá được
    → Google vẫn quản lý HẠ TẦNG KMS

CSEK
    → bạn gửi khoá theo TỪNG YÊU CẦU
    → Google KHÔNG LƯU khoá
    → ⚠ chỉ áp dụng cho MỘT SỐ dịch vụ,
      KHÔNG áp dụng cho BigQuery

⚠ Cách áp CMEK cho BigQuery:

1. Tạo keyring và key trong Cloud KMS
   gcloud kms keyrings create vong-khoa \
     --location=asia-southeast1
   gcloud kms keys create khoa-bq \
     --keyring=vong-khoa \
     --location=asia-southeast1 \
     --purpose=encryption \
     --rotation-period=90d \
     --next-rotation-time=...

2. Cấp quyền cho SERVICE AGENT của BigQuery
   roles/cloudkms.cryptoKeyEncrypterDecrypter

3. Đặt khoá mặc định cho dataset
   bq update --destination_kms_key=... du_an:dataset

⚠ Sức mạnh thật sự của CMEK — vô hiệu hoá khoá:

Vô hiệu hoá hoặc huỷ khoá trong KMS
        ↓
    ⚠ Dữ liệu KHÔNG GIẢI MÃ ĐƯỢC NỮA
        ↓
    → đây là "công tắc ngắt" cho dữ liệu
    → chính là thứ mà yêu cầu tuân thủ
      thường muốn có
        ↓
    ⚠ Cũng là rủi ro: mất khoá =
      mất dữ liệu, không ai khôi phục được

Xem thêm câu #12927 (cùng lô): hỏi về tên gọi hai trạng thái dữ liệu — at rest và in transit, đều mã hoá mặc định. Câu này đi tiếp một bước: ai quản lý khoá. Hai câu bổ sung cho nhau.

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

• A (CSEK với máy chủ khoá riêng) — đây là phương án gần nhất về mức độ kiểm soát và kiểm soát còn cao hơn, nhưng đề nói rõ muốn dùng dịch vụ được quản lý của Google Cloud, còn CSEK là tự cung cấp khoá; ngoài ra CSEK không hỗ trợ BigQuery.

• C (GMEK, mặc định) — Google quản lý khoá, bạn không kiểm soát việc xoay. Ngược yêu cầu.

• B (mã hoá khi truyền bằng TLS) — bảo vệ dữ liệu trên đường truyền, còn đề hỏi về dữ liệu khi lưu.

Ghi nhớ

⚠ Ba (bốn) mức quản lý khoá — bảng phải thuộc: | Mức | Ai tạo khoá | Ai lưu khoá | Kiểm soát | |---|---|---|---| | GMEK | Google | Google | không | | CMEK | BẠN, trong Cloud KMS | Google KMS | xoay, vô hiệu hoá, thu hồi | | CSEK | BẠN, bên ngoài | KHÔNG lưu | cao nhất, ít dịch vụ hỗ trợ | | EKM | hệ thống ngoài GCP | ngoài GCP | dùng cho tuân thủ nghiêm ngặt |

Từ khoá nhận diện:

"tự quản khoá bằng dịch vụ của Google" → CMEK + Cloud KMS "tự cung cấp khoá mỗi lần gọi" → CSEK "khoá nằm ngoài Google Cloud" → Cloud EKM "mặc định, không phải làm gì" → GMEK "bảo vệ trên đường truyền" → TLS — câu hỏi khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dataset dùng khoá nào | bq show --format=prettyjson <dataset> → defaultEncryptionConfiguration | | Khoá xoay bao lâu một lần | gcloud kms keys describe → rotationPeriod | | Ai dùng khoá | audit log của Cloud KMS |

Và một điều phải cân nhắc rất kỹ trước khi bật CMEK: tách bạch quyền quản lý khoá khỏi quyền quản lý dữ liệu. Sức mạnh của CMEK nằm ở chỗ vô hiệu hoá khoá là khoá luôn dữ liệu — nhưng nếu cùng một người vừa quản khoá vừa quản dữ liệu, thì cơ chế ấy không thêm được lớp bảo vệ nào, mà chỉ thêm một cách để mất dữ liệu do nhầm lẫn.

Đáp án

B — Sao lưu tự động (automated backups) và point-in-time recovery.

Vì sao đúng

Yêu cầu là khôi phục về BẤT KỲ THỜI ĐIỂM nào trong 10 ngày qua, chính xác tới từng giây. Chỉ PITR làm được điều đó, và PITR bắt buộc phải có sao lưu tự động làm nền.

⚠ Điểm mấu chốt — PITR = bản sao lưu + nhật ký ghi:

Sao lưu tự động
        ↓
    Ảnh chụp toàn bộ CSDL,
    mỗi ngày một lần
        ↓
    + WRITE-AHEAD LOG (WAL) của PostgreSQL
      ghi LIÊN TỤC mọi thay đổi
        ↓
    Khôi phục về 10:03:15 thứ Ba:
      1. lấy bản sao lưu gần nhất TRƯỚC mốc đó
      2. PHÁT LẠI WAL tới đúng giây đó
        ↓
    ⚠ Thiếu sao lưu tự động → không có
      điểm khởi đầu → PITR không bật được

⚠ Bật và cấu hình:

gcloud sql instances patch ten-instance \
  --backup-start-time=03:00 \
  --enable-point-in-time-recovery \
  --retained-transaction-log-days=10
        ↓
    ⚠ Số ngày giữ nhật ký quyết định
      "cửa sổ" khôi phục — đề cần 10 ngày
        ↓
    Khôi phục tạo ra INSTANCE MỚI:
      gcloud sql instances clone nguon dich \
        --point-in-time='2026-09-01T10:03:15Z'

⚠ Vì sao PITR quan trọng hơn người ta tưởng:

Sao lưu hằng ngày
        ↓
    Chỉ đưa về mốc 3 giờ sáng
        ↓
    Một câu DELETE chạy nhầm lúc 10:03
    → mất TOÀN BỘ dữ liệu từ 3h tới 10h

PITR
        ↓
    Về đúng 10:03:14 — ngay TRƯỚC lệnh sai
        ↓
    → gần như không mất gì

Xem thêm câu #12914 (lô 133): cùng nói về Cloud SQL, ở đó là chọn dịch vụ CSDL. Câu này đi tiếp vào cấu hình bảo vệ dữ liệu của chính dịch vụ đó.

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

• D (sao lưu thủ công) — đây là phương án gần nhất vì cũng là sao lưu, nhưng nó chỉ cho các mốc rời rạc do bạn tự bấm, không cho khôi phục về bất kỳ giây nào. Ngoài ra sao lưu thủ công không tự hết hạn, dễ tích tụ chi phí.

• C (read replica) — dùng để giảm tải đọc và làm phương án dự phòng, nhưng nó sao chép cả sai lầm gần như tức thì — xoá nhầm trên máy chính thì replica cũng mất.

• A (nhân bản đa Region) — bảo vệ khỏi sự cố cả một Region, không giúp quay ngược thời gian.

Ghi nhớ

⚠ Bốn cơ chế bảo vệ dữ liệu của Cloud SQL — bảng phải thuộc: | Cơ chế | Bảo vệ khỏi | |---|---| | Sao lưu tự động + PITR | lỗi CON NGƯỜI, dữ liệu hỏng — quay ngược thời gian | | Cấu hình HA (regional) | hỏng một ZONE | | Read replica | quá tải đọc; thăng cấp được khi cần | | Cross-region replica | sự cố cả một REGION | | Bẫy | replica KHÔNG thay thế được sao lưu |

Từ khoá nhận diện:

"khôi phục về đúng một thời điểm bất kỳ" → PITR "chịu được hỏng một zone" → cấu hình HA "giảm tải đọc" → read replica "mất cả Region" → cross-region replica "xoá nhầm dữ liệu" → PITR — replica không cứu được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | PITR đã bật chưa | gcloud sql instances describe <ten> → pointInTimeRecoveryEnabled | | Cửa sổ khôi phục bao lâu | cùng lệnh trên → transactionLogRetentionDays | | Sao lưu gần nhất khi nào | gcloud sql backups list --instance=<ten> |

Và một việc rất nên đưa vào lịch định kỳ: thật sự chạy thử một lần khôi phục PITR. Cấu hình hiện đúng trong describe không bảo đảm quy trình khôi phục chạy trơn tru dưới áp lực — và thời điểm để phát hiện ra rằng chưa ai biết cách làm không nên là lúc dữ liệu sản xuất vừa bị xoá.

Đáp án

D — Storage Transfer Service.

Vì sao đúng

Đề có bốn manh mối: nguồn là Amazon S3, đích là Cloud Storage, truyền qua Internet, và cần một dịch vụ được quản lý, chạy nền, đáng tin cậy. Storage Transfer Service sinh ra cho đúng việc này.

⚠ Điểm mấu chốt — dịch vụ chuyên chuyển dữ liệu giữa các kho đối tượng:

Storage Transfer Service
        ↓
    Nguồn hỗ trợ sẵn:
      Amazon S3, Azure Blob Storage,
      HTTP/HTTPS, Cloud Storage khác,
      hệ thống tệp tại chỗ
        ↓
    Đích: Cloud Storage
        ↓
    Google chạy việc truyền,
    KHÔNG dùng máy của bạn
        ↓
    → tự thử lại, tự kiểm tra toàn vẹn,
      chạy song song, có báo cáo

⚠ Vì sao không nên dùng gcloud storage cp cho 10 TB:

gcloud storage cp / rsync
        ↓
    Chạy TRÊN MÁY BẠN
        ↓
    ⚠ Máy tắt, mạng rớt, phiên SSH đứt
      → việc truyền dừng
    ⚠ Dữ liệu đi QUA máy bạn:
      S3 → máy bạn → GCS
      → tốn băng thông gấp đôi
    ⚠ Phải tự lo thử lại, tự kiểm tra
        ↓
    Chấp nhận được với vài GB,
    không hợp với 10 TB

⚠ Cấu hình một job:

gcloud transfer jobs create \
  s3://bucket-nguon gs://bucket-dich \
  --source-creds-file=aws-creds.json \
  --name=chuyen-du-lieu-lich-su
        ↓
    Tuỳ chọn đáng chú ý:
      --overwrite-when=different
      --delete-from=destination-if-unique
      --include-prefixes / --exclude-prefixes
      lịch chạy lặp lại

Xem thêm câu #12939 (cùng lô): cùng là chuyển dữ liệu lớn nhưng ở đó băng thông rất hạn chế và dữ liệu 500 TB → khoá là Transfer Appliance (thiết bị vật lý). Hai khoá khác nhau vì băng thông và khối lượng khác nhau — không mâu thuẫn.

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

• C (Transfer Appliance) — đây là phương án gần nhất về "chuyển dữ liệu lớn", nhưng nó là thiết bị vật lý gửi qua đường bưu chính, dành cho khối lượng hàng trăm TB tới PB khi đường truyền không đủ. Với 10 TB qua Internet, nó chậm hơn và phức tạp hơn hẳn.

• B (gcloud storage cp) — chạy trên máy bạn, không phải dịch vụ được quản lý, không chạy nền đáng tin cậy.

• A (BigQuery Data Transfer Service) — nạp dữ liệu vào BigQuery, không phải vào Cloud Storage.

Ghi nhớ

⚠ Chọn công cụ chuyển dữ liệu — bảng phải thuộc: | Tình huống | Công cụ | |---|---| | S3/Azure/HTTP → Cloud Storage | Storage Transfer Service | | Tại chỗ → Cloud Storage, băng thông ĐỦ | Storage Transfer Service (agent) | | Hàng trăm TB, băng thông KHÔNG đủ | Transfer Appliance | | Nguồn SaaS → BigQuery | BigQuery Data Transfer Service | | CSDL → Cloud SQL | Database Migration Service | | Vài GB, làm tay | gcloud storage cp/rsync |

Từ khoá nhận diện:

"S3 → GCS, dịch vụ được quản lý" → Storage Transfer Service "băng thông hạn chế, hàng trăm TB" → Transfer Appliance "Google Ads → BigQuery" → BigQuery Data Transfer Service "MySQL → Cloud SQL" → Database Migration Service "đồng bộ định kỳ hai bucket" → Storage Transfer Service có LỊCH

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job chạy tới đâu | console → Storage Transfer → job → Runs | | Có đối tượng nào lỗi không | báo cáo lỗi của lần chạy | | Dữ liệu đã đủ chưa | so số đối tượng và tổng dung lượng hai bên |

Và một khoản chi phí rất hay bị bỏ sót khi lập kế hoạch: phí egress mà AWS tính khi dữ liệu rời S3. Storage Transfer Service miễn phí, lưu trữ ở Google Cloud thì rẻ, nhưng 10 TB đi ra khỏi AWS có giá riêng của nó — hãy tra bảng giá đó trước khi hứa hẹn con số tổng với bên tài chính.

Đáp án

A — Cloud Scheduler.

Vì sao đúng

Đề cần gọi một endpoint Cloud Run đúng 1 giờ sáng UTC mỗi ngày, bằng một dịch vụ không máy chủ, được quản lý hoàn toàn, chi phí thấp. Đó chính là mô tả của Cloud Scheduler.

⚠ Điểm mấu chốt — cron được quản lý cho toàn Google Cloud:

gcloud scheduler jobs create http bao-cao-hang-ngay \
  --schedule="0 1 * * *" \
  --time-zone="UTC" \
  --uri="https://dich-vu-abc.run.app/bao-cao" \
  --http-method=POST \
  --oidc-service-account-email=sa@du-an.iam.gserviceaccount.com \
  --location=asia-southeast1
        ↓
    ⚠ Cú pháp cron UNIX chuẩn
    ⚠ --time-zone quyết định "1 giờ sáng" ở đâu
    ⚠ OIDC token để Cloud Run xác thực

⚠ Ba đích mà Cloud Scheduler gọi được:

HTTP/HTTPS
    → Cloud Run, Cloud Run functions,
      hoặc bất kỳ endpoint nào   ← đề này

Pub/Sub
    → đẩy thông điệp vào topic

App Engine
    → gọi handler của App Engine

⚠ Xác thực tới Cloud Run — phần dễ sai nhất:

Cloud Run không cho gọi công khai
        ↓
    Scheduler dùng OIDC TOKEN
        ↓
    Service account của Scheduler cần
      roles/run.invoker
      TRÊN chính dịch vụ Cloud Run đó
        ↓
    ⚠ Thiếu quyền này → 403,
      job báo hỏng mà endpoint im lặng

⚠ Chi phí — vì sao "hiệu quả nhất":

Cloud Scheduler
    → 3 job đầu MIỄN PHÍ mỗi tháng
    → sau đó vài cent mỗi job/tháng

VM chạy cron
    → trả tiền 24/7 cho 1 phút làm việc

Cloud Composer
    → môi trường thường trực, chi phí nền lớn

Xem thêm câu #12917 (lô 133): cũng là "chạy tự động mỗi sáng", nhưng ở đó việc cần làm là một truy vấn SQL trong BigQuery → khoá là scheduled query. Câu này cần gọi một dịch vụ Cloud Run → Cloud Scheduler. Quy tắc: việc nằm gọn trong BigQuery thì dùng scheduled query; gọi ra ngoài thì dùng Cloud Scheduler.

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

• C (Cloud Composer) — đây là phương án gần nhất về mặt "điều phối theo lịch", nhưng nó là Airflow được quản lý cho luồng nhiều bước có phụ thuộc, chạy một môi trường thường trực. Quá nặng và quá đắt cho một lời gọi mỗi ngày.

• B (cron trên VM) — không phải serverless: phải nuôi máy 24/7, tự vá lỗi, tự giám sát.

• D (Cloud Logging) — dịch vụ lưu và tra cứu log, không kích hoạt được gì theo lịch.

Ghi nhớ

⚠ Chạy việc theo lịch trên Google Cloud — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | Gọi HTTP endpoint theo lịch | Cloud Scheduler | | Chạy một truy vấn BigQuery theo lịch | BigQuery scheduled query | | Chạy container tới khi xong | Cloud Run job + Scheduler | | Luồng nhiều bước có phụ thuộc | Cloud Composer | | Chuỗi vài lời gọi API | Workflows + Scheduler | | Nạp dữ liệu định kỳ từ SaaS | Data Transfer Service |

Từ khoá nhận diện:

"gọi Cloud Run đúng giờ mỗi ngày" → Cloud Scheduler "DAG, phụ thuộc phức tạp" → Cloud Composer "chỉ là một câu SQL" → scheduled query "chạy rồi thoát, không phục vụ request" → Cloud Run job "cron trên VM" → không phải serverless

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job cấu hình thế nào | gcloud scheduler jobs describe <ten> --location=<r> | | Lần chạy gần nhất ra sao | console, cột kết quả và log | | Chạy thử ngay | gcloud scheduler jobs run <ten> --location=<r> |

Và một cấu hình đáng đặt cẩn thận ngay từ đầu: --time-zone. Đề này nói rõ 1 giờ sáng UTC, nhưng rất nhiều sự cố báo cáo "chạy sai giờ" chỉ đơn giản là múi giờ của job khác múi giờ mà người đọc báo cáo đang nghĩ tới — khai tường minh luôn rẻ hơn là đi tìm hiểu về sau.

Đáp án

D — Chính sách Object Lifecycle Management (quản lý vòng đời đối tượng).

Vì sao đúng

Yêu cầu là tự động xoá mọi tệp quá 30 ngày tuổi, một cách hiệu quả nhất. Lifecycle management là cơ chế có sẵn của Cloud Storage cho đúng việc đó — không mã, không máy chủ, không chi phí.

⚠ Điểm mấu chốt — quy tắc khai báo, Google tự thi hành:

{
  "lifecycle": {
    "rule": [{
      "action": {"type": "Delete"},
      "condition": {"age": 30}
    }]
  }
}

gcloud storage buckets update gs://bucket \
  --lifecycle-file=quy-tac.json
        ↓
    ⚠ MIỄN PHÍ — không tính phí thao tác
      cho các lần xoá do lifecycle thực hiện
    ⚠ Không có mã nào phải bảo trì
    ⚠ Không có máy nào phải nuôi

⚠ So sánh ba cách làm cùng một việc:

LIFECYCLE RULE
    → khai một lần, chạy mãi
    → miễn phí, không hỏng được

CLOUD FUNCTION CHẠY HẰNG NGÀY
    → phải viết mã, phải xử lý phân trang
    → phải liệt kê CẢ BUCKET mỗi ngày
      (tốn phí thao tác LIST)
    → phải giám sát, phải sửa khi hỏng

SCRIPT TRÊN VM
    → thêm một máy phải nuôi và vá
    → tệ nhất trong ba

⚠ Vài điều cần biết về cách lifecycle hoạt động:

- Chạy theo mẻ, KHÔNG tức thì
  → có thể trễ tới 24 giờ sau khi
    điều kiện thoả
- Đánh giá MỖI NGÀY MỘT LẦN
- Xoá bằng lifecycle là VĨNH VIỄN
  → trừ khi bật OBJECT VERSIONING
- Nhiều quy tắc cùng thoả
  → hành động Delete được ưu tiên

Xem thêm câu #12588 và #12923 (lô 133): cùng cơ chế lifecycle nhưng dùng cho SetStorageClass — chuyển lớp lưu trữ theo tuổi. Ở đây là Delete. Cùng công cụ, hai hành động khác nhau.

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

• C (Cloud Function chạy hằng ngày) — đây là phương án gần nhất và chạy được thật, nhưng phải viết mã, xử lý phân trang, giám sát khi hỏng, và trả phí cho các thao tác LIST và DELETE. Nhiều công và nhiều tiền hơn cho cùng kết quả.

• B (script trên VM) — công vận hành cao nhất: nuôi máy 24/7, tự vá lỗi.

• A (Object Versioning) — làm điều NGƯỢC LẠI: giữ lại các phiên bản cũ khi đối tượng bị ghi đè hoặc xoá, khiến dung lượng tăng chứ không giảm.

Ghi nhớ

⚠ Object Lifecycle Management — bảng phải thuộc: | Hành động | Việc | |---|---| | Delete | xoá đối tượng | | SetStorageClass | chuyển lớp lưu trữ | | AbortIncompleteMultipartUpload | dọn phần tải lên dở dang | | Chi phí | MIỄN PHÍ — không tính phí thao tác | | Tần suất | đánh giá mỗi ngày, có thể trễ tới 24 giờ |

Từ khoá nhận diện:

"tự xoá file quá N ngày" → lifecycle rule Delete "tự chuyển sang lớp rẻ hơn" → lifecycle rule SetStorageClass "giữ phiên bản cũ khi ghi đè" → Object Versioning — ngược lại "không cho xoá trong N năm" → Retention Policy + Bucket Lock "dọn tải lên dở" → AbortIncompleteMultipartUpload

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket có quy tắc gì | gcloud storage buckets describe gs://b --format="value(lifecycle)" | | Quy tắc có chạy không | audit log, hoặc theo dõi số đối tượng theo thời gian | | Có bao nhiêu file sắp bị xoá | liệt kê theo tuổi trước khi áp quy tắc |

Và một bước nên làm trước khi áp quy tắc xoá lên bất kỳ bucket nào đang có dữ liệu: liệt kê thử xem quy tắc sẽ chạm vào những gì. Lifecycle không có chế độ chạy thử, và một điều kiện age: 30 thiếu matchesPrefix có thể quét sạch cả những thư mục mà bạn không hề định đụng tới.

Đáp án

D — WHERE status = 'SHIPPED'

Vì sao đúng

Yêu cầu là chỉ lấy các đơn đã giao — tức là LỌC DÒNG theo giá trị của một cột. WHERE là mệnh đề lọc dòng.

⚠ Điểm mấu chốt — mỗi mệnh đề một việc:

WHERE     → LỌC DÒNG theo giá trị cột   ← đề này
GROUP BY  → GOM nhóm để tính tổng hợp
HAVING    → lọc SAU khi đã gom nhóm
LIMIT     → cắt số dòng TRẢ VỀ, không lọc gì

⚠ Truy vấn hoàn chỉnh:

SELECT don_hang_id, khach_hang_id, tong_tien
FROM `du_an.orders`
WHERE status = 'SHIPPED';

⚠ Vì sao HAVING sai ở đây — thứ tự thực thi:

FROM → WHERE → GROUP BY → HAVING
     → SELECT → ORDER BY → LIMIT
        ↓
    HAVING chạy SAU GROUP BY
        ↓
    Không có GROUP BY thì HAVING
    hoặc báo lỗi, hoặc coi cả bảng
    là MỘT nhóm
        ↓
    ⚠ Và ngay cả khi chạy được,
      nó lọc SAU khi đã đọc và gom
      toàn bộ dữ liệu → kém hiệu quả hơn WHERE

⚠ Với BigQuery, WHERE còn có tác dụng về TIỀN:

Bảng có PHÂN VÙNG theo ngày
        ↓
    WHERE ngay_dat >= '2026-08-01'
        ↓
    → BigQuery chỉ ĐỌC các phân vùng đó
    → quét ít byte hơn → RẺ HƠN

Nhưng WHERE trên cột thường (như status)
        ↓
    → vẫn phải đọc cả cột đó
    → trừ khi bảng có PHÂN CỤM theo status

Xem thêm câu #12938 (cùng lô): cùng họ câu hỏi SQL cơ bản nhưng hỏi về tính tổng theo từng nhóm → khoá là GROUP BY. Và #12925 (lô 133) hỏi về sắp xếp → ORDER BY. Ba câu, ba mệnh đề, nhất quán.

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

• C (HAVING status = 'SHIPPED') — đây là phương án gần nhất vì cũng là mệnh đề lọc, nhưng HAVING lọc SAU khi gom nhóm và đi cùng GROUP BY. Dùng ở đây là sai ngữ nghĩa và kém hiệu quả.

• B (GROUP BY status) — GOM nhóm các dòng theo trạng thái, không loại bỏ dòng nào.

• A (LIMIT 100) — cắt số dòng trả về một cách tuỳ tiện, không hề lọc theo trạng thái.

Ghi nhớ

⚠ Các mệnh đề SQL và thứ tự thực thi — bảng phải thuộc: | Thứ tự | Mệnh đề | Việc | |---|---|---| | 1 | FROM / JOIN | nguồn dữ liệu | | 2 | WHERE | lọc DÒNG — trước khi gom nhóm | | 3 | GROUP BY | gom nhóm | | 4 | HAVING | lọc NHÓM — sau khi gom | | 5 | SELECT | chọn cột, tính bí danh | | 6 | ORDER BY | sắp xếp | | 7 | LIMIT | cắt số dòng |

Từ khoá nhận diện:

"chỉ lấy dòng thoả điều kiện" → WHERE "tính tổng theo từng nhóm" → GROUP BY "chỉ lấy nhóm có tổng > X" → HAVING "sắp xếp" → ORDER BY "xem thử vài dòng" → LIMIT

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột status có những giá trị nào | SELECT status, COUNT(*) FROM ... GROUP BY 1 | | Có khoảng trắng thừa hay khác hoa thường | SELECT DISTINCT status | | Truy vấn quét bao nhiêu | --dry_run |

Và một bước rất đáng làm trước khi viết bộ lọc trên cột trạng thái: liệt kê các giá trị thật có trong cột đó. 'SHIPPED', 'Shipped', 'shipped ' là ba giá trị khác nhau với BigQuery, và một báo cáo thiếu mất một phần ba số đơn hàng vì lý do đó trông giống hệt một báo cáo đúng.

Đáp án

B — Đặt mô hình kiểm soát truy cập của bucket thành 'Uniform' (đồng nhất).

Vì sao đúng

Yêu cầu là quyền chỉ áp ở cấp BUCKET, và vô hiệu hoá việc đặt quyền riêng cho từng đối tượng. Đó chính là định nghĩa của uniform bucket-level access.

⚠ Điểm mấu chốt — hai mô hình kiểm soát truy cập:

UNIFORM (đồng nhất)          ← khuyến nghị
        ↓
    CHỈ dùng IAM ở cấp bucket
    → ACL của từng đối tượng bị VÔ HIỆU HOÁ
    → mọi đối tượng thừa hưởng quyền của bucket
        ↓
    → đơn giản, dễ rà soát, khó cấu hình sai

FINE-GRAINED (chi tiết)
        ↓
    IAM cấp bucket + ACL riêng từng đối tượng
    → linh hoạt hơn
    → ⚠ RẤT DỄ để lộ một đối tượng
      ra công khai mà không ai biết

⚠ Bật:

Lúc tạo bucket:
  gcloud storage buckets create gs://ten-bucket \
    --uniform-bucket-level-access

Trên bucket đã có:
  gcloud storage buckets update gs://ten-bucket \
    --uniform-bucket-level-access
        ↓
    ⚠ Có 90 NGÀY để đổi ý và tắt lại
    ⚠ Sau 90 ngày thì KHÔNG QUAY LẠI ĐƯỢC

⚠ Vì sao ACL từng đối tượng là nguồn rủi ro:

Với fine-grained
        ↓
    Mỗi đối tượng có ACL riêng
        ↓
    Một lần tải lên đặt allUsers:READ
        ↓
    → MỘT tệp công khai giữa hàng triệu tệp
    → IAM policy của bucket trông vẫn ĐÚNG
    → audit bằng get-iam-policy KHÔNG THẤY
        ↓
    ⚠ Đây là nguyên nhân của rất nhiều
      vụ rò rỉ dữ liệu trên các đám mây

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

• D (fine-grained) — đây là phương án đối lập trực tiếp: nó BẬT khả năng đặt ACL riêng cho từng đối tượng, đúng thứ đề muốn tắt.

• C (IAM condition trên bucket) — cho phép cấp quyền có điều kiện (theo thời gian, theo tiền tố tên), nhưng không tắt được ACL của đối tượng.

• A (lớp lưu trữ khác nhau cho từng đối tượng) — liên quan tới chi phí lưu trữ, không liên quan gì tới quyền.

Ghi nhớ

⚠ Hai mô hình kiểm soát truy cập của bucket — bảng phải thuộc: | | Uniform | Fine-grained | |---|---|---| | Cơ chế | chỉ IAM cấp bucket | IAM + ACL từng đối tượng | | ACL đối tượng | VÔ HIỆU HOÁ | có hiệu lực | | Rà soát quyền | dễ — một chỗ duy nhất | khó — phải quét từng đối tượng | | Rủi ro lộ dữ liệu | thấp | cao | | Khuyến nghị | MẶC ĐỊNH NÊN DÙNG | chỉ khi thật sự cần | | Đổi lại | có 90 ngày để quay về fine-grained |

Từ khoá nhận diện:

"quyền chỉ ở cấp bucket, tắt ACL đối tượng" → Uniform "cần quyền riêng cho từng tệp" → fine-grained — nên tránh "cấp quyền tạm thời cho một người" → IAM condition, hoặc signed URL "chia sẻ một tệp cho người không có tài khoản" → signed URL "chặn bucket công khai toàn tổ chức" → Public Access Prevention

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket dùng mô hình nào | gcloud storage buckets describe gs://b --format="value(uniformBucketLevelAccess)" | | Có ai truy cập công khai không | get-iam-policy, tìm allUsers | | Còn bao lâu để đổi ý | trường lockedTime trong describe |

Và một điều nên biết trước khi bật uniform trên bucket đang chạy: kiểm tra xem có ứng dụng nào đang dựa vào ACL của từng đối tượng không. Bật uniform sẽ vô hiệu hoá chúng ngay lập tức, và nếu một dịch vụ đang đọc tệp nhờ ACL riêng chứ không nhờ IAM, nó sẽ bắt đầu nhận 403 mà không có thay đổi nào trong chính sách IAM để giải thích điều đó.

Đáp án

A — GROUP BY product_category

Vì sao đúng

Yêu cầu là tính tổng doanh số cho TỪNG danh mục sản phẩm. Cụm "cho từng..." luôn báo hiệu GROUP BY.

⚠ Điểm mấu chốt — truy vấn hoàn chỉnh:

SELECT product_category,
       SUM(sale_amount) AS tong_doanh_so
FROM `du_an.sales_transactions`
GROUP BY product_category;

        ↓
    GROUP BY gom các dòng CÙNG danh mục
        ↓
    SUM() tính trên TỪNG nhóm
        ↓
    Kết quả: mỗi danh mục MỘT DÒNG

⚠ Quy tắc bắt buộc — cột nào được xuất hiện trong SELECT:

Trong SELECT chỉ được có:
    1. Các cột NẰM TRONG GROUP BY
    2. Các HÀM TỔNG HỢP

⚠ SAI:
    SELECT product_category, sale_amount,
           SUM(sale_amount)
    FROM ... GROUP BY product_category
        ↓
    sale_amount không nằm trong GROUP BY
    và cũng không được bọc trong hàm tổng hợp
    → BigQuery báo lỗi

⚠ GROUP BY một mình không tính gì cả:

SELECT product_category
FROM ... GROUP BY product_category
        ↓
    → chỉ ra DANH SÁCH danh mục duy nhất
    → tương đương SELECT DISTINCT
        ↓
    ⚠ Phải có HÀM TỔNG HỢP mới có "tổng"
    → SUM, COUNT, AVG, MIN, MAX

Xem thêm câu #12936 (cùng lô): hỏi về lọc dòng → khoá WHERE. Và #12925 (lô 133): hỏi về sắp xếp → ORDER BY. Ba câu cùng họ, mỗi câu một mệnh đề, khoá nhất quán.

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

• D (HAVING SUM(sale_amount)) — đây là phương án gần nhất vì cũng liên quan tới hàm tổng hợp, nhưng HAVING LỌC các nhóm SAU khi đã gom, và nó cần GROUP BY tồn tại trước đã. Nó không tạo ra nhóm.

• B (ORDER BY sale_amount) — sắp xếp kết quả, không gom nhóm hay tính tổng.

• C (WHERE product_category) — lọc dòng; ngoài ra viết như vậy còn thiếu điều kiện so sánh.

Ghi nhớ

⚠ GROUP BY — quy tắc phải thuộc: | Quy tắc | Nội dung | |---|---| | Cột trong SELECT | phải nằm trong GROUP BY, hoặc trong hàm tổng hợp | | Kết quả | mỗi nhóm MỘT dòng | | Không có hàm tổng hợp | tương đương SELECT DISTINCT | | Lọc trước khi gom | WHERE | | Lọc sau khi gom | HAVING | | Sắp xếp kết quả | ORDER BY ở cuối |

Từ khoá nhận diện:

"tổng / trung bình / đếm CHO TỪNG..." → GROUP BY "chỉ lấy dòng thoả điều kiện" → WHERE "chỉ lấy nhóm có tổng vượt X" → HAVING "danh sách giá trị duy nhất" → DISTINCT hoặc GROUP BY "xếp hạng TRONG từng nhóm mà giữ nguyên dòng" → hàm cửa sổ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu danh mục | SELECT COUNT(DISTINCT product_category) FROM ... | | Tổng có khớp không | so SUM toàn bảng với tổng các nhóm | | Có danh mục NULL không | WHERE product_category IS NULL |

Và một chi tiết hay làm lệch báo cáo mà ít ai để ý: GROUP BY gộp tất cả các dòng có giá trị NULL vào MỘT nhóm riêng. Nếu cột danh mục có dữ liệu thiếu, bạn sẽ thấy một dòng không tên với con số đáng kể — đó không phải lỗi truy vấn mà là dấu hiệu chất lượng dữ liệu cần xử lý trước khi báo cáo được coi là đúng.

Đáp án

C — Transfer Appliance.

Vì sao đúng

Đề nêu ba điều quyết định: 500 TB, băng thông Internet hạn chế, và truyền trực tuyến sẽ mất nhiều tháng. Khi đường truyền là nút thắt, giải pháp là gửi dữ liệu bằng đường vật lý.

⚠ Điểm mấu chốt — làm phép tính băng thông:

500 TB qua đường 1 Gbps dùng hết công suất
        ↓
    500.000 GB × 8 bit / 1 Gbps
        ↓
    ≈ 4.000.000 giây ≈ 46 NGÀY
    (mà thực tế không ai dùng hết 100%
     băng thông, và văn phòng còn phải
     làm việc khác)
        ↓
    Với đường chậm hơn → NHIỀU THÁNG
        ↓
    ⚠ Đây chính là ngưỡng để chuyển sang
      Transfer Appliance

⚠ Transfer Appliance hoạt động thế nào:

1. Đặt thiết bị qua console
2. Google gửi thiết bị tới trung tâm dữ liệu
3. Cắm vào mạng nội bộ, sao dữ liệu vào
       → tốc độ mạng NỘI BỘ, không phải Internet
4. Gửi thiết bị trả lại Google
5. Google nạp dữ liệu vào Cloud Storage
6. Thiết bị được XOÁ AN TOÀN
        ↓
    Dữ liệu MÃ HOÁ trên thiết bị suốt hành trình
    → chỉ bạn giữ khoá giải mã

⚠ Dung lượng thiết bị:

Transfer Appliance TA40   → khoảng 40 TB
Transfer Appliance TA300  → khoảng 300 TB
        ↓
    500 TB → đặt NHIỀU thiết bị,
             hoặc nhiều đợt
        ↓
    Thời gian tổng thường tính bằng
    TUẦN, không phải tháng

Xem thêm câu #12933 (cùng lô): cũng chuyển dữ liệu lớn nhưng là 10 TB từ S3 qua Internet → khoá là Storage Transfer Service. Hai khoá khác nhau vì khối lượng và băng thông khác nhau, hoàn toàn nhất quán. Quy tắc: tính xem truyền trực tuyến mất bao lâu; quá vài tuần thì chuyển sang thiết bị vật lý.

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

• A (Storage Transfer Service) — đây là phương án gần nhất và là lựa chọn đúng khi băng thông đủ, nhưng nó vẫn truyền qua đường mạng. Đề nói rõ đường truyền không kham nổi.

• B (gcloud storage rsync) — cũng qua mạng, lại chạy trên máy bạn, không phải dịch vụ được quản lý.

• D (BigQuery Data Transfer Service) — nạp dữ liệu vào BigQuery từ các nguồn SaaS, không liên quan.

Ghi nhớ

⚠ Chọn cách chuyển dữ liệu theo KHỐI LƯỢNG và BĂNG THÔNG — bảng phải thuộc: | Tình huống | Công cụ | |---|---| | Vài GB, làm tay | gcloud storage cp/rsync | | TB, băng thông ĐỦ, từ đám mây khác | Storage Transfer Service | | TB, từ hệ thống tệp tại chỗ | Storage Transfer Service + agent | | Hàng trăm TB tới PB, băng thông KHÔNG đủ | Transfer Appliance | | Nguồn SaaS → BigQuery | BigQuery Data Transfer Service | | Cần đường truyền riêng lâu dài | Cloud Interconnect / Partner Interconnect |

Từ khoá nhận diện:

"băng thông hạn chế, mất nhiều tháng" → Transfer Appliance "S3 → GCS, dịch vụ được quản lý" → Storage Transfer Service "cần kết nối riêng ổn định lâu dài" → Interconnect "đồng bộ liên tục" → Storage Transfer Service có lịch "CSDL, không phải tệp" → Database Migration Service hoặc Datastream

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truyền trực tuyến mất bao lâu | tính theo băng thông thật đo được, không theo con số hợp đồng | | Dữ liệu đã tới đủ chưa | so số đối tượng và checksum | | Có bỏ sót dữ liệu mới không | chạy Storage Transfer Service cho phần delta |

Và một phần rất hay bị quên trong kế hoạch di chuyển bằng thiết bị vật lý: dữ liệu phát sinh trong lúc thiết bị đang trên đường. Bản chụp trên ổ cứng đứng yên từ lúc bạn rút cáp, nên phải có một bước đồng bộ bù qua mạng trước khi chuyển hệ thống sang — nếu không, những tuần dữ liệu mới nhất sẽ là những tuần duy nhất bị thiếu.

Đáp án

C — BigQuery cho dữ liệu danh mục sản phẩm, và Cloud Storage cho ảnh đánh giá.

Vì sao đúng

Đề có hai loại dữ liệu rất khác nhau, và nguyên tắc là mỗi loại vào đúng kho của nó.

⚠ Điểm mấu chốt — cấu trúc của dữ liệu quyết định kho lưu:

DANH MỤC SẢN PHẨM
    → CÓ CẤU TRÚC, lược đồ cố định
      (product ID, name, price, category)
    → cần TRUY VẤN và PHÂN TÍCH
        ↓
    BIGQUERY
    → kho phân tích, SQL, mở rộng vô hạn

ẢNH ĐÁNH GIÁ CỦA NGƯỜI DÙNG
    → PHI CẤU TRÚC, tệp nhị phân
    → chỉ cần lưu và lấy ra
        ↓
    CLOUD STORAGE
    → kho đối tượng, rẻ, không giới hạn

⚠ Cách nối hai kho lại với nhau:

Trong BigQuery, bảng sản phẩm có thêm cột:
    anh_danh_gia_uri STRING
        ↓
    gs://bucket-anh/review/12345.jpg
        ↓
    → BigQuery giữ SIÊU DỮ LIỆU và đường dẫn
    → Cloud Storage giữ CHÍNH TỆP
        ↓
    Muốn truy vấn cả hai như một:
      → BIGLAKE / OBJECT TABLE
      → cho phép SQL "nhìn thấy" tệp trong GCS

⚠ Vì sao KHÔNG nhét ảnh vào CSDL:

Lưu ảnh trong Cloud SQL hoặc Spanner (BLOB)
        ↓
    ⚠ Giá lưu ĐẮT HƠN GCS nhiều lần
    ⚠ Phình kích thước CSDL → sao lưu chậm
    ⚠ Không phục vụ trực tiếp cho trình duyệt
    ⚠ Không dùng được CDN
        ↓
    → luôn lưu tệp trong kho đối tượng,
      CSDL chỉ giữ ĐƯỜNG DẪN

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

• B (Cloud Storage cho danh mục, BigQuery cho ảnh) — đây là phương án bẫy chính vì đảo ngược hoàn toàn: dữ liệu có cấu trúc bị đẩy vào kho đối tượng (khó truy vấn), còn tệp nhị phân bị nhét vào kho phân tích (đắt và sai mục đích).

• A (Cloud SQL cho cả hai) — Cloud SQL là CSDL giao dịch, không phải kho phân tích; và lưu ảnh trong đó đắt và làm phình CSDL.

• D (Cloud Spanner cho cả hai) — Spanner rất đắt, dành cho giao dịch quy mô toàn cầu, và cũng không phải nơi lưu tệp nhị phân.

Ghi nhớ

⚠ Chọn kho theo LOẠI DỮ LIỆU — bảng phải thuộc: | Loại dữ liệu | Kho | |---|---| | Phi cấu trúc: ảnh, video, PDF, tệp thô | Cloud Storage | | Có cấu trúc, cần PHÂN TÍCH | BigQuery | | Có cấu trúc, GIAO DỊCH độ trễ thấp | Cloud SQL / AlloyDB / Spanner | | Bán cấu trúc, ứng dụng di động | Firestore | | NoSQL ghi cực lớn, chuỗi thời gian | Bigtable | | Bộ nhớ đệm | Memorystore |

Từ khoá nhận diện:

"ảnh, video, tệp nhị phân" → Cloud Storage "lược đồ cố định + phân tích" → BigQuery "đơn hàng, giao dịch, độ trễ thấp" → Cloud SQL "tài liệu JSON, đồng bộ thời gian thực" → Firestore "lưu ảnh trong CSDL" → luôn là phương án SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh chiếm bao nhiêu dung lượng | gcloud storage du -s gs://bucket | | Bảng BigQuery lớn cỡ nào | bq show <dataset>.<bảng> | | Đường dẫn ảnh còn hợp lệ không | đối chiếu cột URI với danh sách đối tượng |

Và một quy ước đáng thống nhất ngay từ đầu khi tách tệp khỏi siêu dữ liệu: cách đặt tên đối tượng trong bucket. Dùng một khoá ổn định gắn với id sản phẩm (review/{product_id}/{uuid}.jpg) thay vì tên tệp gốc do người dùng đặt — tên gốc trùng nhau, có ký tự lạ, và không cho biết tệp thuộc về đâu khi bạn cần dọn dẹp về sau.