AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

正解

A. AWS::AccountId 疑似パラメータを Ref 関数で参照し、タグの値として設定する

疑似パラメータは CloudFormation がすべてのテンプレートに組み込みで提供する変数で、Parameters セクションでの宣言も事前準備も一切不要です。
AWS::AccountId は「そのスタックが作成されているアカウントの AWS アカウント ID」を返すため、同じテンプレートをどのアカウントへ流し込んでも、そのアカウント自身の ID がタグ値として解決されます。
テンプレートは 1 本のまま、アカウントが増えても追加作業がゼロ。「テンプレートを変更することなく」「運用上最も効率的」の両方を同時に満たす唯一の選択肢です。

B. 事前に各アカウントの AWS Systems Manager パラメータストアへアカウント ID を登録しておき、テンプレート内で動的参照（ssm 修飾子）を使って値を取得する

動的参照（ssm 修飾子）でパラメータストアの値を読む構成自体は正しく動きますが、デプロイ先アカウントごとに事前にパラメータを登録しておく作業が必要になります。
アカウントを 1 つ増やすたびに登録漏れが事故の原因になり、登録された値が実際のアカウント ID と食い違っても CloudFormation は検知できません。
CloudFormation が無料で正確な値を提供しているのに、同じ情報を二重管理するぶんだけ運用負荷が増えるため不適です。

C. Mappings セクションにアカウント ID をキーとする対応表を定義し、Fn::FindInMap 関数で値を選択する

Mappings はテンプレート内に静的な対応表を書く仕組みなので、アカウントが増えるたびにテンプレート自体を編集することになり、「テンプレートを変更することなく」という要件に真っ向から反します。
さらに Fn::FindInMap は引くためのキーが必要で、そのキーとして結局アカウント ID を得なければならず、論理が堂々巡りになります。
Mappings が活きるのは「リージョンごとに AMI ID を切り替える」ような、外部から与えられたキーで値を選ぶ場面です。

D. カスタムリソース用の AWS Lambda 関数を実装し、関数内で AWS STS の GetCallerIdentity API を呼び出した結果をテンプレートへ反映する

カスタムリソースで Lambda を呼べば GetCallerIdentity の結果を取得できますが、そのためにはデプロイ先の全アカウントに Lambda 関数と実行ロールを先に用意し、成功・失敗・削除の各シグナルを CloudFormation へ返す実装まで書く必要があります。
カスタムリソースが応答を返さなければスタックはタイムアウトまで停止し、障害点が一つ増えます。
組み込みの疑似パラメータ 1 行で得られる値のために払うコストとしては明らかに過剰で、「運用上最も効率的」から最も遠い選択肢です。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
各スタックが作成された AWS アカウントの ID が欲しい	CloudFormation の疑似パラメータ AWS::AccountId が、まさに「スタックが作成されているアカウントの ID」を返す →選択肢（A）が正解
テンプレートを変更することなく（1 本のテンプレートを使い回す）	Mappings は表をテンプレート内に持つため、アカウント追加のたびにテンプレート編集が発生する →選択肢（C）を消す
複数の AWS アカウントへ横展開する（対象が増えていく前提）	デプロイ先ごとの事前準備（パラメータ登録・Lambda 配置）を要する案は、アカウントが増えるほど運用が重くなる →選択肢（B・D）を消す
運用上最も効率的な方法（判断軸）	疑似パラメータは宣言不要・事前準備不要・追加コストなし。同じ値を自作の仕組みで取りにいくのは二重管理 →選択肢（A）が正解／選択肢（B・D）を消す

ひっかけポイント

• 選択肢 B・D は「実際に動く」構成なので技術的な誤りを探しても見つからない。落とす根拠は動くかどうかではなく、事前準備がデプロイ先アカウントの数だけ増えるという運用効率の一点
• 選択肢 C は循環しているのが見抜きどころ。Fn::FindInMap で「アカウント ID をキーに引く」には、先にアカウント ID を知っている必要がある
• 疑似パラメータは Parameters セクションに書いてはいけない（宣言せずにそのまま Ref で参照する）。「パラメータ」の語感から宣言が要ると思い込ませるのが定番のひっかけ
• 選択肢 D の GetCallerIdentity はAPI 単体としては正しいアカウント ID の取得手段。正しい API 名が出てきても、それをカスタムリソースで呼ぶ必要があるかは別問題

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「テンプレートをデプロイしたリージョン名をタグに入れたい」	同じ疑似パラメータの AWS::Region が正解。考え方は完全に同じ。
「リージョンごとに異なる AMI ID を選びたい」	Mappings + Fn::FindInMap（キーは AWS::Region）が正解軸に。選択肢 C の構成が正しくなる場面。
「DB のパスワードをテンプレートに直書きせず渡したい」	AWS Secrets Manager の動的参照が正解。値が環境ごとに違い、かつ秘密である場合は動的参照の出番。
「CloudFormation が標準サポートしないリソースや外部システムを操作したい」	カスタムリソース（Lambda 支援）が正解軸に。選択肢 D が正しくなる唯一の場面。
「複数アカウント・複数リージョンへ一括でスタックを展開したい」	CloudFormation StackSets が正解に。疑似パラメータと組み合わせると各アカウント固有の値が自動で入る。

関連サービスの解説

AWS CloudFormation
AWS Systems Manager

リファレンス

この問題を解くために必要な知識を扱う公式ドキュメントです。

知識項目	公式ドキュメント
CloudFormation の疑似パラメータ（AWS::AccountId）	擬似パラメータを使用して AWS 値を取得する