表示モード
画像位置
文字位置
理解度の自動記録
Q1Google Associate Cloud Engineer
Q1. あなたは運用チームから、Cloud Storageバケット内のオブジェクトにライフサイクル管理（Object Lifecycle Management）を設定するよう依頼されました。
対象のオブジェクトは一度だけ書き込まれた後、最初の30日間は頻繁に参照されます。
30日を過ぎると、特段の事情がない限り再び読み取られることはありません。
それでもオブジェクトは3年間保持する必要があり、費用はできる限り抑えたいと考えています。
あなたはどうすべきですか？
解答を見る
正解：B. 最初の30日間はStandardストレージクラスを使用し、その後3年間はArchiveストレージクラスへ移行するライフサイクルポリシーを設定する。
要件の鍵は「オブジェクトは一度書き込まれ、30日間は頻繁にアクセスされる」という点です。頻繁にアクセスされる「ホット」なデータには、最初の30日間はStandardストレージが最適です。
30日経過後はほとんどアクセスされないため、年に1回未満のアクセスを想定する最も低コストなArchiveストレージへ移動するのが適切です。
Nearline（最小30日）やColdline（最小90日）は中間的なクラスで、3年間の長期保管にはArchiveが最安となります。
頻繁アクセス期間はStandard、その後の長期保管は最安のArchiveを選ぶのが最小コスト構成です。
ストレージクラス | Cloud Storage | Google Cloud
Q2Google Associate Cloud Engineer
Q2. Google Kubernetes Engine（GKE）のクラスタ上で、複数のマイクロサービスを稼働させています。
そのうちの1つは画像のレンダリング処理を担当しており、必要とするメモリ量に対して非常に多くのCPU時間を消費します。
残りのマイクロサービスは、n1-standardマシンタイプに最適化されたワークロードです。
すべてのワークロードがリソースをできるだけ効率的に使えるよう、クラスタの構成を見直す必要があります。
あなたはどうすべきですか？
解答を見る
正解：B. 画像レンダリングのマイクロサービス向けに、コンピューティング最適化（compute-optimized）マシンタイプのノードプールを作成し、他のマイクロサービスには汎用（general-purpose）マシンタイプのノードプールを使用する。
画像レンダリングはメモリに比べてCPU負荷が高いため、CPUに特化したコンピューティング最適化（compute-optimized）マシンタイプが適しています。一方、他のワークロードはn1-standard（汎用）向けに最適化されています。
ワークロードの特性ごとにノードプールを分け、画像レンダリング用にcompute-optimized、その他に汎用ノードプールを割り当てることで、各Podが特性に合ったノードで動作し、リソースを最も効率的に使えます。
Pod優先度はスケジューリング順序の制御であり、リソース効率の最適化策ではありません。
ワークロードのCPU・メモリ特性に応じてノードプールを分離するのが最も効率的なリソース最適化策です。
ノードプールについて | GKE | Google Cloud
Q3Google Associate Cloud Engineer
Q3. 動画エンコーディング用のソフトウェアを、Compute Engine上でホストしたいと考えています。
利用者数は急速に増えており、ユーザーはいつでも中断やCPU制限を受けることなく動画をエンコードできる必要があります。
このエンコーディング基盤は高可用性を備え、運用を自動化するためのGoogle推奨プラクティスに沿った構成にしたいと考えています。
あなたはどうすべきですか？
解答を見る
正解：D. ソリューションをインスタンスグループにデプロイし、CPU使用率に基づく自動スケーリングを設定する。
Googleが推奨する運用自動化のプラクティスは、マネージドインスタンスグループ（MIG）の自動スケーリングを使うことです。CPU使用率に基づいて自動スケーリングを設定すれば、負荷に応じてインスタンスが自動的に追加・削除され、中断なく高可用性を維持できます。
A・Cのように手動でインスタンス数を増やす方法は自動化されておらず運用効率が低く、Bのインスタンス置き換えも自動スケーリングの代替にはなりません。
CPU使用率に基づくMIGの自動スケーリングが、自動化と高可用性の両方を満たす推奨構成です。
インスタンスの自動スケーリングについて | Compute Engine | Google Cloud
Q4Google Associate Cloud Engineer
Q4. App Engineスタンダード環境上でWebサイトを運用しています。
全ユーザーのうち1%に対してのみ、新しいテスト版のWebサイトを表示したいと考えています。
構成はできる限りシンプルに保ちたいと考えています。
あなたはどうすべきですか？
解答を見る
正解：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
Q5Google Associate Cloud Engineer
Q5. メンテナンス発生時にもサービスを継続できるよう、10台のCompute Engineインスタンスを構成したいと考えています。
要件として、これらのインスタンスはクラッシュした場合に自動的に再起動される必要があります。
加えて、計画的なシステムメンテナンス中も含めて高可用性を維持する必要があります。
あなたはどうすべきですか？
解答を見る
正解：A. インスタンス用のインスタンステンプレートを作成し、「自動再起動（Automatic Restart）」をオンに設定する。「ホストメンテナンス時（On-host maintenance）」は「VMインスタンスを移行（Migrate VM instance）」に設定し、このテンプレートをインスタンスグループへ追加する。
要件は「クラッシュ時の自動再起動」と「メンテナンス中も含む高可用性」の2点です。自動再起動（Automatic Restart）をオンにすればクラッシュ時にインスタンスが自動復旧します。
ホストメンテナンス時の動作をMigrate（ライブマイグレーション）にすれば、計画メンテナンス中もインスタンスが別ホストへ移行され停止しません。
BはTerminateで停止するため不適切、C・Dは自動再起動とライブマイグレーションの両要件を満たしません。
自動再起動オンとホストメンテナンス時のライブマイグレーション設定が、両要件を満たす鍵です。
インスタンスのスケジューリングオプションの設定 | Compute Engine | Google Cloud
Q6Google Associate Cloud Engineer
Q6. 複数のマイクロサービスから構成されるアプリケーションを開発しました。
各マイクロサービスは、それぞれ専用のDockerコンテナイメージとしてパッケージ化されています。
各マイクロサービスを個別にスケーリングできる形で、アプリケーション全体をGoogle Kubernetes Engine（GKE）にデプロイしたいと考えています。
あなたはどうすべきですか？
解答を見る
正解：D. マイクロサービスごとにDeployment（デプロイメント）を作成し、デプロイする。
GKEで継続的に稼働するステートレスなマイクロサービスを個別にスケーリングするには、マイクロサービスごとにDeploymentを作成するのが標準的な方法です。DeploymentはPodのレプリカ数を管理し、HPA（水平Pod自動スケーリング）と組み合わせて各サービスを独立してスケールできます。
Jobは完了して終了するバッチ処理向けで常駐サービスには不適切、Docker ComposeはKubernetesのネイティブ機能ではなく、CRDは独自リソースの拡張定義であり通常のサービス配置には用いません。
個別にスケール可能な常駐マイクロサービスには、サービスごとのDeploymentが適切です。
Deployment について | GKE | Google Cloud
Q7Google Associate Cloud Engineer
Q7. 営業部門は、「Sales Data Digest」という名前のプロジェクト（ID: acme-data-digest）を保有しています。
マーケティング部門向けにも同様のGoogle Cloudリソースを用意する必要がありますが、そのリソースは営業部門とは独立して管理されなければなりません。
あなたはどうすべきですか？
解答を見る
正解：C. マーケティング部門用に、ID「acme-marketing-data-digest」を持つ別のプロジェクトを新規作成し、そこにリソースをデプロイする。
Google Cloudではリソースはプロジェクト単位で分離・管理されます。マーケティング部門のリソースを営業部門から独立させるには、マーケティング専用の新しいプロジェクトを作成し、そこにリソースを配置するのが正解です。
A・Bは同一プロジェクトを共有するため独立性が確保できません。
DはプロジェクトIDがグローバルに一意であり、既存のacme-data-digestを再利用できないため成立しません。
リソースの独立管理は、プロジェクトを分けることで実現するのが基本原則です。
プロジェクトの作成と管理 | Resource Manager | Google Cloud
Q8Google Associate Cloud Engineer
Q8. 既定のリージョンとゾーンで運用している1つのGoogle Cloudアカウントと、既定以外のリージョンとゾーンで運用しているもう1つのアカウントを保有しています。
コマンドラインインターフェース（CLI）を用いて、この2つのアカウントそれぞれで新しいCompute Engineインスタンスを起動したいと考えています。
あなたはどうすべきですか？
解答を見る
正解：A. gcloud config configurations create [NAME] で2つの構成を作成し、Compute Engineインスタンスを起動するコマンドを実行する際にgcloud config configurations activate [NAME] を実行してアカウントを切り替える。
複数のアカウント・リージョン・ゾーンを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 ドキュメント
Q9Google Associate Cloud Engineer
Q9. これから作成する予定の、まだ存在しない新しいプロジェクトの中に、Compute Engineインスタンスを作成する必要があります。
あなたはどうすべきですか？
解答を見る
正解：A. Cloud SDKを使って新しいプロジェクトを作成し、そのプロジェクトでCompute Engine APIを有効化したうえで、新しいプロジェクトを指定してインスタンスを作成する。
存在しないプロジェクトにインスタンスを作る場合、まずプロジェクト自体を作成する必要があります。正しい手順は、Cloud SDK（gcloud）で新規プロジェクトを作成し、そのプロジェクトでCompute Engine APIを有効化し、最後に新プロジェクトを指定してインスタンスを作成する、という順序です。
B・CはAPIを既存プロジェクトで有効化したり、存在しないプロジェクトを先に指定したりして手順が逆です。
Dの「新しいプロジェクトで作成」というフォーム上のオプションは実在しません。
新規プロジェクト作成→API有効化→インスタンス作成、という順序が必須の流れです。
VM インスタンスの作成と起動 | Compute Engine | Google Cloud
Q10Google Associate Cloud Engineer
Q10. 単一のバイナリで構成されるアプリケーションを、Google Cloud上で稼働させたいと考えています。
基盤インフラのCPU使用率に応じて、アプリケーションを自動的にスケーリングする方針にしました。
社内の組織ポリシーにより、仮想マシンを直接利用することが求められています。
スケーリングは運用面で効率的であり、かつできる限り迅速に完了する必要があります。
あなたはどうすべきですか？
解答を見る
正解：B. インスタンステンプレートを作成し、そのテンプレートを自動スケーリングが設定されたマネージドインスタンスグループで使用する。
組織ポリシーで仮想マシンを直接使う必要があるため、コンテナを使うGKE（A）は除外されます。CPU使用率に基づき迅速かつ効率的にスケールするには、インスタンステンプレートを用いたマネージドインスタンスグループ（MIG）の自動スケーリングが最適です。
Cの時刻ベースのスケジュールスケーリングはCPU負荷に追従できず、Dのサードパーティツールは運用が複雑で非効率です。
MIGはCPUなどの指標に応じてVMを自動増減でき、VMを直接使う要件にも合致します。
VMを直接利用しつつCPUベースで即応スケールするには、MIGの自動スケーリングが最適解です。
インスタンスの自動スケーリングについて | Compute Engine | Google Cloud