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

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

✅ Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi xoay quanh việc xử lý dữ liệu telemetry từ hàng nghìn endpoints toàn cầu, với dữ liệu được truyền mỗi 30 giây dưới dạng records (mỗi record có 50 fields, kích thước tối đa 1KB). Nhà cung cấp sử dụng Amazon Kinesis Data Streams để ingest dữ liệu thời gian thực. Yêu cầu chính là tạo hourly summaries (tóm tắt hàng giờ) từ dữ liệu này, sau đó sử dụng Amazon Athena để query chỉ 7-12 fields cụ thể và generate summaries.

Mục tiêu là tìm giải pháp với LEAST amount of customization (ít tùy chỉnh nhất) để transform (chuyển đổi/aggregate) và store dữ liệu vào S3 (để Athena query dễ dàng).
🛠️ Thách thức chính: Dữ liệu streaming cao tần suất (mỗi 30s), cần aggregate hourly mà không cần code phức tạp, tối ưu chi phí và dễ integrate với Athena (hỗ trợ formats như Parquet/JSON trên S3). Giải pháp phải tận dụng native features của AWS để giảm custom code.

✅ Đáp án đúng và lý do lựa chọn:
Đáp án đúng: Use Amazon Kinesis Data Analytics to read and aggregate the data hourly. Transform the data and store it in Amazon S3 by using Amazon Kinesis Data Firehose.

🧩 Lý do chi tiết (theo kiến thức AWS cập nhật 2026 - phiên bản Kinesis Data Analytics for Apache Flink v2.x):

• Amazon Kinesis Data Analytics (KDA) có native windowing (tumbling/sliding windows) để aggregate dữ liệu hourly trực tiếp từ Kinesis Data Streams mà không cần custom code phức tạp – chỉ dùng SQL hoặc Flink SQL để group by time windows và select 7-12 fields.
• Output từ KDA có thể pipe trực tiếp vào Kinesis Data Firehose (qua Kinesis Producer), Firehose tự động transform nhẹ (compression, format conversion sang Parquet/ORC) và store vào S3 với partitioning (e.g., by hour/day) – lý tưởng cho Athena query.
• Least customization: KDA xử lý streaming aggregation real-time với zero-code SQL apps, Firehose managed delivery (no servers). Tổng thể: ingest → aggregate hourly → transform/store → Athena query partitioned data. Giảm ETL custom so với Lambda/EMR.
• ✅ Tối ưu: Hỗ trợ high throughput (thousands endpoints), low latency, auto-scale.

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

❌ Phương án SAI: Use AWS Lambda to read and aggregate the data hourly. Transform the data and store it in Amazon S3 by using Amazon Kinesis Data Firehose.
🛠️ Giải thích sai: Lambda cần custom code phức tạp (stateful aggregation hourly từ Streams via Kinesis Client Library - KCL), quản lý tumbling windows thủ công, checkpointing. Dẫn đến high customization (code logic, error handling), không native như KDA. Firehose chỉ store, không aggregate.

❌ Phương án SAI: Use Amazon Kinesis Data Firehose to read and aggregate the data hourly. Transform the data and store it in Amazon S3 by using a short-lived Amazon EMR cluster.
🛠️ Giải thích sai: Firehose không hỗ trợ aggregate hourly native (chỉ buffering ~60-900s, không windowing chính xác). Phải dùng short-lived EMR (Spark) để transform – rất custom (provision cluster, code EMR jobs), costly (EMR startup time >1h), không phù hợp streaming real-time. Least customization? Không!

✅ Phương án ĐÚNG: Use Amazon Kinesis Data Analytics to read and aggregate the data hourly. Transform the data and store it in Amazon S3 by using Amazon Kinesis Data Firehose.
🛠️ Giải thích đúng (tóm tắt lại): Native hourly aggregation bằng Flink SQL windows trong KDA (zero-code), output qua Firehose đến S3 partitioned. Least custom – chỉ config app SQL đơn giản, auto-scale, Athena-ready.

❌ Phương án SAI: Use Amazon Kinesis Data Firehose to read and aggregate the data hourly. Transform the data and store it in Amazon S3 by using AWS Lambda.
🛠️ Giải thích sai: Firehose không aggregate hourly (buffer-based, không windowing). Lambda transformation chỉ record-level (via Firehose Lambda integration), cần custom code stateful cho hourly summary – phức tạp, shard management, không hiệu quả như KDA native.

📘 Tài liệu tham khảo (AWS Docs cập nhật 2026)

• Kinesis Data Analytics (Apache Flink): AWS Docs - Windowed Aggregations – Native hourly tumbling windows.
• KDA + Firehose Integration: AWS Blog - Streaming ETL with KDA & Firehose.
• Athena with S3 Partitioning: AWS Athena Best Practices – Optimized cho hourly data.
• So sánh Services: AWS Streaming Data Solution – Khuyến nghị KDA cho aggregation least-effort.

🛡️ Kết luận từ DevOps Pro: Giải pháp đúng tận dụng serverless streaming-native AWS, giảm ops overhead, scale global endpoints! 🚀

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

Câu hỏi tập trung vào việc xử lý một tính năng phân loại (categorical feature) trong dữ liệu khảo sát của công ty thiết bị y tế. Dữ liệu này thu thập tên thuốc mà khách hàng nhập thủ công từ câu hỏi khảo sát dạng văn bản thuần (plain text), dẫn đến lỗi chính tả phổ biến (misspellings), tạo ra độ cardinal cao (high cardinality) với sự dư thừa (redundancy) do nhiều biến thể tên thuốc giống nhau nhưng viết sai.

Mục tiêu là tìm cách hiệu quả NHẤT để mã hóa (encode) tính năng này thành tính năng số (numeric feature) cho mô hình ML dự đoán khả năng thu hồi thiết bị. Vấn đề chính là:

• High cardinality làm các phương pháp như one-hot encoding kém hiệu quả (dẫn đến ma trận thưa thớt khổng lồ, "curse of dimensionality").
• Redundancy từ lỗi chính tả cần phương pháp xử lý tương đồng (similarity) để nhóm các giá trị gần giống nhau.
  ✅ Đây là tình huống điển hình trong feature engineering trên Amazon SageMaker Data Wrangler, nơi cần embedding vectors để giữ thông tin ngữ nghĩa mà không làm nổ dữ liệu.

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

Đáp án đúng: Use Amazon SageMaker Data Wrangler similarity encoding on the column to create embeddings of vectors of real numbers.

Lý do:
🛠️ Similarity encoding trong SageMaker Data Wrangler (phiên bản mới nhất 2024-2026) là phương pháp tối ưu cho categorical features có high cardinality và redundancy, đặc biệt với dữ liệu text bị lỗi chính tả. Nó sử dụng sentence transformers (như all-MiniLM-L6-v2) để tạo embeddings vector số thực (real-number vectors) dựa trên tương đồng ngữ nghĩa (semantic similarity).

• Xử lý redundancy bằng cách nhóm các tên thuốc tương tự (fuzzy matching tự động).
• Giảm chiều dữ liệu xuống vector low-dimensional (thường 384 chiều), giữ thông tin mà không gây overfitting.
• Hoàn hảo cho ML models như trong SageMaker, dễ tích hợp với training pipelines.
  📘 Nguồn tham khảo: AWS SageMaker Data Wrangler Documentation - Similarity Encoding (https://docs.aws.amazon.com/sagemaker/latest/dg/data-wrangler-similarity-encoding.html); SageMaker Developer Guide 2024 (cập nhật hỗ trợ embeddings cho high-cardinality text).

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, đánh dấu ✅ đúng hoặc ❌ sai, với lý do cụ thể dựa trên best practices AWS ML (2026):

• ❌ [SAI] Spell check the column. Use Amazon SageMaker one-hot encoding on the column to transform a categorical feature to a numerical feature.
  🧩 Phương án này sửa lỗi chính tả thủ công trước, rồi dùng one-hot encoding. Sai vì: One-hot tạo hàng nghìn cột thưa thớt với high cardinality (hàng triệu tên thuốc unique do lỗi chính tả), dẫn đến memory explosion và kém hiệu suất ML. Spell check thủ công không scalable với dữ liệu lớn, không xử lý redundancy tốt. SageMaker hỗ trợ one-hot nhưng KHÔNG khuyến nghị cho high cardinality (theo AWS best practices).

• ❌ [SAI] Fix the spelling in the column by using char-RNN. Use Amazon SageMaker Data Wrangler one-hot encoding to transform a categorical feature to a numerical feature.
  🛠️ Sử dụng char-RNN (mô hình recurrent neural network cho sửa lỗi chính tả) rồi one-hot. Sai vì: Char-RNN phức tạp, tốn tài nguyên train (không phải built-in SageMaker), và vẫn gặp vấn đề one-hot với high cardinality sau sửa (redundancy vẫn tồn tại nếu model RNN không hoàn hảo). Data Wrangler có one-hot nhưng không hiệu quả cho trường hợp này; AWS ưu tiên embedding thay vì RNN + one-hot.

• ✅ [ĐÚNG] Use Amazon SageMaker Data Wrangler similarity encoding on the column to create embeddings of vectors of real numbers.
  (Đã giải thích chi tiết ở phần đáp án đúng). Phương pháp mạnh nhất, native trong Data Wrangler, xử lý trực tiếp misspelling qua similarity mà không cần preprocess thủ công.

• ❌ [SAI] Use Amazon SageMaker Data Wrangler ordinal encoding on the column to encode categories into an integer between 0 and the total number of categories in the column.
  📘 Ordinal encoding gán số nguyên theo thứ tự alphabet hoặc xuất hiện. Sai vì: Tên thuốc không có thứ tự tự nhiên (non-ordinal), dẫn đến model học sai ngữ nghĩa (ví dụ "Aspirin" =1, "Aspiring" misspelled=2 → coi như khác biệt lớn). Với high cardinality, vẫn tạo target encoding kém; AWS docs cảnh báo ordinal chỉ dùng cho ordered categories như rating (1-5 sao), không phù hợp text redundancy.

🛡️ Kết luận: Similarity encoding là giải pháp scalable, hiệu quả nhất theo AWS ML workflows hiện đại (2026), tích hợp seamless với SageMaker Pipelines và Feature Store!

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

Câu hỏi xoay quanh một chuyên gia Machine Learning (ML specialist) đang huấn luyện mô hình linear regression trên nền tảng AWS (có thể sử dụng Amazon SageMaker Linear Learner hoặc các công cụ ML tương tự). Ban đầu, mô hình bị overfitting (học quá khớp dữ liệu huấn luyện, hiệu suất kém trên dữ liệu kiểm tra). Để khắc phục, specialist áp dụng L1 regularization (hay còn gọi là Lasso regularization), nhưng kết quả là tất cả các feature đều có trọng số (weights) bằng zero.

Điều này cho thấy regularization quá mạnh (L1 penalty quá cao), dẫn đến mô hình underfitting nghiêm trọng – mô hình trở thành một hàm hằng số (constant model), không học được gì từ dữ liệu. Mục tiêu là cải thiện kết quả mô hình bằng cách điều chỉnh regularization mà không thay đổi các tham số huấn luyện khác.

Vấn đề cốt lõi: L1 regularization khuyến khích sparsity (nhiều trọng số = 0), và khi tham số L1 (lambda) quá lớn, tất cả weights bị đẩy về 0. Giải pháp cần giảm mức độ phạt để mô hình cân bằng giữa overfitting và underfitting.

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

• AWS SageMaker Documentation: Linear Learner Algorithm (cập nhật 2024-2026, hỗ trợ L1/L2 regularization với hyperparameter l1 và l2).
• AWS ML Specialty Exam Guide: Nhấn mạnh tuning regularization để tránh extreme sparsity (xem AWS Certified Machine Learning Study Guide).

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

Đáp án đúng: Decrease the L1 regularization parameter. Do not change any other training parameters.

Lý do:

• Khi tất cả weights = 0, chứng tỏ L1 lambda hiện tại quá cao, làm penalty quá mạnh → mô hình không học được pattern nào.
• Giảm L1 parameter (giảm lambda) sẽ nới lỏng regularization, cho phép một số weights khác 0, giúp mô hình học tốt hơn mà vẫn kiểm soát overfitting.
• Không thay đổi tham số khác đảm bảo isolation test – chỉ tuning L1 để fix vấn đề sparsity.
• 🛠️ Thực tế trên AWS SageMaker: Sử dụng Hyperparameter Tuning Job để giảm l1 từ giá trị cao (ví dụ: 1.0 → 0.1), kết hợp với metrics như validation accuracy.

📋 Giải thí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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên nguyên lý ML và AWS best practices:

• ❌ [SAI] Increase the L1 regularization parameter. Do not change any other training parameters.
  Giải thích sai: Tăng L1 lambda sẽ tăng penalty mạnh hơn, đẩy tất cả weights về 0 chắc chắn hơn, làm underfitting nặng thêm (mô hình vẫn là constant). Không giải quyết vấn đề, ngược lại làm tệ hơn. Trên SageMaker, lambda cao (>1.0) thường gây sparsity cực đoan.

• ✅ [ĐÚNG] Decrease the L1 regularization parameter. Do not change any other training parameters.
  Giải thích đúng: Như đã nêu ở trên, giảm L1 giảm sparsity, cho phép mô hình giữ lại các feature quan trọng, cân bằng overfitting/underfitting. Đây là step đầu tiên chuẩn trong tuning regularization cho linear models trên AWS (SageMaker khuyến nghị grid search lambda từ 10^-5 đến 10^1).

• ❌ [SAI] Introduce a large L2 regularization parameter. Do not change the current L1 regularization value.
  Giải thích sai: Giữ L1 cao (đã gây all-zero) và thêm L2 lớn (Ridge) sẽ shrink tất cả weights về gần 0 (không sparse như L1 nhưng vẫn underfit nặng). L2 không counteract L1 sparsity, dẫn đến mô hình yếu hơn. AWS docs cảnh báo kết hợp L1+L2 cần tuning cẩn thận, không dùng "large" khi L1 đã extreme.

• ❌ [SAI] Introduce a small L2 regularization parameter. Do not change the current L1 regularization value.
  Giải thích sai: L2 nhỏ chỉ thêm penalty nhẹ (shrink weights nhẹ), nhưng L1 hiện tại vẫn cao → vẫn giữ all-zero từ L1. Không đủ để recover model, vì L1 dominate sparsity. Trên SageMaker, cần giảm L1 trước khi thêm Elastic Net (L1+L2).

🧩 Lời khuyên thực hành: Sử dụng SageMaker Automatic Model Tuning (Bayesian Optimization) để tự động tìm lambda tối ưu, theo dõi metrics như train:regression:mean_absolute_error và validation:regression:mean_absolute_error. Kiểm tra feature importance qua weights output!

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

Câu hỏi này thuộc chủ đề Machine Learning (ML) trên AWS, cụ thể liên quan đến việc đánh giá hiệu suất mô hình ML trong bối cảnh dataset imbalanced (không cân bằng). Một nhà khoa học dữ liệu tại công ty chẩn đoán y tế đã xây dựng mô hình ML để xác định bệnh nhân mắc bệnh cụ thể. Dataset huấn luyện có số lượng bệnh nhân khỏe mạnh (negative class) lớn, chỉ ít bệnh nhân mắc bệnh (positive class). Điểm quan trọng: Mô hình cần ưu tiên giảm thiểu false positive (FP) – tức là trường hợp bệnh nhân khỏe mạnh bị phân loại nhầm là mắc bệnh – vì điều này sẽ tăng chi phí cho công ty (ví dụ: xét nghiệm thừa, điều trị không cần thiết).

Mục tiêu: Chọn metric đánh giá hiệu suất mô hình chính xác NHẤT (MOST accurately evaluate), đặc biệt trong dataset imbalanced và ưu tiên chi phí từ FP.
(Kiến thức cập nhật: Theo AWS SageMaker phiên bản mới nhất 2026, các metric như Precision được khuyến nghị cho imbalanced classification trong Clarify và Model Monitor để xử lý bias và cost-sensitive scenarios – xem AWS ML Best Practices).

✅ Đáp án đúng: Precision

Lý do lựa chọn:
Precision = TP / (TP + FP) đo lường tỷ lệ dự đoán positive thực sự đúng trong tổng số dự đoán positive. Trong trường hợp này:

• Dataset imbalanced → Accuracy dễ bị "lừa" bởi majority class (healthy).
• FP tăng chi phí → Precision trực tiếp minimize FP, đảm bảo khi mô hình "kêu" positive thì độ tin cậy cao, giảm lãng phí.
  🛠️ Đây là metric tối ưu cho cost-sensitive imbalanced classification trên AWS SageMaker (như trong DOP-C02 exam và SageMaker Model Registry).

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

• Precision [ĐÚNG]
  ✅ Đúng vì: Precision tập trung chính xác vào giảm FP (TP / (TP + FP)), phù hợp hoàn hảo với yêu cầu "patients incorrectly identified as positive will increase costs". Trong imbalanced dataset y tế trên AWS SageMaker, đây là metric chuẩn để đánh giá positive prediction quality (tham khảo: AWS Docs - SageMaker Clarify Metrics, 2026).

• Recall [SAI]
  ❌ Sai vì: Recall = TP / (TP + FN) chỉ đo tỷ lệ positive thực sự được detect, ưu tiên giảm FN (missed diseased patients). Nhưng câu hỏi nhấn mạnh FP costs, không phải FN → Recall không phù hợp, có thể dẫn đến nhiều FP.

• F1 score [SAI]
  ❌ Sai vì: F1 là harmonic mean của Precision và Recall, cân bằng cả hai nhưng không ưu tiên FP cụ thể. Trong imbalanced data với cost từ FP cao, F1 vẫn "trung bình hóa" → kém chính xác hơn Precision thuần (AWS khuyến nghị dùng riêng Precision cho high-cost FP).

• Accuracy [SAI]
  ❌ Sai vì: Accuracy = (TP + TN) / total dễ bị lệch bởi majority class (healthy patients đông), có thể đạt >90% dù model kém với positive class. Hoàn toàn không phù hợp imbalanced dataset – AWS ML docs cảnh báo rõ ràng về hạn chế này.

📘 Tài liệu tham khảo

• AWS SageMaker Documentation (2026): Model Metrics Interpretation & Clarify Bias Detection – Nhấn mạnh Precision cho imbalanced medical use cases.
• AWS DOP-C02 Exam Guide: Domain 5 (Automation & Optimization) – ML evaluation metrics.
• Best Practices: AWS ML Specialty whitepaper "Handling Imbalanced Data" (2025 update).

🧐 Kết luận: Precision là lựa chọn chuẩn AWS cho scenario này! Nếu cần code SageMaker ví dụ, hãy hỏi thêm nhé! 🚀

🧩 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 chia sẻ Feature Repository trong Amazon SageMaker Feature Store giữa các AWS accounts khác nhau (development, integration, và production).

• Bối cảnh: Một ML engineer đã tạo feature repository trong SageMaker Feature Store ở development account. Feature values offline được lưu trong Amazon S3 buckets. Công ty muốn chia sẻ features để integration và production accounts có thể tái sử dụng (reuse) chúng một cách an toàn và hiệu quả.
• Yêu cầu chính: Chọn hai bước kết hợp (choose TWO) để đáp ứng việc chia sẻ cả online features (trong Feature Store) và offline features (trong S3).
• Thách thức: Cross-account access cần tuân thủ nguyên tắc least privilege, không copy dữ liệu thừa, và hỗ trợ real-time/online queries cho ML training/inference.
• Phiên bản AWS cập nhật 2026: SageMaker Feature Store (từ phiên bản 2023+) hỗ trợ AWS Resource Access Manager (RAM) để share Feature Groups cross-account. IAM roles với cross-account assume role là best practice cho S3 access. Không cần replication hay STS direct cho sharing.

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

• AWS SageMaker Feature Store - Sharing Feature Groups with RAM (cập nhật 2025).
• AWS RAM for SageMaker.
• Cross-account access to S3 via IAM roles.

✅ Đáp án đúng (Chọn TWO)

Hai phương án sau là đúng vì chúng trực tiếp giải quyết sharing Feature Store (online) và S3 buckets (offline) cross-account mà không cần copy dữ liệu:

1. Create an IAM role in the development account that the integration account and production account can assume. Attach IAM policies to the role that allow access to the feature repository and the S3 buckets.
   🛠️ Lý do: Tạo IAM role ở dev account với trust policy cho phép integration/production assume role (sử dụng sts:AssumeRole). Attach policies grant sagemaker:DescribeFeatureGroup, sagemaker:GetRecord cho Feature Store và s3:GetObject cho buckets. Đây là cách chuẩn cho cross-account access, hỗ trợ cả online/offline queries.

2. Share the feature repository that is associated the S3 buckets from the development account to the integration account and the production account by using AWS Resource Access Manager (AWS RAM).
   🛠️ Lý do: AWS RAM cho phép share Feature Groups (và associated S3 buckets cho offline storage) trực tiếp cross-account. Dev account tạo resource share, invite integration/production. Sau đó, các account kia accept và truy cập như local resources. Hỗ trợ real-time sharing mà không migrate data.

❌ Phân tích tất cả các phương án (Đúng/Sai)

Dưới đây là giải thích từng phương án một với nội dung gốc giữ nguyên tiếng Anh. Phân tích dựa trên best practices AWS 2026:

• ✅ Create an IAM role in the development account that the integration account and production account can assume. Attach IAM policies to the role that allow access to the feature repository and the S3 buckets.
  🟢 Đúng: Như giải thích trên, đây là cơ chế cross-account role assumption chuẩn cho SageMaker Feature Store và S3. Không cần chia sẻ credentials, an toàn với temporary tokens. Hỗ trợ full access (read/write) cho reuse features.

• ✅ Share the feature repository that is associated the S3 buckets from the development account to the integration account and the production account by using AWS Resource Access Manager (AWS RAM).
  🟢 Đúng: AWS RAM là tính năng native cho sharing SageMaker Feature Groups + S3 offline storage. Giảm latency, không duplicate data. Kết hợp với IAM role ở trên để hoàn thiện access control.

• ❌ Use AWS Security Token Service (AWS STS) from the integration account and the production account to retrieve credentials for the development account.
  🔴 Sai: STS dùng để generate temporary credentials, nhưng không phải cho sharing persistent resources như Feature Store. Cần assume role (như phương án 1) chứ không phải retrieve creds trực tiếp dev account (vi phạm security, dễ bị misuse). Không scale cho ML workloads.

• ❌ Set up S3 replication between the development S3 buckets and the integration and production S3 buckets.
  🔴 Sai: Replication chỉ copy offline data từ S3 dev sang integration/production, không share online Feature Store (real-time queries). Tốn chi phí storage, latency cao, và không sync metadata Feature Groups. Không meet yêu cầu "reuse features" đầy đủ.

• ❌ Create an AWS PrivateLink endpoint in the development account for SageMaker.
  🔴 Sai: PrivateLink dùng cho VPC private access đến SageMaker endpoints (như training jobs), không phải sharing Feature Store cross-account. Chỉ giới hạn trong VPC peering, không hỗ trợ resource-level sharing như RAM. Phức tạp và không cần thiết cho multi-account setup.

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

Câu hỏi xoay quanh một công ty đang xây dựng mô hình phân loại giám sát (supervised classification model) trong môi trường AWS. Dataset của họ có số lượng biến số (variables/features) rất lớn, và tất cả đều là kiểu số (numeric). Đội ngũ data science nhận thấy:

• Độ chính xác (accuracy) của mô hình trên tập train và validation thấp (low accuracy).
• Thời gian xử lý (processing time) bị ảnh hưởng bởi độ trễ cao (high latency) do số lượng features quá nhiều, dẫn đến "curse of dimensionality" (lời nguyền chiều dữ liệu cao), làm mô hình khó học và tính toán chậm.

Mục tiêu: Tăng độ chính xác mô hình và giảm thời gian xử lý. Giải pháp cần áp dụng dimensionality reduction (giảm chiều dữ liệu) để loại bỏ redundancy, noise, giữ lại thông tin chính yếu – đặc biệt phù hợp với dữ liệu numeric thuần túy trong AWS SageMaker (hỗ trợ PCA qua Processing Jobs hoặc Built-in Algorithms).

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

• AWS SageMaker Documentation: Principal Component Analysis (PCA) (cập nhật 2024-2026, hỗ trợ giảm chiều dữ liệu numeric hiệu quả).
• AWS ML Best Practices: Dimensionality Reduction in SageMaker Processing (SageMaker Studio 3.0+).

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

Đáp án đúng: Use a principal component analysis (PCA) model.

Lý do:

• PCA là kỹ thuật giảm chiều dữ liệu (dimensionality reduction) lý tưởng cho dữ liệu numeric thuần túy với số lượng features lớn. Nó chuyển đổi features gốc thành các principal components (thành phần chính) orthogonal, giữ lại variance lớn nhất (thường 95%+ thông tin), loại bỏ multicollinearity và noise.
• Tăng accuracy: Giảm overfitting/underfitting do curse of dimensionality, giúp mô hình học tốt hơn trên train/validation.
• Giảm processing time/latency: Số features giảm đáng kể (ví dụ: từ hàng nghìn xuống vài trăm), tăng tốc training/inference trên SageMaker (hỗ trợ GPU/TPU acceleration).
• Trong AWS SageMaker, PCA được tích hợp sẵn như algorithm hoặc processing job, dễ scale với EMR/SageMaker Pipelines (phiên bản mới nhất 2026 hỗ trợ AutoML với PCA preprocessing).

🛠️ Ví dụ triển khai: Sử dụng sagemaker.sklearn.ProcessingJob với PCA từ scikit-learn, hoặc SageMaker JumpStart cho low-code.

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

• ❌ Create new features and interaction variables.
  Sai vì: Tạo thêm features mới (feature engineering như polynomial/interaction terms) sẽ tăng số lượng biến số, làm tình trạng high dimensionality tệ hơn, dẫn đến accuracy thấp hơn (overfitting) và latency cao hơn. Không giải quyết vấn đề gốc là "large quantity of variables".

• ✅ Use a principal component analysis (PCA) model.
  Đúng vì: Như đã giải thích ở trên, PCA trực tiếp giảm chiều dữ liệu numeric, tăng accuracy bằng cách giữ variance chính và giảm noise, đồng thời tối ưu processing time trên AWS SageMaker. Đây là giải pháp chuẩn theo best practices AWS ML.

• ❌ Apply normalization on the feature set.
  Sai vì: Normalization (Min-Max hoặc Z-score) chỉ chuẩn hóa scale giữa các features (hữu ích nếu scale khác nhau), nhưng không giảm số lượng features. Vấn đề chính là "large quantity of variables" gây latency và low accuracy – normalization không giải quyết dimensionality, thậm chí có thể làm chậm hơn nếu không kết hợp.

• ❌ Use a multiple correspondence analysis (MCA) model.
  Sai vì: MCA dùng cho dữ liệu categorical/non-numeric (như one-hot encoded), không phù hợp với "all variables are numeric". MCA sẽ không hiệu quả, có thể gây lỗi hoặc kết quả kém trên SageMaker (PCA mới là lựa chọn cho numeric data). AWS khuyến nghị PCA cho trường hợp này.

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

Câu hỏi mô tả một công ty nghiên cứu động vật hoang dã sở hữu bộ sưu tập hình ảnh về sư tử (lions) và báo gêpa (cheetahs). Họ đã tạo một dataset với các hình ảnh được gán nhãn nhị phân (binary label): mỗi hình ảnh chỉ được đánh dấu là chứa sư tử hoặc báo gêpa. Mục tiêu là huấn luyện một mô hình để phân loại (classify) các hình ảnh mới, xác định xem chúng chứa sư tử hay báo gêpa.

• Yêu cầu chính: Đây là nhiệm vụ phân loại hình ảnh nhị phân (binary image classification), nơi mô hình cần dự đoán toàn bộ hình ảnh thuộc một trong hai lớp (lion hoặc cheetah). Không liên quan đến phát hiện vị trí object, phân đoạn pixel, hay dữ liệu bảng.
• Ngữ cảnh AWS SageMaker: SageMaker cung cấp các built-in algorithms (thuật toán tích hợp sẵn) được tối ưu hóa cho các nhiệm vụ ML cụ thể, hỗ trợ training trên dữ liệu hình ảnh với framework như TensorFlow hoặc MXNet (cập nhật đến 2026, SageMaker vẫn duy trì các algorithm này với hỗ trợ GPU/TPU cho hiệu suất cao).

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

• AWS SageMaker Image Classification Algorithm: docs.aws.amazon.com/sagemaker/latest/dg/image-classification.html
• SageMaker Built-in Algorithms: docs.aws.amazon.com/sagemaker/latest/dg/algos.html

✅ Đáp án đúng: Image Classification - TensorFlow

Lý do lựa chọn:

• Thuật toán Image Classification - TensorFlow là built-in algorithm của SageMaker được thiết kế chuyên biệt cho phân loại hình ảnh (image classification), hỗ trợ binary classification (nhị phân) hoặc multi-class.
• Nó sử dụng TensorFlow framework với mô hình CNN (Convolutional Neural Network) như ResNet, Inception, được pre-trained và fine-tune trên dataset của người dùng (hình ảnh sư tử/báo gêpa).
• Hoàn hảo cho yêu cầu: Input là hình ảnh labeled, output là lớp dự đoán (lion/cheetah). SageMaker tự động xử lý data augmentation, training job với hyperparameter tuning (như epochs, learning rate).
• Cập nhật 2026: Vẫn là lựa chọn tiêu chuẩn, tích hợp JumpStart models cho zero-shot/few-shot nếu cần.

🛠️ Cách triển khai nhanh: Sử dụng sagemaker.image_classification estimator, upload dataset vào S3, chạy fit() trên training/validation channels.

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

• XGBoost ❌
  Phân tích sai: XGBoost là thuật toán gradient boosting cho dữ liệu bảng (tabular data) như CSV/Parquet, không hỗ trợ trực tiếp dữ liệu hình ảnh thô. Phải extract features thủ công (ví dụ: dùng OpenCV), mất hiệu quả và không tận dụng CNN cho image. Không phù hợp cho binary image classification.

• Image Classification - TensorFlow ✅
  Phân tích đúng: Như đã giải thích ở trên, đây là lựa chọn tối ưu nhất cho nhiệm vụ phân loại toàn bộ hình ảnh vào lớp nhị phân. SageMaker cung cấp container sẵn, hỗ trợ transfer learning từ ImageNet.

• Object Detection - TensorFlow ❌
  Phân tích sai: Đây là thuật toán cho phát hiện object (object detection), output là hộp giới hạn (bounding boxes) + lớp cho từng object trong hình (ví dụ: vị trí sư tử). Không dùng cho phân loại toàn bộ hình ảnh (chỉ cần lion/cheetah, không cần vị trí). Sử dụng SSD/Mask R-CNN, phức tạp hơn và overkill.

• Semantic segmentation - MXNet ❌
  Phân tích sai: Thuật toán này dùng cho phân đoạn ngữ nghĩa (semantic segmentation) ở mức pixel-level (mỗi pixel được gán lớp, ví dụ: pixel sư tử vs nền). Input yêu cầu pixel-perfect masks, không phải binary label đơn giản cho toàn hình. Dùng MXNet với FCN/ResNet, không khớp yêu cầu classification.

🧩 Kết luận nổi bật: Chọn Image Classification - TensorFlow để tiết kiệm thời gian, chi phí và đạt accuracy cao nhất cho binary image classification trên SageMaker! 🚀

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

Câu hỏi mô tả một công ty phân tích dữ liệu tập luyện thể dục muốn dự đoán tốc độ chạy của khách hàng dựa trên bộ dữ liệu chứa nhiều đặc trưng liên quan đến sức khỏe (features), trong đó một số đặc trưng đến từ cảm biến (sensors) có giá trị nhiễu rất lớn (extremely noisy values). 🏃‍♂️

Họ đang huấn luyện mô hình hồi quy (regression model) bằng thuật toán Linear Learner tích hợp sẵn của Amazon SageMaker để dự đoán tốc độ chạy. Trong quá trình huấn luyện, data scientist quan sát thấy:

• Training loss giảm xuống gần 0 (mô hình học thuộc lòng dữ liệu huấn luyện).
• Validation loss tăng lên (mô hình không tổng quát hóa tốt trên dữ liệu kiểm tra).

Vấn đề cốt lõi: Đây là hiện tượng overfitting (quá khớp) – mô hình quá phức tạp, phù hợp quá mức với dữ liệu huấn luyện (có nhiễu cao), dẫn đến hiệu suất kém trên dữ liệu mới. 📈❌

Mục tiêu: Chọn kỹ thuật tối ưu nhất để cải thiện độ fit của mô hình, giúp giảm overfitting mà vẫn giữ khả năng dự đoán tốt. Câu hỏi thuộc chủ đề Machine Learning trên AWS SageMaker, cụ thể là xử lý overfitting trong Linear Learner (phiên bản cập nhật mới nhất đến 2026: SageMaker hỗ trợ hyperparameters regularization linh hoạt hơn với tích hợp AutoML và SageMaker Canvas).

✅ Đáp án đúng: Add L2 regularization to the linear learner regression model.

Lý do lựa chọn:

• L2 regularization (Ridge regularization) thêm phạt hàm mất mát (loss function) dựa trên bình phương tổng các trọng số (weights), giúp giảm độ lớn của weights, ngăn chặn overfitting hiệu quả trong linear regression với dữ liệu nhiễu cao. 🛡️
• Trong SageMaker Linear Learner, hyperparameter l2 (mặc định 0) được thiết lập để kiểm soát mức phạt L2, giúp mô hình tổng quát hóa tốt hơn mà không làm mất nhiều thông tin đặc trưng (khác với L1 làm thưa thớt features).
• Với dữ liệu noisy từ sensors, L2 là lựa chọn tối ưu vì nó "làm mịn" weights, giảm variance mà giữ bias thấp. Kết quả: Training loss không giảm quá sâu, validation loss ổn định hơn. 🎯
• Cập nhật 2026: SageMaker Linear Learner (với SageMaker Pipelines) khuyến nghị L2 cho regression noisy data, tích hợp tự động tuning qua Hyperparameter Optimization (HPO).

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

• ❌ [SAI] Add L1 regularization to the linear learner regression model.
  L1 regularization (Lasso) thêm phạt giá trị tuyệt đối của weights, khuyến khích sparsity (đặt nhiều weights về 0, loại bỏ features không quan trọng). Tuy nhiên, với dữ liệu noisy cao từ nhiều sensors, L1 có thể loại bỏ quá nhiều features hữu ích, dẫn đến underfitting thay vì giải quyết overfitting. Không tối ưu bằng L2 cho trường hợp này (L2 giữ tất cả features nhưng thu nhỏ weights). Trong SageMaker, dùng l1 hyperparameter, nhưng docs ưu tiên L2 cho noisy regression.

• ❌ [SAI] Perform a principal component analysis (PCA) on the dataset. Use the linear learner regression model.
  PCA giảm chiều dữ liệu bằng cách chuyển sang principal components, giúp xử lý multicollinearity hoặc dữ liệu high-dimensional. Tuy nhiên, nó không trực tiếp giảm overfitting ở linear model vì chỉ transform features mà không phạt complexity. Với noisy data, PCA có thể giữ nhiễu trong components, làm validation loss vẫn cao. SageMaker hỗ trợ PCA qua Processing Jobs, nhưng không phải giải pháp chính cho overfitting ở Linear Learner.

• ❌ [SAI] Perform feature engineering by including quadratic and cubic terms. Train the linear learner regression model.
  Thêm quadratic/cubic terms tạo polynomial features, làm mô hình phi tuyến tính phức tạp hơn (tương đương mô hình bậc cao). Điều này tăng overfitting nghiêm trọng hơn vì training loss đã gần 0 – thêm complexity chỉ làm vấn đề tệ đi! Linear Learner hỗ trợ binary classification tốt hơn polynomial, không khuyến khích cho regression noisy. 🛑

• ✅ [ĐÚNG] Add L2 regularization to the linear learner regression model.
  (Giải thích chi tiết ở phần trên – kỹ thuật tối ưu nhất cho overfitting trong SageMaker Linear Learner với noisy features).

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

• AWS SageMaker Linear Learner Documentation: https://docs.aws.amazon.com/sagemaker/latest/dg/linear-learner.html (Hyperparameters: l1, l2 – L2 ưu tiên cho regression overfitting).
• SageMaker Best Practices for Overfitting: https://docs.aws.amazon.com/sagemaker/latest/dg/model-accuracy-improvement.html (Regularization techniques).
• AWS ML Specialty Exam Guide: Khuyến nghị L2 cho noisy sensor data trong DOP-C02 (DevOps Engineer Professional).
• SageMaker Examples Notebook: GitHub aws-samples/amazon-sagemaker-examples/linear_learner_regressor.html (Demo L2 tuning).

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần demo code SageMaker, hãy hỏi thêm.

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

Câu hỏi xoay quanh một công ty đang lập kế hoạch chiến dịch marketing cho sản phẩm mới, sử dụng dữ liệu lịch sử từ các promotion tương tự. Họ muốn thử nghiệm gửi gói marketing đắt tiền hơn cho số lượng khách hàng nhỏ hơn, tập trung vào những khách hàng có khả năng mua cao nhất. Yêu cầu quan trọng: Ít nhất 90% khách hàng có khả năng mua sản phẩm mới (positive class) phải nhận được tài liệu marketing (tức là recall >= 90%).

Model hiện tại được train bằng Linear Learner algorithm trong Amazon SageMaker (dùng cho binary classification: mua/không mua), với recall = 80% và precision = 75%. Recall hiện tại chưa đạt yêu cầu (chỉ capture 80% positive samples), cần retrain model để đạt recall >=90% mà vẫn giữ tính chính xác cao (precision tốt, tránh gửi cho quá nhiều false positive vì gói đắt tiền).

📘 Mục tiêu retrain: Sử dụng hyperparameter của Linear Learner để enforce constraint trên recall >=90%, đồng thời tối ưu precision (vì target "most likely to buy" → ít FP hơn). Đây là tính năng model selection criteria trong SageMaker Linear Learner cho binary classifier, giúp tự động chọn model/threshold tốt nhất dựa trên target metric.

Kiến thức cập nhật (AWS SageMaker 2024-2026): Linear Learner hỗ trợ hyperparameter target_recall/target_precision kết hợp binary_classifier_model_selection_criteria để constrain và optimize metric. Không thay đổi lớn ở phiên bản mới.

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

• AWS SageMaker Docs: Linear Learner Hyperparameters
• Built-in Algorithms - Linear Learner

✅ Đáp án đúng: Phương án đầu tiên

Set the target_recall hyperparameter to 90%. Set the binary_classifier_model_selection_criteria hyperparameter to recall_at_target_precision.

Lý do lựa chọn (chi tiết):

• Yêu cầu chính là recall >=90% (capture ít nhất 90% khách hàng sẽ mua). Set target_recall = 90% (0.9) để định nghĩa constraint.
• binary_classifier_model_selection_criteria = 'recall_at_target_precision' giúp SageMaker chọn model có recall cao nhất trong khi precision >= target_precision (sử dụng giá trị mặc định hoặc từ training). Điều này ưu tiên tăng recall từ 80% lên >=90%, đồng thời giữ precision hợp lý (75% hiện tại), phù hợp cho việc target "most likely" (giảm FP).
• Kết hợp này enforce recall requirement trực tiếp qua hyperparameter tuning, tự động adjust threshold để đạt mục tiêu. Model sẽ được retrain với hyperparams tốt hơn để satisfy điều kiện.

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

• Phương án A: Set the target_recall hyperparameter to 90%. Set the binary_classifier_model_selection_criteria hyperparameter to recall_at_target_precision.
  ✅ Đúng. Như giải thích trên, trực tiếp address recall requirement bằng target_recall=90% và criteria ưu tiên recall cao tại precision threshold. Đây là cách chuẩn của SageMaker để meet "at least 90% coverage" cho positive class mà không cần manual threshold adjustment sau training. Phù hợp nhất với scenario (high recall + reasonable precision cho expensive campaign).

• Phương án B: Set the target_precision hyperparameter to 90%. Set the binary_classifier_model_selection_criteria hyperparameter to precision_at_target_recall.
  ❌ Sai. Set target_precision=90% quá cao (hiện tại chỉ 75%), sẽ làm recall giảm thêm (trade-off giữa precision/recall). Criteria precision_at_target_recall yêu cầu target_recall chứ không phải target_precision, dẫn đến mismatch hyperparam → SageMaker không optimize đúng, không guarantee recall >=90%. Không phù hợp vì ưu tiên precision cao nhưng yêu cầu là recall.

• Phương án C: Use 90% of the historical data for training. Set the number of epochs to 20.
  ❌ Sai. Sử dụng 90% data training (có lẽ imply train/test split) và tăng epochs=20 chỉ ảnh hưởng đến overfitting/underfitting, không liên quan trực tiếp đến recall/precision target. Không enforce được recall >=90%, model vẫn có thể có recall 80% nếu data bias. Đây là tuning generic, không target metric cụ thể như yêu cầu.

• Phương án D: Set the normalize_label hyperparameter to true. Set the number of classes to 2.
  ❌ Sai. normalize_label=true dùng cho label không chuẩn (scale về 0-1), nhưng binary classification (mua/không mua) mặc định đã handle (label 0/1). num_classes=2 là default cho binary, không cần set. Không ảnh hưởng đến recall/precision, chỉ là config cơ bản không giải quyết vấn đề metric constraint.

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

Câu hỏi tập trung vào vấn đề overfitting (quá khớp) trong mô hình học máy (ML) computer vision để phân loại 10 loại biển báo giao thông khác nhau. 🛣️

• Dữ liệu: Công ty có 100 ảnh đã gắn nhãn (labeled) cho mỗi lớp (tổng 1.000 ảnh labeled), lưu trữ trên Amazon S3. Ngoài ra, có 10.000 ảnh chưa gắn nhãn (unlabeled). Tất cả ảnh đều từ camera hành trình (dash cameras), kích thước chuẩn 224x224 pixels.
• Vấn đề: Sau nhiều lần huấn luyện, mô hình overfitting trên dữ liệu huấn luyện (học thuộc lòng dữ liệu train nhưng kém hiệu suất trên dữ liệu mới/test).
• Yêu cầu: Chọn hai hành động mà chuyên gia ML nên thực hiện để khắc phục overfitting, sử dụng các dịch vụ AWS như Amazon SageMaker.
  Overfitting thường xảy ra do dữ liệu huấn luyện ít, thiếu đa dạng, dẫn đến mô hình không tổng quát hóa tốt. Giải pháp phổ biến: tăng dữ liệu, data augmentation, regularization. 📈 (Kiến thức cập nhật AWS SageMaker đến 2026: Best practices từ SageMaker JumpStart và Built-in Algorithms nhấn mạnh data augmentation và labeling để chống overfitting).

✅ Đáp án đúng (Chọn TWO)

Hai lựa chọn đúng là:

1. Use Amazon SageMaker Ground Truth to label the unlabeled images.
2. Use data augmentation to rotate and translate the labeled images.

Lý do chọn:
🛠️ SageMaker Ground Truth giúp gắn nhãn nhanh chóng 10.000 ảnh unlabeled bằng công cụ active learning và human-in-the-loop, tăng đáng kể lượng dữ liệu labeled chất lượng cao → giảm overfitting bằng cách cung cấp thêm dữ liệu đa dạng.
🛠️ Data augmentation (xoay và dịch chuyển ảnh labeled) tạo biến thể nhân tạo từ dữ liệu hiện có, tăng độ đa dạng (diversity) mà không cần dữ liệu mới → trực tiếp chống overfitting bằng cách mô phỏng biến đổi thực tế từ dash cam (như góc quay, rung lắc).
Kết hợp hai cách này là best practice của AWS cho computer vision với dữ liệu hạn chế (theo SageMaker Data Augmentation docs 2025+).

📋 Giải thích chi tiết TẤT CẢ các phương án

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

• Use Amazon SageMaker Ground Truth to label the unlabeled images.
  ✅ ĐÚNG. SageMaker Ground Truth là dịch vụ managed labeling mạnh mẽ, hỗ trợ semi-supervised learning và active learning để gắn nhãn hiệu quả 10k ảnh unlabeled. Tăng dữ liệu labeled giúp mô hình học tổng quát hơn, trực tiếp giải quyết overfitting. (Nguồn: 📘 AWS SageMaker Ground Truth Documentation - Cập nhật 2026 với tích hợp SageMaker Canvas).

• Use image preprocessing to transform the images into grayscale images.
  ❌ SAI. Chuyển sang grayscale làm mất thông tin màu sắc (color), vốn rất quan trọng cho traffic signs (ví dụ: đỏ dừng, xanh đi). Điều này không tăng đa dạng dữ liệu mà còn giảm độ phong phú, có thể làm overfitting tệ hơn hoặc giảm accuracy tổng thể. Preprocessing grayscale chỉ phù hợp case cụ thể, không phải giải pháp chống overfitting ở đây.

• Use data augmentation to rotate and translate the labeled images.
  ✅ ĐÚNG. Data augmentation qua rotate/translate (xoay, dịch chuyển) là kỹ thuật chuẩn trong SageMaker (hỗ trợ qua TensorFlow/Keras hoặc SageMaker Processing Jobs). Nó tạo dữ liệu mới từ 1.000 ảnh labeled, mô phỏng biến đổi thực tế từ dash cam → tăng robustness, giảm overfitting hiệu quả mà không cần labeling thêm ngay.

• Replace the activation of the last layer with a sigmoid.
  ❌ SAI. Sigmoid dùng cho binary classification (0-1), không phù hợp multi-class (10 classes). Với multi-class cần softmax ở last layer để output xác suất phân phối (sum=1). Thay sigmoid sẽ làm mô hình không hội tụ đúng, không liên quan đến overfitting mà còn gây underfitting hoặc sai kết quả.

• Use the Amazon SageMaker k-nearest neighbors (k-NN) algorithm to label the unlabeled images.
  ❌ SAI. SageMaker k-NN là algorithm cho inference nearest neighbors (tìm kiếm tương tự), không phải công cụ labeling chuẩn. Nó kém hiệu quả với high-dimensional images (224x224), dễ noise và không scalable cho 10k ảnh computer vision. Nên dùng Ground Truth hoặc Clarify thay vì k-NN cho labeling semi-supervised.

🛡️ Lời khuyên thực hành (Best Practices AWS 2026)

• Kết hợp SageMaker Debugger để monitor overfitting (loss curves).
• Sử dụng SageMaker JumpStart models pretrained cho computer vision (như ResNet) + augmentation.
• Tham khảo: 📘 AWS ML Overfitting Best Practices và Computer Vision Workflows.
  Nếu áp dụng, accuracy sẽ cải thiện đáng kể! 🚀