Secrets Manager（Lambdaローテーションの挙動）難易度 標準無料
AWS Secrets ManagerでRDS認証情報の自動ローテーションを有効化した。ローテーションの仕組みとアプリケーション側の設計について正しい記述を2つ選べ。
- AローテーションLambdaは
createSecret/setSecret/testSecret/finishSecretの4ステップで新しい認証情報の生成・設定・検証・確定を行う。RDS/Aurora/Redshift等向けにはAWS提供のローテーションテンプレートがあり、自前でこの4ステップを実装しなくてよい - Bアプリケーションはローテーションのたびに必ず再デプロイし、新しい認証情報をコードへ焼き込み直す必要がある
- Cアプリケーションは実行時に
GetSecretValueで都度シークレットを取得する設計にしておけば、裏側でローテーションされても再デプロイ無しに新しい認証情報へ追従できる - DSystems Manager Parameter Storeの
SecureStringパラメータも、Secrets Managerと同じ組み込みのDB向けローテーションLambdaテンプレートをネイティブにサポートする
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
Secrets Managerのローテーションは、ローテーションLambda関数が
createSecret → setSecret → testSecret → finishSecret の4ステップを実行して、
新しい認証情報の生成・DB側への設定・接続検証・確定（バージョンラベルの切り替え）を行う。
RDS/Aurora/Redshift/DocumentDB向けにはAWSが提供する組み込みのローテーションテンプレートがあり、これをそのまま使える。
アプリケーション側は、認証情報を起動時にキャッシュして固定するのではなく、
実行のたびに（あるいは適切な間隔でキャッシュしつつ）secretsmanager:GetSecretValue を呼び出す設計にしておけば、
裏側でローテーションが行われてもコードの変更・再デプロイ無しに新しい認証情報へ自然に追従できる。
- BSecrets Managerを使う利点は、再デプロイ無しでローテーションに追従できる点。アプリが実行時に
GetSecretValueを呼ぶ設計にしておけば再デプロイは不要。 - DParameter Storeにはこの種の組み込みDB向けローテーション機構は無い。ローテーションが必要ならSecrets Managerを使うか、自前でLambda・スケジュールを実装する必要がある。
ひっかけ： 「ローテーションのたびに再デプロイが必要（B）」は、Secrets Managerを使う目的（無停止・無変更でのローテーション）を理解していないと誤答しやすい。
また「Parameter StoreもSecrets Managerと同じ組み込みローテーションテンプレートをネイティブに持つ（D）」も頻出の誤解。
DB向け組み込みローテーションテンプレートはSecrets Manager固有の機能である。
公式ドキュメント・関連AWS Secrets Manager User Guide ― How rotation works↗AWS Secrets Manager User Guide ― Retrieve secrets↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）