表示モード
画像位置
文字位置
理解度の自動記録
Q1Google Professional Cloud Architect
Q1. あなたの組織では、将来の分析対応や法的な照会に備え、全アプリケーションのメトリクスを5年間保持しておく方針を定めています。
どのアプローチを採用すべきですか。
解答を見る
正解：D. 全プロジェクトでStackdriver Monitoring（現Cloud Monitoring）を有効にし、収集したメトリクスをGoogle Cloud Storageへエクスポートする。
正解はDです。5年間という長期アーカイブ目的には、低コストで耐久性の高いGoogle Cloud Storageが最適です。
Cloud Monitoring（旧Stackdriver Monitoring）のメトリクスをCloud Storageへエクスポートすることで、長期保存の要件を満たせます。
デフォルトの保持ポリシー（C）ではメトリクスは数週間程度しか保持されず、5年要件を満たしません。
BigQuery（B）は分析用データウェアハウスであり、必要に応じてCloud Storageからデータを取り込めますが、長期アーカイブの第一選択ではありません。
ログへのアクセス権付与（A）は保持期間の問題自体を解決しません。
Cloud Storage のストレージクラス | Google Cloud
Q2Google Professional Cloud Architect
Q2. ある企業が、オンプレミス環境で稼働するユーザー認証用PostgreSQLデータベースのバックアップレプリカを、Google Cloud Platform上に構築する方針を決めました。
データベースの容量は4TBあり、大規模な更新が高頻度で発生します。
レプリケーション通信はプライベートアドレス空間内で行う必要があります。
どのネットワーキング方式を採用すべきですか。
解答を見る
正解：A. Google Cloud Dedicated Interconnect
正解はAです。Dedicated Interconnectは、オンプレミスとGoogleネットワーク間を専用の物理接続で結び、RFC 1918のプライベートIPアドレスによる通信を可能にします。
4TBという大容量かつ頻繁な大規模更新を扱うには、高帯域で安定した専用接続が適しています。
Cloud VPN（B）はインターネット経由のため帯域に上限があり、大容量・高頻度の更新には不向きです。
NAT/TLSゲートウェイ（C）やVPNサーバー付きインスタンス（D）は、プライベートアドレス空間での効率的な大容量通信という要件に十分には応えられません。
Dedicated Interconnect の概要 | Google Cloud
Q3Google Professional Cloud Architect
Q3. ある企業では、自社データセンターで稼働させているApache SparkおよびHadoopジョブの件数と規模が今後急激に増えると見込んでいます。
運用の手間とコードの改修を極力抑えながら、クラウドを活用してこの需要増に対応したいと考えています。
どの製品を選択すべきですか。
解答を見る
正解：B. Google Cloud Dataproc
正解はBです。DataprocはマネージドなSpark／Hadoopサービスであり、既存のジョブをほぼ変更せずに移行でき、運用負荷も最小限に抑えられます。
クラスタの作成・スケール・停止が容易で、需要の急増に柔軟に対応できます。
Dataflow（A）はApache Beamを用いるストリーム／バッチ処理サービスで、既存のSpark／Hadoopコードをそのまま動かす用途には適しません。
Compute Engine（C）では自前でクラスタを構築・管理する必要があり運用負荷が大きく、Container Engine（D）はコンテナオーケストレーション用でSpark／Hadoopの直接移行先ではありません。
Dataproc の概要 | Google Cloud
Q4Google Professional Cloud Architect
Q4. ある会社のテストスイートは、Linux仮想マシン上で終日にわたり実行されるカスタムC++アプリケーションです。
スイート全体が完了するまでには数時間かかり、テスト専用に用意された台数の限られたオンプレミスサーバー上で動作しています。
この会社は、テスト内容の変更を最小限に留めつつ、システム変更のフルテストに要する時間を短縮するため、テスト基盤をクラウドへ移行したいと考えています。
どのクラウド基盤を推奨すべきですか。
解答を見る
正解：B. 自動スケーリングを有効化したGoogle Compute Engineのマネージド インスタンスグループを使う。
正解はBです。マネージドインスタンスグループと自動スケーリングを使えば、既存のC++テストをほぼ変更せずに多数のVMへ並列展開でき、テスト時間を大幅に短縮できます。
テストはLinux VM上で動くため、同じ環境のVMを必要なだけ増やすこのアプローチが最も移行コストの低い選択です。
非マネージドグループとロードバランサ（A）は自動スケーリングや自己修復に乏しく適しません。
Dataproc（C）はSpark／Hadoop向けで、C++テストをHadoopジョブに書き換える必要が生じます。
App Engine（D）はアプリ実行基盤であり、既存のC++テストをそのまま動かす用途には適しません。
マネージド インスタンス グループの自動スケーリング | Google Cloud
Q5Google Professional Cloud Architect
Q5. ある会社は、増大するコンピューティング需要に対応するため、Google Compute Engineへの迅速なリフト＆シフト移行を完了させたばかりです。
今後9か月かけて、より「クラウドネイティブ」なソリューションへ設計・展開し直す計画です。
具体的には、運用作業が不要（no-ops）で自動的にスケールするシステムを実現したいと考えています。
どの2つのコンピューティング製品を選ぶべきですか。
回答を2つ選んでください。
解答を見る
正解：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
Q6Google Professional Cloud Architect
Q6. ある開発リーダーが新規アプリケーションの構築を進めています。
彼はあなたに、要件を確認したうえで、それらを満たせるクラウド技術を選定するよう依頼しました。
このアプリケーションには次の条件が求められます。
1. クラウド間の移植性を確保するため、オープンソース技術を基盤とすること。
2. 需要の変動に応じて、コンピューティング容量を動的にスケールできること。
3. 継続的なソフトウェア配信（CD）をサポートすること。
4. 同一のアプリケーションスタックを、複数かつ分離した状態で並行実行できること。
5. 動的なテンプレートを使ってアプリケーションバンドルをデプロイできること。
6. URLに応じて、ネットワークトラフィックを該当サービスへ振り分けられること。
これらすべての条件を満たす技術の組み合わせはどれですか。
解答を見る
正解：A. Google Container Engine（現Google Kubernetes Engine）、Jenkins、Helm
正解は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
Q7Google Professional Cloud Architect
Q7. マーケティング部門が、販促のためのメール配信キャンペーンを実施したいと考えています。
開発チームとしては、日々の直接的な運用管理をできる限り抑えたいという要望があります。
想定される反応は幅広く、1日あたり100件から最大50万件のクリックスルーまで見込んでいます。
リンク先は、販促内容を説明し、ユーザーの情報や好みを収集するシンプルなウェブサイトです。
どの基盤構成を推奨すべきですか。
回答を2つ選んでください。
解答を見る
正解：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
Q8Google Professional Cloud Architect
Q8. あなたのチームが掲げる重要なビジネス目標の一つは、アプリケーションに保存するデータの信頼性を担保することです。
そこで、アプリケーションデータへのすべての変更をログとして記録したいと考えています。
ログの真正性を後から検証できるように、ロギングの仕組みをどう設計すればよいですか。
解答を見る
正解：C. 各ログエントリとそのタイムスタンプにデジタル署名を行い、生成された署名を保存する。
正解はCです。各ログエントリとタイムスタンプにデジタル署名を施し署名を保存すれば、後からの改ざんを検知でき、ログの真正性（authenticity）を暗号学的に検証できます。
署名はエントリ内容に基づくため、内容が変われば署名検証が失敗し、改ざんが明らかになります。
二重書き込み（A）は冗長性を高めますが真正性そのものは保証しません。
テーブルの更新権限制限（B）はアクセス制御に留まり、改ざんの暗号的検証にはなりません。
JSONダンプの保存（D）も保管手段にすぎず、内容が正当であることを証明できません。
Cloud Audit Logs の概要 | Google Cloud
Q9Google Professional Cloud Architect
Q9. あなたはGoogle Compute Engine上に、複数のプリエンプティブ（preemptible）なLinux仮想マシンインスタンスを作成しました。
各インスタンスがプリエンプト（preempt：強制停止）される前に、稼働中のアプリケーションを正しくシャットダウンさせたいと考えています。
どのように対応すべきですか。
解答を見る
正解：C. シャットダウンスクリプトを作成し、新しい仮想マシンインスタンスを作成する際に、Cloud Platform Consoleでキー shutdown-script を持つ新しいメタデータエントリの値として設定する。
正解は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
Q10Google Professional Cloud Architect
Q10. ある会社が、リスクを抑えた形でクラウドを試験導入したいと考えています。
約100TB分のログデータをクラウドへアーカイブし、そこで利用可能な分析機能を試すと同時に、そのデータを長期のディザスタリカバリ用バックアップとしても保持したいと考えています。
どの2つの手順を取るべきですか。
回答を2つ選んでください。
解答を見る
正解：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