MLA-3.2既存のアーキテクチャと要件に基づいてインフラストラクチャを作成し、スクリプト化する。
採点する
2問中 0問が回答されています
質問:
インフォメーション
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
結果
結果
正解数 0/問題数2
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
カテゴリー
- MLA-3.2既存のアーキテクチャと要件に基づいてインフラストラクチャを作成し、スクリプト化する。 0%
- 1
- 2
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 2
1. 質問
カテゴリ: MLA-3.2既存のアーキテクチャと要件に基づいてインフラストラクチャを作成し、スクリプト化する。【MLA-55】金融 SaaS 企業は SageMaker Pipelines で学習したモデルを SageMaker Model Registry に登録し、承認済みバージョンのみを CodePipeline で自動デプロイしたい。
要件は
①CodePipeline の IAM ロールは s3://fin-prod-model/ 内の承認済みモデルだけを取得できること、
②トレーニングデータ格納先 s3://fin-prod-data/ には一切アクセスできないこと、
③データサイエンティストはモデルの登録・承認は行えるが削除はできないこと、である。
最も適切な設計はどれか。正解不正解ヒントボタン
要件①では CodePipeline の IAM ロールが s3://fin-prod-model/ 配下だけを読めれば十分です。AmazonS3ReadOnlyAccess のような広範な権限を付けると fin-prod-data も閲覧できてしまうので、カスタムポリシーで s3:GetObject を対象 ARN に限定するのが最小権限原則を守る最適解になります。さらにバケットポリシーまで最小化しておくと監査が容易になり運用負荷も下がります。CI/CD で誤って余計な場所を読み取る事故も防げ、セキュリティチームの承認も得やすくなります。
SageMaker Model Registry にはモデルパッケージのステータス変更時に EventBridge へイベントを出す機能があります。Approved になった瞬間をトリガに Lambda を起動し、承認済みバージョンの S3 URI を Systems Manager Parameter Store に書き込んでおけば、CodePipeline はそのパラメータだけを読み込み自動デプロイできます。直接最新ファイルを参照する方法よりも誤配備リスクを排除できる堅牢な仕組みです。さらに変更履歴を Parameter Store のバージョニングで追跡できる利点もあります。
データサイエンティストには sagemaker:CreateModelPackage と sagemaker:UpdateModelPackage を許可しつつ sagemaker:DeleteModelPackage を明示的に Deny する IAM ポリシーを用意すれば要件③を満たせます。ECR へ転送したり手動操作に頼る案は S3 URI を前提とした Model Registry 連携や自動化目標を損ないます。最小権限設計・イベント駆動・間接パラメータ参照の三点を統合的に考えると自然に最適な構成が導かれます。将来の監査や拡張にもスムーズに対応できます。
-
質問 2 of 2
2. 質問
カテゴリ: MLA-3.2既存のアーキテクチャと要件に基づいてインフラストラクチャを作成し、スクリプト化する。【MLA-56】流通小売企業Ａ社は、日次で更新される推論モデルを Amazon SageMaker エンドポイント（VPC 内）で公開し、ピーク時 2,000 req/s・P95 レイテンシ 150 ms を必須とします。
モデル tar.gz は S3、推論コンテナは自社 ECR に格納済みです。
Infrastructure as Code でデプロイを統合管理し、エンドポイントが InService にならなければ自動ロールバックし、インスタンス数を 1〜10 台で自動スケールさせたいと考えています。
最小の運用負荷で AWS ベストプラクティスに沿う CloudFormation テンプレート設計はどれですか。正解不正解ヒントボタン
日次リリースを完全自動化するには、CloudFormation で AWS::SageMaker::Model・EndpointConfig・Endpoint を同一スタックに含め、S3 の tar.gz と ECR の推論コンテナをバージョンタグでパラメータ化します。Endpoint には CreationPolicy と cfn-signal を設定し、ステータスが InService になるまでデプロイをブロックさせることで、異常時は自動ロールバックが走りヒューマンオペレーションを排除できます。
ピーク 2,000 req/s と 150 ms レイテンシを両立するには、同じテンプレート内に AWS::ApplicationAutoScaling::ScalableTarget と ScalingPolicy を設け、SageMaker インスタンスを最小 1・最大 10 に水平スケールさせる構成が適しています。ターゲット追跡型ポリシーを CloudWatchmetrics:InvocationsPerInstance に紐づければ、需要変動に追従しつつコストも最適化でき、SLA を維持できます。
総合的には、ネイティブリソースで構成を完結させることで IaC によるドリフト検知、CreationPolicy での安全なローリング更新、Application Auto Scaling での動的キャパシティ確保が同時に満たされます。これらを一枚の CloudFormation テンプレートに集約する設計が最小運用負荷かつ AWS ベストプラクティスに沿うアプローチです。
改善リクエスト