頂いているコメントも参考に！注意：この回答は完璧ではありません！和訳の言い回し等、判断が難しいもの多し
どうも、iron千葉です。
DevOpsプロフェッショナル試験、日本語での提供が始まっています。
いざ、DevOpsプロフェッショナルになるべく、試験概要とサンプル問題の回答をしてみたいと思います。
ソリューションアーキテクトプロフェッショナルかなり難しい印象でしたが、DevOpsプロフェッショナルも同じように難しそうです。
ただし、インフラエンジニアとしてのスキルアップとしてかなり濃い内容の問題が沢山用意されているので、とっても勉強になる試験かなと思います。
技術の暗記ではなく、設計力・提案力までもが問われる問題となっています。
アーキテクトを目指している方は、是非勉強してみてはいかがでしょうか。根拠を考える力がつくため、AWS・クラウド問わず仕事で役立つのではないでしょうか。
それでは、いってみましょう。
試験概要
AWS ソリューションアーキテクトプロフェッショナルとの違いという観点で記載します。
DevOpsプロフェッショナルの概要詳細はAmazon公式を参照ください。
ソリューションアーキテクトプロフェッショナルとの違い
- プログラミング、スクリプト等を利用した自動化要素の追加
- AWSのAPI、SDK、CLIが範囲に含まれるということですね。
- これを利用した自動化の知識（バックアップ、自動構成）
- デプロイ方式（ブルーグリーンデプロイ、ローリングアップデートなど）の要素が追加※CIのお話ですね
- CloudWatchのメトリクスやログ記録に関する知識※アプリのログをどうやって記録するか、CloudWatchのメトリクスをどのように活用するかという観点
- Auto Scalingの詳細（デプロ時のクールダウンとか、フック、自己修復の話など詳細な知識が必要そう）※アプリ層、中間層、ストレージに関するスケーリング知識も
- CloudFormationでのテンプレートの知識（設定項目詳細）
- あとは、ソリューションアーキテクトと被っている範囲もあります
試験問題数は記載されていませんが、おそらくソリューションアーキテクトプロフェッショナルと同じで80問だと思います。(どこにも記載がないため推測)
試験時間は170分。時間を意識した試験対策も必要ですね。
ということで、サンプル問題を解いてみます。
※サンプル問題は、模範解答がないので私の推測となります。
ここ違う！とかあれば、コメント下さい。みんなで、正解を導いてみんなの参考にできたら嬉しいと考えています。
コメントお待ちしてます！
サンプル問題
問題1
あなたは Amazon EBS ボリュームを使用する Amazon EC2 上で実行されているアプリケーションサーバ
ー向けに、自動データバックアップソリューションを導入する業務を担当しています。単一障害点を回避し、デ
ータの耐久性を高めるために、分散データストアを使用してバックアップを取りたいと考えています。また、デ
ータを 1 時間以内に復元できるように、毎日のバックアップを 30 日間保存する必要があります。
アプリケーションサーバーでスケジューリングデーモンにより毎日スクリプトを実行し、この仕組みを実装する
には、どうすればよいですか?
A) ec2-create-volume API を呼び出すためのスクリプトを作成し、現在の日時を使用して Amazon EBS ボ
リュームにタグを付けて、バックアップデータを 2 つ目の Amazon EBS ボリュームにコピーする。
ec2-describe-volumes API を使用して既存のバックアップボリュームを列挙する。ec2-delete-volume
API を呼び出して、30 日より前の日時のタグが付けられているバックアップボリュームを削除する。
B) Amazon Glacier UploadArchive API を呼び出すためのスクリプトを作成し、現在の日時を使用してバッ
クアップアーカイブにタグを付ける。ListVaults API を使用して既存のバックアップアーカイブを列挙す
る。DeleteVault API を呼び出して、30 日より前の日時のタグが付けられているバックアップアーカイ
ブを削除する。
C) ec2-create-snapshot API を呼び出すためのスクリプトを作成し、現在の日時を使用して Amazon EBS
スナップショットにタグを付ける。ec2-describe-snapshots API を使用して既存の Amazon EBS スナ
ップショットを列挙する。ec2-delete-snapshot API を呼び出して、30 日より前の日時のタグが付けら
れている Amazon EBS スナップショットを削除する。
D) ec2-create-volume API を呼び出すためのスクリプトを作成し、現在の日時を使用して Amazon EBS ボ
リュームにタグを付けて、ec2-copy-snapshot API を使用して新しい Amazon EBS ボリュームにデータ
をバックアップする。ec2-describe-snapshot API を使用して既存のバックアップボリュームを列挙す
る。ec2-delete-snaphot API を呼び出して、30 日より前の日時のタグが付けられている Amazon EBS
バックアップボリュームを削除する。
回答
C
考察
要件としては
- EBSを日時バックアップ
- １時間以内に復元
- 分散データストアにバックアップをおく
A:バックアップ先にEBSを選択している。EBSはAZ内で冗長化されているが、地理的冗長化ではないため、分散データストアとはいえない
B:1時間以内に復元したい場合、Glacierは復元に時間がかかるため適さない
C:◯ 要件にあっている。※EBSスナップショットは裏の仕組みとしてhあS3に保管される(S3の画面からユーザがEBSのスナップショットを見たり操作できるわけではない)
D:ec2-copy-snapshotはEBSからスナップショットを作成するAPIではなく、スナップショット自体をコピーするAPI
問題2
あなたはモバイルデバイス向けの新しい写真共有アプリケーションを開発したベンチャー企業に勤めていま
す。ここ数か月にわたって、このアプリケーションの人気が高まってきています。このため、負荷の増大が原因
となって、アプリケーションのパフォーマンスが低下してしまいしました。
このアプリケーションでは、Auto Scaling が設定された PHP アプリケーションの層と、当初 AWS
CloudFormation を使用してデプロイされた MySQL RDS インスタンスから構成される、2 層アーキテクチャ
を採用しています。また、Auto Scaling group には、最小値 4 と最大値 8 が設定されています。インスタン
スの CPU 使用率が高いため、現在の希望する容量は 8 です。
分析の結果、パフォーマンス上の問題の原因は CPU 能力の制約であると確信しました。一方で、メモリの使用
率は低いままです。そのため、M3 汎用インスタンスから C3 コンピューティング最適化インスタンスに移行す
ることにします。
エンドユーザーに対するサービス中断を最小限に抑えながらこの変更をデプロイするには、どうしますか?
A) AWS マネジメントコンソールにサインインし、既存の起動設定をコピーして、C3 インスタンスを指定した
新しい起動設定を作成する。また、新しい起動設定を使用して Auto Scaling group を更新する。その後、
Auto Scaling によって、実行されているすべてのインスタンスのインスタンスタイプが更新される。
B) AWS マネジメントコンソールにサインインし、新しい C3 インスタンスタイプを使用して既存の起動設定
を更新する。Auto Scaling group に、AutoScaling RollingUpdate を指定した UpdatePolicy 属性を追加す
る。
C) AWS CloudFormation テンプレートで指定されている起動設定を、新しい C3 インスタンスタイプを使
用して更新する。そして、新しいテンプレートを使用して、スタックの更新を実行する。その後、Auto
Scaling によって、新しいインスタンスタイプに指定され、インスタンスが更新される。
D) AWS CloudFormation テンプレートで指定されている起動設定を、新しい C3 インスタンスタイプを使
用して更新する。また、Auto Scaling group に、AutoScalingRollingUpdate を指定した UpdatePolicy
属性を追加し、そして、新しいテンプレートを使用して、スタックの更新を実行する。
回答
D
考察
要件としては、
- Auto Scaling Groupで起動しているインスタンスのタイプをM3からC3へ移行したい
- サービス影響がないようにに実施したい
CloudFormationを利用したAutoScalingローリングアップデートの話
※ローリングアップデートを実際に利用する場合は、事前にAutoScalingをサスペンドさせる必要あり
A:Auto Scaling Groupの起動設定を更新しても、既存インスタンスは自動で更新されない。次から起動されるインスタンスが新しい起動設定で起動されるようになる
B:起動設定は更新できない。コピーして新規作成する必要がある。
C:既存インスタンスのインスタンスタイプを更新するにはAutoScalingRollingUpdateポリシーを指定する必要がある
D:◯ 正しい
問題3
ネットワーキング、IAM ポリシー、および複数の 3 層アプリケーションが関係する、複雑なシステムがあり
ます。この新システムの要件は現在も更新されているため、最終的な設計に含まれる AWS コンポーネントの数は
まだわかりません。
インフラストラクチャの自動化とバージョン管理を行えるように、AWS CloudFormation を利用してこれらの
AWS リソースの定義を始めたいとします。
俊敏性を備えた新環境を費用対効果と信頼性の高い方法で顧客に提供するために、AWS CloudFormation をど
のように利用しますか?
A) システムで必要なすべてのリソースが含まれる単一のテンプレートを手動で作成し、バージョン管理を
適用するテンプレートが 1 つだけになるようにする。
B) システムの論理パートごとに別個のテンプレートを複数作成し、AWS CloudFormation でネストされた
スタックを作成して、複数のテンプレートにバージョン管理を適用する。
C) システムの論理パートごとに別個のテンプレートを複数作成し、SDK がインストールされている Amazon
Elastic Compute Cloud (EC2) インスタンスを使用して出力を次々に提供して、より詳細に管理する。
D) ネットワーキングレイヤーは頻繁には変更されないため、これを Amazon Virtual Private Cloud (VPC) を使
用して手動で構成してから、その他すべての一時リソースを AWS CloudFormation を利用して定義する。
回答
B
考察
要件としては、
- CloudFormationを利用して、インフラのバージョン管理、構築の自動化を行いたい
- 俊敏性、費用対効果、信頼性を高くしたい
A:複雑で沢山利用しているAWSリソースを１つのテンプレートで利用する場合、テンプレートが複雑化し、俊敏性・信頼性が低下する可能性が高い
B:◯ 論理パートごとに分割するため、テンプレートもシンプルになり俊敏性・信頼性が向上する。（各チームで論理パートごのにテンプレートを他チームと非同期で管理できるため）
C:テンプレートにOutputsを記載することで、マネジメントコンソール上に情報を出力することができるため。専用のEC2は不要
D:インフラのバージョン管理をしたいという要件から外れる。VPCもバージョン管理すべき。
問題4
あなたは、Auto Scaling group に含まれる Amazon EC2 インスタンスが起動された後、設定とアプリケ
ーションの動的なデプロイを自動化するためのシステムを導入しました。このシステムでは、マスターノードの
ないスタンドアロン構成で機能する設定管理ツールを使用しています。アプリケーションの負荷は随時変化する
ため、新しいインスタンスは、インスタンスのオペレーティングシステムの起動後 3 分以内に稼働状態にする
必要があります。各デプロイステージが完了するまでかかる時間は以下のとおりです。
• 設定管理エージェントのインストール: 2 分
• アーティファクトを使用したインスタンスの設定: 4 分
• アプリケーションフレームワークのインストール: 15 分
• アプリケーションコードのデプロイ: 1 分
このようなスタンドアロンのエージェント構成でのデプロイを自動化するには、どの手順を採用する必要があり
ますか?
A) エージェントをインストールするための Amazon EC2 UserData スクリプトを使用して Auto Scaling
起動設定を構成し、Amazon S3 バケットから設定アーティファクトとアプリケーションコードを取得し
てから、エージェントを実行してインフラストラクチャとアプリケーションを設定する。
B) エージェント、設定アーティファクト、アプリケーションフレームワーク、コードといったすべてのコ
ンポーネントが事前にインストールされた、カスタム Amazon マシンイメージを作成する。エージェン
トを実行して起動時にシステムを設定するための起動スクリプトを作成する。
C) 設定管理エージェントとアプリケーションフレームワークが事前にインストールされた、カスタム
Amazon マシンイメージを作成する。Amazon S3 バケットから設定アーティファクトとアプリケーシ
ョンコードを取得するための Amazon EC2 UserData スクリプトを使用して Auto Scaling 起動設定を
構成してから、エージェントを実行してシステムを設定する。
D) Amazon EC2 API をポーリングして、Auto Scaling group 内で起動される新しいインスタンスの有無を
確認するためのウェブサービスを作成する。新しいインスタンスが認識されたら、エージェントをイン
ストールするためのリモートスクリプトを SSH 経由で実行し、設定アーティファクトとアプリケーシ
ョンコードを SCP でコピーして、最後にエージェントを実行してシステムを設定する。
回答
C
考察
要件としては、
- Auto Scalingで起動したインスタンスの動的デプロイを自動化する
- 3分以内に稼働状態にする
実際にできるのは、エージェントインストールと、アプリケーションコードのデプロイのみ
A:エージェントインストールで2分消費するため、その他の設定する時間がなくなる
B:アプリケーションコードもAMIに埋め込むため、動的なアプリケーションデプロイができない
C:◯ 動的にデプロイが実現でき、その他の事前に必要なインストールはAMIに埋め込んでいる
D:ポーリングを行う場合、ラグが発生するためデプロイ時間がなくなる可能性がある
問題5
継続的デプロイプロセスの一環として、アプリケーションには、新しい AMI を使用して本番環境にデプロ
イされる前に、I/O 負荷パフォーマンステストを実施します。このアプリケーションでは、インスタンスごとに
1 つの Amazon EBS PIOPS ボリュームを使用しており、一貫した I/O パフォーマンスが求められます。
I/O 負荷パフォーマンステストにおいて、適切な結果を繰り返し可能な方法で得るには、以下のうちどれを行う
必要がありますか?
A) テスト時の I/O ブロックサイズがランダムに選択されるようにする。
B) テスト前にすべてのブロックに対して読み取りを実行することで、Amazon EBS ボリュームの事前ウォ
ーミングが行われるようにする。
C) バックアップとして、Amazon EBS ボリュームのスナップショットが作成されるようにする。
D) Amazon EBS ボリュームが暗号化されるようにする。
E) テスト前にボリュームのスナップショットを作成することで、Amazon EBS ボリュームの事前ウォーミ
ングが行われるようにする。
回答
B
考察
EBSのウォーミングアップの話
EBSの新規作成時、またはスナップショットから復元した時、ストレージブロックの割り当てが行われる。ただし、アクセスしたタイミグでブロックのデータ削除（新規ボリュームじ）または、データの復元（スナップショット復元時）されるため準備時間(IOPSの5〜50%程度低下する)がかかる。
これを回避するには、事前に全ブロックに読み込みまたは書き込みを実施することで回避できる
問題6
あなたのソーシャルメディアマーケティングアプリケーションに、AWS Elastic Beanstalk で実行される
Ruby で記述されたコンポーネントが含まれています。このアプリケーションコンポーネントは、さまざまなマ
ーケティングキャンペーンを支援するために、ソーシャルメディアサイトにメッセージを投稿します。経営陣
は、マーケティングキャンペーンの有効性を過去および将来の取り組みと比較して分析するため、こうしたソー
シャルメディアのメッセージへの返信を記録するよう求めています。返信を読み取るためにソーシャルメディア
サイトの API と連携する新しいアプリケーションコンポーネントは、既に開発済みです。
履歴データを分析する際にいつでもアクセスできる堅牢なデータストアにソーシャルメディアの返信を記録する
には、どの手順を採用すべきですか?
A) Amazon EC2 インスタンスの Auto Scaling group に新しいアプリケーションコンポーネントをデプロ
イし、ソーシャルメディアサイトからデータを読み取って、そのデータを Amazon Elastic Block Store
を使用して保存し、AWS Data Pipeline によって Amazon Kinesis に公開して分析する。
B) 新しいアプリケーションコンポーネントを Elastic Beanstalk アプリケーションとしてデプロイし、ソー
シャルメディアサイトからデータを読み取って、そのデータを DynamoDB に保存し、Apache Hive と
Amazon Elastic MapReduce を併用して分析する。
C) Amazon EC2 インスタンスの Auto Scaling group に新しいアプリケーションコンポーネントをデプロ
イし、ソーシャルメディアサイトからデータを読み取って、そのデータを Amazon Glacier に保存し、
AWS Data Pipeline によって Amazon RedShift に公開して分析する。
D) 新しいアプリケーションコンポーネントを Amazon Elastic Beanstalk アプリケーションとしてデプロイし、
ソーシャルメディアサイトからデータを読み取って、そのデータを Amazon Elastic Block Store を使用して
保存し、Amazon Kinesis によって Amazon CloudWatch にデータをストリーミングして分析する。
回答
B
考察
要件は、
- 既存のアプリケーションの分析したい
- 履歴データにいつでアクセスでき、堅牢なデータストアに返信を記録したい
A:Kinesisは24時間しかデータを保存できないため永続性がない
B:◯
C:アーカイブストレージのため、いつでもアクセスできるストレージではない
D:そもそもKinesisからCloudWatchにデータストリーミングできない
問題7
前四半期の月々の請求額を確認したところ、経営陣は Amazon からの請求額全体が増加していることに気
付きました。あなたがこのコスト増加について調査した結果、新しいサービスの 1 つが、アプリケーションの
バケット内にあるすべてのオブジェクトのメタデータのキャッシュを構築するために、Amazon S3 に対して多
数の GET Bucket API 呼び出しを行っていることを発見しました。上司は、こうした GET Bucket API の新た
な呼び出しの数を減らすための、費用対効果に優れた新しい方法を考案するよう求めています。
このコストを軽減するには、どの手順を採用すべきですか?
A) オブジェクトの一覧を新しいバケットに自動的にプッシュするように Amazon S3 バケットのライフサ
イクルポリシーを更新し、この一覧を使用して、アプリケーションのバケットに関連付けられたオブジ
ェクトを確認する。
B) 新しい DynamoDB テーブルを作成する。新しい DynamoDB テーブルを使用して、Amazon S3 にア
ップロードされたすべてのオブジェクトに関するすべてのメタデータを保存する。新しいオブジェクト
がアップロードされるときは常に、DynamoDB にあるアプリケーションの内部的な Amazon S3 オブジ
ェクトメタデータのキャッシュを更新する。
C) Amazon SNS を使用して、新しいオブジェクトに関するすべてのメタデータを保存するように新しい
DynamoDB テーブルを自動的に更新する、新しい Amazon S3 オブジェクトに関する通知を作成する。
アプリケーションを Amazon SNS トピックにサブスクライブし、DynamoDB テーブルにある内部的な
Amazon S3 オブジェクトメタデータのキャッシュを更新する。
D) すべてのイメージを Amazon SQS にアップロードし、すべてのイメージを Amazon S3 に移動するよ
うに SQS ライフサイクルをセットアップして、アプリケーションに対する Amazon SNS 通知を開始
してアプリケーションの内部的な Amazon S3 オブジェクトメタデータのキャッシュを更新する。
E) すべてのイメージを ElastiCache ファイルキャッシュサーバーにアップロードする。すべてのファイルメタ
データを ElastiCache ファイルキャッシュサーバーから読み取るようにアプリケーションを更新し、すべて
のファイルを長期保存用の Amazon S3 にプッシュするように ElastiCache ポリシーを設定する。
回答
C
考察
要件は、
- AWSのコストを下げたい
- S3のメタデータを取得するAPIの回数を減らしたい
A:S3のライフサイクルポリシーは、オブジェクトの有効期限を設定するものなので用途が違う
B:アップロード→メタデータ取得API実行→dynamoに格納となり、結局APIをリクエストする必要がありコスト低下にはつながらない
C:◯ S3通知（メタデータ送付）→安価なSNSでメタデータをさらにDynamoDB書き込みアプリにプッシュ通知することで、S3へのリクエストを行わずにメタデータをDynamoDBへ書き込み可能※さらにLambdaを利用することでEC2インスタンスも不要となりさらに安価な構成にすることが可能
D:SQSを利用するとアップロードイメージ容量に新しく制限ができてしまう
E:イメージサイズが多くなると、キャッシュに全てのイメージをアップロードするのは大きなメモリサイズが必要となりコストが高くなる
問題8
チームで、ある AWS Elastic Beanstalk アプリケーションを担当しています。ビジネス上の要件として、
継続的なデプロイモデルに移行し、ダウンタイムなしで 1 日に何回もアプリケーションの更新をリリースする
必要があります。
これを実現しながら、緊急時に以前のバージョンにほぼ即座にロールバックできるようにするには、どうすべき
ですか?
A) Elastic Beanstalk 環境でローリング更新を有効にし、アプリケーションの起動を考慮した適切な停止時
間を設定する。
B) 新しいアプリケーションバージョンを実行する 2 つ目の Elastic Beanstalk 環境を作成し、これらの環
境の CNAME を交換する。
C) コードリポジトリ内の新しいアプリケーションバージョンをポーリングし、実行中の各 Elastic
Beanstalk インスタンスにダウンロードしてインストールするためのアプリケーションを開発する。
D) 新しいアプリケーションバージョンを使用する 2 つ目の Elastic Beanstalk 環境を作成し、HTTP 301
レスポンスコードで新しい環境にクライアントをリダイレクトするように既存の環境を設定する。
回答
B
考察
要件としては、
- AWS Elastic Beanstalkを利用した構成
- ダウンタイムなしに１日に何回もアプリをリリースしたい
- ほぼ即座にロールバックしたい
A:ローリング更新をすると、即座なロールバック対応ができない
B:◯ ダウンタイムなしのデプロイ、ロールバックが可能
C:実行中にデプロイするのダウンタイムが発生する
D:Beanstalk以外にHTTP301を返す構成が必要になる（旧環境を利用する場合は、旧環境を破棄できなくなる）
問題9
あなたの現在のログ分析用アプリケーションでは、ウェブアプリケーションの上位 10 名のユーザーに関す
るレポートを生成するまでに 4 時間以上かかります。あなたは、この情報をリアルタイムで報告できるシステ
ムを導入し、レポートを常に最新の状態に維持し、ウェブアプリケーションのリクエスト数の増加に対応するよ
う求められています。
この要件を満たすことができる、費用対効果に優れた方法を選択してください。
A) データを CloudWatch ログにパブリッシュし、自動スケーリングを行って負荷にオンデマンドで対応す
るようにアプリケーションを設定する。
B) ログデータを Amazon S3 バケットにパブリッシュする。AWS CloudFormation を使用して Auto
Scaling group を作成する。このグループによって、Amazon S3 に保存されているログファイルを取得
するように設定されたポストプロセッシングアプリケーションをスケールする。
C) ログデータを Amazon Kinesis データストリームに公開し、ログデータを処理するように設定されたロ
グ処理用アプリケーションをサブスクライブする。
D) Amazon EMR クラスターのサイズを増やすように Auto Scaling group を設定する。
E) マルチ AZ Amazon RDS MySQL クラスターを作成し、ログデータを MySQL に書き込んで、ユーザー
数に関する必要な情報を取得するためのマップリデュースジョブを実行する。
回答
C
考察
要件としては、
- ログを解析して、リアルタイムでレポートを表示したい
- Webアプリケーションのリクエストが増加してもログ解析に遅延が発生しない
- 費用対効果にすぐれている
A:検索・ソート等できないため、解析処理をするのが難しい
B:ログデータをある一定の間隔でしか取得できないため、リアルタイム性がない
C:◯ アクセスが増加してもkinesisによりデータ受信のスケール性がある、また費用も安くできる。
D:EMRを常に起動しておく必要があり、費用が高くなる
E:MapReduceではRDSを直接利用できない。また、マルチAZのため費用が高くなる
問題10
サードパーティのサプライヤへの注文を処理するあなたのアプリケーションは、単一の Amazon EC2 イ
ンスタンス上で実行されています。注文は Amazon SQS キューから取得され、5 分ごとに一括処理されます。
ビジネス上の要件として、処理における遅延が 1 時間を超えてはなりません。週に約 3 回、アプリケーション
で障害が発生して注文の処理が停止し、手動での再起動が必要になります。
このアプリケーションの障害耐性を、費用対効果に優れた方法で高めるには、どの手順を採用すべきですか?（2 つ選
択してください）
A) 処理用インスタンスを監視し、障害が検出された場合にインスタンスを再起動するように設定された、
2 つ目の「ウォッチドッグ」インスタンスを作成する。
B) 処理を実行するように設定されたインスタンスを起動するための Auto Scaling 起動設定を作成する。
最小数および最大数として 1 が指定された起動設定を使用する、Auto Scaling group を作成する。
C) 処理を_実行するように設定されたインスタンスを起動するための Auto Scaling 起動設定を作成する。最
小数として 2 が、最大数として 10 が指定された起動設定を使用し、Amazon SQS キューのサイズに
基づいてスケールする、Auto Scaling group を作成する。
D) ロードバランサーを作成し、インスタンスを Elastic Load Balancing に登録する。処理を実行するアプリケ
ーションの HTTP エンドポイントを呼び出すように Elastic Load Balancing ヘルスチェックを設定する。
E) カスタム CloudWatch メトリックスと InstanceId ディメンションを送信するように処理用アプリケー
ションを変更する。メトリックスで Insufficient 状態が 10 分間続いた場合に、インスタンスを終了す
るための Amazon EC2 アクションを実行するように設定された CloudWatch アラームを作成する。
回答
C,E
考察
要件としては、
- SQSのキューを５分毎に一括処理
- 処理遅延が1時間を超えてはいけない
- アプリケーション障害が週３回発生し、手動で再起動しているため自動で復旧するようにしたい
- 費用対効果を高めたい
A:ウォッチドック専用のインスタンスを追加する必要があり、費用対効果が低い。またウォチっドック用のサーバ障害を考慮する必要がでてくる
B:インスタンス障害やキューが増加した場合に、処理遅延が発生する可能性がある
C:◯ キュー増加に対応でき、処理遅延を防げる
D:SQSから疎結合にバッチを実行するという観点から、ELBは不要
E:◯ カスタムメトリクスでアプリレベルのヘルスチェックを実施できる
最後に
間違い有りましたら、遠慮せずコメントお願いします！
参考URL
http://media.amazonwebservices.com/jp/certification/AWS_certified_DevOps_Engineer_Professional_SampleExam.pdf
http://aws.amazon.com/jp/certification/certified-devops-engineer-professional/