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

Đáp án

A — gcloud projects describe [PROJECT_ID] hoặc gcloud projects describe [PROJECT_NAME].

Vì sao đúng

Lệnh gcloud tuân theo một cấu trúc rất đều đặn, và câu này kiểm tra đúng cấu trúc đó.

⚠ Điểm mấu chốt — thứ tự của lệnh gcloud:

gcloud  <NHÓM>  <ĐỘNG TỪ>  [THAM SỐ]
        ↓
    gcloud projects describe my-project
             ↑         ↑
          nhóm     động từ
        ↓
    → NHÓM đứng TRƯỚC, ĐỘNG TỪ đứng SAU
    → "gcloud describe project" là SAI thứ tự

⚠ Và nhận được cả PROJECT_ID lẫn PROJECT_NAME:

gcloud projects describe
        ↓
    Chấp nhận:
      - PROJECT_ID    (định danh duy nhất toàn cầu)
      - PROJECT_NAME  (tên hiển thị)
        ↓
    → nên phương án A đầy đủ hơn phương án B

⚠ Ba định danh của một project — đừng lẫn:

PROJECT_ID
        ↓
    Duy nhất TOÀN CẦU, KHÔNG đổi được sau khi tạo
    → dùng trong hầu hết lệnh và API

PROJECT_NAME
        ↓
    Tên hiển thị, ĐỔI ĐƯỢC, không cần duy nhất

PROJECT_NUMBER
        ↓
    Số do Google sinh, duy nhất, không đổi
    → xuất hiện trong một số service account

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

• B (gcloud projects describe [PROJECT_NAME] mà thôi) — đây là phương án gần nhất và cú pháp đúng, nhưng chữ "only" làm nó sai: lệnh này cũng nhận PROJECT_ID, và trong thực tế PROJECT_ID mới là thứ được dùng nhiều hơn.

• C và D (gcloud describe project ...) — sai thứ tự: gcloud luôn là nhóm trước, động từ sau. Không có nhóm nào tên là describe.

Ghi nhớ

⚠ Cấu trúc lệnh gcloud — bảng phải thuộc: | Thành phần | Ví dụ | |---|---| | Cấu trúc | gcloud <nhóm> <nhóm con> <động từ> [tham số] | | Ví dụ | gcloud compute instances list | | Ví dụ | gcloud projects describe my-proj | | Ví dụ | gcloud iam roles create ... | | Động từ thường gặp | list, describe, create, delete, update, add-iam-policy-binding | | Trợ giúp | gcloud <nhóm> --help |

Từ khoá nhận diện:

"xem thông tin một tài nguyên" → describe "liệt kê nhiều tài nguyên" → list "cấp quyền IAM" → add-iam-policy-binding "gcloud describe ..." → SAI thứ tự, luôn luôn "đổi tên project" → đổi PROJECT_NAME được, PROJECT_ID thì KHÔNG

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Project hiện tại là gì | gcloud config get-value project | | Có những project nào | gcloud projects list | | Cú pháp một lệnh | gcloud <nhóm> --help |

Và một tuỳ chọn rất đáng dùng khi làm việc với gcloud trong script: --format=json kết hợp với --filter. Nó cho phép lấy đúng trường cần mà không phải cắt chuỗi bằng awk hay sed — một thói quen giúp script bền hơn nhiều khi Google thay đổi định dạng hiển thị mặc định.

Đáp án

A — gcloud storage objects update gs://free-photos-gcp --storage-class=Nearline

Vì sao đúng

Đây là câu kiểm tra xem bạn có biết lệnh nào THẬT SỰ TỒN TẠI hay không — ba phương án còn lại đều là lệnh bịa.

⚠ Điểm mấu chốt — gcloud storage là công cụ hiện hành:

gsutil (công cụ CŨ)
        ↓
    Vẫn dùng được, nhưng Google đang chuyển
    sang gcloud storage
        ↓
gcloud storage (công cụ MỚI)
        ↓
    Nhanh hơn đáng kể với thao tác hàng loạt
    Cú pháp thống nhất với phần còn lại của gcloud
        ↓
    gcloud storage objects update gs://bucket/** \
      --storage-class=NEARLINE

⚠ Đổi storage class thực chất là GHI LẠI đối tượng:

Storage class là thuộc tính của TỪNG ĐỐI TƯỢNG
        ↓
    Đổi class = REWRITE đối tượng đó
        ↓
    → tính phí thao tác ghi
    → và với Nearline/Coldline/Archive
      còn có THỜI GIAN LƯU TỐI THIỂU
        ↓
    Xoá hoặc đổi class trước thời hạn tối thiểu
      → vẫn bị tính đủ tiền cho thời gian đó

⚠ Và có cách TỰ ĐỘNG tốt hơn — Object Lifecycle Management:

Đặt luật vòng đời trên bucket
        ↓
    "Đối tượng quá 30 ngày → Nearline"
    "Quá 90 ngày  → Coldline"
    "Quá 365 ngày → Archive"
    "Quá 7 năm    → xoá"
        ↓
    → Google tự chuyển, KHÔNG tốn phí thao tác
    → không phải chạy lệnh thủ công
        ↓
    Hoặc: Autoclass — Google tự chọn class
    theo mẫu truy cập thật

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

• C (gsutil rewrite -from multiregional --to nearline ...) — đây là phương án gần nhất vì gsutil rewrite là lệnh CÓ THẬT để đổi storage class, nhưng cú pháp sai: lệnh đúng là gsutil rewrite -s nearline gs://bucket/**, không có cờ -from và --to.

• B và D (gsutil migrate ...) — không có lệnh gsutil migrate. Đây là lệnh hoàn toàn bịa.

Ghi nhớ

⚠ Bốn storage class của Cloud Storage — bảng phải thuộc: | Class | Thời gian lưu tối thiểu | Dùng khi | |---|---|---| | Standard | không có | truy cập thường xuyên | | Nearline | 30 ngày | truy cập khoảng 1 lần/tháng | | Coldline | 90 ngày | khoảng 1 lần/quý | | Archive | 365 ngày | dưới 1 lần/năm — rẻ nhất | | Đánh đổi | class càng lạnh: lưu càng rẻ, ĐỌC càng đắt | |

Từ khoá nhận diện:

"đổi storage class" → gcloud storage objects update --storage-class, hoặc gsutil rewrite -s "tự động chuyển theo tuổi" → Object Lifecycle Management "không đoán được mẫu truy cập" → Autoclass "gsutil migrate" → KHÔNG TỒN TẠI "dữ liệu lưu trữ dài hạn" → Archive

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Class hiện tại của đối tượng | gcloud storage objects describe gs://bucket/tep | | Bucket có luật vòng đời không | gcloud storage buckets describe gs://bucket | | Chi phí thay đổi ra sao | Cloud Billing report, lọc theo SKU của Cloud Storage |

Và một lời khuyên nên áp dụng thay cho việc chạy lệnh đổi class bằng tay: đặt Object Lifecycle Management ngay từ khi tạo bucket. Nó không tốn phí thao tác chuyển class, chạy tự động mãi mãi, và tránh được tình huống rất hay gặp là ai đó đổi class hàng loạt cho hàng triệu đối tượng rồi nhận một hoá đơn thao tác ghi ngoài dự kiến.

Đáp án

A — URL MAPS.

Vì sao đúng

Với HTTP(S) Load Balancing của Google Cloud, URL map chính là thành phần quyết định request đi tới backend service nào.

⚠ Điểm mấu chốt — URL map là bộ định tuyến tầng 7:

URL map chứa các quy tắc:
        ↓
    Host rule    → theo TÊN MIỀN
      api.example.com  → path matcher A
      www.example.com  → path matcher B
        ↓
    Path matcher → theo ĐƯỜNG DẪN
      /api/users/*   → backend-service-users
      /api/orders/*  → backend-service-orders
      /*             → backend-service-default
        ↓
    → đúng thứ đề mô tả: "tuỳ URL người dùng
      gõ mà chuyển tới backend service khác nhau"

⚠ Các thành phần của HTTP(S) Load Balancer:

Forwarding rule
        ↓
    Địa chỉ IP + cổng
        ↓
Target HTTP(S) proxy
        ↓
    Kết thúc kết nối, gắn chứng chỉ SSL
        ↓
URL MAP                              ← đề này
        ↓
    Quyết định request đi tới backend nào
        ↓
Backend service
        ↓
    Nhóm máy (instance group / NEG),
    health check, thuật toán cân bằng
        ↓
Backend (instance group hoặc NEG)

⚠ URL map còn làm được nhiều hơn định tuyến:

Ngoài host và path, còn có:
        ↓
    - CHUYỂN HƯỚNG (redirect) HTTP → HTTPS
    - VIẾT LẠI (rewrite) đường dẫn
    - Chia lưu lượng theo TRỌNG SỐ
      → dùng cho canary và blue/green
    - Sửa header của request và response
    - Mirror lưu lượng sang backend thử nghiệm
        ↓
    → gọi là "advanced traffic management"

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

• B (Routes) — đây là phương án gần nhất về mặt tên gọi, nhưng route trong VPC là bảng định tuyến ở TẦNG 3: nó quyết định gói tin IP đi đâu (tới internet gateway, tới VPN, tới máy khác), không đọc được URL.

• C (Firewall rules) — cho phép hoặc chặn lưu lượng theo IP, cổng, giao thức và tag. Là kiểm soát truy cập, không phải định tuyến ứng dụng.

• D (Traces) — Cloud Trace là công cụ theo dõi độ trễ phân tán, dùng để chẩn đoán hiệu năng, hoàn toàn không định tuyến gì.

Ghi nhớ

⚠ Các loại load balancer của Google Cloud — bảng phải thuộc: | Loại | Tầng | Đặc điểm | |---|---|---| | Global external HTTP(S) | 7 | URL map, IP anycast toàn cầu, tích hợp Cloud CDN và Cloud Armor | | SSL Proxy | 4 | TLS không phải HTTP | | TCP Proxy | 4 | TCP toàn cầu | | External passthrough Network LB | 4 | giữ nguyên IP nguồn, theo Region | | Internal HTTP(S) | 7 | trong VPC, có URL map | | Internal passthrough Network LB | 4 | trong VPC |

Từ khoá nhận diện:

"định tuyến theo URL / theo đường dẫn" → URL map "cân bằng tải toàn cầu cho web" → Global external HTTP(S) LB "cần giữ IP nguồn của client" → passthrough Network LB "chặn theo IP, cổng" → firewall rule "gói tin đi đâu trong VPC" → route

Ba việc kiểm chứng: | Việc | Cách | |---|---| | URL map đang định tuyến ra sao | gcloud compute url-maps describe <ten> | | Backend có khoẻ không | gcloud compute backend-services get-health <ten> | | Request đi tới đâu | Cloud Logging với log của load balancer |

Và một công cụ rất hữu ích khi cấu hình URL map phức tạp: gcloud compute url-maps validate. Nó kiểm tra bộ quy tắc trước khi áp dụng và chỉ ra những quy tắc bị che khuất bởi quy tắc rộng hơn đứng trước — đúng loại lỗi khiến một đường dẫn cụ thể im lặng đi nhầm backend mà không có thông báo nào.

Đáp án

C — Cụm REGIONAL (theo Region).

Vì sao đúng

Yêu cầu là tính sẵn sàng cao, và chỉ cụm regional nhân bản CẢ control plane lẫn node ra nhiều zone.

⚠ Điểm mấu chốt — ba kiểu cụm GKE khác nhau ở chỗ nào:

SINGLE-ZONE (một zone)
        ↓
    Control plane: 1 bản, MỘT zone
    Node:          MỘT zone
        ↓
    → zone hỏng là MẤT TẤT CẢ

MULTI-ZONAL (nhiều zone)
        ↓
    Control plane: 1 bản, MỘT zone     ← điểm yếu
    Node:          NHIỀU zone
        ↓
    → zone của control plane hỏng
      → ứng dụng vẫn chạy nhưng
        KHÔNG QUẢN LÝ ĐƯỢC cụm
      → không co giãn, không triển khai được

REGIONAL (theo Region)                 ← đề này
        ↓
    Control plane: NHIỀU BẢN, nhiều zone
    Node:          NHIỀU zone
        ↓
    → mất một zone: control plane vẫn sống,
      node ở zone khác vẫn phục vụ
    → đây mới là sẵn sàng cao thật sự

⚠ Và có một chi tiết về số node cần nhớ:

Cụm regional
        ↓
    Số node bạn khai là SỐ NODE MỖI ZONE
        ↓
    Khai 3 node, cụm trải 3 zone
        ↓
    → THỰC TẾ có 9 node
    → và trả tiền cho 9 node
        ↓
    → tính chi phí phải nhân với số zone

⚠ Nâng cấp control plane cũng khác nhau:

Cụm zonal
        ↓
    Nâng cấp control plane → GIÁN ĐOẠN
      API server không dùng được vài phút

Cụm regional
        ↓
    Nâng cấp lần lượt từng bản
        ↓
    → API server LUÔN sẵn sàng
    → đây là lợi ích lớn cho môi trường production

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

• B (Multi-zonal) — đây là phương án gần nhất và node đúng là trải nhiều zone, nhưng control plane vẫn chỉ có MỘT bản ở MỘT zone. Mất zone đó thì ứng dụng còn chạy nhưng bạn không triển khai, không co giãn và không sửa được gì — không đạt chuẩn sẵn sàng cao.

• A (Single zone) — mọi thứ trong một zone, không có dự phòng nào.

• D ("Dedicated cluster") — không phải một kiểu cụm của GKE. GKE có zonal (single-zone, multi-zonal) và regional; ngoài ra còn phân biệt Standard ↔ Autopilot, và public ↔ private cluster.

Ghi nhớ

⚠ Ba kiểu cụm GKE — bảng phải thuộc: | Kiểu | Control plane | Node | |---|---|---| | Single-zone | 1 bản, 1 zone | 1 zone | | Multi-zonal | 1 bản, 1 zone | nhiều zone | | Regional | nhiều bản, nhiều zone | nhiều zone | | Sẵn sàng cao | chỉ Regional | | | Nâng cấp control plane | zonal có gián đoạn, regional không | |

Từ khoá nhận diện:

"tính sẵn sàng cao cho cụm Kubernetes" → regional cluster "không muốn quản node nào cả" → GKE Autopilot "node không có IP công cộng" → private cluster "cụm tự thêm node khi thiếu" → Cluster Autoscaler, hoặc node auto-provisioning "chi phí cụm regional cao bất ngờ" → số node được NHÂN với số zone

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm thuộc kiểu nào | gcloud container clusters describe <ten> → xem location | | Node trải mấy zone | kubectl get nodes -L topology.kubernetes.io/zone | | Pod có trải đều không | kubectl get pods -o wide |

Và một chi tiết về chi phí rất hay gây bất ngờ khi chuyển từ zonal sang regional: con số node bạn khai là số node MỖI ZONE. Một cụm regional trải ba zone với "3 node" thực chất chạy chín máy — nên khi lập dự toán, hãy luôn nhân với số zone trước khi so sánh với cụm zonal hiện tại.

Đáp án

A — Dùng tuỳ chọn --dry-run với lệnh bq query.

Vì sao đúng

BigQuery tính tiền theo lượng dữ liệu QUÉT, và --dry-run cho biết con số đó mà không chạy truy vấn.

⚠ Điểm mấu chốt — dry run trả về số byte sẽ được quét:

bq query --dry-run --use_legacy_sql=false \
  'SELECT ... FROM ...'
        ↓
    BigQuery PHÂN TÍCH truy vấn
        ↓
    Trả về: "Query successfully validated.
             Assuming the tables are not modified,
             running this query will process
             N bytes of data."
        ↓
    → KHÔNG chạy, KHÔNG tính tiền
    → biết trước chi phí để so sánh các cách viết

⚠ Từ số byte ra tiền:

Giá on-demand: tính theo TB dữ liệu quét
        ↓
    Chi phí = (số byte / 2^40) × đơn giá mỗi TB
        ↓
    → so sánh được hai cách viết truy vấn
      trước khi chạy cái nào
        ↓
    Console BigQuery cũng hiện ước tính này
    ở góc phải khi bạn gõ truy vấn

⚠ Và những cách giảm dữ liệu quét — quan trọng hơn cả:

1. ĐỪNG DÙNG SELECT *
        ↓
    BigQuery lưu theo CỘT
    → chỉ quét cột được nêu tên
    → SELECT * quét TOÀN BỘ bảng

2. PHÂN VÙNG (partition) theo ngày
        ↓
    WHERE ngay BETWEEN ... → chỉ quét phân vùng đó
    → giảm được hàng chục tới hàng trăm lần

3. PHÂN CỤM (cluster) theo cột hay lọc
        ↓
    → BigQuery bỏ qua khối dữ liệu không khớp

4. Materialized view / bảng tổng hợp
        ↓
    → tính sẵn kết quả cho truy vấn lặp lại

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

• C (--estimate-cost với lệnh bq) — đây là phương án gần nhất và nghe rất hợp lý, nhưng cờ này không tồn tại. Cờ đúng là --dry-run.

• D (--estimate-cost với lệnh gcloud) — sai cả cờ lẫn công cụ: BigQuery dùng bq, không phải gcloud.

• B (dùng Price Calculator) — Google Cloud Pricing Calculator ước tính chi phí hạ tầng ở mức tổng quát, dựa trên con số bạn tự nhập. Nó không phân tích một truy vấn cụ thể để biết truy vấn đó quét bao nhiêu dữ liệu.

Ghi nhớ

⚠ Hai mô hình tính giá của BigQuery — bảng phải thuộc: | Mô hình | Cách tính | |---|---| | On-demand | theo TB dữ liệu QUÉT — có mức miễn phí mỗi tháng | | Capacity (slot) | mua slot theo giờ hoặc cam kết — chi phí cố định, đoán được | | Lưu trữ | active và long-term (không sửa quá 90 ngày thì rẻ hơn) | | Streaming insert | tính riêng | | Chọn capacity khi | khối lượng truy vấn lớn và ổn định |

Từ khoá nhận diện:

"biết chi phí truy vấn trước khi chạy" → bq query --dry-run "giảm chi phí truy vấn" → partition, cluster, bỏ SELECT * "chi phí ổn định, đoán trước được" → capacity pricing (slot) "giới hạn chi tiêu" → custom quota theo project hoặc theo user "truy vấn lặp lại nhiều" → materialized view, hoặc kết quả được cache

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu | bq query --dry-run | | Bảng có partition không | bq show <dataset>.<bang> | | Ai đang tốn nhiều nhất | INFORMATION_SCHEMA.JOBS — truy vấn được lịch sử job |

Và một cờ rất đáng đưa vào mọi script chạy truy vấn tự động: --maximum_bytes_billed. Nó biến một truy vấn viết sai — chẳng hạn quên mệnh đề lọc theo phân vùng — thành một lỗi rõ ràng ngay lập tức, thay vì một hoá đơn quét vài trăm terabyte mà bạn chỉ phát hiện vào cuối tháng.

Đáp án

B — Tạo SHARED VPC.

Vì sao đúng

Đề mô tả đúng tình huống Shared VPC sinh ra để giải: nhiều project trong CÙNG một tổ chức, muốn dùng CHUNG một mạng VPC.

⚠ Điểm mấu chốt — Shared VPC tách quản trị mạng khỏi tải công việc:

HOST PROJECT
        ↓
    Chứa mạng VPC, subnet, firewall rule,
    Cloud Router, Cloud NAT
    → do đội hạ tầng quản lý
        ↓
SERVICE PROJECT (nhiều cái)
        ↓
    Chứa VM, GKE, Cloud SQL… của từng tầng
    → do từng đội phát triển quản lý
        ↓
    Tài nguyên trong service project
    DÙNG TRỰC TIẾP subnet của host project
        ↓
    → cùng một dải IP RIÊNG
    → giao tiếp nội bộ, KHÔNG cần peering
    → chi phí và quyền vẫn tách theo project

⚠ Vì sao hợp với kiến trúc nhiều tầng của đề:

Mỗi tầng một project riêng
        ↓
    → hạn ngạch, hoá đơn, quyền IAM tách bạch
        ↓
    Nhưng vẫn cùng một mạng
        ↓
    → tầng web gọi tầng ứng dụng bằng IP riêng
    → firewall rule quản tập trung ở host project
        ↓
    Đúng yêu cầu "làm việc với một VPC chung"

⚠ Vai trò IAM cần biết:

roles/compute.xpnAdmin
        ↓
    Gắn ở cấp TỔ CHỨC hoặc FOLDER
    → chỉ định host project, gắn service project

roles/compute.networkUser
        ↓
    Gắn cho người dùng của SERVICE PROJECT
    → cho phép họ TẠO tài nguyên trong subnet
      của host project
        ↓
    Cấp được ở mức TOÀN BỘ host project
    hoặc chỉ MỘT SUBNET cụ thể

Xem thêm câu #12470 (cùng lô): cũng về nối mạng giữa các đơn vị, nhưng ở đó là nhiều TỔ CHỨC khác nhau nên khoá là VPC Network Peering. Khoá khác nhau vì phạm vi khác nhau, không mâu thuẫn.

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

• C (tạo route giữa các subnet của từng project) — đây là phương án gần nhất về ý tưởng kết nối, nhưng mỗi project có VPC riêng biệt hoàn toàn; không có route nào nối thẳng hai VPC mà không qua peering hoặc VPN. Và như vậy vẫn không phải "một VPC chung" như đề yêu cầu.

• A (tạo VPN giữa các project) — chạy được nhưng rất thừa: thêm chi phí gateway, thêm độ trễ, thêm thứ phải vận hành — cho các project trong cùng một tổ chức.

• D (tạo firewall rule cho phép lưu lượng giữa subnet các project) — firewall rule chỉ cho phép hoặc chặn, không tạo ra đường đi. Không có kết nối thì mở firewall cũng vô nghĩa.

Ghi nhớ

⚠ Ba cách nối mạng trong Google Cloud — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Shared VPC | nhiều project CÙNG tổ chức dùng CHUNG một VPC | | VPC Network Peering | nối hai VPC riêng biệt — kể cả khác tổ chức | | Cloud VPN / Interconnect | nối GCP với mạng TẠI CHỖ hoặc với cloud khác | | Network Connectivity Center | trung tâm nối nhiều mạng |

Từ khoá nhận diện:

"nhiều project, một mạng chung, cùng tổ chức" → Shared VPC "nối hai VPC, khác tổ chức" → VPC Network Peering "nối với trung tâm dữ liệu" → Cloud VPN hoặc Interconnect "quản mạng tập trung, tải phân tán" → Shared VPC "gọi dịch vụ của bên khác qua IP riêng" → Private Service Connect

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Project có phải host không | gcloud compute shared-vpc get-host-project <project> | | Service project nào đang gắn | gcloud compute shared-vpc list-associated-resources <host> | | Ai được dùng subnet | gcloud compute networks subnets get-iam-policy <subnet> |

Và một cách phân quyền nên áp dụng ngay từ đầu với Shared VPC: cấp compute.networkUser ở mức TỪNG SUBNET, không phải cả host project. Khi đó mỗi đội chỉ dựng được máy trong đúng subnet của họ — và bạn giữ được ranh giới mạng rõ ràng mà không phải dựng nhiều VPC.

Đáp án

B — Cloud Data Fusion.

Vì sao đúng

Đề cần một đường ống ETL đọc từ nhiều nguồn, biến đổi, ghi vào BigQuery — và không muốn quản máy chủ.

⚠ Điểm mấu chốt — Data Fusion là ETL được quản lý, có giao diện kéo thả:

Cloud Data Fusion
        ↓
    Dịch vụ tích hợp dữ liệu ĐƯỢC QUẢN LÝ
    (dựa trên CDAP mã nguồn mở)
        ↓
    Giao diện KÉO THẢ để dựng pipeline
        ↓
    Hơn 150 CONNECTOR có sẵn:
      Cloud Storage, Cloud Spanner, BigQuery,
      Cloud SQL, Pub/Sub, JDBC, SaaS…
        ↓
    Bên dưới chạy trên DATAPROC do Google quản
        ↓
    → không phải dựng máy, không phải vá
    → đúng yêu cầu "không quản lý hạ tầng"

⚠ Đúng ba việc mà đề mô tả:

Đọc từ Cloud Storage và Cloud Spanner
        ↓
    → có connector sẵn cho cả hai
        ↓
Gộp dữ liệu hai nguồn
        ↓
    → có sẵn transform Joiner
        ↓
Ghi vào BigQuery
        ↓
    → có sink sẵn
        ↓
    → dựng được toàn bộ mà không viết mã

⚠ Nhưng nên biết lựa chọn thay thế:

Dataflow (Apache Beam)
        ↓
    Cũng serverless, mạnh hơn về xử lý luồng
    → nhưng phải VIẾT MÃ (Java/Python)
    → phù hợp khi cần logic phức tạp

Data Fusion
        ↓
    Kéo thả, ít mã
    → phù hợp khi cần dựng nhanh và
      cho người không chuyên lập trình
        ↓
    (Data Fusion có thể sinh ra job Dataflow
     hoặc Dataproc bên dưới)

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

• C (Cloud Dataprep) — đây là phương án gần nhất và cũng là công cụ dữ liệu không cần mã, nhưng Dataprep hướng tới KHÁM PHÁ VÀ LÀM SẠCH dữ liệu một cách trực quan cho nhà phân tích, không phải dựng đường ống sản xuất đọc từ nhiều nguồn hệ thống. (Và nó là sản phẩm của đối tác Trifacta, không phải dịch vụ Google thuần.)

• A (Compute Engine) — đòi tự quản máy chủ, trái thẳng yêu cầu của khách hàng.

• D (Cloud Build) — dịch vụ CI/CD để build và triển khai phần mềm, không phải công cụ xử lý dữ liệu.

Ghi nhớ

⚠ Các dịch vụ dữ liệu của Google Cloud — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Cloud Data Fusion | ETL KÉO THẢ, được quản lý, hơn 150 connector | | Dataflow | xử lý luồng và lô, Apache Beam — PHẢI VIẾT MÃ | | Dataproc | Hadoop và Spark được quản lý | | Dataprep | làm sạch và khám phá dữ liệu trực quan | | BigQuery | kho dữ liệu, serverless, SQL | | Pub/Sub | hàng đợi tin nhắn, nhận dữ liệu theo luồng | | Composer | điều phối luồng công việc (Apache Airflow) |

Từ khoá nhận diện:

"ETL không cần viết mã, không quản server" → Cloud Data Fusion "xử lý luồng, cần logic phức tạp" → Dataflow "đã có job Spark/Hadoop" → Dataproc "làm sạch dữ liệu bằng giao diện" → Dataprep "điều phối nhiều bước theo lịch" → Cloud Composer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline chạy thế nào | giao diện Data Fusion → tab Runs | | Có lỗi ở bước nào | log của pipeline, và Cloud Logging | | Chi phí bao nhiêu | Cloud Billing, lọc theo Data Fusion và Dataproc |

Và một điểm về chi phí rất đáng cân nhắc trước khi chọn Data Fusion: instance của nó tính tiền theo giờ kể cả khi không có pipeline nào chạy. Với một đội chỉ có vài đường ống chạy hằng đêm, Dataflow thường rẻ hơn nhiều vì chỉ tính tiền lúc job thực sự thực thi — nên hãy so sánh cả hai theo khối lượng công việc thật trước khi chốt.

Đáp án

B — roles/bigtable.reader

Vì sao đúng

Đề nói rõ hai điều: nhóm này chỉ cần ĐỌC dữ liệu, và phải theo thực hành tốt về bảo mật — tức là quyền tối thiểu.

⚠ Điểm mấu chốt — chọn vai trò hẹp nhất đủ dùng:

Nhu cầu: ĐỌC dữ liệu từ Bigtable
        ↓
    roles/bigtable.reader
        ↓
    → chỉ đọc dữ liệu trong bảng
    → KHÔNG ghi, KHÔNG sửa lược đồ,
      KHÔNG quản lý instance
        ↓
    → đúng nguyên tắc quyền tối thiểu

⚠ Bốn vai trò Bigtable — thang từ hẹp tới rộng:

roles/bigtable.reader
        ↓
    ĐỌC dữ liệu                      ← đề này

roles/bigtable.user
        ↓
    ĐỌC và GHI dữ liệu
    → nhưng không sửa lược đồ, không quản instance

roles/bigtable.admin
        ↓
    Quản lý instance, cluster, bảng, lược đồ
    → và đọc ghi dữ liệu

roles/bigtable.owner
        ↓
    Toàn quyền, kể cả xoá instance

⚠ Ba loại vai trò IAM của Google Cloud:

BASIC (cũ, rất rộng — TRÁNH DÙNG)
        ↓
    roles/viewer, roles/editor, roles/owner
    → áp cho MỌI dịch vụ trong project
    → quá rộng, không dùng cho production

PREDEFINED (nên dùng)
        ↓
    roles/bigtable.reader, roles/storage.objectViewer…
    → do Google định nghĩa và bảo trì cho từng dịch vụ

CUSTOM (khi predefined vẫn quá rộng)
        ↓
    Tự chọn từng permission
    → bạn phải tự bảo trì khi Google thêm quyền mới

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

• C (roles/bigtable.user) — đây là phương án gần nhất và cũng cho đọc được, nhưng nó cấp thêm quyền GHI — thừa so với nhu cầu, và vi phạm quyền tối thiểu.

• A (roles/bigtable.admin) — cho quản lý instance, cluster và lược đồ. Rộng hơn nhiều so với việc chỉ đọc dữ liệu.

• D (roles/bigtable.owner) — rộng nhất, kể cả xoá instance. Cấp cho nhà khoa học dữ liệu là rủi ro rất lớn.

Ghi nhớ

⚠ Ba loại vai trò IAM — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | Basic | viewer / editor / owner — quá rộng, tránh dùng | | Predefined | theo từng dịch vụ, Google bảo trì — NÊN DÙNG | | Custom | tự chọn permission — bạn phải tự bảo trì | | Nguyên tắc | luôn bắt đầu từ predefined hẹp nhất đủ dùng |

Từ khoá nhận diện:

"chỉ cần đọc" → vai trò có chữ reader hoặc viewer "đọc và ghi dữ liệu" → user (với Bigtable), editor cấp dịch vụ "quản lý tài nguyên" → admin "thực hành tốt về bảo mật" → quyền tối thiểu, predefined role "predefined vẫn quá rộng" → custom role

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền gì | gcloud projects get-iam-policy <project> | | Vai trò gồm những permission nào | gcloud iam roles describe roles/bigtable.reader | | Có quyền nào thừa không | IAM Recommender trong console |

Và một công cụ rất đáng dùng định kỳ: IAM Recommender. Nó phân tích 90 ngày sử dụng thật rồi gợi ý thay một vai trò rộng bằng vai trò hẹp hơn — cách nhanh nhất để siết quyền mà không phải đoán xem ai còn cần gì, và cũng là bằng chứng tốt khi cần giải trình với bộ phận kiểm toán.

Đáp án

B — Triển khai VPC NETWORK PEERING giữa các VPC.

Vì sao đúng

Chi tiết quyết định nằm ở một từ: NHIỀU TỔ CHỨC (multiple organizations). Shared VPC không vượt qua ranh giới tổ chức, còn peering thì có.

⚠ Điểm mấu chốt — peering nối được cả qua ranh giới tổ chức:

VPC Network Peering
        ↓
    Nối HAI mạng VPC riêng biệt
        ↓
    Hoạt động được khi hai VPC ở:
      - cùng project
      - khác project
      - KHÁC TỔ CHỨC          ← trường hợp của đề
        ↓
    Lưu lượng đi trên MẠNG NỘI BỘ của Google
    → không qua internet công cộng
    → độ trễ thấp, không tốn phí gateway

⚠ Vì sao Shared VPC không dùng được ở đây:

Shared VPC
        ↓
    Host project và service project
    PHẢI CÙNG MỘT TỔ CHỨC
        ↓
    Đề nói rõ: "multiple organizations"
        ↓
    → loại Shared VPC ngay

⚠ Ba ràng buộc của peering phải nhớ:

1. KHÔNG BẮC CẦU
        ↓
    A ↔ B và B ↔ C
    → KHÔNG cho A ↔ C
    → phải peer A ↔ C riêng
        ↓
    Nhiều VPC → dùng Network Connectivity Center

2. CIDR KHÔNG ĐƯỢC CHỒNG LẤN
        ↓
    Hai VPC trùng dải IP → không peer được
    → phải quy hoạch IP từ đầu

3. PHẢI TẠO Ở CẢ HAI PHÍA
        ↓
    Mỗi bên tạo một peering trỏ sang bên kia
    → chỉ một bên tạo thì trạng thái là INACTIVE

Xem thêm câu #12467 (cùng lô): cùng chủ đề nối mạng, nhưng ở đó là nhiều project CÙNG một tổ chức nên khoá là Shared VPC. Khoá khác nhau vì phạm vi khác nhau, không mâu thuẫn.

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

• C (triển khai Shared VPC) — đây là phương án gần nhất và là câu trả lời đúng cho một đề rất giống, nhưng Shared VPC chỉ hoạt động TRONG MỘT tổ chức. Đề nói rõ là nhiều tổ chức.

• D (triển khai VPN giữa các VPC) — chạy được, nhưng thua peering ở mọi mặt khi cả hai đầu đều nằm trong Google Cloud: VPN có phí gateway, giới hạn băng thông mỗi đường hầm, và thêm độ trễ mã hoá. Peering đi thẳng trên mạng nội bộ của Google.

• A (đặt firewall rule cho phép lưu lượng ra tới VPC khác) — firewall chỉ cho phép hoặc chặn, không tạo ra đường đi. Không có kết nối thì mở firewall vô nghĩa.

Ghi nhớ

⚠ Bốn cách nối mạng trong Google Cloud — bảng phải thuộc: | Cách | Phạm vi | Đặc điểm | |---|---|---| | Shared VPC | CHỈ trong một tổ chức | một VPC dùng chung, quản tập trung | | VPC Peering | cùng hoặc KHÁC tổ chức | hai VPC riêng, nối lại, không bắc cầu | | Cloud VPN | tới mạng ngoài | có mã hoá, có phí gateway | | Cloud Interconnect | tới trung tâm dữ liệu | băng thông lớn, độ trễ thấp | | Network Connectivity Center | nhiều mạng | trung tâm nối, giải bài toán không bắc cầu |

Từ khoá nhận diện:

"nhiều TỔ CHỨC" → VPC Peering "nhiều project CÙNG tổ chức, một mạng chung" → Shared VPC "nối với trung tâm dữ liệu" → Cloud VPN hoặc Interconnect "nhiều VPC nối chằng chịt" → Network Connectivity Center "gọi dịch vụ của bên khác qua IP riêng" → Private Service Connect

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Peering đã hoạt động chưa | gcloud compute networks peerings list → trạng thái phải là ACTIVE | | Route đã trao đổi chưa | gcloud compute routes list --filter="peering" | | Máy có gọi được nhau không | ping hoặc nc giữa hai VM bằng IP riêng |

Và một điều nên xác nhận sớm trước khi hứa hẹn tiến độ với các bên: hai VPC có dải IP chồng lấn hay không. Peering từ chối thẳng nếu CIDR trùng nhau, và cách sửa duy nhất là đánh số lại toàn bộ một bên — một công việc rất tốn kém mà lẽ ra chỉ cần vài phút quy hoạch ở giai đoạn thiết kế.

Đáp án

A — Địa chỉ NỘI BỘ theo REGION (regional internal address).

Vì sao đúng

Mỗi VM trong Compute Engine luôn được cấp một IP nội bộ thuộc dải của subnet, và subnet là tài nguyên theo Region.

⚠ Điểm mấu chốt — subnet của GCP có phạm vi REGION:

VPC của Google Cloud là TOÀN CẦU
        ↓
    Nhưng SUBNET thuộc về MỘT REGION
        ↓
    VM khởi chạy vào một subnet
        ↓
    → nhận IP nội bộ từ dải CIDR của subnet đó
    → nên IP nội bộ là REGIONAL
        ↓
    (Điểm khác biệt lớn với AWS:
     ở AWS subnet thuộc một AZ,
     ở GCP subnet trải cả Region)

⚠ IP nội bộ được cấp TỰ ĐỘNG, IP ngoài thì KHÔNG:

IP nội bộ (internal)
        ↓
    LUÔN được cấp tự động
    → VM nào cũng có
        ↓
IP ngoài (external)
        ↓
    CHỈ có nếu bạn yêu cầu
    → mặc định VM KHÔNG có IP công cộng
        ↓
    → đề nói "Google Cloud tự động gán"
      → đang nói tới IP NỘI BỘ

⚠ Bảng phân loại địa chỉ IP của GCP:

                REGIONAL          GLOBAL
INTERNAL    IP của VM          (dải cấp cho
            (từ subnet)         Private Service
                                Access)

EXTERNAL    IP của VM,         IP của Global
            Regional LB         HTTP(S) LB
                                (anycast)

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

• C (regional external address) — đây là phương án gần nhất vì đúng phạm vi Region, nhưng IP ngoài KHÔNG được cấp tự động: mặc định VM của Compute Engine không có địa chỉ công cộng trừ khi bạn yêu cầu.

• B (global internal address) — IP nội bộ của VM luôn là regional. Địa chỉ nội bộ toàn cầu tồn tại nhưng dùng cho mục đích khác (ví dụ dải cấp cho Private Service Access).

• D (global external address) — dành cho Global HTTP(S) Load Balancer với IP anycast, không phải cho VM.

Ghi nhớ

⚠ Bốn loại địa chỉ IP của GCP — bảng phải thuộc: | | Internal | External | |---|---|---| | Regional | IP của VM — cấp TỰ ĐỘNG từ subnet | IP công cộng của VM, Regional LB | | Global | dải cho Private Service Access | IP anycast của Global HTTP(S) LB | | Tĩnh hay tạm | cả hai đều có ephemeral và static | | | Chi phí | nội bộ miễn phí | IP tĩnh KHÔNG dùng thì BỊ TÍNH TIỀN |

Từ khoá nhận diện:

"IP tự động gán cho VM" → regional internal "IP cố định cho VM" → static external (hoặc static internal) "IP toàn cầu cho load balancer" → global external, anycast "VM không có IP công cộng mà cần ra internet" → Cloud NAT "VM ở subnet nào" → subnet là REGIONAL trong GCP

⚠ Khác biệt lớn giữa GCP và AWS về mạng: | | Google Cloud | AWS | |---|---|---| | VPC | TOÀN CẦU | theo Region | | Subnet | theo REGION | theo Availability Zone | | Firewall | áp cho cả VPC, nhắm bằng tag hoặc service account | security group gắn vào ENI | | Route | theo VPC, có ưu tiên | theo route table của từng subnet | | Mở rộng subnet | mở rộng được dải IP | không đổi CIDR được |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM có IP gì | gcloud compute instances describe <ten> — xem networkInterfaces | | Có IP tĩnh nào bỏ không | gcloud compute addresses list --filter="status=RESERVED" | | Subnet dải nào | gcloud compute networks subnets describe <subnet> --region=<region> |

Và một khác biệt rất đáng nhớ khi chuyển từ AWS sang GCP: subnet của Google Cloud trải cả một Region, không phải một zone. Nghĩa là một subnet duy nhất đã phục vụ được VM ở mọi zone trong Region đó — đơn giản hơn nhiều so với việc phải tạo một subnet cho mỗi AZ như bên AWS.