AWS認定DevOpsエンジニアプロフェッショナル【DOP-C02版】100題 問題集全問解答＋全問解説付き
AWS認定DevOpsエンジニアプロフェッショナル【DOP-C02版】の過去問100題を全問解答＋全問解説付き
AWS Certified DevOps Engineer - Professional(DOP-C02) の最新の問題になります。
筆者が実際に受験して、問題を収集し解答とその解説を全問付けております。
問題数は合計100題。
実際に受験し、重複問題や類似問題を削除しています。
この100問の問題の解答を理解できれば、ほぼ間違いなく、合格すると思います。
ここから問題と解答/解説になります。
100題、全問解答＋全問解説付きになります。
1.
DevOpsチームがAWS上でマイクロサービスアーキテクチャを採用しているアプリケーションのデプロイメントプロセスを自動化したいと考えています。複数のマイクロサービスが独立して更新されるべきであり、それぞれが異なるデプロイメント戦略を持つ可能性があります。以下のAWSサービスのうち、この要件を最も効果的にサポートするものはどれですか？
A. AWS CodeCommit
B. AWS CodeBuild
C. AWS CodePipeline
D. Amazon ECS
解答: C. AWS CodePipeline
解説:
A. AWS CodeCommit - 不正解。AWS CodeCommitは、セキュアなGitベースのリポジトリを提供するマネージドソースコントロールサービスです。コードのバージョン管理には有用ですが、デプロイメントプロセスの自動化や異なるデプロイメント戦略の管理には直接対応していません。
B. AWS CodeBuild - 不正解。AWS CodeBuildは、コンパイル、テスト、パッケージ化のプロセスを自動化する完全マネージド型のビルドサービスです。ビルドプロセスには重要ですが、マイクロサービスの独立したデプロイメントを管理する機能は提供していません。
C. AWS CodePipeline - 正解。AWS CodePipelineは、高速で信頼性の高いアプリケーションとインフラストラクチャのアップデートを自動化する連続デリバリーサービスです。複数のステージを持つワークフローを設計することができ、各マイクロサービスに対して独自のデプロイメント戦略を適用することが可能です。これにより、DevOpsチームはマイクロサービスごとに異なるデプロイメントパイプラインを容易に管理できます。
D. Amazon ECS - 不正解。Amazon Elastic Container Service (ECS)は、コンテナ化されたアプリケーションのデプロイ、管理、スケールを容易にする高度にスケーラブルなコンテナ管理サービスです。マイクロサービスアーキテクチャの実行環境としては適していますが、デプロイメントプロセスの自動化や異なるデプロイメント戦略の管理に特化したサービスではありません。
2.
DevOps エンジニアは、Amazon EC2 および Amazon RDS MySQL で実行されているワークロードのモニタリングを実装する必要があります。監視には以下が含まれている必要があります。
Amazon EC2 のアプリケーション ログとオペレーティング システムの指標
インスタンス
Amazon RDS のデータベース ログとオペレーティング システムの指標
データベース
エンジニアはどの手順を実行する必要がありますか?
A. EC2 インスタンスに Amazon CloudWatch エージェントをインストールし、アプリケーション ログとオペレーティング システムのメトリックを CloudWatch に送信するようにエージェントを構成します。RDS 拡張モニタリングを有効にし、RDS インスタンスを変更してデータベース ログを CloudWatch Logs に発行します。
B. EC2 インスタンスに Amazon CloudWatch Logs エージェントをインストールし、アプリケーション ログを CloudWatch に送信するように設定します。
C. EC2 および RDS インスタンスでスケジュールされたタスクをセットアップして、オペレーティング システムのメトリックとアプリケーションおよびデータベースのログを Amazon S3 バケットに入れます。オブジェクトがバケットに入れられるたびにエラーを監視する AWS Lambda 関数を呼び出すイベントをバケットに設定します。
D. EC2 および RDS インスタンスに Amazon CloudWatch エージェントをインストールします。オペレーティング システムのメトリクスとアプリケーションおよびデータベースのログを CloudWatch に送信するようにエージェントを構成します。
正解：A
解説は以下の通りです：
A. EC2インスタンスにAmazon CloudWatchエージェントをインストールし、アプリケーションログとオペレーティングシステムのメトリックをCloudWatchに送信するようにエージェントを構成します。RDS拡張モニタリングを有効にし、RDSインスタンスを変更してデータベースログをCloudWatch Logsに発行します。これが正解です。Amazon CloudWatchエージェントはEC2インスタンスでのアプリケーションログとメトリクスの収集に使用されます。また、RDS拡張モニタリングとRDSインスタンスの変更を通じてデータベースログをCloudWatch Logsに送信することが可能です。
B. EC2インスタンスにAmazon CloudWatch Logsエージェントをインストールし、アプリケーションログをCloudWatchに送信するように設定します。この選択肢は部分的に正しいですが、オペレーティングシステムのメトリクスの収集やRDSの監視に関しての言及がありません。
C. EC2およびRDSインスタンスでスケジュールされたタスクをセットアップして、オペレーティングシステムのメトリックとアプリケーションおよびデータベースのログをAmazon S3バケットに入れます。オブジェクトがバケットに入れられるたびにエラーを監視するAWS Lambda関数を呼び出すイベントをバケットに設定します。この方法は非常に複雑であり、Amazon CloudWatchや他の簡単なツールを使用する標準的な方法よりも効率が悪いです。
D. EC2およびRDSインスタンスにAmazon CloudWatchエージェントをインストールします。オペレーティングシステムのメトリクスとアプリケーションおよびデータベースのログをCloudWatchに送信するようにエージェントを構成します。この選択肢は誤りです。Amazon RDSインスタンスに直接CloudWatchエージェントをインストールすることはできません。
したがって、正解はAです。これはEC2インスタンスおよびRDSインスタンスでのモニタリングを実装するための正しいアプローチを提供します。
3.
Amazon S3 をデータ ストアとして使用するコード リポジトリがあります。セキュリティ管理の最近の監査中に、Amazon S3 バケット内のデータの整合性を維持することについていくつかの懸念が提起されました。仮想プライベート クラウド内の Amazon EC2 で実行されているアプリケーションに、Amazon S3 からコードを安全にデプロイすることに関して、別の懸念が提起されました。
これらの懸念を軽減するために実施できる対策にはどのようなものがありますか? 2つの答えを選択してください。
A. AWS Data Pipeline を使用して、Amazon S3 バケット内のデータを毎週 Amazon Glacier にライフサイクルします。
B. AWS Data Pipeline と多要素認証を使用して、Amazon .5.3 バケットから Amazon EC2 インスタンスにコードを安全にデプロイします。
C. Amazon 53 バケットにアクセスする権限を持つ Amazon Identity and Access Management ロールを作成し、このロールでアプリケーションのすべての Amazon EC2 インスタンスを起動します。
D. オブジェクトを削除してバケットのバージョニングを有効にするために、多要素認証を必要とする条件ステートメントを含む Amazon S3 バケット ポリシーを追加します。
E. 条件ステートメントを含む Amazon S3 バケット ポリシーを追加して、RFC 1918 IP アドレスを持つ Amazon EC2 インスタンスからのアクセスのみを許可し、バケットのバージョニングを有効にします。
F. 構成管理サービスを使用して、AWS Identity and Access Management ユーザー認証情報を Amazon EC2 インスタンスにデプロイします。
これらの認証情報を使用して、コードをデプロイするときに Amazon S3 バケットに安全にアクセスします。
正解：C,D
解説は以下の通りです：
A. AWS Data Pipelineを使用して、Amazon S3バケット内のデータを毎週Amazon Glacierにライフサイクルします。これはデータの長期保存に役立ちますが、データの整合性や安全なデプロイメントに直接関係しません。
B. AWS Data Pipelineと多要素認証を使用して、Amazon S3バケットからAmazon EC2インスタンスにコードを安全にデプロイします。この選択肢は、実際のセキュリティ懸念に直接対処していないため、誤りです。
C. Amazon S3バケットにアクセスする権限を持つAmazon Identity and Access Managementロールを作成し、このロールでアプリケーションのすべてのAmazon EC2インスタンスを起動します。これはセキュリティのベストプラクティスであり、EC2インスタンスからS3バケットへの安全なアクセスを提供します。正解です。
D. オブジェクトを削除してバケットのバージョニングを有効にするために、多要素認証を必要とする条件ステートメントを含むAmazon S3バケットポリシーを追加します。これはデータの整合性を保護するための有効な方法です。正解です。
E. 条件ステートメントを含むAmazon S3バケットポリシーを追加して、RFC 1918 IPアドレスを持つAmazon EC2インスタンスからのアクセスのみを許可し、バケットのバージョニングを有効にします。これはバケットへのアクセスを制限するものですが、提案されているアプローチは特定の状況では有用ですが、このシナリオには完全には適用されません。
F. 構成管理サービスを使用して、AWS Identity and Access Managementユーザー認証情報をAmazon EC2インスタンスにデプロイします。これらの認証情報を使用して、コードをデプロイするときにAmazon S3バケットに安全にアクセスします。このアプローチはセキュリティリスクを高める可能性があり、IAMロールを使用する方が好ましいです。
したがって、正解はCとDです。これらはAmazon S3バケット内のデータの整合性を保護し、Amazon EC2インスタンスからの安全なコードデプロイメントを可能にするための効果的な対策です。
4.
ある企業は、一部の IAM ユーザーが、Git リポジトリ ホスティング サービスにプッシュされた構成ファイルに AWS アクセス キーを保存していることを発見しました。公開された AWS アクセス キーが使用されるのを防ぎながら、必要な管理オーバーヘッドが最も少ないソリューションはどれですか?
A. AWS Trusted Advisor を設定し、Trusted Advisor をイベント ソースとして使用する Amazon CloudWatch Events ルールを作成します。AWS Lambda 関数をターゲットとして呼び出すように CloudWatch イベント ルールを設定します。公開されたアクセス キーが Lambda 関数で見つかった場合は、アクセス キーを無効にして使用できないようにします。
B. Amazon Inspector を使用して、キーがオンラインでいつ公開されたかを検出します。キーが公開されたときに、Amazon Inspector が Amazon SNS トピックに通知を送信するようにします。SNS トピックにサブスクライブする AWS Lambda 関数を作成して、キーが属する IAM ユーザーを無効にし、キーを使用できないように削除します。
C. アカウント内のすべての AWS アクセス キーのリストを作成し、Git リポジトリ ホスティング サービスで各キーを検索するアプリケーションを構築します。一致が見つかった場合は、関連付けられたアクセス キーを無効にするようにアプリケーションを構成します。次に、アプリケーションを AWS Elastic Beanstalk ワーカー環境にデプロイし、1 時間ごとにアプリケーションを呼び出す定期的なタスクを定義します。
D. キーがオンラインでいつ公開されたかを検出する AWS Config ルールを作成します。AWS Config が変更通知を SNS トピックに送信する方法。SNS トピックにサブスクライブする AWS Lambda 関数を設定して、AWS Config から送信される通知を確認し、アクセス キーを使用できないように無効にします。
正解：D
解説です：
A. AWS Trusted Advisorを設定し、Trusted Advisorをイベントソースとして使用するAmazon CloudWatch Eventsルールを作成し、AWS Lambda関数をターゲットとして呼び出すようにCloudWatchイベントルールを設定します。公開されたアクセスキーがLambda関数で見つかった場合は、アクセスキーを無効にして使用できないようにします。この方法はAWSアクセスキーの公開を検出するためのものですが、Gitリポジトリでの公開を直接検出するものではありません。
B. Amazon Inspectorを使用して、キーがオンラインでいつ公開されたかを検出します。キーが公開されたときに、Amazon InspectorがAmazon SNSトピックに通知を送信するようにします。SNSトピックにサブスクライブするAWS Lambda関数を作成して、キーが属するIAMユーザーを無効にし、キーを使用できないように削除します。しかし、Amazon Inspectorは主にセキュリティ評価と脆弱性管理のためのサービスであり、公開されたアクセスキーの検出には直接対応していません。
C. アカウント内のすべてのAWSアクセスキーのリストを作成し、Gitリポジトリホスティングサービスで各キーを検索するアプリケーションを構築します。一致が見つかった場合は、関連付けられたアクセスキーを無効にするようにアプリケーションを構成します。次に、アプリケーションをAWS Elastic Beanstalkワーカー環境にデプロイし、1時間ごとにアプリケーションを呼び出す定期的なタスクを定義します。この方法は機能する可能性がありますが、かなりの管理オーバーヘッドがあり、効率的ではありません。
D. キーがオンラインでいつ公開されたかを検出するAWS Configルールを作成します。AWS Configが変更通知をSNSトピックに送信する方法。SNSトピックにサブスクライブするAWS Lambda関数を設定して、AWS Configから送信される通知を確認し、アクセスキーを使用できないように無効にします。これは効率的で自動化されたソリューションであり、管理オーバーヘッドが最も少ない方法です。正解です。
結論として、Dの選択肢が最も効率的で、必要な管理オーバーヘッドが最も少ないソリューションです。
5.
Cloudwatch Logs と組み合わせて使用できるサービスは次のうちどれですか。以下のオプションから最も実行可能なサービスを 3 つ選択してください
A. Amazon キネシス
B. Amazon S3
C. Amazon SQS
D. アマゾン ラムダ
正解：A,B,D
A. Amazon Kinesis: CloudWatch Logsと組み合わせて使用することができます。CloudWatch LogsからのログデータをAmazon Kinesisにストリームすることで、リアルタイムのデータ分析やその他の処理を実行することが可能です。このため、選択肢Aは実行可能なサービスです。
B. Amazon S3: CloudWatch Logsと組み合わせて使用することが可能です。CloudWatch LogsからログデータをAmazon S3にエクスポートし、長期ストレージや他の分析サービスでの使用のために保存することができます。このため、選択肢Bも実行可能なサービスです。
C. Amazon SQS: 一般的に、CloudWatch Logsは直接Amazon SQSと組み合わせて使用されることは少ないです。CloudWatch Logsから直接SQSにデータを送信するネイティブな統合は存在しません。しかし、間接的に、例えばLambdaを介してCloudWatch LogsのデータをSQSに送ることは可能ですが、他のオプションと比較すると、直接的な統合はありません。
D. Amazon Lambda: CloudWatch Logsと直接統合して使用することができます。CloudWatch Logs内の特定のパターンやイベントが発生した時にLambda関数をトリガーすることが可能です。これはログデータのリアルタイム処理や応答に非常に有効です。したがって、選択肢Dも実行可能なサービスです。
6.
報道機関は、20 TB のビデオ アーカイブを AWS に移行することを計画しています。ファイルはめったにアクセスされませんが、
その場合は、事前にリクエストを行い、3 時間から 5 時間の時間枠で取得できます。しかし、
ニュース速報がある場合、編集者は数分以内にアーカイブされた映像にアクセスする必要があります。
最も低いストレージ コストを提供しながら、この組織のニーズを満たすストレージ ソリューションはどれですか?
A. アーカイブを Amazon Glacier に保存し、すべてのコンテンツに対して標準の取得を使用します。
B. アーカイブを Amazon S3 低冗長ストレージに保存します。
C. アーカイブを Amazon Glacier に保存し、必要に応じて迅速な取得のために追加料金を支払います。
D. ライフサイクル ポリシーを使用して Amazon S3 にアーカイブを保存し、30 日後にこれを S3 低頻度アクセスに移動します。
正解：A
解説します。
A. アーカイブをAmazon Glacierに保存し、すべてのコンテンツに対して標準の取得を使用します。
Amazon Glacierは、長期アーカイブ用の低コストストレージサービスです。標準取得オプションは、数時間内にデータを取得できます。これはコスト効率が良く、めったにアクセスされないファイルに適しています。ただし、ニュース速報の場合の数分以内のアクセス要件を満たすことはできません。それでも、低コストと3-5時間の取得時間枠を考慮すると、このオプションが最も適していると考えられます。
B. アーカイブをAmazon S3低冗長ストレージに保存します。
S3低冗長ストレージ（Reduced Redundancy Storage）は、データの耐久性が少し低いが、コスト効率の良いストレージオプションでしたが、現在は廃止されているため、このオプションは適切ではありません。
C. アーカイブをAmazon Glacierに保存し、必要に応じて迅速な取得のために追加料金を支払います。
Glacierの迅速な取得オプションは、数分内にデータを取得できますが、そのための追加料金がかかります。報道機関の場合、大量のデータがあり、頻繁に迅速な取得を必要とする場合、コストがかなり高くなる可能性があります。このオプションは、速報時のニーズは満たしますが、最も低いストレージコストを提供するとは言えません。
D. ライフサイクルポリシーを使用してAmazon S3にアーカイブを保存し、30日後にこれをS3低頻度アクセスに移動します。
S3標準-低頻度アクセス（S3 Standard-IA）は、低コストで、必要なときにすぐにアクセスできるオプションですが、S3標準よりも高い取得コストがかかります。頻繁にアクセスされないデータには適していますが、Glacierよりも高コストです。
7.
ある企業がAWS上でマイクロサービスアーキテクチャを採用しています。彼らはアプリケーションのデプロイメントプロセスを自動化し、各マイクロサービスの独立したスケーリングと更新を可能にしたいと考えています。また、デプロイメント中にサービスのダウンタイムを最小限に抑え、リアルタイムでデプロイメントの状態を監視したいと考えています。この目的を達成するために企業が利用すべきAWSサービスはどれですか？
A. AWS CodePipeline + AWS CodeDeploy
B. Amazon ECS + AWS Fargate
C. AWS Lambda + Amazon API Gateway
D. Amazon EC2 Auto Scaling + Amazon CloudWatch
正解: A. AWS CodePipeline + AWS CodeDeploy
解説:
A. AWS CodePipelineは、連続的なインテグレーションとデリバリーのためのサービスで、コードの変更からデプロイメントまでのプロセスを自動化します。AWS CodeDeployは、アプリケーションのデプロイメントを自動化するサービスで、サーバー、Lambda関数、およびコンテナーを含む様々なターゲットへのデプロイをサポートします。これらのサービスを組み合わせることで、デプロイメントプロセスを自動化し、ダウンタイムを最小限に抑えながら、リアルタイムでの監視が可能になります。
B. Amazon ECS (Elastic Container Service) は、コンテナ化されたアプリケーションの管理を簡単にするサービスで、AWS FargateはサーバーレスコンピュートエンジンでECSと組み合わせて使用されます。これらはマイクロサービスのスケーリングと管理に適していますが、デプロイメントプロセスの自動化やリアルタイム監視にはCodePipelineやCodeDeployの方が直接適しています。
C. AWS Lambdaは、サーバーレスコンピューティングを提供し、Amazon API GatewayはLambda関数へのHTTPリクエストをルーティングします。これらは特定のユースケースには適していますが、デプロイメントの自動化やリアルタイム監視の観点ではAの選択肢がより適しています。
D. Amazon EC2 Auto Scalingはインスタンスの自動スケーリングを提供し、Amazon CloudWatchはリソースとアプリケーションの監視を提供します。これらはインフラストラクチャのスケーリングと監視には有用ですが、アプリケーションのデプロイメントプロセスの自動化に特化しているわけではありません。
このシナリオでは、マイクロサービスアーキテクチャのデプロイメントプロセスを自動化し、ダウンタイムを最小限に抑えながらリアルタイムで監視する目的に、AWS CodePipelineとAWS CodeDeployの組み合わせが最適です。
8.
Code Deploy サービスで EC2 インスタンスを使用する場合、EC2 インスタンスが Code Deploy で確実に機能するための前提条件の一部は次のうちどれですか。以下の選択肢から2つの答えを選択してください
A. 1AM ロールがインスタンスにアタッチされていることを確認して、CodeDeploy サービスと連携できるようにします。
B. EC2 インスタンスが拡張ネットワーキングで構成されていることを確認します
C. EC2 インスタンスがデフォルト VPC に配置されていることを確認します
D. CodeDeploy エージェントが EC2 インスタンスにインストールされていることを確認します
正解：A,D
解説します：
A. IAMロールがインスタンスにアタッチされていることを確認して、CodeDeployサービスと連携できるようにします。
これは正しいです。EC2インスタンスは、CodeDeployとの通信や他のAWSサービスとのやり取りを行うために、適切なIAMロールを持っている必要があります。このロールはCodeDeployに必要な権限を提供します。
B. EC2インスタンスが拡張ネットワーキングで構成されていることを確認します。
これはCodeDeployの前提条件ではありません。拡張ネットワーキングは、特定のネットワーク関連のパフォーマンス要件がある場合に関連しますが、CodeDeployの機能には直接影響しません。
C. EC2インスタンスがデフォルトVPCに配置されていることを確認します。
これもCodeDeployの必要条件ではありません。EC2インスタンスはデフォルトVPCにある必要はなく、カスタムVPC内でも動作します。重要なのは、CodeDeployサービスと通信できることです。
D. CodeDeployエージェントがEC2インスタンスにインストールされていることを確認します。
これは正しいです。CodeDeployを使用してEC2インスタンスにアプリケーションをデプロイするためには、インスタンスにCodeDeployエージェントがインストールされている必要があります。このエージェントは、デプロイメントの実行と監視を行います。
9.
ソリューション アーキテクトは、Amazon Redshift を使用して回復力のあるデータ ウェアハウスを構築する必要があります。アーキテクトは、
別のリージョンで Redshift クラスターを再構築します。
アーキテクトは、この要件に対処するためにどのアプローチを取ることができますか?
A. Redshift クラスターを変更して、Amazon EBS ボリュームのスナップショットを毎日作成し、それらを共有します。
他のリージョンとのスナップショット。
B. Redshift クラスターを変更し、クロスリージョン スナップショットを他のリージョンに構成します。
C. Redshift クラスターを変更し、バックアップを構成し、Amazon S3 バケットを別の場所に指定します。
D. Redshift クラスターを変更して、AWS Snowball をエクスポート モードで使用し、データを他のクラスターに配信します。
正解：A
解説します：
A. Redshiftクラスターを変更して、Amazon EBSボリュームのスナップショットを毎日作成し、それらを他のリージョンと共有します。 これは実際には誤りです。RedshiftはEBSボリュームを直接使用しないため、EBSボリュームのスナップショットを取ることはできません。代わりに、Redshiftは自動的にデータをバックアップし、オプションでクロスリージョンスナップショットを設定することができます。
B. Redshiftクラスターを変更し、クロスリージョンスナップショットを他のリージョンに構成します。 これは、データウェアハウスの耐障害性を高めるための適切なアプローチです。Redshiftクロスリージョンスナップショットは、データを別のリージョンに自動的に複製することで、災害復旧のためのデータ保護を提供します。
C. Redshiftクラスターを変更し、バックアップを構成し、Amazon S3バケットを別の場所に指定します。 Redshiftは自動的にS3にバックアップを作成しますが、このバックアップのS3バケットの場所を指定するオプションはありません。
D. Redshiftクラスターを変更して、AWS Snowballをエクスポートモードで使用し、データを他のクラスターに配信します。 これは非効率的で、回復力のあるソリューションとは考えられません。Snowballは大量のデータ移行に使用されるものであり、定期的なバックアップやデータ同期には適していません。
10.
AWS Auto Scaling の場合、既存のインスタンスがスタンバイ状態を離れた後に最初に入る遷移状態は何ですか?
A. 取り外し
B. 終了中:待機
C. 保留中
D. スタンバイに入る
正解：C
解説します：
A. 取り外し
これは不正解です。取り外し状態は、Auto Scalingグループからインスタンスが削除される前の状態を指します。スタンバイから移行するときには適用されません。
B. 終了中:待機
これも不正解です。終了中:待機状態は、インスタンスが終了プロセスの一部として待機している状態です。スタンバイからの移行とは関連ありません。
C. 保留中
これが正解です。スタンバイ状態を離れると、インスタンスは通常「保留中」状態に入ります。これは、インスタンスがAuto Scalingグループによって開始され、初期化される前の状態です。スタンバイから出たインスタンスは、通常の運用状態に戻る前にこのステートを経由します。
D. スタンバイに入る
これは不正解です。スタンバイに入る状態は、インスタンスがアクティブな運用からスタンバイモードに移行するときの状態です。この質問では、スタンバイ状態から移行する状態が尋ねられています。
この記事が気に入ったらサポートをしてみませんか？