Q1. あなたの組織は、将来の分析や法的手続きの可能性に備えて、すべてのアプリケーションのメトリクスを5年間保持することを求めています。
どのアプローチを使用すべきですか。
A. 各プロジェクトのログへのアクセス権をセキュリティチームに付与する。
B. すべてのプロジェクトでStackdriver Monitoring（現Cloud Monitoring）を構成し、BigQueryへエクスポートする。
C. すべてのプロジェクトでStackdriver Monitoring（現Cloud Monitoring）をデフォルトの保持ポリシーで構成する。
D. すべてのプロジェクトでStackdriver Monitoring（現Cloud Monitoring）を構成し、Google Cloud Storageへエクスポートする。
回答
- D
-
正解はDです。
5年間という長期アーカイブ目的には、低コストで耐久性の高いGoogle Cloud Storageが最適です。
Cloud Monitoring（旧Stackdriver Monitoring）のメトリクスをCloud Storageへエクスポートすることで、長期保存の要件を満たせます。
デフォルトの保持ポリシー（C）ではメトリクスは数週間程度しか保持されず、5年要件を満たしません。
BigQuery（B）は分析用データウェアハウスであり、必要に応じてCloud Storageからデータを取り込めますが、長期アーカイブの第一選択ではありません。
ログへのアクセス権付与（A）は保持期間の問題自体を解決しません。
Cloud Storage のストレージクラス | Google Cloud
Q2. あなたの会社は、オンプレミスのユーザー認証用PostgreSQLデータベースのバックアップレプリカをGoogle Cloud Platform上に構築することを決定しました。
データベースは4TBで、大規模な更新が頻繁に発生します。
レプリケーションにはプライベートアドレス空間での通信が必要です。
どのネットワーキングのアプローチを使用すべきですか。
A. Google Cloud Dedicated Interconnect
B. データセンターネットワークに接続したGoogle Cloud VPN
C. オンプレミスに設置したNATおよびTLS変換ゲートウェイ
D. データセンターネットワークに接続した、VPNサーバーをインストール済みのGoogle Compute Engineインスタンス
回答
- A
-
正解はAです。
Dedicated Interconnectは、オンプレミスとGoogleネットワーク間を専用の物理接続で結び、RFC 1918のプライベートIPアドレスによる通信を可能にします。
4TBという大容量かつ頻繁な大規模更新を扱うには、高帯域で安定した専用接続が適しています。
Cloud VPN（B）はインターネット経由のため帯域に上限があり、大容量・高頻度の更新には不向きです。
NAT/TLSゲートウェイ（C）やVPNサーバー付きインスタンス（D）は、プライベートアドレス空間での効率的な大容量通信という要件に十分には応えられません。
Dedicated Interconnect の概要 | Google Cloud
Q3. あなたの会社は、ローカルデータセンターで実行されるApache SparkおよびHadoopジョブの数と規模が急増すると予測しています。
運用作業とコード変更を最小限に抑えつつ、クラウドを活用してこの今後の需要に対応したいと考えています。
どの製品を使用すべきですか。
A. Google Cloud Dataflow
B. Google Cloud Dataproc
C. Google Compute Engine
D. Google Container Engine（現Google Kubernetes Engine）
回答
- B
-
正解はBです。
DataprocはマネージドなSpark／Hadoopサービスであり、既存のジョブをほぼ変更せずに移行でき、運用負荷も最小限に抑えられます。
クラスタの作成・スケール・停止が容易で、需要の急増に柔軟に対応できます。
Dataflow（A）はApache Beamを用いるストリーム／バッチ処理サービスで、既存のSpark／Hadoopコードをそのまま動かす用途には適しません。
Compute Engine（C）では自前でクラスタを構築・管理する必要があり運用負荷が大きく、Container Engine（D）はコンテナオーケストレーション用でSpark／Hadoopの直接移行先ではありません。
Dataproc の概要 | Google Cloud
Q4. あなたの会社のテストスイートは、Linux仮想マシン上で毎日終日テストを実行するカスタムC++アプリケーションです。
テストスイート全体の完了には数時間を要し、テスト用に確保された限られた数のオンプレミスサーバー上で実行されています。
会社は、テストの変更を可能な限り少なくしながら、システムへの変更を完全にテストするのに要する時間を短縮するため、テスト基盤をクラウドへ移行したいと考えています。
どのクラウド基盤を推奨すべきですか。
A. Google Compute Engineの非マネージドインスタンスグループとNetwork Load Balancer
B. 自動スケーリングを有効にしたGoogle Compute Engineのマネージドインスタンスグループ
C. 各テストを処理するためApache HadoopジョブをGoogle Cloud Dataprocで実行する
D. ロギングにGoogle Stackdriverを用いるGoogle App Engine
回答
- B
-
正解はBです。
マネージドインスタンスグループと自動スケーリングを使えば、既存のC++テストをほぼ変更せずに多数のVMへ並列展開でき、テスト時間を大幅に短縮できます。
テストはLinux VM上で動くため、同じ環境のVMを必要なだけ増やすこのアプローチが最も移行コストの低い選択です。
非マネージドグループとロードバランサ（A）は自動スケーリングや自己修復に乏しく適しません。
Dataproc（C）はSpark／Hadoop向けで、C++テストをHadoopジョブに書き換える必要が生じます。
App Engine（D）はアプリ実行基盤であり、既存のC++テストをそのまま動かす用途には適しません。
マネージド インスタンス グループの自動スケーリング | Google Cloud
Q5. あなたの会社は、コンピューティング需要に対応するためGoogle Compute Engineへの迅速なリフト&シフトを終えたばかりです。
より「クラウドネイティブ」なソリューションを設計・展開するための期間が、あと9か月あります。
具体的には、運用作業が不要（no-ops）で自動スケーリングするシステムを求めています。
どの2つのコンピューティング製品を選ぶべきですか。
回答を2つ選んでください。
A. コンテナを用いるCompute Engine
B. コンテナを用いるGoogle Container Engine（現Google Kubernetes Engine）
C. Google App Engine スタンダード環境
D. カスタムインスタンスタイプを用いるCompute Engine
E. マネージドインスタンスグループを用いるCompute Engine
回答
- B、C
-
正解はBとCです。
no-opsで自動スケーリングという要件には、フルマネージドなApp Engine スタンダード環境（C）と、コンテナを自動スケール・自己修復で運用できるGoogle Kubernetes Engine（B）が適合します。
App Engine スタンダードはインフラ管理が不要で、トラフィックに応じて自動的にスケールします。
GKEはノードやPodの自動スケーリングを備え、マネージドな運用が可能です。
Compute Engineベースの選択肢（A・D・E）は、いずれもVMの管理が残るため完全なno-opsとは言えず要件を満たしません。
App Engine スタンダード環境 | Google Cloud
Q6. ある開発マネージャーが新しいアプリケーションを構築しています。
彼はあなたに要件をレビューし、それらを満たすために使用できるクラウド技術を特定するよう依頼しました。
そのアプリケーションは次を満たす必要があります。
1. クラウドポータビリティのためオープンソース技術をベースとすること。
2. 需要に応じてコンピューティング容量を動的にスケールすること。
3. 継続的なソフトウェアデリバリーをサポートすること。
4. 同一のアプリケーションスタックを複数、分離された形で実行すること。
5. 動的なテンプレートを用いてアプリケーションバンドルをデプロイすること。
6. URLに基づいて特定のサービスへネットワークトラフィックをルーティングすること。
これらすべての要件を満たす技術の組み合わせはどれですか。
A. Google Container Engine（現Google Kubernetes Engine）、Jenkins、Helm
B. Google Container EngineとCloud Load Balancing
C. Google Compute EngineとCloud Deployment Manager
D. Google Compute Engine、Jenkins、Cloud Load Balancing
回答
- A
-
正解はAです。
Google Kubernetes Engine、Jenkins、Helmの組み合わせは、6つの要件すべてを満たします。
GKEはオープンソースのKubernetesをベースとし（要件1）、Podの動的スケーリング（要件2）、Namespaceによる同一スタックの分離実行（要件4）、IngressによるURLベースのルーティング（要件6）を提供します。
JenkinsがCI/CDによる継続的デリバリー（要件3）を担い、Helmが動的テンプレートによるアプリケーションバンドルのデプロイ（要件5）を実現します。
BやDはCD（Jenkins）やHelmのテンプレート機能が欠け、CはGCE中心でオープンソースのポータビリティやURLルーティングを十分に満たしません。
Google Kubernetes Engine の概要 | Google Cloud
Q7. あなたのマーケティング部門は、販促用のメールキャンペーンを送信したいと考えています。
開発チームは直接的な運用管理を最小限に抑えたいと考えています。
彼らは、1日あたり100件から500,000件のクリックスルーまで、幅広い顧客の反応を見込んでいます。
リンク先は、販促内容を説明し、ユーザー情報や好みを収集する単純なウェブサイトです。
どの基盤を推奨すべきですか。
回答を2つ選んでください。
A. ウェブサイトの配信にGoogle App Engineを、ユーザーデータの保存にGoogle Cloud Datastoreを使用する。
B. ウェブサイトの配信にGoogle Container Engineクラスタを使用し、データを永続ディスクに保存する。
C. ウェブサイトの配信にマネージドインスタンスグループを使用し、ユーザーデータの保存にGoogle Cloud Bigtableを使用する。
D. ウェブサーバーをホストするために単一のCompute Engine仮想マシン（VM）を使用し、バックエンドにGoogle Cloud SQLを用いる。
回答
- A、C
-
正解はAとCです。
1日100件から50万件まで大きく変動するトラフィックを、運用管理を最小化しながら吸収できる構成が求められます。
App EngineとDatastore（A）はフルマネージドで、需要に応じて自動的にスケールするため運用負荷が小さく最適です。
マネージドインスタンスグループとBigtable（C）も自動スケーリングと高いスループットを備え、急増するアクセスに対応できます。
単一VM＋Cloud SQL（D）はスケールできず50万件に耐えられません。
Container Engine＋永続ディスク（B）は永続ディスクが水平スケールやマネージドなデータ保存に向かず、要件に合いません。
App Engine ドキュメント | Google Cloud
Q8. あなたの主要なビジネス目標の一つは、アプリケーションに保存されたデータを信頼できることです。
あなたはアプリケーションデータへのすべての変更をログに記録したいと考えています。
ログの真正性を検証できるよう、ロギングシステムをどのように設計できますか。
A. ログをクラウドとオンプレミスの両方に同時に書き込む。
B. SQLデータベースを使用し、ログテーブルを変更できる人を制限する。
C. 各タイムスタンプとログエントリにデジタル署名を行い、その署名を保存する。
D. 各ログエントリのJSONダンプを作成し、Google Cloud Storageに保存する。
回答
- C
-
正解はCです。
各ログエントリとタイムスタンプにデジタル署名を施し署名を保存すれば、後からの改ざんを検知でき、ログの真正性（authenticity）を暗号学的に検証できます。
署名はエントリ内容に基づくため、内容が変われば署名検証が失敗し、改ざんが明らかになります。
二重書き込み（A）は冗長性を高めますが真正性そのものは保証しません。
テーブルの更新権限制限（B）はアクセス制御に留まり、改ざんの暗号的検証にはなりません。
JSONダンプの保存（D）も保管手段にすぎず、内容が正当であることを証明できません。
Cloud Audit Logs の概要 | Google Cloud
Q9. あなたはGoogle Compute Engineを使って、いくつかのプリエンプティブ（preemptible）なLinux仮想マシンインスタンスを作成しました。
仮想マシンがプリエンプト（preempt：強制停止）される前に、アプリケーションを適切にシャットダウンしたいと考えています。
何をすべきですか。
A. /etc/rc.6.d/ ディレクトリに k99.shutdown という名前のシャットダウンスクリプトを作成する。
B. Linuxのxinetdサービスとして登録したシャットダウンスクリプトを作成し、そのサービスを呼び出すStackdriverのエンドポイントチェックを構成する。
C. シャットダウンスクリプトを作成し、新しい仮想マシンインスタンスを作成する際に、Cloud Platform Consoleでキー shutdown-script を持つ新しいメタデータエントリの値として設定する。
D. シャットダウンスクリプトを作成してLinuxのxinetdサービスとして登録し、gcloud compute instances add-metadata コマンドで、キー shutdown-script-url を持つ新しいメタデータエントリの値としてサービスURLを指定する。
回答
- C
-
正解はCです。
Compute Engineでは、メタデータのキー shutdown-script にスクリプト本文を設定することで、プリエンプト時に自動実行されるシャットダウン処理を構成できます。
プリエンプト時はACPI G2シグナルでスクリプトが起動し、ベストエフォートで最大30秒の猶予内にクリーンアップを実行できます。
rc6.dへの配置（A）はメタデータ経由のGCE標準の仕組みではなく、確実に呼び出される保証がありません。
xinetdとStackdriverチェック（B）は本来の用途と異なり過剰かつ不確実です。
shutdown-script-url（D）はGCSのスクリプトを参照する正規の方法ですが、xinetd登録という前提が不適切で、本問の最適解はCです。
シャットダウン スクリプトの実行 | Compute Engine | Google Cloud
Q10. あなたの会社は、低リスクでクラウドを試したいと考えています。
約100TBのログデータをクラウドにアーカイブし、そこで利用できる分析機能をテストすると同時に、そのデータを長期的なディザスタリカバリ用バックアップとしても保持したいと考えています。
どの2つのステップを取るべきですか。
回答を2つ選んでください。
A. ログをGoogle BigQueryにロードする。
B. ログをGoogle Cloud SQLにロードする。
C. ログをGoogle Stackdriverにインポートする。
D. ログをGoogle Cloud Bigtableに挿入する。
E. ログファイルをGoogle Cloud Storageにアップロードする。
回答
- A、E
-
正解はAとEです。
長期のディザスタリカバリ用アーカイブにはCloud Storage（E）が、分析機能のテストにはBigQuery（A）が最適です。
Cloud Storageは100TB規模のデータを低コストかつ高耐久で長期保管でき、DRバックアップの要件を満たします。
BigQueryはサーバーレスのデータウェアハウスで、ログに対してSQL分析を手軽に試せます。
Cloud SQL（B）はリレーショナルDBで大規模ログのアーカイブや分析に不向きです。
Stackdriver（C）は監視・ロギング製品で100TBの長期保管先ではなく、Bigtable（D）はアーカイブやアドホック分析の用途には適しません。
Cloud Storage からのデータ読み込み | BigQuery | Google Cloud