DOP-C02 練習問題 6

あるDevOpsエンジニアが、複数のAmazon EC2インスタンスを含むネストされたスタック（nested stack）を追加するために、AWS CloudFormationスタックを更新しています。DevOpsエンジニアが更新されたスタックをデプロイしようとすると、ネストされたスタックのデプロイが失敗します。 DevOpsエンジニアが失敗の原因を特定するには、何をすべきですか？

【正解】B

【0からの解説】
ネストされたスタックは、親（ルート）スタックの中から子スタックを呼び出す入れ子構造です。子スタックが失敗すると親スタックも失敗しますが、本当の失敗理由（どのリソースで何が起きたか）は子スタック側のイベントに記録されています。

失敗原因を特定する正攻法は、CloudFormationのスタックイベントを調べることです。具体的には DescribeStacks や ListStacks でスタックを照会し、ネストされたスタックを ParentId（親スタックのID）で絞り込み、各スタックの StackStatusReason（ステータス理由）を確認します。StackStatusReason には「このリソースがこういう理由で失敗した」という具体的なメッセージが入るため、ここからEC2作成失敗などの根本原因に辿り着けます。これがBであり、CloudFormationが標準で提供する正規の調査手段です。

【誤りの選択肢】
A：「detect root cause」という名称のCloudFormation機能は存在しない（ドリフト検出 detect drift とは別物）。実在しない機能を指しており誤り。
C：AWS-SupportTroubleshootCFNCustomResource は“カスタムリソース”のトラブルシュート用ランブックであり、EC2インスタンスを含む通常リソースのネストスタック失敗の調査には対象が合わない。
D：CloudFormation自体はスタックの詳細ログをCloudWatchへ自動発行する仕組みを標準では持たない（個々のリソースのログはあっても、スタックの失敗理由はスタックイベントに出る）。設定も曖昧で正攻法ではない。
B：ParentId で子スタックを特定し StackStatusReason を確認するのが、ネストスタック失敗原因を特定する標準手順。

【参考】
Working with nested stacks
DescribeStacks - AWS CloudFormation API
Troubleshooting CloudFormation