AWS DOP-C02のサンプル問題（本番形式・解説付き）

AWS DOP-C02（Amazon Web Services・AWS Certified DevOps Engineer - Professional（DOP-C02））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試第1回（75問）の冒頭から抜粋したオリジナル問題です。当サイトは全525問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

CloudFormationスタックが管理しているセキュリティグループに対し、運用担当者がマネジメントコンソールから直接インバウンドルールを追加してしまった。テンプレートで定義された状態と実際の設定に差異が生じていないかを確認する機能はどれか。

スタックポリシー
変更セット（Change Set）
ドリフト検出（Drift Detection）（正解）
ネストスタック（Nested）

解説

ドリフト検出は、スタックが管理するリソースの実際の設定が、テンプレートで定義された期待値からどれだけ乖離（ドリフト）しているかを確認する機能です。変更セットはこれから行う更新のプレビュー、スタックポリシーは更新操作の制限、ネストスタックはテンプレートの部品化であり、いずれも既存の乖離を検出する機能ではありません。

他の選択肢が誤りである理由

「スタックポリシー」スタックポリシーは更新操作自体を許可・拒否する制限機能であり、既存の設定差異を検出するものではありません。
「変更セット（Change Set）」変更セットはこれから適用する更新内容を事前確認する機能であり、すでに生じた手動変更との乖離を検出する機能ではありません。
「ネストスタック（Nested）」ネストスタックはテンプレートを部品化する構造上の仕組みであり、設定差異の検出機能ではありません。

設問2

CodeDeployのappspec.yml（EC2／オンプレミス向け）で、アプリケーションファイルを配置する前に旧バージョンのアプリケーションを停止させるためのライフサイクルイベントフックはどれか。

AfterInstall
ApplicationStop（正解）
ApplicationStart
ValidateService

解説

ApplicationStopは、デプロイの最初期に実行されるフックで、旧バージョンのアプリケーションを新しいファイルの配置前に停止させるために使います。

他の選択肢が誤りである理由

「AfterInstall」AfterInstallはファイル配置後に実行されるフックで、配置前の旧バージョン停止処理には使いません。
「ApplicationStart」ApplicationStartは新バージョンの起動処理に使うフックで、旧バージョンの停止処理ではありません。
「ValidateService」ValidateServiceはデプロイ完了間際に正常性を検証するフックで、旧バージョンの停止処理ではありません。

設問3

同一AWS Organizations内の複数アカウントを横断して運用担当者が管理作業を行うために、各メンバーアカウントに共通の管理者ロールを用意し、管理アカウントのIAMユーザーがそのロールを引き受ける構成を取りたい。この用途に最も適したSTSのAPIはどれか。

AssumeRole（正解）
GetFederationToken
AssumeRoleWithWebIdentity
AssumeRoleWithSAML

解説

AssumeRoleは、同一アカウント内または別のAWSアカウントのIAMユーザー／ロールが、信頼ポリシーで許可された別のロールを引き受けるための標準的なSTS APIです。組織内の複数アカウントを横断した管理者ロールの引き受けはこの典型的なユースケースです。

他の選択肢が誤りである理由

「GetFederationToken」GetFederationTokenは長期IAM認証情報を持つ独自のIDブローカーがフェデレーションユーザー向けに使うAPIで、IAMプリンシパル同士のロール引き受けには使いません。
「AssumeRoleWithWebIdentity」AssumeRoleWithWebIdentityは外部Web IDプロバイダー向けのAPIであり、IAMユーザー同士のクロスアカウントロール引き受けには使いません。
「AssumeRoleWithSAML」AssumeRoleWithSAMLはSAML IdP連携向けのAPIであり、IAMユーザー同士の直接のロール引き受けとは異なります。

設問4

ALB の背後の Auto Scaling グループで動く EC2 上の CMS を、ダウンタイム無しで入れ替えられる構成にしたい。現状、利用者のアップロードファイルは各インスタンスの /var/www/uploads に保存され、ログインのセッション状態もインスタンスのローカルディスクに置かれている。CMS 本体のコードは改修できない。この構成を成立させるために必要な対応はどれか。（2つ選択）

既存インスタンスの EBS スナップショットから新環境のボリュームを作成し、切り替えの時点で付け替える
アップロードファイルの保存先を Amazon S3 に変更し、アプリケーションから HTTP API 経由で読み書きするよう書き換える
io2 の EBS ボリュームをマルチアタッチで複数のインスタンスへ接続し、共有ディレクトリとして使う
Amazon EFS のファイルシステムを作り、既存のファイルを移行して /var/www/uploads にマウントする（正解）
Fargate の一時ストレージを 200GB まで拡張し、アップロードファイルの保存先として割り当てる
セッション状態をローカルディスクではなく Amazon DynamoDB や Amazon ElastiCache に置いてステートレスにする（正解）

解説

本文は、複数台から同時に読み書きする必要のある作業領域は Amazon EFS だとし、同じ場面で EFS を作りファイルを移行して起動テンプレートのユーザーデータやイメージでマウントすれば新旧どちらの環境からも同じファイルが見えると示しています。あわせて、セッション状態はローカルディスクではなく DynamoDB や ElastiCache に置くこと、これをやらないと入れ替えのたびにログアウトが発生することを述べています。S3 へ移す案はアプリ改修が要るため要件に反します。EBS スナップショットからの作成は、切り替え後に旧環境へ書き込まれたファイルが失われます。EBS のマルチアタッチは強い制約があり汎用の解になりません。Fargate の一時ストレージはタスク終了で消えます。

設問5

多数のEC2インスタンスに対して、SSHキーの管理や踏み台サーバーの用意をすることなく、任意のシェルコマンドを一括実行したい。最も適したSystems Manager機能はどれか。

Run Command（正解）
State Manager
Patch Manager
Inventory

解説

Run Commandは、SSHキーや踏み台サーバーを用意せずに、SSM Agent経由で多数のマネージドインスタンスへコマンドを一括実行できる機能です。State Managerは継続的な状態維持、Patch Managerはパッチ適用、Inventoryはインスタンスのメタデータ収集に特化しており、任意コマンドの都度実行が主目的ではありません。

他の選択肢が誤りである理由

「State Manager」State Managerは望ましい状態を継続的に維持するための仕組みであり、任意のシェルコマンドを都度一括実行する用途にはRun Commandの方が適しています。
「Patch Manager」Patch Managerはパッチの適用に特化した機能であり、任意のシェルコマンドを汎用的に一括実行する用途には向いていません。
「Inventory」Inventoryはインスタンスにインストールされたソフトウェアなどのメタデータを収集する機能であり、コマンドを実行する機能ではありません。

続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。

登録なしで50問解く

← AWS DOP-C02 の資格ページへ