Ngân hàng đề — AWS Certified Machine Learning Specialty

Đáp án

A — Hai lớp C và D quá giống nhau

Vì sao đúng

Khi ma trận nhầm lẫn cho thấy mô hình liên tục đoán C thành D và ngược lại trong khi các lớp khác vẫn tốt, nguyên nhân gần như luôn là hai lớp đó không tách được bằng những đặc trưng đang có — nội dung văn bản của chúng chồng lấn nhau. Đây là vấn đề ranh giới giữa hai lớp, không phải vấn đề của toàn mô hình.

Hướng xử lý: xem lại định nghĩa nhãn (có nên gộp hai lớp không), bổ sung đặc trưng phân biệt được chúng, hoặc thêm dữ liệu cho đúng hai lớp đó.

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

• B. Tập dữ liệu quá nhỏ cho kiểm định — nếu vậy thì kết quả sẽ kém đều ở mọi lớp, không chỉ tập trung ở một cặp.
• C. Phân bố dữ liệu lệch — với 300 mẫu mỗi lớp trên 5 lớp thì dữ liệu cân bằng.
• D. Quá khớp ở lớp B và E — mâu thuẫn với dữ kiện: vấn đề nằm ở C và D.

Đáp án

B và E — mã hoá một-nóng, và thay tên màu bằng tần suất xuất hiện trong tập huấn luyện

Vì sao đúng

Màu tường là biến phân loại không có thứ tự — đỏ không "lớn hơn" trắng. Hai cách mã hoá đúng:

• B. Một-nóng — mỗi màu thành một cột 0/1, nên mô hình không suy ra thứ tự giả nào. Đây là cách mặc định khi số hạng mục ít.
• E. Mã hoá theo tần suất — thay tên màu bằng số lần xuất hiện. Cách này giữ được thông tin "màu này phổ biến hay hiếm" mà chỉ tốn một cột, rất hữu ích khi số hạng mục lớn.

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

• A. Gán số nguyên 1, 5, 10 — tạo ra thứ tự và khoảng cách giả: mô hình sẽ hiểu xanh gấp mười lần đỏ, điều hoàn toàn vô nghĩa.
• C. Thay bằng độ dài chuỗi tên màu — số ký tự của tên màu không mang thông tin gì về giá thuê.
• D. Mã hoá thành ba cột RGB — nghe hợp lý nhưng áp một trật tự theo phổ màu lên một biến mà quan hệ với giá thuê không hề theo phổ màu.

🧩 Giải thích nội dung câu hỏi một cách chi tiết

Câu hỏi thuộc chủ đề Machine Learning Model Evaluation trong chứng chỉ AWS Certified Machine Learning - Specialty, tập trung vào việc đánh giá mô hình dự đoán churn (khách hàng rời bỏ dịch vụ) cho một công ty mạng di động lớn. Công ty sử dụng mô hình để xác định khách hàng có nguy cơ cao rời bỏ, sau đó cung cấp incentive (ưu đãi) nhằm giữ chân họ, vì chi phí churn (mất khách) lớn hơn nhiều so với chi phí incentive.

• Confusion Matrix từ hình ảnh (dựa trên tập test 100 khách hàng): | | Predicted Churn Yes | Predicted Churn No | |------------------|-------------------------|------------------------| | Actual Churn Yes | 10 (TP - True Positive) | 4 (FN - False Negative) | | Actual Churn No | 10 (FP - False Positive)| 76 (TN - True Negative)|

  📊 Các chỉ số chính (tính từ matrix):

  • Accuracy = (TP + TN) / Tổng = (10 + 76) / 100 = 86%.
  • Precision (cho lớp positive - predicted churn) = TP / (TP + FP) = 10 / (10 + 10) = 50%.
  • Recall = TP / (TP + FN) = 10 / (10 + 4) ≈ 71.43%.
  • Ý nghĩa kinh doanh:
    • FP (10 trường hợp): Dự đoán churn nhưng thực tế không → Cung cấp incentive thừa → Chi phí = giá incentive (thấp).
    • FN (4 trường hợp): Dự đoán không churn nhưng thực tế có → Mất khách → Chi phí = giá churn (cao hơn incentive nhiều).
  • Câu hỏi cốt lõi: Tại sao mô hình này viable cho production (phù hợp triển khai thực tế)? Dựa trên accuracy cao và cost analysis phù hợp với business (cost FP < cost FN).

Mô hình viable vì accuracy cao (86%) và phù hợp với business cost: ưu tiên tránh FN hơn FP, dù precision thấp.

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

Đáp án đúng: The model is 86% accurate and the cost incurred by the company as a result of false positives is less than the false negatives.

🛠️ Lý do chi tiết:

• Accuracy đúng là 86% (tính chính xác từ matrix).
• Trong ngữ cảnh churn prediction, cost của FP (incentive thừa cho 10 khách không churn) thấp hơn cost của FN (mất 4 khách thực sự churn, chi phí cao gấp nhiều lần incentive).
• Mô hình viable vì accuracy tốt và align với business metric: cost FP (10 cases) < cost FN (4 cases nhưng giá trị cao hơn), giúp công ty tiết kiệm tổng chi phí dài hạn. Đây là nguyên tắc cost-sensitive evaluation trong AWS SageMaker (Model Monitor, Clarify) – cập nhật đến 2026, nhấn mạnh custom metrics cho imbalanced classes như churn.

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

• ❌ SAI: The model is 86% accurate and the cost incurred by the company as a result of false negatives is less than the false positives.
  🧩 Phân tích: Accuracy đúng 86%, nhưng cost FN > cost FP (mất khách đắt hơn incentive thừa). Đảo ngược logic kinh doanh, làm mô hình không viable vì bỏ lỡ khách hàng thực sự churn.

• ❌ SAI: The precision of the model is 86%, which is less than the accuracy of the model.
  🧩 Phân tích: Precision chỉ 50% (10/(10+10)), không phải 86%. Accuracy 86% > precision 50%, nhưng câu sai vì nhầm lẫn con số và không giải thích viability (precision thấp nhưng chấp nhận được vì cost FP thấp).

• ✅ ĐÚNG: The model is 86% accurate and the cost incurred by the company as a result of false positives is less than the false negatives.
  🧩 Phân tích: Hoàn toàn chính xác như phần trên. Accuracy 86%, và cost FP < cost FN khớp business case, làm mô hình phù hợp production.

• ❌ SAI: The precision of the model is 86%, which is greater than the accuracy of the model.
  🧩 Phân tích: Precision 50% < accuracy 86%, không phải 86% và không greater. Sai cả số liệu lẫn so sánh, bỏ qua cost analysis quan trọng cho churn.

📘 Tài liệu tham khảo

• AWS Certified Machine Learning - Specialty Exam Guide (2024-2026): Domain 3 - Modeling (Evaluation Metrics, Confusion Matrix). Link AWS.
• Amazon SageMaker Documentation: Confusion Matrix & Custom Metrics (e.g., Cost-Sensitive Learning in Built-in Algorithms). SageMaker Model Evaluation.
• AWS ML Best Practices: Churn prediction case studies (e.g., XGBoost on SageMaker với imbalance handling). AWS ML Examples.

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀

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

Câu hỏi mô tả một Machine Learning Specialist đang thiết kế hệ thống để cải thiện doanh số bán hàng cho công ty. Mục tiêu chính là sử dụng lượng dữ liệu lớn về hành vi người dùng (user behavior) và sở thích sản phẩm (product preferences) để dự đoán sản phẩm mà người dùng sẽ thích, dựa trên sự tương đồng giữa các người dùng với nhau (users' similarity to other users).

📘 Đây là mô tả điển hình của thuật ngữ "collaborative filtering" trong hệ thống khuyến nghị (recommendation systems):

• Không dựa vào đặc trưng sản phẩm (content-based), mà dựa vào ma trận tương tác người dùng-sản phẩm (user-item interactions), tìm người dùng tương tự và khuyến nghị sản phẩm họ đã thích.
• Phù hợp với AWS nhờ Amazon EMR (Elastic MapReduce) tích hợp Apache Spark MLlib, hỗ trợ thuật toán ALS (Alternating Least Squares) cho collaborative filtering quy mô lớn (cập nhật đến 2026, EMR phiên bản 7.x+ hỗ trợ Spark 3.5+ với MLlib tối ưu hóa).

Tài liệu tham khảo:

• AWS Documentation: Amazon EMR với Spark MLlib (ALS cho collaborative filtering).
• Spark MLlib Guide: Collaborative Filtering via ALS.

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

Đáp án đúng: Build a collaborative filtering recommendation engine with Apache Spark ML on Amazon EMR.

🛠️ Lý do:

• Câu hỏi nhấn mạnh "users' similarity to other users" → Chính xác khớp với collaborative filtering (lọc cộng tác), sử dụng dữ liệu hành vi người dùng để tìm tương đồng (user-user hoặc item-item similarity).
• Apache Spark ML trên Amazon EMR là lựa chọn tối ưu cho dữ liệu lớn: Spark MLlib có sẵn ALS algorithm xử lý ma trận thưa (sparse matrices) hiệu quả, scale-out trên EMR clusters.
• Cập nhật 2026: EMR hỗ trợ Spark ML với GPU acceleration (nếu dùng EC2 P4/P5 instances) và tích hợp SageMaker cho deployment.

❌ Phân tích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh dấu đúng/sai với lý do cụ thể:

• [SAI] Build a content-based filtering recommendation engine with Apache Spark ML on Amazon EMR
  ❌ Sai vì: Content-based filtering dựa vào đặc trưng sản phẩm (product features) và lịch sử cá nhân người dùng, không sử dụng sự tương đồng giữa người dùng. Câu hỏi tập trung vào "users' similarity", không phải nội dung sản phẩm. Spark ML hỗ trợ nhưng không phù hợp mục tiêu.

• [ĐÚNG] Build a collaborative filtering recommendation engine with Apache Spark ML on Amazon EMR
  ✅ Đúng vì: Như phân tích trên, khớp hoàn hảo với yêu cầu dự đoán dựa trên tương đồng người dùng. Spark MLlib/ALS trên EMR xử lý hàng tỷ interactions hiệu quả, chi phí thấp với spot instances.

• [SAI] Build a model-based filtering recommendation engine with Apache Spark ML on Amazon EMR
  ❌ Sai vì: "Model-based filtering" không phải thuật ngữ chuẩn trong recommendation systems. Nó có thể ám chỉ các mô hình ML như matrix factorization (phần của collaborative), nhưng câu hỏi cần collaborative cụ thể. Spark ML hỗ trợ models nhưng không khớp trực tiếp.

• [SAI] Build a combinative filtering recommendation engine with Apache Spark ML on Amazon EMR
  ❌ Sai vì: "Combinative filtering" không tồn tại trong tài liệu AWS/Spark (có lẽ lỗi chính tả của "combinative" thay vì "hybrid" hoặc "combinative"). Hybrid filtering kết hợp content + collaborative mới đúng, nhưng câu hỏi chỉ rõ collaborative thuần túy dựa trên user similarity.

Tóm tắt nhanh 📊: Chỉ collaborative filtering mới trực tiếp giải quyết "users' similarity", tận dụng EMR + Spark ML cho big data ML workflows! 🚀

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

Câu hỏi tập trung vào việc xây dựng một nền tảng phân tích dữ liệu cho Mobile Network Operator sử dụng Amazon Athena và Amazon S3. Dữ liệu nguồn được gửi dưới dạng .CSV theo thời gian thực (real-time) từ các hệ thống nguồn. Nhóm Data Engineering muốn chuyển đổi (transform) dữ liệu từ CSV sang định dạng Apache Parquet trước khi lưu trữ vào S3, nhằm tối ưu hóa hiệu suất truy vấn với Athena (Parquet hỗ trợ columnar storage, compression tốt hơn).

Mục tiêu chính: Tìm giải pháp ít nỗ lực triển khai nhất (LEAST effort) để ingest dữ liệu real-time, transform sang Parquet và lưu vào S3. Các yếu tố cần cân nhắc bao gồm: serverless (không quản lý infra), tích hợp native AWS, thời gian setup nhanh, chi phí thấp và scalability tự động. 📈

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

Đáp án đúng: Ingest .CSV data from Amazon Kinesis Data Streams and use Amazon Kinesis Data Firehose to convert data into Parquet.

Lý do chi tiết 🛠️:

• Amazon Kinesis Data Firehose là dịch vụ serverless hoàn toàn, hỗ trợ ingest real-time từ Kinesis Data Streams (hoặc trực tiếp từ sources khác), tự động transform CSV sang Parquet mà không cần code custom.
• Firehose có built-in converter cho Parquet (sử dụng AWS Glue Data Catalog schema nếu cần), batching, compression, encryption và direct delivery vào S3 với partitioning tùy chọn.
• Ít effort nhất: Setup chỉ vài cú click trên console, không cần quản lý cluster, code ETL phức tạp hay EC2. Thời gian triển khai < 10 phút, scale tự động theo throughput.
• Phù hợp real-time analytics với Athena (query trực tiếp Parquet trên S3).
• Cập nhật 2026: Firehose vẫn hỗ trợ Parquet conversion native (ra mắt từ 2018, cải tiến schema inference 2023+).

Nguồn tham khảo 📘:

• AWS Docs: Amazon Kinesis Data Firehose Data Transformation
• AWS Well-Architected Data Analytics Lens (2024 update).

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên effort triển khai (setup, quản lý, code, scaling).

• Ingest .CSV data using Apache Kafka Streams on Amazon EC2 instances and use Kafka Connect S3 to serialize data as Parquet
  ❌ Sai: Yêu cầu triển khai Kafka trên EC2 (self-managed cluster), config Kafka Streams + Kafka Connect Sink Connector cho S3 (cần custom SerDe cho Parquet). Effort cao: quản lý EC2, scaling thủ công, monitoring, high availability. Không serverless, dễ lỗi config. Phù hợp on-prem nhưng không optimal cho AWS native.

• Ingest .CSV data from Amazon Kinesis Data Streams and use Amazon Glue to convert data into Parquet
  ❌ Sai: Kinesis Data Streams tốt cho ingest, nhưng Glue là ETL batch/serverless job (Glue Jobs/Streaming), cần viết Spark/Scala/Python script để crawl Kinesis, transform Parquet và lưu S3. Effort trung bình-cao: phát triển code, schedule job, debug schema, Glue Crawler cho Athena. Không real-time seamless như Firehose; Glue Streaming mới (2022+) vẫn phức tạp hơn.

• Ingest .CSV data using Apache Spark Structured Streaming in an Amazon EMR cluster and use Apache Spark to convert data into Parquet
  ❌ Sai: EMR cluster (managed Hadoop/Spark) cần provision instance, config Spark Structured Streaming đọc nguồn (Kinesis/Kafka), viết job transform Parquet. Effort cao nhất: quản lý cluster (auto-terminate giúp nhưng vẫn bootstrap script, tuning), cost cao cho real-time, scaling thủ công. Không serverless thuần.

• Ingest .CSV data from Amazon Kinesis Data Streams and use Amazon Kinesis Data Firehose to convert data into Parquet
  ✅ Đúng: Như giải thích trên, serverless end-to-end, transform native (no-code), LEAST effort. Ideal cho real-time CSV → Parquet → S3 + Athena. 🚀

Kết luận nổi bật 🌟: Firehose thắng vì zero-management transformation, phù hợp DevOps best practices (IaC với CDK/CloudFormation). Nếu throughput cao, kết hợp Data Streams làm buffer. Test thực tế: Setup Firehose → S3 trong 5 phút! 💡

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

Câu hỏi tập trung vào việc dự báo chất lượng không khí (đo lường bằng ppm - parts per million của các chất ô nhiễm) cho 2 ngày tới tại một thành phố. Đây là prototype (mẫu thử nghiệm), chỉ có dữ liệu hàng ngày từ 1 năm qua (khoảng 365 điểm dữ liệu), hình thành một chuỗi thời gian đơn (single time series).
Nhiệm vụ là chọn mô hình trong Amazon SageMaker có khả năng mang lại kết quả tốt nhất (MOST likely) cho bài toán dự báo (forecasting) - một nhiệm vụ hồi quy (regression) vì output là giá trị liên tục (ppm).
🛠️ Đặc điểm quan trọng: Dữ liệu ít, không phức tạp, cần mô hình đơn giản, có sẵn (built-in algorithms) trong SageMaker, hỗ trợ xử lý time series đơn lẻ cho regression. Không cần mô hình chuyên sâu như DeepAR hay Prophet vì dữ liệu hạn chế và prototype.

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

Đáp án đúng: Use the Amazon SageMaker Linear Learner algorithm on the single time series consisting of the full year of data with a predictor_type of regressor.

Lý do:

• Linear Learner là thuật toán supervised learning built-in của SageMaker, hỗ trợ hoàn hảo cho regression (predictor_type=regressor) để dự báo giá trị liên tục như ppm.
• Với dữ liệu ít (1 năm), mô hình tuyến tính đơn giản như Linear Learner hiệu quả cao, tránh overfitting, dễ train nhanh cho prototype.
• Nó xử lý tốt single time series bằng cách sử dụng features từ dữ liệu lịch sử (ví dụ: lag features hoặc windowing).
• Theo tài liệu SageMaker mới nhất (2024-2026), Linear Learner vẫn là lựa chọn tối ưu cho regression cơ bản với data nhỏ. ✅

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên tính phù hợp với bài toán regression trên single time series:

• ❌ [SAI] Use the Amazon SageMaker k-Nearest-Neighbors (kNN) algorithm on the single time series consisting of the full year of data with a predictor_type of regressor.
  Lý do sai: kNN là thuật toán instance-based (dựa trên khoảng cách), hỗ trợ regressor nhưng không hiệu quả cho forecasting time series vì không học pattern thời gian (temporal dependencies). Với data ít, kNN dễ bị ảnh hưởng bởi noise và không dự báo tốt ahead-of-time (2 ngày tới). Phù hợp hơn cho classification hoặc recommendation, không phải prototype forecasting.

• ❌ [SAI] Use Amazon SageMaker Random Cut Forest (RCF) on the single time series consisting of the full year of data.
  Lý do sai: RCF là thuật toán unsupervised anomaly detection, dùng để phát hiện bất thường (outliers) trong dữ liệu, không hỗ trợ forecasting hay regression. Nó chỉ phân tích pattern hiện tại, không dự báo tương lai. Hoàn toàn không phù hợp cho nhiệm vụ dự báo ppm.

• ✅ [ĐÚNG] Use the Amazon SageMaker Linear Learner algorithm on the single time series consisting of the full year of data with a predictor_type of regressor.
  Lý do đúng: Như đã giải thích ở trên, đây là lựa chọn tối ưu cho regression đơn giản trên time series nhỏ. Linear Learner train nhanh, scalable trên SageMaker, và predictor_type=regressor khớp chính xác với output liên tục.

• ❌ [SAI] Use the Amazon SageMaker Linear Learner algorithm on the single time series consisting of the full year of data with a predictor_type of classifier.
  Lý do sai: Linear Learner với predictor_type=classifier chỉ dùng cho phân loại (classification), output là class labels (ví dụ: tốt/xấu), không phải giá trị số liên tục như ppm. Sử dụng classifier sẽ lỗi output và không giải quyết được forecasting regression.

📘 Tài liệu tham khảo (cập nhật đến 2026)

• AWS SageMaker Algorithms Documentation: Linear Learner - Xác nhận hỗ trợ regressor/classifier cho supervised tasks.
• kNN Algorithm: docs.aws.amazon.com/sagemaker/latest/dg/k-nearest-neighbors.html - Không ưu tiên cho time series forecasting.
• RCF Algorithm: docs.aws.amazon.com/sagemaker/latest/dg/randomcutforest.html - Chỉ anomaly detection.
• SageMaker Time Series Forecasting Best Practices (2024+): Khuyến nghị Linear Learner cho prototype đơn giản trước khi dùng BlazingText hoặc JumpStart models.
  🛠️ Lưu ý thực hành: Trong SageMaker Studio/Notebook, dùng sagemaker.LinearLearner với predictor_type='regressor', prepare data với Pandas cho lag features để tối ưu time series.

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

Câu hỏi tập trung vào một Data Engineer cần xây dựng mô hình học máy sử dụng bộ dữ liệu chứa thông tin thẻ tín dụng khách hàng (customer credit card information). Mục tiêu chính là đảm bảo dữ liệu luôn được mã hóa (encrypted) và thông tin thẻ tín dụng được bảo mật an toàn.

🛡️ Yêu cầu bảo mật kép:

• Mã hóa dữ liệu: Tại chỗ lưu trữ (at-rest) và trong quá trình truyền tải (in-transit), sử dụng các dịch vụ AWS như S3 và SageMaker.
• Bảo vệ thông tin nhạy cảm: Không chỉ mã hóa mà còn loại bỏ hoặc che giấu (redact/mask) số thẻ tín dụng để tránh rủi ro lộ thông tin PCI DSS compliant.

Câu hỏi kiểm tra kiến thức về bảo mật dữ liệu nhạy cảm trong pipeline ML trên AWS, đặc biệt với SageMaker (xây dựng model), S3 (lưu trữ dữ liệu), và các công cụ ETL như Glue. Theo tài liệu AWS mới nhất (2024-2026), AWS nhấn mạnh sử dụng KMS cho mã hóa và Glue cho data anonymization để tuân thủ GDPR/PCI.

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

• AWS SageMaker Security: https://docs.aws.amazon.com/sagemaker/latest/dg/security-permissions.html
• AWS KMS Encryption: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
• AWS Glue Data Redaction: https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html (hỗ trợ PII masking qua transformations).

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

Đáp án đúng: Use AWS KMS to encrypt the data on Amazon S3 and Amazon SageMaker, and redact the credit card numbers from the customer data with AWS Glue.

Lý do chọn 🏆:

• AWS KMS là dịch vụ mã hóa chuẩn của AWS (FIPS 140-2 validated), hỗ trợ mã hóa dữ liệu tại S3 (SSE-KMS) và SageMaker (tự động mã hóa EBS volumes, S3 inputs/outputs). Đảm bảo dữ liệu encrypted end-to-end.
• AWS Glue là ETL service hỗ trợ redact/mask PII như credit card numbers qua custom transformations hoặc FindMatches (de-duplication với masking). Điều này loại bỏ dữ liệu nhạy cảm trước khi đưa vào model training, tuân thủ best practices PCI DSS.
• Giải pháp toàn diện, native AWS, không cần custom code rủi ro, cập nhật đến 2026 với KMS multi-region keys và Glue 4.0 crawling.

📋 Phân tích tất cả các phương án (đúng/sai)

Dưới đây là phân tích chi tiết từng lựa chọn. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với emoji nổi bật:

• ❌ SAI: Use a custom encryption algorithm to encrypt the data and store the data on an Amazon SageMaker instance in a VPC. Use the SageMaker DeepAR algorithm to randomize the credit card numbers.
  Giải thích sai: Custom encryption algorithm không được AWS khuyến nghị vì thiếu tương thích với services (khó key management, không FIPS compliant). DeepAR là algorithm time-series forecasting (dự báo chuỗi thời gian), không dùng để randomize data. VPC chỉ isolate network, không giải quyết encryption/redaction. Rủi ro cao lộ dữ liệu.

• ❌ SAI: Use an IAM policy to encrypt the data on the Amazon S3 bucket and Amazon Kinesis to automatically discard credit card numbers and insert fake credit card numbers.
  Giải thích sai: IAM policy chỉ kiểm soát access (permissions), không encrypt data (encryption dùng S3 SSE/SSE-KMS). Kinesis là streaming service, không tự động discard/insert fake data (cần Lambda/Glue custom logic). Không phù hợp cho SageMaker model building, thiếu mã hóa toàn diện.

• ❌ SAI: Use an Amazon SageMaker launch configuration to encrypt the data once it is copied to the SageMaker instance in a VPC. Use the SageMaker principal component analysis (PCA) algorithm to reduce the length of the credit card numbers.
  Giải thích sai: SageMaker launch configuration (nay là Instance Metadata) không encrypt data khi copy (dùng S3/SageMaker encryption settings). PCA là dimensionality reduction cho features ML, không dùng để shorten/mask credit card (vẫn giữ thông tin gốc, rủi ro lộ). VPC chỉ network security, không đủ.

• ✅ ĐÚNG: Use AWS KMS to encrypt the data on Amazon S3 and Amazon SageMaker, and redact the credit card numbers from the customer data with AWS Glue.
  Giải thích đúng: Như phần trên, KMS mã hóa S3/SageMaker (at-rest/in-transit), Glue redact PII qua ETL jobs (regex masking cho CC patterns như 16-digit). Best practice AWS 2026, scalable và compliant.

🛠️ Lời khuyên DevOps: Trong thực tế DOP-C02, implement qua CloudFormation với KMS keys customer-managed, Glue crawlers cho schema detection, và SageMaker Pipelines cho automated secure ML workflow!

🧩 Phân tích chi tiết câu hỏi trắc nghiệm AWS SageMaker

📖 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi xoay quanh một Machine Learning Specialist đang sử dụng Amazon SageMaker notebook instance được triển khai trong private subnet của VPC công ty (corporate VPC). Chuyên gia này có dữ liệu quan trọng lưu trữ trên Amazon EBS volume gắn với notebook instance và muốn tạo snapshot của volume đó. Tuy nhiên, họ không tìm thấy EBS volume hoặc Amazon EC2 instance tương ứng của notebook instance trong VPC.
🛠️ Vấn đề cốt lõi: Tại sao SageMaker notebook instance (và tài nguyên liên quan như EC2/EBS) không hiển thị trong VPC của khách hàng? Điều này liên quan đến kiến trúc backend của SageMaker, nơi AWS quản lý các tài nguyên một cách ẩn để đảm bảo bảo mật và cô lập. Kiến thức cập nhật đến 2026: SageMaker notebook instances vẫn giữ nguyên mô hình này theo tài liệu AWS mới nhất (không thay đổi lớn từ phiên bản 2023-2026).

✅ Đáp án đúng:
Amazon SageMaker notebook instances are based on EC2 instances running within AWS service accounts.
Lý do lựa chọn: SageMaker notebook instances được xây dựng trên nền tảng EC2 instances, nhưng chúng chạy trong các AWS service accounts (tài khoản dịch vụ do AWS quản lý), không nằm trong customer account hoặc VPC của khách hàng. Do đó, bạn không thể thấy chúng trong EC2 console, VPC dashboard, hoặc các công cụ quản lý VPC/EC2 của tài khoản cá nhân. Việc chỉ định VPC cho notebook chỉ ảnh hưởng đến network traffic routing (qua endpoints hoặc NAT), không phải vị trí vật lý của instance. Điều này giúp AWS đảm bảo bảo mật cao, tránh khách hàng truy cập trực tiếp vào backend.

🧐 Giải thích tất cả các phương án (đúng/sai):
Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá với lý do chi tiết dựa trên kiến thức AWS SageMaker mới nhất:

• ❌ [SAI] Amazon SageMaker notebook instances are based on the EC2 instances within the customer account, but they run outside of VPCs.
  Phương án này sai hoàn toàn vì SageMaker notebook không dựa trên EC2 instances trong customer account. Chúng chạy trong AWS service accounts, không phải tài khoản khách hàng. Phần "run outside of VPCs" có phần đúng (không trong VPC khách hàng), nhưng mâu thuẫn với thực tế backend AWS-managed.

• ❌ [SAI] Amazon SageMaker notebook instances are based on the Amazon ECS service within customer accounts.
  Phương án này sai vì SageMaker notebook không dựa trên Amazon ECS (Elastic Container Service). Chúng sử dụng EC2 instances thuần túy, không phải container orchestration như ECS. Hơn nữa, không nằm trong customer accounts.

• ✅ [ĐÚNG] Amazon SageMaker notebook instances are based on EC2 instances running within AWS service accounts.
  Phương án này chính xác 100%. Như đã giải thích, notebook instances là EC2-based, chạy trong AWS service accounts để AWS kiểm soát toàn bộ lifecycle, bảo mật và scaling. Bạn chỉ truy cập qua SageMaker console/API, không trực tiếp quản lý EC2/EBS.

• ❌ [SAI] Amazon SageMaker notebook instances are based on AWS ECS instances running within AWS service accounts.
  Phương án này sai vì lại nhầm lẫn với ECS (không có "AWS ECS instances" – ECS dùng tasks trên EC2/Fargate). SageMaker dùng EC2 thuần, dù trong AWS service accounts phần sau đúng nhưng tổng thể sai kiến trúc.

📘 Tài liệu tham khảo (cập nhật đến 2026):

• AWS SageMaker Documentation: Notebook instances in a VPC – Xác nhận "Notebook instances run in subnets in AWS-managed VPCs".
• AWS re:Post & Best Practices: SageMaker Notebook Instances Backend Architecture – Nhấn mạnh không visible trong EC2 console.
• AWS Well-Architected Framework (ML Lens, 2025 update): Khuyến nghị sử dụng SageMaker endpoints cho VPC integration thay vì truy cập trực tiếp backend.
  🔍 Mẹo thực hành: Để snapshot EBS của notebook, dùng SageMaker API (CreateNotebookInstanceLifecycleConfig hoặc export data qua S3), không cần truy cập EC2 trực tiếp!

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

Câu hỏi xoay quanh một Machine Learning Specialist đang xây dựng mô hình dự báo chuỗi thời gian (time series forecasting) bằng Amazon SageMaker. Sau khi hoàn tất việc huấn luyện mô hình, chuyên gia cần thực hiện load testing trên SageMaker endpoint để đánh giá hiệu suất trước khi cấu hình Auto Scaling cho biến thể mô hình (model variant).

Mục tiêu chính là tìm cách xem xét (review) các chỉ số hiệu suất quan trọng trong quá trình load test, bao gồm:

• Latency (độ trễ phản hồi).
• Memory utilization (sử dụng bộ nhớ).
• CPU utilization (sử dụng CPU).

🛠️ SageMaker endpoint tự động xuất các metrics này trực tiếp đến Amazon CloudWatch, giúp theo dõi thời gian thực mà không cần cấu hình phức tạp. Điều này đặc biệt quan trọng cho Auto Scaling, vì SageMaker hỗ trợ scaling dựa trên các metrics CloudWatch (cập nhật mới nhất đến 2026: SageMaker Inference Recommender và Serverless Inference vẫn tích hợp chặt chẽ với CloudWatch metrics).

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

• AWS SageMaker Monitoring: docs.aws.amazon.com/sagemaker/latest/dg/monitoring-cloudwatch.html
• SageMaker Endpoints Metrics: docs.aws.amazon.com/sagemaker/latest/dg/monitoring-cloudwatch-endpoint-metrics.html

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

Đáp án đúng: Generate an Amazon CloudWatch dashboard to create a single view for the latency, memory utilization, and CPU utilization metrics that are outputted by Amazon SageMaker.

Lý do:

• SageMaker endpoint tự động emit (xuất) các metrics chuẩn như Latency, CPUUtilization, và MemoryUtilization trực tiếp đến CloudWatch Metrics (Namespace: AWS/SageMaker).
• Tạo CloudWatch Dashboard cho phép tổng hợp một view duy nhất (single view), hiển thị đồ thị thời gian thực, dễ dàng theo dõi trong load test. Điều này hỗ trợ cấu hình Auto Scaling dựa trên target metrics (ví dụ: scale out khi CPU > 70%).
• Phương pháp đơn giản, native, không cần tool bên thứ ba, phù hợp với best practice AWS (cập nhật 2026: CloudWatch hỗ trợ Embedded Metrics và Anomaly Detection cho SageMaker).

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

• ❌ Phương án SAI: Review SageMaker logs that have been written to Amazon S3 by leveraging Amazon Athena and Amazon QuickSight to visualize logs as they are being produced.
  Giải thích: Logs của SageMaker (như training/debugger logs) được lưu vào S3, nhưng không chứa metrics hiệu suất endpoint như latency/CPU/memory một cách trực tiếp. Athena + QuickSight dùng để query/visualize logs text-based (batch processing), không phù hợp real-time load test (chậm, không native metrics). SageMaker logs chủ yếu cho debugging, không phải monitoring metrics.

• ✅ Phương án ĐÚNG: Generate an Amazon CloudWatch dashboard to create a single view for the latency, memory utilization, and CPU utilization metrics that are outputted by Amazon SageMaker.
  Giải thích: Như đã nêu ở phần đáp án đúng – đây là cách chuẩn và hiệu quả nhất, tận dụng CloudWatch Metrics native của SageMaker cho real-time dashboard.

• ❌ Phương án SAI: Build custom Amazon CloudWatch Logs and then leverage Amazon ES and Kibana to query and visualize the log data as it is generated by Amazon SageMaker.
  Giải thích: Yêu cầu build custom logs (phức tạp, không cần thiết vì SageMaker đã có metrics sẵn). CloudWatch Logs + Amazon OpenSearch (ES cũ) + Kibana dùng cho log analytics/search, không phải metrics số như CPU/memory. SageMaker không output metrics qua logs mà qua Metrics namespace riêng.

• ❌ Phương án SAI: Send Amazon CloudWatch Logs that were generated by Amazon SageMaker to Amazon ES and use Kibana to query and visualize the log data.
  Giải thích: CloudWatch Logs từ SageMaker (nếu có) chỉ là text logs (request/response), không chứa metrics định lượng như latency/CPU. Forward đến OpenSearch + Kibana là cho log search/visualization, không real-time và không chính xác cho endpoint metrics (phải dùng CloudWatch Metrics dashboard thay thế).

🧠 Kết luận: Chọn CloudWatch Dashboard là best practice để load test và Auto Scaling SageMaker endpoint, giúp tiết kiệm thời gian và chi phí! 🚀

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

Câu hỏi tập trung vào một công ty sản xuất có dữ liệu có cấu trúc (như CSV, JSON) và không cấu trúc (như logs, images) lưu trữ trong Amazon S3 bucket. Một Machine Learning Specialist muốn sử dụng SQL để chạy các truy vấn (queries) trên dữ liệu này.
Yêu cầu chính là tìm giải pháp yêu cầu ÍT NỖ LỰC NHẤT (LEAST effort) để có thể query dữ liệu mà không cần di chuyển dữ liệu khỏi S3, tránh các bước ETL phức tạp, provisioning server hay quản lý cơ sở dữ liệu.
✅ Đây là tình huống điển hình trong AWS cho serverless querying trên dữ liệu lớn ở S3, tận dụng các dịch vụ không cần quản lý hạ tầng (serverless). Kiến thức cập nhật đến 2026: Amazon Athena (phiên bản mới nhất hỗ trợ federated queries, ML integrations) kết hợp AWS Glue (Glue Data Catalog v4.0+ với auto-crawlers cải tiến) là lựa chọn tối ưu nhất, không thay đổi lớn từ 2023-2026.

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

Đáp án đúng: Use AWS Glue to catalogue the data and Amazon Athena to run queries.
🛠️ Lý do chi tiết:

• AWS Glue tự động crawl (quét) dữ liệu S3, tạo schema và catalog (Glue Data Catalog) mà không cần code thủ công, hỗ trợ cả dữ liệu có cấu trúc (CSV, Parquet) và không cấu trúc (JSON, logs).
• Amazon Athena cho phép chạy SQL queries trực tiếp trên S3 (query-in-place), serverless, tính phí theo scan dữ liệu (pay-per-query), không cần ETL, load data hay quản lý cluster.
• Ít effort nhất: Chỉ cần tạo crawler Glue (1-2 clicks qua console), sau đó query SQL ngay. Thời gian setup < 10 phút, scale tự động cho PB dữ liệu. Hoàn hảo cho ML workflows (Athena tích hợp SageMaker).
  📘 Tài liệu tham khảo:
• AWS Athena Documentation (Query data in S3 with SQL).
• AWS Glue Crawlers (Auto-catalog S3 data, updated 2025 features).

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

Dưới đây là phân tích từng phương án một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên mức độ effort (công sức triển khai, quản lý, chi phí).

• [SAI] Use AWS Data Pipeline to transform the data and Amazon RDS to run queries.
  ❌ Giải thích sai: AWS Data Pipeline dùng cho ETL pipelines phức tạp (cần định nghĩa graph, scripts), phải transform và di chuyển dữ liệu từ S3 vào RDS (relational DB như MySQL/PostgreSQL). Effort cao: Provision RDS instance, quản lý scaling, backup, VPC; không phù hợp dữ liệu không cấu trúc lớn (RDS giới hạn scale). Không serverless, tốn kém cho query ad-hoc.

• [ĐÚNG] Use AWS Glue to catalogue the data and Amazon Athena to run queries.
  ✅ Giải thích đúng: Như phần trên, ít effort nhất nhờ serverless end-to-end. Glue catalog + Athena query trực tiếp S3, hỗ trợ SQL chuẩn (Presto/Trino engine, v3+ 2024). Lý tưởng cho structured/unstructured data mà không ETL.

• [SAI] Use AWS Batch to run ETL on the data and Amazon Aurora to run the queries.
  ❌ Giải thích sai: AWS Batch dùng cho batch computing (cần Docker images, job definitions, compute environments), chạy ETL custom rồi load vào Aurora (serverless MySQL/PostgreSQL). Effort rất cao: Code ETL, provision Batch queues, migrate data to Aurora (high IOPS chi phí), quản lý clusters. Không hiệu quả cho S3 static data lớn.

• [SAI] Use AWS Lambda to transform the data and Amazon Kinesis Data Analytics to run queries.
  ❌ Giải thích sai: Lambda cho transform serverless nhưng cần code handlers phức tạp cho ETL; Kinesis Data Analytics (nay là Amazon Managed Service for Apache Flink) dành cho streaming data real-time (không phải static S3). Effort cao: Phải stream data từ S3 qua Kinesis, setup Flink apps, SQL streaming queries. Không phù hợp batch/ML queries trên S3.

🧩 Tóm tắt insight: Athena + Glue là best practice AWS Well-Architected cho serverless SQL on S3 (Data Lake querying). Các phương án sai đều yêu cầu ETL + data movement → effort gấp 5-10 lần! Nếu implement, ưu tiên partition S3 (date/hour) để optimize Athena costs.