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

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

正解 B,D問題
分野5:インシデントとイベントへの対応 タスクステートメント5.3:システムおよびアプリケーション障害のトラブルシューティング
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
あるゲーム運営会社の DevOps エンジニアは、AWS CodeBuild のビルドが失敗したときに、失敗したビルドのログを退避して障害チケットを起票する AWS Step Functions のステートマシンを用意しました。起動は Amazon EventBridge のルールに任せ、ルールのターゲットとしてこのステートマシンを指定しています。

動作確認のために意図的に失敗するビルドを流したところ、ステートマシンの実行履歴には新しい実行が 1 件も現れませんでした。ルールは有効な状態にあり、マネジメントコンソールから同じ入力でステートマシンを手動実行すると最後まで完了します。

この事象の原因として考えられるものはどれですか。(2つ選択)
  • ステートマシンにリソースベースのポリシーを設定しておらず、events.amazonaws.com サービスプリンシパルからの起動が許可されていない。
  • ルールのイベントパターンに書いた detail の項目や値が、CodeBuild が実際に送出しているイベントの内容と一致しておらず、イベントが除外されている。
  • ルールのターゲットに入力トランスフォーマーを設定していないため、イベント全体がそのまま渡されてステートマシンが受け付けられない。
  • ルールのターゲットに指定した IAM ロールに states:StartExecution が与えられておらず、EventBridge が実行を開始できない。
  • ステートマシンの実行ロールに、ログの退避先である Amazon S3 バケットへの書き込み権限が付与されていない。
解説 頻出度★★★★
この問題は、「ルールは有効 × 手動実行は成功 × 実行履歴が 1 件も無い」という 3 つの事実から、障害点がステートマシンの内部ではなく「イベントがルールに一致していない」か「ターゲットを起動する権限が無い」かのどちらかだと切り分けられるかがポイント

A. ステートマシンにリソースベースのポリシーを設定しておらず、events.amazonaws.com サービスプリンシパルからの起動が許可されていない。

AWS Step Functions のステートマシンは、呼び出しを許可するためのリソースベースのポリシーをサポートしていません。EventBridge がステートマシンを起動するときは、ルールのターゲットに指定した IAM ロールを引き受けて states:StartExecution を呼び出します。
したがって「リソースベースのポリシーが無いから起動できない」という状況は起こり得ません。
リソースベースのポリシーで呼び出しを許可する形になるのは AWS Lambda・Amazon SNS・Amazon SQS などのターゲットで、その混同を狙った選択肢です。

正解

B. ルールのイベントパターンに書いた detail の項目や値が、CodeBuild が実際に送出しているイベントの内容と一致しておらず、イベントが除外されている。

正解のひとつです。EventBridge はイベントパターンに一致したイベントだけをターゲットへ配信します。detail 内のキー名や値が CodeBuild の実際のイベントと食い違っていれば、ルールが有効でも一致数は 0 のままで、何も起こりません。
CodeBuild のビルド状態変更イベントは detail の build-status にハイフン区切りで FAILED などが入るため、キャメルケースで書いたり、プロジェクト名の指定を誤ったりすると簡単に一致しなくなります。
この場合ターゲット側には一切痕跡が残らず、「実行履歴が空」という今回の症状と完全に一致します。CloudWatch の TriggeredRules が 0 のままかどうかで確認できます。

C. ルールのターゲットに入力トランスフォーマーを設定していないため、イベント全体がそのまま渡されてステートマシンが受け付けられない。

入力トランスフォーマーは任意の設定であり、指定しなければイベント全体が JSON としてそのままターゲットへ渡されます。Step Functions は任意の JSON を実行入力として受け付けるため、変換していないこと自体が起動失敗の原因になることはありません。
そもそも「同じ入力で手動実行すると完了する」と明記されており、入力の形式は問題ではないと設問自身が否定しています。

正解

D. ルールのターゲットに指定した IAM ロールに states:StartExecution が与えられておらず、EventBridge が実行を開始できない。

正解のひとつです。EventBridge は Step Functions をターゲットにする場合、ルールに設定した IAM ロールを引き受けて states:StartExecution を呼び出します
そのロールのポリシーに states:StartExecution が無い、または信頼ポリシーで events.amazonaws.com からの引き受けが許可されていないと、呼び出しがアクセス拒否となり実行そのものが作られません
ルールは有効でイベントも一致しているのに実行が現れない、という今回の症状を説明できます。この失敗は CloudWatch の FailedInvocations メトリクスに現れます。

E. ステートマシンの実行ロールに、ログの退避先である Amazon S3 バケットへの書き込み権限が付与されていない。

ステートマシンの実行ロールに Amazon S3 への書き込み権限が無い場合、実行は開始されたうえで S3 に書き込むステップで失敗します。つまり実行履歴には「失敗した実行」が残るはずで、「実行が 1 件も現れない」という症状の説明になりません。
加えて、同じ入力での手動実行が最後まで完了しているため、実行ロールの権限は足りていることが既に確認済みです。

これだけ覚える(記憶フック)
実行履歴ゼロ=起動する前で止まっている。疑うのはイベントパターンとターゲットの IAM ロールだけ。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
ルールは有効なのに実行履歴が 1 件も無い 実行が1 件も作られていない=ステートマシンに到達する前で止まっている。実行後に失敗する要因は原因になり得ない
→選択肢(E)を消す
同じ入力でコンソールから手動実行すると完了する ステートマシン本体・入力形式・実行ロールはすべて正常だと設問が保証している
→選択肢(C・E)を消す
EventBridge がイベントを取りこぼす条件 イベントパターンが実イベントと一致しなければ配信されない。ターゲット側には痕跡すら残らない
→選択肢(B)が正解
EventBridge がターゲットを起動する仕組み Step Functions はターゲット用 IAM ロールを引き受けて states:StartExecution。権限不足なら実行は作られない
→選択肢(D)が正解
リソースベースのポリシーで呼び出しを許可できるターゲット Lambda・SNS・SQS・CloudWatch Logs・API Gateway などに限られ、Step Functions は非対応
→選択肢(A)を消す
ひっかけポイント
  • 「ルールは有効な状態にある」と明記されているため、ルールの無効化やイベントバスの取り違えは最初から除外されている。残る停止点は「パターン不一致」と「ターゲット起動権限」の 2 つだけ
  • 選択肢 A の「リソースベースのポリシーで events.amazonaws.com を許可」は、Lambda ターゲットなら実在する構図(lambda:AddPermission)。Step Functions には無い仕組みを、正しそうな用語で持ち込んでいる
  • 選択肢 E は実際に起こりうる設定ミスだが、症状は「実行が残ったうえで失敗する」。「実行履歴が空」という症状と対応しないため切れる
  • 「手動実行すると完了する」の一文は、ステートマシン側は無罪という宣言。入力形式(C)も実行ロール(E)もこの一文だけで消せる
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「実行履歴に失敗した実行が残っている」に変わったら 起動は成功しているため、ステートマシン実行ロールの S3 権限不足(E 相当)が正解に。
「ターゲットが AWS Lambda 関数で起動しない」に変わったら 関数のリソースベースのポリシー(AddPermission)不足が正解軸になり得る。
「CloudWatch の FailedInvocations が増えている」という情報が加わったら イベントは一致している証拠なので、ターゲット IAM ロールの権限に原因が絞られる。
TriggeredRules が 0 のまま」という情報が加わったら そもそもルールが一致していないため、イベントパターンの誤りに絞られる。
別アカウントのステートマシンを起動したい」に変わったら イベントバス間のクロスアカウント転送と、転送先アカウント側のルール構成が論点に。
関連サービスの解説 Amazon EventBridge
AWS CodeBuild
AWS Step Functions
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
EventBridge のターゲット起動権限(リソースベースのポリシー対応ターゲット) Amazon EventBridge でリソースベースのポリシーを使用する
+ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。(コメント投稿にはログインが必要です)
正答率 0%
No.6 解説
あるゲーム運営会社の DevOps エンジニアは、AWS CodeBuild のビルドが失敗したときに、失敗したビルドのログを退避して障害チケットを起票する AWS Step Functions のステートマシンを用意しました。起動は Amazon EventBridge のルールに任せ、ルールのターゲットとしてこのステートマシンを指定しています。

動作確認のために意図的に失敗するビルドを流したところ、ステートマシンの実行履歴には新しい実行が 1 件も現れませんでした。ルールは有効な状態にあり、マネジメントコンソールから同じ入力でステートマシンを手動実行すると最後まで完了します。

この事象の原因として考えられるものはどれですか。(2つ選択)
  • ステートマシンにリソースベースのポリシーを設定しておらず、events.amazonaws.com サービスプリンシパルからの起動が許可されていない。
  • ルールのイベントパターンに書いた detail の項目や値が、CodeBuild が実際に送出しているイベントの内容と一致しておらず、イベントが除外されている。
  • ルールのターゲットに入力トランスフォーマーを設定していないため、イベント全体がそのまま渡されてステートマシンが受け付けられない。
  • ルールのターゲットに指定した IAM ロールに states:StartExecution が与えられておらず、EventBridge が実行を開始できない。
  • ステートマシンの実行ロールに、ログの退避先である Amazon S3 バケットへの書き込み権限が付与されていない。

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