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

DevOpsエンジニア-プロフェッショナル

正解 A,D問題
分野5：インシデントとイベントへの対応 タスクステートメント5.3：システムおよびアプリケーション障害のトラブルシューティング
要復習（もう一度解きたい問題） 1 2 3 4
次の問題
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
ある物流会社は、注文管理システムの高可用性キャッシュ層としてAmazon ElastiCacheクラスターをAWS CloudFormationスタックで管理しています。テンプレートの更新を適用した際にエラーが発生し、CloudFormationは自動的にロールバック処理を開始しました。ところが、直前に運用チームがマネジメントコンソールから対象のキャッシュクラスターを手動で削除していたため、CloudFormationはロールバック先のリソースを見つけられずロールバックが完了せず、スタックはUPDATE_ROLLBACK_FAILED状態のまま停止しています。

DevOpsエンジニアがこのスタックを正常な状態（UPDATE_ROLLBACK_COMPLETE）に戻すために取るべきアクションを2つ選んでください。
  • 削除されたキャッシュクラスターをスタックが想定する状態に一致するよう手動で作成し直すか、スタック定義と整合するように修正する。
  • AWS CloudFormation StackSetsを使って対象リージョンのスタックを自動的に再作成し、問題を解消する。
  • スタックポリシーを一時的に解除してCloudFormationにリソースの強制再作成権限を付与し、自動ロールバックを再実行させる。
  • ContinueUpdateRollbackコマンドを実行し、ロールバック処理の続行を指示する。
  • スタックのドリフト検出を実行し、検出された差分をもとに自動的にリソースを修復する。
解説 頻出度★★★★★
この問題は、「UPDATE_ROLLBACK_FAILED × スタックの外で手動削除されたリソース × 正常な状態への復帰」という状況で、失敗の原因を解消してから ContinueUpdateRollback でロールバックを再開するという復旧の型を選べるかがポイント
正解

A. 削除されたキャッシュクラスターをスタックが想定する状態に一致するよう手動で作成し直すか、スタック定義と整合するように修正する。

正解。CloudFormation は、ロールバック先のリソースが実在することを前提に処理を再開します。手動で削除されたキャッシュクラスターを元のスタックが設定していたものと同じ名前・プロパティで作成し直すと、スタックの想定と実体が一致し、ロールバックを完走できるようになります。
どうしても復元できない場合は、ContinueUpdateRollback の ResourcesToSkip で当該リソースをスキップする方法も用意されていますが、その場合はロールバック完了後にテンプレートとの整合を取り直す必要があります。
いずれにせよ、失敗の原因そのものを解消することが復旧の第一歩です。

B. AWS CloudFormation StackSetsを使って対象リージョンのスタックを自動的に再作成し、問題を解消する。

AWS CloudFormation StackSets は、複数のアカウント・リージョンへ同一のスタックをまとめて展開するための仕組みであり、既存スタックが陥った UPDATE_ROLLBACK_FAILED を解消する機能はありません。
別のスタックを新たに作っても、失敗しているスタック自体は UPDATE_ROLLBACK_FAILED のまま残り、更新も削除もできない不整合なスタックが増えるだけです。
単一スタックの状態復旧の手段としては筋違いです。

C. スタックポリシーを一時的に解除してCloudFormationにリソースの強制再作成権限を付与し、自動ロールバックを再実行させる。

スタックポリシーはスタック更新時に特定のリソースを保護（更新・置換・削除を拒否）するための仕組みで、解除したところで CloudFormation に「リソースを強制再作成する権限」が生まれるわけではありません（権限は IAM の話であってスタックポリシーの役割ではありません）。
また、UPDATE_ROLLBACK_FAILED からロールバックを再開できる操作は ContinueUpdateRollback だけで、ポリシーを外しても自動ロールバックがやり直されることはありません。
「権限を与えれば自動で直る」という語感に引きずられやすい誤答です。

正解

D. ContinueUpdateRollbackコマンドを実行し、ロールバック処理の続行を指示する。

正解。ContinueUpdateRollback（コンソールの「更新のロールバックを続行」、AWS CLI の continue-update-rollback）は、失敗した箇所からロールバックを再開するための専用操作です。
原因を取り除いた状態で実行すると、スタックは UPDATE_ROLLBACK_IN_PROGRESS を経て UPDATE_ROLLBACK_COMPLETE へ遷移し、再び更新できる状態に戻ります。
逆に、原因を解消しないまま実行すると同じ箇所で再び失敗するため、選択肢 A とセットで初めて成立する点が重要です。

E. スタックのドリフト検出を実行し、検出された差分をもとに自動的にリソースを修復する。

ドリフト検出は、スタックのリソースがテンプレートの定義からどれだけ乖離しているかを検出するだけの機能で、検出した差分を自動的に修復することはありません。
削除済みのリソースを DELETED として検出できたとしても、CloudFormation が代わりに作り直してくれるわけではなく、スタックの状態も UPDATE_ROLLBACK_FAILED のままです。
「検出＝修復」と読み替えさせる典型的なひっかけです。

これだけ覚える（記憶フック）
UPDATE_ROLLBACK_FAILED は「原因を直してから ContinueUpdateRollback」。別の操作を足しても前には進まない。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
スタックが UPDATE_ROLLBACK_FAILED で停止している この状態から前へ進められる操作は ContinueUpdateRollback だけ。新しいスタックを作っても元のスタックの状態は変わらない
→選択肢（D）が正解、選択肢（B）を消す
ロールバック対象のキャッシュクラスターがコンソールから手動削除された 失敗の原因はスタックの想定と実体の食い違い。同じ名前・プロパティで作り直すか ResourcesToSkip でスキップして解消する
→選択肢（A）が正解
目標は UPDATE_ROLLBACK_COMPLETE へ戻すこと ドリフト検出は差分を検出するだけで修復しないため、スタックの状態は 1 ミリも動かない
→選択肢（E）を消す
CloudFormation にリソースを直させたい、という発想の切り分け スタックポリシーは更新時の保護設定であり、IAM 権限でもロールバックの再実行手段でもない
→選択肢（C）を消す
復旧手順の順序 原因の解消が先、ContinueUpdateRollback が後。順序が逆だと同じ箇所で再び失敗する
→選択肢（A・D）が正解
ひっかけポイント
  • 「ContinueUpdateRollback さえ実行すれば直る」と考えがちだが、削除されたリソースを手当てしない限り同じ箇所で再び失敗する。原因の解消とセットで初めてロールバックが完了する
  • 選択肢 E のドリフト検出は「差分を見つける」ところまでが仕事で、自動修復は行わない。自動修復まで担うのは AWS Config のルールと修復アクションであり、両者を混同させる罠
  • 選択肢 C の「スタックポリシーを解除」はリソース保護を外す操作であって、ロールバックの再実行とは無関係。スタックポリシー＝更新時の保護、IAM＝権限と切り分ける
  • UPDATE_ROLLBACK_FAILED のスタックは更新も削除もできない状態。作り直し系（StackSets での再作成など）は復旧手段にならないことを押さえる
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「削除されたリソースをどうしても復元できない」 ContinueUpdateRollback の ResourcesToSkip で当該リソースをスキップし、完了後にテンプレートとの整合を取る手順が正解軸に。
「スタックが初回作成に失敗して ROLLBACK_COMPLETE のまま残っている」 続行ではなくスタックの削除と再作成が正解軸に（この状態からは更新できない）。
「更新失敗時に自動でロールバックさせず、失敗した状態のまま調査したい」 スタック更新時の DisableRollback（--disable-rollback）指定が正解軸に。
「スタック外での手動変更そのものを検知・抑止したい」 ドリフト検出の定期実行と、IAM やスタックポリシーによる直接操作の禁止が正解軸に。
「ロールバック中にリソースの安定化待ちでタイムアウトして失敗した」 原因（ヘルスチェック失敗・cfn-signal の未送信など）の是正後に ContinueUpdateRollback、という同じ型で解ける。
関連サービスの解説 Amazon ElastiCache
AWS CloudFormation
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
UPDATE_ROLLBACK_FAILED からの復旧（手動削除されたリソースの扱いと ContinueUpdateRollback） CloudFormation のトラブルシューティング
＋ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。（コメント投稿にはログインが必要です）
正答率 0%
No.1 解説
ある物流会社は、注文管理システムの高可用性キャッシュ層としてAmazon ElastiCacheクラスターをAWS CloudFormationスタックで管理しています。テンプレートの更新を適用した際にエラーが発生し、CloudFormationは自動的にロールバック処理を開始しました。ところが、直前に運用チームがマネジメントコンソールから対象のキャッシュクラスターを手動で削除していたため、CloudFormationはロールバック先のリソースを見つけられずロールバックが完了せず、スタックはUPDATE_ROLLBACK_FAILED状態のまま停止しています。

DevOpsエンジニアがこのスタックを正常な状態（UPDATE_ROLLBACK_COMPLETE）に戻すために取るべきアクションを2つ選んでください。
  • 削除されたキャッシュクラスターをスタックが想定する状態に一致するよう手動で作成し直すか、スタック定義と整合するように修正する。
  • AWS CloudFormation StackSetsを使って対象リージョンのスタックを自動的に再作成し、問題を解消する。
  • スタックポリシーを一時的に解除してCloudFormationにリソースの強制再作成権限を付与し、自動ロールバックを再実行させる。
  • ContinueUpdateRollbackコマンドを実行し、ロールバック処理の続行を指示する。
  • スタックのドリフト検出を実行し、検出された差分をもとに自動的にリソースを修復する。

次の問題


(会員限定)当問題の評価をお願いします。改善に活用します。
広告

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報