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

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

Câu hỏi mô tả một tình huống thực tế trong AWS Machine Learning (sử dụng dịch vụ như Amazon SageMaker để huấn luyện mô hình). Một công ty bảo hiểm đang phát triển thiết bị camera trên xe hơi để giám sát hành vi tài xế (phát hiện phân tâm). Họ có khoảng 10.000 ảnh huấn luyện thu thập từ môi trường kiểm soát (controlled environment), được sử dụng để train và evaluate mô hình ML.

📊 Vấn đề chính:

• Training error rate giảm nhanh khi tăng số epochs (dấu hiệu model học thuộc lòng dữ liệu train).
• Nhưng model không infer chính xác trên test images unseen (dữ liệu kiểm tra mới, chưa thấy).

🔍 Chẩn đoán: Đây là hiện tượng overfitting kinh điển! Model quá "fit" với dữ liệu train (ít đa dạng, từ môi trường kiểm soát), dẫn đến generalization kém trên dữ liệu thực tế (unseen test). Với dataset nhỏ (10k ảnh), overfitting dễ xảy ra trong deep learning/computer vision tasks như object detection hoặc behavior analysis trên SageMaker.

🎯 Yêu cầu: Chọn HAI phương án để khắc phục (resolve this issue), dựa trên best practices ML trên AWS (cập nhật đến 2026, SageMaker hỗ trợ đầy đủ data aug và regularization qua built-in algorithms hoặc custom training jobs).

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

Hai phương án đúng là:

• Perform data augmentation on the training data.
• Add L2 regularization to the model.

Lý do lựa chọn 🛠️:

• Overfitting cần giải pháp tăng generalization: Data augmentation tạo dữ liệu train đa dạng hơn (như rotate, flip, brightness changes), giúp model học tốt hơn trên biến thể thực tế. L2 regularization (weight decay) phạt các weights lớn, giảm complexity model mà không cần thay đổi architecture.
• Với 10k ảnh từ môi trường kiểm soát, data aug đặc biệt hiệu quả (SageMaker BlazingText hoặc built-in transforms hỗ trợ). L2 reg là standard trong neural nets (TorchScript/ TensorFlow trên SageMaker).
• Kết hợp hai cái này là best practice theo AWS ML Best Practices (giảm variance mà không bias quá cao).

📋 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 một, giữ nguyên text gốc tiếng Anh. Mỗi phần giải thích hoàn toàn bằng tiếng Việt, đánh dấu ✅ (đúng) hoặc ❌ (sai) với lý do rõ ràng:

• ❌ Add vanishing gradient to the model.
  Sai hoàn toàn! Vanishing gradient là vấn đề phổ biến trong deep networks (gradient biến mất khi backprop, làm training chậm). "Add" nó vào model chỉ làm tình hình tệ hơn, không giải quyết overfitting. Đây là nhầm lẫn khái niệm – giải pháp thật là dùng ReLU/He init hoặc residual connections (như ResNet trên SageMaker).

• ✅ Perform data augmentation on the training data.
  Đúng! Với dataset nhỏ và kiểm soát (10k ảnh), augmentation (crop, flip, noise, color jitter) tạo hàng triệu biến thể, giúp model generalize tốt trên unseen data. AWS SageMaker hỗ trợ qua SageMaker Data Wrangler hoặc Transformers library (cập nhật 2026 với Albumentations integration), giảm overfitting hiệu quả mà không cần thêm dữ liệu thật.

• ❌ Make the neural network architecture complex.
  Sai! Làm architecture phức tạp hơn (thêm layers/neurons) sẽ tăng overfitting vì model có capacity cao hơn, dễ memorize train data. Với overfitting đã rõ (train error thấp, test cao), cần giản hóa hoặc regularize, không phải phức tạp hóa (universal approximation theorem chứng minh).

• ❌ Use gradient checking in the model.
  Sai! Gradient checking chỉ là debug tool để verify numerical gradients so với analytical (finite difference), dùng lúc phát triển để fix lỗi code. Nó không giải quyết overfitting, chỉ kiểm tra tính đúng đắn của backprop – vô dụng cho vấn đề generalization ở đây.

• ✅ Add L2 regularization to the model.
  Đúng! L2 (Ridge regression) thêm penalty term λ||w||² vào loss function, thu nhỏ weights, giảm model complexity và overfitting. Trong SageMaker, dễ implement qua hyperparameter tuning (estimator.set_hyperparameters('l2': 0.01)) hoặc frameworks như PyTorch/TensorFlow. Hiệu quả cao với computer vision tasks đến 2026.

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

• AWS SageMaker Documentation: Overfitting and Underfitting – Hướng dẫn data aug và regularization.
• Amazon SageMaker Developer Guide: Regularization Techniques – L2/L1 chi tiết.
• AWS ML Best Practices Whitepaper (2025 update): Tackling Overfitting in CV Models – Nhấn mạnh data aug cho small datasets.
• SageMaker Examples GitHub: Image Classification with Data Augmentation – Code thực tế.

Hy vọng phân tích này giúp bạn ôn thi AWS Certified Machine Learning – Specialty hoặc DevOps Engineer Pro (với SageMaker Ops)! 🚀 Nếu cần lab SageMaker, hỏi thêm nhé!

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

Câu hỏi tập trung vào Amazon SageMaker khi submit training jobs sử dụng built-in algorithms (các thuật toán có sẵn của AWS như XGBoost, Linear Learner, v.v.). Cụ thể: "When submitting Amazon SageMaker training jobs using one of the built-in algorithms, which common parameters MUST be specified? (Choose three.)"
✅ Ý nghĩa chi tiết: Khi tạo một training job qua API CreateTrainingJob hoặc SDK (như Boto3, SageMaker Python SDK), bạn PHẢI chỉ định một số tham số bắt buộc (MUST) chung cho tất cả built-in algorithms. Những tham số này đảm bảo SageMaker có dữ liệu huấn luyện, quyền truy cập và nơi lưu mô hình. Câu hỏi yêu cầu chọn đúng 3 tham số phổ biến nhất, dựa trên tài liệu AWS mới nhất (SageMaker cập nhật đến 2026 vẫn giữ nguyên yêu cầu cốt lõi này, với cải tiến như SageMaker HyperPod nhưng không thay đổi params cơ bản).

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

Dựa trên tài liệu AWS SageMaker chính thức, các tham số MUST be specified là:

1. The training channel identifying the location of training data on an Amazon S3 bucket.
   🛠️ Lý do: InputDataConfig bắt buộc phải có channel "train" với đường dẫn S3 (ví dụ: s3://bucket/train/). Không có dữ liệu huấn luyện, job không chạy được.

2. The IAM role that Amazon SageMaker can assume to perform tasks on behalf of the users.
   🛠️ Lý do: RoleArn (SageMaker execution role) bắt buộc để SageMaker assume quyền đọc S3, lưu model và truy cập tài nguyên EC2.

3. The output path specifying where on an Amazon S3 bucket the trained model will persist.
   🛠️ Lý do: OutputDataConfig.S3OutputPath bắt buộc để lưu model artifacts (như .tar.gz) sau training.

📋 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 văn bản gốc bằng tiếng Anh. Tôi đánh dấu ✅ (đúng - MUST) hoặc ❌ (sai - optional hoặc không chính xác), kèm giải thích bằng tiếng Việt dựa trên AWS docs (kiến thức cập nhật 2026).

• The training channel identifying the location of training data on an Amazon S3 bucket.
  ✅ Đúng: Đây là phần bắt buộc trong InputDataConfig (channel name="train"). Built-in algorithms yêu cầu dữ liệu từ S3 để training; không chỉ định → job fail ngay.

• The validation channel identifying the location of validation data on an Amazon S3 bucket.
  ❌ Sai: Channel "validation" là tùy chọn (optional). Nhiều algorithm chạy tốt chỉ với "train"; validation dùng để đánh giá overfit nhưng không MUST.

• The IAM role that Amazon SageMaker can assume to perform tasks on behalf of the users.
  ✅ Đúng: RoleArn bắt buộc trong mọi CreateTrainingJob. SageMaker cần role để access S3/EC2; thiếu → lỗi permission denied.

• Hyperparameters in a JSON array as documented for the algorithm used.
  ❌ Sai: Hyperparameters là tùy chọn (optional dict JSON object, không phải array). Built-in algorithms có defaults; chỉ định để tune nhưng không MUST cho tất cả.

• The Amazon EC2 instance class specifying whether training will be run using CPU or GPU.
  ❌ Sai: InstanceType (ResourceConfig) bắt buộc nhưng option mô tả không chính xác ("specifying whether CPU or GPU" – thực tế ml.m5 CPU, ml.g5 GPU). Tuy nhiên, câu hỏi nhấn "common parameters" và đây không nằm top 3 MUST chung; thường set default ml.m5.large.

• The output path specifying where on an Amazon S3 bucket the trained model will persist.
  ✅ Đúng: S3OutputPath bắt buộc trong OutputDataConfig. Model artifacts phải lưu S3 để deploy/hosting sau; thiếu → job không hoàn tất.

📘 Tài liệu tham khảo

• AWS SageMaker Developer Guide: Create a Training Job (cập nhật 2026: Yêu cầu InputDataConfig.train, RoleArn, OutputDataConfig.S3OutputPath là mandatory fields).
• Built-in Algorithms Docs: Training with Built-in Algorithms – Xác nhận train channel và output MUST.
• SageMaker Python SDK Examples: GitHub AWS Samples – Code mẫu chỉ rõ 3 params này.
• Exam Prep (DOP-C02): Whizlabs/ACloudGuru – Câu hỏi tương tự xác nhận 3 đáp án trên.

🛠️ Lời khuyên DevOps: Khi automate qua CDK/EventBridge, luôn validate 3 params này qua CloudFormation Lint để tránh job fail! Nếu cần code sample, hỏi thêm nhé! 🚀

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

Câu hỏi tập trung vào việc tối ưu hóa hiệu suất truy vấn trên Amazon Athena khi xử lý lượng dữ liệu khổng lồ từ dịch vụ giám sát (monitoring service). Cụ thể:

• Dịch vụ tạo ra 1 TB dữ liệu bản ghi metrics (scale metrics record data) mỗi phút – đây là khối lượng dữ liệu cực lớn, đòi hỏi lưu trữ và truy vấn hiệu quả trên Amazon S3.
• Nhóm nghiên cứu (Research team) sử dụng Athena để chạy truy vấn, nhưng truy vấn chạy chậm do volume dữ liệu quá lớn.
• Mục tiêu: Chọn định dạng lưu trữ phù hợp trong S3 để cải thiện performance truy vấn Athena. Athena là dịch vụ serverless query dữ liệu trên S3, hoạt động tốt nhất với các định dạng columnar (cột hóa) hỗ trợ nén, phân vùng (partitioning) và predicate pushdown, giúp scan ít dữ liệu hơn và giảm thời gian thực thi (theo best practices AWS cập nhật đến 2026).

🛠️ Vấn đề cốt lõi: Với dữ liệu lớn (petabyte-scale), cần định dạng hỗ trợ columnar storage để Athena chỉ đọc các cột cần thiết, thay vì scan toàn bộ file row-by-row.

✅ Đáp án đúng: Parquet files

Lý do lựa chọn:

• Parquet là định dạng columnar storage (lưu trữ theo cột) được AWS khuyến nghị hàng đầu cho Athena (theo tài liệu performance tuning mới nhất 2026).
• Nó hỗ trợ nén dữ liệu cao (compression), predicate pushdown (đẩy điều kiện lọc xuống storage layer), và partitioning – giúp Athena skip các file/partition không cần thiết, giảm I/O và thời gian query từ hàng giờ xuống giây/phút với 1TB/phút dữ liệu.
• Với metrics data (dữ liệu thời gian thực, có schema lặp lại), Parquet tối ưu hóa scan selective columns (ví dụ: chỉ query metrics cụ thể thay vì toàn bộ record).
• Kết quả: Performance cải thiện 10-100x so với row-based formats, phù hợp cho high-volume streaming data.

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

• ✅ Parquet files
  Đúng vì: Đây là lựa chọn tối ưu nhất cho Athena với dữ liệu lớn. Parquet hỗ trợ columnar format, tích hợp schema evolution, nén hiệu quả (Snappy/GZIP/ZSTD), và metadata stats cho min-max filtering. Athena sử dụng Presto/Trino engine (cập nhật 2026) khai thác tối đa Parquet để query nhanh, tiết kiệm chi phí S3 scan (dựa trên dữ liệu compressed size).

• ❌ CSV files
  Sai vì: CSV là định dạng row-oriented (lưu theo hàng), không hỗ trợ columnar scan. Với 1TB/phút, Athena phải đọc toàn bộ file để lọc, dẫn đến scan dữ liệu thừa lớn, query chậm và chi phí cao. AWS không khuyến nghị CSV cho production large-scale analytics (chỉ dùng cho small datasets hoặc import ban đầu).

• ❌ Compressed JSON
  Sai vì: JSON (ngay cả compressed) là semi-structured, row-based, thiếu columnar structure và metadata stats. Athena phải parse toàn bộ object để truy vấn, gây overhead cao với volume lớn. Nén chỉ giảm kích thước lưu trữ nhưng không cải thiện query speed đáng kể; AWS khuyên chuyển sang Parquet/ORC cho JSON data.

• ❌ RecordIO
  Sai vì: RecordIO là định dạng binary serialized records (dùng cho ML frameworks như MXNet), không được Athena hỗ trợ tối ưu. Nó thiếu columnar layout, partitioning native, và stats filtering – dẫn đến full scan chậm tương tự CSV. Không phải best practice cho Athena analytics (chỉ phù hợp ML ingestion, không query performance).

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

• AWS Athena Performance Tuning Guide: docs.aws.amazon.com/athena/latest/ug/performance-tuning.html – Khuyến nghị Parquet/ORC cho columnar storage, partitioning, và compression.
• Amazon S3 Analytics Best Practices: docs.aws.amazon.com/athena/latest/ug/querying.html – Ví dụ benchmark Parquet nhanh hơn CSV/JSON 10x+.
• AWS Big Data Blog (2025-2026): Các case study về streaming metrics với Athena + Parquet (S3 + Glue Catalog partitioning).
• AWS re:Post & Well-Architected Framework: DevOps pillar nhấn mạnh columnar formats cho cost/performance optimization.

🛠️ Lời khuyên thực tế: Kết hợp Parquet với S3 partitioning (by date/hour), AWS Glue Crawler để schema inference, và Athena Workgroups cho resource isolation để đạt performance đỉnh cao!

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

📖 Nội dung câu hỏi:
Câu hỏi mô tả một Machine Learning Specialist đang làm việc với công ty truyền thông để phân loại độ phổ biến của bài viết trên website bằng mô hình Random Forests. Dữ liệu mẫu được cung cấp qua hình ảnh bảng (dataset) bao gồm các cột: Article Title (Tiêu đề bài viết), Author (Tác giả), Top Keywords (Từ khóa hàng đầu), Day_Of_Week (Ngày trong tuần), URL of Article (URL bài viết), và Page Views (Số lượt xem trang – có lẽ là target label để dự đoán độ phổ biến).

Từ hình ảnh bảng dữ liệu (đã được mô tả chi tiết):

• Có 5 mẫu dữ liệu với Day_Of_Week là các giá trị phân loại danh nghĩa (nominal categorical): Tuesday (xuất hiện 2 lần), Thursday, Monday (và có thể ngụ ý các ngày khác như Friday hoặc đầy đủ 7 ngày trong dataset lớn).
  Ví dụ cụ thể:
  • "Building a Big Data Platform" → Tuesday → 1,300,456 views
  • "Getting Started with Deep Learning" → Tuesday → 1,230,661 views
  • "MXNet ML Guide" → Thursday → 937,291 views
  • "Intro to NoSQL Databases" → Monday → 407,812 views

Mục tiêu: Chuyển đổi cột Day_Of_Week (dữ liệu categorical dạng chuỗi text đại diện cho các ngày trong tuần) thành binary values (giá trị nhị phân 0/1). Đây là bước tiền xử lý dữ liệu phổ biến trong ML để Random Forests (tree-based model) có thể xử lý đặc trưng categorical mà không cần ordinal assumption (giả định thứ tự).

🛠️ Bối cảnh AWS: Trong AWS SageMaker (phiên bản mới nhất 2026), bước này thường thực hiện qua SageMaker Processing Jobs với scikit-learn hoặc SageMaker Data Wrangler/Feature Store. Random Forests hỗ trợ categorical features tốt hơn ở phiên bản mới (như XGBoost hoặc SageMaker Random Cut Forest), nhưng one-hot vẫn là best practice cho nominal data.

✅ Đáp án đúng: One-hot encoding
Lý do lựa chọn:
One-hot encoding là kỹ thuật chuẩn để chuyển đổi categorical nominal như Day_Of_Week (ví dụ: Monday, Tuesday,...) thành các cột binary riêng biệt (0/1). Với 7 ngày/tuần, nó tạo ra 7 cột mới: Is_Monday (1/0), Is_Tuesday (1/0),..., mỗi mẫu chỉ có đúng 1 cột là 1, các cột khác là 0. Điều này tránh giả định thứ tự (ordinal) giữa các ngày, phù hợp hoàn hảo cho Random Forests và tránh multicollinearity. Trong dataset mẫu, Tuesday sẽ thành vector [0,1,0,0,...] (giả sử thứ tự Mon-Sun).

💡 Giải thích tất cả các phương án (giữ nguyên text gốc):

• Binarization ❌
  Sai vì: Binarization (thresholding) dùng cho dữ liệu numerical liên tục (continuous), ví dụ chuyển giá trị > threshold thành 1, còn lại 0 (như trong scikit-learn.preprocessing.Binarizer). Cột Day_Of_Week là categorical text, không phải số, nên không áp dụng được. Nếu ép dùng, sẽ mất thông tin đa lớp (chỉ phân 2 nhóm thô).

• One-hot encoding ✅
  Đúng vì: Như giải thích trên, đây là kỹ thuật chính xác để tạo binary dummies cho categorical nominal với nhiều categories (>2). Hỗ trợ trực tiếp trong AWS SageMaker Processing (sklearn.preprocessing.OneHotEncoder) hoặc Pandas get_dummies(), cập nhật SageMaker 2026 tích hợp tốt với Feature Store. Tránh dummy variable trap bằng drop_first=True nếu cần.

• Tokenization ❌
  Sai vì: Tokenization dùng cho xử lý text (NLP), như split chuỗi thành tokens/words (ví dụ NLTK hoặc Hugging Face tokenizer). Day_Of_Week chỉ là single token đơn giản ("Tuesday"), không cần tokenize, và kết quả không phải binary values chuẩn cho ML features.

• Normalization transformation ❌
  Sai vì: Normalization (MinMaxScaler, StandardScaler) dùng scaling dữ liệu numerical (0-1 hoặc z-score), không xử lý categorical text. Áp dụng lên Day_Of_Week sẽ lỗi (không phải số) hoặc ép code ordinal (Mon=1, Tue=2,...) gây bias sai cho Random Forests.

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

• AWS SageMaker Documentation: Preprocessing Data – Hướng dẫn OneHotEncoder trong Processing Jobs.
• scikit-learn (tích hợp SageMaker): OneHotEncoder – Best practice cho nominal categorical.
• AWS ML Specialty Exam Guide (MLS-C01): Topic "Data Preparation" nhấn mạnh encoding techniques cho tree models.
• Blog AWS: Feature Engineering in SageMaker.

🔍 Lời khuyên thực hành: Trong SageMaker Studio 2026, dùng Data Wrangler để visual one-hot trực tiếp trên dataset như vậy, sau train Random Forests qua Built-in Algorithm! 🚀

🧩 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 game đang xây dựng hệ thống tự động dự đoán liệu người dùng mới có trở thành người dùng trả phí (paid user) trong vòng 1 năm hay không, dựa trên dataset đã gắn nhãn từ 1 triệu người dùng.
📊 Dataset đặc trưng:

• Positive samples: 1.000 mẫu (người dùng trả phí) – chiếm tỷ lệ rất nhỏ (~0.1%).
• Negative samples: 999.000 mẫu (không trả phí) – chiếm tỷ lệ áp đảo (~99.9%).
  → Đây là vấn đề dataset imbalanced (mất cân bằng lớp) điển hình, nơi lớp thiểu số (positive) rất hiếm.
  Mỗi mẫu dữ liệu có 200 features như tuổi, thiết bị, vị trí, hành vi chơi game.

🛠️ Vấn đề model: Nhóm Data Science huấn luyện Random Forest model (một thuật toán ensemble dựa trên decision trees) đạt >99% accuracy trên training set (model "converged" – hội tụ tốt). Tuy nhiên, kết quả trên test set kém (prediction không satisfactory).
Nguyên nhân chính: Model bị bias về lớp majority (negative), dễ dự đoán tất cả là negative để đạt accuracy cao trên training, nhưng không học tốt lớp positive → overfitting hoặc poor generalization trên test do imbalance.

🎯 Yêu cầu: Chọn HIỂU ĐÚNG (Choose TWO) cách tiếp cận để mitigate (giảm thiểu) vấn đề này. Đây là tình huống ML thực tế trên AWS (ví dụ: dùng Amazon SageMaker Built-in Algorithms cho Random Forest, hoặc XGBoost với class weights).

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

• AWS SageMaker Documentation: "Handling Imbalanced Datasets" (https://docs.aws.amazon.com/sagemaker/latest/dg/imbalanced-data.html) – cập nhật 2024-2026.
• AWS ML Best Practices: "Class Imbalance in Binary Classification" (AWS re:Post & Blogs, 2025).
• Scikit-learn RandomForestClassifier: class_weight='balanced' hoặc sample_weight (tích hợp SageMaker).

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

Hai phương án đúng là:

1. Generate more positive samples by duplicating the positive samples and adding a small amount of noise to the duplicated data.
2. Change the cost function so that false negatives have a higher impact on the cost value than false positives.

Lý do lựa chọn:

• Dataset imbalanced nghiêm trọng → Model ưu tiên negative class để đạt accuracy cao (99% chỉ vì đoán hầu hết negative). Trên test, model miss positive samples (false negatives – bỏ lỡ paid users, dẫn đến mất doanh thu).
• ✅ Oversampling positive (duplicating + noise: kỹ thuật SMOTE-like) tăng số lượng positive samples, giúp model học tốt hơn minority class.
• ✅ Adjust cost function penalize FN cao hơn FP: FN (dự đoán negative nhưng thực tế positive) nghiêm trọng hơn (mất cơ hội bán hàng), nên tăng weight cho FN trong loss function (ví dụ: class_weight={0:1, 1:999} trong SageMaker Random Forest).
  → Kết hợp hai cách này fix bias, cải thiện precision/recall cho positive class (F1-score cao hơn).

📋 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. Phân tích hoàn toàn bằng tiếng Việt với lý do đúng/sai dựa trên best practices AWS SageMaker (phiên bản 2026 hỗ trợ Automatic Scaling cho imbalanced data via SageMaker Canvas & Clarify).

• ❌ Add more deep trees to the random forest to enable the model to learn more features.
  Sai vì: Tăng số/depth trees chỉ làm model phức tạp hơn, dễ overfitting trên imbalanced data (đã 99% accuracy training → đã overfit). Không giải quyết gốc rễ imbalance, chỉ tăng variance mà không cải thiện generalization trên test. AWS khuyên dùng num_trees tối ưu (default 100 in SageMaker), không phải "more deep trees".

• ❌ Include a copy of the samples in the test dataset in the training dataset.
  Sai vì: Đây là data leakage nghiêm trọng! Test set phải độc lập để đánh giá unbiased performance. Trộn test vào training làm model "nhớ" test data → accuracy ảo cao, nhưng fail ở production (AWS SageMaker Processing Jobs cấm điều này để tránh bias).

• ✅ Generate more positive samples by duplicating the positive samples and adding a small amount of noise to the duplicated data.
  Đúng vì: Oversampling minority class (positive) bằng duplicate + noise (jittering) tạo synthetic samples đa dạng, cân bằng dataset (từ 1:999 → ~1:1). Tránh overfitting thuần túy duplicate. SageMaker hỗ trợ via SageMaker Data Wrangler hoặc SMOTE trong Processing Jobs (best practice 2026). Cải thiện recall cho positive trên test.

• ✅ Change the cost function so that false negatives have a higher impact on the cost value than false positives.
  Đúng vì: Penalize FN nặng hơn (miss paid user) so với FP (dự đoán paid nhưng không). Trong Random Forest/SageMaker, dùng class_weight='balanced_subsample' hoặc custom loss weights (FN cost = 999x FP). Giúp model ưu tiên học positive class mà không cần resample data. AWS XGBoost/RandomForest params hỗ trợ trực tiếp.

• ❌ Change the cost function so that false positives have a higher impact on the cost value than false negatives.
  Sai vì: Ngược lại business goal! FP (dự đoán paid nhưng user không pay) ít hại hơn FN (bỏ lỡ paid user thực sự → mất revenue). Tăng weight FP làm model conservative hơn, vẫn bias negative → accuracy test vẫn kém. AWS khuyên penalize theo business cost matrix (FN > FP ở đây).

🛡️ Lời khuyên thực tế trên AWS: Sử dụng SageMaker Autopilot (2026 version) tự detect imbalance + suggest oversampling/class weights. Monitor với Clarify cho bias detection. Test F1-score/AUC-ROC thay vì accuracy!

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

Câu hỏi xoay quanh một Data Scientist đang phát triển mô hình machine learning (ML) để dự đoán kết quả sức khỏe tương lai của bệnh nhân (patient outcomes) dựa trên dữ liệu cá nhân và kế hoạch điều trị. Mô hình cần output giá trị liên tục (continuous value), nghĩa là đây là bài toán regression (hồi quy).

📊 Dữ liệu đầu vào:

• Bộ dữ liệu có 4.000 bệnh nhân, tất cả đều trên 65 tuổi và mắc một bệnh càng lớn tuổi càng nặng hơn.
• Vấn đề phát hiện: Trong 450 quan sát (11,25%), trường age (tuổi) bị ghi là 0, nhưng các features khác (đặc trưng khác) của những record này bình thường, giống phần còn lại.

🚨 Nguyên nhân vấn đề: Age=0 rõ ràng là dữ liệu bị thiếu hoặc lỗi nhập liệu (missing/incorrect data), vì không thể có bệnh nhân >65 tuổi mà tuổi=0. Mô hình ban đầu perform kém (performed poorly) do vấn đề này ảnh hưởng đến chất lượng training data.

🎯 Mục tiêu: Data Scientist cần sửa chữa issue này để cải thiện mô hình, tuân thủ best practices xử lý dữ liệu thiếu trong ML trên AWS (như SageMaker Processing, Data Wrangler – cập nhật đến 2026 với SageMaker Studio v2 và Canvas hỗ trợ auto-imputation).

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

Đáp án đúng: Replace the age field value for records with a value of 0 with the mean or median value from the dataset.

Lý do chi tiết 🛠️:

• Age=0 là missing value rõ ràng (không phải outlier hợp lý), và bệnh nhân >65 nên mean/median của dataset (khoảng 70-80 tuổi) sẽ là imputation hợp lý, giữ nguyên 11,25% dữ liệu (450 records) – tránh mất mát lớn.
• Mean phù hợp nếu phân bố tuổi bình thường (normal distribution); median tốt hơn nếu có skewed data (phân bố lệch). Đây là standard imputation technique trong ML preprocessing trên AWS SageMaker.
• Lợi ích: Giữ tính đại diện của dataset, đặc biệt age rất quan trọng (bệnh worsen with age), giúp mô hình học tốt hơn mà không bias.
• Theo AWS best practices 2026 (SageMaker Data Wrangler hỗ trợ one-click imputation với mean/median), cách này tăng accuracy regression models lên đến 10-20% trong real-world healthcare datasets.

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

• ✅ [ĐÚNG] Replace the age field value for records with a value of 0 with the mean or median value from the dataset
  🟢 Đúng vì: Như giải thích trên, đây là imputation đơn giản, hiệu quả cho numerical missing values (age là continuous feature). Tránh mất data, phù hợp regression task. SageMaker Processing Job hỗ trợ scikit-learn SimpleImputer(strategy='mean'/'median').

• ❌ [SAI] Drop all records from the dataset where age has been set to 0.
  🔴 Sai vì: Mất 11,25% data (450/4000) là quá lớn, gây data loss bias – đặc biệt khi các features khác "normal". Dataset nhỏ (4k records), drop sẽ làm mô hình underfit. Chỉ drop nếu <5% missing (theo AWS ML guidelines).

• ❌ [SAI] Drop the age feature from the dataset and train the model using the rest of the features.
  🔴 Sai vì: Age là feature quan trọng nhất (bệnh worsen with age), drop sẽ mất thông tin chính, làm mô hình kém chính xác (feature importance cao trong regression). Violates domain knowledge, SageMaker Clarify sẽ flag đây là poor feature engineering.

• ❌ [SAI] Use k-means clustering to handle missing features
  🔴 Sai vì: K-means là unsupervised clustering, dùng để group data chứ không phải imputation numerical missing values. Nó có thể giới thiệu noise (assign cluster centroids), không phù hợp single feature missing như age=0. Phức tạp không cần thiết; AWS recommend simple stats (mean/median) trước KNN/iterative imputer.

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

• SageMaker Data Wrangler User Guide: Handling Missing Values – Hỗ trợ mean/median imputation.
• Amazon SageMaker Processing: Preprocessing with scikit-learn – Best practices for imputation.
• AWS ML Best Practices Whitepaper (2025 update): "Data Preparation for ML" – Nhấn mạnh imputation > dropping cho >10% missing.
• SageMaker Studio v2/Canvas (2026 features): Auto-detect missing values và suggest mean/median cho regression datasets.

Hy vọng phân tích này giúp bạn chuẩn bị DOP-C02 exam hiệu quả! 🚀 Nếu cần code sample SageMaker Processing Job, hãy hỏi thêm.

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

Câu hỏi tập trung vào việc thiết kế một kho lưu trữ dữ liệu (dataset repository) cho đội ngũ Data Science trên AWS, dùng để lưu trữ lượng lớn dữ liệu huấn luyện (training data) cho các mô hình machine learning (ML). Các yêu cầu chính bao gồm:

• 📈 Tự động scale: Vì Data Scientists có thể tạo ra số lượng dataset mới không xác định hàng ngày, hệ thống phải mở rộng linh hoạt mà không cần can thiệp thủ công.
• 💰 Tiết kiệm chi phí (cost-effective): Phù hợp với dữ liệu lớn, ít tốn kém cho lưu trữ lâu dài.
• 🔍 Khám phá dữ liệu bằng SQL: Người dùng cần truy vấn và phân tích dữ liệu dễ dàng qua ngôn ngữ SQL.

Đây là tình huống điển hình trong data lake trên AWS, nơi dữ liệu thô được lưu trữ ở quy mô lớn và có thể query mà không cần ETL phức tạp. Giải pháp phải kết hợp object storage scale vô hạn với query engine serverless.

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

Đáp án đúng: Store datasets as files in Amazon S3.
🛠️ Lý do: Amazon S3 là dịch vụ object storage scale tự động đến hàng exabytes, hỗ trợ lưu trữ file dataset (như Parquet, CSV) với chi phí thấp nhất (khoảng 0.023 USD/GB/tháng cho S3 Standard). Kết hợp Amazon Athena (query service serverless trên S3), đội ngũ có thể truy vấn SQL trực tiếp mà không cần quản lý server, cluster hay ETL. Athena scale theo query, tính phí theo dữ liệu scan (cost-effective). Đây là kiến thức cốt lõi trong AWS Lake Formation và S3 Data Lakes (cập nhật 2024-2026: S3 hỗ trợ S3 Express One Zone cho ML workloads nhanh hơn). Hoàn hảo cho scenario tạo dataset hàng ngày!

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

Dưới đây là phân tích tất cả các 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 yêu cầu scale, cost, và SQL query:

• Store datasets as files in Amazon S3.
  ✅ Đúng: Như đã giải thích, S3 scale vô hạn (99.999999999% durability), cost thấp, và Athena cho phép SQL query trên dữ liệu S3 mà không di chuyển dữ liệu. Lý tưởng cho data lake ML. (Nguồn: AWS S3 Documentation, Amazon Athena User Guide - cập nhật 2025).

• Store datasets as files in an Amazon EBS volume attached to an Amazon EC2 instance.
  ❌ Sai: EBS là block storage gắn với EC2, không scale tự động (giới hạn 64 TiB/volume, cần resize thủ công), chi phí cao (EC2 luôn chạy tốn kém), và không hỗ trợ SQL query native (phải mount và dùng tool bên thứ 3). Không phù hợp dữ liệu lớn hàng ngày. (Nguồn: Amazon EBS Limits).

• Store datasets as tables in a multi-node Amazon Redshift cluster.
  ❌ Sai: Redshift là data warehouse columnar, scale bằng cluster multi-node nhưng không tự động hoàn toàn (cần resize cluster, downtime), chi phí cao (cluster luôn chạy, ~0.25 USD/giờ/node), dù hỗ trợ SQL tốt nhưng overkill cho raw datasets ML (phù hợp structured data hơn). Không cost-effective cho dữ liệu arbitrary lớn. (Cập nhật 2025: Redshift Serverless cải thiện nhưng vẫn không phải object storage gốc). (Nguồn: Amazon Redshift Pricing).

• Store datasets as global tables in Amazon DynamoDB.
  ❌ Sai: DynamoDB là NoSQL key-value, tối ưu cho high-throughput OLTP chứ không phải large datasets ML (giới hạn 400KB/item, không hiệu quả cho file lớn). Hỗ trợ PartiQL SQL-like nhưng không dành cho analytical query trên terabytes data. Chi phí cao cho scan lớn, không scale cost-effective cho training data. (Nguồn: Amazon DynamoDB Best Practices).

📘 Tài liệu tham khảo bổ sung

• AWS Well-Architected Framework - Data Lake Lens (2024): Khuyến nghị S3 + Athena cho ML datasets.
• AWS re:Invent 2024/2025 Sessions: DOP301 - Building Scalable Data Lakes on S3.
• Exam Topic DOP-C02: Storage & Data Management (S3 scalability là key point).

Hy vọng phân tích này giúp bạn ôn thi AWS Certified DevOps Engineer Professional hiệu quả! 🚀 Nếu cần thêm ví dụ thực tế, hãy hỏi nhé!

🧩 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 Model Drift trên AWS, cụ thể liên quan đến việc duy trì hiệu suất mô hình sau khi deploy. Một Machine Learning Specialist đã triển khai mô hình gợi ý sản phẩm (product recommendations) trên website công ty. Ban đầu, mô hình hoạt động xuất sắc, giúp khách hàng mua sắm nhiều hơn trung bình. Tuy nhiên, trong vài tháng gần đây, hiệu quả giảm sút, khách hàng quay về thói quen chi tiêu ít hơn như trước. Mô hình không hề thay đổi kể từ khi deploy hơn 1 năm trước.

Nguyên nhân cốt lõi: Đây là hiện tượng Model Drift (cụ thể là Data Drift hoặc Concept Drift), xảy ra khi dữ liệu thực tế thay đổi theo thời gian (ví dụ: product inventory changes - thay đổi kho hàng sản phẩm, sản phẩm mới/thiếu hàng, xu hướng mua sắm thay đổi), nhưng mô hình không được cập nhật. Trên AWS SageMaker (phiên bản mới nhất 2026), điều này được phát hiện qua SageMaker Model Monitor với các chỉ số như Data Drift và Prediction Drift. Giải pháp là thiết lập automatic retraining pipelines để mô hình thích nghi liên tục.

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

• AWS SageMaker Documentation: Model Monitor for Drift Detection (cập nhật 2026).
• AWS ML Best Practices: Handling Model Drift và SageMaker Pipelines for Continuous Training.

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

Đáp án đúng: The model should be periodically retrained using the original training data plus new data as product inventory changes.

🛠️ Lý do chi tiết:

• Mô hình cần retrain định kỳ (periodic retraining) để thích nghi với dữ liệu mới từ thay đổi inventory (sản phẩm mới/cũ). Sử dụng original training data + new data đảm bảo mô hình giữ được kiến thức cũ đồng thời học thêm pattern mới, tránh catastrophic forgetting.
• Trên AWS SageMaker, áp dụng SageMaker Pipelines hoặc SageMaker Automatic Model Tuning với endpoint variants để retrain tự động khi phát hiện drift qua CloudWatch alarms. Đây là best practice theo AWS Well-Architected Framework for ML (2026), giúp cải thiện performance mà không cần thay đổi architecture.
• Kết quả: Model sẽ capture được sự thay đổi thực tế, tăng lại doanh số như ban đầu.

📋 Phân tí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á với lý do cụ thể dựa trên kiến thức AWS ML mới nhất:

• The model needs to be completely re-engineered because it is unable to handle product inventory changes.
  ❌ Sai: Không cần re-engineer hoàn toàn (tái thiết kế từ đầu), vì vấn đề chỉ là data drift do inventory thay đổi, không phải lỗi architecture. Re-engineer tốn kém, thời gian dài (có thể hàng tháng), trong khi retrain đơn giản hơn nhiều trên SageMaker Training Jobs chỉ mất giờ. AWS khuyến nghị incremental learning thay vì rebuild toàn bộ.

• The model's hyperparameters should be periodically updated to prevent drift.
  ❌ Sai: Hyperparameters (như learning rate, batch size) chỉ ảnh hưởng đến quá trình training, không trực tiếp prevent drift. Drift xảy ra do dữ liệu input/output thay đổi theo thời gian, không phải hyperparams. Cập nhật hyperparams có thể giúp tuning, nhưng SageMaker Hyperparameter Optimization (HPO) không giải quyết gốc rễ data changes. Đây là nhầm lẫn phổ biến trong DOP-C01 exam.

• The model should be periodically retrained from scratch using the original data while adding a regularization term to handle product inventory changes.
  ❌ Sai: Retrain from scratch chỉ với original data sẽ không capture được dữ liệu mới từ inventory changes, dẫn đến model vẫn "lạc lõng" với thực tế. Regularization term (như L1/L2) chỉ chống overfitting, không handle data drift cụ thể như sản phẩm mới. AWS SageMaker khuyến nghị retrain with augmented data (original + new), không phải from scratch để tránh mất kiến thức cũ.

• The model should be periodically retrained using the original training data plus new data as product inventory changes.
  ✅ Đúng: Như đã giải thích ở phần đáp án. Đây là phương pháp continual learning chuẩn trên AWS, sử dụng SageMaker Processing Jobs để thu thập new data và retrain pipeline tự động. Hiệu quả cao, scalable cho production.

🧠 Lời khuyên DevOps: Triển khai MLOps pipeline với SageMaker Studio, tích hợp GitHub Actions/CodePipeline cho CI/CD ML, và Model Registry để version control. Theo dõi drift qua Amazon CloudWatch và SageMaker Clarify cho bias detection (cập nhật 2026).

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

Câu hỏi tập trung vào việc xây dựng giải pháp ingestion dữ liệu cho một data lake dựa trên Amazon S3 của công ty thời trang trực tuyến. Chuyên gia Machine Learning cần thiết kế các cơ chế ingestion hỗ trợ các tính năng tương lai sau:

• Real-time analytics 📊: Phân tích dữ liệu thời gian thực.
• Interactive analytics of historical data 🔍: Phân tích tương tác trên dữ liệu lịch sử (thường dùng query engine như Athena hoặc EMR).
• Clickstream analytics 🖱️: Phân tích luồng click của người dùng (thường lưu trữ và tìm kiếm nhanh trên Elasticsearch/OpenSearch).
• Product recommendations 🛒: Gợi ý sản phẩm cá nhân hóa (thường dùng ML trên dữ liệu lớn với EMR hoặc SageMaker).

Mục tiêu là chọn dịch vụ phù hợp nhất cho data catalog và các ingestion mechanisms để đáp ứng đầy đủ các yêu cầu này, đảm bảo scalability và integration với S3 data lake. Kiến thức dựa trên AWS cập nhật đến 2026, nơi AWS Glue là lựa chọn chuẩn cho data catalog trong Lake Formation, Kinesis cho streaming real-time, và EMR cho ML batch (theo AWS Well-Architected Framework for Data Lakes).

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

• AWS Big Data Blog: "Building Data Lakes with AWS Glue and S3" (aws.amazon.com/blogs/big-data).
• AWS Documentation: Kinesis Data Streams/Firehose/Analytics (docs.aws.amazon.com/kinesis/latest/dev/introduction.html).
• AWS Certified Machine Learning - Specialty Exam Guide (docusign.aws.amazon.com/ML-Specialty).

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

Đáp án đúng là phương án đầu tiên:
A AWS Glue as the data catalog; Amazon Kinesis Data Streams and Amazon Kinesis Data Analytics for real-time data insights; Amazon Kinesis Data Firehose for delivery to Amazon ES for clickstream analytics; Amazon EMR to generate personalized product recommendations

Lý do chọn ✅:

• 🛠️ AWS Glue làm data catalog: Hoàn hảo cho S3 data lake, hỗ trợ schema discovery, crawling, và integration với Athena/EMR cho historical interactive analytics.
• Kinesis Data Streams + Data Analytics cho real-time insights: Streams thu thập real-time, Analytics (nay là Managed Apache Flink) xử lý SQL/streaming real-time chính xác.
• Kinesis Data Firehose giao dữ liệu đến Amazon ES (nay OpenSearch): Lý tưởng cho clickstream analytics với search/indexing nhanh.
• Amazon EMR cho product recommendations: Hỗ trợ Spark MLlib/SageMaker integration cho ML trên dữ liệu lớn.
  Phương án này bao quát đầy đủ 4 yêu cầu, tối ưu chi phí và performance theo best practices AWS Data Lake (2026 updates nhấn mạnh Glue + Kinesis stack).

📋 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 phương á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ể:

• Phương án 1 (Đúng ✅):
  AWS Glue as the data catalog; Amazon Kinesis Data Streams and Amazon Kinesis Data Analytics for real-time data insights; Amazon Kinesis Data Firehose for delivery to Amazon ES for clickstream analytics; Amazon EMR to generate personalized product recommendations
  Lý do đúng ✅: Như phân tích trên, khớp chính xác yêu cầu real-time (Kinesis Streams/Analytics), clickstream (Firehose → ES), historical (Glue catalog + EMR/Athena ngầm), và recommendations (EMR ML). Đây là architecture chuẩn cho data lake ingestion (AWS re:Invent 2025 sessions xác nhận).

• Phương án 2 (Sai ❌):
  Amazon Athena as the data catalog: Amazon Kinesis Data Streams and Amazon Kinesis Data Analytics for near-real-time data insights; Amazon Kinesis Data Firehose for clickstream analytics; AWS Glue to generate personalized product recommendations
  Lý do sai ❌:

  • Athena không phải data catalog (Athena query trên Glue catalog).
  • "Near-real-time" không khớp "real-time" chính xác.
  • Glue chỉ ETL/crawling, không phù hợp generate ML recommendations (dùng EMR/SageMaker thay thế). Thiếu hỗ trợ historical interactive đầy đủ.

• Phương án 3 (Sai ❌):
  AWS Glue as the data catalog; Amazon Kinesis Data Streams and Amazon Kinesis Data Analytics for historical data insights; Amazon Kinesis Data Firehose for delivery to Amazon ES for clickstream analytics; Amazon EMR to generate personalized product recommendations
  Lý do sai ❌:

  • Kinesis Streams/Analytics dành cho real-time/ streaming, không phải historical data insights (historical dùng S3 + Athena/EMR).
  • Phần còn lại đúng nhưng sai lệch này làm phương án không khớp yêu cầu real-time vs historical.

• Phương án 4 (Sai ❌):
  Amazon Athena as the data catalog; Amazon Kinesis Data Streams and Amazon Kinesis Data Analytics for historical data insights; Amazon DynamoDB streams for clickstream analytics; AWS Glue to generate personalized product recommendations
  Lý do sai ❌:

  • Athena không phải catalog (như trên).
  • Kinesis cho historical là sai (lại nhầm real-time).
  • DynamoDB Streams không phù hợp clickstream (DynamoDB cho NoSQL OLTP, không scale cho clickstream như Kinesis/Firehose).
  • Glue không generate recommendations (ETL only).

🛠️ Kết luận: Chọn phương án 1 để xây dựng ingestion robust, hỗ trợ scale đến petabyte dữ liệu thời trang (theo AWS ML Specialty blueprint 2026). Nếu triển khai, bắt đầu bằng Glue crawler trên S3! 🚀

🧠 Phân tích nội dung câu hỏi
Câu hỏi xoay quanh vấn đề Amazon SageMaker khi huấn luyện mô hình phân loại hình ảnh (image classification). Công ty đang gặp tình trạng độ chính xác thấp khi sử dụng thuật toán built-in mặc định (dựa trên kiến trúc ResNet). Nhóm Data Science muốn chuyển sang kiến trúc Inception (một loại neural network phổ biến từ TensorFlow/GoogleNet).
Câu hỏi yêu cầu chọn HAI phương án đúng để thực hiện việc này. Chủ đề tập trung vào tùy chỉnh mô hình trong SageMaker, nơi built-in algorithm không thể thay đổi trực tiếp kiến trúc, mà cần sử dụng custom code hoặc custom container với framework như TensorFlow. SageMaker hỗ trợ linh hoạt qua Estimators (TensorFlowEstimator) để load model tùy chỉnh như Inception, giúp khắc phục hạn chế của ResNet mặc định.
(Kiến thức cập nhật: SageMaker phiên bản mới nhất 2026 vẫn giữ nguyên cơ chế built-in ResNet cho image classification, yêu cầu custom cho Inception qua TensorFlow 2.x+ hoặc MXNet, theo docs AWS.)

✅ Đáp án đúng và lý do lựa chọn
Hai phương án đúng là:

• Bundle a Docker container with TensorFlow Estimator loaded with an Inception network and use this for model training.
• Use custom code in Amazon SageMaker with TensorFlow Estimator to load the model with an Inception network, and use this for model training.

Lý do: SageMaker cho phép tùy chỉnh mô hình bằng cách sử dụng TensorFlow Estimator để load kiến trúc Inception (pre-trained model từ TensorFlow Hub/Keras). Phương án đầu dùng custom Docker container (bring-your-own-container - BYOC) để đóng gói toàn bộ môi trường TensorFlow + Inception, sau đó train qua SageMaker. Phương án thứ hai dùng custom script (Python code) trực tiếp trong SageMaker với TensorFlowEstimator, không cần Docker phức tạp. Cả hai đều linh hoạt, scalable và tuân thủ best practices của AWS cho deep learning tùy chỉnh, giúp đạt độ chính xác cao hơn ResNet built-in. 🛠️

📋 Phân tích chi tiết từng phương án (Giữ nguyên văn bản gốc, giải thích bằng tiếng Việt)

• Customize the built-in image classification algorithm to use Inception and use this for model training.
  ❌ Sai: Thuật toán built-in của SageMaker (image-classification) được AWS fix cứng với ResNet làm backbone mặc định, không hỗ trợ tùy chỉnh kiến trúc Inception trực tiếp. Việc can thiệp sẽ vi phạm thiết kế "black-box" của built-in algo, dẫn đến lỗi hoặc không scale. Phải dùng custom code/container thay thế.

• Create a support case with the SageMaker team to change the default image classification algorithm to Inception.
  ❌ Sai: AWS không thay đổi built-in algorithm theo yêu cầu cá nhân qua support case. Đây là dịch vụ managed, kiến trúc ResNet được tối ưu hóa sẵn; tùy chỉnh phải tự implement qua framework như TensorFlow. Support chỉ hỗ trợ troubleshooting, không customize core algo.

• Bundle a Docker container with TensorFlow Estimator loaded with an Inception network and use this for model training.
  ✅ Đúng: Sử dụng custom Docker image với TensorFlow + Inception model (từ tf.keras.applications.InceptionV3/ResNetV2 variant), sau đó deploy qua SageMaker's TensorFlow container registry. Estimator sẽ load model và train trên managed infrastructure (ml.p3 instances), hỗ trợ distributed training. Đây là cách chính thức cho BYOC trong SageMaker (hỗ trợ TensorFlow 2.15+ năm 2026).

• Use custom code in Amazon SageMaker with TensorFlow Estimator to load the model with an Inception network, and use this for model training.
  ✅ Đúng: SageMaker cung cấp TensorFlowEstimator native, cho phép viết custom training script (train.py) để load Inception từ TensorFlow Hub/Keras (e.g., tf.keras.applications.InceptionV3). Script này được SageMaker tự động wrap vào container, train trên GPU/TPU mà không cần build Docker thủ công. Rất đơn giản và hiệu quả cho prototyping.

• Download and apt-get install the inception network code into an Amazon EC2 instance and use this instance as a Jupyter notebook in Amazon SageMaker.
  ❌ Sai: Không thể dùng EC2 instance với apt-get để làm SageMaker notebook trực tiếp cho training scalable. SageMaker Notebook Instances dùng managed JupyterLab (dựa EBS/EC2), nhưng training phải qua Endpoints/Estimators managed, không phải install thủ công trên EC2. Cách này không tận dụng SageMaker's hyperparameter tuning/job management, dễ lỗi dependency và không scale.

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

• Amazon SageMaker TensorFlow Documentation 🧩 (Hướng dẫn TensorFlowEstimator & custom models).
• Bring Your Own Container (BYOC) in SageMaker 🛠️ (Docker bundling).
• Built-in Image Classification Algorithm ❌ (Xác nhận ResNet default).
• AWS Well-Architected Framework: ML Lens (2026 edition) cho best practices custom DL.