解説

クロスアカウントアクセスはSTS AssumeRoleで実現します。アカウントBにIAMロールを作成して信頼ポリシーでアカウントAのLambda実行ロールを信頼エンティティとして設定し、アカウントAのLambda実行ロールにsts:AssumeRole権限を付与してコード内でassumeRoleを呼び出します。取得した一時認証情報でアカウントBのDynamoDBにアクセスします。 選択肢A（アカウントBのIAMロール作成）: 信頼ポリシーでアカウントAのLambda実行ロールARNをプリンシパルとして設定することでクロスアカウントのAssumeRoleが許可されます。長期認証情報を使用せず最小権限を維持できる正しい手法です。 選択肢B（sts:AssumeRole権限の付与）: Lambda実行ロールにsts:AssumeRole権限を持たせ、コード内でアカウントBのロールを引き受けて一時認証情報を取得します。一時認証情報は短期間で失効するため長期認証情報よりセキュアです。 選択肢C（リソースベースポリシーへのアクセスキーID記述）: IAMポリシーのプリンシパルにはIAM ARNを指定するものであり、アクセスキーIDを記述することはできません。仮にDynamoDBリソースベースポリシーを使用する場合でも、Lambda実行ロールのARNで制御します。 選択肢D（ルートユーザーの認証情報を環境変数に設定）: ルートユーザーの認証情報の使用はAWSのセキュリティベストプラクティスに絶対に反します。環境変数への長期認証情報の設定も認証情報漏洩リスクが高く、最小権限の原則にも違反します。