10問中 0問が回答されています
質問:
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
無料レッスン・テストを受講するにはフリーコース(無料)に登録してください。
まず、次の操作を完了する必要があります:
正解数 0/問題数10
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【DOP-2001】ある企業は AWS CodePipeline を使用して us-east-1 リージョンのアプリケーションをデプロイしています。パイプラインは AWS CodeBuild でビルドしたアーティファクトを AWS CodeDeploy でデプロイします。事業拡大に伴い、同じパイプラインから ap-northeast-1 リージョンの Amazon EC2 環境へも同じアーティファクトをデプロイする必要が生じました。DevOps エンジニアは既存のパイプラインにデプロイステージのアクションを追加することを検討しています。この要件を満たすために必要な手順の組み合わせを選択してください。(2つ選択)
CodePipeline が別リージョンのリソースを操作するとき、ビルド成果物はどのリージョンの S3 バケットに置かれている必要があるでしょうか。アクションを追加するだけで、アーティファクトは自動的に対象リージョンへ届くのかを考えてみましょう。また CodeDeploy のアプリケーションとデプロイグループは、リージョンをまたいで参照できるサービスでしょうか。「入れ物の準備」と「実行の指示」という2つの側面から、どの組み合わせで要件の全範囲をカバーできるかに注目してください。
【DOP-2002】ある DevOps エンジニアは、複数のリージョンにデプロイされる Web アプリケーションのリリースを AWS CodePipeline で管理しています。パイプラインは AWS CodeDeploy でリージョンごとにアプリケーションを更新します。エンジニアは、あるリージョンへのデプロイ完了後に、そのリージョンのエラー率とレイテンシーを監視する Amazon CloudWatch アラームの状態を一定時間確認し、アラーム状態であれば次のリージョンへ進む処理を中断させたいと考えています。アラームの評価ロジックは今後の要件変更に応じて拡張する予定です。これらの要件を満たす方法を選択してください。
CodePipeline には CloudWatch アラームを直接評価する組み込みアクションが存在しません。では「一定時間待機してからアラームを評価する」ロジックをステージ間に挟むには、どのアクションタイプを使うでしょうか。
待機時間の間、コンピュートリソースを占有し続ける方式と、状態遷移として待機を表現する方式では、時間上限やコストにどのような差が出るか比較してみましょう。
さらに「評価ロジックを今後拡張する予定」という条件に注目してください。分岐や再試行をコード修正なしに追加できるのはどちらでしょうか。
【DOP-2003】ある企業は、開発アカウントで AWS CodePipeline を実行し、AWS CodeBuild でビルドしたアーティファクトを本番アカウントの Amazon ECS サービスへ AWS CodeDeploy でデプロイしています。パイプラインのアーティファクトストアは開発アカウントの Amazon S3 バケットで、既定の暗号化設定のままです。DevOps エンジニアがクロスアカウントのデプロイステージを追加したところ、本番アカウント側でアーティファクトの取得が失敗しました。この問題を解決する手順の組み合わせを選択してください。(2 つ選択)
クロスアカウントでアーティファクトを取得するには、S3 オブジェクトを「読める」ことと、暗号化されたオブジェクトを「復号できる」ことの2つが揃う必要があります。既定の暗号化のままだと、どちらが欠けるでしょうか。AWS マネージドキーはキーポリシーを編集できるかどうかを思い出してみましょう。そして本番アカウント側は、どの主体としてバケットにアクセスするのかに注目してください。
【DOP-2004】ある企業の DevOps エンジニアは、Web アプリケーションのリリースを自動化しています。アプリケーションは、Amazon EC2 上で稼働する API サーバーと、Amazon S3 の静的ウェブサイトホスティングで配信されるフロントエンドの 2 つのコンポーネントで構成されています。ソースコードは別々のリポジトリで管理されています。フロントエンドの更新頻度は API サーバーより高く、フロントエンドの変更時に API サーバーのデプロイを発生させたくないという要件があります。また、各コンポーネントのビルド成果物は個別に検証してからデプロイする必要があります。これらの要件を満たす構成を選択してください。
更新頻度の異なる 2 つのコンポーネントを「一方の変更で他方を動かさない」ようにするには、パイプラインを 1 本にまとめるべきか、分けるべきか考えてみましょう。AWS CodePipeline はソースの変更を検知してパイプライン全体を起動する仕組みであることに注目してください。また、EC2 への配置と S3 バケットへの静的ファイル配置では、利用できるデプロイアクションプロバイダーが異なります。ビルドの中でファイルをコピーする方法と、独立したデプロイステージを設ける方法の違いも比較してみましょう。
【DOP-2005】ある企業の DevOps エンジニアは、AWS CloudFormation テンプレートをリポジトリで管理し、AWS CodePipeline で 2 つのステージに分けてデプロイしています。最初のステージでネットワークスタックを作成し、そこで生成される VPC ID とサブネット ID を、後続ステージのアプリケーションスタックのパラメータとして渡す必要があります。現在はネットワークスタック作成後に担当者が出力値を手作業で確認し、後続のテンプレート設定ファイルを書き換えてからパイプラインを再実行しています。この受け渡しをパイプライン内で自動化する必要があります。これらの要件を満たす手順の組み合わせを選択してください。(2 つ選択)
値を「渡す側」と「受け取る側」の двух段構えで考えてみましょう。まずスタックが値を外部に公開するには、テンプレート内のどのセクションが必要でしょうか。次に、CodePipeline のアクションはその公開された値をどのような記法で後続アクションに引き継げるでしょうか。中継用の仕組みを自作せずに済む、CodePipeline 標準の変数機構に注目してください。どの組み合わせで受け渡しの全範囲をカバーできるかを見極めることが鍵です。
【DOP-2006】ある企業の DevOps エンジニアは、AWS CodePipeline でパイプラインを新規に構築しました。ソースステージは Git リポジトリ、続くステージは AWS CodeBuild と AWS CodeDeploy で構成されています。パイプラインの初回実行は正常に完了し、アプリケーションはデプロイされました。しかし開発者が追加のコミットをリポジトリの追跡対象ブランチにプッシュしても、パイプラインの実行は開始されません。マネジメントコンソールにはエラーも失敗した実行履歴も表示されず、パイプラインは待機状態のままです。パイプラインを手動で開始すると最新のコミットが正常にデプロイされます。この状況の原因を特定して解消する方法を選択してください。
手動実行では最新コミットが正常にデプロイされている点は、何を意味しているでしょうか。ビルドやデプロイの権限や設定に問題があるなら、実行履歴に失敗として記録されるはずです。ところがコンソールには実行履歴もエラーも一切残っていません。つまり「実行が失敗している」のではなく「実行そのものが作られていない」状態です。プッシュを検知してパイプラインを開始する役割を担うのは誰なのか、その入口の仕組みに注目してみてください。
【DOP-2007】ある DevOps エンジニアは、AWS CodePipeline でコンテナアプリケーションのビルドとデプロイを管理しています。開発チームは Git リポジトリに v1.2.3 形式のリリースタグを付与した時点でのみ、ビルド用パイプラインを起動させたいと考えています。ビルド用パイプラインは Amazon ECR にイメージをプッシュし、その後にデプロイ用パイプラインが実行される必要があります。現在はタグ以外のコミットでも起動してしまい、さらに短時間に複数のタグが付与されると先行する実行が新しい実行に上書きされて、リリースが欠落しています。すべてのタグの実行を付与された順に完了させる必要があります。これらの要件を満たす方法を選択してください。
Git のタグパターンでパイプラインを起動する機能は、CodePipeline のどのタイプで利用できるでしょうか。次に、短時間に複数のタグが付与されたときに先行実行が上書きされてしまう原因を考えてみましょう。実行モードには SUPERSEDED、QUEUED、PARALLEL の3種類がありますが、「すべての実行を付与された順に完了させる」という要件を満たすのはどれかに注目してください。並列実行と順次実行の違いも整理してみましょう。
【DOP-2008】ある企業の DevOps エンジニアは、AWS CodeBuild でのビルド時に外部 API の認証情報を参照する仕組みを構築しています。認証情報は AWS Secrets Manager に保存し、CodeBuild プロジェクトのサービスロールから取得します。監査部門は、このシークレットの平文の値を取得できるプリンシパルを CodeBuild のサービスロールだけに限定し、管理者を含む他の IAM プリンシパルからは取得できない状態にすることを求めています。現在シークレットは Secrets Manager のデフォルトの暗号化設定で作成されています。これらの要件を満たす手順の組み合わせを選択してください。(2つ選択)
シークレットの平文を得るには、Secrets Manager の API 呼び出しと、暗号化キーによる復号という 2 段階の関門を通過する必要があります。まず API 側で誰に許可するかをどう定義し、次に復号側で誰を許可するかをどう定義するか、2 段階で考えてみましょう。
そのうえで、デフォルトの aws/secretsmanager キーはキーポリシーを利用者が編集できるでしょうか。この制約が、どちらのレイヤーに手を入れる必要があるかを決めます。
【DOP-2009】ある企業は、アカウント A の共有サービスアカウントで CI/CD パイプラインの構成値と接続情報を AWS Systems Manager Parameter Store のスタンダードティアのパラメータとして SecureString で保管しています。暗号化には AWS マネージドキーを使用しています。開発チームはアカウント B とアカウント C の AWS CodeBuild プロジェクトから、これらのパラメータをコピーせずに参照したいと考えています。パラメータの実体はアカウント A で一元管理し、参照側では復号した値を取得できる必要があります。これらの要件を満たす手順の組み合わせを選択してください。(3 つ選択)
Parameter Store のパラメータを AWS Resource Access Manager で他アカウントへ共有するには、ティアの条件があります。スタンダードティアのままで共有できるでしょうか。
また SecureString を参照側で復号するには KMS の許可が必要ですが、AWS マネージドキーはキーポリシーを編集できるでしょうか。
「共有の土台」「復号鍵の準備」「参照側の権限付与」という3つのフェーズを、それぞれどの選択肢が担うのかを整理してみましょう。
【DOP-2010】ある企業の DevOps エンジニアは、Application Load Balancer の背後にある Amazon EC2 Auto Scaling グループ上で稼働する Web アプリケーションを運用しています。このアプリケーションは AWS CodeDeploy でインプレースデプロイされています。現在のデプロイでは複数のインスタンスが同時に更新されるため、不良なリビジョンが配信されると一時的にリクエストを処理できるインスタンスが不足します。エンジニアは、更新中も残りのインスタンスがトラフィックを処理し続けるようにし、さらにアプリケーションの HTTP 5xx エラー率が上昇した場合はデプロイを中断して直前のリビジョンへ戻したいと考えています。これらの要件を満たす方法を選択してください。
デプロイ中に「残りのインスタンスがトラフィックを処理し続ける」ためには、同時に更新される台数をどう制御すればよいでしょうか。CodeDeploy にはこの同時更新台数を決める設定が用意されています。
また、HTTP 5xx エラー率の上昇を検知してデプロイを止め、直前のリビジョンへ戻す動作は、追加のコードを書かずに実現できないでしょうか。CodeDeploy のデプロイグループに設定できる項目に注目してください。
⚠️ こちらは教材の操作/UIなど全般に対するリクエストフォームではございません。
個別の問題についての改善リクエストです。
教材全般についての改善リクエストはお問い合わせフォームよりご連絡ください。
CloudTech(クラウドテック)は多くのユーザーの皆様から改善リクエストをご協力いただき運営できております。
あなたの視点での気づきは他の学習者の迷いを解決する手助けとなります。
運営側でもチェックをしておりますが限界があるため、誠に恐縮ではございますが細かい点でもご遠慮なくご指摘をお願いいたします。
※ 匿名での報告となり、内容は一般公開されません。
※ 技術的なご質問への回答を行うフォームではございませんのでご注意ください。
