ACE#02

ACE#01 – ACE#02 – ACE#03
R – F

お疲れ様でした!ACE#02のクイズ終了しました。

解答スコアは %%SCORE%% / %%TOTAL%% 問正解です。

%%RATING%%


あなたの選択した答えは強調表示されています。
問題1
Google App Engine で本番トラフィックに対応したアプリケーションを運用しています。リスクはあるが必要な変更をアプリケーションに加えたいと考えています。適切にコーディングされていなければ、サービスが停止する可能性があります。アプリケーションの開発中に、その機能を適切にテストするには、ユーザーのライブトラフィックが必要であることに気付きました。どのようにその機能をテストすればよいですか。
A
新しいアプリケーションのバージョンを一時的にデプロイし、その後ロールバックします。
B
2 番目の Google App Engine サービスをセットアップしてから、クライアントのサブセットを更新して新しいサービスを利用します。
C
新しいアプリケーションを分離した 2 番目のプロジェクトを作成し、ユーザーを登録します。
D
新しいバージョンのアプリケーションをデプロイし、トラフィック分割を使用して、ごく一部のトラフィックをアプリケーションに送信します。
問題 1 の説明および補足 
トラフィック分割
トラフィック分割を行うと、指定したパーセンテージでトラフィックをアプリケーションのバージョンに分散します。トラフィック分割により、トラフィックの 100% を 1 つのバージョンに移行したり、指定した割合のトラフィックを複数のバージョンにルーティングしたりできます。トラフィックを 2 つ以上のバージョンに分割すると、バージョン間で A/B テストを実施して、機能をロールアウトする際のペースを制御できます。
参考URL:Admin API でトラフィックの移行と分割

■以下は間違いです。
・2 番目の Google App Engine サービスをセットアップしてから、クライアントのサブセットを更新して新しいサービスを利用します。
→App Engine サービスはさまざまなサービスロジックをホストすることを目的としているため間違いです。さまざまなサービスを使用するには、サービスのコンシューマを手動で設定して、デプロイのプロセスを認識し、誰がどのサービスにアクセスしているかをコンシューマ側で管理する必要があります。
参考URL:App Engine

・新しいアプリケーションを分離した 2 番目のプロジェクトを作成し、ユーザーを登録します。
→2 番目のプロジェクトをデプロイする際に、データの同期や、トラフィックを新しいアプリケーションに転送するための外部のトラフィック分割ソリューションが必要になるため間違いです。これは可能ですが、Google App Engine では、このような手動の手順は必要ありません。

・新しいアプリケーションのバージョンを一時的にデプロイし、その後ロールバックします。
→アプリケーションのバージョンをデフォルトでデプロイすると、すべてのトラフィックを新しいバージョンに移動する必要があるため間違いです。これにより、すべてのユーザーに影響が及び、サービスが停止する可能性があります。
問題2
あなたは、チームの App Engine アプリケーションをデプロイしようとしています。スタンダード環境で Go ランタイムを使用しています。どのコマンドを使用してアプリケーションをデプロイしますか?
A
gcloud app-engine deploy app.yaml
B
gcloud app-engine apply app.yaml
C
gcloud app deploy app.yaml
D
gcloud app apply app.yaml
問題 2 の説明および補足 
gcloud app deploy
gcloud app deploy は、アプリのローカルコードや構成を App Engine にデプロイする機能を提供します。

※gcloud app deploy
このコマンドは、コードと構成の両方を App Engine サーバーにデプロイするために使用します。アップロードされる 1 つ以上の DEPLOYABLES を入力として受け取ります。DEPLOYABLE には、サービスの .yaml ファイルやコンフィグレーションの .yaml ファイルを指定できます。
参考URL:gcloud app deploy

■以下は間違いです。
・gcloud app-engine apply app.yaml
・gcloud app-engine deploy app.yaml
→gcloud app-engine は有効なコマンドではないため間違いです。

・gcloud app apply app.yaml
→gcloud app apply は有効なコマンドではないため間違いです。
問題3
あなたの会社は、タイムスタンプ付きの大量の IoT データを処理しています。データの総量は数ペタバイトにもなります。データは高速で書き込まれ、変更される必要があります。データには、最もパフォーマンスの高いストレージオプションを使用する必要があります。どのプロダクトを使用する必要がありますか?
A
Cloud Storage
B
BigQuery
C
Cloud Datastore
D
Cloud Bigtable
問題 3 の説明および補足 
Cloud Bigtable
Cloud Bigtable は IoT および時系列データを処理するための最もパフォーマンスの高いストレージオプションです。Google Cloud Bigtable は、高速で完全に管理された、拡張性の高い NoSQL データベースサービスです。1 TB から数百 PB までのデータの収集と保持のために設計されています。
参考URL:Cloud Bigtable
参考URL:時系列データ用のスキーマ設計

■以下は間違いです。
・BigQuery
→BigQuery はスケーラブルで完全に管理されたエンタープライズデータウェアハウスソリューションであり、変化の激しいデータには適していないため間違いです。
参考URL:BigQuery

・Cloud Storage
→Cloud Storage はオブジェクトストレージ用に設計されており、この種のデータの取り込みや収集には適していないため間違いです。
参考URL:Cloud Storage とは

・Cloud Datastore
→Cloud Datastore は、頻繁な書き込みやタイムスタンプベースのクエリに対して最もパフォーマンスの高いプロダクトではないため間違いです。

※Datastore
Datastore は、ウェブアプリとモバイルアプリのためのスケーラビリティが高い NoSQL データベースです。
参考URL:Datastore
問題4
運用チームの公開 SSH 鍵のみをすべて、特定のプロジェクトの特定の踏み台ホストインスタンスに取得する必要があります。現在、プロジェクト全体のアクセスは、プロジェクト内のすべてのインスタンスにすでに許可されています。できるだけ少ない手順で、踏み台ホストのプロジェクトレベルのアクセスをブロックまたはオーバーライドする方法を選択してください。
A
gcloud compute instances add-metadata [INSTANCE_NAME] --metadata block-project-ssh-keys=FALSE コマンドを使用して、アクセスをブロックします。
B
プロジェクト全体の SSH アクセスは、上書きまたはブロックできないため、削除する必要があります。
C
gcloud compute instances add-metadata [INSTANCE_NAME] --metadata block-project-ssh-keys=TRUE コマンドを使用して、アクセスをブロックします。
D
gcloud compute project-info add-metadata [INSTANCE_NAME] --metadata block-project-ssh-keys=FALSE コマンドを使用して、アクセスをブロックします。
問題 4 の説明および補足 
Linux インスタンスによるプロジェクト全体の公開 SSH 認証鍵の使用を許可またはブロックする
--metadata block-project-ssh-keys=TRUE を使用して、プロジェクト全体の SSH アクセスをブロックすることができます。

※Linux インスタンスによるプロジェクト全体の公開 SSH 認証鍵の使用を許可またはブロックする
インスタンスでプロジェクト全体の公開 SSH 認証鍵を無視し、インスタンス レベルの認証鍵のみを使用する必要がある場合、インスタンスからプロジェクト全体の公開 SSH 認証鍵をブロックできます。これにより、インスタンス レベルのメタデータに公開 SSH 認証鍵が格納されているユーザーのみがインスタンスにアクセスできるようになります。インスタンスがプロジェクト全体とインスタンス レベルの両方の公開 SSH 認証鍵を使用できるようにする場合は、プロジェクト全体の SSH 認証鍵を許可するようにインスタンスのメタデータを設定します。これにより、プロジェクト全体またはインスタンス レベルのメタデータに公開 SSH 認証鍵が格納されているユーザーがすべてインスタンスにアクセスできるようになります。
参考URL:Linux インスタンスによるプロジェクト全体の公開 SSH 認証鍵の使用を許可またはブロックする

■以下は間違いです。
・プロジェクト全体の SSH アクセスは、上書きまたはブロックできないため、削除する必要があります。
→プロジェクト全体の SSH 鍵のアクセスがブロックされる可能性があるため間違いです。

・gcloud compute project-info add-metadata [INSTANCE_NAME] --metadata block-project-ssh-keys=FALSE コマンドを使用して、アクセスをブロックします。
→コマンドをインスタンスレベルで実行する必要があるため間違いです。

・gcloud compute instances add-metadata [INSTANCE_NAME] --metadata block-project-ssh-keys=FALSE コマンドを使用して、アクセスをブロックします。
→--metadata block-project-ssh-keys パラメータを TRUE に設定する必要があるため間違いです。
問題5
App Engine アプリケーションでは、ステートフルなデータを適切なストレージサービスに保存する必要があります。データは非リレーショナルデータベースデータです。データベースのサイズが 10 GB 以上になることは想定しておらず、不要なコストを回避するためにゼロまでスケールダウンできる機能が必要です。どのストレージサービスを使用する必要がありますか?
A
Cloud Datastore
B
Cloud Dataproc
C
Cloud SQL
D
Cloud Bigtable
問題 5 の説明および補足 
Cloud Datastore
Datastore は、ウェブアプリとモバイルアプリのためのスケーラビリティが高い NoSQL データベースです。
参考URL:Cloud Datastore

※Cloud SQL
MySQL、PostgreSQL、SQL Server 向けのフルマネージド リレーショナル データベース サービスです。
参考URL:Cloud SQL

※Cloud Bigtable
最大 99.999% の可用性を誇る大規模分析ワークロードや運用ワークロード向けの、フルマネージドのスケーラブルな NoSQL データベース サービスです。
参考URL:Cloud Bigtable

※Cloud Dataproc
Dataproc は、オープンソースのデータツールを利用してバッチ処理、クエリ実行、ストリーミング、機械学習を行えるマネージド Spark / Hadoop サービスです。
参考URL:Cloud Dataproc
問題6
アプリケーションを Compute Engine インスタンスにデプロイし、Cloud Storage や Bigtable から読み取るための呼び出しを行う必要があります。その際、最小特権の原則に従っていることを確認する必要があります。コードが必要な Google Cloud API を認証できるようにする最も簡単な方法は何ですか?
A
アプリケーションを Binary Registration Service に登録し、必要なロールを適用します。
B
必要な限定された権限で新しいサービス アカウントとキーを作成します。新しいサービス アカウントを使用するようにインスタンスを設定します。サービス アカウントキーを使用するようにコードを編集します。
C
デフォルトの Compute Engine のサービス アカウントを使用し、そのスコープを設定します。「アプリケーションのデフォルトの認証情報」を使用して、コードにデフォルトのサービス アカウントを見つけさせます。
D
必要なロールを持つ新しいユーザーアカウントを作成します。認証情報を Cloud Key Management Service に保存し、コードでインスタンスにダウンロードします。
問題 6 の説明および補足 
サービス アカウントについて
ベストプラクティスは、サービス アカウントを使用してアプリケーションに必要なアクセスを許可することであるため、必要な限定された権限で新しいサービス アカウントとキーを作成します。新しいサービス アカウントを使用するようにインスタンスを設定します。サービス アカウントキーを使用するようにコードを編集します。

※サービス アカウントについて
サービス アカウントは特別なタイプの Google アカウントで、Google API のデータにアクセスして認証を受ける必要がある人間以外のユーザーを表します。

通常、サービス アカウントは次のような場合に使用されます。
・仮想マシン (VM) でのワークロードの実行。
・Google API を呼び出すオンプレミスのワークステーションまたはデータセンターでのワークロードの実行。
・1 人のユーザーのライフサイクルに結び付けられていないワークロードの実行。
参考URL:サービス アカウントについて

■以下は間違いです。
・アプリケーションを Binary Registration Service に登録し、必要なロールを適用します。
→デプロイ時のセキュリティ管理サービスのため間違いです。
参考URL:Binary Authorization

・デフォルトの Compute Engine のサービス アカウントを使用し、そのスコープを設定します。「アプリケーションのデフォルトの認証情報」を使用して、コードにデフォルトのサービス アカウントを見つけさせます。
→デフォルトのサービス アカウントには必要な権限がないため間違いです。

・必要なロールを持つ新しいユーザーアカウントを作成します。認証情報を Cloud Key Management Service に保存し、コードでインスタンスにダウンロードします。
→推奨される方法ではないため間違いです。
参考URL:Cloud Key Management Service
問題7
一連のバッチ処理ジョブのために、コンピュートリソースを選択して設定する必要があります。これらのジョブは約 2 時間で完了し、毎晩実行されます。サービスのコストを最小限に抑えたいと考えています。どのように対応しますか。
A
Google Kubernetes Engine を選択します。マイクロインスタンス タイプの 3 ノードクラスタを使用します。
B
Compute Engine を選択します。短時間のバーストをサポートする VM インスタンス タイプを使用します。
C
Google Kubernetes Engine を選択します。インスタンス タイプが小さい単一ノードクラスタを使用します。
D
Compute Engine を選択します。適切な標準マシンタイプのプリエンプティブル VM インスタンスを使用します。
問題 7 の説明および補足 
プリエンプティブル VM インスタンス
Compute Engine プリエンプティブル VM は、バッチ処理ジョブに最適であり、標準インスタンスよりもはるかに低価格で実行できるため正解です。

※プリエンプティブル VM インスタンス
プリエンプティブル VM は、通常のインスタンスよりはるかに低価格で作成、実行できるインスタンスです。ただし、他のタスクがリソースへのアクセスを必要とする場合、Compute Engine がこのインスタンスを停止(プリエンプト)する可能性があります。プリエンプティブル インスタンスは Compute Engine の余剰のキャパシティを利用する機能であり、使用できるかどうかは利用状況に応じて異なります。
アプリがフォールト トレラントであり、インスタンスで生じる可能性のあるプリエンプションに対応できる場合、プリエンプティブル インスタンスで Compute Engine のコストを大幅に削減できます。たとえば、バッチ処理ジョブは、プリエンプティブル インスタンス上で実行できます。これらのインスタンスのいくつかが処理中に停止する場合、ジョブは遅くなりますが、完全に停止することはありません。プリエンプティブル インスタンスは、既存のインスタンスの負荷を増やさずにバッチ処理タスクを完了し、通常インスタンスの追加に対する正規価格を支払う必要もありません。
参考URL:プリエンプティブル VM インスタンス

■以下は間違いです。
他の選択肢は、Compute Engine インスタンスが実行されているため間違いです。バッチ処理ジョブの費用対効果の高いオプションではありません。
参考URL:Compute Engine インスタンス
お疲れさまでした。 クイズが完了したら、「クイズの結果を見る」ボタンをクリックしてください。あなたが完了していないアイテムは、間違いのマークがされます。 クイズの結果を見る
問題は全部で 7 問。全て答えられるように頑張りましょう!
リスト
戻る
網掛け部分は完了した項目です。
12345
67ゴール
戻る
error: コンテンツの複製・転用は禁止されております。