Ngân hàng đề Google Cloud Professional Data Engineer

Câu 61 Machine learning

You are training a deep learning model with a relatively small set of features and a large number of instances. The model is not performing as well as you like. You believe the model is underfitting. What technique would you try to improve performance?

A AI
B Use feature crosses
C Use gradient descent
D Use backpropagation

Xem giải thích

Đáp án

B — Dùng feature cross (đặc trưng lai).

Vì sao đúng

⚠ Tình huống của đề: | Dữ kiện | Suy ra | |---|---| | ⚠ ÍT đặc trưng | ⚠ mô hình không có đủ thông tin | | ⚠ NHIỀU mẫu dữ liệu | ⚠ không phải thiếu dữ liệu | | ⚠ CHƯA KHỚP (underfitting) | ⚠ cần mô hình biểu diễn được quan hệ phức tạp hơn |

⚠ Feature cross = ⚠ nhân/ghép các
  đặc trưng có sẵn thành đặc trưng mới
        ↓
⚠ Ví dụ: kinh độ × vĩ độ
   → ⚠ nắm được "khu vực cụ thể"
⚠ Ví dụ: giờ trong ngày × ngày trong tuần
   → ⚠ nắm được "giờ cao điểm ngày thường"
        ↓
⚠ Mô hình học được quan hệ PHI TUYẾN
   mà từng đặc trưng riêng lẻ không diễn tả được

⚠ Thêm sức biểu diễn mà không cần thêm dữ liệu.

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

C (gradient descent) — ⚠ là THUẬT TOÁN TỐI ƯU, luôn được dùng sẵn: ⚠ không phải kỹ thuật để chữa chưa khớp.
D (backpropagation) — ⚠ cũng là cơ chế huấn luyện chuẩn: ⚠ mọi mạng nơ-ron đều dùng; ⚠ không phải lựa chọn để "thử thêm".
A ("AI") — ⚠ không phải kỹ thuật cụ thể nào: ⚠ phương án vô nghĩa.

Ghi nhớ

⚠ Chưa khớp và quá khớp — cách chữa phải thuộc: | Vấn đề | Dấu hiệu | Cách chữa | |---|---|---| | ⚠ Chưa khớp | ⚠ tệ trên CẢ train và test | ⚠ feature cross, thêm đặc trưng, mô hình lớn hơn, huấn luyện lâu hơn | | ⚠ Quá khớp | ⚠ tốt trên train, tệ trên test | ⚠ regularization, dropout, dừng sớm, thêm dữ liệu |

Từ khoá nhận diện:

"chưa khớp, ít đặc trưng" → ⚠ feature cross "quá khớp" → ⚠ L1/L2, dropout "chọn đặc trưng quan trọng" → ⚠ L1/Lasso "tệ trên cả hai tập" → ⚠ mô hình chưa đủ mạnh

⚠ Feature cross — ví dụ kinh điển	Ví dụ
⚠ Kinh độ × vĩ độ	⚠ nắm được vị trí cụ thể thay vì hai trục riêng
⚠ Loại phòng × khu vực	⚠ giá nhà
⚠ Giờ × ngày trong tuần	⚠ mẫu giao thông
⚠ Vì sao cần	⚠ mô hình tuyến tính chỉ cộng các đặc trưng — không nhân được
⚠ Lưu ý	⚠ cross quá nhiều gây bùng nổ chiều và QUÁ khớp

⚠ Kỹ thuật kỹ thuật đặc trưng (feature engineering)	Kỹ thuật
⚠ Feature cross	⚠ kết hợp đặc trưng
⚠ Bucketing / binning	⚠ chia giá trị liên tục thành khoảng
⚠ One-hot encoding	⚠ biến phân loại thành vector
⚠ Chuẩn hoá (normalization)	⚠ đưa về cùng thang
⚠ Embedding	⚠ biểu diễn dày cho dữ liệu phân loại nhiều giá trị

⚠ Chẩn đoán mô hình — quy trình	Bước
⚠ 1. So sánh lỗi trên train và test
⚠ 2. Lỗi train CAO → chưa khớp	⚠ mô hình yếu
⚠ 3. Lỗi train THẤP, test cao → quá khớp
⚠ 4. Cả hai thấp → tốt
⚠ Bước này quyết định	⚠ mọi hành động tiếp theo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi trên tập huấn luyện là bao nhiêu | ⚠ cao là chưa khớp | | Đã thử feature cross đơn giản chưa | | | Có đặc trưng nào bị bỏ sót không | ⚠ kiến thức nghiệp vụ thường chỉ ra |

Và nguồn cải thiện thường bị đánh giá thấp nhất trong học máy: hiểu biết nghiệp vụ về dữ liệu. Một đặc trưng lai do người hiểu bài toán nghĩ ra thường hơn hẳn việc tăng gấp đôi kích thước mô hình.

Câu 62 Machine Learning

A retailer is building machine learning models to help predict the number of products that will be sold and therefore should be available in inventory. What kind of model should they build?

A Regression
B Classification
C Feature
D Reinforcement

Xem giải thích

Đáp án

A — Hồi quy (regression).

Vì sao đúng

⚠ Câu hỏi quyết định luôn là: ĐẦU RA là gì? | Đầu ra | Loại mô hình | |---|---| | ⚠ Một CON SỐ liên tục | ⚠ HỒI QUY — đề này | | ⚠ Một NHÃN trong tập hữu hạn | ⚠ PHÂN LOẠI |

⚠ Đề: dự đoán SỐ LƯỢNG sản phẩm
   sẽ bán được
        ↓
⚠ Đầu ra là một con số
   (⚠ 120 cái, 3.500 cái…)
        ↓
⚠ HỒI QUY

⚠ Nếu đề hỏi "sản phẩm này có bán hết không" → ⚠ đó mới là phân loại.

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

B (phân loại) — ⚠ dự đoán NHÃN, không phải số: ⚠ ví dụ "còn hàng / hết hàng".
D (học tăng cường) — ⚠ học qua thử và phản hồi thưởng phạt: ⚠ dùng cho chuỗi quyết định (robot, trò chơi, tối ưu vận hành), ⚠ không phải dự đoán một giá trị từ dữ liệu lịch sử.
C ("feature") — ⚠ không phải loại mô hình: ⚠ đặc trưng là đầu vào của mô hình.

Ghi nhớ

⚠ Phân loại bài toán học máy — bảng phải thuộc: | Loại | Đầu ra | Ví dụ | |---|---|---| | ⚠ Hồi quy | ⚠ số liên tục | ⚠ doanh số, giá nhà, nhiệt độ | | ⚠ Phân loại nhị phân | ⚠ hai nhãn | ⚠ thư rác hay không | | ⚠ Phân loại nhiều lớp | ⚠ nhiều nhãn | ⚠ loại sản phẩm | | ⚠ Phân cụm | ⚠ nhóm, không có nhãn sẵn | ⚠ phân khúc khách hàng | | ⚠ Dự báo chuỗi thời gian | ⚠ số theo thời gian | ⚠ nhu cầu theo tuần | | ⚠ Gợi ý | ⚠ danh sách xếp hạng | ⚠ sản phẩm nên xem |

Từ khoá nhận diện:

"dự đoán SỐ LƯỢNG, doanh thu, giá" → ⚠ hồi quy "có hay không, thuộc loại nào" → ⚠ phân loại "nhu cầu theo thời gian, có mùa vụ" → ⚠ dự báo chuỗi thời gian "nhóm khách hàng giống nhau" → ⚠ phân cụm

⚠ Với bài toán tồn kho — chi tiết thêm	Chi tiết
⚠ Nếu có yếu tố MÙA VỤ và xu hướng	⚠ dự báo chuỗi thời gian (ARIMA, Prophet)
⚠ BigQuery ML có `arima_plus`	⚠ rất hợp cho dự báo nhu cầu
⚠ Vertex AI Forecasting	⚠ AutoML cho chuỗi thời gian
⚠ Đề này	⚠ hồi quy là câu trả lời ở mức khái niệm

⚠ Chỉ số đánh giá theo loại bài toán	Chỉ số
⚠ Hồi quy	⚠ MAE, RMSE, R²
⚠ Phân loại	⚠ precision, recall, F1, AUC
⚠ Chuỗi thời gian	⚠ MAPE, RMSE
⚠ Dùng nhầm chỉ số	⚠ là dấu hiệu chưa hiểu bài toán

⚠ Học có giám sát so với không giám sát	Phân biệt
⚠ Có giám sát	⚠ có NHÃN — hồi quy, phân loại
⚠ Không giám sát	⚠ không nhãn — phân cụm, giảm chiều
⚠ Tăng cường	⚠ học từ phần thưởng qua tương tác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đầu ra mong muốn là số hay nhãn | ⚠ quyết định loại mô hình | | Dữ liệu có yếu tố mùa vụ không | ⚠ thì nên dùng mô hình chuỗi thời gian | | Chỉ số đánh giá đã chọn đúng loại chưa | |

Và câu hỏi đầu tiên nên đặt cho mọi dự án học máy: quyết định gì sẽ được đưa ra dựa trên đầu ra này?. Câu trả lời quyết định cả loại mô hình lẫn chỉ số đánh giá — và đôi khi cho thấy không cần học máy chút nào.

Câu 63 Machine learning

What technique is used in backpropagation to update parameters of a model during training?`

A L1 or Lasso Regression
B L2 or Ridge Regression
C Feature crosses
D Gradient descent

Xem giải thích

Đáp án

D — Gradient descent (hạ gradient).

Vì sao đúng

⚠ Backpropagation và gradient descent làm hai việc khác nhau nhưng đi cùng nhau: | Thành phần | Việc | |---|---| | ⚠ Backpropagation | ⚠ TÍNH đạo hàm của hàm mất mát theo từng tham số | | ⚠ Gradient descent | ⚠ DÙNG đạo hàm đó để CẬP NHẬT tham số |

⚠ Tính đầu ra (forward pass)
        ↓
⚠ Tính hàm mất mát
        ↓ ⚠ Backpropagation
⚠ Lan ngược đạo hàm về từng trọng số
        ↓ ⚠ Gradient descent
⚠ w_mới = w_cũ − (tốc độ học × gradient)
        ↓
⚠ Lặp lại tới khi mất mát đủ nhỏ

⚠ Backprop TÍNH, gradient descent CẬP NHẬT.

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

A (L1 / Lasso) và B (L2 / Ridge) — ⚠ là REGULARIZATION: ⚠ chúng thêm hạng phạt vào hàm mất mát, ⚠ không phải cơ chế cập nhật tham số.
C (feature cross) — ⚠ là kỹ thuật KỸ THUẬT ĐẶC TRƯNG: ⚠ tạo đặc trưng mới trước khi huấn luyện.

Ghi nhớ

⚠ Vòng lặp huấn luyện — bảng phải thuộc: | Bước | Việc | |---|---| | ⚠ Forward pass | ⚠ tính dự đoán | | ⚠ Loss function | ⚠ đo sai lệch giữa dự đoán và thực tế | | ⚠ Backpropagation | ⚠ tính gradient bằng quy tắc chuỗi | | ⚠ Gradient descent | ⚠ cập nhật trọng số | | ⚠ Lặp lại | ⚠ qua nhiều epoch |

Từ khoá nhận diện:

"cập nhật tham số" → ⚠ gradient descent "tính đạo hàm lan ngược" → ⚠ backpropagation "chống quá khớp" → ⚠ L1, L2, dropout "tốc độ học" → ⚠ learning rate, siêu tham số của gradient descent

⚠ Các biến thể gradient descent	Biến thể
⚠ Batch GD	⚠ dùng TOÀN BỘ dữ liệu mỗi bước — chậm, ổn định
⚠ Stochastic GD (SGD)	⚠ một mẫu mỗi bước — nhanh, dao động
⚠ Mini-batch GD	⚠ một nhóm nhỏ — THỰC TẾ dùng nhất
⚠ Adam, RMSprop	⚠ tốc độ học thích ứng — mặc định phổ biến

⚠ Learning rate — siêu tham số quan trọng nhất	Ảnh hưởng
⚠ Quá LỚN	⚠ nhảy qua điểm tối ưu, mất mát dao động hoặc phân kỳ
⚠ Quá NHỎ	⚠ hội tụ rất chậm, có thể kẹt ở cực tiểu địa phương
⚠ Vừa phải	⚠ mất mát giảm đều
⚠ Kỹ thuật	⚠ learning rate schedule, warmup, giảm dần

⚠ Vấn đề gradient trong mạng sâu	Vấn đề
⚠ Vanishing gradient	⚠ gradient tiêu biến ở các lớp đầu — học rất chậm
⚠ Exploding gradient	⚠ gradient bùng nổ — mất mát thành NaN
⚠ Cách chữa	⚠ ReLU, batch normalization, kết nối tắt (residual), gradient clipping

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường cong mất mát có giảm đều không | ⚠ dao động mạnh là learning rate quá lớn | | Mất mát có thành NaN không | ⚠ exploding gradient | | Đã thử Adam trước khi chỉnh tay chưa | |

Và điều đáng nhớ khi đọc mọi tài liệu về huấn luyện mạng nơ-ron: backpropagation không phải thuật toán học, nó chỉ là cách tính đạo hàm hiệu quả. Việc học thật sự nằm ở bước cập nhật trọng số phía sau.

Câu 64 Data Pipelines

A group of analysts is migrating a Hadoop cluster from on premises to GCP. They want to follow Google Cloud recommended best practices. What should they do as part of the migration?

A Use ephemeral clusters and Cloud Storage instead of HDFS on local storage.
B Use ephemeral clusters and use HDFS on local storage.
C Continually run clusters and use Cloud Storage instead of HDFS on local storage.
D Continually run clusters and use HDFS on local storage.

Xem giải thích

Đáp án

A — Dùng cụm ngắn hạn (ephemeral cluster) và Cloud Storage thay cho HDFS trên đĩa cục bộ.

Vì sao đúng

⚠ Hai thực hành tốt của Google Cloud, gộp trong một phương án: | Thực hành | Lý do | |---|---| | ⚠ Cụm NGẮN HẠN | ⚠ tạo → chạy job → XOÁ; không trả tiền cho cụm rảnh | | ⚠ Cloud Storage thay HDFS | ⚠ TÁCH lưu trữ khỏi tính toán |

⚠ Mô hình CŨ (tại chỗ)
   ⚠ cụm chạy 24/7
   ⚠ dữ liệu nằm trên HDFS của cụm
        ↓ ⚠ xoá cụm = mất dữ liệu
   ⚠ nên không ai dám xoá

⚠ Mô hình ĐÁM MÂY
   ⚠ dữ liệu ở Cloud Storage
   ⚠ cụm tạo khi cần, xoá khi xong
        ↓
   ⚠ xoá cụm KHÔNG mất gì

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

C (cụm chạy liên tục + Cloud Storage) — ⚠ đúng một nửa: ⚠ tách lưu trữ rồi ⚠ nhưng ⚠ vẫn trả tiền cho cụm rảnh.
B (cụm ngắn hạn + HDFS cục bộ) — ⚠ MÂU THUẪN: ⚠ xoá cụm là ⚠ mất toàn bộ dữ liệu HDFS.
D (cụm chạy liên tục + HDFS cục bộ) — ⚠ bê nguyên mô hình cũ lên đám mây: ⚠ mất hết lợi thế.

Ghi nhớ

⚠ Thực hành tốt cho Dataproc — bảng phải thuộc: | Thực hành | Lý do | |---|---| | ⚠ Cụm ngắn hạn cho từng job | ⚠ chỉ trả tiền khi chạy | | ⚠ Dữ liệu ở Cloud Storage | ⚠ connector gs:// thay hdfs:// | | ⚠ Secondary worker preemptible | ⚠ giảm chi phí tới 80% | | ⚠ --max-idle tự xoá cụm rảnh | | | ⚠ Initialization action để cài phần mềm | | | ⚠ Cân nhắc Dataproc Serverless | ⚠ không quản cụm nào cả |

Từ khoá nhận diện:

"di trú Hadoop, thực hành tốt" → ⚠ cụm ngắn hạn + Cloud Storage "giữ nguyên mã Spark/Hive" → ⚠ Dataproc "hiện đại hoá hẳn" → ⚠ BigQuery + Dataflow "không muốn quản cụm" → ⚠ Dataproc Serverless

⚠ Vì sao tách lưu trữ khỏi tính toán	Lý do
⚠ Co giãn tính toán độc lập với dữ liệu
⚠ Nhiều cụm cùng đọc một tập dữ liệu
⚠ Dữ liệu sống lâu hơn cụm
⚠ Cloud Storage bền hơn HDFS	⚠ 11 số 9
⚠ Không phải cân bằng lại dữ liệu khi đổi số node
⚠ Đánh đổi	⚠ độ trễ cao hơn HDFS cục bộ một chút — thường không đáng kể

⚠ Cloud Storage connector	Đặc điểm
⚠ Cài sẵn trong Dataproc
⚠ Dùng đường dẫn `gs://bucket/path`	⚠ thay cho `hdfs://`
⚠ Tương thích với Spark, Hive, MapReduce
⚠ Sửa mã	⚠ thường chỉ đổi đường dẫn

⚠ Khi nào vẫn cần HDFS	Khi nào
⚠ Dữ liệu trung gian trong một job	⚠ shuffle, spill
⚠ Job đọc ghi rất nhiều lần cùng một tệp nhỏ
⚠ Nhưng	⚠ dữ liệu ĐẦU VÀO và ĐẦU RA nên ở Cloud Storage

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cụm có bị để chạy khi không có job không | ⚠ --max-idle | | Dữ liệu đầu vào có ở Cloud Storage không | | | Đã thử Dataproc Serverless chưa | ⚠ bỏ hẳn việc quản cụm |

Và thay đổi tư duy khó nhất khi chuyển Hadoop lên đám mây: cụm không còn là tài sản, nó là thứ dùng xong thì vứt. Chừng nào dữ liệu còn nằm trong cụm, chừng đó không ai dám xoá cụm — và mọi lợi ích của đám mây đều mất.

Câu 65 Data pipelines

A manufacturer of delivery drones is implementing a new data analysis pipeline to detect part failures before they occur. The drones have multiple sensors that send performance and environment data to an analytics pipeline. Currently, data is sent to a REST API endpoint. The REST API endpoint that receives data cannot always keep up with the pace data is arriving. When that happens, data is lost. Machine learning engineers have asked you to change the ingestion process to reduce this data loss. What would you do?

A Write data to a Cloud Pub/Sub topic instead of a REST API endpoint and have the ingestion application read from the topic.
B Write data to a Cloud Storage bucket instead of a REST API endpoint and have the ingestion application read from the bucket.
C Write data to a Cloud SQL Postgres database endpoint and have the ingestion application query the database.
D Create a Hadoop cluster in Compute Engine using managed instance groups and write data to an Hbase database and have the application query the database.

Xem giải thích

Đáp án

A — Ghi dữ liệu vào một topic Cloud Pub/Sub thay vì endpoint REST, và cho ứng dụng nạp dữ liệu đọc từ topic đó.

Vì sao đúng

⚠ Vấn đề của đề: endpoint REST ⚠ không theo kịp tốc độ dữ liệu tới, ⚠ và ⚠ dữ liệu bị MẤT.

⚠ Hiện tại
   ⚠ Cảm biến → ⚠ REST endpoint
        ↓ ⚠ endpoint quá tải
   ⚠ MẤT dữ liệu

⚠ Với Pub/Sub
   ⚠ Cảm biến → ⚠ Pub/Sub topic
        ↓ ⚠ ĐỆM tới 7 ngày
   ⚠ Ứng dụng đọc theo TỐC ĐỘ CỦA MÌNH
        ↓
   ⚠ KHÔNG mất dữ liệu

⚠ Pub/Sub tách rời tốc độ GỬI khỏi tốc độ XỬ LÝ — ⚠ đó chính xác là bài toán đề nêu.

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

B (ghi vào bucket Cloud Storage) — ⚠ hoạt động được nhưng kém hơn nhiều: ⚠ hàng loạt tệp nhỏ, ⚠ độ trễ cao, ⚠ khó xử lý theo luồng thời gian thực.
C (ghi vào Cloud SQL Postgres rồi truy vấn) — ⚠ CSDL quan hệ không chịu nổi ghi tốc độ cao từ IoT: ⚠ chính nó sẽ thành nút thắt tiếp theo.
D (dựng cụm Hadoop trên Compute Engine, ghi vào HBase) — ⚠ cực kỳ phức tạp: ⚠ tự quản hạ tầng khi đã có dịch vụ được quản; ⚠ và ⚠ vẫn không giải quyết chuyện đệm.

Ghi nhớ

⚠ Kiến trúc nạp dữ liệu IoT chuẩn — bảng phải thuộc: | Tầng | Dịch vụ | |---|---| | ⚠ Thu nhận và ĐỆM | ⚠ Pub/Sub | | ⚠ Xử lý luồng | ⚠ Dataflow | | ⚠ Phục vụ độ trễ thấp | ⚠ Bigtable | | ⚠ Phân tích lịch sử | ⚠ BigQuery | | ⚠ Lưu dữ liệu thô | ⚠ Cloud Storage |

Từ khoá nhận diện:

"mất dữ liệu vì hệ thống nhận không theo kịp" → ⚠ Pub/Sub làm lớp đệm "tốc độ gửi thay đổi thất thường" → ⚠ hàng đợi tin nhắn "cần xử lý thời gian thực" → ⚠ Pub/Sub + Dataflow

⚠ Vì sao hàng đợi giải quyết được vấn đề này	Lý do
⚠ Người gửi không phải chờ người xử lý
⚠ Đỉnh tải được san phẳng theo thời gian
⚠ Người xử lý chết thì dữ liệu vẫn còn
⚠ Thêm subscriber song song để xử lý nhanh hơn
⚠ Nguyên tắc kiến trúc	⚠ tách rời (decoupling) là công cụ chống mất dữ liệu mạnh nhất

⚠ Pub/Sub — con số phải nhớ	Con số
⚠ Giữ tin chưa ack	⚠ tới 7 ngày (cấu hình được)
⚠ Kích thước tin nhắn tối đa	⚠ 10 MB
⚠ Thông lượng	⚠ co giãn tự động, không phải cấp phát trước
⚠ Đảm bảo	⚠ giao ít nhất một lần

⚠ Nếu dữ liệu vẫn dồn lại	Cách xử lý
⚠ Theo dõi `num_undelivered_messages`
⚠ Theo dõi `oldest_unacked_message_age`
⚠ Tăng số subscriber song song
⚠ Kiểm tra ack deadline có đủ không
⚠ Với Dataflow	⚠ tự co giãn worker theo tồn đọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cảnh báo trên độ tuổi tin nhắn chưa xử lý không | | | Thiết bị xử lý thế nào khi không gửi được | ⚠ có đệm phía thiết bị không | | Xử lý có chịu được tin nhắn lặp không | |

Và nguyên tắc kiến trúc rút ra được từ câu này, áp dụng cho mọi hệ thống: giữa hai thành phần chạy ở tốc độ khác nhau, luôn cần một cái đệm. Không có nó thì bên chậm hơn quyết định lượng dữ liệu bị mất.

Câu 66 Data Pipelines

A machine learning model has been containerized and deployed on Kubernetes Engine. It is currently deployed with 2 replicas. You need to increase the number of replicas to 4. What command would you use?

A
kubectl scale deployment command with the --replicas 4 parameter.
B kubectl scale deployment command with the --replicas 2 parameter.
C kubectl scale deployment command with the --deploy 4 parameter.
D kubectl scale deployment command with the --deploy 2 parameter.

Xem giải thích

Đáp án

A — Lệnh kubectl scale deployment với tham số --replicas 4.

Vì sao đúng

⚠ --replicas khai số bản sao MONG MUỐN, không phải số bản sao thêm vào:

kubectl scale deployment ten-deployment --replicas=4
        ↓
⚠ Kubernetes so trạng thái mong muốn (4)
   với trạng thái hiện tại (2)
        ↓
⚠ Tạo thêm 2 pod
        ↓
⚠ Tổng cộng 4 replica

⚠ Đây là mô hình "trạng thái mong muốn" (declarative) — ⚠ nền tảng của Kubernetes: ⚠ bạn khai muốn có gì, ⚠ Kubernetes lo làm sao đạt được.

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

B (--replicas 2) — ⚠ hiểu nhầm cơ chế: ⚠ khai 2 nghĩa là muốn có 2 pod — ⚠ hệ thống sẽ giữ nguyên 2, không thành 4.
C (--deploy 4) và D (--deploy 2) — ⚠ tham số --deploy KHÔNG tồn tại.

Ghi nhớ

⚠ Lệnh kubectl hay dùng — bảng phải thuộc: | Lệnh | Việc | |---|---| | ⚠ kubectl scale deployment X --replicas=N | ⚠ đổi số bản sao | | ⚠ kubectl get pods | ⚠ xem pod đang chạy | | ⚠ kubectl describe pod X | ⚠ chi tiết và sự kiện — gỡ lỗi | | ⚠ kubectl logs X | ⚠ xem log container | | ⚠ kubectl apply -f file.yaml | ⚠ áp dụng cấu hình — cách khai báo | | ⚠ kubectl rollout status deployment X | ⚠ theo dõi triển khai | | ⚠ kubectl rollout undo deployment X | ⚠ quay lui phiên bản trước |

Từ khoá nhận diện:

"đổi số replica" → ⚠ kubectl scale --replicas=N "tự động co giãn theo tải" → ⚠ HPA (Horizontal Pod Autoscaler) "tự động thêm node" → ⚠ Cluster Autoscaler "tự chỉnh CPU/RAM cho pod" → ⚠ VPA (Vertical Pod Autoscaler)

⚠ Ba loại autoscaler trong GKE	Loại
⚠ HPA	⚠ thêm/bớt POD theo CPU, bộ nhớ, chỉ số tuỳ chỉnh
⚠ VPA	⚠ chỉnh yêu cầu tài nguyên CỦA pod
⚠ Cluster Autoscaler	⚠ thêm/bớt NODE khi pod không xếp được
⚠ Thứ tự hoạt động	⚠ HPA tạo pod → không đủ chỗ → Cluster Autoscaler thêm node
⚠ Cẩn thận	⚠ HPA và VPA cùng dựa trên CPU sẽ xung đột

⚠ Cách khai báo tốt hơn lệnh scale	Cách
⚠ Sửa `replicas` trong file YAML
⚠ `kubectl apply -f`
⚠ Lưu YAML trong Git	⚠ GitOps
⚠ Vì sao tốt hơn	⚠ `kubectl scale` là thay đổi thủ công sẽ bị ghi đè ở lần apply sau

⚠ Với mô hình học máy trên GKE	Lưu ý
⚠ Đặt resource request và limit rõ ràng	⚠ mô hình ML ngốn bộ nhớ
⚠ Node có GPU thì dùng node pool riêng + taint
⚠ Readiness probe quan trọng	⚠ mô hình cần thời gian nạp trước khi nhận request
⚠ HPA theo chỉ số tuỳ chỉnh	⚠ số request đang chờ thay vì CPU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thay đổi có được ghi vào YAML trong Git không | ⚠ nếu không sẽ bị mất | | Node có đủ tài nguyên cho 4 replica không | | | Readiness probe đã cấu hình chưa | |

Và điều làm Kubernetes khác các hệ thống trước nó: bạn không ra lệnh "thêm hai pod", bạn khai "tôi muốn có bốn". Sự khác biệt đó là lý do một cụm Kubernetes tự phục hồi được sau khi node chết.

Câu 67 Databases

A data pipeline uses Cloud Pub/Sub for ingesting data. The data is stored in topics and a Dataflow workflow reads from a subscription to that topic, processes the data, and writes output to BigQuery. What is the recommended way to authenticate when reading data from Cloud Pub/Sub?

A Custom role
B Google Workspace Identity
C Use service accounts
D Basic role

Xem giải thích

Đáp án

C — Dùng service account.

Vì sao đúng

⚠ Đây là workload TỰ ĐỘNG, không có con người ngồi đăng nhập: | Loại danh tính | Dành cho | |---|---| | ⚠ Service account | ⚠ ứng dụng, dịch vụ, job tự động — đề này | | ⚠ Tài khoản người dùng | ⚠ con người | | ⚠ Google Group | ⚠ gom nhiều người |

⚠ Job Dataflow chạy
        ↓
⚠ Dùng service account của worker
        ↓
⚠ Service account có vai trò
   pubsub.subscriber
        ↓
⚠ Đọc được từ subscription
   ⚠ không cần mật khẩu, không cần khoá

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

A (custom role) và D (basic role) — ⚠ VAI TRÒ không phải DANH TÍNH: ⚠ vai trò trả lời được làm gì, ⚠ câu hỏi ở đây là AI thực hiện; ⚠ vai trò vẫn phải gán cho một danh tính nào đó.
B (Google Workspace Identity) — ⚠ danh tính của CON NGƯỜI: ⚠ không dùng cho tiến trình tự động.

Ghi nhớ

⚠ Danh tính so với quyền — bảng phải thuộc: | Khái niệm | Trả lời | |---|---| | ⚠ Danh tính (principal) | ⚠ AI — người dùng, service account, group | | ⚠ Vai trò (role) | ⚠ ĐƯỢC LÀM GÌ — tập các quyền | | ⚠ Binding | ⚠ gán vai trò cho danh tính trên một tài nguyên | | ⚠ Đề hỏi "xác thực" | ⚠ là hỏi về DANH TÍNH |

Từ khoá nhận diện:

"ứng dụng/job xác thực thế nào" → ⚠ service account "cần quyền gì" → ⚠ vai trò IAM "chạy ngoài Google Cloud" → ⚠ Workload Identity Federation "trong GKE" → ⚠ Workload Identity, gắn KSA với GSA

⚠ Vai trò Pub/Sub hay dùng	Vai trò
⚠ `pubsub.publisher`	⚠ gửi tin nhắn vào topic
⚠ `pubsub.subscriber`	⚠ đọc tin từ subscription — đề này
⚠ `pubsub.viewer`	⚠ xem cấu hình
⚠ `pubsub.editor`	⚠ tạo/xoá topic và subscription
⚠ Quyền tối thiểu	⚠ job đọc thì chỉ cần subscriber

⚠ Service account cho Dataflow	Chi tiết
⚠ Có hai loại: controller và worker
⚠ Worker service account cần quyền đọc nguồn và ghi đích	⚠ Pub/Sub + BigQuery
⚠ Nên tạo service account RIÊNG cho pipeline	⚠ đừng dùng mặc định
⚠ Mặc định	⚠ service account Compute Engine — quyền Editor quá rộng

⚠ Thực hành tốt với service account	Thực hành
⚠ Mỗi workload MỘT service account
⚠ KHÔNG tạo file khoá nếu chạy trong Google Cloud
⚠ Gán vai trò predefined hẹp nhất
⚠ Đặt tên rõ mục đích	⚠ `dataflow-iot-pipeline@...`
⚠ Rà soát định kỳ bằng IAM Recommender

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline có dùng service account riêng không | | | Vai trò có hẹp nhất có thể không | ⚠ subscriber thay vì editor | | Có file khoá nào được tạo ra không | ⚠ không nên có |

Và cách phân biệt hai câu hỏi hay bị gộp làm một: xác thực là "bạn là ai", uỷ quyền là "bạn được làm gì". Service account trả lời câu đầu; vai trò IAM trả lời câu sau.

Câu 68 Data management

Data at rest in Google Cloud is encrypted at the hardware, infrastructure, and platform levels. What encryption algorithm is used for encryption at the infrastructure level?

A Blowfish
B AES256
C DES
D RSA

Xem giải thích

Đáp án

B — AES256.

Vì sao đúng

⚠ Google mã hoá dữ liệu khi lưu trữ ở nhiều tầng: | Tầng | Thuật toán | |---|---| | ⚠ Tầng hạ tầng (infrastructure) | ⚠ AES256 — đề này | | ⚠ Tầng phần cứng (ổ đĩa) | ⚠ AES256 hoặc AES128 tuỳ thiết bị | | ⚠ Tầng nền tảng | ⚠ AES256 cho từng khối dữ liệu |

⚠ Dữ liệu được chia thành CHUNK
        ↓
⚠ Mỗi chunk có KHOÁ RIÊNG (DEK)
   ⚠ mã hoá bằng AES256
        ↓
⚠ DEK được mã hoá bằng KEK
   (⚠ key encryption key)
        ↓
⚠ KEK giữ trong hệ thống quản khoá
   nội bộ của Google

⚠ Mã hoá khi lưu trữ là MẶC ĐỊNH, không tắt được, không tính phí thêm.

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

D (RSA) — ⚠ thuật toán BẤT ĐỐI XỨNG: ⚠ dùng cho trao đổi khoá và chữ ký số, ⚠ quá chậm để mã hoá khối lượng dữ liệu lớn.
C (DES) — ⚠ đã LỖI THỜI và không an toàn: ⚠ khoá 56 bit, ⚠ phá được từ lâu.
A (Blowfish) — ⚠ thuật toán cũ, khối 64 bit: ⚠ không được dùng trong hạ tầng Google Cloud.

Ghi nhớ

⚠ Mã hoá trên Google Cloud — bảng phải thuộc: | Trạng thái dữ liệu | Cách bảo vệ | |---|---| | ⚠ Khi LƯU TRỮ (at rest) | ⚠ AES256, mặc định, không tắt được | | ⚠ Khi TRUYỀN (in transit) | ⚠ TLS; giữa các trung tâm dữ liệu Google tự mã hoá | | ⚠ Khi ĐANG XỬ LÝ (in use) | ⚠ Confidential Computing — mã hoá cả RAM |

Từ khoá nhận diện:

"thuật toán mã hoá dữ liệu lưu trữ" → ⚠ AES256 "mã hoá bất đối xứng, chữ ký" → ⚠ RSA, ECDSA "mã hoá cả khi đang xử lý" → ⚠ Confidential Computing "khách tự quản khoá" → ⚠ CMEK trong Cloud KMS

⚠ Đối xứng so với bất đối xứng	So sánh
⚠ Đối xứng (AES)	⚠ một khoá cho cả mã và giải — NHANH
⚠ Bất đối xứng (RSA, ECC)	⚠ cặp khoá công khai/riêng tư — CHẬM hơn nhiều
⚠ Thực tế	⚠ dùng bất đối xứng để TRAO ĐỔI khoá đối xứng, rồi mã hoá dữ liệu bằng đối xứng
⚠ Đó là cách	⚠ TLS hoạt động

⚠ Phân cấp khoá của Google	Phân cấp
⚠ DEK (Data Encryption Key)	⚠ mã hoá từng chunk dữ liệu
⚠ KEK (Key Encryption Key)	⚠ mã hoá DEK — nằm trong Cloud KMS
⚠ Master key	⚠ bảo vệ KEK, trong hệ thống nội bộ của Google
⚠ Với CMEK	⚠ KEK do KHÁCH quản trong Cloud KMS
⚠ Ưu điểm phân cấp	⚠ xoay vòng KEK không phải mã hoá lại toàn bộ dữ liệu

⚠ Con số về AES cần nhớ	Con số
⚠ AES256	⚠ khoá 256 bit — tiêu chuẩn Google dùng
⚠ AES128	⚠ vẫn an toàn, nhanh hơn
⚠ Kích thước khối	⚠ 128 bit cho mọi biến thể AES
⚠ AES được chọn vì	⚠ an toàn, nhanh, có hỗ trợ phần cứng (AES-NI)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần kiểm soát khoá không | ⚠ mặc định đã mã hoá rồi | | Dữ liệu truyền có dùng TLS 1.2+ không | | | Có yêu cầu tuân thủ nào về thuật toán không | |

Và điều hay bị hiểu nhầm về mã hoá trên đám mây: dữ liệu của bạn đã được mã hoá rồi, mặc định. CMEK không thêm lớp mã hoá — nó chỉ chuyển quyền kiểm soát chiếc chìa khoá sang tay bạn.

Câu 69 Databases

A database administrator would like to migrate a PostgreSQL database to a managed service in Google Cloud with minimal changes. The database is used by a team of researchers all located in Spain and France. Which of the following services would you recommend?

A Cloud Spanner
B Cloud SQL
C Cloud Bigtable
D Cloud Firestore

Xem giải thích

Đáp án

B — Cloud SQL.

Vì sao đúng

⚠ Hai dữ kiện quyết định: | Dữ kiện | Suy ra | |---|---| | ⚠ Đang dùng PostgreSQL, muốn ÍT THAY ĐỔI nhất | ⚠ Cloud SQL chạy chính PostgreSQL | | ⚠ Người dùng đều ở Tây Ban Nha và Pháp | ⚠ cùng khu vực — MỘT vùng là đủ |

⚠ PostgreSQL tại chỗ
        ↓ ⚠ Cloud SQL for PostgreSQL
⚠ Cùng giao thức, cùng cú pháp SQL
⚠ Cùng công cụ (psql, pg_dump)
        ↓
⚠ Gần như chỉ đổi chuỗi kết nối

⚠ Không cần Spanner vì ⚠ người dùng không phân tán toàn cầu.

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

A (Cloud Spanner) — ⚠ bẫy "cứ toàn cầu là chọn Spanner": ⚠ đắt hơn nhiều, ⚠ cú pháp SQL khác, ⚠ phải thiết kế lại lược đồ; ⚠ và ⚠ người dùng chỉ ở hai nước cạnh nhau — không cần.
C (Cloud Bigtable) — ⚠ NoSQL, không có SQL, không có JOIN: ⚠ phải viết lại toàn bộ.
D (Cloud Firestore) — ⚠ CSDL tài liệu: ⚠ mô hình khác hẳn quan hệ.

Ghi nhớ

⚠ Di trú CSDL quan hệ — bảng phải thuộc: | Nguồn | Đích ít thay đổi nhất | |---|---| | ⚠ PostgreSQL | ⚠ Cloud SQL for PostgreSQL, hoặc AlloyDB | | ⚠ MySQL | ⚠ Cloud SQL for MySQL | | ⚠ SQL Server | ⚠ Cloud SQL for SQL Server | | ⚠ Oracle | ⚠ chạy trên Compute Engine, hoặc chuyển sang Postgres | | ⚠ Chỉ chọn Spanner khi | ⚠ thật sự cần quy mô/toàn cầu vượt Cloud SQL |

Từ khoá nhận diện:

"PostgreSQL, ít thay đổi nhất" → ⚠ Cloud SQL "cần hiệu năng Postgres cao hơn nhiều" → ⚠ AlloyDB "nhất quán mạnh xuyên châu lục" → ⚠ Spanner "người dùng ở một khu vực" → ⚠ một vùng là đủ

⚠ Giới hạn của Cloud SQL cần biết	Giới hạn
⚠ Co giãn theo CHIỀU DỌC	⚠ máy to hơn, không phải nhiều máy hơn
⚠ Chỉ MỘT primary nhận ghi
⚠ Read replica là nhất quán cuối cùng
⚠ Có giới hạn dung lượng tối đa mỗi instance
⚠ Vượt giới hạn	⚠ thì mới tính tới AlloyDB hoặc Spanner

⚠ AlloyDB — lựa chọn giữa Cloud SQL và Spanner	Đặc điểm
⚠ Tương thích PostgreSQL
⚠ Nhanh hơn Cloud SQL đáng kể cho tải giao dịch
⚠ Có công cụ phân tích cột tích hợp
⚠ Read pool co giãn
⚠ Khi nào	⚠ cần Postgres nhưng Cloud SQL không đủ mạnh

⚠ Công cụ di trú	Công cụ
⚠ Database Migration Service	⚠ di trú có/không downtime, được quản
⚠ `pg_dump` / `pg_restore`	⚠ cách thủ công, có downtime
⚠ Datastream	⚠ CDC, sao chép thay đổi liên tục
⚠ Chọn theo	⚠ chấp nhận downtime bao lâu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kích thước CSDL và tải hiện tại là bao nhiêu | ⚠ quyết định Cloud SQL có đủ không | | Có extension PostgreSQL nào Cloud SQL không hỗ trợ không | | | Chấp nhận downtime bao lâu khi chuyển | |

Và cái bẫy hay gặp khi ôn thi kiến trúc đám mây: thấy chữ "quốc tế" là phản xạ chọn dịch vụ toàn cầu. Tây Ban Nha và Pháp cách nhau vài trăm cây số — một vùng ở châu Âu phục vụ cả hai nước tốt hơn và rẻ hơn nhiều lần.

Câu 70 Data management

The CIO of a online gaming company is concerned with the increasing cost of maintaining a MongoDB database used to store player game data. What managed service in Google Cloud would you recommend as an alternative option to MongoDB?

A Cloud SQL
B Cloud Firestore
C Cloud Dataproc
D Bigtable

Xem giải thích

Đáp án

B — Cloud Firestore.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này GẦN TRÙNG với #16214 ở lô trước.

Câu	Bối cảnh
⚠ #16214 (lô 157)	⚠ công ty phần mềm phòng thí nghiệm, MongoDB → dịch vụ được quản
⚠ #16255 (câu này)	⚠ công ty game, lo chi phí bảo trì MongoDB
⚠ Cùng khoá	⚠ Firestore
⚠ Nhớ một điều	⚠ MongoDB ⇒ Firestore (cùng mô hình tài liệu)

Vì sao đúng

⚠ Ba lý do Firestore hợp với đề: | Lý do | Nội dung | |---|---| | ⚠ Cùng mô hình TÀI LIỆU | ⚠ collection/document — ít phải thiết kế lại | | ⚠ HOÀN TOÀN được quản | ⚠ hết chi phí bảo trì mà CIO lo lắng | | ⚠ Hợp với dữ liệu game | ⚠ hồ sơ người chơi, vật phẩm, tiến độ — cấu trúc linh hoạt |

⚠ Firestore còn có đồng bộ thời gian thực — ⚠ rất hợp cho game nhiều người chơi.

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

A (Cloud SQL) — ⚠ quan hệ, lược đồ cứng: ⚠ dữ liệu game thay đổi cấu trúc liên tục theo tính năng mới.
D (Bigtable) — ⚠ NoSQL cột rộng, chỉ truy vấn theo row key: ⚠ mô hình khác MongoDB nhiều.
C (Cloud Dataproc) — ⚠ dịch vụ Spark/Hadoop, không phải CSDL.

Ghi nhớ

⚠ Firestore cho dữ liệu game — bảng phải thuộc: | Nhu cầu game | Firestore | |---|---| | ⚠ Hồ sơ người chơi cấu trúc linh hoạt | ⚠ document | | ⚠ Cập nhật thời gian thực cho nhiều máy | ⚠ realtime listener | | ⚠ Hoạt động khi mất mạng | ⚠ offline persistence trong SDK di động | | ⚠ Giao dịch khi đổi vật phẩm | ⚠ giao dịch ACID | | ⚠ Co giãn tự động | ⚠ không phải cấp phát trước |

Từ khoá nhận diện:

"MongoDB được quản" → ⚠ Firestore "bảng xếp hạng khối lượng cực lớn" → ⚠ Bigtable hoặc Memorystore "phân tích hành vi người chơi" → ⚠ BigQuery "trạng thái phiên chơi tạm thời" → ⚠ Memorystore

⚠ Chi phí Firestore — mô hình khác CSDL truyền thống	Mô hình
⚠ Tính theo số THAO TÁC đọc, ghi, xoá	⚠ không theo giờ máy chạy
⚠ Cộng thêm dung lượng lưu và băng thông
⚠ Truy vấn trả về 1.000 tài liệu = 1.000 lượt đọc
⚠ Hệ quả thiết kế	⚠ tránh truy vấn trả về quá nhiều tài liệu
⚠ Mẹo	⚠ lưu sẵn giá trị tổng hợp thay vì đếm lại mỗi lần

⚠ Kiến trúc dữ liệu game điển hình	Kiến trúc
⚠ Firestore: trạng thái người chơi
⚠ Memorystore: phiên chơi, bảng xếp hạng nóng
⚠ Pub/Sub + Dataflow: sự kiện trong game
⚠ BigQuery: phân tích hành vi, giữ chân người chơi
⚠ Mỗi dịch vụ	⚠ giải một loại câu hỏi khác nhau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có truy vấn nào Firestore không làm được không | | | Ước tính số thao tác đọc/ghi mỗi ngày là bao nhiêu | ⚠ quyết định chi phí | | Có truy vấn nào trả về hàng nghìn tài liệu không | ⚠ rất tốn |

Và điểm khác biệt lớn nhất khi chuyển từ CSDL tự vận hành sang Firestore: chi phí không còn theo thời gian mà theo lượt truy cập. Một truy vấn viết cẩu thả không làm chậm hệ thống, nó chỉ lặng lẽ làm tăng hoá đơn.

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

Đá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

Ghi nhớ về chất lượng câu hỏi

Vì sao đúng

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

Ghi nhớ