Secrets Manager vs Parameter Store難易度 標準無料
Amazon RDS for MySQLのマスターユーザー認証情報を、30日ごとに自動でローテーションさせ、アプリケーションはコード変更・再デプロイ無しに常に最新の認証情報を取得できるようにしたい。追加のLambda実装を極力書かずに実現する方法として最も適切なものを選べ。（単一選択）
- A認証情報をSystems Manager Parameter Storeの
SecureStringとして保存し、KMSで暗号化しておけば自動的に30日ごとローテーションされる - B認証情報をSecrets Managerに保存し、RDS向けの組み込みローテーションテンプレートを使ってローテーションを有効化する。ローテーション期間を30日に設定し、アプリケーションは実行時に
GetSecretValueで常に最新の認証情報を取得する - C認証情報をKMSで暗号化してS3オブジェクトとして保存し、S3のライフサイクルポリシーで30日ごとに新しい認証情報へ差し替える
- D認証情報をLambda関数の環境変数としてKMSで暗号化し、Lambdaのデプロイ時に手動で30日ごと更新する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：BAI作成・独立検証済
解説
AWS Secrets Managerは、RDS（MySQL/PostgreSQL/Oracle等）・Redshift・DocumentDBなど主要データベース向けに 組み込みのローテーションLambdaテンプレートを提供しており、コンソールで有効化するだけで 指定した日数（例：30日）ごとに自動でDBパスワードをローテーションできる。
- ローテーションされた新しい認証情報はSecretsManagerのシークレットとして保存され、アプリケーションは実行のたびに
GetSecretValueで最新値を取得する設計にしておけば、ローテーション後も再デプロイ不要で追従できる。 - 一方 Systems Manager Parameter Store（
SecureString）はKMSで暗号化した値を保管する機能は持つが、 DB認証情報向けの組み込み自動ローテーション機構は持たない。ローテーションを実現するには自前でLambda・EventBridgeスケジュールを組む必要がある。
「DB認証情報を自動ローテーションしたい」という要件は、Secrets Managerがまさに設計目的とする領域である。
- AParameter Storeは暗号化保管はできるが、DB認証情報向けの組み込み自動ローテーション機能は持たない。自動ローテーションが目的ならSecrets Managerが適する。
- CS3のライフサイクルポリシーはオブジェクトの保管クラス移行・削除の機能であり、シークレットのローテーション（新しい値の生成・DB側への反映・整合性確保）を行う仕組みではない。
- D手動デプロイでの更新は自動化要件を満たさず、認証情報が環境変数に固定されることで漏えい・追従漏れのリスクも高い。
ひっかけ： 「Parameter StoreのSecureStringも暗号化できるから同じことができる（A）」という思い込みが罠。暗号化保管の機能はあるが、
DB向け組み込みローテーションはSecrets Manager固有の機能であり、Parameter Storeには標準搭載されていない。
公式ドキュメント・関連AWS Secrets Manager User Guide ― Rotating AWS Secrets Manager secrets↗AWS Secrets Manager User Guide ― Rotate database credentials↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）