Q1 — 単一選択企業は1つのOCIコンテナイメージを、チームAではAWS独自APIのオーケストレーション、チームBではKubernetes APIで実行したい。両チームで同じプライベートイメージ保管先を共有し、必要に応じてサーバー管理を減らす実行方式も選択できる設計にしたい。サービスの役割を正しく整理したものはどれか。
A. Amazon ECRをオーケストレーター、Amazon ECSとAmazon EKSをイメージレジストリ、AWS Fargateをロードバランサーとして整理する
B. Amazon ECSをレジストリ、Amazon EKSをサーバーレスコンピューティング、Amazon ECRとAWS FargateをKubernetesコントロールプレーンとして整理する
C. Amazon ECRを共通イメージレジストリ、Amazon ECSとAmazon EKSを異なるAPIモデルのオーケストレーター、AWS Fargateを両方で選択できるサーバーレスコンピューティングとして整理する
D. AWS Fargateをイメージレジストリ、Amazon ECRをコンピューティング、Amazon ECSとAmazon EKSを共有ストレージとして整理する
答えと解説
答え：C
Amazon ECRはコンテナイメージを保存するレジストリです。Amazon ECSとAmazon EKSはそれぞれ異なるAPIモデルでコンテナをオーケストレーションし、AWS Fargateは両方で利用できるサーバーレスコンピューティングを提供します。
Q2 — 単一選択Amazon ECSで実行するコンテナがGPUを必須とします。チームはAmazon ECSを維持しながら、基盤インスタンスのプロビジョニング、パッチ適用、スケーリングの管理負荷もできるだけ減らしたいと考えています。
最も適切な候補はどれですか。
A. AWS Fargateを使用し、Fargateタスク定義でgpuパラメータを指定してGPUを割り当てる
B. Amazon ECSマネージドインスタンスを評価し、GPU対応のEC2キャパシティをAWS管理で利用する
C. Amazon ECRへGPU対応タグを付けたイメージを保存し、レジストリ側でGPUキャパシティを提供する
D. Amazon EKS Fargateへ変更すれば、Kubernetesへの移行によってFargateでGPUを利用できるようになる
答えと解説
答え：B
FargateではGPUを利用できません。Amazon ECSマネージドインスタンスではAmazon ECSを維持しながら、GPUなどのEC2機能を利用し、基盤のプロビジョニングやパッチ適用などをAWSへ委任できます。
Q3 — 単一選択Amazon EKSへ移行するKubernetesワークロードには、各ノードで動作するDaemonSetとprivilegedコンテナを必要とするセキュリティエージェントがあります。チームはすべてのPodをAWS Fargateへ移そうとしています。
最も適切な判断はどれですか。
A. AWS FargateはDaemonSetとprivilegedコンテナをサポートしないため、要件を満たすノードベースのAmazon EKSコンピューティングを評価する
B. AWS Fargateへ移行し、DaemonSetはFargateが自動的に各Podのサイドカーへ変換すると想定する
C. Amazon ECRへセキュリティエージェントを保存すれば、Fargate上でもprivilegedアクセスが有効になると想定する
D. Amazon ECS Fargateへ変更すれば、KubernetesのDaemonSetとprivilegedコンテナをそのまま実行できると想定する
答えと解説
答え：A
EKS FargateではDaemonSetとprivilegedコンテナをサポートしません。Kubernetesを維持する必要があるなら、Amazon EKS自体を変更するのではなく、要件を満たせるノードベースのコンピューティングを評価します。
Q4 — 単一選択現在Amazon ECSで稼働するアプリケーションは、AWS上のプライベートレジストリにOCIイメージを保存している。今後、一部ワークロードだけをAmazon EKSへ移すが、イメージのビルドパイプラインと脆弱性スキャンは共通化したままにしたい。既存イメージは移行先のOS/CPUアーキテクチャと互換性がある。変更範囲を最小化する判断として最も適切なのはどれか。
A. Amazon ECRを共通レジストリとして継続利用し、EKS側のイメージ取得権限を構成する
B. Amazon EKSへ変更する場合はAmazon ECRを廃止し、Kubernetes専用レジストリへ必ず移行する
C. Amazon ECRのイメージはAmazon ECSからしか利用できないため、EKS用の別形式へ変換して別レジストリへ保存する
D. Amazon ECRを利用すればOSやCPUアーキテクチャの差異も自動変換されるため、移行先との互換性確認は不要である
答えと解説
答え：A
Amazon ECRのイメージはAmazon ECSだけでなくAmazon EKSからも利用できます。オーケストレーター変更だけを理由にレジストリを変更する必要はありません。EKS側のIAM権限と、イメージのOS/CPUアーキテクチャ互換性は別途確認します。
Q5 — 単一選択現在、アプリケーションをAmazon ECS on AWS Fargateで実行し、コンテナイメージはAmazon ECRに保存しています。新しい要件としてKubernetes API、DaemonSet、privilegedコンテナが必要になりました。既存イメージはLinux/CPUアーキテクチャの互換性を満たしています。
変更範囲を必要最小限にしながら要件を満たすターゲット構成はどれですか。
A. Amazon ECRは維持し、オーケストレーターをAmazon EKSへ変更してノードベースのコンピューティングを使用する
B. Amazon ECRは維持し、Amazon ECS on AWS FargateのままDaemonSetとprivilegedコンテナを有効化する
C. Amazon ECRを廃止して別レジストリへ変更すれば、Amazon ECS on AWS FargateでKubernetes APIを利用できる
D. Amazon ECRに保存済みのイメージを維持するには、オーケストレーターとコンピューティングもAmazon ECS on AWS Fargateのままにする
答えと解説
答え：A
要件変更はオーケストレーターとコンピューティングのレイヤーに影響します。Kubernetes APIを利用するためAmazon EKSへ変更し、DaemonSetとprivilegedコンテナを必要とするためノードベースのコンピューティングを選びます。一方、互換性を満たすコンテナイメージはAmazon ECRに継続して保存できます。