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

デベロッパー–アソシエイト

正解 C問題
分野1：AWS のサービスによる開発 タスクステートメント1.2：AWS Lambda 用のコードの開発 タスクステートメント1.1：AWS でホストされるアプリケーションのコードの開発
要復習（もう一度解きたい問題） 1 2 3 4
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
ある製造業の企業は、生産設備の稼働ログをバックアップする仕組みを AWS 上に構築しており、AWS Backup を使ってバックアップジョブを実行している。AWS Backup のジョブが完了または失敗した際に、担当者へ通知を送る AWS Lambda 関数を自動的に起動したいが、AWS Backup 自体には Lambda 関数を直接呼び出すための設定項目が用意されていない。

この要件を満たすために取るべき方法として、最も適切なものはどれですか。
  • AWS Backup のジョブ状態を数分おきにポーリングする Lambda 関数を、EventBridge のスケジュールルールで定期実行する
  • AWS Backup 用のイベントソースマッピングを Lambda 関数に作成し、ジョブ状態の変化をポーリングさせる
  • Amazon EventBridge にルールを作成し、AWS Backup のジョブ状態変化イベントをパターンマッチさせて Lambda 関数をターゲットに指定する
  • AWS Backup が出力するジョブログを Amazon CloudWatch Logs のロググループで受け取り、サブスクリプションフィルターで Lambda 関数へ配信する
解説 頻出度★★★★★
この問題は、「AWS Backup 側に Lambda を呼ぶ設定が無い × ジョブの完了／失敗で Lambda を起動したい」という要件で、AWS サービスが発する状態変化イベントは Amazon EventBridge が受け取り、ルールのターゲットとして Lambda へ配るという疎結合の定石を選べるかがポイント

A. AWS Backup のジョブ状態を数分おきにポーリングする Lambda 関数を、EventBridge のスケジュールルールで定期実行する

Lambda 関数から ListBackupJobs API などを定期的に呼べば状態変化は検知できるものの、「変化していない時間帯」も含めて数分おきに Lambda が動き続けるため無駄な実行課金が発生し、通知も最大でポーリング間隔ぶん遅れます。
さらに「どのジョブを通知済みか」の重複排除を自前で持つ必要があり、コードと状態管理が増えます。
要件を満たせなくはありませんが、イベント駆動の仕組みが標準で用意されている以上、最も適切な方法ではありません。

B. AWS Backup 用のイベントソースマッピングを Lambda 関数に作成し、ジョブ状態の変化をポーリングさせる

Lambda のイベントソースマッピングは、Lambda 側がポーリングして読み取るストリーム／キュー型のサービス専用の仕組みです（Kinesis Data Streams、DynamoDB Streams、Amazon SQS、Amazon MQ、Amazon MSK / 自己管理型 Kafka、Amazon DocumentDB など）。
AWS Backup はイベントソースマッピングの対象に含まれておらず、そもそも作成できません。
「ポーリングさせる」という語感からもっともらしく見えますが、実在しない構成です。

正解

C. Amazon EventBridge にルールを作成し、AWS Backup のジョブ状態変化イベントをパターンマッチさせて Lambda 関数をターゲットに指定する

AWS Backup は、バックアップジョブやコピージョブの状態が変わるたびに、source が aws.backup、detail-type が「Backup Job State Change」のイベントを Amazon EventBridge へ自動的に送信します。
EventBridge のルールでイベントパターンを書けば、COMPLETED / FAILED といった状態だけを絞り込んでターゲットの Lambda 関数を起動できます。
AWS Backup 側に「Lambda を呼ぶ設定」が無くても、イベントの受け側である EventBridge が仲介するため両者を直接つなぐ必要がなく、通知先を SNS や Step Functions へ増やすのもターゲット追加だけで済みます。ポーリング不要・追加コードほぼゼロで要件を満たす唯一の選択肢です。

D. AWS Backup が出力するジョブログを Amazon CloudWatch Logs のロググループで受け取り、サブスクリプションフィルターで Lambda 関数へ配信する

CloudWatch Logs のサブスクリプションフィルターで Lambda へ配信する構成自体は実在しますが、それはロググループにログが流れてくることが前提です。
AWS Backup はジョブの実行ログを CloudWatch Logs のロググループへ出力しません。ジョブの状態は EventBridge へのイベント送信、またはバックアップボールトの通知 API（Amazon SNS）で公開されます。
起点となるログソースが存在しないため、この構成は組み立てられません。

構成図

AWS Backup（バックアップジョブ）
   │ Backup Job State Change（COMPLETED / FAILED）
   ▼
Amazon EventBridge（イベントパターンでルールにマッチ）
   │ ターゲットとして起動
   ▼
AWS Lambda（担当者へ通知）
これだけ覚える（記憶フック）
AWS サービスの「状態が変わった」は EventBridge で拾う。ポーリングを書き始めた時点で設計を疑う。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
AWS Backup 側に Lambda を呼び出す設定項目が無い 呼び出し元に機能が無いなら、イベントの受け側（EventBridge）で仲介する。AWS サービス間の疎結合連携の基本形
→選択肢（C）が正解
ジョブが「完了または失敗した際に」起動したい（状態変化がトリガー） AWS Backup は Backup Job State Change イベントを EventBridge へ送信済み。ルールのイベントパターンで state を絞り込むだけでよい
→選択肢（C）が正解／選択肢（A）を消す
自動的に起動したい（運用の手間を増やしたくない） 数分おきのポーリングは通知遅延・無駄な実行課金・重複排除の自作を招く。イベント駆動が用意されている場面では選ばない
→選択肢（A）を消す
Lambda をどうつなぐか（連携方式の知識） イベントソースマッピングはストリーム／キュー型のサービス専用で、AWS Backup は対象外。EventBridge ルールのターゲットとして指定するのが正しい
→選択肢（B）を消す
実在する連携経路かどうか AWS Backup はジョブログを CloudWatch Logs へ出力しないため、サブスクリプションフィルターの起点がない
→選択肢（D）を消す
ひっかけポイント
  • 選択肢 B の「イベントソースマッピング」は Lambda の実在機能だが、使えるのは Lambda 側がポーリングするストリーム／キュー型サービスだけ（Kinesis・DynamoDB Streams・SQS・MQ・MSK/Kafka・DocumentDB）。AWS Backup のような「イベントを push してくるサービス」には作成できない
  • 選択肢 D は「CloudWatch Logs サブスクリプションフィルター → Lambda」という実在するパターンを、ログを出さないサービスに当てはめたひっかけ。連携方式だけでなくそのサービスがログを出すのか、イベントを出すのかを区別する
  • 選択肢 A は「動くには動く」タイプの誤答。設問が「最も適切」を問うている以上、要件を満たすかどうかではなく遅延・コスト・自作コード量で比較して落とす
  • 「AWS Backup に Lambda を呼ぶ設定が無い」という与件を、連携そのものが不可能と読み違えないこと。呼び出し元に機能が無くても EventBridge が受け側として成立させる
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「バックアップ失敗時にメールで担当者へ通知したいだけ（コードは書きたくない）」 EventBridge ルールのターゲットを Amazon SNS トピックにする（Lambda は不要）。バックアップボールトの通知 API（SNS）も選択肢になる。
「複数ステップの復旧処理を、失敗時のリトライ付きで実行したい」 EventBridge のターゲットを AWS Step Functions ステートマシンにする。
「毎晩 1 時にレポート集計の Lambda を動かしたい」 状態変化ではなく時刻がトリガーなので、EventBridge Scheduler（スケジュールルール）が正解に。選択肢 A の構成が正しくなる場面。
「Amazon S3 にオブジェクトが置かれたら Lambda を起動したい」 S3 イベント通知で直接 Lambda を呼べる（EventBridge 経由も可）。呼び出し元に機能があるなら仲介は不要。
「Amazon SQS のキューに入ったメッセージを Lambda で処理したい」 ここでこそイベントソースマッピングが正解。選択肢 B の用語が正しく使われる場面。
関連サービスの解説 Amazon EventBridge
AWS Backup
AWS Lambda
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
AWS Backup のジョブ状態変化イベントと EventBridge 連携 EventBridge を使用した AWS Backup イベントのモニタリング
＋ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。（コメント投稿にはログインが必要です）
正答率 80%
No.9 解説
ある製造業の企業は、生産設備の稼働ログをバックアップする仕組みを AWS 上に構築しており、AWS Backup を使ってバックアップジョブを実行している。AWS Backup のジョブが完了または失敗した際に、担当者へ通知を送る AWS Lambda 関数を自動的に起動したいが、AWS Backup 自体には Lambda 関数を直接呼び出すための設定項目が用意されていない。

この要件を満たすために取るべき方法として、最も適切なものはどれですか。
  • AWS Backup のジョブ状態を数分おきにポーリングする Lambda 関数を、EventBridge のスケジュールルールで定期実行する
  • AWS Backup 用のイベントソースマッピングを Lambda 関数に作成し、ジョブ状態の変化をポーリングさせる
  • Amazon EventBridge にルールを作成し、AWS Backup のジョブ状態変化イベントをパターンマッチさせて Lambda 関数をターゲットに指定する
  • AWS Backup が出力するジョブログを Amazon CloudWatch Logs のロググループで受け取り、サブスクリプションフィルターで Lambda 関数へ配信する


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

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報