AWS認定資格 WEB問題集＆徹底解説
デベロッパー–アソシエイト
問題文と選択肢
これらの要件を満たすソリューションはどれですか。
- データベース認証情報を Amazon Machine Image (AMI) の環境変数に保存する。AMI を置き換えて認証情報をローテーションする。
- データベース認証情報を AWS Systems Manager Parameter Store に保存する。認証情報を自動的にローテーションするように Parameter Store を設定する。
- データベース認証情報を EC2 インスタンスの環境変数に保存する。EC2 インスタンスを再起動して認証情報をローテーションする。
- データベース認証情報を AWS Secrets Manager に保存する。認証情報を自動的にローテーションするように Secrets Manager を設定する。
A. データベース認証情報を Amazon Machine Image (AMI) の環境変数に保存する。AMI を置き換えて認証情報をローテーションする。
AMI の環境変数に認証情報を焼き込む方式は、AMI を参照できる相手に平文の認証情報が渡ってしまうため、そもそも安全な保存方法ではない。
さらにローテーションのたびに AMI を作り直してインスタンスを入れ替える必要があり、「自動的にローテーションする」という要件を満たさない。
ソースコードへのハードコードを AMI に移し替えただけで、問題の本質は解決していない。
B. データベース認証情報を AWS Systems Manager Parameter Store に保存する。認証情報を自動的にローテーションするように Parameter Store を設定する。
AWS Systems Manager Parameter Store は SecureString でパラメータを暗号化保存できるが、認証情報を自動ローテーションする機能は標準では備えていない。
ローテーションを実現するには、値を更新する Lambda 関数と EventBridge スケジュールを自分で実装・運用する必要があり、「追加のカスタム実装なし」という要件に反する。
「保存はできるがローテーションはできない」という点が、Secrets Manager との最大の違い。
C. データベース認証情報を EC2 インスタンスの環境変数に保存する。EC2 インスタンスを再起動して認証情報をローテーションする。
EC2 インスタンスの環境変数に認証情報を置くと、インスタンスにログインできる利用者やプロセスから平文で読み取れてしまう。
また「再起動してローテーションする」というのは手動運用そのもので、自動ローテーションではない。
安全性・自動化の両方の要件を同時に満たせない。
D. データベース認証情報を AWS Secrets Manager に保存する。認証情報を自動的にローテーションするように Secrets Manager を設定する。
AWS Secrets Manager は、シークレットの暗号化保存（AWS KMS 連携）・きめ細かなアクセス制御・自動ローテーションを備えたシークレット管理の専用サービス。
Amazon RDS などのデータベースについてはローテーション用の Lambda 関数が AWS から提供され、ローテーション周期を設定するだけで認証情報の入れ替えが自動化される（RDS 側のパスワードも同時に更新される）。
アプリケーションは実行時に API でシークレットを取得すればよく、ソースコードからも AMI からも認証情報を排除できるため、要件を完全に満たす唯一の選択肢。
「自動ローテーション」と書かれたら Secrets Manager。Parameter Store は保存はできてもローテーションは自作。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 認証情報を安全に保存する | 環境変数や AMI への埋め込みは平文で参照可能で、保存場所を変えただけの対策にすぎない →選択肢（A・C）を消す |
| 認証情報を自動的にローテーションする | AMI の作り直し・インスタンス再起動は手動運用であり、自動ローテーションではない →選択肢（A・C）を消す |
| 追加のカスタム実装なしで実現する | Parameter Store は保存はできてもローテーション機能を標準で持たない（Lambda の自作が必要） →選択肢（B）を消す |
| 対象は Amazon RDS for MySQL の認証情報 | Secrets Manager は RDS 向けのローテーション用 Lambda を AWS が提供しており、設定だけで自動ローテーションできる →選択肢（D）が正解 |
ひっかけポイント
- 選択肢 B の「認証情報を自動的にローテーションするように Parameter Store を設定する」は、存在しない設定を自然な日本語で書いた典型的なひっかけ。Parameter Store に自動ローテーションのスイッチはない
- Parameter Store と Secrets Manager は「暗号化して保存する」点は同じ。差が出るのはローテーションと、RDS 等との統合。逆に単純な設定値の保存なら Parameter Store の方が安価で有利
- 「環境変数に保存する」は一見モダンに見えるが、AWS の文脈では平文の長期認証情報を持ち回ることと同義。AMI・EC2 いずれの環境変数でも評価は同じ
- ローテーション＝「再起動」「AMI 置き換え」といった人手の作業を伴う言い換えが誤答に混ぜられる。自動化されているかを必ず確認する
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「認証情報ではなく、API のエンドポイント URL や環境ごとの設定値を保存したい（コスト重視）」 | Systems Manager Parameter Store が正解軸に。無料枠のある標準パラメータで十分。 |
| 「ローテーションは不要だが、値は暗号化して保存したい」 | Parameter Store の SecureString が正解になり得る（Secrets Manager は過剰）。 |
| 「RDS ではなくサードパーティ API のキーを独自ロジックでローテーションしたい」 | Secrets Manager のカスタムローテーション Lambda を実装する構成が問われる。 |
| 「EC2 上のアプリが AWS サービス（S3 や DynamoDB）にアクセスするための認証情報が欲しい」 | そもそもシークレット保存は不要で、IAM ロール（インスタンスプロファイル）が正解軸に。 |
これらの要件を満たすソリューションはどれですか。
- データベース認証情報を Amazon Machine Image (AMI) の環境変数に保存する。AMI を置き換えて認証情報をローテーションする。
- データベース認証情報を AWS Systems Manager Parameter Store に保存する。認証情報を自動的にローテーションするように Parameter Store を設定する。
- データベース認証情報を EC2 インスタンスの環境変数に保存する。EC2 インスタンスを再起動して認証情報をローテーションする。
- データベース認証情報を AWS Secrets Manager に保存する。認証情報を自動的にローテーションするように Secrets Manager を設定する。