Google Cloud認定資格Professional Cloud DevOps Engineer100題 問題集全問解答＋全問解説付き
Google Cloud認定資格Professional Cloud DevOps Engineerの過去問100題を全問解答＋全問解説付き
Google Cloud Professional Cloud DevOps Engineerの最新の問題になります。
筆者が実際に受験して、問題を収集し解答とその解説を全問付けております。
問題数は合計100題。
実際に受験し、重複問題や類似問題を削除しています。
この100問の問題の解答を理解できれば、ほぼ間違いなく、合格すると思います。
ここから問題と解答/解説になります。
100題、全問解答＋全問解説付きになります。
1.
停止のためにポストモダンでアクション アイテムを作成して割り当てています。停止は終わりましたが、根本原因に対処する必要があります。チームがアクション アイテムを迅速かつ効率的に処理できるようにする必要があります。アクション アイテムに所有者と共同作業者をどのように割り当てる必要がありますか?
A. アクション アイテムごとに 1 人の所有者と、必要な共同作業者を割り当てます。
B. 各アイテムに複数の所有者を割り当てて、チームがアイテムに迅速に対処できるようにします
C. 共同作業者をアイテムに割り当てますが、個々の所有者は割り当てず、事後分析を無責任に保ちます。
D. チーム リーダーは SRE チームを担当しているため、すべてのアクション アイテムの所有者としてチーム リーダーを割り当てます。
正解：A
解説: A. アクション アイテムごとに1人の所有者を割り当てることで、責任と進捗状況の明確化が保たれ、必要な共同作業者とのコラボレーションも促進されます。これにより、根本原因への対策が効率的かつ効果的に進行することが期待できます。
B. 各アイテムに複数の所有者を割り当てると、アイテムに対する明確な責任が失われ、「責任の拡散」が生じる可能性があります。これは「誰もが責任を持っているとき、実際には誰も責任を持っていない」という状況を引き起こす可能性があるため、推奨されません。
C. アイテムに共同作業者を割り当てることは良い実践ですが、所有者を割り当てないと、誰が最終的な責任を持つのか不明確になります。これはアイテムが適切にフォローされないリスクを増大させ、事後分析の質を下げる可能性があります。
D. チームリーダーを全てのアクションアイテムの所有者とすることは、リーダーシップに過剰な負荷をかけることになり、その人の他の業務にも影響を与えかねません。また、個々の専門知識を持つチームメンバーの能力を活用する機会を逸することになるため、最適なアプローチとは言えません。
正解のAが最も効果的な方法です。それぞれのアクションアイテムに対して明確な責任者がいることで、タスクの遂行がスムーズになり、問題の再発防止に繋がります。
2.
トラフィックの多い Web アプリケーションをサポートしており、ホームページがタイムリーに読み込まれるようにしたいと考えています。最初のステップとして、許容可能なページ読み込み時間を 100 ミリ秒に設定して、ホームページ要求の待ち時間を表すサービス レベル インジケーター (SLI) を実装することを決定します。この SLI を計算するために Google が推奨する方法は何ですか?
A. 100 ミリ秒未満でロードされるホームページ リクエストの数をカウントします。次に、すべての Web アプリケーション要求の合計数で割ります。
B. リクエストのレイテンシを範囲に分類し、100 ミリ秒でパーセンタイルを計算します。
C. 100 ミリ秒未満で読み込まれたホームページ リクエストの数をカウントし、ホームページ リクエストの総数で割ります。
D. リクエストのレイテンシを範囲にバケット化し、中央値と 90 パーセンタイルを計算します。
正解：B
解説: A. この方法は正確なSLIを提供しますが、すべてのWebアプリケーション要求ではなく、ホームページ要求のみに焦点を当てる必要があるため、この文脈では不適切です。
B. パーセンタイル計算はSLIを評価する一般的な方法であり、特にレイテンシーに関しては、より具体的なユーザーエクスペリエンスの指標を提供します。100ミリ秒でのパーセンタイルは、特定のしきい値を下回るリクエストの割合を示し、ユーザーがどの程度迅速にページをロードできるかをよりよく理解するのに役立ちます。
C. このアプローチはホームページの読み込みに限定されており、Aの選択肢と似ていますが、全体的なWebアプリケーションの要求ではなく、ホームページの要求のみをカウントする点が正確です。ただし、全ての応答時間が100ミリ秒未満であるかどうかのみを計済するため、レイテンシの分布についての洞察は限られています。
D. リクエストのレイテンシをバケット化することは有効な手法ですが、この選択肢はパーセンタイルではなく、中央値と90パーセンタイルの計算を提案しています。これはSLIを評価する一つの方法ですが、特定のしきい値に関する明確な要件に対する直接的な計測ではありません。
正解のBは、特定のしきい値（この場合は100ミリ秒）でパーセンタイルを計算することにより、許容可能なパフォーマンスのレベルをユーザーエクスペリエンスの観点から定量化する最も適切な方法を提供します。
3.
Compute Engine でホストされているウェブ アプリケーションをサポートしています。このアプリケーションは、何千人ものユーザーに予約サービスを提供します。新機能のリリース直後、監視ダッシュボードは、すべてのユーザーがログイン時に遅延を経験していることを示しています。サービスのユーザーに対するインシデントの影響を軽減したいと考えています。最初に何をすべきですか？
A. 最近のリリースをロールバックします。
B. Stackdriver のモニタリングを確認します。
C. ログイン サービスを実行する仮想マシンをアップサイズします。
D. 新しいリリースをデプロイして、問題が修正されるかどうかを確認します。
正解：C
解説: A. リリースのロールバックは、新機能のデプロイによって問題が引き起こされたことが明白である場合に有効な手段ですが、その原因を特定せずに実行すると、問題の原因が新機能であるかどうかが不確かであり、また時間を浪費する可能性があります。
B. Stackdriver（現在はGoogle Cloud MonitoringとLogging）の監視を確認することは、問題の原因を特定する上で有用な第一歩ですが、すでにダッシュボードが問題を示している状況では、このアクションは既に実施されている可能性があり、即座の影響を軽減する措置ではありません。
C. ログインサービスを実行している仮想マシンをアップサイズすることは、サービスのレイテンシー問題がリソースの不足から発生している場合に有効です。特に新機能によってリソース要件が変更された場合や、ユーザーの数が予想より多い場合など、即座に実行することでサービスのパフォーマンスが向上する可能性があります。
D. 新しいリリースのデプロイは、問題の原因が特定され、その修正が新しいリリースで対応されている場合にのみ有効です。ただし、これはリリースに問題がないことが確認されていないとリスクが伴います。
正解のCは、遅延が発生している状況で最も直接的で迅速な解決策を提供する可能性があります。
4.
Compute Engine でアプリケーションを実行し、Stackdriver を介してログを収集しています。個人を特定できる情報 (Pll) が特定のログ エントリ フィールドに漏れていることを発見しました。すべての Pll エントリは、テキスト userinfo で始まります。これらのログエントリを後で確認できるように安全な場所にキャプチャし、Stackdriver Logging に漏洩しないようにする必要があります。あなたは何をするべきか？
A. userinfo に一致する基本的なログフィルタを作成し、Cloud Storage をシンクとして Stackdriver コンソールでログ エクスポートを構成します。
B. Stackdriver Agent で Fluentd フィルタ プラグインを使用して、ユーザー情報を含むログエントリを削除し、そのエントリを Cloud Storage バケットにコピーします。
C. userinfo に一致する高度なログ フィルタを作成し、Cloud Storage をシンクとして Stackdriver コンソールでログ エクスポートを構成してから、userinfo をフィルタとして tog 除外を構成します。
D. Stackdriver Agent で Fluentd フィルタ プラグインを使用して、ユーザー情報を含むログエントリを削除し、ユーザー情報に一致する高度なログフィルタを作成してから、Cloud Storage をシンクとして Stackdriver コンソールでログ エクスポートを構成します。
正解：B
解説:
A. 基本的なログフィルタを作成し、Cloud Storageにログをエクスポートすることは、PIIが含まれているログエントリを特定し、それらを保存するための方法の一つですが、この方法だけでは、ログにPIIが含まれないようにするための対策ではありません。つまり、PIIがまずStackdriverに入ってしまうという問題を解決しません。
B. Stackdriver AgentでFluentdフィルタプラグインを使用することは、ログデータがStackdriver Loggingに入る前にPIIをフィルタリングする効果的な方法です。この方法では、PIIが含まれるログエントリを削除し、代わりに安全な場所（たとえばCloud Storageバケット）にコピーすることができます。これにより、Stackdriver LoggingにPIIが漏れることがなくなります。
C. 高度なログフィルタを作成し、Cloud Storageにエクスポートすることも有効な手段ですが、userinfoをフィルタとしてログ除外を構成すると、PIIが含まれているログデータがStackdriverに保存される可能性があるため、この選択肢は誤っています。
D. この選択肢は、Fluentdフィルタプラグインを使用してPIIを含むログエントリを削除し、それから高度なログフィルタを作成するというステップを組み合わせています。ただし、最初にFluentdでPIIをフィルタリングした場合、高度なログフィルタで再びエクスポートを構成する必要はありません。この選択肢は冗長であるため、誤っています。
正解のBは、PIIを含むログデータがStackdriver Loggingに到達する前にそれをフィルタリングし、安全な場所にのみ保存する最も適切なアプローチを提供します。
5
組織の仮想マシン (VM|) のコストを削減する必要があります。さまざまなオプションを検討した後、プリエンプティブル VM インスタンスを活用することにしました。プリエンプティブル VM に適しているアプリケーションはどれですか?
A. スケーラブルなインメモリ キャッシング システム
B. 組織の公開 Web サイト
C. 十分なクォーラムを備えた分散型の最終的に一貫性のある NoSQL データベース クラスター
D. ビデオを取得してストレージ バケットに保存する、GPU で高速化されたビデオ レンダリング プラットフォーム
正解：D
解説:
A. スケーラブルなインメモリキャッシングシステムは、データが失われると性能が著しく影響を受けるため、プリエンプティブルVMには適していません。プリエンプティブルVMは予告なしに停止する可能性があり、インメモリデータが失われるリスクが高いです。
B. 組織の公開Webサイトは、一般的に高可用性が求められるため、プリエンプティブルVMには適していません。プリエンプティブルVMは予期せず終了する可能性があり、Webサイトの可用性に直接影響を与えます。
C. 十分なクォーラムを備えた分散型の最終的に一貫性のあるNoSQLデータベースクラスターは、理論的にはプリエンプティブルVMで実行することができるかもしれませんが、データベース操作は通常、継続的な可用性と信頼性を必要とするため、プリエンプティブルVMは理想的ではありません。
D. GPUで高速化されたビデオレンダリングプラットフォームは、プリエンプティブルVMに適しています。ビデオレンダリングは計算集約的なバッチ処理作業であり、一時的なVMの終了がプロセスに中断をもたらしても、再開または再実行可能なタスクであることが多いです。プリエンプティブルVMはコストが低く、短期間で高い計算能力を必要とするワークロードに最適です。
正解のDは、プリエンプティブルVMが一時的なリソースを必要とし、仕事が中断されても問題ないタイプのアプリケーションに適しているため、ビデオレンダリングなどの非常に計算集約的で中断許容型の作業に理想的です。
6.
あなたは、Google Cloud Platform (GCP) で実行されるトラフィックの多い Web アプリケーションをサポートしています。アプリケーションに技術的な変更を加えることなく、ユーザーの観点からアプリケーションの信頼性を測定する必要があります。あなたは何をするべきか？（2つ選んでください。）
A. Web プロキシ ログのみを分析し、各要求の応答時間をキャプチャします。
B. コードを変更して、ユーザーの操作に関する追加情報を取得します。
C. 現在および過去のリクエスト ログを使用して、顧客とアプリケーションのやり取りを追跡します。
D. 新しい合成クライアントを作成して、アプリケーションを使用してユーザー ジャーニーをシミュレートします。
E. 現在のアプリケーション メトリックを確認し、必要に応じて新しいメトリックを追加します。
正解：A,C
解説:
A. Web プロキシ ログの分析はユーザーの視点からアプリケーションの信頼性を測定するのに役立ちます。応答時間はユーザー体験の重要な指標であり、これらのログを分析することで、ページの読み込み時間やトランザクションの完了にかかる時間など、ユーザーが実際に経験するパフォーマンスを理解できます。
B. 技術的な変更を加えずに信頼性を測定する必要があるため、この選択肢は要件に反しています。コードを変更して追加情報を取得することは、技術的な変更を伴うため、この文脈では不適切です。
C. リクエストログを使用して顧客とアプリケーションとのやり取りを追跡することは、アプリケーションの信頼性をユーザーの観点から測定するのに有用です。これにより、エラー発生時のユーザーの行動やアプリケーションの応答を分析し、信頼性に関する洞察を得ることができます。
D. 合成クライアントを作成してアプリケーションの使用をシミュレートすることは、実際のユーザーの視点から信頼性を測定する手法です。これはユーザーの行動を模倣し、ユーザーが遭遇するであろう問題を特定するのに役立ちますが、この選択肢も新しいシステムを作ることになるため、技術的な変更を加えることになります。
E. 現在のアプリケーションメトリックを確認することは、ユーザーの観点からアプリケーションの信頼性を測定する際に役立ちます。これは、既存のデータに基づいて分析を行うため、新たな技術的変更を加えることなく行える作業です。
7.
Stackdriver Workspaces を使用して、本番環境で Google Cloud Platform (GCP) プロジェクトをモニタリングするための戦略を開発しています。要件の 1 つは、開発およびステージング プロジェクトからの誤ったアラートなしで、運用環境の問題を迅速に特定して対応できることです。関連するチーム メンバーに Stackdriver Workspaces へのアクセス権を付与するときは、最小権限の原則に従う必要があります。あなたは何をするべきか？
A. 新しい GCP モニタリング プロジェクトを作成し、その中に Stackdriver ワークスペースを作成します。本番プロジェクトをこのワークスペースに接続します。関連するチーム メンバーに、Stackdriver ワークスペースへの読み取りアクセス権を付与します。
B. 関連するチーム メンバーに、すべての GCP 本番プロジェクトに対するプロジェクト閲覧者の IAM ロールを付与します。各プロジェクト内に Slackdriver ワークスペースを作成します。
C. 関連するチーム メンバーに、すべての GCP 本番プロジェクトへの読み取りアクセス権を付与します。各プロジェクト内に Stackdriver ワークスペースを作成します。
D. 既存の GCP 本番環境プロジェクトを選択して、モニタリング ワークスペースをホストします。本番プロジェクトをこのワークスペースに接続します。関連するチーム メンバーに、Stackdriver ワークスペースへの読み取りアクセス権を付与します。
正解：D
説:
A. この選択肢は、新しい専用のGCPモニタリングプロジェクトを作成し、本番プロジェクトをそのモニタリングプロジェクトのStackdriverワークスペースにリンクすることを提案しています。これにより、開発やステージングのプロジェクトからの誤ったアラートを避けることができます。チームメンバーにはワークスペースの読み取りアクセスのみを与えることで、最小権限の原則を適用しています。
B. この選択肢では、全ての本番プロジェクトに対してチームメンバーにプロジェクト閲覧者ロールを付与し、各プロジェクトにStackdriverワークスペースを作成することを提案しています。しかし、これによって開発やステージング環境のアラートを適切に分離することができない可能性があります。また、プロジェクト閲覧者ロールはStackdriverに必要以上の広範な権限を与えてしまうため、最小権限の原則に反します。
C. 各本番プロジェクトに対して読み取りアクセスをチームメンバーに与えることも、最小権限の原則に反する可能性があります。また、各プロジェクトに個別のStackdriverワークスペースを作成することは、集中管理と迅速な問題特定には適していないかもしれません。
D. 既存の本番環境プロジェクトを選択し、それをモニタリングのためのワークスペースとして使用するというこの選択肢は、必要な情報を一箇所で管理することで迅速な問題特定を可能にします。チームメンバーにはワークスペースへの読み取りアクセスのみを与えることで、必要な情報にはアクセスできるが、システムの変更はできないようにすることで最小権限の原則を守っています。これが最も好ましい選択であり、正解とされています。
8.
アプリケーション イメージがビルドされ、Google Container Registry (GCR) にプッシュされます。開発作業を最小限に抑えながら、イメージが更新されたときにアプリケーションをデプロイする自動化されたパイプラインを構築したいと考えています。あなたは何をするべきか？
A. Cloud Build を使用して Spinnaker パイプラインをトリガーします。
B. Cloud Pub/Sub を使用して Spinnaker パイプラインをトリガーします。
C. Cloud Build でカスタム ビルダーを使用して、Jenkins パイプラインをトリガーします。
D. Cloud Pub/Sub を使用して、Google Kubernetes Engine (GKE) で実行されているカスタム デプロイ サービスをトリガーします。
正解：B
解説:
A. Cloud Build は、コードのコンパイル、実行、テスト、デプロイなどのCI/CDパイプラインの一環として使用できます。しかし、Spinnakerは独自のトリガーメカニズムを持っており、Cloud Buildが直接Spinnakerパイプラインをトリガーする通常の方法ではありません。
B. Cloud Pub/Subを使用してSpinnakerパイプラインをトリガーするという選択肢は、GCRにイメージがプッシュされたときにメッセージをPub/Subトピックに送信し、そのトピックを購読しているSpinnakerがデプロイパイプラインを開始するというものです。この方法は、開発作業を最小限に抑えつつ、新しいイメージがプッシュされるたびに自動的にデプロイが行われるパイプラインを構築する効果的な方法です。これが正解です。
C. Cloud Buildのカスタムビルダーを使用してJenkinsパイプラインをトリガーするという選択肢は、可能ですが、この質問の文脈ではSpinnakerの利用が想定されています。また、カスタムビルダーを作成してJenkinsをトリガーするのはより複雑であり、開発作業を最小限に抑えるという要件にはそぐわない可能性があります。
D. Cloud Pub/Subを使用して、GKEで実行されているカスタムデプロイサービスをトリガーするという選択肢は、実行可能なアプローチですが、既存の自動化されたデプロイツール（この場合はSpinnaker）を利用するよりも開発作業が増える可能性があります。この選択肢は、もしカスタムのデプロイメント要件がある場合に検討されるかもしれませんが、問題の要件には最適ではないようです。
9.
Cloud Build を使用して、アプリケーションをビルドしてデプロイします。データベース資格情報やその他のアプリケーション シークレットをビルド パイプラインに安全に組み込みたい。また、開発作業を最小限に抑えたいと考えています。あなたは何をするべきか？
A. Cloud Storage バケットを作成し、保存時に組み込みの暗号化を使用します。シークレットをバケットに保存し、Cloud Build にバケットへのアクセスを許可します。
B. シークレットを暗号化し、アプリケーション リポジトリに保存します。復号鍵を別のリポジトリに保存し、Cloud Build にリポジトリへのアクセスを許可します。
C. クライアント側の暗号化を使用してシークレットを暗号化し、Cloud Storage バケットに保存します。バケットに復号鍵を保存し、Cloud Build にバケットへのアクセスを許可します。
D. Cloud Key Management Service (Cloud KMS) を使用してシークレットを暗号化し、Cloud Build デプロイ構成に含めます。KeyRing への Cloud Build アクセス権を付与します。
正解：D
解説:
A. Cloud Storage バケットはファイルを保存するのに適していますが、機密データやシークレットを保存する場合、Cloud KMSのような専用のシークレット管理サービスを使用した方がより安全です。保存時にバケットで暗号化を使用することは基本的なセキュリティを提供しますが、Cloud Buildとの統合やシークレットの管理に関しては、最善の選択ではありません。
B. シークレットを暗号化してリポジトリに保存することは、シークレットを安全に管理する推奨される方法ではありません。これは、特にリポジトリが誤って公開された場合にシークレットが露出するリスクを増加させます。復号鍵を別のリポジトリに保存することも安全な方法ではなく、キー管理において複雑さを増加させます。
C. クライアント側でシークレットを暗号化することはセキュリティを高めますが、復号鍵を同じCloud Storage バケットに保存することはセキュリティ上のリスクをもたらします。復号鍵が露出した場合、暗号化されたシークレットは簡単にアクセス可能になります。
D. Cloud KMSを使用してシークレットを暗号化する方法は、Google Cloudの推奨されるプラクティスに従うものです。Cloud KMSは鍵のライフサイクル管理、アクセスのロギング、セキュリティポリシーの適用といった機能を提供し、Cloud Buildデプロイ構成に安全にシークレットを組み込むことができます。この方法では開発作業を最小限に抑えることができ、必要な権限だけをCloud Buildに付与することで、最小権限の原則にも従います。これが正解です。
10.
アプリケーション アーティファクトは、CI/CD パイプラインを介して構築およびデプロイされています。CI/CD パイプラインがアプリケーション シークレットに安全にアクセスできるようにする必要があります。また、セキュリティ違反が発生した場合に備えて、シークレットをより簡単にローテーションしたいと考えています。
あなたは何をするべきか？
A. Cloud KMS の鍵で暗号化された Cloud Storage にシークレットを保存します。IAM を介して Cloud KMS にアクセスできる CI / CD パイプラインを提供します。
B. ビルド時に開発者にシークレットを要求します。シークレットを保存しないように開発者に指示します。
C. シークレットを Git の別の構成ファイルに保存します。選択した開発者に構成ファイルへのアクセスを提供します。
D. シークレットを暗号化し、ソース コード リポジトリに保存します。復号化キーを別のリポジトリに保存し、パイプラインへのアクセスを許可します。
正解：A
解説:
A. Cloud KMSを使用してシークレットを暗号化し、Cloud Storageに保存する方法はセキュリティのベストプラクティスに従っています。IAM（Identity and Access Management）を使ってCI/CDパイプラインにCloud KMSへのアクセスを制御することで、セキュリティが強化され、シークレットのローテーションも容易になります。シークレットの管理に特化したツールを使用することで、CI/CDパイプラインが安全にアクセスできるようにしつつ、セキュリティ違反が起こった場合の対応もスムーズに行えます。
B. ビルド時に開発者からシークレットを要求する方法は、人為的ミスを招きやすく、セキュリティリスクを高めるため適切ではありません。また、シークレットのローテーションを簡単にするという要件にも対応できません。
C. シークレットをGitの別の構成ファイルに保存し、選択した開発者のみがアクセスできるようにする方法は、シークレットの露出リスクを減らすものの、セキュリティが完全には保証されません。また、リポジトリが漏洩した場合にシークレットが危険にさらされる可能性があります。
D. シークレットを暗号化してソースコードリポジトリに保存し、復号化キーを別のリポジトリに保存する方法も、BやCの選択肢と同様に、セキュリティリスクが高いです。これらの方法では、リポジトリのセキュリティが侵害された場合にシークレットが漏洩する可能性があります。
正しい答えはAです。Cloud KMSとCloud Storageを組み合わせて使用し、CI/CDパイプラインがIAMを通じて適切な権限でシークレットにアクセスする構成は、セキュリティを強化し、シークレットの管理を容易にするための最適な方法です。
ここから先は
¥ 2,000
この記事が気に入ったらサポートをしてみませんか？