Google プロフェッショナル クラウド デベロッパー コンピューティングおよびアプリ プラットフォームGoogle Professional Cloud Developer Compute and App Platforms

C

このタスクは、古いソフトウェアを削除する必要があることを示しているわけではありません。問題となるのは、時間が重要な問題の場合にのみ遅いことです。したがって、タイムクリティカルなアラートには Stackdriver を使用し、ログやそのビジネスケースのさらなる分析や保存には引き続き古いプラットフォームを利用します。

C

The task does not indicate that we should get rid of the old software. The pain point is slowness for time critical problems only. Thus we would use Stackdriver for the time critical alerts and still utilize the old platform for further analysis/storing of logs or whatever its business case is.

B と D は直接省略できます。
B. Stackdriver をインストールするだけでは何も役に立ちません。通知システムが必要です
D. ここではテストは関係ありません。
A&C に基づいて、私は C を選択します

we can directly omit B and D.
B. Just installing Stackdriver wont do any good. we need notification system
D. Testing is irrelevant here.
based on A&C, i would go with C

差し迫った問題に対処します:
* 重大な通知速度の問題を解決します
* 既存の監視インフラストラクチャを維持します
* 両方のシステムの長所を活用するハイブリッド アプローチを提供します
このアプローチの利点:
* Stackdriver のリアルタイム アラート機能を使用します
* 既存の監視プラットフォームへの投資を維持
* 現在の業務への中断を最小限に抑えます
* 必要に応じて段階的な移行が可能

Addresses Immediate Problem:
* Solves the critical notification speed issue
* Maintains existing monitoring infrastructure
* Provides a hybrid approach that leverages the best of both systems
Benefits of this approach:
* Uses Stackdriver's real-time alerting capabilities
* Preserves investment in existing monitoring platform
* Minimizes disruption to current operations
* Allows for gradual transition if needed

最もバランスが取れており、混乱が最も少ないアプローチは、オプション C の「Stackdriver を使用してログを取得し、アラートを出し、既存のプラットフォームに送信する」ことになるでしょう。この方法により、システムを全面的に見直しなくても、Stackdriver のリアルタイム アラート機能を既存のモニタリング ワークフローにシームレスに統合できます。

the most balanced and least disruptive approach would likely be option C, "Use Stackdriver to capture and alert on logs, then ship them to your existing platform". This method allows for a seamless integration of Stackdriver's real-time alerting capabilities into your existing monitoring workflow without the need for a complete overhaul of your system.

Bが正解です

B is correct answer

オプション C.

オンプレミス監視システムからの通知が遅すぎ、アプリケーションは現在 GCP にあります => Stackdriver のログでアラートが表示されます。

アプリが GCE、GKE、App Engine、または Cloud Run に移行されたかどうかについては言及されていないため、「Compute Engine インスタンス」は仮定に基づいています。

Option C.

Notifications from on-prem monitoring system are too slow & applications are in GCP now => Stackdriver alerts on logs.

There's no mentioning whether the apps have been migrated to GCE, GKE, App Engine or Cloud Run, so "Compute Engine instances" come from an assumption.

私ならCと一緒に行きます。

I would go with C.

オプション B「コンピューティング インスタンスにスタック ドライバー エージェントをインストールする」が正解です。
Stackdriver を使用して既存のプラットフォームに配布すると、多少の遅れが生じます

Option B , Install stack driver agents on the compute instances is the correct answer .
using stackdriver and shipping it to existing platform will have some delay

C
通知に問題があります。
C オプションを使用すると、Stackdriver を使用して、このすべてのデータをオンプレミス監視プラットフォームに送信した後すぐにアラートを送信できます。

C
you have problems with notifications.
C option allows you to use stackdriver to send alerts immediately and straight away after sends all this data to your on-prem monitoring platform

B が正解です。
https://cloud.google.com/monitoring/agent/monitoring/installation

B is the correct answer.
https://cloud.google.com/monitoring/agent/monitoring/installation

よく考えてください。あなたは、Splunk などの高価な監視システムを使用していて、インシデントから通知までの許容できない遅延時間の問題を抱えています。この問題を解決する必要があるのは、革命 (監視システムの変更) を行うことではありません。必要に応じてログがクラウド ロギングに保存されるため、すぐに使用できるアラート システムを備えた GCP モニタリングを大きな労力なしで活用できます。アラートを実装し、ログを Splunk にプッシュするだけです。シンプルズ。

Think twice. You have working an expensive monitoring system i.e Splunk and you have the problem with unacceptable delay time between incident and notification. You need to fix this problem, not doing a revolution (changing monitoring system). You can leverage GCP Monitoring with alerting system which is out-of-the-box with no huge effort, because if you want or not logs are in cloud logging. Simply implement alerts and push logs to Splunk. Simples.

Aが正しいです

A is correct

それが一番正しい答えです。 C はエージェントなしでは機能せず、古い監視にログを送信するのは意味がありません。

It's the rightest answer. C cannot work without Agent and there's not sense to send log to old monitoring

コンピューティング エンジンに Stackdriver エージェントをインストールしないと Stackdriver を使用できないためです。

It's A 'cos you cannot use Stackdriver if you don't install Stackdriver agent on your compute engine.

コミュニティの選択は C です

Community choice is C

CよりAのほうがいいと思います
アプリは移行されていますが、直接接続などを使用して古いシステムを修正する代わりに、データを既存のシステムに送り返すために C に投資する理由はありませんか

I think it should be A than C
Apps have been migrated and why would you invest on C to send data back to existing system instead fix old system using direct connect or something

答えは C です。ポイントは監視ではなく、パフォーマンスが低い通知の問題です。

The answer is C. The point is notification problem with low performance, not monitoring.

答え:A

Ans:A

オプション A は、App Engine の組み込みトラフィック分割機能を使用して、サイトのさまざまなバージョンにトラフィックを分散できるため、最良のアプローチです。この機能は、A/B テストとまったく同様のシナリオ向けに設計されており、複数の Web サイト設計にわたるコンバージョン率をシームレスかつ効率的にテストできるようになります。

option A is the best approach because it allows you to use App Engine's built-in traffic splitting feature to distribute traffic across different versions of your site. This feature is designed for scenarios exactly like A/B testing, making it possible to seamlessly and efficiently test conversion rates across multiple website designs.

A が正解です。

A is Correct.

同じサービスにデプロイされた各バージョンの URL があります。

you have a URL for each version deployed in the same service.

Aが正しいです

A is correct

もちろん

A of course

トラフィック分割の方が適していると思います

i think traffic splitting is more suitable

私は A に投票しますが、質問が詳細ではないため、間違っている可能性があります。 URL を同じままにするように要求するものではありません。したがって、B が良い答えになる可能性があります。この方法では、分割を管理する必要がなく、3 つの異なる URL が得られます。

I vote A but It could be wrong 'cos the question is not detailed. It doesn't ask to let url remain the same. So B could be a good answer: in this way you have 3 url different without any need to manage splitting

A
A は正解です。これにより、トラフィックを単一ドメインにルーティングし、IP または Cookie に基づいてトラフィックを分割できます。
B は不正解です。ドメイン名はサービスに応じて変わります。
出典: Google サンプル質問

A
A is correct because it allows routing traffic to a single domain and split traffic based on IP or Cookie.
B is not correct because the domain name will change based on the service.
source: Google Sample Questions

3 つの異なる Web サイトをテストし、トラフィック分割をどのように使用するかを比較したい場合 (33%)

If you want to test three different websites and compare how would you use traffic splitting (33%)

Aが正しいです

A is correct

これは間違いなくAです

This is A for sure

この質問は質問例でも出題されています。
正解は A です。トラフィック分割はまさにテスト目的であり、100% のトラフィックを特定のバージョンにリダイレクトすることを選択できます。

this question is also asked in the example questions.
Correct answer is A, because traffic splitting is exactly for testing purpose and you can choose to redirect 100% percent traffic to a specific version.

ウェブサイトのデザインは 3 つありますが、サービスは同じです。 Aだと思います

3 different website designs but the same service. I think is A

答えは B で、Appengine サービスが 3 つあります。 (必要なバージョンにアクセスするには 3 つの URL)。
バージョンごとにトラフィックが分割されているため、必要なバージョンを正確に選択することはできません...

Answer is B with 3 appengine services. (3 urls to access the version you want).
With traffic splitting on versions, you can't chosse exactly the version you want...

同意 C が正しい選択肢です

Agreed C is correct option

gcloud compute scp は、VM からファイルをコピーまたは転送するために使用されます。

gcloud compute scp is used to copy or transfer files from a vm

C が正解です。

C is correct.

Cが正解です

C is correct

SCPのせいでC

C because of scp

Cが正解です

C is the correct answer

B

プロセスの健全性ポリシー
プロセス正常性ポリシーは、パターンに一致するプロセスの数がしきい値を超えた場合に通知できます。これは、たとえば、プロセスの実行が停止したことを通知するために使用できます。

B

Process-health policy
A process-health policy can notify you if the number of processes that match a pattern crosses a threshold. This can be used to tell you, for example, that a process has stopped running.

C

メトリクスの不在
UNIX プロセスが少なくとも 5 分間実行されなかった場合にアラートを受け取りたいとします。アプリケーションを変更して指標やログを生成することはできないため、Stackdriver Monitoring Agent によって収集された指標の欠如を検出する必要があります。

C

Metric absence
You want to be alerted if the UNIX process has not run for at least 5 minutes. Since you cannot modify the application to generate metrics or logs, you need to rely on detecting the absence of metrics collected by the Stackdriver Monitoring Agent.

プロセスがメトリクスのレポートを停止したかどうかを単に判断することが要件の場合は、「メトリクスの不在」が推奨される選択肢です。

If the requirement is to simply determine whether a process has stopped reporting metrics, Metric Absence is the preferred choice.

メトリクスの不在により、プロセスに関連するメトリクス (CPU 使用率、メモリ使用量など) が特定の期間 (5 分間など) 受信されなかった場合にアラートをトリガーできます。

Metric absence allows you to trigger an alert if no metrics (e.g., CPU usage, memory usage, etc.) related to the process are received for a specific period, such as 5 minutes

Unix プロセスが少なくとも 5 分間実行されていない場合にアラートを受け取るには、**メトリックの不在** アラート条件を構成する必要があります。アプリケーションを変更してメトリクスやログを生成することはできないため、このアプローチを使用すると、特定の期間におけるデータの欠如を監視できます。 Unix プロセスの実行が停止すると、メトリック データが失われ、アラートがトリガーされます。

したがって、正解は **C です。メトリクスの不在**。このタイプのアラート ポリシーは、プロセス実行における予期せぬ中断について常に最新の情報を得るのに役立ちます。

To be alerted if your Unix process has not run for at least 5 minutes, you should configure a **metric absence** alert condition. Since you cannot modify the application to generate metrics or logs, this approach allows you to monitor the absence of data for a specific duration. When the Unix process stops running, the metric data will be absent, triggering the alert.

Therefore, the correct answer is **C. Metric absence**. This type of alerting policy will help you stay informed about any unexpected interruptions in your process execution.

B が正しいです。

B is correct.

B が正しいです

B is correct

B が正しいです

B is correct

https://cloud.google.com/monitoring/uptime-checks:
「稼働時間チェックは、リソースが応答するかどうかを確認するためにリソースに送信されるリクエストです。」

Aは間違っています

メトリクスの不在としきい値は意味をなさない

プロセスの健全性は確かに正しいので、答えは B です

https://cloud.google.com/monitoring/uptime-checks:
"An uptime check is a request sent to a resource to see if it responds"

A is wrong

Metric absence and threshold don't make sense

Process health is correct for sure so answer is B

Bが正解です
https://cloud.google.com/monitoring/alerts/types-of-conditions#metric-threshold

B is correct answer
https://cloud.google.com/monitoring/alerts/types-of-conditions#metric-threshold

「署名付き URL」を使用して、App Engine の 32 MB 制限なしでファイルを Google Cloud Storage に直接アップロードします。

Via 'Signed URLs' to upload the file directly to Google Cloud Storage without 32MB limit of App Engine.

C は正解です。署名付き URL を使用すると、期間限定のアクセス権を持つ URL を生成して、Google Cloud Storage に直接アップロードできます。この方法では、App Engine のファイル アップロード制限が回避され、クライアントは大きなファイルを Cloud Storage に直接アップロードできます。

C is correct: Signed URLs allow you to generate URLs with limited-time access to upload directly to Google Cloud Storage. This method bypasses App Engine's file upload limitations and allows clients to upload large files directly to Cloud Storage.

D. API をマルチパート ファイル アップロード API に変更する: マルチパート アップロードは大きなファイルには役立ちますが、App Engine のサイズ制限という核心的な問題には対処できません。アップロードは App Engine を経由する必要があるため、制限を超える可能性があります。

D. Change the API to be a multipart file upload API: While multipart uploads can be helpful for large files, they don't address the core issue of App Engine's size limitations. The uploads would still need to go through App Engine, potentially exceeding the limits.

C. 署名付き URL を使用してファイルをアップロードする: 署名付き URL は、Google アカウントの認証情報を必要とせずに、特定の Google Cloud Storage オブジェクトへの時間制限付きの読み取りまたは書き込みアクセスを許可する安全な方法です。 HTTP メソッド (アップロードの場合は PUT) や有効期限などの指定された制限付きでオブジェクトにアクセスできるようにする署名付き URL を作成できます。この方法を使用すると、API ユーザーはファイルを Google Cloud Storage に直接アップロードできるため、大きなファイルを効率的に処理できます。 App Engine アプリケーションは、必要に応じてこれらのファイルを処理または参照できます。

C. Use signed URLs to upload files: Signed URLs are a secure way to give time-limited read or write access to a specific Google Cloud Storage object, without needing Google account credentials. You can create a signed URL that allows an object to be accessed with the specified restrictions such as HTTP method (PUT for uploads) and an expiration time. This method would allow your API users to upload files directly to Google Cloud Storage, which can handle large files efficiently. Your App Engine application can then process or reference these files as needed.

C は、ファイルをアップロードしてもらいたい場合には非常に良い選択肢ですが、サイズに代表される問題は解決しません。

While C is a very good option if you want to people to upload files, it does not solve the problem represented by the size.

マルチパート ファイルのアップロードをサポートするように API を変更すると、既存の API の機能を維持しながら、App Engine 環境に適応させることができます。

By changing the API to support multipart file uploads, you can maintain the functionality of your existing API while adapting it to the App Engine environment.

署名付き URL ではマルチパート モードで大きなファイルをアップロードできるため、正解は C です。

The correct answer is C because signed url permits to upload a big file in multipart-mode

大きなサイズのファイルをアップロードするにはマルチパートを使用する必要があります

It should use multipart to upload big size files

Cはどうして正しいのでしょうか？バケット内のオブジェクトに一時的にアクセスするために使用されるのではありませんか?

How is C correct ? Isn't it used to give temporary access to objects in buckets ?

Cが正解です

C is correct

Cが最良の選択です

C is the best choice

https://cloud.google.com/appengine/docs/standard/php/googlestorage/user_upload:
「この URL は作成後 10 分以内にアップロードを開始する必要があることに注意してください。また、URL はいかなる方法でも変更することはできません。URL は署名されており、アップロードが開始される前に署名がチェックされます。」

Cが答えです

https://cloud.google.com/appengine/docs/standard/php/googlestorage/user_upload:
"Note that you must start uploading to this URL within 10 minutes of its creation. Also, you cannot change the URL in any way - it is signed and the signature is checked before your upload begins"

C is the answer

Cが正解です

C is correct answer

オプション B は、/healthz エンドポイントを readiness プローブとして使用するためにポッド構成に含める正しいコード スニペットです。

オプション A で指定された liveness プローブは、アプリケーションが実行中で応答しているかどうかを判断するために使用されます。 liveness プローブが失敗した場合、アプリケーションは失敗した状態とみなされ、再起動されます。

オプション B で指定された readiness プローブは、ポッドがいつトラフィックを受信できるかを判断するために使用されます。 Readiness Probe が失敗した場合、Pod は再び正常になるまでロード バランサーからトラフィックを受信しません。

オプション C、loadbalancerHealthCheck は、ポッド構成の有効なフィールドではありません。

オプション D の healthCheck も、ポッド構成では有効なフィールドではありません。

Option B is the correct code snippet to include in the Pod configuration in order to use the /healthz endpoint as a readiness probe.

The liveness probe, specified in option A, is used to determine whether the application is running and responsive. If the liveness probe fails, the application is considered to be in a failed state and will be restarted.

The readiness probe, specified in option B, is used to determine when a Pod is ready to receive traffic. If the readiness probe fails, the Pod will not receive traffic from the load balancer until it becomes healthy again.

Option C, loadbalancerHealthCheck, is not a valid field in a Pod configuration.

Option D, healthCheck, is also not a valid field in a Pod configuration.

Readiness Probe はポッドを「実行中」としてマークし、トラフィックの受け入れを開始できるようになります。
ただし、ポッドが「実行中」状態になると、Liveness プローブが機能し、ポッドのライフサイクル全体のヘルス チェックとして機能します。

そこで、こう考えてみてください。ポッドは最初のチェック (準備完了) に合格し、しばらくの間トラフィックを受け入れた後、クラッシュします (論理的には、ポッドはまだ「実行中」である可能性があります)。
Liveness プローブはそれを検出します。そうしないと、LB はトラフィックを処理できないポッドにトラフィックを渡す可能性があります。

したがって、Aだと思います。

Readiness probe marks the pod as "Running" and can START accepting traffic.
However, after the pod is in a "Running" state, the Liveness probe comes in and acts as the health check for the entire lifecycle of the pod.

So think of it this way. The pod passes its initial check (readiness), accepts traffic for a while then crashes (logically, the pod can still be "Running").
The Liveness probe is responsible for detecting it. Otherwise, the LB could still pass traffic to a pod that can't serve traffic.

Therefore, I believe it's A.

B が正しいです

B is correct

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ によれば、B は正しいです。

B is correct according with https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features

ingress backendconfig は healthCheck を設定できますが、このリソースは httpGet を設定できません

```
APIバージョン:cloud.google.com/v1
種類: BackendConfig
メタデータ:
名前: my-backendconfig
仕様:
ヘルスチェック:
checkIntervalSec: 間隔
タイムアウト秒: タイムアウト
健康しきい値: HEALTH_THRESHOLD
不健康なしきい値: UNHEALTHY_THRESHOLD
タイプ: プロトコル
リクエストパス: PATH
ポート: ポート
```

https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features

ingress backendconfig can set healthCheck, but this resource can not set httpGet

```
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
healthCheck:
checkIntervalSec: INTERVAL
timeoutSec: TIMEOUT
healthyThreshold: HEALTH_THRESHOLD
unhealthyThreshold: UNHEALTHY_THRESHOLD
type: PROTOCOL
requestPath: PATH
port: PORT
```

B が正しいです

B is correct

https://cloud.google.com/kubernetes-engine/docs/concepts/ingress:
「サービス提供ポッドが、readiness プローブにヘルスチェック パラメータとして解釈できる属性を持つコンテナを持つポッド テンプレートを使用している場合、GKE はヘルス チェックのパラメータの一部またはすべてを推論できます。実装の詳細については、readiness プローブからのパラメータを、ヘルス チェック パラメータの作成に使用できる属性のリストについては、デフォルトおよび推論されたパラメータを参照してください。readiness プローブからのパラメータの推論をサポートしているのは、GKE Ingress コントローラのみです。」

B が正しいです

https://cloud.google.com/kubernetes-engine/docs/concepts/ingress:
"GKE can infer some or all of the parameters for a health check if the Serving Pods use a Pod template with a container whose readiness probe has attributes that can be interpreted as health check parameters. See Parameters from a readiness probe for implementation details and Default and inferred parameters for a list of attributes that can be used to create health check parameters. Only the GKE Ingress controller supports inferring parameters from a readiness probe."

B is correct

Bが正解です

https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes

B is correct answer

https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes

B です - クライアントはクラスター内にあるため、サービス DNS 名を使用できます。

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
「クラスター内で定義されたすべてのサービス (DNS サーバー自体を含む) には、DNS 名が割り当てられます。デフォルトでは、クライアント ポッドの DNS 検索リストには、ポッド自体の名前空間とクラスターのデフォルト ドメインが含まれます。」

It's B - Clients are in the cluster and therefore can use service dns names.

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
"Every Service defined in the cluster (including the DNS server itself) is assigned a DNS name. By default, a client Pod's DNS search list includes the Pod's own namespace and the cluster's default domain."

B. これは標準の Kubernetes サービス検出メカニズムです。 Kubernetes でサービスを定義すると、内部クラスター DNS に DNS エントリが作成されます。クラスター内のすべてのポッドは、サービス名を DNS 名として使用してサービスにアクセスできます (例: http://service-name)。これは、クラスター内でサービス検出を可能にする最も簡単で Kubernetes ネイティブな方法です。

B. This is the standard Kubernetes service discovery mechanism. When you define a Service in Kubernetes, it creates a DNS entry in the internal cluster DNS. Any pod in the cluster can then reach the service using the service name as a DNS name (e.g., http://service-name). This is the most straightforward and Kubernetes-native way to enable service discovery within a cluster.

これはマイクロサービス アーキテクチャの例なので、答えは次のとおりです: B

This is an example of Microservice Architecture, so Ans is : B

B が正しいです。

B is correct.

A.
GKE エンドポイントは外部向けであり、Opt C と D は非対応です。また、エンドポイントに公開しても、GKE クラスタ内のすべてのコンテナが公開されるわけではありません。1 つのサービスがコンテナを含む 4,000 個のノードに公開する場合、GKE は 4,000 回更新する必要があるということですか?これでは意味がありません。オプション B ではサービス名、つまり CNAME を使用するため、依然として Cloud DNS を経由する必要があります。したがって、選択肢 A は正しいものとなります。

A.
GKE endpoint is external facing, Opt C and D are out. Also exposing to endpoint won't expose all containers in the GKE cluster - if one service exposes to 4000 nodes with containers then does this mean the GKE would need to update 4000 times? This just doesn't make sense. Opt B use service name, in other words, CNAME, so it still has to go through Cloud DNS. Hence the opt A shall be correct.

Bです

It's B

A と B は両方とも有効です
オプション A、DNS A レコードは、サービス FQDN を IP アドレスにマップします。fqdn は、service-name.default.svc.cluster.local のようになります。
B の方が簡単です。http://service-name を使用するだけです。

both A and B are valid
Option A, DNS A record maps service FQDN to IP address, fqdn like service-name.default.svc.cluster.local
B is more easier, just use http://service-name

答えは B です。クライアントは同じクラスター内にあるため、サービス名を使用できます。

answer is B because client are in the same cluster so service name can be used.

質問には「IPアドレス」とありますが、Bを使用してもIPは取得できないと思います。

Question reads "IP address" and I don't think that using B the IP can be obtained.

https://cloud.google.com/kubernetes-engine/docs/concepts/service-discovery

「Kubernetes では、サービスの検出は、サービスの IP アドレスにマップされる自動生成されたサービス名を使用して実装されます。サービス名は、my-svc.my-namespace.svc.cluster-domain.example のように、標準仕様に従います。ポッドは、example.com などの名前を通じて外部サービスにアクセスすることもできます。」

https://cloud.google.com/kubernetes-engine/docs/concepts/service-discovery

"In Kubernetes, service discovery is implemented with automatically generated service names that map to the Service's IP address. Service names follow a standard specification: as follows: my-svc.my-namespace.svc.cluster-domain.example. Pods can also access external services through their names, such as example.com. "

B が正しいです

B is correct

B が正しいです

B is correct

B である必要があります

Should be B

Bは回収です。

クライアントとサーバーが同じ名前空間にある場合、C は収集されます。ただし、この場合、名前空間の条件はありません。したがって、クライアント ポッドはサーバー サービス名を使用する必要があります。

B is collect.

If client and server are in same namespace, C is collect.But in this case, no condition of namespace. So client pod must be use server service name.

D: https://cloud.google.com/endpoints/docs/openapi/get-started-kubernetes-engine#cconfiguring-endpoints-dns を参照してください。

D: see https://cloud.google.com/endpoints/docs/openapi/get-started-kubernetes-engine#configuring-endpoints-dns

A - SVC を使用してポッドを公開し、クラスター DNS サービスを取得して IP を取得します。

A - use SVC to expose your pod, and get the cluster DNS service to get the IP

A. Stackdriver Logging エージェントは、仮想マシン上のさまざまなソースからログを収集し、Stackdriver Logging に送信できるソフトウェア エージェントです。エージェントを構成すると、カスタム ログ ファイルのパスを指定でき、エージェントはこれらのログを Stackdriver Logging に転送します。これは、アプリケーション コードを変更できない、または変更したくない場合に、最も直接的で煩わしさが少ない方法です。

A. The Stackdriver Logging Agent is a software agent that can collect logs from various sources on your virtual machine and send them to Stackdriver Logging. By configuring the agent, you can specify custom log file paths, and the agent will forward these logs to Stackdriver Logging. This is the most direct and least intrusive method when you cannot or do not want to change the application code.

正解はAです

Correct answer is A

Aが正しいです

A is correct

正解：A

Correct Answer: A

ここではAが正解です

A is correct here

A は正解です。VM にスタックドライバー エージェントをインストールする必要があります。

A is correct -We need to install stackdriver agent in the VM

Aが正しいです

A is correct

Aが正しいです

A is correct

https://cloud.google.com/logging/docs/agent/logging/installation:
「Logging エージェントは、VM インスタンスと選択したサードパーティ ソフトウェア パッケージから Cloud Logging にログをストリーミングします。」

Aが正しいです

https://cloud.google.com/logging/docs/agent/logging/installation:
"The Logging agent streams logs from your VM instances and from selected third-party software packages to Cloud Logging"

A is correct

ここでは A が正しい選択肢です

A is correct option here

これについてはオプション B を選択します。

RollingUpdate: 新しいポッドは徐々に追加され、古いポッドは徐々に終了されます
再作成: 新しいポッドが追加される前に、古いポッドはすべて終了されます。

質問では、現在のバージョンを保持するように求められているため、ここではローリング アップデートの方が良い選択肢です。

I will go with Option B for this.

RollingUpdate: New pods are added gradually, and old pods are terminated gradually
Recreate: All old pods are terminated before any new pods are added

Question ask us to retain current version hence rolling update is better option here.

https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-upgrades:
「サージ アップグレードを活用する最も簡単な方法は、maxSurge=1 maxUnavailable=0 を設定することです。これは、アップグレード中にノード プールに追加できるサージ ノードは 1 つだけであるため、一度にアップグレードされるノードは 1 つだけであることを意味します。この設定は、保守的に進行しながらアップグレード中の Pod の再起動を高速化するため、既存のアップグレード構成 (maxSurge=0 maxUnavailable=1) よりも優れています。」

答えはBです

https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-upgrades:
"The simplest way to take advantage of surge upgrade is to configure maxSurge=1 maxUnavailable=0. This means that only 1 surge node can be added to the node pool during an upgrade so only 1 node will be upgraded at a time. This setting is superior to the existing upgrade configuration (maxSurge=0 maxUnavailable=1) because it speeds up Pod restarts during upgrades while progressing conservatively."

Answer is B

B. デプロイメント戦略を RollingUpdate に設定し、maxSurge を 1 に設定し、maxUnavailable を 0 に設定します。

maxSurge を 1 に設定すると、デプロイメントで必要なポッド数を 1 つ超えることができ、古いポッドを終了する前に追加の新しいポッドを作成できるようになり、要件と一致します。
maxUnavailable を 0 に設定すると、更新中にすべての既存の Pod が利用可能な状態を維持する必要があり、これも要件を満たします。

B. Set the Deployment strategy to RollingUpdate with maxSurge set to 1, maxUnavailable set to 0:

maxSurge set to 1 allows the Deployment to exceed the desired number of Pods by one, permitting the creation of an additional new Pod before terminating the old ones, which aligns with the requirement.
maxUnavailable set to 0 ensures that all existing Pods must remain available during the update, which again meets the requirement.

「maxSurge=1」は、RU プロセス中に少なくとも 1 つの VM が稼働し続ける必要があることを意味します。

"maxSurge=1" means that at least one VM has to stay up during the RU process.

選択肢 B が正しい選択肢です。

Option B is the correct one.

新しいバージョンの少なくとも 1 つのレプリカをデプロイし、新しいレプリカが正常になるまで以前のレプリカを維持するには、デプロイメント戦略を RollingUpdate に設定し、maxSurge を 1 に設定し、maxUnavailable を 0 (B) に設定する必要があります。

RollingUpdate Deployment 戦略を使用すると、更新プロセスの一環として一度に作成または削除できるレプリカの数を指定できます。 maxSurge パラメータは、必要なレプリカ数を超えて作成できるレプリカの最大数を指定し、maxUnavailable パラメータは、特定の時点で使用できないレプリカの最大数を指定します。

maxSurge を 1 に、maxUnavailable を 0 に設定すると、新しいバージョンの新しいレプリカを少なくとも 1 つ作成し、新しいレプリカが正常になるまで以前のレプリカをすべて維持するようにデプロイメントに指示することになります。これにより、新しいバージョンの少なくとも 1 つのレプリカが常に利用できるようになり、デプロイメントが残りのレプリカに更新を段階的にロールアウトできるようになります。

To deploy at least 1 replica of the new version and maintain the previous replicas until the new replica is healthy, you should set the Deployment strategy to RollingUpdate with maxSurge set to 1 and maxUnavailable set to 0 (B).

The RollingUpdate Deployment strategy allows you to specify the number of replicas that can be created or removed at a time as part of the update process. The maxSurge parameter specifies the maximum number of replicas that can be created in excess of the desired number of replicas, and the maxUnavailable parameter specifies the maximum number of replicas that can be unavailable at any given time.

By setting maxSurge to 1 and maxUnavailable to 0, you are telling the Deployment to create at least 1 new replica of the new version and to maintain all of the previous replicas until the new replica is healthy. This will ensure that at least 1 replica of the new version is always available, while allowing the Deployment to gradually roll out the update to the rest of the replicas.

Bは明らかです

B is obvious

B が正しいです

B is correct

B が正しいです

B is correct

明らかにBです

Obviously it's B

答えはBです

Answer is B

答えはBです

Answer is B

答えはBです。

the answer is B.

再作成では以前のレプリカを維持できません。答えはBでなければなりません。

Recreate can't be maintain previous replica. Answer must be B.

Bが正解です

B is correct answer

Recreate 戦略では何もメンテナンスしていません

You are not maintaining anything with Recreate strategy

シンプルな静的 HTML アプリケーションをデプロイする最も簡単で効率的な方法は、B. アプリケーションを App Engine 環境にアップロードすることです。

A. アプリケーションを Cloud Storage にアップロードすることは、静的ウェブサイトをホストするための実行可能なオプションですが、特に初心者にとっては、App Engine にデプロイするほど簡単ではありません。

The most straightforward and efficient way to deploy a simple static HTML application is to B. Upload your application to an App Engine environment.

While A. Upload your application to Cloud Storage is a viable option for hosting static websites, it's not as straightforward as deploying to App Engine, especially for beginners.

オプション A: Cloud Storage で静的アプリケーションをホストできるため。

Option A: As we can host static applications on Cloud Storage.

正解：A

Correct Answer: A

Aが正しいです

A is correct

Aが正しいです

A is correct

Aは正しいです

A is right

A が正しいです。提供されたリンクがそれをサポートしています

A is correct; provided link supports it

A、静的な場合、最も早い方法はクラウド ストレージを使用することです。

A, if its static then quickest way is via cloud storage.

ここではDが正解です。

D is correct answer here.

私にとって、オプションは C または D です。すぐに A と B を省略します。理由は A です。レイテンシ分析には適していますが、コードの動作の監視には推奨されません。
B - コード監視には適さないリソース監視ツールです
C - スナップショットはコールスタックと変数の詳細を提供しますが、継続的な監視には役に立ちません
D - 分析用の一時ログは提供されますが、検査用の変数は提供されません。
質問は経時的なモニタリングについて尋ねているので、私は D を選択します。特定の PIT について質問された場合は、オプション C を選択します。

For me, The options is either C or D , i would omit A & B right away, the reason is A - good for latency analysis but it is not recommended for monitoring code behaviour.
B - Its a resource monitoring tool not suitable for code monitoring
C - Snapshots provide details on call stack and variables but it is not usefull in continous monitoring
D - It gives temp logs for analysis but it doesnt give variables for inspection.
since the questions asks about monitoring over time im choosing D , it they asked about specific PIT , i would choose option C

質問にはデバッグについては何も記載されていないため、監視する必要があります。

There is nothing about debugging in the question, so should be monitoring.

このシナリオに最適なツールは、C. Stackdriver Debug Snapshots です。その理由は次のとおりです。

Stackdriver デバッグ スナップショットを使用すると、特定の時点でのアプリケーションの状態のスナップショットを取得できます。これには、呼び出しスタックと変数値が含まれます。これにより、問題発生時のコードの実行パスと変数の値を調べることができ、アプリケーション コード内の問題を正確に特定するのに役立ちます。

The best tool for this scenario is C. Stackdriver Debug Snapshots . Here's why:

Stackdriver Debug Snapshots allow you to take a snapshot of your application's state at a specific point in time. This includes the call stack and variable values. This lets you examine the code's execution path and the values of variables at the time of the issue, helping you pinpoint the problem within the application code.

コードを変更せずに、コード内の何が問題なのかを確認したいとします。 => ログポイント。

You want to see what is the problem in the code without altering it. => Logpoints.

アプリケーションを監視したい - > Stackdriver 監視

You want to MONITOR the application - > Stackdriver MONITORING