Q1. ストレージバケットに保存されたオブジェクトに対して、オブジェクトのライフサイクル管理（Object Lifecycle Management）を設定するよう依頼されました。
これらのオブジェクトは一度だけ書き込まれ、30日間は頻繁にアクセスされます。
30日経過後は、特別な必要がない限り再び読み取られることはありません。
オブジェクトは3年間保持する必要があり、コストを最小限に抑える必要があります。
あなたはどうすべきですか？
A. 30日間はNearlineストレージを使用し、その後3年間Archiveストレージに移動するポリシーを設定する。
B. 30日間はStandardストレージを使用し、その後3年間Archiveストレージに移動するポリシーを設定する。
C. 30日間はNearlineストレージを使用し、その後1年間Coldlineに移動し、さらに2年間Archiveストレージに移動するポリシーを設定する。
D. 30日間はStandardストレージを使用し、その後1年間Coldlineに移動し、さらに2年間Archiveストレージに移動するポリシーを設定する。
回答
- B. 30日間はStandardストレージを使用し、その後3年間Archiveストレージに移動するポリシーを設定する。
-
要件の鍵は「オブジェクトは一度書き込まれ、30日間は頻繁にアクセスされる」という点です。
頻繁にアクセスされる「ホット」なデータには、最初の30日間はStandardストレージが最適です。
30日経過後はほとんどアクセスされないため、年に1回未満のアクセスを想定する最も低コストなArchiveストレージへ移動するのが適切です。
Nearline（最小30日）やColdline（最小90日）は中間的なクラスで、3年間の長期保管にはArchiveが最安となります。
頻繁アクセス期間はStandard、その後の長期保管は最安のArchiveを選ぶのが最小コスト構成です。
ストレージクラス | Cloud Storage | Google Cloud
Q2. Kubernetes Engineクラスタで複数のマイクロサービスを実行しています。
あるマイクロサービスは画像のレンダリングを行っています。
画像レンダリングを担当するマイクロサービスは、必要とするメモリに比べて大量のCPU時間を必要とします。
他のマイクロサービスは、n1-standardマシンタイプ向けに最適化されたワークロードです。
すべてのワークロードができる限り効率的にリソースを使用するよう、クラスタを最適化する必要があります。
あなたはどうすべきですか？
A. 画像レンダリングのマイクロサービスのPodに、他のマイクロサービスよりも高いPod優先度（Pod Priority）を割り当てる。
B. 画像レンダリングのマイクロサービス用に、コンピューティング最適化（compute-optimized）マシンタイプのノードを持つノードプールを作成する。他のマイクロサービスには汎用（general-purpose）マシンタイプのノードを持つノードプールを使用する。
C. 画像レンダリングのマイクロサービスには汎用（general-purpose）マシンタイプのノードを持つノードプールを使用する。他のマイクロサービス用にコンピューティング最適化（compute-optimized）マシンタイプのノードを持つノードプールを作成する。
D. 画像レンダリングのマイクロサービスのデプロイメントのリソースリクエスト仕様に必要なCPUとメモリ量を設定する。他のマイクロサービスのリソースリクエストはデフォルトのままにする。
回答
- B. 画像レンダリング用にコンピューティング最適化ノードプールを作成し、他のマイクロサービスには汎用ノードプールを使用する。
-
画像レンダリングはメモリに比べてCPU負荷が高いため、CPUに特化したコンピューティング最適化（compute-optimized）マシンタイプが適しています。
一方、他のワークロードはn1-standard（汎用）向けに最適化されています。
ワークロードの特性ごとにノードプールを分け、画像レンダリング用にcompute-optimized、その他に汎用ノードプールを割り当てることで、各Podが特性に合ったノードで動作し、リソースを最も効率的に使えます。
Pod優先度はスケジューリング順序の制御であり、リソース効率の最適化策ではありません。
ワークロードのCPU・メモリ特性に応じてノードプールを分離するのが最も効率的なリソース最適化策です。
ノードプールについて | GKE | Google Cloud
Q3. 動画エンコーディングソフトウェアをCompute Engineでホストしたいと考えています。
ユーザーベースは急速に拡大しており、ユーザーは中断やCPU制限なしにいつでも動画をエンコードできる必要があります。
エンコーディングソリューションは高可用性である必要があり、運用を自動化するためにGoogleが推奨するプラクティスに従いたいと考えています。
あなたはどうすべきですか？
A. 複数のスタンドアロンCompute Engineインスタンスにソリューションをデプロイし、Cloud MonitoringのCPU使用率が一定のしきい値に達したら既存のインスタンス数を増やす。
B. 複数のスタンドアロンCompute Engineインスタンスにソリューションをデプロイし、Cloud MonitoringのCPU使用率が一定のしきい値に達したら既存のインスタンスを高CPUインスタンスに置き換える。
C. ソリューションをインスタンスグループにデプロイし、Cloud Monitoringで高いCPU使用率が見られるたびに利用可能なインスタンス数を増やす。
D. ソリューションをインスタンスグループにデプロイし、CPU使用率に基づいて自動スケーリングを設定する。
回答
- D. ソリューションをインスタンスグループにデプロイし、CPU使用率に基づいて自動スケーリングを設定する。
-
Googleが推奨する運用自動化のプラクティスは、マネージドインスタンスグループ（MIG）の自動スケーリングを使うことです。
CPU使用率に基づいて自動スケーリングを設定すれば、負荷に応じてインスタンスが自動的に追加・削除され、中断なく高可用性を維持できます。
A・Cのように手動でインスタンス数を増やす方法は自動化されておらず運用効率が低く、Bのインスタンス置き換えも自動スケーリングの代替にはなりません。
CPU使用率に基づくMIGの自動スケーリングが、自動化と高可用性の両方を満たす推奨構成です。
インスタンスの自動スケーリングについて | Compute Engine | Google Cloud
Q4. App Engineスタンダード環境でホストされているWebサイトがあります。
ユーザーの1%に新しいテスト版のWebサイトを表示したいと考えています。
複雑さを最小限に抑えたいと考えています。
あなたはどうすべきですか？
A. 同じアプリケーションに新しいバージョンをデプロイし、–migrateオプションを使用する。
B. 同じアプリケーションに新しいバージョンをデプロイし、–splitsオプションを使用して現在のバージョンに99、新しいバージョンに1の重みを与える。
C. 同じプロジェクト内に新しいApp Engineアプリケーションを作成する。そのアプリケーションに新しいバージョンをデプロイする。App Engineライブラリを使用してリクエストの1%を新しいバージョンにプロキシする。
D. 同じプロジェクト内に新しいApp Engineアプリケーションを作成する。そのアプリケーションに新しいバージョンをデプロイする。ネットワークロードバランサを構成して、トラフィックの1%をその新しいアプリケーションに送信する。
回答
- B. 同じアプリケーションに新しいバージョンをデプロイし、–splitsオプションを使用して現在のバージョンに99、新しいバージョンに1の重みを与える。
-
App Engineにはトラフィック分割（traffic splitting）機能が組み込まれており、–splitsオプションで各バージョンに重みを指定するだけで、複雑さを最小限にカナリアリリースが実現できます。
現行99・新版1とすればユーザーの1%に新バージョンを表示できます。
1つのプロジェクトにはApp Engineアプリは1つしか作成できないため、C・Dの「新しいApp Engineアプリを作成」は実現できません。
–migrateは全トラフィックを移行するため、1%だけ表示する用途には不適切です。
App Engineの–splitsによるトラフィック分割が、最小限の複雑さで段階的リリースを実現します。
トラフィックの分割 | App Engine スタンダード環境 | Google Cloud
Q5. メンテナンス発生時の可用性のために10台のCompute Engineインスタンスを構成したいと考えています。
要件では、これらのインスタンスはクラッシュした場合に自動的に再起動を試みる必要があります。
また、システムメンテナンス中も含めて高可用性である必要があります。
あなたはどうすべきですか？
A. インスタンス用のインスタンステンプレートを作成する。「自動再起動（Automatic Restart）」をオンに設定する。「ホストメンテナンス時（On-host maintenance）」を「VMインスタンスを移行（Migrate VM instance）」に設定する。インスタンステンプレートをインスタンスグループに追加する。
B. インスタンス用のインスタンステンプレートを作成する。「自動再起動」をオフに設定する。「ホストメンテナンス時」を「VMインスタンスを終了（Terminate VM instances）」に設定する。インスタンステンプレートをインスタンスグループに追加する。
C. インスタンス用のインスタンスグループを作成する。「自動修復（Autohealing）」のヘルスチェックをhealthy（HTTP）に設定する。
D. インスタンス用のインスタンスグループを作成する。「詳細作成オプション（Advanced creation options）」の「マシン作成を再試行しない（do not retry machine creation）」設定がオフになっていることを確認する。
回答
- A. 自動再起動をオン、ホストメンテナンス時を「VMインスタンスを移行」に設定したインスタンステンプレートを作成し、インスタンスグループに追加する。
-
要件は「クラッシュ時の自動再起動」と「メンテナンス中も含む高可用性」の2点です。
自動再起動（Automatic Restart）をオンにすればクラッシュ時にインスタンスが自動復旧します。
ホストメンテナンス時の動作をMigrate（ライブマイグレーション）にすれば、計画メンテナンス中もインスタンスが別ホストへ移行され停止しません。
BはTerminateで停止するため不適切、C・Dは自動再起動とライブマイグレーションの両要件を満たしません。
自動再起動オンとホストメンテナンス時のライブマイグレーション設定が、両要件を満たす鍵です。
インスタンスのスケジューリングオプションの設定 | Compute Engine | Google Cloud
Q6. 複数のマイクロサービスで構成されるアプリケーションを開発しました。
各マイクロサービスはそれぞれ独自のDockerコンテナイメージにパッケージ化されています。
各マイクロサービスを個別にスケーリングできるよう、アプリケーション全体をGoogle Kubernetes Engineにデプロイしたいと考えています。
あなたはどうすべきですか？
A. マイクロサービスごとにカスタムリソース定義（Custom Resource Definition）を作成してデプロイする。
B. Docker Composeファイルを作成してデプロイする。
C. マイクロサービスごとにJob（ジョブ）を作成してデプロイする。
D. マイクロサービスごとにDeployment（デプロイメント）を作成してデプロイする。
回答
- D. マイクロサービスごとにDeployment（デプロイメント）を作成してデプロイする。
-
GKEで継続的に稼働するステートレスなマイクロサービスを個別にスケーリングするには、マイクロサービスごとにDeploymentを作成するのが標準的な方法です。
DeploymentはPodのレプリカ数を管理し、HPA（水平Pod自動スケーリング）と組み合わせて各サービスを独立してスケールできます。
Jobは完了して終了するバッチ処理向けで常駐サービスには不適切、Docker ComposeはKubernetesのネイティブ機能ではなく、CRDは独自リソースの拡張定義であり通常のサービス配置には用いません。
個別にスケール可能な常駐マイクロサービスには、サービスごとのDeploymentが適切です。
Deployment について | GKE | Google Cloud
Q7. 営業チームは「Sales Data Digest」という名前のプロジェクト（ID: acme-data-digest）を持っています。
マーケティングチーム向けに同様のGoogle Cloudリソースを設定する必要がありますが、彼らのリソースは営業チームとは独立して管理される必要があります。
あなたはどうすべきですか？
A. acme-data-digestに対して、マーケティングチームにプロジェクト編集者（Project Editor）ロールを付与する。
B. acme-data-digestにプロジェクトリーエン（Project Lien）を作成し、その後マーケティングチームにプロジェクト編集者ロールを付与する。
C. マーケティングチーム用にID「acme-marketing-data-digest」を持つ別のプロジェクトを作成し、そこにリソースをデプロイする。
D. 「Meeting Data Digest」という名前の新しいプロジェクトを作成し、ID「acme-data-digest」を使用する。マーケティングチームにプロジェクト編集者ロールを付与する。
回答
- C. マーケティングチーム用に別のプロジェクト（ID: acme-marketing-data-digest）を作成し、そこにリソースをデプロイする。
-
Google Cloudではリソースはプロジェクト単位で分離・管理されます。
マーケティングチームのリソースを営業チームから独立させるには、マーケティング専用の新しいプロジェクトを作成し、そこにリソースを配置するのが正解です。
A・Bは同一プロジェクトを共有するため独立性が確保できません。
DはプロジェクトIDがグローバルに一意であり、既存のacme-data-digestを再利用できないため成立しません。
リソースの独立管理は、プロジェクトを分けることで実現するのが基本原則です。
プロジェクトの作成と管理 | Resource Manager | Google Cloud
Q8. デフォルトのリージョンとゾーンで実行されている1つのGCPアカウントと、デフォルト以外のリージョンとゾーンで実行されているもう1つのアカウントがあります。
コマンドラインインターフェース（CLI）を使用して、これら2つのGoogle Cloud Platformアカウントで新しいCompute Engineインスタンスを起動したいと考えています。
あなたはどうすべきですか？
A. gcloud config configurations create [NAME] を使用して2つの構成を作成する。Compute Engineインスタンスを起動するコマンドを実行する際に、gcloud config configurations activate [NAME] を実行してアカウントを切り替える。
B. gcloud config configurations create [NAME] を使用して2つの構成を作成する。gcloud configurations list を実行してCompute Engineインスタンスを起動する。
C. gcloud configurations activate [NAME] を使用して2つの構成をアクティブ化する。gcloud config list を実行してCompute Engineインスタンスを起動する。
D. gcloud configurations activate [NAME] を使用して2つの構成をアクティブ化する。gcloud configurations list を実行してCompute Engineインスタンスを起動する。
回答
- A. gcloud config configurations create で2つの構成を作成し、コマンド実行時に gcloud config configurations activate で構成を切り替える。
-
複数のアカウント・リージョン・ゾーンをCLIで切り替えるには、gcloud config configurations create で各アカウント用の名前付き構成を作成し、gcloud config configurations activate で必要な構成に切り替えるのが正しい方法です。
アクティブな構成に応じて、認証情報や既定リージョン・ゾーンが切り替わります。
B・C・Dの「gcloud configurations list」や「config list」は構成の一覧表示や設定確認用のコマンドであり、インスタンスを起動する手段にはなりません。
gcloud config configurations の create と activate で名前付き構成を切り替えるのが正攻法です。
gcloud CLI 構成の管理 | Google Cloud CLI ドキュメント
Q9. まだ存在しない新しいプロジェクトにCompute Engineインスタンスを作成する必要があります。
あなたはどうすべきですか？
A. Cloud SDKを使用して新しいプロジェクトを作成し、そのプロジェクトでCompute Engine APIを有効化し、その後新しいプロジェクトを指定してインスタンスを作成する。
B. Cloud ConsoleでCompute Engine APIを有効化し、Cloud SDKを使用してインスタンスを作成し、-pproject フラグを使用して新しいプロジェクトを指定する。
C. Cloud SDKを使用して新しいインスタンスを作成し、-pproject フラグを使用して新しいプロジェクトを指定する。Cloud SDKからCompute Engine APIの有効化を求められたら「はい（yes）」と答える。
D. Cloud ConsoleでCompute Engine APIを有効化する。コンソールのCompute Engineセクションに移動して新しいインスタンスを作成し、作成フォームで「新しいプロジェクトで作成（Create In A New Project）」オプションを探す。
回答
- A. Cloud SDKで新しいプロジェクトを作成し、そのプロジェクトでCompute Engine APIを有効化したうえで、新しいプロジェクトを指定してインスタンスを作成する。
-
存在しないプロジェクトにインスタンスを作る場合、まずプロジェクト自体を作成する必要があります。
正しい手順は、Cloud SDK（gcloud）で新規プロジェクトを作成し、そのプロジェクトでCompute Engine APIを有効化し、最後に新プロジェクトを指定してインスタンスを作成する、という順序です。
B・CはAPIを既存プロジェクトで有効化したり、存在しないプロジェクトを先に指定したりして手順が逆です。
Dの「新しいプロジェクトで作成」というフォーム上のオプションは実在しません。
新規プロジェクト作成→API有効化→インスタンス作成、という順序が必須の流れです。
VM インスタンスの作成と起動 | Compute Engine | Google Cloud
Q10. Google Cloud Platformで実行したい単一バイナリのアプリケーションがあります。
基盤となるインフラのCPU使用率に基づいてアプリケーションを自動的にスケーリングすることにしました。
組織のポリシーにより、仮想マシンを直接使用することが求められています。
アプリケーションのスケーリングが運用上効率的で、可能な限り迅速に完了することを保証する必要があります。
あなたはどうすべきですか？
A. Google Kubernetes Engineクラスタを作成し、水平Pod自動スケーリング（horizontal pod autoscaling）を使用してアプリケーションをスケーリングする。
B. インスタンステンプレートを作成し、そのテンプレートを自動スケーリングが構成されたマネージドインスタンスグループで使用する。
C. インスタンステンプレートを作成し、そのテンプレートを時刻に基づいてスケールアップ・スケールダウンするマネージドインスタンスグループで使用する。
D. Stackdriver（現Cloud Monitoring）のCPU使用率モニタリングに基づいて、アプリケーションのスケールアップ・ダウンを自動化するサードパーティ製ツール群を使用する。
回答
- B. インスタンステンプレートを作成し、そのテンプレートを自動スケーリングが構成されたマネージドインスタンスグループで使用する。
-
組織ポリシーで仮想マシンを直接使う必要があるため、コンテナを使うGKE（A）は除外されます。
CPU使用率に基づき迅速かつ効率的にスケールするには、インスタンステンプレートを用いたマネージドインスタンスグループ（MIG）の自動スケーリングが最適です。
Cの時刻ベースのスケジュールスケーリングはCPU負荷に追従できず、Dのサードパーティツールは運用が複雑で非効率です。
MIGはCPUなどの指標に応じてVMを自動増減でき、VMを直接使う要件にも合致します。
VMを直接利用しつつCPUベースで即応スケールするには、MIGの自動スケーリングが最適解です。
インスタンスの自動スケーリングについて | Compute Engine | Google Cloud