Professional Cloud DevOps Engineer

Question 61

あなたは、パブリックIPアドレスを持つCompute Engineインスタンス上で実行される新しいアプリケーションのためにCloud Loggingを設定しています。ユーザー管理のサービスアカウントがそのインスタンスにアタッチされています。必要なエージェントがインスタンス上で実行されていることは確認しましたが、Cloud Loggingでそのインスタンスからのログエントリが表示されません。Googleが推奨するプラクティスに従ってこの問題を解決したいと考えています。何をすべきでしょうか?

A.
サービスアカウントキーをエクスポートし、エージェントがそのキーを使用するように設定する。
B.
インスタンスがデフォルトのCompute Engineサービスアカウントを使用するように更新する。
C.
サービスアカウントにログ書き込み (Logs Writer) ロールを追加する。
D.
インスタンスが存在するサブネットで限定公開のGoogleアクセスを有効にする。
Question 62

サイト信頼性エンジニア(SRE)として、あなたは本番環境のGoogle Kubernetes Engine(GKE)上で動作するGo言語製のアプリケーションをサポートしています。アプリケーションの新しいバージョンをリリースした後、アプリケーションが約15分間稼働した後に再起動することに気づきました。そこで、アプリケーションにCloud Profilerを導入したところ、アプリケーションが再起動するまでヒープ使用量が継続的に増加していることが判明しました。この状況で、あなたは何をすべきですか?

A.
アプリケーションのデプロイメントでCPU制限を引き上げます。
B.
クラスタに大容量メモリのコンピュートノードを追加します。
C.
アプリケーションのデプロイメントでメモリ制限を引き上げます。
D.
アプリケーションにCloud Traceを追加し、再デプロイします。
Question 63

あなたは、Gitブランチが更新されたときにTerraformコードをデプロイするCloud Buildジョブをデプロイしています。テスト中に、ジョブが失敗することに気づきました。ビルドログに以下のエラーが表示されます。 「バックエンドを初期化しています... エラー: 既存のワークスペースの取得に失敗しました: Cloud Storageへのクエリに失敗しました: googleapi: エラー 403」 Googleが推奨するプラクティスに従って、この問題を解決する必要があります。何をすべきですか?

A.
Terraformコードをローカルステートを使用するように変更する。
B.
Terraform設定で指定された名前でストレージバケットを作成する。
C.
プロジェクトのCloud Buildサービスアカウントに roles/owner のIdentity and Access Management (IAM) ロールを付与する。
D.
ステートファイルバケットのCloud Buildサービスアカウントに roles/storage.objectAdmin のIdentity and Access Management (IAM) ロールを付与する。
Question 64

あなたの会社では、Google Kubernetes Engine (GKE) でアプリケーションを実行しています。いくつかのアプリケーションはエフェメラルボリュームに依存しています。ワーカーノードで DiskPressure ノード状態が発生したため、一部のアプリケーションが不安定になっていることに気づきました。どのPodが問題を引き起こしているかを特定する必要がありますが、ワークロードやノードへの実行アクセス権がありません。どうすればよいですか?

A.
Metrics Explorer を使用して、`node/ephemeral_storage/used_bytes` メトリクスを確認する。
B.
Metrics Explorer を使用して、`container/ephemeral_storage/used_bytes` メトリクスを確認する。
C.
`emptyDir` ボリュームを持つすべてのPodを特定する。`df -h` コマンドを使用してボリュームのディスク使用量を測定する。
D.
`emptyDir` ボリュームを持つすべてのPodを特定する。`df -sh *` コマンドを使用してボリュームのディスク使用量を測定する。
Question 65

あなたはクライアントのために新しいGoogle Cloud組織を設計しています。クライアントは、Google Cloudで作成される長期間有効な認証情報に関連するリスクを懸念しています。JSONサービスアカウントキーの使用に関連するリスクを完全に排除し、運用オーバーヘッドを最小限に抑えるソリューションを設計する必要があります。どうすればよいですか?

A.
組織に `constraints/iam.disableServiceAccountKeyCreation` 制約を適用する。
B.
事前定義ロールのカスタムバージョンを使用して、すべての `iam.serviceAccountKeys.*` サービスアカウントロール権限を除外する。
C.
組織に `constraints/iam.disableServiceAccountKeyUpload` 制約を適用する。
D.
`roles/iam.serviceAccountKeyAdmin` IAMロールを組織管理者のみに付与する。