AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

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

正解 A,D問題

分野2：構成管理と IaC 分野6：セキュリティとコンプライアンスタスクステートメント2.3：複雑なタスクと大規模環境向けの自動化ソリューションの設計・構築タスクステートメント6.2：セキュリティ統制とデータ保護のための自動化の適用

1 2 3 4

次の問題

問題文と選択肢

ある放送局は、映像素材の変換処理を担う Windows Server ベースの Amazon EC2 インスタンス 40 台を AWS Systems Manager のマネージドノードとして運用しています。ノードはプライベートサブネットに置かれ、NAT ゲートウェイ経由の HTTPS の送信のみが許可されています。

監視エージェントの設定調整やライセンス更新を行う PowerShell スクリプトは、社内の GitHub Enterprise Cloud のプライベートリポジトリで変更管理されています。これまで運用チームは、そのスクリプトの中身を SSM ドキュメントの runCommand 行に貼り付けてドキュメントを改訂する方法をとってきましたが、リポジトリ側の改訂とドキュメント側の改訂が二重管理になり、貼り付け忘れによって古い手順が実行される事故が起きています。

そこで運用チームは、State Manager の関連付けによる週次実行のたびに、ノード自身がリポジトリの main ブランチから最新のスクリプトを取り込む方式へ切り替えることにしました。加えて社内規程では、リポジトリの読み取りに使うアクセストークンが Run Command の出力や AWS CloudTrail のイベントに平文で現れることを禁じています。

運用オーバーヘッドを最小限に抑えてこれらを満たすために実施すべき対応はどれですか。（2つ選択）

SSM ドキュメントの mainSteps に aws:downloadContent アクションを置き、sourceType に GitHub、sourceInfo にリポジトリの所有者・名称・パス・ブランチを指定して、関連付けが動くたびにノードが main ブランチの内容を取り込むようにする。
GitHub Actions のワークフローから OpenID Connect (OIDC) で AWS のロールを引き受けさせ、その延長でノードのインスタンスプロファイルにリポジトリの読み取り権限を与えることで、トークンによる認証を不要にする。
aws:runPowerShellScript の runCommand に Invoke-WebRequest でリポジトリの raw URL を取得する処理を記述し、認証ヘッダーに載せるトークンは SSM ドキュメントの入力パラメータとして実行時に指定する。
アクセストークンを Systems Manager パラメータストアへ SecureString 型で登録し、SSM ドキュメント側では {{ ssm-secure:/broadcast/github/token }} の形式で参照する。ノードのインスタンスプロファイルには当該パラメータの取得と復号に必要な権限のみを与える。
リポジトリの Webhook を受ける AWS Lambda 関数を用意してスクリプトを Amazon S3 バケットへ複製し、SSM ドキュメントの aws:downloadContent では sourceType に S3 を指定してノードに取得させる。

解説頻出度★★★★★

この問題は、「関連付けの実行のたびにノード自身が GitHub の main から最新スクリプトを取得 × トークンを Run Command の出力や CloudTrail に平文で出さない × 運用オーバーヘッド最小」の要件で、aws:downloadContent による取得と、パラメータストアの SecureString を ssm-secure で参照する組み合わせを選べるかがポイント

正解

A. SSM ドキュメントの mainSteps に aws:downloadContent アクションを置き、sourceType に GitHub、sourceInfo にリポジトリの所有者・名称・パス・ブランチを指定して、関連付けが動くたびにノードが main ブランチの内容を取り込むようにする。

正解。aws:downloadContent は SSM ドキュメントの標準アクションで、sourceType に GitHub / S3 / HTTP / SSMDocument を指定し、sourceInfo にリポジトリの所有者・名称・パス・ブランチ（getOptions）を書くと、ノードが実行のたびに指定ブランチの最新内容を取得します。
スクリプト本体をドキュメントに貼り付ける必要がなくなるため、リポジトリ側の改訂がそのまま実行内容に反映され、二重管理と貼り付け忘れという事故の原因そのものが消えます。
State Manager の関連付けで週次実行すれば、常に main の最新版が適用されます。

B. GitHub Actions のワークフローから OpenID Connect (OIDC) で AWS のロールを引き受けさせ、その延長でノードのインスタンスプロファイルにリポジトリの読み取り権限を与えることで、トークンによる認証を不要にする。

GitHub Actions の OIDC 連携は、GitHub 側のワークフローが AWS の IAM ロールを引き受けるための仕組みで、本問とは方向が逆です。
本問で必要なのは「AWS 側のノードが GitHub のプライベートリポジトリを読む」ための認証であり、インスタンスプロファイル（IAM）で GitHub リポジトリへの読み取り権限を表現することはできません。
結局 GitHub 側のアクセストークンが必要であり、トークンの秘匿という論点は何も解決しません。

C. aws:runPowerShellScript の runCommand に Invoke-WebRequest でリポジトリの raw URL を取得する処理を記述し、認証ヘッダーに載せるトークンは SSM ドキュメントの入力パラメータとして実行時に指定する。

ドキュメントの入力パラメータとしてトークンを渡すと、関連付けの定義や Run Command の実行内容、CloudTrail の API 呼び出し記録に平文で残ります。SecureString として扱われないため、「平文で現れることを禁じる」という社内規程に真っ向から反します。
また、標準アクションの aws:downloadContent があるにもかかわらず Invoke-WebRequest による取得処理を自前で書くのは、エラー処理も含めて保守対象を増やすだけです。
秘匿・運用負荷の両面で不適切です。

正解

D. アクセストークンを Systems Manager パラメータストアへ SecureString 型で登録し、SSM ドキュメント側では {{ ssm-secure:/broadcast/github/token }} の形式で参照する。ノードのインスタンスプロファイルには当該パラメータの取得と復号に必要な権限のみを与える。

正解。アクセストークンを Systems Manager パラメータストアへ SecureString 型で登録し、ドキュメントからは {{ ssm-secure:パラメータ名 }} の形式で参照すると、値の解決と復号はノード上の SSM Agent が実行時に行うため、ドキュメント本文にも実行結果にも平文のトークンは現れません。
ノードのインスタンスプロファイルには、当該パラメータの取得（ssm:GetParameters）と復号（kms:Decrypt）だけを許可すれば足り、最小権限を保ったまま秘匿要件を満たせます。
aws:downloadContent の sourceInfo にある tokenInfo をこの形式で書くのが、GitHub プライベートリポジトリを扱う際の定石です。

E. リポジトリの Webhook を受ける AWS Lambda 関数を用意してスクリプトを Amazon S3 バケットへ複製し、SSM ドキュメントの aws:downloadContent では sourceType に S3 を指定してノードに取得させる。

Webhook を受ける Lambda 関数でスクリプトを Amazon S3 へ複製し、ノードは S3 から取得する構成でも動作はしますが、Lambda・Webhook・S3 バケットと構成要素が増え、Webhook の署名シークレット管理まで新たに必要になります。
「運用オーバーヘッドを最小限に抑える」という要件に照らすと、標準アクションだけで完結する案より明らかに重い構成です。
また「ノード自身がリポジトリの main ブランチから最新を取り込む」という方針からも外れ、S3 上のコピーが最新かどうかという新たな心配事も生まれます。

これだけ覚える（記憶フック）
GitHub からの取得は aws:downloadContent、トークンは ssm-secure 参照。平文の入力パラメータは即アウト。

正解への思考ルート

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

要件	判断ポイント
関連付けの実行のたびに、ノード自身が main ブランチの最新を取り込む	SSM ドキュメントの標準アクション aws:downloadContent（sourceType GitHub）で実現でき、貼り付けによる二重管理が消える →選択肢（A）が正解、選択肢（E）を消す
アクセストークンを Run Command の出力や CloudTrail に平文で出さない	パラメータストアの SecureString を {{ ssm-secure:... }} で参照し、復号はノード上の SSM Agent に任せる →選択肢（D）が正解
トークンを実行時の入力パラメータで渡す案の評価	入力パラメータは関連付け定義や CloudTrail に平文で残るため、規程違反になる →選択肢（C）を消す
認証の向き（誰が誰に対して認証するか）	GitHub Actions の OIDC は GitHub → AWS の認証。ノードが GitHub を読む権限は IAM では表現できない →選択肢（B）を消す
運用オーバーヘッドを最小限に抑える	Lambda と Webhook と S3 を挟む構成は部品も秘密情報も増える。標準アクションだけで完結する案が優先される →選択肢（E）を消す

ひっかけポイント

選択肢 C の「実行時の入力パラメータで指定する」は、ドキュメントに直接書かない分だけ安全に見えるのが罠。入力パラメータは平文で記録に残るため、秘匿要件を満たすのは ssm-secure 参照だけ
選択肢 B の OIDC は「トークンレス認証」という語感で正解らしく見えるが、使う向きが逆。AWS リソースが外部 SaaS を読む場面では、外部側の資格情報をどう秘匿するかが論点になる
Invoke-WebRequest で raw URL を叩く自前実装より、標準アクション aws:downloadContent を優先する。sourceType には GitHub / S3 / HTTP / SSMDocument が用意されている
ssm-secure による参照はノード側で復号するため、インスタンスプロファイルに kms:Decrypt が無いと実行時に失敗する。「パラメータの取得権限だけ」では足りない点に注意

出題バリエーション

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

問題文がこう変わったら	正解はこう変わる
「スクリプトの配布元が GitHub ではなく Amazon S3」	同じ aws:downloadContent の sourceType を S3 に変え、インスタンスプロファイルに s3:GetObject を付与する形が正解軸に。
「ノードがインターネットに出られない（NAT も無い）」	GitHub からの直接取得は不可能になり、SSM 用インターフェイスエンドポイント＋S3 経由の配布が正解軸に。
「週次ではなくリポジトリの更新と同時に反映したい」	Webhook から Lambda を起動して関連付けを即時実行する、イベント駆動の構成が正解軸に（本問の選択肢 E に近い形）。
「実行結果をまとめて監査したい」	Run Command / State Manager の出力を Amazon S3 や CloudWatch Logs へ送る設定が論点に。
「40 台への適用を一斉ではなく段階的に行いたい」	State Manager の関連付けにおけるレート制御（同時実行数・エラーしきい値）の設定が論点に。

AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

B. GitHub Actions のワークフローから OpenID Connect (OIDC) で AWS のロールを引き受けさせ、その延長でノードのインスタンスプロファイルにリポジトリの読み取り権限を与えることで、トークンによる認証を不要にする。

C. aws:runPowerShellScript の runCommand に Invoke-WebRequest でリポジトリの raw URL を取得する処理を記述し、認証ヘッダーに載せるトークンは SSM ドキュメントの入力パラメータとして実行時に指定する。

E. リポジトリの Webhook を受ける AWS Lambda 関数を用意してスクリプトを Amazon S3 バケットへ複製し、SSM ドキュメントの aws:downloadContent では sourceType に S3 を指定してノードに取得させる。

次の問題

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報