Google Professional Cloud デベロッパー デリバリーと CI/CDGoogle Professional Cloud Developer Delivery and CI/CD

B カナリア デプロイメントでは、アプリケーションの新しいバージョンをすべてのユーザーにロールアウトする前に、少数のユーザー サブセットにリリースできます。この戦略は、最初にトラフィックのごく一部のみが新しいバージョンに送信されるため、ユーザーへの影響を最小限に抑えながら、新しいバージョンの潜在的な問題を特定するのに役立ちます。

B Canary deployment allows you to release a new version of your application to a small subset of users before rolling it out to everyone. This strategy helps you identify potential issues with the new version while minimizing the impact on users, as only a small portion of traffic is directed to the new version initially.

これは A です。Canary はテスト戦略であり、展開戦略ではありません。

this is A, Canary is a Testing strategy not a deployment strategy.

B. カナリア デプロイメント: この戦略では、アプリケーションの新しいバージョン (「カナリア」) がユーザー ベース全体で利用可能になる前に、少数のユーザーのサブセットにロールアウトされます。これにより、実際の運用環境で実際のトラフィックを使用して新しいバージョンのパフォーマンスと安定性を監視できますが、影響を受けるのは少数のユーザー グループのみです。問題が発生した場合は、最小限の影響でカナリア デプロイメントをロールバックできます。

B. Canary deployment: In this strategy, the new version of the application (the "canary") is rolled out to a small subset of users before it is made available to the entire user base. This allows you to monitor the performance and stability of the new version in the real-world production environment with actual traffic, but only affects a small group of users. If issues arise, the canary deployment can be rolled back with minimal impact.

まさにそれが Canary Deployment の目的です。

That's exactly what Canary Deployment is for.

このシナリオには B が最適であるため、私は B を選択します。

I would go with B as it is best suited for this senario.

答えは B です。これはプログレッシブ リリースであるため、ユーザーへの影響を軽減するためです。

answer is B to reduce impact on users because it's a progressive release

緑への切り替えはすべてのテストを実行した後にのみ行われるため、A が正しいと思います。したがって、（質問を満たすために）トラフィックをテストすることもできます。これが、私が理解した限り、Blue-Green デプロイメントのポイントです。
B は不正解です。実際のトラフィックは部分的に新しいバージョンにすぐに切り替えられるため、一部のユーザーに影響を与えます。

参照: https://digitalvarys.com/what-is-blue-gren-deployment/

I think A is correct because of the switching to green only happens after you perform all the tests on it. So you can also test traffic (to satisfy the question) This is the point of blue-green deployment as far as I understood it.
B is not correct because the real traffic is switched partially to new version immediately and so it effects some users.

reference: https://digitalvarys.com/what-is-blue-gren-deployment/

ブルー/グリーンは 100% ユーザーからグリーン、カナリア ID はプログレッシブです。 B.

Blue/Green is 100% users to Green, Canary id progressive. B.

B が正しいです

B is correct

私の場合はBです。カナリアデプロイメントでは、一部のユーザーのみが新しいバージョンを受信するため、エラーが発生した場合はすぐにロールバック、B/Gはすぐに新しいバージョンを受信し、緑はすべてのトラフィックを受信し、青は非推奨としてマークされます。

For me it's B, in Canary Deployment only a percentage of users receives the new version and therefore in case of error immediately rollback , B/G immediately the new version , Green, receive all traffic and Blue marked as deprecated

I think the concept of google about B/G testing is that there is a shadow running next to production that receives the same traffic as production.このシャドウにエラーがない場合は、シャドウを PROD に更新できます。したがって、考えられるすべての新しいエラーは本番環境ではなくシャドウで発生するため、ユーザーは影響を受けません。

I think the concept of google about B/G testing is that there is a shadow running next to production that receives the same traffic as production. When this shadow is not having any errors you can update the shadow to PROD. So no user is impacted, since all possible new errors will occur in the shadow and not in prod.

私にとっては B です。しかし、なぜ購入したすべての試験がこの質問で青/緑を正解とするのか理解できません。 Canary が最も正しいことは明らかです。なぜなら、少数のユーザーのみを新規デプロイに転送し (全員がブルー/グリーンであるわけではありません)、ロールバック アクションも許可しているからです。

For me is B. But I cannot understand why all purchased exam test with this question, put Blue/Green as correct answer. It's so clear that Canary is the rightest one 'cos forward only a few of users to new deploy (not every as blue/green) and also allow the rollback action

B が正しいです。青緑(B/G)はすべてのユーザーに影響します。

B is correct. Blue Green(B/G) affects all users.

1. 影響の軽減
2. 影響を受けるユーザーの数
両方の条件を満たす場合は、Canary を選択する必要があります

1. Reducing impact
2. Number of users affected
If you want meet both of the conditions, you need to choose Canary

Bだと思うんですが、正解はAですね、うーん……。
トラフィックの 100% をテストする必要があると考える場合、つまり、完全に動作するテストを作成する必要がある場合は、正解です。エラーが発生した場合は、すぐに古いバージョンに戻すことができるためです。

I think it is B, but correct answer is A, hmmm.......
if we think that we need to test 100% of the traffic, i.e. create a full working test, then right A, because if there is an error we can quickly go back to the old version

同意B

Agree B

Bが正解です
https://cloud.google.com/cloud-build/docs/cconfiguring-builds/use-community-and-custom-builders#creating_a_custom_builder

B is correct answer
https://cloud.google.com/cloud-build/docs/configuring-builds/use-community-and-custom-builders#creating_a_custom_builder

他のプロジェクトでも使用できるため、一般的なソリューションだと思います。

I think is a generic solution because I can use it in other projects.

B が正しいです。

B is correct.

B が正しいです

B is correct

B が正しいです

B is correct

B が正しいです

B is correct

b https://cloud.google.com/cloud-build/docs/cconfiguring-builds/use-community-and-custom-builders#creating_a_custom_builder

b https://cloud.google.com/cloud-build/docs/configuring-builds/use-community-and-custom-builders#creating_a_custom_builder

B が正しいです。
ただし、通常は A の方が B よりも高速です (Docker イメージのダウンロード速度 <<< バイナリのダウンロード)

B is correct.
But in usual A is faster than B(download docker image speed <<< download binary)

正解はBだと思います）
Container Registry は、コンテナを安全に管理できる方法で保存するのに適しています。 Cloud Build サービス アカウントのロールを持つコンテナをホストするために使用される Cloud Storage バケットのメンバーとして適切なサービス アカウントを追加することで、あるプロジェクトに ContainerRegistry を設定し、別のプロジェクトの Cloud Build からそれにプッシュすることができます。

I think the correct answer is B)
Container Registry is a good choice to store containers in a secure manageable way. It is possible to have ContainerRegistry in One project and push to it from Cloud Build of another project by adding appropriate service account as a member of a Cloud Storage Bucket used to host containers with the role Cloud Build Service Account.

B. Container Registry が構成された運用チーム用の別のプロジェクトを作成します。各開発者チームのプロジェクトの Cloud Build サービス アカウントに適切な権限を割り当て、運用チームのレジストリへのアクセスを許可します。

このアプローチは、高レベルのセキュリティと制御を維持しながら、アクセスを管理し、Docker イメージのストレージを一元化するためのベスト プラクティスと一致しています。

B. Create a separate project for the operations team that has Container Registry configured. Assign appropriate permissions to the Cloud Build service account in each developer team's project to allow access to the operation team's registry.

This approach aligns with best practices for managing access and centralizing the storage of Docker images while maintaining a high level of security and control

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

I would go with B.

オプション B は、すべての開発チームが使用できる一元的で安全に管理された Docker レジストリを提供し、Docker イメージをレジストリにプッシュするために必要な権限を Cloud Build サービス アカウントに付与できるため、最適なソリューションです。

The option B is the best solution because it provides a centralized, securely managed Docker registry for all development teams to use, and the Cloud Build service account can be granted the necessary permissions to push Docker images to the registry.

Bも正しいと思います

I think B is the correct one as well

B が最適な選択です。これにより、運用チームは一元化され安全に管理された Docker レジストリを制御できると同時に、開発チームがプロジェクトで Cloud Build を使用できるようになります。このオプションでは、運用チームは Container Registry が構成された別のプロジェクトを作成し、各開発者チームのプロジェクトの Cloud Build サービス アカウントに適切な権限を付与して、運用チームのレジストリへのアクセスを許可できます。これにより、開発チームは運用チームの要件に従いながら、Docker イメージを構築して一元化されたレジストリにプッシュできます。

B is the best choice because it allows the operations team to have control over the centralized, securely managed Docker registry while also allowing the development teams to use Cloud Build in their projects. In this option, the operations team can create a separate project with Container Registry configured and grant appropriate permissions to the Cloud Build service account in each developer team's project to allow access to the operations team's registry. This allows the development teams to build and push Docker images to the centralized registry while still following the operations team's requirements.

B が正しいです。プロジェクトごとに 1 つの CR をデプロイしても意味がありません。

B is correct. No point deploying 1 CR per project.

B が正しいです

B is correct

この場合、B が適切な答えです

B is the suitable answer in this case

B は、異なるプロジェクト間で画像を保存および共有するための最良の方法です。
さらに、SA の使用は GCP の推奨事項と一致する選択肢です

B is the best way to store and share images between different projects.
Furthermore use of SA is a choice that match with GCP recommendations

「一元化され、安全に管理された Docker レジストリ」

Bが答えです

"centralized, securely managed Docker registry"

B is the answer

私の答えは C です。サービス アカウントを使用してアクセス許可を付与し、それをセキュリティで保護された変数に保存するのが適切な方法です。

My answer is C , using service account to give permissions and storing it in a secured variable is a proper way

ここではDが正解です

D is correct answer here

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

I would go with D.

D - 単体テストと統合テストをコンパイルして実行するための個別のクラウド ビルダー ステップを含む Cloud Build ビルド構成ファイルを作成します。これにより、ビルド プロセスのさまざまな段階 (単体テストのコンパイル、単体テストの実行、統合テストのコンパイル、統合テストの実行) を明確に指定して分離できるため、これが最適なオプションです。これにより、ビルド履歴を理解し、発生する可能性のある障害を特定しやすくなります。さらに、個別のビルド ステップを使用すると、ビルド プロセスの各段階で異なるプロパティ (タイムアウト値や環境変数など) を指定できます。

D - Create a Cloud Build build config file with separate cloud builder steps to compile and execute unit and integration tests. This is the best option because it allows you to clearly specify and separate the different stages of the build process (compiling unit tests, executing unit tests, compiling integration tests, executing integration tests). This makes it easier to understand the build history and identify any failures that may occur. In addition, using separate build steps allows you to specify different properties (such as timeout values or environment variables) for each stage of the build process.

Dが正解です

D is correct

Dに投票

Vote D

https://cloud.google.com/build/docs/build-config-file-schema:
「ビルド ステップでは、Cloud Build に実行させたいアクションを指定します。ビルド ステップごとに、Cloud Build は Docker run のインスタンスとして Docker コンテナを実行します。ビルド ステップはスクリプト内のコマンドに似ており、ビルド内で任意の命令を実行する柔軟性を提供します。」

ここでは D が最も理にかなっています

https://cloud.google.com/build/docs/build-config-file-schema:
"A build step specifies an action that you want Cloud Build to perform. For each build step, Cloud Build executes a docker container as an instance of docker run. Build steps are analogous to commands in a script and provide you with the flexibility of executing arbitrary instructions in your build."

D makes the most sense here

Bが正解です

B is correct answer

B. Git タグ パターンでビルド トリガーを作成します。新しいリリースには Git タグ規則を使用します。

このアプローチは、自動化されながらも制御された方法でリリースを管理する場合に効果的です。特定の Git タグ パターンに基づいてアクティブ化される Cloud Build トリガーを作成すると、新しいリリースのビルドとデプロイのプロセスを自動化できます。 Git タグはリポジトリ内のリリース ポイントをマークするためによく使用されるため、これは一般的な開発慣行とよく一致します。

リポジトリ内でコミットが特定のパターン（「v1.0」、「release-*」など）でタグ付けされている場合、Cloud Build は自動的にビルドをトリガーし、場合によってはデプロイ プロセスをトリガーできます。これにより、master ブランチへのコミットごとにトリガーする場合と比較して、より慎重なリリース プロセスが可能になります。

B. Create a build trigger on a Git tag pattern. Use a Git tag convention for new releases.

This approach is effective for managing releases in an automated yet controlled manner. By creating a Cloud Build trigger that activates based on a specific Git tag pattern, you can automate the build and deployment process for new releases. Git tags are often used to mark release points in the repository, so this aligns well with common development practices.

When a commit is tagged in the repository with a specific pattern (e.g., "v1.0", "release-*"), Cloud Build can automatically trigger a build and potentially a deployment process. This allows for a more deliberate release process compared to triggering on every commit to the master branch.

B が正しいです。

B is correct.

B が正しいです

B is correct

なぜ人々が C を選択するのかわかりませんが、qus は master にコミットすると言っています。 C では文字通り、機能ブランチへのコミットがマスター ビルドをトリガーする仕組みが理解できません。

I don't know why people are selecting C , the qus says commit to master . C literally does not make sense how commit to a feature branch can trigger a master build.

Bに投票

Vote B

Cが正解だと思います

I think C correct answer

https://cloud.google.com/source-repositories/docs/integrating-with-cloud-build:
「特定のブランチに対して行われたコミット、または特定のタグを含むコミットでビルドを開始するトリガーを設定できます。」

qn にはコミットがブランチに対して行われると記載されているため、私は C を採用します。

https://cloud.google.com/source-repositories/docs/integrating-with-cloud-build:
"you can set a trigger to start a build on commits that are made to a particular branch, or on commits that contain a particular tag"

I would take C since the qn states that the commit is made to a branch

C. https://cloud.google.com/build/docs/automating-builds/create-manage-triggers にはブランチ パターンまたはタグ パターンのいずれかが含まれます

C. https://cloud.google.com/build/docs/automating-builds/create-manage-triggers has either branch pattern or tag pattern

また、B は正しいですが、質問ではタグではなく「ブランチ名」が指定されています

Also B is correct, but in the questions is specificied "branch name" , not tag

C。ダイジェストは不変ですが、docker タグは変更可能です (したがって D ではありません)。
https://cloud.google.com/architecture/using-container-images

C, since digests are immutable, whilst docker tags are mutable (hence not D).
https://cloud.google.com/architecture/using-container-images

私の場合は D です。最新のタグが付いた画像を使用するのはベストプラクティスではありません。また、セマンティック バージョンを使用すると、すべての環境で必要なコードを持つまったく同じイメージが使用されるようになります。

For me it's D, it's not a best practice to use image with the latest tag. And using the semantic version will ensure that all the environment use the exact same image with the wanted code.

最良の答えは C です。Docker イメージのダイジェストを使用します。

その理由は次のとおりです。

Docker イメージ ダイジェスト: ダイジェストは、特定の Docker イメージの一意の識別子です。これはイメージのコンテンツの暗号化ハッシュであり、環境間で常にまったく同じイメージを展開できるようにします。

The best answer is C. Use the digest of the Docker image.

Here's why:

Docker Image Digest: A digest is a unique identifier for a specific Docker image. It's a cryptographic hash of the image's contents, ensuring that you're always deploying the exact same image across environments.

C. Docker イメージのダイジェストを使用します。

CI/CD パイプライン内の異なる環境間で Docker イメージをプロモートする場合、まったく同じイメージが各環境にデプロイされていることを確認することが重要です。 Docker イメージを識別する最も信頼性の高い方法は、そのダイジェストを使用することです。

ダイジェストを使用することが最良のアプローチである理由は次のとおりです。

ダイジェストは、イメージのコンテンツと構成の SHA256 ハッシュであり、イメージを一意に識別します。画像に関する何かが変更されると、ダイジェストも変更されます。これは、イメージをダイジェストでデプロイすると、各環境にまったく同じイメージをデプロイすることが保証されることを意味します。

ダイジェストを使用すると、「最新」などのタグやセマンティック バージョン管理を使用するよりも信頼性が高くなります。タグは別の画像を指すように移動できますが、ダイジェストは不変です。イメージがレジストリにプッシュされると、そのダイジェストは変更できません。

C. Use the digest of the Docker image.

When promoting Docker images across different environments in a CI/CD pipeline, it's crucial to ensure that exactly the same image is deployed to each environment. The most reliable way to identify a Docker image is by using its digest.

Here's why using the digest is the best approach:

The digest is a SHA256 hash of the image's content and configuration, which uniquely identifies an image. If anything about the image changes, the digest changes. This means that if you deploy an image by its digest, you are guaranteed to deploy the exact same image in each environment.

Using the digest is more reliable than using tags like 'latest' or semantic versioning. Tags can be moved to point to different images, but digests are immutable. Once an image is pushed to a registry, its digest can never change.

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

I would go with C.

C. Docker イメージのダイジェストを使用します。

Docker イメージのダイジェストを使用することは、まったく同じ Docker イメージが各環境にデプロイされることを保証する最も信頼性の高い方法です。ダイジェストは、画像コンテンツとメタデータのハッシュであり、各画像に固有です。これは、イメージに異なるバージョンや名前がタグ付けされていても、コンテンツとメタデータが同一で​​ある限り、ダイジェストは同じままであることを意味します。

一方、最新の Docker イメージ タグまたはセマンティック バージョン タグを使用しても、まったく同じイメージが各環境にデプロイされるとは限りません。これらのタグは変更可能であり、上書きまたは更新される可能性があるため、異なるイメージが異なる環境にデプロイされる可能性があります。

一意の Docker イメージ名を使用することは機能しますが、特に環境が多い場合や更新が頻繁にある場合は、異なる名前を持つ複数のイメージを管理および追跡することがより困難になる可能性があります。

C. Use the digest of the Docker image.

Using the digest of the Docker image is the most reliable way to ensure that the exact same Docker image is deployed to each environment. The digest is a hash of the image content and metadata, which is unique to each image. This means that even if the image is tagged with different versions or names, the digest will remain the same as long as the content and metadata are identical.

On the other hand, using the latest Docker image tag or a semantic version tag may not guarantee that the exact same image is deployed to each environment. These tags are mutable and can be overwritten or updated, which could result in different images being deployed to different environments.

Using a unique Docker image name could work, but it may be more difficult to manage and track multiple images with different names, especially if there are many environments or frequent updates.

Anser C は、3 つの環境に対して同じイメージであることを確認する必要があるためです。タグのバージョンは、環境のデプロイメントの間に変更できます。

Anser C because nees to be sure that the same image for the 3 envs. A tag version can be change between the deployment of the env.

C. Docker イメージのダイジェストを使用します。

Docker イメージのダイジェストは、イメージの特定のバージョンの一意の識別子です。ダイジェストを使用すると、まったく同じバージョンのイメージが各環境に確実にデプロイされます。最新のタグまたは一意のイメージ名を使用しても、これらのタグは時間の経過とともに変更される可能性があるため、必ずしも同じバージョンが展開されるとは限りません。セマンティック バージョン タグを使用すると、厳密なバージョン管理ポリシーに従い、パッチまたはマイナー バージョン番号をインクリメントすることによってのみイメージを更新する場合にのみ、同じバージョンが確実にデプロイされます。

C. Use the digest of the Docker image.

The digest of the Docker image is a unique identifier for the specific version of the image. By using the digest, you can ensure that the same exact version of the image is deployed to each environment. Using the latest tag or a unique image name may not necessarily guarantee that the same version is deployed, as these tags may change over time. Using a semantic version tag would only ensure that the same version is deployed if you follow a strict versioning policy and only update the image by incrementing the patch or minor version number.

Cが答えです

C is the answer

Dが正解です

D is correct

C は 100% 正しいです

C is 100% correct

質問を読むと、「同じ」Docker イメージがすべての環境にデプロイされていることを確認するよう求められているため、Docker イメージを識別するにはダイジェストを使用する必要があります

Read the question, it asks to ensure that the 'same' Docker image is deployed to every environment, so to identify the docker image, we have to use digests

C が正解です。
別の答えは不変ではありません。

C is correct.
another answers are not immutable.

https://cloud.google.com/architecture/best-practices-for-building-containers#tagging_using_semantic_versioning

答えはDです

https://cloud.google.com/architecture/best-practices-for-building-containers#tagging_using_semantic_versioning

Answer is D

私にとっての正解はAです）

for me the correct answer is A)

青/緑の方が適切だと思われます(https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment)

Blue/green seems to be more appropriate(https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment)

ここでの最良の答えは A. ブルー/グリーン展開 です。その理由は次のとおりです。

ブルー/グリーン展開: この戦略には、「ブルー」環境 (現在の運用バージョン) と「グリーン」環境 (新しいバージョン) の 2 つの同一の環境を実行することが含まれます。トラフィックは最初は青色の環境にルーティングされます。グリーン環境が完全に展開されテストされると、トラフィックはグリーン環境に切り替えられます。これにより、新しいバージョンに問題がある場合に、青い環境に迅速にロールバックできます。

The best answer here is A. Blue/green deployment . Here's why:

Blue/Green Deployment: This strategy involves running two identical environments: a "blue" environment (the current production version) and a "green" environment (the new version). Traffic is initially routed to the blue environment. Once the green environment is fully deployed and tested, traffic is switched over to the green environment. This allows for a quick rollback to the blue environment if there are issues with the new version.

これは、Blue/Green アプローチを使用して実現できます。

This can be achieved by using Blue/Green approach.

申し訳ありませんが、A が正しいということです

Sorry I mean A is correct

B が正しいです

B is correct

A - 青緑が適切だと思われます。

A - Blue green seems appropriate.

コミュニティの選択は A: ブルー/グリーンです

Community choice is A: Blue/Green

これは qn 9 と同じです。答えはBです

This is the same as qn 9; answer is B

Cが正解です

C is correct

C が正解です。

C is correct.

Cが正解です

C is correct

Cに投票

Vote C

クラウドシェルが答えです

Cloud shell is the answer

ソース コードは公共の PC にローカルに保存すべきではないため、C が正解です。

C should be the correct answer because the source code should not be stores locally in the public pc.

D 「フル本番負荷」によるもの

D due to "full production load"

トラフィック ミラーリングを使用した A/B テスト: このアプローチにより、ライブ運用トラフィックの一部をアプリケーションの新しいバージョンと既存のバージョンの両方に同時に送信できます。これにより、実際の負荷を伴う現実的なテスト環境が提供され、両方のバージョンのパフォーマンス メトリックを並べて収集できるようになります。トラフィック ミラーリングにより、新しいバージョンが既存のバージョンと同じ条件でテストされ、より正確な比較が可能になります。

A/B Testing with Traffic Mirroring: This approach allows you to send a portion of your live production traffic to both the new and existing versions of your application simultaneously. This provides a realistic test environment with real-world load, allowing you to gather performance metrics for both versions side-by-side. Traffic mirroring ensures that the new version is tested under the same conditions as the existing version, providing a more accurate comparison.

Canary はトラフィックのごく一部のみをリダイレクトしますが、ミラーリングを使用した A/B は新しいバージョンを全負荷でテストします。

Canary will only redirect a small portion of the traffic, while A/B with mirroring will test the new version in full load

導入時のトラフィックミラーリングを使用した A/B テスト。この手法を使用すると、トラフィックの大部分を既存のバージョンに提供しながら、ライブ運用トラフィックの一部を新しいアプリケーション バージョンに迂回させることができます。実際の条件下で両方のバージョンのパフォーマンス メトリックを比較することで、アプリケーションのパフォーマンスと安定性に対する新しいデプロイメントの影響を評価できます。

A/B testing with traffic mirroring during deployment. This technique allows you to divert a portion of the live production traffic to the new application version while still serving the majority of the traffic to the existing version. By comparing the performance metrics of both versions under real-world conditions, you can assess the impact of the new deployment on your application’s performance and stability.

「起動前に、本番環境全体の負荷に対してテストする必要があります。」 Canary ではそれは不可能です。
「展開中のトラフィック ミラーリングを使用した A/B テスト」は、ロールアウト前にトラフィック全体をテストする必要がある唯一の可能性です。

"You need to test against the full production load prior to launch" It's impossible with canary.
"A/B testing with traffic mirroring during deployment" is the only one possibility we have to test the entire traffic before the roll out.

Dが正解です

D is correct

よく考えた結果、選択肢Dだと思います。
ここでのキーワードは「パフォーマンス指標の収集」です。誰もが知っているように、A/B テストの全体の目的はパフォーマンス指標を収集することです。

After giving a deliberate thought, I think it's option D.
The keyword here is 'gather performance metrics,' and as everyone must know A/B testing's whole purpose is to gather performance metrics.

正解は、選択したオプションにないため、シャドウ テスト パターンです D
https://cloud.google.com/architecture/application-deployment-and-testing-strategies#shadow_test_pattern

Correct Answer is Shadow test pattern, as it is not in the option selected D
https://cloud.google.com/architecture/application-deployment-and-testing-strategies#shadow_test_pattern

Dは私の答えです

D is my answer

Aに投票する

Vote A

完全な運用 - A/B テスト、オプション D

Full production - A/B testing, option D

Canary は本番環境でライブ本番トラフィックをテストできます (回答 A) https://cloud.google.com/architecture/application-deployment-and-testing-strategies#key_benefits_4

Canary can test live production traffic on production (Answer A) https://cloud.google.com/architecture/application-deployment-and-testing-strategies#key_benefits_4

正解はAです:

カナリア デプロイメントは、すべてのユーザーが利用できるようになる前に、一部のユーザーに変更をゆっくりと展開することで、実稼働環境にソフトウェア アップデートを導入するリスクを軽減する手法です。

この展開手法は、アプリケーション開発チームの SRE がルーターまたはロード バランサーに依存して個々のルートをターゲットにする手法です。彼らは、新しいバージョンのアプリケーションを使用するユーザー ベース全体の小さな断片をターゲットにしています。この新しいユーザー セットが使用されると、アプリケーションの重要なメトリクスが収集および分析され、新しい更新プログラムがすべてのユーザーにフルスケールでロールされるのに適しているかどうか、またはさらなるトラブルシューティングのためにロールバックする必要があるかどうかが判断されます。

Correct answer is A:

Canary deployment is a technique to reduce the risk of introducing a software update in production by slowly rolling out the change to a small subset of users before making it available to everybody.

This deployment technique is one where the SRE of an application development team relies on a router or load balancer to target individual routes. They target a small fragment of the overall user base with the newer version of the application. Once this new set of users are have used the application important metrics will be collected and analyzed to decide whether the new update is good for a full scale rolled to all the users or whether it needs to be rolled back for further troubleshooting.

ライブ トラフィックを使用して、新規アプリケーションと既存アプリケーションの両方のパフォーマンス メトリックを収集したい

you want to use live traffic to gather performance metrics for both new and existing applications

オプション A に同意する

Agree with Option A

私はAに投票します

I vote A

C. 引数を使用して、プロモーション ステップの前に、cloudbuild.yaml ファイルにビルド ステップを追加します。
-name: gcr.io/cloud-builders/gsutil
引数: ['cp','-r','gs://webphotos-staging','gs://webphotos-prod']
waitFor: ['-']

上記の引数を使用して、プロモーション ステップの前に、cloudbuild.yaml ファイルにビルド ステップを追加する必要があります。このビルド ステップでは、gsutil ツールを使用して、webphotos-staging バケットから webphotos-prod バケットに写真をコピーします。 -r フラグは、バケット内のすべてのファイルを再帰的にコピーするように gsutil に指示し、waitFor パラメータは、プロモーション ステップを続行する前にこのステップが完了するまで待機するように Cloud Build に指示します。

C.Add a build step in the cloudbuild.yaml file before the promotion step with the arguments:
-name: gcr.io/cloud-builders/gsutil
args: ['cp','-r','gs://webphotos-staging','gs://webphotos-prod']
waitFor: ['-']

You should add a build step in the cloudbuild.yaml file before the promotion step with the arguments shown above. This build step will use the gsutil tool to copy the photos from the webphotos-staging bucket to the webphotos-prod bucket. The -r flag tells gsutil to copy all files in the bucket recursively, and the waitFor parameter tells Cloud Build to wait for this step to complete before continuing with the promotion step.

Cが正解です

C is correct

選択肢 C に同意する

Agree with Option C

Cさんに同意

Agree with C

私はDに投票します
https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-using-serial-console

I vote D
https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-using-serial-console

ここでの最良のアプローチは D. シリアル ポートを使用して Compute Engine OS ログを確認し、Cloud Logging ログを確認してシリアル ポートへのアクセスを確認することです。

その理由は次のとおりです。

シリアル ポート ログ: Compute Engine インスタンスには、ブート メッセージやその他のシステムレベルの情報をキャプチャするシリアル ポートがあります。多くの場合、これはブート障害のトラブルシューティングを行う際に最も貴重な情報源となります。
Cloud Logging: プロジェクトでシリアル ポート ロギングを有効にしている場合、ブート メッセージがキャプチャされて Cloud Logging に送信されます。これにより、ログを確認するための集中的な場所が提供されます。

The best approach here is D. Check Compute Engine OS logs using the serial port and check the Cloud Logging logs to confirm access to the serial port.

Here's why:

Serial Port Logs: Compute Engine instances have a serial port that captures boot messages and other system-level information. This is often the most valuable source of information when troubleshooting boot failures.
Cloud Logging: If you've enabled serial port logging in your project, the boot messages will be captured and sent to Cloud Logging. This provides a centralized location for reviewing the logs.

D が答えです。他のものは長すぎます。

D is the answer - the other are too long.

答えはDです

Compute Engine イメージが起動しない場合、問題をトラブルシューティングするための最初のステップの 1 つは、OS ログをチェックして問題の原因を確認することです。 Compute Engine は、仮想マシンのシリアル コンソール ログへのアクセスを提供します。このログには、Cloud Console または gcloud コマンドライン ツールを通じてアクセスできます。これにより、仮想マシンのブート プロセスの出力を確認し、仮想マシンの起動を妨げている可能性のあるエラーや問題を特定できるようになります。

さらに、Cloud Logging のログをチェックして、シリアル ポートにアクセスできることを確認する必要もあります。ファイアウォール ルールまたは IAM 権限がシリアル ポートへのアクセスをブロックし、イメージが起動しない原因となっている可能性があります。したがって、アクセス ルールまたはファイアウォール ルールに関連するエラーがないかログを確認する必要があります。

OS ログと Cloud Logging ログを確認することで、あなたと CI/CD チームは問題の原因をより深く理解し、問題を修正するための措置を講じることができます。

Answer is D

If the Compute Engine image is not booting up, one of the first steps to troubleshoot the issue would be to check the OS logs to see what might be causing the problem. Compute Engine provides access to the serial console logs of a virtual machine, which can be accessed through the Cloud Console or the gcloud command-line tool. This will allow you to see the output of the virtual machine's boot process and identify any errors or issues that might be preventing it from starting up.

Additionally, you should also check the Cloud Logging logs to confirm that you have access to the serial port. It may be possible that the firewall rules or IAM permissions are blocking access to the serial port and causing the image not to boot. So, you should check the logs for any errors related to access or firewall rules.

By checking the OS logs and the Cloud Logging logs, you and the CI/CD team can get a better understanding of what might be causing the issue and take steps to fix it.

選択肢 D の「シリアル ポートへのアクセスを確認する」とはどういう意味ですか?
ブート ログを確認する必要がある場合、シリアル ポートへのアクセスを確認するとどうなるでしょうか?

In option D, what does it mean by "confirm access to the serial port"?
If I need to see the boot logs, then how the checking the access to serial port gonna help?

https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-using-serial-console#connecting_to_a_serial_console_with_a_login_prompt
答えD

https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-using-serial-console#connecting_to_a_serial_console_with_a_login_prompt
Answer D

Dが正解です

D is correct

Dの方が適している

D is more suitable

B が正しいです。

B is correct.

バグを特定するには、Cloud Build で次の手順を行う必要があります。」
1) 静的コード解析
2) コードの脆弱性スキャン
3) Docker イメージの脆弱性スキャン
Grype の使用はその一例です。

We need to have the following steps in Cloud Build to identify bugs"
1) Static code analysis
2) Code Vulnerability scanning
3) Docker Image vulnerability scanning
Using Grype is one such example.

Dと言います。

B と D の両方が機能する可能性があります。ただし、従来の git ワークフローを使用して、個別のタスク用に個別のブランチを保持しないのはなぜでしょうか。このようにして、各イメージを個別にテストできます。

I say D.

Both B and D could work. However why not use traditional git workflows and keep separate branches for separate tasks. This way each image can be tested independently.

オプション B は、Git タグに基づいて Cloud Source Repositories に保存されたコードからコンテナ イメージを自動的に構築できるサービスである Cloud Build を使用するため、適切です。これにより、開発者は、構築プロセスを自動化し、開発者のフィードバックを改善することにより、コードを運用環境にデプロイする前に、コード内のバグを迅速に特定できるようになります。

オプション A では、コンテナ イメージの構築、テスト、デプロイを自動化できるマルチクラウドの継続的配信プラットフォームである Spinnaker を使用します。ただし、git タグを使用してビルドをトリガーすることについては特に言及されていないため、この特定の使用例には最適ではない可能性があります。

Option B is appropriate because it uses Cloud Build, a service that can automatically build container images from code stored in Cloud Source Repositories based on Git tags. This allows developers to quickly identify bugs in their code before it is deployed to production, by automating the building process and improving developer feedback.

Option A uses Spinnaker, which is a multi-cloud continuous delivery platform that can automate building, testing, and deploying container images. However, it does not specifically mention using git tags to trigger builds, thus for this particular use case it might not be the best fit.

D ) コードを実稼働環境にデプロイする前に、コード内のバグを迅速に特定する必要があります。したがって、コードをフォークしてビルドをテストするのは開発者です。後で、PR を使用して変更をマスター リポジトリ/ブランチにプッシュできます。

D ) You need to quickly identify bugs in the code before it is deployed to production. So it's for developer to fork the code and test the build. Later they can push the changes using PR to the master repo/branch.

bが正しいと思います

I think b is correct

私は D に投票します。マスターにマージする前にすべての開発者は自分のブランチでビルドをテストする必要があるからです。それはバグを暴露するでしょう。ブランチがマスターにマージされると、マスター ビルド パイプラインが起動します。

I vote D. Because every developer before merge to the master should test build in his branch. It will expose bugs. Once branch merged to the master, master build pipeline comes up.