更新された2024年08月公式問題Professional-Cloud-DevOps-Engineer日本語認定にはProfessional-Cloud-DevOps-Engineer日本語問題集PDF
2024年最新のに更新された最新Professional-Cloud-DevOps-Engineer日本語問題集を掴み取れ!
質問 # 95
会社のマルチクラウド環境でアプリケーションの CI'CD パイプラインを実装している アプリケーションは、カスタム Compute Engine イメージと他のクラウド プロバイダの同等のものを使用してデプロイされている 構築およびデプロイを可能にするソリューションを実装する必要があるイメージを現在の環境に適用し、将来の変更にも適応できるようにするには、どのソリューション スタックを使用する必要がありますか?
- A. Google Kubernetes Engine と Google Cloud Deploy
- B. Google Cloud Deploy を使用した Cloud Build
- C. kpt を使用した Cloud Build
- D. Packer を使用した Cloud Build
正解:B
解説:
Explanation
Cloud Build is a fully managed continuous integration and continuous delivery (CI/CD) service that helps you automate your builds, tests, and deployments. Google Cloud Deploy is a service that automates the deployment of your applications to Google Kubernetes Engine (GKE).
Together, Cloud Build and Google Cloud Deploy can be used to build and deploy your application's custom Compute Engine images to your current environment and to other cloud providers in the future.
Here are the steps involved in using Cloud Build and Google Cloud Deploy to implement a CI/CD pipeline for your application:
Create a Cloud Build trigger that fires whenever a change is made to your application's code.
In the Cloud Build trigger, configure Cloud Build to build your application's Docker image.
Create a Google Cloud Deploy configuration file that specifies how to deploy your application's Docker image to GKE.
In Google Cloud Deploy, create a deployment that uses your configuration file.
Once you have created the Cloud Build trigger and Google Cloud Deploy configuration file, any changes made to your application's code will trigger Cloud Build to build a new Docker image. Google Cloud Deploy will then deploy the new Docker image to GKE.
This solution stack is adaptable to future changes because it uses a cloud-agnostic approach. Cloud Build can be used to build Docker images for any cloud provider, and Google Cloud Deploy can be used to deploy Docker images to any Kubernetes cluster.
The other solution stacks are not as adaptable to future changes. For example, solution stack A (Cloud Build with Packer) is limited to building Docker images for Compute Engine. Solution stack C (Google Kubernetes Engine with Google Cloud Deploy) is limited to deploying Docker images to GKE. Solution stack D (Cloud Build with kpt) is a newer solution that is not yet as mature as Cloud Build and Google Cloud Deploy.
Overall, the best solution stack for implementing a CI/CD pipeline for your application in a multi-cloud environment is Cloud Build with Google Cloud Deploy. This solution stack is fully managed, cloud-agnostic, and adaptable to future changes.
質問 # 96
あなたは現在、組織の Google Cloud プロジェクトの Cloud Monitoring 指標を表示する方法を計画しています。あなたの組織には 3 つのフォルダーと 6 つのプロジェクトがあります。
1 つのフォルダ内のプロジェクトの指標のみを表示するように Cloud Monitoring ダッシュボードを構成したい 他のフォルダ内のプロジェクトの指標がダッシュボードに表示されないようにする必要がある Google が推奨するプラクティスに従いたい どうすればよいですか?
- A. 現在の app-one-prod プロジェクトをスコープ プロジェクトとして使用します。
- B. 現在の app-one-dev、app-one-staging、および app-one-prod プロジェクトを各フォルダーのスコープ プロジェクトとして使用します。
- C. 単一の新しいスコープ プロジェクトを作成します。
- D. フォルダーごとに新しいスコープ プロジェクトを作成します。
正解:D
解説:
Explanation
The best option for configuring Cloud Monitoring dashboards to only display metrics from the projects within one folder is to create new scoping projects for each folder. A scoping project is a project that defines which resources are monitored by Cloud Monitoring. You can create new scoping projects for each folder by using the gcloud monitoring register-project command. This way, you can associate each scoping project with a folder and only monitor the resources within that folder. You can then configure Cloud Monitoring dashboards to use the scoping projects as data sources and only display metrics from the projects within one folder.
質問 # 97
Spinnaker を使用してアプリケーションをデプロイし、パイプラインにカナリア デプロイメント ステージを作成しました。アプリケーションには、起動時にオブジェクトをロードするメモリ内キャッシュがあります。カナリア バージョンと製品バージョンの比較を自動化したいと考えています。カナリア分析をどのように構成すればよいでしょうか?
- A. カナリアを以前の製品バージョンのスライディング ウィンドウの平均パフォーマンスと比較します。
- B. カナリアを現在の製品バージョンの新しいデプロイメントと比較します。
- C. カナリアを現在の運用バージョンの既存のデプロイメントと比較します。
- D. カナリアを以前の製品バージョンの新しいデプロイメントと比較します。
正解:B
解説:
Explanation
https://cloud.google.com/architecture/automated-canary-analysis-kubernetes-engine-spinnaker
https://spinnaker.io/guides/user/canary/best-practices/#compare-canary-against-baseline-not-against-production
質問 # 98
Git ブランチが更新されたときに Terraform コードをデプロイする Cloud Build ジョブをデプロイしています。テスト中に、ジョブが失敗したことに気づきました。ビルド ログに次のエラーが表示されます。
バックエンドを初期化しています。..
エラー: 既存のワークスペースの取得に失敗しました: Cloud Storage のクエリに失敗しました: googleapi: エラー
403
Google が推奨する方法に従って問題を解決する必要があります。あなたは何をするべきか?
- A. ローカル状態を使用するように Terraform コードを変更します。
- B. Terraform 構成で指定された名前でストレージ バケットを作成します。
- C. ロール/所有者 Identity and Access Management (IAM) ロールをプロジェクトの Cloud Build サービス アカウントに付与します。
- D. ロール/ストレージを付与します。objectAdmin Identity and Access Management (IAM) ロールを状態ファイル バケットの Cloud Build サービス アカウントに付与します。
正解:D
解説:
The correct answer is D. Grant the roles/storage.objectAdmin Identity and Access Management (IAM) role to the Cloud Build service account on the state file bucket.
According to the Google Cloud documentation, Cloud Build is a service that executes your builds on Google Cloud Platform infrastructure1. Cloud Build uses a service account to execute your build steps and access resources, such as Cloud Storage buckets2. Terraform is an open-source tool that allows you to define and provision infrastructure as code3. Terraform uses a state file to store and track the state of your infrastructure4. You can configure Terraform to use a Cloud Storage bucket as a backend to store and share the state file across multiple users or environments5.
The error message indicates that Cloud Build failed to access the Cloud Storage bucket that contains the Terraform state file. This is likely because the Cloud Build service account does not have the necessary permissions to read and write objects in the bucket. To resolve this issue, you need to grant the roles/storage.objectAdmin IAM role to the Cloud Build service account on the state file bucket. This role allows the service account to create, delete, and manage objects in the bucket6. You can use the gcloud command-line tool or the Google Cloud Console to grant this role.
The other options are incorrect because they do not follow Google-recommended practices. Option A is incorrect because it changes the Terraform code to use local state, which is not recommended for production or collaborative environments, as it can cause conflicts, data loss, or inconsistency. Option B is incorrect because it creates a new storage bucket with the name specified in the Terraform configuration, but it does not grant any permissions to the Cloud Build service account on the new bucket. Option C is incorrect because it grants the roles/owner IAM role to the Cloud Build service account on the project, which is too broad and violates the principle of least privilege. The roles/owner role grants full access to all resources in the project, which can pose a security risk if misused or compromised.
Reference:
Cloud Build Documentation, Overview. Service accounts, Service accounts. Terraform by HashiCorp, Terraform by HashiCorp. State, State. Google Cloud Storage Backend, Google Cloud Storage Backend. Predefined roles, Predefined roles. [Granting roles to service accounts for specific resources], Granting roles to service accounts for specific resources. [Local Backend], Local Backend. [Understanding roles], Understanding roles.
質問 # 99
Compute Engine でホストされているウェブ アプリケーションをサポートしているとします。このアプリケーションは、数千人のユーザーに予約サービスを提供します。新機能のリリース直後、監視ダッシュボードには、すべてのユーザーがログイン時に遅延を経験していることが表示されます。サービスのユーザーに対するインシデントの影響を軽減したいと考えています。まず何をすべきでしょうか?
- A. 新しいリリースをデプロイして、問題が解決されるかどうかを確認します。
- B. Stackdriver モニタリングを確認します。
- C. 最近のリリースをロールバックします。
- D. ログイン サービスを実行している仮想マシンをアップサイズします。
正解:D
解説:
Rollback to previous stable version. Then you need to find what is causing the issue.
質問 # 100
CTO は、内部使用のためにすべてのインシデントに対して事後分析ポリシーを実装するように依頼しました。会社でポリシーが確実に成功するようにするには、適切な事後分析とは何かを定義したいと考えています。あなたは何をするべきか?
2 つの答えを選択してください
- A. すべての事後分析に、顧客情報の名前を指定せずに、インシデントがどのように解決されたか、およびインシデントの原因が記載されていることを確認します。
- B. すべての事後分析に、インシデントの原因、インシデントがどのように悪化した可能性があるか、将来のインシデントの発生を防ぐ方法が含まれていることを確認します。
- C. すべての事後分析に、事後分析の作成にすべてのインシデント参加者が含まれていることを確認し、事後分析をできるだけ広く共有します。
- D. すべての事後分析に、インシデントの重大度、将来のインシデントの発生を防ぐ方法が含まれていることを確認します。内部システムコンポーネントの名前は示さずに、何がインシデントを引き起こしたのか。
- E. すべての事後分析にインシデントの原因が含まれていることを確認し、インシデントを引き起こした責任のある個人またはチームを特定します。そして今後のインシデントの発生をどのように防ぐか。
正解:B、C
解説:
The correct answers are B and E.
A good postmortem should include what caused the incident, how the incident could have been worse, and how to prevent a future occurrence of the incident1. This helps to identify the root cause of the problem, the impact of the incident, and the actions to take to mitigate or eliminate the risk of recurrence.
A good postmortem should also include all incident participants in postmortem authoring and share postmortems as widely as possible2. This helps to foster a culture of learning and collaboration, as well as to increase the visibility and accountability of the incident response process.
Answer A is incorrect because it assigns blame to a person or team, which goes against the principle of blameless postmortems2. Blameless postmortems focus on finding solutions rather than pointing fingers, and encourage honest and constructive feedback without fear of punishment.
Answer C is incorrect because it omits how the incident could have been worse, which is an important factor to consider when evaluating the severity and impact of the incident1. It also avoids naming internal system components, which makes it harder to understand the technical details and root cause of the problem.
Answer D is incorrect because it omits how to prevent a future occurrence of the incident, which is the main goal of a postmortem1. It also avoids naming customer information, which may be relevant for understanding the impact and scope of the incident.
質問 # 101
App Engine で実行されるアプリケーションをサポートしているとします。このアプリケーションはグローバルに使用され、さまざまな種類のデバイスからアクセスされます。接続数を知りたい。App Engine 向け Stackdriver Monitoring を使用しています。どのような指標を使用する必要がありますか?
- A. tcp_ssl_proxy/open_connections
- B. フレックス/インスタンス/接続/現在
- C. フレックス/接続/現在
- D. tcp_ssl_proxy/new_connections
正解:C
解説:
https://cloud.google.com/monitoring/api/metrics_gcp#gcp-appengine
質問 # 102
アプリケーション イメージは Cloud Build を使用して構築され、Google Container Registry (GCR) にプッシュされます。ソース管理でタグ付けされたリリース バージョンに基づいて、展開するアプリケーションの特定のバージョンを指定できるようにしたいと考えています。画像をプッシュするときはどうすればよいですか?
- A. ソース管理タグ内のイメージダイジェストを参照します。
- B. ソース管理タグをイメージ名内のパラメータとして指定します。
- C. Cloud Build を使用して、アプリケーション イメージにリリース バージョン タグを含めます。
- D. GCR ダイジェスト バージョン管理を使用して、イメージをソース管理のタグと照合します。
正解:B
解説:
Explanation
https://cloud.google.com/container-registry/docs/pushing-and-pulling
質問 # 103
あなたは、Stackdriver Workspaces を使用して本番環境の Google Cloud Platform (GCP) プロジェクトをモニタリングする戦略を開発しています。要件の 1 つは、開発およびステージング プロジェクトからの誤ったアラートを発生させることなく、実稼働環境の問題を迅速に特定して対応できることです。関連するチーム メンバーに Stackdriver Workspaces へのアクセスを許可するときは、最小権限の原則を確実に遵守する必要があります。あなたは何をするべきか?
- A. 新しい GCP モニタリング プロジェクトを作成し、その中に Stackdriver ワークスペースを作成します。実稼働プロジェクトをこのワークスペースにアタッチします。関連するチームメンバーに Stackdriver Workspace への読み取りアクセス権を付与します。
- B. モニタリング ワークスペースをホストする既存の GCP 本番プロジェクトを選択します。実稼働プロジェクトをこのワークスペースにアタッチします。関連するチームメンバーに Stackdriver Workspace への読み取りアクセス権を付与します。
- C. 関連するチーム メンバーに、すべての GCP 本番プロジェクトに対するプロジェクト閲覧者の IAM ロールを付与します。各プロジェクト内に Slackdriver ワークスペースを作成します。
- D. 関連するチーム メンバーに、すべての GCP 本番プロジェクトへの読み取りアクセス権を付与します。各プロジェクト内に Stackdriver ワークスペースを作成します。
正解:A
解説:
"A Project can host many Projects and appear in many Projects, but it can only be used as the scoping project once. We recommend that you create a new Project for the purpose of having multiple Projects in the same scope."
質問 # 104
あなたのチームは最近、NGINX ベースのアプリケーションを Google Kubernetes Engine (GKE) にデプロイし、HTTP Google Cloud Load Balancer (GCLB) Ingress 経由で一般に公開しました。適切なサービス レベル インジケーター (SLI) を使用して、アプリケーションのフロントエンドのデプロイメントを拡張したいと考えています。あなたは何をするべきか?
- A. NGINX 統計エンドポイントを公開し、NGINX デプロイメントによって公開されるリクエスト メトリクスを使用するように水平ポッド オートスケーラーを構成します。
- B. Liveness プローブと Readiness プローブからの平均応答時間を使用するように、水平ポッド オートスケーラーを構成します。
- C. GKE で垂直ポッド オートスケーラーを構成し、ポッドの拡張に応じてクラスター オートスケーラーがクラスターをスケーリングできるようにします。
- D. Stackdriver カスタム指標アダプターをインストールし、GCLB によって提供されるリクエスト数を使用するように水平ポッド オートスケーラーを構成します。
正解:D
解説:
https://cloud.google.com/kubernetes-engine/docs/tutorials/autoscaling-metrics The Google Cloud HTTP Load Balancer (GCLB) provides metrics on the number of requests and the response latency for each backend service. These metrics can be used as custom metrics for the horizontal pod autoscaler (HPA) to scale the deployment based on the load. This is the correct solution to use an appropriate SLI for scaling.
質問 # 105
Google Cloud にデプロイされたアプリケーションのフロントエンド層を構成しています。 フロントエンド層は ngmx でホストされ、Envoy ベースの外部 HTTP(S) ロードバランサを前面に備えたマネージド インスタンス グループを使用してデプロイされます。 アプリケーションは完全にヨーロッパ内にデプロイされます。 west2 リージョン: 英国に拠点を置くユーザーのみにサービスを提供します。最もコスト効率の高いネットワーク層と負荷分散構成を選択する必要があります。何を使用する必要がありますか?
- A. リージョン ロード バランサーを備えたプレミアム ティア
- B. グローバル ロード バランサーを備えたスタンダード ティア
- C. リージョン ロード バランサーを備えたスタンダード ティア
- D. グローバル ロード バランサーを備えたプレミアム ティア
正解:A
解説:
Explanation
The most cost-effective network tier and load balancing configuration for your frontend tier is to use Premium Tier with a regional load balancer. Premium Tier is a network tier that provides high-performance and low-latency network connectivity across Google's global network. A regional load balancer is a load balancer that distributes traffic within a single region. Since your application is deployed entirely within the europe-west2 region and only serves users based in the United Kingdom, you can use Premium Tier with a regional load balancer to optimize the network performance and cost.
質問 # 106
ロード バランサーを使用せずに HTTP エンドポイントを公開するアプリケーションを管理しています。HTTP 応答の遅延は、ユーザー エクスペリエンスにとって重要です。すべてのユーザーが経験している HTTP 遅延を把握したいと考えています。Stackdriver Monitoring を使用します。あなたは何をするべきか?
- A. * アプリケーションで、metricKind を使用してメトリックを作成します。METRlc_KIND_UNSPECIFIED に設定し、valueType を INT64 に設定します。
* Stackdriver の Metrics Explorer では、積み上げ面グラフを使用して指標を視覚化します。 - B. * アプリケーションで、metricKind を DELTA に設定し、valueType を DOUBLE に設定してメトリックを作成します。
* Stackdriver の Metrics Explorer では、緩み棒グラフを使用して指標を視覚化します。 - C. * アプリケーションで、metricKind をゲージに設定し、valueType を distribution に設定してメトリックを作成します。
* Stackdriver の Metrics Explorer では、ヒートマップ グラフを使用して指標を視覚化します。 - D. * アプリケーションで、metricKind を CUMULATIVE に設定し、valueType を DOUBLE に設定してメトリックを作成します。
* Stackdriver の Metrics Explorer では、折れ線グラフを使用して指標を視覚化します。
正解:C
解説:
Explanation
https://sre.google/workbook/implementing-slos/
https://cloud.google.com/architecture/adopting-slos/
Latency is commonly measured as a distribution. Given a distribution, you can measure various percentiles.
For example, you might measure the number of requests that are slower than the historical 99th percentile.
質問 # 107
現在、製品は 3 つの Google Cloud Platform (GCP) ゾーンにデプロイされており、ユーザーはゾーン間で分割されています。あるゾーンから別のゾーンにフェールオーバーすることはできますが、影響を受けるユーザーに対して 10 分間のサービス中断が発生します。通常、データベース障害は四半期に 1 回発生しますが、5 分以内に検出できます。あなたは、製品の新しいリアルタイム チャット機能の信頼性リスクをカタログ化しています。リスクごとに次の情報をカタログ化します。
* 平均検出時間 (MUD) (分単位)
* 分単位の平均修復時間 (MTTR)
* 平均故障間隔 (MTBF) 日単位
* ユーザーへの影響の割合
チャット機能には、ゾーン間で正常にフェールオーバーするのに 2 倍の時間がかかる新しいデータベース システムが必要です。1 つのゾーンで新しいデータベースに障害が発生するリスクを考慮したいと考えています。新しいシステムでのデータベース フェイルオーバーのリスクの値はどれくらいでしょうか?
- A. MTTD:5
MTTR: 20
MTBF: 90
影響: 33% - B. MTTD:5
MTTR: 10
MTBF: 90
影響力 50% - C. MTTD:5
MTTR: 20
MTBF: 90
影響: 50% - D. MTTD:5
MTTR: 10
MTBF: 90
影響: 33%
正解:A
解説:
Explanation
https://www.atlassian.com/incident-management/kpis/common-metrics
https://linkedin.github.io/school-of-sre/
質問 # 108
あなたの会社はサイト信頼性エンジニアリングの原則に従っています。あなたは、ソフトウェアの変更によって引き起こされ、ユーザーに深刻な影響を与えたインシデントの事後分析を作成しています。将来的に重大なインシデントが発生するのを防ぎたいと考えています。あなたは何をするべきか?
- A. 変更をレビューした従業員をフォローアップし、今後従うべき慣行を処方します。
- B. インシデントの責任のあるエンジニアを特定し、上級管理者にエスカレーションします。
- C. 新しいソフトウェアがリリースされる前に、このタイプのエラーをキャッチするテスト ケースが正常に実行されていることを確認します。
- D. インシデントが発生した場合、オンコール チームが直ちにエンジニアと経営陣に電話して対応計画について話し合うことを要求するポリシーを設計します。
正解:C
解説:
Explanation
The best way to prevent severe incidents from happening in the future is to ensure that test cases that catch errors of this type are run successfully before new software releases. This is aligned with the Site Reliability Engineering principle of testing for reliability.
質問 # 109
あなたの組織は、2,000 ドルの投資でアプリケーションの可用性目標を 99 9% から 99 99% に向上させたいと考えています。 アプリケーションの現在の収益は S1,000,000 です。 可用性の向上が 1 年間の投資に見合う価値があるかどうかを判断する必要があります。どうすればいいですか?
- A. 可用性の向上の価値は 900 ドルと計算され、可用性の向上には投資に値しないと判断します。
- B. 可用性の向上の価値を 1,000 ドルと計算し、可用性の向上には投資に値しないと判断します。
- C. 可用性の向上の価値を 1,000 ドルと計算し、可用性の向上には投資する価値があると判断します。
- D. 可用性の向上の価値は 9,000 ドルと計算されます。可用性の向上には投資する価値があると判断します
正解:A
解説:
The best option for determining whether the increase in availability is worth the investment for a single year of usage is to calculate the value of improved availability to be $900, and determine that the increase in availability is not worth the investment. To calculate the value of improved availability, we can use the following formula:
Value of improved availability = Revenue * (New availability - Current availability) Plugging in the given numbers, we get:
Value of improved availability = $1,000,000 * (0.9999 - 0.999) = $900
Since the value of improved availability is less than the investment of $2,000, we can conclude that the increase in availability is not worth the investment.
質問 # 110
Compute Engine 上で実行されているアプリケーション サーバーのプールがあります。必要な構成が最小限で、開発者がトラブルシューティングのためにアプリケーション ログに簡単にアクセスできる安全なソリューションを提供する必要があります。GCP にソリューションを実装するにはどうすればよいでしょうか?
- A. * gsutil コマンド ライン ツールをアプリケーション サーバーにインストールします。
* gsutil を使用してアプリケーション ログを Cloud Storage バケットにアップロードするスクリプトを作成し、cron 経由で 5 分ごとに実行するようにスケジュールします。 - B. * Stackdriver ロギング エージェントをアプリケーション サーバーにデプロイします。
* Stackdriver にアクセスしてログを表示するための IAM ログのプライベート ログ閲覧者の役割を開発者に付与します。 - C. * Stackdriver モニタリング エージェントをアプリケーション サーバーにデプロイします。
* 開発者に、Stackdriver にアクセスして指標を表示するための IAM モニタリング閲覧者のロールを付与します。 - D. * Stackdriver ロギング エージェントをアプリケーション サーバーにデプロイします。
* 開発者に、Stackdriver にアクセスしてログを表示するための IAM ログ閲覧者のロールを付与します。
正解:D
解説:
* Give the developers IAM Object Viewer access to view the logs in the specified bucket.
Explanation:
https://cloud.google.com/logging/docs/audit#access-control
質問 # 111
本番サービスの一部は、eu-west-1 リージョンの Google Kubernetes Engine (GKE) で実行されています。ビルド システムは us-west-1 リージョンで実行されます。コンテナー イメージをビルド システムからスケーラブルなレジストリにプッシュして、イメージをクラスターに転送するための帯域幅を最大化したいと考えています。あなたは何をするべきか?
- A. eu.gcr.io ホスト名を使用してイメージを Google Container Registry (GCR) にプッシュします。
- B. eu-west-1 リージョンの Compute Engine インスタンスで実行されているプライベート イメージ レジストリにイメージをプッシュします。
- C. gcr.io ホスト名を使用してイメージを Google Container Registry (GCR) にプッシュします。
- D. us.gcr.io ホスト名を使用してイメージを Google Container Registry (GCR) にプッシュします。
正解:A
解説:
Hostname Storage location gcr.io Stores images in data centers in the United States asia.gcr.io Stores images in data centers in Asia eu.gcr.io Stores images in data centers within member states of the European Union us.gcr.io Stores images in data centers in the United States
質問 # 112
トラフィックの多いマルチリージョン Web アプリケーションのサービス レベル目標 (SLO) を定義する必要があります。顧客は、アプリケーションが常に利用可能であり、応答時間が速いことを期待しています。現在、顧客はアプリケーションのパフォーマンスと可用性に満足しています。現在の測定に基づくと、28 日間の期間で、遅延の 90 パーセンタイルが 120 ミリ秒、遅延の 95 パーセンタイルが 275 ミリ秒であることがわかります。公開するためにチームに推奨するレイテンシー SLO はどれですか?
- A. 90 パーセンタイル - 150ms
95 パーセンタイル - 300ms - B. 90 パーセンタイル - 120ms
95 パーセンタイル - 275ms - C. 90 パーセンタイル - 100ms
95 パーセンタイル - 250ms - D. 90 パーセンタイル - 250ms
95 パーセンタイル - 400ms
正解:A
解説:
https://sre.google/sre-book/service-level-objectives/
質問 # 113
......
最新のProfessional-Cloud-DevOps-Engineer日本語試験問題集でGoogle試験にはトレーニング:https://www.goshiken.com/Google/Professional-Cloud-DevOps-Engineer-JPN-mondaishu.html