SAA-002
Lambda関数がDynamoDBテーブルに問い合わせデータを書き込む必要があります。最小権限の原則に最も合うIAMポリシーはどれですか？
選択肢
解説と正解
解説と正解を読む（先に自分で回答してから開くのがおすすめです）
正解：D. 対象テーブルに対するdynamodb:PutItemのみを許可する
解説
Lambdaが問い合わせ保存だけを行うなら、対象DynamoDBテーブルへのPutItemだけを許可するのが最小権限です。
選択肢ごとの解説
A. Lambda実行ロールにAdministratorAccessを付与する
AdministratorAccessは権限が広すぎます。
B. DynamoDBへのアクセスキーをLambda環境変数に保存する
AWS認証情報を環境変数に保存する設計は避けるべきです。Lambda実行ロールを使います。
C. すべてのDynamoDBテーブルに対するdynamodb:*を許可する
dynamodb:*は権限過多です。
D. 対象テーブルに対するdynamodb:PutItemのみを許可する
正解です。対象テーブルと必要な操作に限定しています。
実務での使いどころ
Lambda 実行ロールに付与する IAM ポリシーは、関数が実際に必要とする操作と対象リソースだけに限定するのが最小権限の原則である。問い合わせを DynamoDB の特定テーブルに書き込むだけの関数であれば、Action は `dynamodb:PutItem` のみ、Resource は対象テーブルの ARN のみに絞ったポリシーが適切となる。`dynamodb:*` や AdministratorAccess を付与すると、関数が侵害された場合の影響範囲が一気に広がるため避ける。 実務でやりがちな反パターンとしては、AWS のアクセスキー（IAM ユーザーの長期認証情報）を Lambda の環境変数に保存する設計がある。Lambda は実行ロールを通じて自動的に一時的な認証情報を受け取れるため、長期キーをコードや環境変数に持ち込む必要はない。長期キーは漏洩時のローテーション運用も発生し、IAM Access Analyzer や CloudTrail での追跡も難しくなる。Secrets Manager や Parameter Store と組み合わせる場合も、保存対象は外部システム（DB の DSN、外部 API キー等）に限定し、AWS への認証はロールに任せるのが基本となる。 SAA-C03 では「最小権限」「IAM ロール vs アクセスキー」「Resource を ARN レベルで絞る」という観点が頻出する。誤答パターンは、ワイルドカード Action、AdministratorAccess、Lambda 環境変数へのアクセスキー保存などで、いずれも最小権限・ベストプラクティスに反するため除外できる。さらに上位の出題では、Condition で送信元 VPC エンドポイントや MFA を縛る、IAM Access Analyzer で実際の利用権限をモニタリングするといった発展も問われる。