Ngân hàng đề Google Cloud Digital Leader

Câu 141 Modernize Infrastructure and Applications with Google Cloud

A development team is planning their Google Cloud architecture and one of the developers asks: "We have several applications that need custom kernel modules, specific OS libraries, and some proprietary monitoring agents installed at the system level. We also need to configure firewall rules directly on the OS and manage custom system services. Which Google Cloud compute service will give us the level of OS access we need for these requirements?"

A
Cloud Run Functions
B Compute Engine
C App Engine Standard
D Cloud Run

Xem giải thích

Đáp án

B — Compute Engine.

Vì sao đúng

Đề liệt kê bốn yêu cầu ở tầng hệ điều hành, và chỉ IaaS mới cho phép:

⚠ Bốn yêu cầu ↔ Compute Engine:

1. ⚠ "MODULE KERNEL TUỲ BIẾN"
     → cần quyền nạp module vào nhân
     → ⚠ chỉ có với máy ảo riêng

2. "THƯ VIỆN HỆ ĐIỀU HÀNH CỤ THỂ"
     → cần chọn được bản phân phối
       và phiên bản

3. "AGENT GIÁM SÁT ĐỘC QUYỀN
    cài ở TẦNG HỆ THỐNG"
     → cần quyền root

4. ⚠ "CẤU HÌNH TƯỜNG LỬA NGAY TRÊN OS
    và QUẢN DỊCH VỤ HỆ THỐNG"
     → iptables, systemd
        ↓
    → chỉ Compute Engine đáp ứng

⚠ Vì sao ba phương án kia bất khả thi:

CLOUD RUN
    → chạy container trong sandbox
    → ⚠ KHÔNG có quyền kernel
    → ⚠ KHÔNG nạp được module
    → không quản systemd

APP ENGINE STANDARD
    → ⚠ sandbox còn chặt hơn nữa
    → chỉ runtime được hỗ trợ
    → không SSH, không root

CLOUD RUN FUNCTIONS
    → ⚠ chỉ chạy một hàm
    → sai hoàn toàn loại

⚠ Module kernel — ranh giới rõ nhất:

Container DÙNG CHUNG NHÂN
với hệ điều hành chủ
        ↓
    ⚠ Không thể nạp module riêng
      vào nhân dùng chung
    ⚠ (và nếu được thì sẽ ảnh hưởng
      mọi container khác)
        ↓
    → cần MÁY ẢO có nhân RIÊNG
        ↓
    → Compute Engine

Nhất quán với #13338 (lô 140) — đề đó cũng là ứng dụng cũ đòi hệ điều hành cụ thể và cài thủ công, và cùng khoá Compute Engine. Cũng nhất quán với #13363 (lô 140) về đánh đổi kiểm soát vs dễ dùng.

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

D (Cloud Run) — phương án gần nhất trong các lựa chọn hiện đại: nó chạy container tuỳ ý, nên rất linh hoạt. Nhưng container dùng chung nhân với hệ chủ, nên không nạp được module kernel và không có quyền quản dịch vụ hệ thống.
C (App Engine Standard) — sandbox chặt nhất: không chọn OS, không SSH, không quyền root.
A (Cloud Run Functions) — chỉ chạy một hàm; sai hẳn loại bài toán.

Ghi nhớ

⚠ Mức truy cập hệ điều hành theo nền tảng — bảng phải thuộc: | Nền tảng | Quyền OS | |---|---| | ⚠ Compute Engine | ⚠ ROOT đầy đủ, kernel, systemd, SSH | | GKE (node) | root trên node nếu là Standard | | Cloud Run | ⚠ trong container, KHÔNG có kernel | | App Engine Standard | ⚠ sandbox, không SSH | | Cloud Run Functions | không |

Từ khoá nhận diện:

"module kernel, driver, systemd, iptables" → ⚠ Compute Engine "container không trạng thái" → Cloud Run "nhiều container phụ thuộc nhau" → GKE "chỉ tải mã nguồn lên" → App Engine

⚠ Vì sao container không cho quyền kernel	Lý do
Container dùng CHUNG nhân với hệ chủ
Nạp module riêng	⚠ sẽ ảnh hưởng MỌI container khác
Đó là lý do	container cách ly ở mức TIẾN TRÌNH, không phải phần cứng
Muốn có nhân riêng	⚠ phải dùng MÁY ẢO

Compute Engine cho những gì	Khả năng
Chọn image OS bất kỳ	⚠ Windows, RHEL, SUSE, image riêng
Quyền root, SSH/RDP
Custom machine type	đúng vCPU và RAM cần
GPU, TPU, Local SSD
Sole-tenant node	⚠ máy vật lý riêng cho giấy phép BYOL
Shielded VM / Confidential VM	tăng cường bảo mật
Live migration	không dừng khi Google bảo trì

⚠ Cái giá của quyền kiểm soát	Cái giá
Bạn vá hệ điều hành	⚠ VM Manager giúp làm hàng loạt
Bạn lo mở rộng	MIG + autoscaling
Bạn lo sẵn sàng cao	regional MIG + load balancer
Bạn lo giám sát	Ops Agent
Máy chạy là tính tiền	⚠ không co về 0

Thực hành tốt với Compute Engine	Thực hành
Dùng instance template + MIG	⚠ hạ tầng bất biến
Dựng image đã cài sẵn	Packer, Cloud Build
OS Login	⚠ quản SSH bằng IAM
Shielded VM	verified boot
VM Manager	quản bản vá
Recommender	rightsizing sau vài tuần

Có cách nào chạy container mà vẫn có kernel riêng không	Cách
GKE với node pool riêng	⚠ cấu hình node được, DaemonSet cài agent
GKE Sandbox (gVisor)	tăng cách ly, ⚠ vẫn không cho module kernel
Container privileged trên GKE Standard	⚠ rủi ro bảo mật cao
Kết luận	với yêu cầu như đề, VM vẫn là câu trả lời sạch nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | OS đó có image sẵn không | danh sách image công khai | | VM đã vá tới đâu | ⚠ VM Manager — báo cáo tuân thủ | | Kích cỡ máy có hợp không | Recommender sau 2–4 tuần |

Và một điều đáng cân nhắc song song với quyết định chọn Compute Engine: rà lại xem những yêu cầu đó có còn cần thiết không. Module kernel tuỳ biến và agent giám sát độc quyền đôi khi là di sản của một hệ thống cũ, và nếu thay được bằng công cụ hiện đại thì cả kiến trúc sẽ mở ra nhiều lựa chọn nhẹ nhàng hơn.

Câu 142 Modernize Infrastructure and Applications with Google Cloud

A company is migrating a database from its on-premises data center to Google Cloud. They decide to move the database workload to a managed service like Cloud SQL to reduce the operational burden of patching and backups, but they will not rewrite the application that uses the database.

Which migration strategy does this represent?

A Refactor
B Retire
C Replatform
D Rehost

Xem giải thích

Đáp án

C — Replatform.

Vì sao đúng

Đề mô tả chính xác đặc trưng của replatform: đổi nền tảng chạy để giảm gánh nặng vận hành, nhưng không viết lại ứng dụng.

⚠ Hai vế của đề:

VẾ 1 — "chuyển CSDL sang dịch vụ
        CÓ QUẢN LÝ như Cloud SQL
        để giảm gánh nặng vá và
        sao lưu"
        ↓
    ⚠ CÓ thay đổi nền tảng

VẾ 2 — "KHÔNG viết lại ứng dụng
        đang dùng CSDL đó"
        ↓
    ⚠ KHÔNG phải refactor
        ↓
    → REPLATFORM

⚠ Ba mức thay đổi — nhìn cạnh nhau:

REHOST
    MySQL tự quản → MySQL trên VM
        ↓
    ⚠ vẫn tự vá, tự sao lưu

REPLATFORM              ← đề này
    MySQL tự quản → Cloud SQL
        ↓
    ⚠ chỉ đổi chuỗi kết nối
    ⚠ Google lo vá, sao lưu, HA

REFACTOR
    Viết lại ứng dụng, tách
    microservices, chia CSDL
        ↓
    ⚠ mất hàng tháng

⚠ Vì sao replatform thường là điểm ngọt:

Công sức: vừa phải
    → đổi chuỗi kết nối, kiểm thử

Lợi ích: rất lớn
    ⚠ bỏ hẳn việc vá CSDL
    ⚠ sao lưu tự động + PITR
    ⚠ HA bằng một hộp kiểm
    ⚠ read replica trong vài phút
        ↓
    → tỉ lệ lợi ích trên công sức
      cao nhất trong ba chiến lược

⚠ Gần trùng với #13297 (lô 140) — đề đó cũng là chuyển MySQL tự quản sang Cloud SQL mà không sửa mã, và cùng khoá Replatform. Hoàn toàn nhất quán.

⚠ Đối chiếu #13370 (Rehost) và #13373 (Refactor) cùng lô này — ba câu tạo thành bộ đầy đủ. Quy tắc: không sửa gì → rehost; đổi nền tảng, không sửa mã → replatform; viết lại kiến trúc → refactor.

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

D (Rehost) — phương án gần nhất và bị nhầm nhiều: rehost là bê nguyên trạng lên VM, tức là cài MySQL trên một máy ảo và vẫn tự vá. Đề nói rõ họ dùng dịch vụ CÓ QUẢN LÝ.
A (Refactor) — viết lại ứng dụng, mà đề nói rõ họ không viết lại.
B (Retire) — bỏ hẳn; ở đây họ đang chuyển đi.

Ghi nhớ

⚠ Bộ "6 R" — bảng phải thuộc: | Chiến lược | Nội dung | |---|---| | Rehost | bê nguyên lên VM — không sửa mã | | ⚠ Replatform | ⚠ đổi sang dịch vụ có quản lý — sửa nhẹ | | Refactor | viết lại kiến trúc | | Repurchase | thay bằng SaaS | | Retire | bỏ hẳn | | Retain | giữ lại tại chỗ |

Từ khoá nhận diện:

"dịch vụ có quản lý, không sửa mã ứng dụng" → Replatform "bê nguyên lên máy ảo" → Rehost "tách microservices, viết lại" → Refactor "mua SaaS thay thế" → Repurchase

Các cặp replatform hay gặp	Từ → Sang
MySQL/PostgreSQL tự quản	→ ⚠ Cloud SQL
Máy chủ web trên VM	→ Cloud Run hoặc App Engine
Hadoop tự dựng	→ Dataproc
Kafka tự quản	→ Pub/Sub
Redis tự quản	→ Memorystore
Airflow tự dựng	→ Cloud Composer
Kho dữ liệu truyền thống	→ BigQuery

⚠ Lợi ích cụ thể khi bỏ CSDL tự quản	Lợi ích
Không còn vá OS và MySQL
Sao lưu tự động + PITR
HA bằng một hộp kiểm	⚠ tự chuyển đổi trong ~60 giây
Read replica trong vài phút
Giám sát và cảnh báo sẵn có
Nâng phiên bản có hỗ trợ

Cái giá của replatform	Cái giá
Phải kiểm thử lại	tương thích phiên bản, tham số
⚠ Mất một số quyền ở tầng CSDL	không có `SUPER` privilege
Một số plugin/extension không hỗ trợ	⚠ kiểm TRƯỚC
Khoá chân nhiều hơn rehost	giảm bằng cách dùng engine chuẩn

Công cụ di cư CSDL	Công cụ
Database Migration Service	⚠ ít gián đoạn, sao chép liên tục
`mysqldump` + import	đơn giản, có gián đoạn
Datastream	CDC liên tục
Lời khuyên	⚠ luôn thử ở staging trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phiên bản có tương thích không | kiểm danh sách Cloud SQL hỗ trợ | | Extension có chạy không | ⚠ thử ở staging | | Hiệu năng có giữ nguyên không | đo trước và sau |

Và một lý do khiến replatform thường là bước đầu tiên đáng làm nhất trong mọi kế hoạch di cư: cơ sở dữ liệu là thứ tốn công vận hành nhất mà lại dễ thay thế nhất. Đổi chuỗi kết nối mất một buổi chiều, còn thứ bạn bỏ lại là những đêm thức trắng vì vá bảo mật và khôi phục sao lưu.

Câu 143 Exploring Data Transformation with Google Cloud

An e-commerce company has customer data scattered across multiple systems: order history in a MySQL database, website clickstream data in log files, customer support tickets in a SaaS platform, and marketing campaign data in Google Ads. The executive team wants to analyze customer behavior across the entire journey—from first website visit through purchase to support interactions—to identify opportunities to improve customer retention.

How does using a cloud data warehouse like BigQuery help this organization unlock business value from its data?

A By providing a single, scalable source of truth for analysis, breaking down data silos.
B By requiring all data to be stored in simple text files.
C By restricting data access to only the CEO of the company.
D By automatically deleting any data that is more than 30 days old.

Xem giải thích

Đáp án

A — Bằng cách cung cấp một nguồn sự thật duy nhất, mở rộng được cho phân tích, phá bỏ các ốc đảo dữ liệu.

Vì sao đúng

Đề mô tả đúng bài toán silo dữ liệu: cùng một khách hàng nhưng thông tin nằm rải rác ở bốn hệ thống khác nhau, không nối được với nhau.

⚠ Vấn đề silo trong đề:

Lịch sử đơn hàng    → MySQL
Clickstream website → tệp log
Ticket hỗ trợ       → nền tảng SaaS
Dữ liệu quảng cáo   → Google Ads
        ↓
    ⚠ Bốn nơi, bốn định dạng,
      bốn cách truy cập
        ↓
    ⚠ KHÔNG trả lời được:
      "khách này từ quảng cáo nào,
       xem gì, mua gì, rồi than phiền
       chuyện gì?"

⚠ BigQuery gom lại thế nào:

MySQL      → Datastream (CDC)
Log files  → Cloud Storage → nạp
SaaS       → API hoặc connector
Google Ads → ⚠ Data Transfer Service
             (connector dựng sẵn)
        ↓
        BIGQUERY
        ↓
    ⚠ MỘT nơi, MỘT ngôn ngữ (SQL)
    ⚠ Nối được bằng `customer_id`
        ↓
    → phân tích được TOÀN BỘ
      hành trình khách hàng

⚠ Vì sao "một nguồn sự thật" đáng giá:

Không có nó
    → mỗi đội tự trích xuất
      và tự tính
    → ⚠ ba đội ra ba con số
    → họp hành cãi nhau về số liệu

Có nó
    → ⚠ một định nghĩa duy nhất
    → mọi báo cáo cùng nguồn
    → tranh luận chuyển sang
      "làm gì tiếp theo"

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

B (đòi mọi dữ liệu phải lưu ở dạng tệp văn bản đơn giản) — phương án gần nhất về mặt "cũng nói về cách lưu", nhưng sai: BigQuery nhận nhiều định dạng và có cả bảng ngoài, không đòi hỏi gì như vậy.
C (giới hạn quyền truy cập chỉ cho CEO) — ngược lại: giá trị nằm ở việc mở quyền cho đúng người với quản trị chặt chẽ.
D (tự động xoá dữ liệu quá 30 ngày) — không đúng, và trái mục tiêu phân tích hành trình dài hạn của đề.

Ghi nhớ

⚠ Giá trị của kho dữ liệu tập trung — bảng nên thuộc: | Giá trị | Nội dung | |---|---| | ⚠ Phá bỏ silo | ⚠ một nơi duy nhất cho mọi nguồn | | Một nguồn sự thật | định nghĩa chỉ số thống nhất | | Mở rộng được | ⚠ serverless, tách lưu trữ và tính toán | | Truy cập bằng SQL | ai biết SQL đều dùng được | | Quản trị tập trung | policy tag, audit log | | Nền cho ML | BigQuery ML, Vertex AI |

Từ khoá nhận diện:

"dữ liệu rải rác nhiều hệ thống" → silo → kho dữ liệu tập trung "hành trình khách hàng đầy đủ" → BigQuery "dữ liệu thô, chưa biết dùng làm gì" → data lake trên Cloud Storage "dashboard cho lãnh đạo" → Looker trên BigQuery

Cách đưa từng nguồn vào BigQuery	Nguồn → Công cụ
CSDL quan hệ	⚠ Datastream (CDC) hoặc Database Migration Service
Tệp log	Cloud Storage → batch load hoặc bảng ngoài
SaaS	⚠ BigQuery Data Transfer Service — connector sẵn
Google Ads, YouTube, GA4	⚠ Data Transfer Service — có sẵn
Sự kiện thời gian thực	Pub/Sub → Dataflow
Đám mây khác	BigQuery Omni

⚠ Nối dữ liệu từ nhiều nguồn — thách thức thật	Thách thức
⚠ Khoá nối (identity resolution)	cùng một người, ba mã khác nhau
Định dạng và đơn vị khác nhau	tiền tệ, múi giờ
Chất lượng khác nhau
Độ trễ khác nhau	nguồn này realtime, nguồn kia hằng ngày
Giải	⚠ lớp mô hình hoá (Dataform) và bảng chiều dùng chung

Tổ chức dữ liệu theo lớp	Lớp
Raw / bronze	⚠ nguyên trạng từng nguồn
Staging / silver	đã làm sạch và chuẩn hoá
Mart / gold	⚠ đã mô hình hoá cho nghiệp vụ
Công cụ	Dataform quản chuỗi biến đổi SQL
Lợi ích	làm lại được từ lớp thô khi luật đổi

⚠ Quản trị đi kèm với tập trung hoá	Việc
Policy tag cho cột PII	⚠ email, số điện thoại
Row access policy	mỗi đội chỉ thấy phần của mình
Data Access audit log
Dataplex	danh mục và chất lượng
⚠ Nguyên tắc	gom dữ liệu lại làm rủi ro tập trung theo — phải quản chặt hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có nối được khách hàng qua các nguồn không | ⚠ tỉ lệ khớp customer_id | | Ba đội hỏi cùng câu có ra cùng số không | phép thử của mô hình chung | | Dữ liệu PII đã được bảo vệ chưa | Sensitive Data Protection + policy tag |

Và một thách thức luôn xuất hiện trong loại dự án này mà đề không nhắc tới: nối đúng danh tính khách hàng qua các hệ thống. Cùng một người có thể là user_8231 trong website, customer@email.com trong hệ hỗ trợ và một mã quảng cáo khác nữa — và chất lượng của toàn bộ phân tích hành trình phụ thuộc vào việc ba mã đó có được ghép đúng hay không.

Câu 144 Exploring Data Transformation with Google Cloud

A large media company needs to store petabytes of raw, unstructured video files, audio recordings, and social media text feeds for future analysis. They do not have a predefined schema and want to keep the data in its native format.

Which Google Cloud approach is best suited for storing this type of data?

A Storing metadata in Cloud Spanner.
B Using Cloud SQL, a relational database, to enforce a strict schema on all incoming data.
C Building a data lake on Cloud Storage to hold the raw, unstructured data.
D Streaming all data directly into BigQuery for immediate analysis.

Xem giải thích

Đáp án

C — Dựng một data lake trên Cloud Storage để chứa dữ liệu thô, phi cấu trúc.

Vì sao đúng

Đề nêu bốn đặc điểm, và tất cả đều là dấu hiệu kinh điển của hồ dữ liệu:

⚠ Bốn đặc điểm ↔ data lake:

1. "HÀNG PETABYTE"
     → quy mô rất lớn, chi phí lưu
       phải rẻ

2. "VIDEO, ÂM THANH, VĂN BẢN
    mạng xã hội"
     → ⚠ dữ liệu PHI CẤU TRÚC

3. ⚠ "KHÔNG CÓ SCHEMA ĐỊNH TRƯỚC"
     → ⚠ schema-on-read

4. ⚠ "GIỮ NGUYÊN ĐỊNH DẠNG GỐC"
   + "cho PHÂN TÍCH TRONG TƯƠNG LAI"
     → ⚠ chưa biết sẽ dùng làm gì

⚠ Schema-on-write và schema-on-read:

KHO DỮ LIỆU (warehouse)
    → ⚠ phải quyết định SCHEMA
      TRƯỚC khi nạp
    → dữ liệu không khớp thì bị loại
        ↓
    ⚠ schema-on-write

HỒ DỮ LIỆU (lake)
    → ⚠ nạp NGUYÊN TRẠNG trước
    → áp schema khi ĐỌC ra dùng
        ↓
    ⚠ schema-on-read
        ↓
    → đúng nhu cầu "chưa biết
      sẽ phân tích thế nào"

⚠ Vì sao ba phương án kia không hợp:

CLOUD SQL với schema chặt
    → ⚠ ép schema lên dữ liệu
      chưa có schema — bất khả thi
    → và không lưu nổi petabyte video

STREAM THẲNG VÀO BIGQUERY
    → ⚠ BigQuery cho dữ liệu
      CÓ CẤU TRÚC
    → không phải nơi lưu file video

CHỈ LƯU METADATA Ở SPANNER
    → ⚠ metadata thì được,
      nhưng đề hỏi lưu DỮ LIỆU THÔ
    → Spanner rất đắt cho việc này

Nhất quán với #13263 (lô 138) — đề đó ghép ba khái niệm database / warehouse / data lake, và cũng mô tả hồ dữ liệu bằng đúng ba cụm "thô, định dạng gốc, thí nghiệm chưa xác định". Cũng nhất quán với #13320 (lô 140) về Cloud Storage cho dữ liệu phi cấu trúc.

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

D (stream thẳng vào BigQuery để phân tích ngay) — phương án gần nhất về mặt "cũng là nền tảng dữ liệu lớn", nhưng BigQuery dành cho dữ liệu có cấu trúc. Tệp video và âm thanh thô không thuộc về đó. (Metadata và bản chép lời thì có.)
A (chỉ lưu metadata ở Cloud Spanner) — metadata có thể ở CSDL, nhưng đề hỏi lưu dữ liệu thô, và Spanner rất đắt cho mục đích này.
B (Cloud SQL với schema chặt) — ép schema lên dữ liệu chưa có schema là bất khả thi, và CSDL quan hệ không lưu nổi hàng petabyte tệp media.

Ghi nhớ

⚠ Ba khái niệm lưu trữ dữ liệu — bảng phải thuộc: | | Database | Data Warehouse | Data Lake | |---|---|---|---| | Dữ liệu | đang diễn ra | lịch sử, đã sạch | ⚠ thô, mọi định dạng | | Schema | on-write | on-write | ⚠ on-read | | Sản phẩm | Cloud SQL, Spanner | BigQuery | ⚠ Cloud Storage | | Người dùng | ứng dụng | nhà phân tích | ⚠ nhà khoa học dữ liệu |

Từ khoá nhận diện:

"thô, định dạng gốc, chưa biết dùng làm gì" → data lake "lịch sử, báo cáo, SQL" → data warehouse "giao dịch đang diễn ra" → database "kết hợp cả hai" → ⚠ lakehouse — BigLake + Dataplex

⚠ Data lake trên Google Cloud gồm những gì	Thành phần
Cloud Storage	⚠ lớp lưu trữ thô
Dataplex	⚠ quản trị, danh mục, chất lượng
BigLake	⚠ truy vấn SQL tại chỗ, phân quyền mức cột
Dataproc / Dataflow	xử lý
Vertex AI	học máy trên dữ liệu thô
Định dạng mở	Parquet, Avro, ORC, Iceberg

⚠ Rủi ro lớn nhất: "data swamp"	Rủi ro
Đầm lầy dữ liệu	⚠ nạp vào mà không ai biết trong đó có gì
Nguyên nhân	⚠ thiếu metadata, thiếu người sở hữu
Chữa	danh mục (Dataplex), lineage, quy ước đặt tên
Nguyên tắc	⚠ hồ dữ liệu cần QUẢN TRỊ nhiều hơn kho, không phải ít hơn

Tổ chức bucket cho data lake	Cách
Phân vùng theo ngày trong đường dẫn	`raw/video/2026/09/02/`
Tách bucket theo lớp	`raw/`, `curated/`, `mart/`
Vòng đời khác nhau cho từng lớp	⚠ dữ liệu thô cũ → Coldline/Archive
Uniform bucket-level access
Gắn nhãn để quy chi phí

Khai thác dữ liệu phi cấu trúc bằng gì	Công cụ
Video Intelligence API	⚠ nội dung video
Speech-to-Text	⚠ âm thanh → văn bản
Natural Language API	văn bản mạng xã hội
Vision API	ảnh và khung hình
Gemini	⚠ đa phương thức — hiểu cả ảnh, video, văn bản
Kết quả	⚠ đổ vào BigQuery để phân tích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có biết trong hồ có gì không | ⚠ Dataplex — danh mục và mô tả | | Chi phí lưu trữ có tối ưu không | vòng đời + Storage Insights | | Ai truy cập dữ liệu nào | Data Access audit log |

Và một nguyên tắc quyết định hồ dữ liệu của bạn là tài sản hay gánh nặng: ghi metadata ngay lúc nạp, đừng để sau. Vài phút mô tả nguồn gốc và ý nghĩa của một tập dữ liệu lúc còn nhớ sẽ tiết kiệm cả tuần dò tìm sau hai năm — hoặc cứu tập dữ liệu đó khỏi số phận bị bỏ quên.

Câu 145 Scaling with Google Cloud Operations

A new manager has joined a team and needs to be able to view billing reports for their team's specific Google Cloud project, but they should not be able to view billing data for any other project or make changes to any resources. Which Google Cloud capability allows for this level of granular cost control?

A
Using the Resource Hierarchy to assign a specific "Billing Account Viewer" role to the manager for that project only.
B Creating a new billing account just for that one project.
C Sending a monthly PDF of the entire company's cloud bill to the manager.
D Giving the manager the Owner" role on the project."

Xem giải thích

Đáp án

A — Dùng phân cấp tài nguyên để gán vai "Billing Account Viewer" cho người quản lý CHỈ trên project đó.

Vì sao đúng

Đề đòi ba điều kiện, và chỉ cách này thoả cả ba:

⚠ Ba điều kiện:

1. "XEM được báo cáo thanh toán
    của project ĐỘI MÌNH"
     → cần quyền xem chi phí

2. ⚠ "KHÔNG xem được project khác"
     → ⚠ phạm vi phải HẸP

3. ⚠ "KHÔNG thay đổi được tài nguyên"
     → chỉ đọc, không sửa
        ↓
    → vai xem thanh toán, ở đúng
      phạm vi cần

⚠ Cấp quyền ở đúng cấp:

        ORGANIZATION
              │
    ┌─────────┼─────────┐
 Project A  Project B  Project C
              ↑
    ⚠ Cấp vai xem chi phí
      CHỈ ở project này
        ↓
    ⚠ Quyền KHÔNG lan sang
      project khác
    ⚠ Vai chỉ đọc → không sửa
      được tài nguyên

⚠ Vì sao ba phương án kia sai:

"TẠO TÀI KHOẢN THANH TOÁN RIÊNG
 cho một project"
    → ⚠ làm được nhưng QUÁ NẶNG
    → thêm hoá đơn, thêm quản trị
    → ⚠ không cần thiết chỉ để
      cho một người XEM

"GỬI PDF hoá đơn cả công ty
 hằng tháng"
    → ⚠ LỘ chi phí mọi project
    → vi phạm yêu cầu thứ hai
    → và bị động, không tự tra cứu được

"CẤP VAI OWNER trên project"
    → ⚠ xem được nhưng cũng
      SỬA và XOÁ được mọi thứ
    → vi phạm yêu cầu thứ ba

Nhất quán với #13371 (cùng lô này) về quyền tối thiểu và vai dựng sẵn, và với #13275 (lô 139) về cấp quyền ở đúng cấp trong phân cấp tài nguyên. Cả ba cùng một nguyên tắc.

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

D (cấp vai Owner trên project) — phương án gần nhất về mặt "chắc chắn xem được", và là cám dỗ thật trong thực tế. Nhưng Owner sửa và xoá được mọi tài nguyên và cấp quyền cho người khác — vi phạm thẳng yêu cầu "không thay đổi được gì".
B (tạo tài khoản thanh toán riêng cho một project) — làm được nhưng quá nặng: thêm hoá đơn, thêm quy trình, chỉ để cho một người xem báo cáo.
C (gửi PDF hoá đơn cả công ty) — lộ chi phí của mọi project khác, vi phạm yêu cầu, và bị động.

Ghi nhớ

⚠ Các vai liên quan tới thanh toán — bảng nên thuộc: | Vai | Quyền | |---|---| | billing.viewer | ⚠ XEM chi phí và giao dịch | | billing.user | ⚠ gắn project vào tài khoản thanh toán | | billing.admin | quản lý tài khoản thanh toán | | billing.creator | tạo tài khoản thanh toán mới | | billing.costsManager | ⚠ xem chi phí và quản ngân sách | | ⚠ Lưu ý | quyền thanh toán TÁCH BIỆT với quyền tài nguyên |

Từ khoá nhận diện:

"chỉ xem chi phí, không sửa gì" → vai xem thanh toán, phạm vi hẹp "quản ngân sách và cảnh báo" → billing.costsManager "gắn project vào tài khoản thanh toán" → billing.user "chặn cứng số tài nguyên" → quota

⚠ Ba cấp phạm vi của quyền thanh toán	Cấp
Tài khoản thanh toán	⚠ thấy MỌI project gắn vào nó
Folder	thấy các project trong folder
Project	⚠ chỉ project đó — đề này
Nguyên tắc	cấp ở cấp THẤP NHẤT đủ dùng

Cách bóc tách chi phí theo đội	Cách
⚠ Nhãn (label)	`team`, `env`, `cost-center`
Folder theo phòng ban
Project riêng cho mỗi đội	⚠ cách sạch nhất
Billing export → BigQuery	phân tích sâu
Ngân sách theo phạm vi	cảnh báo riêng cho từng đội

⚠ Vì sao KHÔNG nên tạo nhiều tài khoản thanh toán	Lý do
Thêm hoá đơn phải đối soát
Mất giảm giá theo mức dùng gộp	⚠ sustained use discount tính theo tài khoản
Khó nhìn tổng quan toàn công ty
Khi nào MỚI nên tách	pháp nhân khác nhau, đơn vị tiền tệ khác nhau

Kết hợp để kiểm soát chi phí theo đội	Việc
Vai xem chi phí ở phạm vi project	⚠ để quản lý tự theo dõi
Ngân sách + cảnh báo cho project đó
Nhãn bắt buộc
Quota nếu cần chặn cứng
Báo cáo định kỳ tự động	scheduled query từ billing export

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người đó thấy được gì | ⚠ đăng nhập bằng chính tài khoản đó và thử | | Có sửa được tài nguyên không | thử một thao tác ghi | | Có thấy project khác không | ⚠ kiểm danh sách project hiện ra |

Và một cách kiểm chứng phân quyền mà ít người làm nhưng luôn hiệu quả: tự đăng nhập bằng đúng tài khoản của người dùng cuối để xem họ thấy gì. Người quản trị vốn có sẵn mọi quyền nên không bao giờ chạm phải rào chắn mình vừa dựng — và đó là lý do rất nhiều cấu hình "trông có vẻ đúng" hoá ra không đúng.

Câu 146 Exploring Data Transformation with Google Cloud

A business analyst at an e-commerce company needs to combine sales transaction data stored in a Cloud SQL database with customer engagement metrics from a third-party marketing analytics platform to create a unified dashboard for the executive team. The analyst must merge these datasets, ensure data consistency, and prepare the information for visualization.

Which stage of the data value chain does this activity represent?

A Store
B Generate
C Analyze
D Transform

Xem giải thích

Đáp án

D — Transform (biến đổi).

Vì sao đúng

Ba việc mà nhà phân tích phải làm — gộp, đảm bảo nhất quán, chuẩn bị để trực quan hoá — đều nằm ở giai đoạn biến đổi của chuỗi giá trị dữ liệu.

⚠ Ba việc trong đề ↔ Transform:

"GỘP (merge) hai tập dữ liệu"
    → ⚠ join dữ liệu bán hàng
      với dữ liệu marketing

"ĐẢM BẢO TÍNH NHẤT QUÁN"
    → ⚠ chuẩn hoá định dạng,
      đơn vị, khoá nối

"CHUẨN BỊ để TRỰC QUAN HOÁ"
    → tổng hợp, tạo bảng mart
        ↓
    → tất cả đều là BIẾN ĐỔI

⚠ Chuỗi giá trị dữ liệu — năm giai đoạn:

1. GENERATE  → dữ liệu được SINH RA
                (giao dịch, click, cảm biến)
2. COLLECT   → thu thập, nhận vào
                (Pub/Sub, Datastream)
3. STORE     → lưu
                (Cloud Storage, BigQuery)
4. ⚠ TRANSFORM → ⚠ làm sạch, gộp,
                  chuẩn hoá, mô hình hoá
                  (Dataflow, Dataform, SQL)
5. ANALYZE   → phân tích và
                trực quan hoá
                (BigQuery, Looker)
        ↓
    Đề dừng ở "CHUẨN BỊ để
    trực quan hoá"
        ↓
    ⚠ tức là còn ở bước 4

⚠ Ranh giới với Analyze:

TRANSFORM
    → ⚠ CHUẨN BỊ dữ liệu
    → gộp, làm sạch, mô hình hoá

ANALYZE
    → ⚠ ĐẶT CÂU HỎI trên dữ liệu
      đã chuẩn bị
    → truy vấn, dashboard, ML
        ↓
    Đề nói "chuẩn bị thông tin
    ĐỂ trực quan hoá"
        ↓
    ⚠ chữ "ĐỂ" cho thấy việc
      trực quan hoá CHƯA xảy ra

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

C (Analyze) — phương án gần nhất và bị nhầm nhiều: dashboard là phân tích, nhưng đề mô tả công việc chuẩn bị TRƯỚC khi dashboard được dựng. Chữ "prepare for visualization" đặt hoạt động này ở giai đoạn trước.
A (Store) — dữ liệu đã nằm sẵn ở Cloud SQL và nền tảng marketing; việc lưu đã xong.
B (Generate) — dữ liệu đã được sinh ra từ trước bởi hệ thống giao dịch và marketing.

Ghi nhớ

⚠ Chuỗi giá trị dữ liệu — bảng phải thuộc: | Giai đoạn | Việc | Sản phẩm | |---|---|---| | Generate | dữ liệu được sinh ra | ứng dụng, cảm biến, IoT | | Collect / Ingest | thu thập | Pub/Sub, Datastream, Storage Transfer | | Store | lưu | Cloud Storage, BigQuery, Cloud SQL | | ⚠ Transform | ⚠ làm sạch, gộp, chuẩn hoá | ⚠ Dataflow, Dataform, Data Fusion | | Analyze | phân tích, trực quan hoá, ML | BigQuery, Looker, Vertex AI | | Activate | ⚠ đưa hiểu biết vào hành động | |

Từ khoá nhận diện:

"gộp, làm sạch, chuẩn hoá, chuẩn bị" → Transform "truy vấn, dashboard, dự đoán" → Analyze "nhận dữ liệu vào hệ thống" → Collect / Ingest "lưu ở đâu" → Store

Công cụ cho giai đoạn Transform	Công cụ
Dataflow	⚠ lô và luồng, cần viết Beam
Dataform	⚠ biến đổi bằng SQL, có Git và kiểm thử
Cloud Data Fusion	kéo thả, không cần mã
Dataprep	làm sạch trực quan
BigQuery SQL	biến đổi ngay trong kho
Dataproc	Spark/Hadoop

⚠ Ba việc khó nhất khi gộp dữ liệu	Việc
Khoá nối (identity resolution)	⚠ cùng một khách, hai mã khác nhau
Chuẩn hoá đơn vị và định dạng	tiền tệ, múi giờ, ngày tháng
Xử lý dữ liệu thiếu và trùng
Công cụ	Dataform assertions, Dataplex data quality

ETL và ELT — nằm ở đâu trong chuỗi	Mô hình
ETL	⚠ Transform TRƯỚC khi Store
ELT	⚠ Store trước, Transform trong kho
Trên BigQuery	ELT phổ biến hơn
Lợi ích ELT	⚠ giữ được dữ liệu thô để làm lại

Tổ chức lớp biến đổi	Lớp
Raw / bronze	nguyên trạng
Staging / silver	⚠ đã làm sạch và chuẩn hoá
Mart / gold	⚠ đã mô hình hoá cho nghiệp vụ
Công cụ	Dataform quản chuỗi phụ thuộc
Lợi ích	mỗi lớp có mục đích rõ, dễ kiểm thử

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gộp có mất bản ghi không | ⚠ so số dòng trước và sau join | | Tỉ lệ khớp khoá nối là bao nhiêu | thước đo chất lượng của việc gộp | | Dữ liệu có nhất quán không | Dataform assertions |

Và một bước rất đáng thêm vào mọi pipeline biến đổi: kiểm thử tự động cho dữ liệu. Dataform assertions cho phép khai những điều kiện phải luôn đúng — khoá không trùng, cột không rỗng, tổng khớp với nguồn — và nó bắt được lỗi ngay khi pipeline chạy, thay vì để lãnh đạo phát hiện ra qua một con số kỳ lạ trên dashboard.

Câu 147 Trust and Security with Google Cloud

A financial services company implements a defense-in-depth security strategy for their Google Cloud environment hosting customer transaction data and payment systems. This multi-layered approach combines Google's built-in infrastructure protections with customer-configured security controls.

Which of the following represents a customer-managed security layer in this defense-in-depth approach?

A The security of Google's purpose-built server hardware.
B The physical security of the Google data center buildings.
C The encryption of data on Google's internal network.
D Configuring Identity and Access Management (IAM) roles to enforce the principle of least privilege.

Xem giải thích

Đáp án

D — Cấu hình vai IAM để thực thi nguyên tắc quyền tối thiểu.

Vì sao đúng

Trong mô hình phòng thủ nhiều lớp, đề hỏi lớp nào do KHÁCH HÀNG cấu hình — và IAM là ví dụ điển hình nhất.

⚠ Ranh giới trách nhiệm:

GOOGLE LO — "an ninh CỦA đám mây"
    ⚠ An ninh vật lý trung tâm dữ liệu
    ⚠ Phần cứng máy chủ và chip Titan
    ⚠ Mã hoá trên mạng nội bộ Google
    ⚠ Hypervisor và hạ tầng
  ──────────── ranh giới ────────────
KHÁCH HÀNG LO — "an ninh TRONG đám mây"
    ⚠ IAM và phân quyền     ← đề này
    ⚠ Cấu hình dịch vụ
    ⚠ Dữ liệu và phân loại
    ⚠ Mã ứng dụng
    ⚠ Vá hệ điều hành khách (IaaS)

⚠ Ba phương án kia đều thuộc về Google:

"An ninh của PHẦN CỨNG máy chủ
 Google tự thiết kế"
    → ⚠ Google lo hoàn toàn

"An ninh VẬT LÝ của các toà nhà
 trung tâm dữ liệu"
    → ⚠ khách hàng còn không biết
      máy mình ở toà nào

"Mã hoá dữ liệu trên MẠNG NỘI BỘ
 của Google"
    → ⚠ tự động, khách không
      cấu hình gì

⚠ Vì sao IAM là lớp quan trọng nhất của khách hàng:

Các sự cố rò rỉ dữ liệu đám mây
thực tế thường do:
    ⚠ bucket để công khai
    ⚠ quyền quá rộng
    ⚠ khoá lọt vào kho mã nguồn
        ↓
    ⚠ TẤT CẢ đều nằm ở nửa
      trách nhiệm của khách hàng
        ↓
    → cấu hình IAM đúng là lớp
      phòng thủ có tác động
      lớn nhất mà bạn kiểm soát

Nhất quán với #13288 (lô 139) và #13334 (lô 140) — hai câu đó cũng về mô hình trách nhiệm chung, với vế "khách hàng vá hệ điều hành khách". Câu này nêu vế "khách hàng cấu hình IAM". Cả ba nhất quán.

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

C (mã hoá dữ liệu trên mạng nội bộ của Google) — phương án gần nhất về mặt "cũng là biện pháp bảo mật thật", nhưng nó do Google thực hiện tự động; khách hàng không cấu hình và không tắt được.
A (an ninh phần cứng máy chủ Google) và B (an ninh vật lý trung tâm dữ liệu) — đều hoàn toàn thuộc trách nhiệm Google.

Ghi nhớ

⚠ Mô hình trách nhiệm chung — bảng phải thuộc: | Tầng | Ai lo | |---|---| | Vật lý, phần cứng, hypervisor | Google | | Mã hoá hạ tầng và mạng nội bộ | Google | | ⚠ IAM và phân quyền | ⚠ KHÁCH HÀNG | | ⚠ Cấu hình dịch vụ | ⚠ KHÁCH HÀNG | | ⚠ Dữ liệu và phân loại | ⚠ KHÁCH HÀNG — ở MỌI mô hình | | Hệ điều hành khách | ⚠ khách hàng với IaaS |

Từ khoá nhận diện:

"cấu hình IAM, phân quyền, bucket" → trách nhiệm khách hàng "phần cứng, vật lý, hypervisor" → Google "an ninh CỦA đám mây" → Google "an ninh TRONG đám mây" → khách hàng

Các lớp phòng thủ do khách hàng cấu hình	Lớp
IAM quyền tối thiểu	⚠ lớp nền tảng nhất
Organization Policy	⚠ cấm hành vi ở mọi project
VPC firewall và Private IP
Cloud Armor	chống DDoS và WAF
VPC Service Controls	vành đai chống rò rỉ
CMEK	khoá mã hoá tự quản
Policy tag, row access policy	mức cột và dòng
Audit log	⚠ phải BẬT Data Access log

⚠ Ba nguyên nhân sự cố thực tế	Nguyên nhân
Cấu hình sai	⚠ bucket công khai — phổ biến nhất
Quyền quá rộng	Owner cho cả công ty
Bí mật lọt vào kho mã
Điểm chung	⚠ KHÔNG cái nào là lỗi của Google

Phòng thủ nhiều lớp — đủ bộ	Lớp
Biên	Cloud Armor
Mạng	VPC, firewall, Private Service Connect
Danh tính	⚠ IAM, MFA, IAP
Ứng dụng	mã an toàn, quét lỗ hổng
Dữ liệu	mã hoá, policy tag, DLP
Giám sát	Security Command Center, audit log
⚠ Nguyên tắc	không lớp nào đủ một mình

Kiểm chứng nửa trách nhiệm của mình	Công cụ
Security Command Center	⚠ phát hiện cấu hình sai
IAM Recommender	quyền quá rộng
Policy Analyzer	ai có quyền gì trên tài nguyên nào
Access Transparency	khi nhân viên Google truy cập
Secret scanning	bí mật trong kho mã

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bucket nào công khai không | ⚠ Security Command Center | | Có bao nhiêu Owner | càng ít càng tốt | | Data Access log đã bật chưa | ⚠ không bật mặc định, có phí |

Và một điều rất đáng nhớ về mô hình trách nhiệm chung: phần Google lo hầu như không bao giờ là nguyên nhân của sự cố. Các vụ rò rỉ dữ liệu đám mây nổi tiếng gần như đều bắt nguồn từ nửa còn lại — nên phần lớn nỗ lực bảo mật của bạn nên dồn vào đúng những lớp mà bạn cấu hình được.

Câu 148 Digital Transformation with Google Cloud

A company is evaluating different cloud computing models. They want a solution where the cloud provider manages the underlying infrastructure, operating system, and runtime environment, allowing their developers to focus solely on deploying application code.

Which model meets this requirement?

A Software as a Service (SaaS)
B Platform as a Service (PaaS)
C Infrastructure as a Service (IaaS)
D On-premises

Xem giải thích

Đáp án

B — Platform as a Service (PaaS).

Vì sao đúng

Đề liệt kê đúng ba tầng mà PaaS gánh hộ và đúng phần còn lại cho bạn:

⚠ Ranh giới trong đề:

NHÀ CUNG CẤP LO:
    ⚠ hạ tầng bên dưới
    ⚠ hệ điều hành
    ⚠ môi trường runtime
        ↓
BẠN LO:
    ⚠ CHỈ triển khai mã ứng dụng
        ↓
    → đúng định nghĩa PaaS

⚠ Bảng trách nhiệm — thứ phải thuộc:

                IaaS     PaaS     SaaS
Ứng dụng        BẠN      BẠN     n.c.cấp
Dữ liệu         BẠN      BẠN     n.c.cấp
⚠ Runtime       BẠN     n.c.cấp  n.c.cấp
Middleware      BẠN     n.c.cấp  n.c.cấp
⚠ Hệ điều hành  BẠN     n.c.cấp  n.c.cấp
Ảo hoá         n.c.cấp  n.c.cấp  n.c.cấp
Phần cứng      n.c.cấp  n.c.cấp  n.c.cấp
        ↓
    ⚠ Đề nói nhà cung cấp lo tới
      RUNTIME, bạn lo MÃ
        ↓
    → chính xác là PaaS

⚠ Vì sao ba phương án kia sai:

SaaS
    → ⚠ bạn KHÔNG triển khai mã nào
    → chỉ dùng phần mềm có sẵn

IaaS
    → ⚠ bạn PHẢI quản hệ điều hành
      và runtime

ON-PREMISES
    → ⚠ bạn lo mọi thứ, kể cả
      phần cứng

⚠ Gần trùng với #13272 (lô 139) và #13352 (lô 140) — cả ba đề đều mô tả nhu cầu "chỉ viết mã, không quản hạ tầng và OS", và cùng khoá PaaS. Hoàn toàn nhất quán.

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

C (IaaS) — phương án gần nhất về mặt "cũng là mô hình đám mây", nhưng với IaaS bạn nhận máy ảo trống và phải tự cài, tự vá hệ điều hành và runtime — đúng thứ đề nói nhà cung cấp lo.
A (SaaS) — bạn dùng phần mềm có sẵn, không triển khai mã của riêng mình.
D (on-premises) — tự lo mọi thứ, kể cả phần cứng.

Ghi nhớ

⚠ Ba mô hình dịch vụ — bảng phải thuộc: | Mô hình | Bạn quản | Ví dụ Google | |---|---|---| | IaaS | hệ điều hành trở lên | Compute Engine | | ⚠ PaaS | ⚠ CHỈ mã và dữ liệu | App Engine, Cloud Run | | SaaS | không gì cả | Google Workspace |

Từ khoá nhận diện:

"nhà cung cấp lo OS và runtime, tôi lo mã" → PaaS "tôi tự cài hệ điều hành" → IaaS "dùng phần mềm có sẵn" → SaaS "co về 0, trả theo request" → serverless (một dạng PaaS)

Các lựa chọn PaaS của Google Cloud	Lựa chọn
App Engine	⚠ PaaS cổ điển — đẩy mã nguồn lên
Cloud Run	⚠ container serverless — phổ biến nhất hiện nay
Cloud Run Functions	hàm theo sự kiện
Cloud SQL	⚠ PaaS cho cơ sở dữ liệu
BigQuery	serverless cho phân tích
Firebase	nền tảng cho app web và di động

⚠ Serverless khác PaaS thế nào	Điểm
PaaS truyền thống	thường có ít nhất một instance chạy
Serverless	⚠ CO VỀ 0 khi rảnh
Tính tiền	serverless trả theo request và thời gian chạy
Quan hệ	⚠ serverless là PaaS tiến hoá hơn

Đánh đổi của PaaS	Đánh đổi
✔ Nhanh, ít vận hành, tự mở rộng
⚠ Ít kiểm soát hạ tầng hơn
⚠ Ràng buộc runtime và thư viện
⚠ Khoá chân nhiều hơn IaaS	giảm bằng container
Với đội nhỏ	đánh đổi này gần như luôn xứng đáng

Khi nào vẫn phải chọn IaaS	Trường hợp
Cần module kernel hoặc driver riêng
Phần mềm cũ đòi OS cụ thể
Yêu cầu tuân thủ đòi kiểm soát tầng OS
Giấy phép ràng buộc phần cứng	sole-tenant node

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Tôi có phải vá hệ điều hành không | có → IaaS | | Tôi có viết mã ứng dụng không | không → SaaS | | Viết mã nhưng không quản máy chủ | → PaaS |

Và một cách trả lời nhanh mọi câu hỏi dạng này trong phòng thi: đếm xem đề nói bạn chịu trách nhiệm tới tầng nào. Câu chữ như "tự cài đặt", "chỉ triển khai mã", "dùng ngay" luôn chỉ thẳng vào một trong ba mô hình mà không cần suy luận thêm.

Câu 149 Exploring Data Transformation with Google Cloud

A retail company uses Cloud SQL to manage its online store's customer orders, inventory updates, and payment transactions. Each time a customer places an order, the system needs to immediately update inventory counts, record the transaction, and confirm the purchase—all within milliseconds. The company also uses BigQuery to analyze sales trends, identify best-selling products across regions, and forecast seasonal demand by running complex queries across years of historical data.

What is the key difference between these two services?

A Cloud SQL is for unstructured data, while BigQuery is for structured data.
B Cloud SQL is a data lake, while BigQuery is a database.
C Cloud SQL is optimized for frequent read/write operations (OLTP), while BigQuery is optimized for complex queries on large datasets (OLAP).
D Cloud SQL is a global service, while BigQuery is a regional service.

Xem giải thích

Đáp án

C — Cloud SQL tối ưu cho các thao tác đọc/ghi thường xuyên (OLTP), còn BigQuery tối ưu cho truy vấn phức tạp trên tập dữ liệu lớn (OLAP).

Vì sao đúng

Đề mô tả hai loại tải công việc hoàn toàn khác nhau, và đó chính là ranh giới OLTP – OLAP.

⚠ Hai tình huống trong đề:

CLOUD SQL
  "mỗi lần khách đặt hàng, hệ thống
   phải cập nhật tồn kho, ghi giao dịch,
   xác nhận đơn — ⚠ TẤT CẢ trong
   vài MILI-GIÂY"
        ↓
    ⚠ nhiều thao tác NHỎ, rất nhanh,
      cần GIAO DỊCH
        ↓
    → OLTP

BIGQUERY
  "phân tích xu hướng, tìm sản phẩm
   bán chạy theo vùng, dự báo mùa vụ
   trên ⚠ NHIỀU NĂM dữ liệu lịch sử"
        ↓
    ⚠ ÍT truy vấn nhưng mỗi cái
      quét RẤT NHIỀU
        ↓
    → OLAP

⚠ Vì sao không thể đổi vai cho nhau:

Dùng BigQuery cho đặt hàng
    → ⚠ độ trễ tính bằng GIÂY
    → ⚠ tính tiền theo BYTE QUÉT
    → ⚠ có hạn chế về UPDATE/DELETE
        ↓
    → khách chờ vài giây để
      xác nhận một đơn hàng

Dùng Cloud SQL cho phân tích
    → ⚠ truy vấn quét nhiều năm
      dữ liệu sẽ chạy hàng giờ
    → ⚠ và làm CHẬM luôn hệ
      đặt hàng đang chạy cùng máy

⚠ Vì sao ba phương án kia sai:

"Cloud SQL cho PHI CẤU TRÚC,
 BigQuery cho CÓ CẤU TRÚC"
    → ⚠ SAI: cả hai đều làm việc
      với dữ liệu CÓ CẤU TRÚC

"Cloud SQL là DATA LAKE,
 BigQuery là DATABASE"
    → ⚠ SAI hoàn toàn: Cloud SQL
      là CSDL, BigQuery là kho
      dữ liệu; hồ dữ liệu là
      Cloud Storage

"Cloud SQL TOÀN CẦU,
 BigQuery THEO VÙNG"
    → ⚠ NGƯỢC: Cloud SQL theo vùng,
      BigQuery có cả vị trí đa vùng

Nhất quán với #13296 (lô 139) — câu phủ định về việc BigQuery không phải cho OLTP — và #13332 (lô 140) về chọn CSDL theo loại tải. Cả ba cùng một ranh giới.

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

A (Cloud SQL cho phi cấu trúc, BigQuery cho có cấu trúc) — phương án gần nhất về mặt "nghe như một khác biệt kỹ thuật", nhưng cả hai đều xử lý dữ liệu có cấu trúc.
B (Cloud SQL là data lake, BigQuery là database) — sai cả hai vế; hồ dữ liệu trên Google Cloud là Cloud Storage.
D (Cloud SQL toàn cầu, BigQuery theo vùng) — đảo ngược: Cloud SQL gắn với một vùng, còn dataset BigQuery có cả tuỳ chọn đa vùng.

Ghi nhớ

⚠ OLTP và OLAP — bảng phải thuộc: | | OLTP | OLAP | |---|---|---| | Mục đích | giao dịch | phân tích | | Truy vấn | ⚠ nhiều, nhỏ | ⚠ ít, quét rất nhiều | | Độ trễ | mili-giây | giây | | Dữ liệu | hiện hành | lịch sử | | Sản phẩm | Cloud SQL, Spanner, Firestore, Bigtable | ⚠ BigQuery |

Từ khoá nhận diện:

"đặt hàng, thanh toán, cập nhật tồn kho" → OLTP → Cloud SQL / Spanner "xu hướng, dự báo, nhiều năm dữ liệu" → OLAP → BigQuery "phi cấu trúc, tệp video" → Cloud Storage "khoá–giá trị, mili-giây, thông lượng cực lớn" → Bigtable

⚠ Kiến trúc chuẩn — dùng CẢ HAI	Dòng chảy
Ứng dụng → Cloud SQL	giao dịch
Cloud SQL → Datastream (CDC) → BigQuery	⚠ đồng bộ sang kho phân tích
BigQuery → Looker	báo cáo
BigQuery ML	dự báo mùa vụ
⚠ Lợi ích	phân tích KHÔNG làm chậm hệ đặt hàng

Vì sao BigQuery nhanh với truy vấn lớn	Lý do
Lưu trữ theo CỘT	⚠ chỉ đọc cột cần
Xử lý song song quy mô lớn	hàng nghìn slot
Tách lưu trữ và tính toán	mở rộng độc lập
Serverless	không có cụm để quản

Cloud SQL — điều cần nhớ	Điểm
MySQL, PostgreSQL, SQL Server
Có quản lý	vá, sao lưu, HA
Mở rộng chủ yếu DỌC	⚠ có trần
Read replica	giảm tải đọc
HA hai zone	tự chuyển đổi ~60 giây

⚠ Đừng chạy báo cáo nặng trên CSDL sản xuất	Lý do
Truy vấn phân tích chiếm CPU và I/O
Hậu quả	⚠ làm chậm giao dịch của khách hàng
Cách chữa	read replica, hoặc ⚠ đồng bộ sang BigQuery
Thực hành	tách hoàn toàn hai loại tải

Ba câu hỏi kiểm chứng: | Câu hỏi | Dẫn tới | |---|---| | Cần trả lời trong mili-giây không | có → OLTP | | Truy vấn quét bao nhiêu dữ liệu | rất nhiều → OLAP | | Có cần giao dịch nhiều bảng không | có → CSDL quan hệ |

Và một dấu hiệu rất dễ nhận biết rằng ai đó đang dùng sai công cụ: báo cáo cuối tháng làm chậm trang thanh toán. Đó là lúc tải phân tích và tải giao dịch đang tranh nhau cùng một cơ sở dữ liệu — và cách chữa không phải là mua máy to hơn mà là tách chúng ra hai hệ thống khác nhau.

Câu 150 Modernize Infrastructure and Applications with Google Cloud

A development team is breaking down a large, monolithic application into a set of small, loosely coupled, independently deployable services. Each service is responsible for a specific business function. What is this architectural approach called?

A Virtual Machines
B Serverless
C Microservices
D Rehosting

Xem giải thích

Đáp án

C — Microservices (kiến trúc vi dịch vụ).

Vì sao đúng

Đề dùng đúng ba đặc trưng định nghĩa của microservices: nhỏ, ghép lỏng, triển khai độc lập, mỗi dịch vụ lo một chức năng nghiệp vụ.

⚠ Bốn đặc trưng trong đề:

"NHỎ (small)"
    → mỗi dịch vụ làm một việc

"⚠ GHÉP LỎNG (loosely coupled)"
    → ⚠ đổi một dịch vụ không
      buộc phải đổi dịch vụ khác

"⚠ TRIỂN KHAI ĐỘC LẬP"
    → ⚠ đây là đặc điểm quan
      trọng nhất

"mỗi dịch vụ lo MỘT CHỨC NĂNG
 NGHIỆP VỤ"
    → ⚠ chia theo NGHIỆP VỤ,
      không theo tầng kỹ thuật

⚠ Trước và sau khi tách:

KHỐI NGUYÊN (monolith)
    Mọi thứ trong một khối
        ↓
    ⚠ Sửa một dòng → kiểm thử
      và triển khai LẠI TOÀN BỘ
    ⚠ Một lỗi có thể sập tất cả
    ⚠ Mở rộng phải nhân cả khối

MICROSERVICES
   ┌────────┬────────┬────────┐
Thanh toán  Tìm kiếm  Hồ sơ
   │          │         │
  CSDL      CSDL      CSDL
  riêng     riêng     riêng
        ↓
    ⚠ Triển khai từng cái độc lập
    ⚠ Lỗi được cô lập
    ⚠ Mở rộng đúng phần cần

⚠ Vì sao ba phương án kia là khái niệm khác:

SERVERLESS
    → ⚠ mô hình VẬN HÀNH
      (không quản máy chủ)
    → không phải cách CHIA ứng dụng

VIRTUAL MACHINES
    → ⚠ công nghệ hạ tầng

REHOSTING
    → ⚠ chiến lược DI CƯ
      (bê nguyên lên đám mây)

⚠ Gần trùng với #13256 (lô 138) — đề đó cũng mô tả việc tách khối nguyên thành các thành phần triển khai độc lập, và cùng khoá Microservices. Hoàn toàn nhất quán.

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

B (Serverless) — phương án gần nhất về mặt "cũng là kiến trúc hiện đại", và microservices thường chạy trên nền serverless. Nhưng serverless nói về ai quản máy chủ, còn câu hỏi là về cách chia ứng dụng.
A (Virtual Machines) — công nghệ hạ tầng, không phải kiến trúc phần mềm.
D (Rehosting) — chiến lược di cư giữ nguyên kiến trúc, ngược hẳn.

Ghi nhớ

⚠ Monolith và microservices — bảng phải thuộc: | | Monolith | Microservices | |---|---|---| | Triển khai | cả khối một lần | ⚠ từng dịch vụ độc lập | | Mở rộng | nhân cả khối | ⚠ nhân đúng phần cần | | Lỗi | có thể sập tất cả | ⚠ cô lập | | Công nghệ | thống nhất | mỗi dịch vụ chọn riêng | | ⚠ Độ phức tạp | thấp | ⚠ CAO | | Hợp với | đội nhỏ, sản phẩm mới | đội lớn, hệ thống trưởng thành |

Từ khoá nhận diện:

"nhỏ, ghép lỏng, triển khai độc lập" → microservices "không quản máy chủ" → serverless "đóng gói cùng phụ thuộc" → container "bê nguyên lên đám mây" → rehost

⚠ Chia dịch vụ theo tiêu chí nào	Tiêu chí
⚠ Theo NĂNG LỰC NGHIỆP VỤ	thanh toán, tìm kiếm, hồ sơ
Mỗi dịch vụ sở hữu DỮ LIỆU của mình	⚠ không dùng chung CSDL
Một đội sở hữu một dịch vụ
⚠ Sai lầm	chia theo TẦNG KỸ THUẬT (UI / logic / CSDL)
Khái niệm liên quan	Domain-Driven Design, bounded context

⚠ Microservices KHÔNG miễn phí	Cái giá
Gọi qua mạng thay vì gọi hàm	⚠ chậm hơn, có thể lỗi
Giao dịch phân tán rất khó	⚠ không còn một CSDL duy nhất
Gỡ lỗi khó hơn nhiều	cần distributed tracing
Cần CI/CD trưởng thành
Lời khuyên phổ biến	⚠ bắt đầu bằng monolith, tách khi ĐÃ đau

Dịch vụ Google Cloud cho microservices	Dịch vụ
GKE	điều phối, kiểm soát đầy đủ
Cloud Run	⚠ container serverless, đơn giản hơn
Pub/Sub	⚠ giao tiếp bất đồng bộ, tách rời
API Gateway / Apigee	quản API ra ngoài
Cloud Service Mesh	định tuyến, bảo mật, quan sát
Cloud Trace	⚠ lần theo một request qua nhiều dịch vụ

Cách tách an toàn — Strangler Fig	Bước
Đặt lớp mặt tiền trước khối cũ
Tách từng tính năng một	⚠ không làm cả loạt
Chuyển dần lưu lượng
Khối cũ teo dần rồi bỏ
Lợi ích	⚠ không có "ngày X" đầy rủi ro

Ba câu hỏi kiểm chứng: | Câu hỏi | Nếu... | |---|---| | Triển khai một dịch vụ có phải đụng dịch vụ khác không | có → chưa thật sự độc lập | | Hai dịch vụ có dùng chung bảng CSDL không | có → ⚠ vẫn còn ghép chặt | | Có lần theo được một request xuyên dịch vụ không | không → thiếu quan sát |

Và một dấu hiệu cho biết việc tách microservices chưa thật sự thành công: hai dịch vụ vẫn đọc chung một bảng cơ sở dữ liệu. Khi đó chúng chỉ tách về mặt mã nguồn chứ vẫn ghép chặt qua schema — và một thay đổi cột sẽ làm gãy cả hai đúng như thời còn là khối nguyên.

Ngân hàng đề — Google Cloud Digital Leader

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ