Ngân hàng đề — AWS Certified Machine Learning Engineer - Associate

Tìm thấy 195 câu.

Câu 151 Data Preparation for Machine Learning (ML)

A research institute is planning to use Amazon SageMaker to train a machine learning model for object detection in satellite imagery. The training dataset, consisting of 8 TB of high-resolution images, is stored on an Amazon FSx for NetApp ONTAP system virtual machine (SVM) that is configured in the same VPC as the SageMaker environment. The ML engineer needs to ensure that the SageMaker training job can efficiently access the dataset during training.

Which of the following represents the best solution for the given use case?

  1. A

    Use AWS DataSync to continuously synchronize the FSx for NetApp ONTAP system with Amazon S3 and set up SageMaker to read the data from S3 during training
  2. B

    Mount the FSx for NetApp ONTAP file system directly as a volume to the SageMaker training instance
  3. C

    Export the training data from the FSx for NetApp ONTAP system to a local system and re-upload the data to SageMaker through the SageMaker Python SDK
  4. D

    Copy the training data from the FSx for NetApp ONTAP system to an Amazon S3 bucket and configure SageMaker to use the S3 bucket for training
Xem giải thích

Đáp án

B — Mount trực tiếp hệ thống tệp FSx for NetApp ONTAP làm volume cho instance huấn luyện SageMaker.

Vì sao đúng

Đề nêu ba yếu tố, và chúng cùng chỉ về một hướng: | Yếu tố | Hệ quả | |---|---| | 8 TB ảnh vệ tinh độ phân giải cao | sao chép đi đâu cũng rất tốn thời gian và tiền | | FSx đã ở CÙNG VPC với môi trường SageMaker | kết nối mạng đã sẵn sàng | | Cần truy cập hiệu quả trong lúc huấn luyện | mount trực tiếp là nhanh nhất |

Vì sao mount trực tiếp là lựa chọn đúng:

Sao chép sang S3:  8 TB × thời gian truyền + chi phí lưu trữ GẤP ĐÔI
                   + phải đồng bộ khi dữ liệu nguồn thay đổi

Mount trực tiếp:   dữ liệu ở nguyên chỗ
                   SageMaker đọc qua mạng nội bộ VPC
                   → không sao chép, không nhân bản

SageMaker training job nhận hệ thống tệp làm nguồn dữ liệu:

estimator.fit({'training': FileSystemInput(
    file_system_id='fs-0123456789abcdef',
    file_system_type='FSxLustre',
    directory_path='/anh-ve-tinh',
    file_system_access_mode='ro')})

Và điều kiện "cùng VPC" là chi tiết quan trọng đề đã nêu sẵn: mount hệ thống tệp đòi hỏi training instance nằm trong VPC có đường tới nó — đề nói điều kiện này đã thoả.

(Ghi chú thực tế: SageMaker training job có hỗ trợ dựng sẵn cho FSx for Lustre và EFS. Với FSx for NetApp ONTAP, việc mount thường đi qua giao thức NFS trong VPC. Trong bốn phương án, B vẫn là lựa chọn đúng về nguyên tắc — tránh sao chép 8 TB — nhưng khi triển khai thật, FSx for Lustre là lựa chọn được tài liệu hoá tốt nhất cho SageMaker training, và nó liên kết được với S3.)

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

  • D. Sao chép dữ liệu từ FSx sang S3 bucket và cấu hình SageMaker dùng bucket đó — đây là phương án gần nhất và hoạt động được, nhưng nó nhân bản 8 TB: tốn thời gian truyền, tốn chi phí lưu trữ gấp đôi, và cần cơ chế đồng bộ khi dữ liệu nguồn thay đổi. Trong khi dữ liệu đã ở cùng VPC và mount được trực tiếp.
  • A. Dùng AWS DataSync đồng bộ LIÊN TỤC FSx với S3, rồi SageMaker đọc từ S3 — cùng vấn đề nhân bản, cộng thêm một dịch vụ phải vận hành và trả tiền liên tục cho việc đồng bộ.
  • C. Xuất dữ liệu ra hệ thống cục bộ rồi tải lại lên SageMaker qua Python SDK — hoàn toàn không khả thi với 8 TB: tải xuống rồi tải lên là hai lần truyền qua Internet, mất rất nhiều ngày.

Ghi nhớ

Bốn nguồn dữ liệu cho SageMaker training job: | Nguồn | Đặc điểm | |---|---| | Amazon S3 | phổ biến nhất — File, Pipe, FastFile mode | | FSx for Lustre | hệ thống tệp hiệu năng cao, liên kết S3 được | | Amazon EFS | tệp dùng chung, chậm hơn FSx | | Hệ thống tệp khác trong VPC | mount qua NFS |

Bảng chọn theo tình huống: | Tình huống | Chọn | |---|---| | Dữ liệu đã ở S3 | S3 với FastFile hoặc File mode | | Hàng triệu tệp nhỏ | FSx for Lustre (liên kết S3) | | Dữ liệu đã ở hệ thống tệp trong VPC | mount trực tiếp ← câu này | | Đọc lặp qua nhiều job | FSx for Lustre |

Ba lợi ích của việc không sao chép dữ liệu: | Lợi ích | Chi tiết | |---|---| | Tiết kiệm chi phí lưu trữ | không trả tiền cho hai bản | | Không có độ trễ đồng bộ | dữ liệu luôn là bản mới nhất | | Không có bản sao lệch nhau | một nguồn sự thật duy nhất |

Ba điều kiện để mount hệ thống tệp cho training job: | Điều kiện | Chi tiết | |---|---| | Training job phải trong VPC | khai subnets và security_group_ids | | Security group cho phép lưu lượng | NFS (2049) hoặc Lustre (988, 1021–1023) | | Quyền IAM đọc hệ thống tệp | qua execution role |

Và một cân nhắc về hiệu năng với ảnh vệ tinh: chúng thường là tệp lớn đọc tuần tự, nên băng thông quan trọng hơn độ trễ. Nếu chuyển sang FSx for Lustre, chọn throughput per TiB cao (200 MB/s) sẽ đáng giá hơn là tăng dung lượng.

Câu 152 ML Model Development

A company is building a recommendation system to provide personalized product suggestions to its customers. The company has collected historical user interaction data - including product views, purchases, and ratings. An ML engineer needs to select the most suitable built-in Amazon SageMaker algorithm to train the recommendation model efficiently. The engineer wants a solution that minimizes development effort while providing high-quality recommendations.

Which built-in SageMaker algorithm should the ML engineer use to meet these requirements?

  1. A

    XGBoost (eXtreme Gradient Boosting)
  2. B

    K-Means Clustering
  3. C

    Factorization Machines
  4. D

    Linear Learner
Xem giải thích

Đáp án

C — Factorization Machines.

Vì sao đúng

Đề mô tả hệ gợi ý dựa trên dữ liệu tương tác người dùng–sản phẩm (lượt xem, mua hàng, đánh giá), và Factorization Machines là thuật toán dựng sẵn được thiết kế chính xác cho việc đó.

Vấn đề cốt lõi của hệ gợi ý là DỮ LIỆU THƯA:

Ma trận người dùng × sản phẩm:
  Mỗi người chỉ tương tác với một phần rất nhỏ catalog
  → hơn 99% ô trong ma trận là TRỐNG

Factorization Machines giải quyết bằng phân rã thành vector tiềm ẩn:

Thay vì học giá trị cho từng ô (bất khả thi):
  Học một vector k chiều cho MỖI người dùng và MỖI sản phẩm
  Dự đoán = tích vô hướng của hai vector
    ↓
  Suy ra được sở thích cho cặp CHƯA TỪNG tương tác

Đây chính là cơ chế của collaborative filtering — nền tảng của mọi hệ gợi ý hiện đại.

Và FM có ưu điểm so với matrix factorization cổ điển: nó nhận thêm đặc trưng phụ (tuổi người dùng, danh mục sản phẩm, thời điểm), nên xử lý tốt hơn với người dùng và sản phẩm mới.

Vế "minimizes development effort" cũng được đáp ứng: FM là thuật toán dựng sẵn của SageMaker, không phải viết mã huấn luyện.

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

  • A. XGBoost — đây là phương án gần nhất và XGBoost mạnh với dữ liệu bảng, nhưng nó xử lý kém dữ liệu thưa quy mô lớn: mã hoá hàng trăm nghìn sản phẩm thành đặc trưng one-hot tạo ra không gian khổng lồ mà cây quyết định xử lý rất kém. (XGBoost dùng được cho bài toán xếp hạng nếu bạn tự tạo đặc trưng tổng hợp — nhưng đó là nhiều công hơn.)
  • **B. K-Means Clustering — quá thô cho gợi ý cá nhân hoá: nó nhóm người dùng thành phân khúc, và mọi người trong cùng cụm nhận cùng một danh sách gợi ý. Nó là kỹ thuật bổ trợ (phân khúc để phân tích), không phải hệ gợi ý.
  • **D. Linear Learner — không nắm được tương tác giữa người dùng và sản phẩm: model tuyến tính học trọng số cho từng đặc trưng độc lập, trong khi bản chất của gợi ý là tương tác bậc hai giữa hai thực thể.

Ghi nhớ

Thuật toán dựng sẵn của SageMaker cho hệ gợi ý: | Thuật toán | Đặc điểm | |---|---| | Factorization Machines | dữ liệu thưa, tương tác người dùng–sản phẩm | | Object2Vec | embedding cho cặp thực thể bất kỳ — tổng quát hơn FM | | k-NN | tìm người dùng hoặc sản phẩm tương tự | | Neural Topic Model | gợi ý theo chủ đề nội dung |

Ba loại hệ gợi ý: | Loại | Dựa trên | Điểm yếu | |---|---|---| | Collaborative filtering | hành vi người dùng tương tự | cold start với người và sản phẩm MỚI | | Content-based | thuộc tính sản phẩm | ít đa dạng | | Hybrid | kết hợp | khắc phục cả hai |

FM thuộc nhóm đầu — nên trong hệ thống thật nên ghép thêm content-based cho khách hàng mới.

Ba tín hiệu tương tác và độ mạnh: | Tín hiệu | Độ mạnh | |---|---| | Mua hàng | mạnh nhất — thể hiện ý định thật | | Đánh giá | mạnh (nhưng ít người đánh giá) | | Lượt xem | yếu — có thể chỉ là tò mò |

Gán trọng số khác nhau cho các loại tín hiệu thường cải thiện đáng kể so với coi chúng như nhau — một lượt mua đáng giá hơn nhiều lượt xem.

Ba chỉ số đánh giá hệ gợi ý: | Chỉ số | Đo | |---|---| | Precision@K, Recall@K | trong K gợi ý đầu, bao nhiêu đúng | | NDCG | có tính THỨ TỰ — đúng ở vị trí 1 giá trị hơn vị trí 10 | | Coverage, Diversity | gợi ý có đa dạng không hay chỉ lặp lại sản phẩm bán chạy |

Dòng cuối quan trọng trong thực tế: một hệ thống chỉ gợi ý sản phẩm phổ biến có precision cao nhưng không tạo giá trị mới — khách hàng vốn đã tìm thấy chúng.

Và Amazon Personalize đáng nhắc như lựa chọn thay thế: dịch vụ được quản lý cho hệ gợi ý, xử lý sẵn cold start và cập nhật thời gian thực — thường nhanh hơn nhiều so với tự xây trên SageMaker.

Câu 153 ML Model Development

You are an AI/ML engineer at a company that is rapidly expanding its use of generative AI and machine learning to create personalized customer experiences. The company is exploring AWS services to quickly prototype and deploy both generative AI models and traditional machine learning models with minimal effort. The team is particularly interested in services that provide pre-built models, templates, and the ability to scale solutions into production seamlessly.

Given these requirements, which of the following statements BEST highlights the differences between Amazon Bedrock and Amazon SageMaker JumpStart to help your team make an informed decision?

  1. A

    Amazon Bedrock focuses on providing a managed service for deploying pre-trained foundation models from various providers, whereas Amazon SageMaker JumpStart offers a range of pre-built solutions, including models, notebooks, and algorithms for both machine learning and generative AI use cases
  2. B

    Amazon Bedrock is ideal for quick deployment of computer vision models, while Amazon SageMaker JumpStart specializes in deploying natural language processing models
  3. C

    Amazon Bedrock is designed specifically for building and deploying custom machine learning models, while Amazon SageMaker JumpStart is tailored for deploying pre-trained large language models (LLMs) with minimal customization
  4. D

    Amazon Bedrock provides a simplified interface for training and tuning models from scratch, while Amazon SageMaker JumpStart is primarily for deploying third-party models with limited customization
Xem giải thích

Đáp án

A — Amazon Bedrock tập trung cung cấp dịch vụ được quản lý để triển khai foundation model đã huấn luyện sẵn từ nhiều nhà cung cấp, trong khi SageMaker JumpStart cung cấp một loạt giải pháp dựng sẵn gồm model, notebook và thuật toán cho cả ML truyền thống lẫn GenAI.

Vì sao đúng

Đây là mô tả chính xác vai trò của hai dịch vụ: | | Amazon Bedrock | SageMaker JumpStart | |---|---|---| | Nội dung | foundation model từ nhiều nhà cung cấp | model, notebook, thuật toán, mẫu giải pháp | | Phạm vi | chỉ GenAI | cả ML truyền thống lẫn GenAI | | Hạ tầng | serverless — không quản lý gì | bạn triển khai endpoint SageMaker | | Tính tiền | theo token | theo instance-giờ |

Ba khác biệt thực dụng quan trọng nhất:

① Ai quản lý hạ tầng:

Bedrock:    gọi API → xong. Không có endpoint nào của bạn.
JumpStart:  triển khai model lên endpoint SageMaker → bạn quản lý instance

② Mô hình chi phí:

Bedrock:    trả theo token → tải thấp = chi phí thấp
JumpStart:  trả theo instance-giờ → endpoint chạy 24/7 dù không ai gọi

Với khối lượng lớn và ổn định, instance-giờ có thể rẻ hơn; với tải thưa, Bedrock rẻ hơn nhiều.

③ Phạm vi model:

Bedrock:    foundation model — Claude, Titan, Llama, Mistral, Cohere...
JumpStart:  hàng trăm model gồm cả CNN phân loại ảnh, BERT, XGBoost...

Và JumpStart cho nhiều hơn model: nó có notebook mẫu chạy được ngay và solution template cho các bài toán hoàn chỉnh — đúng như đáp án mô tả.

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

  • C. Bedrock được thiết kế để XÂY và TRIỂN KHAI MODEL TUỲ CHỈNH, còn JumpStart chuyên triển khai LLM đã huấn luyện sẵn với ít tuỳ biến — đây là phương án gần nhất và đảo ngược vai trò: Bedrock cung cấp model được quản lý sẵn, còn SageMaker (bao gồm JumpStart) mới là nền tảng cho model tuỳ chỉnh.
  • D. Bedrock cung cấp giao diện đơn giản để HUẤN LUYỆN VÀ TINH CHỈNH MODEL TỪ ĐẦU, JumpStart chủ yếu triển khai model bên thứ ba với ít tuỳ biến — Bedrock không huấn luyện từ đầu: nó phục vụ foundation model có sẵn và hỗ trợ fine-tune có giới hạn, không phải pre-training.
  • B. Bedrock lý tưởng cho model THỊ GIÁC MÁY TÍNH, JumpStart chuyên NLP — sai hoàn toàn về phân vai: cả hai đều hỗ trợ nhiều loại tác vụ, và không có sự phân chia nào theo kiểu này.

Ghi nhớ

Bốn dịch vụ AI/ML của AWS — nhớ đúng vai: | Dịch vụ | Việc | |---|---| | Bedrock | foundation model được quản lý, serverless, theo token | | SageMaker JumpStart | kho model và mẫu giải pháp — bạn tự host | | SageMaker (nền tảng) | huấn luyện và host model của bạn | | Dịch vụ AI chuyên biệt | Comprehend, Rekognition, Transcribe... |

Cách chọn giữa Bedrock và JumpStart: | Đề nói | Chọn | |---|---| | "managed", "serverless", "third-party foundation models" | Bedrock | | "pre-trained models", "notebooks", "cả ML lẫn GenAI" | JumpStart | | "fine-tune sâu", "kiểm soát hạ tầng" | SageMaker | | Khối lượng lớn ổn định, model nhỏ | JumpStart (instance-giờ rẻ hơn) |

Ba thành phần của JumpStart: | Thành phần | Chi tiết | |---|---| | Model | hàng trăm model từ Hugging Face và các nguồn khác | | Notebook mẫu | ví dụ chạy được ngay | | Solution template | giải pháp đầu-cuối cho bài toán cụ thể |

Và fine-tuning dựng sẵn là điểm mạnh riêng của JumpStart:

estimator = JumpStartEstimator(model_id='huggingface-tc-bert-base-uncased')
estimator.fit({'training': 's3://kho/du-lieu-cua-ban/'})

Ba dòng — không script huấn luyện, không container tuỳ chỉnh.

Ba cách kết hợp hai dịch vụ trong một kiến trúc: | Kết hợp | Chi tiết | |---|---| | Bedrock cho GenAI, JumpStart cho model chuyên biệt | mỗi cái làm phần nó giỏi | | Fine-tune trên SageMaker → nhập vào Bedrock | Custom Model Import | | Prototype trên JumpStart → chuyển sang Bedrock | khi muốn bỏ quản lý hạ tầng |

Dòng giữa đáng biết: Bedrock Custom Model Import cho phép đưa model đã tuỳ biến vào Bedrock để hưởng hạ tầng serverless — kết hợp được ưu điểm của cả hai.

Câu 154 ML Model Development

You are a data scientist working on a loan approval model for a bank. The model predicts whether a loan application should be approved or rejected based on various features such as income, credit score, and employment history. The bank is particularly concerned about ensuring that the model is fair and does not discriminate against any demographic group, such as age, gender, or ethnicity. To address this, you need to select the appropriate evaluation metrics to assess both the model’s performance and any potential bias.

Given these requirements, which combination of evaluation metrics and bias detection methods is MOST APPROPRIATE for ensuring fair and accurate model predictions?

  1. A

    Evaluate the model using F1 score and AUC-ROC, and assess whether the model has similar true positive rates across different demographic groups
  2. B

    Measure the model’s performance using accuracy and AUC-ROC, and check for bias by comparing feature distributions across demographic groups
  3. C

    Use accuracy as the primary evaluation metric and perform feature importance analysis to ensure that the model’s decisions are driven by relevant features
  4. D

    Evaluate the model using F1 score and AUC-ROC, and and check for bias by comparing feature distributions across demographic groups
Xem giải thích

Đáp án

A — Đánh giá model bằng F1 score và AUC-ROC, và kiểm tra xem model có tỷ lệ true positive tương đương giữa các nhóm nhân khẩu hay không.

Vì sao đúng

Đề nêu hai yêu cầu song song, và đáp án phải đúng ở cả hai: | Yêu cầu | Cơ chế | |---|---| | Đánh giá hiệu năng model | F1 + AUC-ROC | | Phát hiện thiên lệch giữa các nhóm | so tỷ lệ true positive giữa các nhóm |

Vế thứ hai là điểm phân biệt quan trọng nhất, và nó là chỗ hai phương án B và D sai:

Đo thiên lệch phải nhìn vào KẾT QUẢ CỦA MODEL, không phải vào phân bố ĐẦU VÀO.

So sánh phân bố ĐẶC TRƯNG giữa các nhóm:
  "Nhóm A có thu nhập trung bình khác nhóm B"
  → đó là SỰ THẬT VỀ XÃ HỘI, không phải thiên lệch của model

So sánh TỶ LỆ TRUE POSITIVE giữa các nhóm:
  "Trong số người ĐỦ ĐIỀU KIỆN vay, model duyệt 85% nhóm A nhưng chỉ 62% nhóm B"
  → đây MỚI là thiên lệch của model

Tỷ lệ true positive tương đương giữa các nhóm là định nghĩa của equal opportunity — một tiêu chuẩn công bằng được dùng rộng rãi trong tín dụng:

Equal opportunity:  P(dự đoán = duyệt | thực tế đủ điều kiện, nhóm A)
                  = P(dự đoán = duyệt | thực tế đủ điều kiện, nhóm B)

Và F1 + AUC-ROC cho vế hiệu năng: F1 cân bằng precision và recall (quan trọng vì duyệt nhầm và từ chối nhầm đều tốn kém), AUC-ROC đo khả năng phân biệt qua mọi ngưỡng.

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

  • **D. Đánh giá bằng F1 và AUC-ROC, và kiểm tra thiên lệch bằng cách so sánh PHÂN BỐ ĐẶC TRƯNG giữa các nhóm — đây là phương án gần nhất và nửa đầu giống hệt đáp án A. Nó sai ở nửa sau: phân bố đặc trưng khác nhau không phải thiên lệch của model — đó là đặc điểm của dân số. Model có thể hoàn toàn công bằng dù phân bố đầu vào rất khác nhau, và ngược lại.
  • B. Dùng accuracy và AUC-ROC, kiểm tra thiên lệch bằng so sánh phân bố đặc trưng — sai cả hai vế: accuracy gây hiểu lầm với dữ liệu mất cân bằng (tỷ lệ vỡ nợ thường thấp), và cách đo thiên lệch sai như D.
  • C. Dùng accuracy làm chỉ số chính và phân tích feature importance để đảm bảo quyết định dựa trên đặc trưng liên quan — feature importance hữu ích để phát hiện đặc trưng thay thế (proxy), nhưng nó không đo được chênh lệch kết quả giữa các nhóm. Model có thể không dùng trực tiếp giới tính mà vẫn phân biệt đối xử qua các đặc trưng tương quan.

Ghi nhớ

Ba tiêu chuẩn công bằng thường dùng — và chúng không thể thoả mãn đồng thời: | Tiêu chuẩn | Định nghĩa | |---|---| | Demographic parity | tỷ lệ được duyệt bằng nhau giữa các nhóm | | Equal opportunity | tỷ lệ TRUE POSITIVE bằng nhau ← câu này | | Equalized odds | cả TPR lẫn FPR bằng nhau |

Một kết quả toán học quan trọng: ba tiêu chuẩn này mâu thuẫn nhau khi tỷ lệ cơ sở giữa các nhóm khác nhau — nên phải chọn một dựa trên bối cảnh nghiệp vụ và pháp lý, không thể đạt tất cả.

Với tín dụng, equal opportunity thường được ưa dùng: nó nói rằng trong số những người thật sự đủ điều kiện, mọi nhóm phải có cơ hội được duyệt như nhau — không đòi hỏi tỷ lệ duyệt tổng thể bằng nhau (vốn có thể khác do yếu tố kinh tế thật).

Các chỉ số thiên lệch của SageMaker Clarify: | Chỉ số | Đo | |---|---| | DPPL | chênh lệch tỷ lệ dự đoán dương giữa các nhóm | | DI (Disparate Impact) | tỷ số của hai tỷ lệ — quy tắc 80% | | RD (Recall Difference) | chênh lệch recall — chính là equal opportunity | | DAR, DCR | chênh lệch precision, tỷ lệ chấp nhận |

Quy tắc 80% (four-fifths rule) là chuẩn thường dùng trong tuyển dụng và tín dụng ở Mỹ:

DI = tỷ lệ duyệt nhóm thiểu số / tỷ lệ duyệt nhóm đa số
DI < 0,8  →  dấu hiệu tác động chênh lệch (disparate impact)

Ba cách phát hiện đặc trưng thay thế (proxy) cho thuộc tính nhạy cảm: | Cách | Chi tiết | |---|---| | Tương quan với thuộc tính nhạy cảm | mã bưu chính thường thay thế cho chủng tộc | | SHAP theo nhóm | đặc trưng nào chi phối dự đoán ở mỗi nhóm | | Huấn luyện model dự đoán thuộc tính nhạy cảm | nếu dự đoán được, có proxy |

Và một lưu ý về mặt vận hành: để đo thiên lệch, bạn cần biết người thuộc nhóm nào — trong khi nhiều quy định hạn chế thu thập chính những thuộc tính đó. Cách thường dùng: giữ thuộc tính nhóm ở kho riêng chỉ dùng cho kiểm toán công bằng, không đưa vào đặc trưng của model.

Câu 155 Deployment and Orchestration of ML Workflows

A healthcare company is running containerized ML applications to process patient data and generate predictive insights. These applications are deployed across Amazon EC2 instances, Amazon Elastic Container Service (Amazon ECS) cluster and AWS Lambda functions. The EC2 and ECS workloads store predictions and artifacts on Amazon Elastic Block Store (Amazon EBS) volumes. To optimize costs, the company wants to identify inefficiently used resources and receive actionable recommendations to reduce expenses.

What is the most efficient solution to achieve this goal with minimal development effort?

  1. A

    Use AWS Trusted Advisor to analyze the specifications and utilization metrics of your AWS resources
  2. B

    Use AWS Budgets to analyze the specifications and utilization metrics of your AWS resources
  3. C

    Use AWS Compute Optimizer to analyze the specifications and utilization metrics of your AWS compute resources
  4. D

    Use AWS Cost Explorer to analyze the specifications and utilization metrics of your AWS compute resources
Xem giải thích

Đáp án

C — Dùng AWS Compute Optimizer phân tích thông số kỹ thuật và metric sử dụng của các tài nguyên tính toán.

Vì sao đúng

Đề nêu các loại tài nguyên rất cụ thể, và Compute Optimizer hỗ trợ đúng những loại đó: | Tài nguyên trong đề | Compute Optimizer hỗ trợ | |---|---| | Amazon EC2 | ✅ | | Amazon ECS trên Fargate | ✅ | | AWS Lambda | ✅ | | Amazon EBS volume | ✅ |

Compute Optimizer dùng máy học phân tích metric lịch sử rồi đưa ra khuyến nghị cụ thể:

EC2 instance i-0abc123:
  Hiện tại:  m5.4xlarge  (CPU max 12%, bộ nhớ max 24%)
  Khuyến nghị: m5.xlarge   → tiết kiệm ~65%
  Rủi ro hiệu năng: Thấp

Lambda function xu-ly-anh:
  Hiện tại:  3008 MB      (dùng thực tế 512 MB)
  Khuyến nghị: 1024 MB     → tiết kiệm ~60%

EBS volume vol-0def456:
  Hiện tại:  io1 500 IOPS  (dùng thực tế 45 IOPS)
  Khuyến nghị: gp3          → tiết kiệm ~70%

Và vế "actionable recommendations" là điểm mạnh riêng: nó không chỉ nói "tài nguyên này chưa dùng hết", nó nói nên đổi sang loại nào và tiết kiệm được bao nhiêu.

Vế "minimal development effort" cũng được đáp ứng: chỉ cần bật dịch vụ và chờ nó thu thập đủ dữ liệu (thường 14 ngày), không viết mã gì.

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

  • A. Dùng AWS Trusted Advisor phân tích thông số và metric sử dụng — đây là phương án gần nhất và Trusted Advisor cũng có khuyến nghị tối ưu chi phí, nhưng nó thô hơn nhiều: nó chỉ ra tài nguyên nhàn rỗi hoặc chưa dùng hết theo ngưỡng cố định, mà không khuyến nghị loại instance cụ thể nên đổi sang. Và nó không hỗ trợ Lambda memory sizing — một trong bốn loại tài nguyên đề nêu. (Đầy đủ kiểm tra của Trusted Advisor còn cần Business/Enterprise Support.)
  • D. Dùng AWS Cost Explorer phân tích thông số và metric sử dụng của tài nguyên tính toán — Cost Explorer phân tích CHI PHÍ, không phân tích MỨC SỬ DỤNG tài nguyên: nó cho biết bạn tiêu bao nhiêu ở đâu, nhưng không biết instance đó có bị cấp thừa hay không. (Nó có tính năng Rightsizing Recommendations, nhưng chỉ cho EC2 và dựa trên dữ liệu của Compute Optimizer.)
  • B. Dùng AWS Budgets phân tích thông số và metric sử dụng — Budgets chỉ đặt ngưỡng và cảnh báo: nó không phân tích gì và không khuyến nghị gì.

Ghi nhớ

Bốn công cụ tối ưu chi phí — nhớ đúng vai: | Công cụ | Việc | |---|---| | Compute Optimizer | khuyến nghị KÍCH THƯỚC tài nguyên tính toán cụ thể | | Trusted Advisor | khuyến nghị rộng: nhàn rỗi, RI, bảo mật, hiệu năng | | Cost Explorer | phân tích CHI PHÍ, xu hướng, dự báo | | Budgets | đặt ngưỡng và cảnh báo |

Câu hỏi phân biệt:

"Tài nguyên này nên đổi sang loại nào?" → Compute Optimizer "Tôi có tài nguyên nào lãng phí không?" → Trusted Advisor "Tiền của tôi đi đâu?" → Cost Explorer "Báo cho tôi khi vượt ngưỡng" → Budgets

Bốn loại tài nguyên Compute Optimizer hỗ trợ: | Loại | Khuyến nghị về | |---|---| | EC2 instance | loại và kích thước instance | | Auto Scaling group | cấu hình nhóm | | EBS volume | loại volume và IOPS | | Lambda function | kích thước bộ nhớ | | ECS trên Fargate | CPU và bộ nhớ task |

Dòng Lambda đáng chú ý vì nó có đặc điểm riêng: Lambda cấp CPU tỷ lệ thuận với bộ nhớ, nên tăng bộ nhớ có thể vừa nhanh hơn vừa rẻ hơn — Compute Optimizer tính được điểm tối ưu đó.

Ba mức khuyến nghị của Compute Optimizer: | Mức | Nghĩa | |---|---| | Under-provisioned | thiếu tài nguyên — có rủi ro hiệu năng | | Over-provisioned | thừa tài nguyên — lãng phí tiền | | Optimized | đang phù hợp |

Ba điều kiện để có khuyến nghị chất lượng: | Điều kiện | Chi tiết | |---|---| | Đủ dữ liệu lịch sử | tối thiểu 14 ngày | | Bật enhanced infrastructure metrics | dùng 3 tháng dữ liệu thay vì 14 ngày — chính xác hơn | | Bật CloudWatch agent cho metric bộ nhớ | CPU đo được mặc định, bộ nhớ thì KHÔNG |

Dòng cuối là chi tiết quan trọng và hay bị bỏ sót: không có agent thì Compute Optimizer không biết mức dùng bộ nhớ, và khuyến nghị chỉ dựa trên CPU — có thể dẫn tới chọn instance thiếu RAM.

Và một lưu ý cho workload ML: SageMaker endpoint KHÔNG nằm trong phạm vi Compute Optimizer. Với chúng, dùng SageMaker Inference Recommender — công cụ chạy load test thật trên nhiều loại instance.

Câu 156 ML Solution Monitoring, Maintenance, and Security

A company operates an Amazon SageMaker training job in a public subnet within an Amazon VPC. The network is properly configured, allowing seamless data transfer between the SageMaker training job and Amazon S3. Recently, the company identified malicious traffic originating from a specific IP address, targeting the resources within the VPC. The company needs to block all traffic from the suspicious IP address while ensuring legitimate traffic remains unaffected.

Which of the following would you recommend to address this requirement?

  1. A

    Create a network ACL (NACL) for the subnet hosting the SageMaker training job and add a deny rule to block traffic from the specific IP address
  2. B

    Modify the VPC route table to direct all traffic from the specific IP address to a target with a blackhole routing state
  3. C

    Update the security group associated with the SageMaker training job to include a deny rule for traffic from the specific IP address
  4. D

    Enable AWS WAF (Web Application Firewall) for the SageMaker domain and create a rule to block traffic from the specific IP address
Xem giải thích

Đáp án

A — Tạo network ACL (NACL) cho subnet chứa training job và thêm deny rule chặn lưu lượng từ địa chỉ IP cụ thể.

Vì sao đúng

Đề nêu yêu cầu: chặn toàn bộ lưu lượng từ một IP đáng ngờ trong khi lưu lượng hợp lệ không bị ảnh hưởng.

Điểm mấu chốt nằm ở một khác biệt cơ bản giữa NACL và security group:

Security group CHỈ CÓ allow rule — không có deny rule.

Security group Network ACL
Có deny rule ❌ CHỈ allow ✅ có cả allow lẫn deny
Mức áp dụng ENI (instance) SUBNET
Có trạng thái ✅ stateful ❌ stateless
Xử lý rule tất cả rule theo THỨ TỰ số, dừng ở rule khớp đầu tiên

Vì sao chỉ NACL làm được: với security group, "không cho phép" = "không có rule allow". Nhưng nếu đã có rule allow cho 0.0.0.0/0 hoặc cho một dải rộng chứa IP đó, bạn không thể loại trừ riêng một IP — chỉ có thể thu hẹp toàn bộ rule.

NACL rules (xử lý theo thứ tự số tăng dần):
  Rule 90:   DENY   từ 203.0.113.45/32   ← IP đáng ngờ, số THẤP
  Rule 100:  ALLOW  từ 0.0.0.0/0         ← lưu lượng hợp lệ

Rule 90 được xét trước, nên IP đó bị chặn; mọi IP khác rơi xuống rule 100 và được phép.

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

  • C. Cập nhật security group của training job để thêm deny rule — đây là phương án gần nhất và bị loại bởi một sự thật kỹ thuật: security group không hỗ trợ deny rule. Đây là câu hỏi kiểm tra đúng kiến thức đó.
  • B. Sửa route table để định tuyến toàn bộ lưu lượng từ IP đó tới một target ở trạng thái blackhole — route table định tuyến theo ĐÍCH ĐẾN, không theo NGUỒN: bạn khai "lưu lượng ĐI TỚI dải X đi qua gateway Y", không khai được "lưu lượng ĐẾN TỪ IP Z". (Blackhole là trạng thái của một route trỏ tới tài nguyên không còn tồn tại, không phải một cơ chế chặn.)
  • D. Bật AWS WAF cho SageMaker domain và tạo rule chặn IP — WAF không gắn được vào SageMaker domain: nó bảo vệ CloudFront, ALB, API Gateway, AppSync. Và nó lọc ở tầng 7 (HTTP), trong khi đây là vấn đề ở tầng mạng.

Ghi nhớ

So sánh NACL và security group — bảng nên thuộc: | Đặc điểm | Security group | Network ACL | |---|---|---| | Mức | ENI / instance | subnet | | Deny rule | ❌ | ✅ | | Stateful | ✅ trả lời tự động được phép | ❌ phải khai cả hai chiều | | Xử lý | tất cả rule | theo thứ tự, dừng ở rule khớp | | Mặc định | deny hết | allow hết (NACL mặc định) |

Hệ quả của tính stateless của NACL: nếu chặn inbound từ một IP, bạn thường cũng nên chặn outbound tới IP đó — và với lưu lượng hợp lệ, phải mở cả inbound lẫn outbound, bao gồm dải cổng tạm (1024–65535) cho lưu lượng trả về.

Quy tắc đánh số NACL rule: | Nguyên tắc | Chi tiết | |---|---| | Số nhỏ được xét trước | đặt deny rule ở số thấp | | Chừa khoảng trống | dùng 100, 200, 300 để chèn được sau này | | Rule * cuối cùng | deny mặc định, không sửa được |

Ba tầng bảo vệ mạng — nên dùng theo lớp: | Tầng | Công cụ | Chặn gì | |---|---|---| | Subnet | NACL | IP hoặc dải IP cụ thể | | Instance | Security group | nguồn được phép (allow) | | Ứng dụng (HTTP) | AWS WAF | request độc hại, SQL injection, rate limit |

Và ba cách phát hiện lưu lượng đáng ngờ ngay từ đầu: | Cách | Chi tiết | |---|---| | VPC Flow Logs | ghi lại mọi luồng lưu lượng — nguồn của phân tích | | Amazon GuardDuty | phát hiện mối đe doạ bằng ML, tự nhận IP độc hại đã biết | | AWS Network Firewall | lọc có trạng thái ở mức VPC, mạnh hơn NACL |

GuardDuty đáng bật mặc định: nó tự phát hiện lưu lượng tới IP độc hại đã biết, quét cổng, và hành vi bất thường — thay vì chờ ai đó phát hiện thủ công như tình huống trong đề.

Và với môi trường training job nhạy cảm, cân nhắc thêm: đặt training job trong PRIVATE subnet (không có Internet gateway) và dùng VPC endpoint cho S3 và SageMaker — khi đó phần lớn lưu lượng độc hại từ bên ngoài không tới được ngay từ đầu.

Câu 157 ML Model Development

How would you differentiate between K-Means and K-Nearest Neighbors (KNN) algorithms in machine learning?

  1. A

    K-Means is an unsupervised learning algorithm used for clustering data points into groups, while KNN is a supervised learning algorithm used for classifying data points based on their proximity to labeled examples
  2. B

    K-Means is primarily used for regression tasks, while KNN is used for reducing the dimensionality of data
  3. C

    K-Means is a supervised learning algorithm used for classification, while KNN is an unsupervised learning algorithm used for clustering
  4. D

    K-Means requires labeled data to form clusters, whereas KNN does not use labeled data for making predictions
Xem giải thích

Đáp án

A — K-Means là thuật toán học KHÔNG giám sát dùng để phân cụm dữ liệu thành nhóm; KNN là thuật toán học CÓ giám sát dùng để phân loại dựa trên độ gần với các ví dụ đã gán nhãn.

Vì sao đúng

Hai thuật toán này có tên gần giống nhau và đều dùng khái niệm "khoảng cách", nên rất dễ nhầm — nhưng chúng khác nhau ở ba điểm căn bản: | | K-Means | KNN | |---|---|---| | Hình thức học | KHÔNG giám sát | CÓ giám sát | | Cần nhãn | ❌ | ✅ | | Việc | phân cụm | phân loại (hoặc hồi quy) | | Ý nghĩa của K | số CỤM | số LÁNG GIỀNG xét tới |

K-Means — tìm cấu trúc ẩn:

Dữ liệu KHÔNG nhãn
    ↓ chọn K = 3
Thuật toán tìm 3 tâm cụm, gán mỗi điểm về tâm gần nhất
    ↓ lặp cho tới khi ổn định
3 nhóm — nhưng thuật toán KHÔNG BIẾT chúng là gì

KNN — phân loại theo láng giềng:

Điểm mới cần phân loại
    ↓ tìm K = 5 điểm ĐÃ GÁN NHÃN gần nhất
    ↓ bỏ phiếu: 3 "gian lận", 2 "hợp lệ"
Kết luận: gian lận

Và ý nghĩa của chữ K khác hẳn nhau — đây là điểm dễ nhầm nhất:

K-Means, K = 3  →  chia dữ liệu thành 3 nhóm
KNN,     K = 3  →  xét 3 láng giềng gần nhất khi phân loại một điểm

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

  • C. K-Means là có giám sát dùng để phân loại, KNN là không giám sát dùng để phân cụm — đảo ngược hoàn toàn cả hai.
  • D. K-Means CẦN dữ liệu có nhãn để tạo cụm, KNN không dùng nhãn khi dự đoán — đảo ngược vế nhãn: K-Means không cần nhãn, KNN thì cần.
  • B. K-Means chủ yếu dùng cho HỒI QUY, KNN dùng để GIẢM CHIỀU dữ liệu — sai cả hai: K-Means là phân cụm (không phải hồi quy), và KNN là phân loại hoặc hồi quy (không phải giảm chiều — đó là PCA).

Ghi nhớ

Mẹo nhớ nhanh:

K-Means: chữ "Means" = TRUNG BÌNH của cụm → tìm cụm → KHÔNG giám sát. KNN: "Nearest Neighbors" = láng giềng ĐÃ BIẾT NHÃN → dùng nhãn → CÓ giám sát.

Ba đặc điểm riêng của KNN: | Đặc điểm | Chi tiết | |---|---| | Lazy learning | KHÔNG có giai đoạn huấn luyện — chỉ lưu dữ liệu | | Suy luận chậm | phải tính khoảng cách tới TOÀN BỘ tập huấn luyện | | Nhạy với thang đo | bắt buộc chuẩn hoá trước |

Dòng giữa là lý do KNN ít dùng cho hệ thống thời gian thực quy mô lớn: mỗi dự đoán tốn thời gian tỷ lệ với kích thước tập huấn luyện.

Ba đặc điểm riêng của K-Means: | Đặc điểm | Chi tiết | |---|---| | Phải chọn K trước | dùng elbow method hoặc silhouette score | | Nhạy với khởi tạo | K-Means++ chọn tâm ban đầu tốt hơn | | Giả định cụm hình cầu | kém với cụm hình dạng phức tạp — dùng DBSCAN |

Bảng phân loại thuật toán theo hình thức học: | Hình thức | Thuật toán | |---|---| | Có giám sát — phân loại | KNN, hồi quy logistic, SVM, cây quyết định, XGBoost | | Có giám sát — hồi quy | hồi quy tuyến tính, XGBoost, DeepAR | | Không giám sát — phân cụm | K-Means, DBSCAN, hierarchical clustering | | Không giám sát — giảm chiều | PCA, t-SNE, UMAP | | Không giám sát — bất thường | Random Cut Forest, Isolation Forest |

Và một ứng dụng kết hợp đáng biết: dùng K-Means để phân khúc khách hàng, rồi huấn luyện một model riêng cho mỗi phân khúc. Đây là mẫu hữu ích khi các nhóm khách hàng có hành vi khác biệt rõ rệt — một model chung phải thoả hiệp giữa các nhóm, còn model riêng thì không.

Câu 158 Deployment and Orchestration of ML Workflows

You are a machine learning engineer at a biotechnology company working on a deep learning model to analyze genomic sequences. The model requires significant computational resources for training due to the complexity and size of the dataset, which consists of billions of nucleotide sequences. Additionally, once deployed, the model must provide real-time inferences for clinical applications, requiring low-latency predictions. Your task is to choose the appropriate compute environment for both training and inference.

Which of the following compute environment configurations is the MOST SUITABLE for meeting the training and inference requirements of this use case?

  1. A

    Use Amazon SageMaker with p3 instances (NVIDIA V100 GPUs) for training, and deploy the model using ml.m5.large instances (Intel Skylake CPUs) for real-time inference to balance cost and performance
  2. B

    Use Amazon SageMaker with ml.c5.large instances (Intel Cascade Lake CPUs) for training and inference, relying on the CPU's high memory bandwidth for both tasks
  3. C

    Use Amazon SageMaker with p4d instances (NVIDIA A100 GPUs) for training to handle large-scale deep learning workloads, and deploy the model using ml.inf1 instances (AWS Inferentia chips) for low-latency inference
  4. D

    Use Amazon EC2 with g4dn instances (NVIDIA T4 GPUs) for both training and inference, optimizing for cost-efficiency while maintaining moderate GPU performance
Xem giải thích

Đáp án

C — Dùng SageMaker với instance p4d (NVIDIA A100) cho huấn luyện để xử lý workload deep learning quy mô lớn, và triển khai bằng instance ml.inf1 (AWS Inferentia) cho suy luận độ trễ thấp.

Vì sao đúng

Đề nêu hai yêu cầu tách biệt, và mỗi cái cần loại phần cứng khác nhau: | Giai đoạn | Yêu cầu | Phần cứng | |---|---|---| | Huấn luyện | tài nguyên tính toán lớn, hàng tỷ chuỗi nucleotide | GPU mạnh (p4d) | | Suy luận | độ trễ thấp cho ứng dụng lâm sàng | Inferentia (inf1) |

Nguyên tắc quan trọng: huấn luyện và suy luận có đặc tính tính toán khác nhau.

Huấn luyện:  forward + backward pass, cập nhật hàng tỷ trọng số
             → cần bộ nhớ GPU lớn và băng thông cao
             → chạy hàng giờ tới hàng ngày

Suy luận:    chỉ forward pass, một mẫu hoặc lô nhỏ
             → cần độ trễ thấp và chi phí mỗi dự đoán thấp
             → chạy liên tục 24/7

Vì sao Inferentia cho suy luận: | Đặc điểm | Chi tiết | |---|---| | Chip do AWS thiết kế riêng cho SUY LUẬN | tối ưu đúng loại phép tính cần | | Chi phí mỗi suy luận thấp hơn GPU | thường rẻ hơn đáng kể | | Độ trễ thấp | phù hợp ứng dụng lâm sàng | | Cần biên dịch | qua AWS Neuron SDK |

Và p4d cho huấn luyện: NVIDIA A100 có bộ nhớ lớn và hỗ trợ NVLink cùng EFA — cần thiết cho huấn luyện phân tán trên dữ liệu gen quy mô lớn.

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

  • A. Dùng p3 (V100) cho huấn luyện và ml.m5.large (CPU) cho suy luận thời gian thực để cân bằng chi phí và hiệu năng — đây là phương án gần nhất và p3 cho huấn luyện là hợp lý (dù p4d mạnh hơn), nhưng CPU cho suy luận model deep learning phân tích chuỗi gen khó đạt độ trễ thấp mà ứng dụng lâm sàng cần. m5.large còn là instance rất nhỏ.
  • B. Dùng ml.c5.large (CPU) cho CẢ huấn luyện lẫn suy luận, dựa vào băng thông bộ nhớ cao của CPU — CPU không khả thi cho huấn luyện deep learning quy mô này: hàng tỷ chuỗi nucleotide trên CPU sẽ mất hàng tháng. Và "băng thông bộ nhớ cao của CPU" không phải lợi thế so với GPU.
  • D. Dùng EC2 với g4dn (T4) cho cả huấn luyện lẫn suy luận, tối ưu chi phí với hiệu năng GPU vừa phải — T4 quá yếu cho huấn luyện quy mô lớn (nó là GPU suy luận), và dùng EC2 thay SageMaker nghĩa là tự quản lý mọi thứ.

Ghi nhớ

Các loại instance ML của AWS và mục đích: | Họ | Chip | Dùng cho | |---|---|---| | p3, p4d, p5 | NVIDIA V100, A100, H100 | HUẤN LUYỆN deep learning quy mô lớn | | g4dn, g5 | NVIDIA T4, A10G | suy luận GPU, huấn luyện nhỏ, đồ hoạ | | inf1, inf2 | AWS Inferentia | SUY LUẬN — rẻ và nhanh | | trn1, trn2 | AWS Trainium | HUẤN LUYỆN — thay thế GPU | | c5, m5, r5 | CPU | model nhẹ, tiền xử lý |

Mẹo nhớ hai chip AWS:

Inferentia → Inference (suy luận) Trainium → Training (huấn luyện)

Nguyên tắc chọn phần cứng: | Giai đoạn | Ưu tiên | |---|---| | Huấn luyện | thông lượng và bộ nhớ — GPU mạnh hoặc Trainium | | Suy luận thời gian thực | độ trễ và chi phí mỗi dự đoán — Inferentia hoặc GPU nhỏ | | Suy luận theo lô | thông lượng — GPU hoặc CPU tuỳ model | | Thử nghiệm, phát triển | rẻ nhất có thể — CPU |

Ba điều kiện dùng Inferentia: | Điều kiện | Chi tiết | |---|---| | Biên dịch qua AWS Neuron SDK | thêm một bước trong pipeline | | Framework được hỗ trợ | PyTorch, TensorFlow và model phổ biến | | Kiểm tra model biên dịch được | không phải model nào cũng hỗ trợ |

Ba cách xác nhận lựa chọn phần cứng trước khi cam kết: | Cách | Chi tiết | |---|---| | SageMaker Inference Recommender | load test thật trên nhiều loại instance, so chi phí mỗi suy luận | | SageMaker Debugger profiling | xem GPU có được dùng hết không trong lúc huấn luyện | | Thử nghiệm quy mô nhỏ | chạy một phần dữ liệu trên vài loại instance |

Dòng giữa đáng nhớ: profiling thường lộ ra GPU chỉ dùng 30–50% vì nghẽn ở khâu đọc dữ liệu — và khi đó, đổi sang GPU mạnh hơn không giúp gì; tối ưu I/O mới là việc cần làm.

Câu 159 ML Solution Monitoring, Maintenance, and Security

A technology company manages an application that performs data enrichment by integrating with various external APIs. To enhance security, the company must implement a solution to automatically rotate the API tokens used by the application every 90 days.

Which approach should the company use to meet this requirement?

  1. A

    Store the API tokens in AWS Secrets Manager. Use AWS Key Management Service (KMS) to encrypt the keys and configure automatic rotation of the keys
  2. B

    Store the API tokens in AWS Secrets Manager. Configure an AWS Lambda function to perform the token rotation
  3. C

    Store the API tokens in AWS Secrets Manager. Configure Managed Rotation to perform the token rotation automatically
  4. D

    Store the tokens in Parameter Store of AWS Systems Manager. Create an AWS Lambda function to perform the token rotation
Xem giải thích

Đáp án

B — Lưu API token trong AWS Secrets Manager, cấu hình một AWS Lambda function thực hiện việc xoay vòng token.

Vì sao đúng

Đề nêu yêu cầu: tự động xoay vòng token của API BÊN NGOÀI mỗi 90 ngày — và loại token đó là điểm quyết định.

Secrets Manager có hai chế độ xoay vòng, và chúng áp dụng cho hai loại secret khác nhau: | Chế độ | Áp dụng cho | Cần Lambda? | |---|---|---| | Managed rotation | CHỈ dịch vụ AWS: RDS, Aurora, Redshift, DocumentDB | ❌ AWS lo hết | | Lambda rotation function | MỌI loại secret khác — API bên thứ ba, khoá tuỳ chỉnh | ✅ |

Đề nói rõ đây là "API tokens used by the application" để tích hợp với "various external APIs" — tức là secret của bên thứ ba, nên phải dùng Lambda:

def lambda_handler(event, context):
    step = event['Step']
    if step == 'createSecret':
        token_moi = goi_api_ben_ngoai_tao_token()    # logic RIÊNG của API đó
        secrets.put_secret_value(SecretId=..., SecretString=token_moi,
                                 VersionStages=['AWSPENDING'])
    elif step == 'setSecret':
        kich_hoat_token_moi_o_ben_ngoai()
    elif step == 'testSecret':
        kiem_tra_token_moi_hoat_dong()
    elif step == 'finishSecret':
        secrets.update_secret_version_stage(...)      # AWSPENDING → AWSCURRENT

Vì sao managed rotation không dùng được: AWS không biết cách gọi API của bên thứ ba để tạo token mới — mỗi nhà cung cấp có quy trình riêng. Chỉ mã của bạn mới biết.

aws secretsmanager rotate-secret   --secret-id token-api-ben-ngoai   --rotation-lambda-arn arn:aws:lambda:...:function:xoay-vong-token   --rotation-rules AutomaticallyAfterDays=90

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

  • C. Lưu trong Secrets Manager, cấu hình Managed Rotation thực hiện xoay vòng tự động — đây là phương án gần nhất và là bẫy chính của câu hỏi: managed rotation chỉ hỗ trợ các cơ sở dữ liệu AWS, không hỗ trợ API bên thứ ba. Nghe rất hợp lý nhưng không áp dụng được cho loại secret trong đề.
  • A. Lưu trong Secrets Manager, dùng KMS mã hoá khoá và cấu hình xoay vòng KHOÁ — nhầm hai thứ hoàn toàn khác nhau: KMS key rotation xoay vòng khoá mã hoá dùng để bảo vệ secret, không xoay vòng bản thân secret. Token API vẫn giữ nguyên giá trị cũ.
  • D. Lưu token trong Parameter Store và tạo Lambda xoay vòng — Parameter Store không có cơ chế xoay vòng tích hợp: bạn phải tự dựng lịch, tự quản lý phiên bản, tự xử lý giai đoạn chuyển đổi. Secrets Manager có sẵn toàn bộ khung đó.

Ghi nhớ

So sánh Secrets Manager và Parameter Store: | | Secrets Manager | Parameter Store | |---|---|---| | Xoay vòng tự động | ✅ tích hợp | ❌ tự làm | | Mã hoá | KMS | KMS (SecureString) | | Sao chép chéo Region | ✅ | ❌ | | Chi phí | ~0,40 USD/secret/tháng | standard MIỄN PHÍ | | Dùng cho | bí mật cần xoay vòng | cấu hình, tham số |

Quy tắc chọn:

Cần xoay vòng → Secrets Manager. Chỉ là cấu hình → Parameter Store.

Bốn bước của một Lambda rotation function — cần nhớ đúng thứ tự: | Bước | Việc | |---|---| | createSecret | tạo giá trị mới, lưu ở stage AWSPENDING | | setSecret | kích hoạt giá trị mới ở hệ thống đích | | testSecret | kiểm tra giá trị mới hoạt động | | finishSecret | chuyển AWSPENDING → AWSCURRENT |

Bước testSecret là lý do quy trình có bốn bước thay vì một: nó đảm bảo không bao giờ chuyển sang token mới nếu token đó không hoạt động — tránh làm gián đoạn ứng dụng.

Ba stage của một secret: | Stage | Nghĩa | |---|---| | AWSCURRENT | giá trị đang dùng | | AWSPENDING | giá trị mới đang được kiểm tra | | AWSPREVIOUS | giá trị cũ — giữ lại để rollback |

Dòng cuối hữu ích: nếu phát hiện vấn đề sau khi xoay vòng, bạn quay lại giá trị trước mà không cần tạo token mới.

Và một mẫu thiết kế quan trọng cho ứng dụng dùng secret:

Đọc secret từ Secrets Manager LÚC CHẠY, đừng cache vĩnh viễn.

Nếu ứng dụng đọc token một lần lúc khởi động và giữ mãi, việc xoay vòng sẽ làm hỏng ứng dụng cho tới lần khởi động lại tiếp theo. Dùng AWS Parameters and Secrets Lambda Extension để cache có thời hạn — cân bằng giữa số lời gọi API và tính cập nhật.

Câu 160 Chọn nhiều đáp án ML Solution Monitoring, Maintenance, and Security

A financial services company is building an automated pipeline to update its fraud detection ML model every week using Amazon SageMaker Pipelines. The pipeline will consist of the following steps:

A data preprocessing step to clean and transform transactional data.

A model training step to build the fraud detection model.

An evaluation step to calculate accuracy and other metrics.

A model registration step to store the new model in the SageMaker Model Registry.

The preprocessing step involves large-scale data transformations and joins across multiple datasets stored in Amazon S3. The data transformations currently run on a distributed Amazon EMR cluster. The data science team wants to integrate these transformations into the SageMaker Pipelines workflow seamlessly.

Which options should be combined for a solution that addresses these requirements? (Select two)

  1. A

    Add a policy to the SageMaker Pipelines execution role to allow the role to invoke an Amazon EMR job flow
  2. B

    Set up an Amazon EMR job as the processing step of the SageMaker Pipelines workflow
  3. C

    Swap out the SageMaker Pipeline with AWS Step Functions as the ML workflow orchestration service
  4. D

    Set up an Amazon EMR job as a callback step of the SageMaker Pipelines workflow
  5. E

    Set up an Amazon EMR job as the first step of the ML workflow orchestrated by AWS Step Functions
Xem giải thích

Đáp án

A và D.

  • D — Thiết lập EMR job làm callback step của SageMaker Pipelines workflow
  • A — Thêm policy vào execution role của SageMaker Pipelines cho phép role đó gọi EMR job flow

Vì sao đúng

Đề nêu tình huống: các phép biến đổi dữ liệu quy mô lớn đang chạy trên cụm EMR, và đội muốn tích hợp liền mạch vào SageMaker Pipelines.

D — vì sao callback step là cơ chế đúng:

SageMaker Pipelines KHÔNG có step type cho EMR job. ProcessingStep chạy SageMaker Processing job, không chạy EMR.

Callback step là mẫu chuẩn để tạm dừng pipeline chờ hệ thống bên ngoài:

SageMaker Pipeline
    ↓ CallbackStep: gửi token vào SQS rồi TẠM DỪNG
       ↓
    Lambda nhận message → khởi động EMR job
       ↓ (EMR chạy, có thể hàng giờ)
    EMR xong → Lambda gọi SendPipelineExecutionStepSuccess(token)
       ↓
Pipeline TIẾP TỤC với dữ liệu đã xử lý

buoc_emr = CallbackStep(
    name='TienXuLyBangEMR',
    sqs_queue_url=url_hang_doi,
    inputs={'s3_input': duong_dan_nguon},
    outputs=[CallbackOutput(output_name='s3_output',
                            output_type=CallbackOutputTypeEnum.String)])

buoc_huan_luyen = TrainingStep(
    inputs={'training': buoc_emr.properties.Outputs['s3_output']})  # nối tiếp

A — quyền IAM là điều kiện bắt buộc: execution role của pipeline (hoặc của Lambda được nó gọi) phải có quyền khởi động EMR:

{"Effect": "Allow",
 "Action": ["elasticmapreduce:RunJobFlow",
            "elasticmapreduce:DescribeCluster",
            "elasticmapreduce:AddJobFlowSteps"],
 "Resource": "*"}

Hai đáp án bổ sung nhau: D là cơ chế, A là quyền để cơ chế đó chạy được.

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

  • B. Thiết lập EMR job làm PROCESSING STEP của SageMaker Pipelines — đây là phương án gần nhất và không tồn tại: ProcessingStep chỉ chạy SageMaker Processing job (một container trên instance SageMaker), không chạy được EMR job.
  • C. Thay SageMaker Pipeline bằng AWS Step Functions làm dịch vụ điều phối — thay đổi kiến trúc lớn không cần thiết: đề nói đội muốn tích hợp EMR vào SageMaker Pipelines đang có, không muốn bỏ nó. Và Step Functions mất lineage tracking tự động mà Pipelines cho sẵn.
  • E. Thiết lập EMR job làm bước đầu tiên của workflow do Step Functions điều phối — cùng vấn đề với C: nó thay công cụ điều phối thay vì tích hợp.

Ghi nhớ

Các step của SageMaker Pipelines: | Step | Chạy gì | |---|---| | ProcessingStep | SageMaker Processing job | | TrainingStep | SageMaker training job | | TuningStep | tinh chỉnh siêu tham số | | ConditionStep | rẽ nhánh theo điều kiện | | LambdaStep | Lambda — logic ngắn (≤ 15 phút) | | CallbackStep | TẠM DỪNG chờ hệ thống bên ngoài — không giới hạn thời gian |

Phân biệt hai step cuối: | | LambdaStep | CallbackStep | |---|---|---| | Thời gian | ≤ 15 phút | không giới hạn | | Cơ chế | gọi và chờ | gửi token, chờ được gọi lại | | Dùng cho | logic ngắn | EMR, Glue, hệ thống on-premises, chờ người |

Ba tình huống dùng CallbackStep: | Tình huống | Ví dụ | |---|---| | Job bên ngoài chạy lâu | EMR, Glue ← câu này | | Chờ người phê duyệt | gửi thông báo, chờ duyệt | | Gọi dịch vụ bên thứ ba | gọi API rồi chờ webhook |

Ba lợi ích của việc giữ mọi thứ trong MỘT pipeline: | Lợi ích | Chi tiết | |---|---| | Một lịch sử thực thi | thấy toàn bộ luồng ở một chỗ | | Phụ thuộc dữ liệu tường minh | bước sau nhận đầu ra của bước trước | | Lineage tự động | biết model sinh ra từ dữ liệu nào qua bước nào |

Và một điều bắt buộc phải chuẩn bị khi dùng CallbackStep:

Đặt timeout ở mức pipeline.

Nếu hệ thống bên ngoài chết mà không gọi lại token, pipeline sẽ treo vô hạn. Đặt TimeoutInSeconds dài hơn thời gian chạy EMR tối đa dự kiến, và có cơ chế xử lý khi hết hạn.