IAMロールの説明として最も適切なものはどれですか？

解説

IAMロールは、AWSサービスやユーザーなどに一時的な認証情報を使って権限を付与する仕組みです。

選択肢ごとの解説

実務での使いどころ

IAM ロールは、AWS リソースや利用者に対して一時的な認証情報を発行する形で権限を付与 する仕組みである。IAM ユーザーが「人」に紐づく永続的なクレデンシャル（パスワード / アクセスキー）を持つのに対し、IAM ロールはエンティティに紐づかず、必要なタイミングで AssumeRole することで一時的なクレデンシャル(STS が発行するアクセスキー ID / シーク レットアクセスキー / セッショントークン)が払い出される。発行された認証情報には 有効期限が設定されており、漏えい時の影響範囲が時間軸で制限される点が、長期間有効な アクセスキーと比較した最大の利点である。 実務での代表的な利用パターンは 3 つある。1 つ目は EC2 インスタンスプロファイルで、 EC2 上で動くアプリケーションから S3 や DynamoDB を操作する際に、アクセスキーを コードや環境変数に埋め込まず IAM ロール経由で権限を取得する構成である。2 つ目は Lambda 実行ロールで、Lambda 関数が他の AWS サービスにアクセスする際の認証に使う。 3 つ目はクロスアカウントアクセスで、別 AWS アカウントの IAM ユーザーやロールに AssumeRole を許可することで、長期クレデンシャルを共有せずにアカウント間連携を実現 する。Identity Center（旧 SSO）や Cognito も、内部的には IAM ロールの一時クレデン シャル発行機構を利用している。 CLF-C02 では、「IAM ロールの説明として最も適切なものはどれか」「アクセスキーを使わず EC2 から S3 にアクセスする方法は何か」という形で問われる。誤答として「画像圧縮 サービス」「メトリクス表示」「ドメイン登録機能」のように、IAM とは別領域のサービスを 当て込んでくるパターンが多い。SAA-C03 以降では、IAM ユーザー / グループ / ロール / ポリシーの使い分け、信頼ポリシーとアクセス許可ポリシーの違い、AssumeRole の認可 フローまで踏み込んで出題される。