第1回 問題集（全般）

正解: A. A. 組織の下にフォルダを部門ごとに作成し、各フォルダ内でプロジェクトを管理してIAMポリシーをフォルダレベルで継承させる

正解の根拠・詳細解説

フォルダを部門・チーム単位で作成し、IAMポリシーや組織ポリシーをフォルダレベルで設定することで、ポリシーの継承を活かしつつ部門ごとの柔軟な管理が可能になる。これはGoogle Cloudのリソース階層設計のベストプラクティス。

正解: A. A. 共有VPC（Shared VPC）を構成し、ホストプロジェクトでネットワークを管理しサービスプロジェクトにアタッチする

正解の根拠・詳細解説

共有VPC（Shared VPC）はホストプロジェクトでネットワークリソースを集中管理し、複数のサービスプロジェクトがそのネットワークを共有利用できる仕組みで、IPアドレス計画やファイアウォールルールの一元統制に最適。

正解: A. A. Cloud Monitoringのスコープ付きプロジェクト（Metrics Scope）を構成し、複数プロジェクトのメトリクスを1つのモニタリングプロジェクトに集約する

正解の根拠・詳細解説

Cloud MonitoringのMetrics Scope機能を使うことで、複数プロジェクトのメトリクスを1つの監視用プロジェクトに集約し、組織全体を横断したダッシュボード・アラートの一元管理が可能になる。

正解: A. A. 組織レベルで設定されたIAMポリシーは、特別な制限がない限り下位のフォルダ・プロジェクトに継承される

正解の根拠・詳細解説

Google CloudのIAMポリシーはリソース階層（組織→フォルダ→プロジェクト）に沿って継承される。上位レベルで許可されたポリシーは下位に継承され、ポリシーの追加（許可の重ね合わせ）として機能する。

正解: A. A. アプリケーションの機能単位で専用のサービスアカウントを作成し、必要最小限のIAMロールのみを付与する

正解の根拠・詳細解説

最小権限の原則に基づき、アプリケーション・機能単位で専用のサービスアカウントを作成し、業務上必要な最小限のIAMロールのみを付与することで、権限漏洩時の影響範囲を限定できる。

正解: A. A. プロジェクトやサービスをまたいで「アプリケーション」という論理的な単位でリソースをグルーピングし、運用・モニタリングの粒度を技術的境界からビジネス境界に合わせられる

正解の根拠・詳細解説

App Hubは複数のプロジェクト・サービスにまたがるリソースを「アプリケーション」という論理単位でグルーピングし、技術的なプロジェクト境界ではなくビジネス上の意味のある単位で運用・モニタリング・ガバナンスを行えるようにする。

正解: A. A. terraform planを実行して変更内容を事前確認し、レビュープロセスを経てからapplyする

正解の根拠・詳細解説

Infrastructure as Codeのベストプラクティスとして、terraform planで変更内容（diff）を事前に確認し、コードレビュープロセスを経てから本番適用（apply）することで、意図しない変更による障害を防止する。

正解: A. A. Kubernetesのカスタムリソース定義（CRD）を通じてGoogle Cloudリソースを宣言的に管理できるようにするアドオン

正解の根拠・詳細解説

Config ConnectorはGKE上で動作するKubernetesアドオンで、Google CloudリソースをKubernetesのカスタムリソース（YAML）として宣言的に管理でき、GitOpsワークフローにGoogle Cloudインフラ管理を統合できる。

正解: A. A. IaCツールは宣言的なリソース管理に適し、スクリプトは複雑な条件分岐やカスタムロジックを要する運用タスク（一時的な操作やレポート生成等）に適している

正解の根拠・詳細解説

Terraform等のIaCツールはリソースの望ましい状態を宣言的に管理するのに適しており、PythonやGoのスクリプトは条件分岐や外部API連携を伴う複雑な運用タスク・一時的な操作の自動化に適している。両者は補完的に使い分けるのがベストプラクティス。

正解: A. A. ソースコードのpushをトリガーにビルド・テストを実行し、コンテナイメージをArtifact Registryにプッシュする

正解の根拠・詳細解説

継続的インテグレーション（CI）は、コードのpush等をトリガーに自動的にビルド・自動テストを実行し、検証済みのコンテナイメージをArtifact Registry等のレジストリにプッシュするまでの一連の流れを指す。

正解: A. A. Kustomizeで環境ごとのKubernetesマニフェストのカスタマイズを行い、Skaffoldでローカル開発からデプロイまでの開発者体験を効率化する

正解の根拠・詳細解説

KustomizeはベースとなるKubernetesマニフェストを環境（dev/staging/prod等）ごとにオーバーレイでカスタマイズする宣言的な仕組みで、Skaffoldはローカルでのビルド・テスト・デプロイのワークフローを自動化し開発者体験を向上させる。Cloud DeployはこれらをCDパイプラインに統合する。

正解: A. A. ツールが使用するサービスアカウントの権限を最小化し、シークレットの管理をCloud KMSやSecret Managerと連携させる

正解の根拠・詳細解説

サードパーティCI/CDツールがGoogle Cloudリソースにアクセスする際は、専用のサービスアカウントに最小権限を付与し、認証情報やAPIキー等のシークレットはSecret Manager等で安全に管理することがセキュリティの基本原則。

正解: A. A. プルリクエストごとに使い捨てのテスト環境を自動生成・破棄し、本番に近い条件での検証とコスト最適化を両立する

正解の根拠・詳細解説

エフェメラル（一時的な）環境は、プルリクエストやフィーチャーブランチごとに自動生成され、検証完了後に自動破棄される使い捨ての環境であり、本番に近い条件でのテストとリソースコストの最適化を両立できる。

正解: A. A. GKE Enterpriseのフリート管理機能を使い、複数クラスタのポリシー・構成・セキュリティを一元的に統制する

正解の根拠・詳細解説

GKE Enterprise（旧Anthos）のフリート管理機能は、複数のGKEクラスタ（オンプレミス・マルチクラウドを含む）をグループ化し、構成管理・ポリシー適用・セキュリティをまとめて一元統制できる。

正解: A. A. ノードプールのアップグレード設定（サロゲート、Blue/Greenアップグレード等）とメンテナンスウィンドウを活用し、段階的にアップグレードする

正解の根拠・詳細解説

GKEはノードプールごとのアップグレード戦略（サロゲートアップグレード、Blue/Greenアップグレード）とメンテナンスウィンドウの設定により、ワークロードへの影響を最小化しながら段階的に安全にパッチ・バージョンアップグレードを適用できる。

正解: A. A. Cloud Workstationsはカスタマイズ可能な永続的なクラウド開発環境を提供し、Cloud Shellは一時的な軽量シェル環境を提供する

正解の根拠・詳細解説

Cloud Workstationsはカスタムイメージ・IDE統合・永続ディスクを備えたフルマネージドの開発環境を提供し、組織全体の標準化された開発環境構築に向く。Cloud Shellはブラウザから即座に使える軽量な一時シェル環境で、簡易な操作・デバッグに向く。

正解: A. A. AIによるコード補完・レビュー支援・トラブルシューティング支援により開発者の生産性を高める

正解の根拠・詳細解説

Gemini Code Assist（旧Duet AI for Developers）はIDEやCloud Shell等に統合され、AIによるコード補完・コードレビューの支援・エラーのトラブルシューティング支援を提供し、開発者の生産性向上に寄与する。

正解: A. A. コマンドラインからのリソース操作・スクリプト自動化を一貫した方法で行え、IaCツールやCI/CDパイプラインとの統合も容易になる

正解の根拠・詳細解説

Cloud SDK は gcloud、gsutil、bq といったコマンドラインツール群の総称であり、チーム全体で同じツールと同じ構成プロファイルを使うことに大きな意味があります。コンソールでのGUI操作は手順が個人の記憶に依存して再現性がありませんが、gcloud のコマンドはそのままシェルスクリプトに書き起こせ、Cloud Build や Jenkins などのCI/CDパイプラインのステップとしてそのまま実行できます。また gcloud config configurations を使えば開発・検証・本番のプロジェクトや認証情報を切り替えられるため、環境を取り違えた操作ミスを防げます。サービスアカウントやWorkload Identity連携による非対話認証にも対応しており、自動化との相性が良い点も標準化の理由です。なお Cloud SDK はコンソールの代替にならない限定的なツールではなく、主要なサービスのAPIを幅広く網羅しており、コンソールでできる操作の大半はCLIからも実行できます。

正解: A. A. コンテナイメージ・言語パッケージを一元管理し、脆弱性スキャンとIAMによるアクセス制御を組み合わせる

正解の根拠・詳細解説

Artifact Registryはコンテナイメージ・Maven・npm等の言語パッケージを一元的に管理できるサービスで、脆弱性スキャン機能とIAMによる細かいアクセス制御を組み合わせることで、安全なソフトウェアサプライチェーンを構築できる。

正解: A. A. オンプレミスや他クラウドのKubernetesクラスタを含めて統一的なデプロイ・ポリシー管理が可能になる

正解の根拠・詳細解説

GKE Enterprise（旧Anthos）はGoogle Cloudだけでなくオンプレミスや他クラウド上のKubernetesクラスタも含めてフリートとして統一管理でき、一貫したデプロイ・ポリシー適用をハイブリッド/マルチクラウド環境全体で実現する。

正解: A. A. プルリクエスト時はテスト・検証のみを実行し、マージ後のpushで本番デプロイまで進めるなど、リスクに応じた処理を分離できる

正解の根拠・詳細解説

プルリクエスト時のトリガーでは自動テストや静的解析のみを実行し、本番ブランチへのマージ・pushをトリガーとして本番デプロイまで進める、というようにイベントの種類に応じてリスクの異なる処理を分離するのが一般的なベストプラクティス。

正解: A. A. カナリアデプロイ（一部のトラフィックを新バージョンに振り分けて検証する）

正解の根拠・詳細解説

カナリアデプロイは新バージョンに本番トラフィックの一部（例: 5%）を振り分けて実際のユーザートラフィックで動作確認を行い、問題がなければ徐々に比率を増やしていく、リスクを抑えた検証手法。

正解: A. A. 本番環境への影響が大きい変更について、デプロイ前に人間の確認・承認を必須とし誤った変更の適用を防ぐ

正解の根拠・詳細解説

承認フロー（manual approval gate）は、本番環境のような影響範囲が大きい環境へのデプロイ前に、責任者の人間による確認・承認を必須にすることで、意図しない変更やリスクの高い変更の本番適用を防ぐガードレールとして機能する。

正解: A. A. コンテナイメージのビルド・テスト後、トラフィック分割機能を使って新リビジョンへの段階的な移行を行える

正解の根拠・詳細解説

Cloud Runはリビジョン単位でデプロイされ、トラフィック分割機能により新旧リビジョン間でトラフィックの比率を段階的に調整できるため、CI/CDパイプラインにカナリアデプロイ等の戦略を組み込みやすい。

正解: A. A. インフラの変更もアプリケーションコードと同様にバージョン管理し、パイプラインを通じてテスト・デプロイする「GitOps」的アプローチを取る

正解の根拠・詳細解説

GitOpsの考え方では、インフラの構成（Terraform、Kubernetesマニフェスト等）もコードとしてGitで管理し、CI/CDパイプラインを通じてレビュー・テスト・デプロイを行うことで、アプリケーションと同様の品質保証プロセスをインフラにも適用できる。

正解: A. A. 誰が・いつ・何をデプロイしたかを追跡可能にし、問題発生時の原因調査やコンプライアンス要件に対応する

正解の根拠・詳細解説

Cloud Audit Logsはデプロイ操作を含むGoogle Cloudリソースへのすべての管理アクティビティを記録し、デプロイの「誰が・いつ・何を」を追跡可能にすることで、障害調査やコンプライアンス対応の重要な証跡となる。

正解: A. A. 新バージョン（Green）を旧バージョン（Blue）と並行して用意し、準備が整った時点でトラフィックを一括切り替えることで、即時ロールバックも容易にする

正解の根拠・詳細解説

Blue/Greenデプロイは新旧バージョンの環境を並行して稼働させ、検証完了後にトラフィックを一括で新環境（Green）に切り替える手法。問題発生時は旧環境（Blue）に即座に戻せるため、ロールバックが容易という特徴がある。

正解: A. A. 事前に定義したロールバック手順（前バージョンへの即時切り替え等）を自動化し、エラーバジェットの異常を検知したら速やかに実行する

正解の根拠・詳細解説

エラー率の急増等の異常を検知した際は、事前に定義・テスト済みのロールバック手順を自動化しておき、迅速に前バージョンへ切り替えることで、ユーザー影響を最小化できる。手順を都度考えるのではなく事前準備が重要。

正解: A. A. ビルドアーティファクトの署名やデータの暗号化に使う鍵を安全に管理する

正解の根拠・詳細解説

Cloud KMSは暗号鍵のライフサイクル管理（生成・ローテーション・破棄）を行うサービスで、CI/CDパイプラインではビルドアーティファクトの署名鍵や、保管データ・シークレットの暗号化に使う鍵の管理に活用される。

正解: A. A. シークレットをコードやログに平文で残さず、IAMベースのアクセス制御とバージョン管理付きで安全に保管・取得できる

正解の根拠・詳細解説

Secret Managerはシークレットをコードやリポジトリに直接埋め込むことなく、IAMで制御されたアクセス権限とバージョン履歴付きで安全に保管・取得できるサービスで、CI/CDパイプラインでのシークレット管理の標準的な選択肢。

正解: A. A. ビルド時挿入はイメージに焼き込むリスクがあるため非推奨とされやすく、ランタイム時挿入（環境変数やマウントされたシークレット）の方が安全性が高いとされる

正解の根拠・詳細解説

ビルド時にシークレットをコンテナイメージに焼き込むと、イメージそのものが漏洩した場合にシークレットも漏洩するリスクがある。ランタイム時に環境変数やマウントボリュームとしてシークレットを注入する方が、イメージ自体には機密情報が残らず安全性が高い。

正解: A. A. コンテナイメージ内の既知の脆弱性（CVE）を自動的にスキャンし、デプロイ前に検出する

正解の根拠・詳細解説

Artifact Registryと連携するContainer Analysisは、コンテナイメージ内のOSパッケージやライブラリの既知の脆弱性（CVE）を自動スキャンし、デプロイパイプラインの早い段階でセキュリティリスクを検出できる。

正解: A. A. 事前に定義した信頼できるポリシー（署名済みアーティファクトのみ等）に合致しないコンテナイメージのデプロイをGKE等でブロックする

正解の根拠・詳細解説

Binary Authorizationは、信頼できるビルドプロセス（特定のCI/CDパイプラインの署名等）を経て検証されたイメージのみのデプロイを許可するポリシーをGKE等に適用し、未承認・未検証のイメージのデプロイをブロックするセキュリティ機構。

正解: A. A. ソフトウェアサプライチェーンの完全性（ビルドプロセスの来歴・改ざん防止等）を段階的なレベルで評価・向上させる業界標準フレームワーク

正解の根拠・詳細解説

SLSAはソフトウェアサプライチェーンセキュリティの成熟度を段階的なレベル（Level 1〜4等）で評価する業界標準フレームワークで、ビルドの来歴（provenance）の検証や改ざん防止等を通じてサプライチェーン全体の完全性を高める指針となる。

正解: A. A. 開発環境とは異なる、より厳格なIAM権限を本番環境に適用し、最小権限の原則を環境ごとに徹底する

正解の根拠・詳細解説

開発・ステージング・本番という環境ごとにIAMポリシーを分離し、本番環境ではより厳格な最小権限を適用することで、誤操作や意図しない変更のリスクを環境特性に応じて適切に管理できる。

正解: A. A. バージョンタグ（v1.2.0等）のpushをトリガーに本番リリース用のビルド・デプロイを実行する

正解の根拠・詳細解説

セマンティックバージョニングに基づくGitタグ（v1.2.0等）のpushをトリガーとすることで、明示的なリリースバージョンに対応した本番デプロイパイプラインを実行する設計は、リリース管理の一般的なパターン。

正解: A. A. インスタンスやポッドを段階的に新バージョンへ入れ替えていくため、追加リソースを最小化しつつ漸進的に展開できる

正解の根拠・詳細解説

ローリングデプロイは既存インスタンス・ポッドを段階的に新バージョンへ入れ替えていく方式で、Blue/Greenのように倍のリソースを用意する必要がなくコスト効率が良いが、入れ替え中は新旧バージョンが混在する点に注意が必要。

正解: A. A. 人間の介入を待たずに迅速に異常を検知し被害範囲を最小化できる

正解の根拠・詳細解説

SLI/SLOの異常値（エラー率上昇等）を検知して自動的にトラフィックを旧バージョンに戻す仕組みを構築することで、人間が気づくまでの時間差を排除し、インシデントの影響範囲と時間を最小化できる。

正解: A. A. 依存関係の不整合・テストの失敗・権限不足によるリソースアクセスエラー

正解の根拠・詳細解説

ビルド失敗の典型的な原因には、ライブラリ/パッケージの依存関係の不整合、自動テストの失敗、サービスアカウントの権限不足によるリソース（Artifact Registry等）へのアクセスエラーなどがあり、ログを確認して原因を特定する。

正解: A. A. クラウド固有のAPIに依存しない抽象化レイヤー（Terraform、Kubernetesマニフェスト等）を使い、各クラウドのデプロイターゲットを切り替え可能にする

正解の根拠・詳細解説

Terraformのようなクラウド中立なIaCツールやKubernetesのような共通のオーケストレーション基盤を使うことで、AWS・Azure・GCP等のクラウド固有差異を抽象化し、統一的なCI/CDパイプラインでマルチクラウドデプロイを実現できる。

正解: A. A. 最小インスタンス数の設定や定期的なウォームアップリクエストにより、デプロイ後の初回応答レイテンシを低減する

正解の根拠・詳細解説

Cloud Run等のサーバーレス環境では、リクエストがない期間の後の初回起動（コールドスタート）でレイテンシが発生する。最小インスタンス数の設定や定期的なヘルスチェック/ウォームアップにより、デプロイ直後やトラフィックの少ない時間帯の応答性を改善できる。

正解: A. A. Cloud Audit Logsの管理アクティビティログに記録される承認操作のエントリ

正解の根拠・詳細解説

Cloud Deployの承認プロセスを含む管理操作は、Cloud Audit Logsの管理アクティビティログに「誰が」「いつ」「何を承認したか」が記録され、これを参照することで承認の追跡・コンプライアンス対応が可能になる。

正解: A. A. 古い・不要なイメージバージョンを自動削除し、ストレージコストを最適化する

正解の根拠・詳細解説

Artifact Registryのクリーンアップポリシー（リテンションポリシー）は、一定期間を超えた古いイメージバージョンや未使用のタグを自動削除する設定で、無制限に蓄積するストレージコストを最適化する。

正解: A. A. ビルド環境専用の最小権限サービスアカウントを使い、ビルドごとに分離された一時的な実行環境を利用する

正解の根拠・詳細解説

ビルド環境には専用の最小権限サービスアカウントを割り当て、Cloud Build等が提供する一時的・分離された実行環境（ビルドごとに使い捨て）を利用することで、ビルドプロセスを通じた権限昇格や情報漏洩のリスクを低減できる。

正解: A. A. 同一のビルドアーティファクトを環境ごとの設定（環境変数、ConfigMap等）と組み合わせて再利用でき、環境差異によるビルドのやり直しを防げる

正解の根拠・詳細解説

「Build once, deploy many」の原則に基づき、ビルドされたアーティファクト（コンテナイメージ等）は変更せず、環境ごとの設定（ConfigMap、環境変数、Secret等）を外部化して注入することで、環境差異に起因する再ビルドの手間とリスクを排除できる。

正解: A. A. dev・staging・productionなど、デプロイ先となる環境（クラスタやCloud Runサービス等）を明示的に管理する

正解の根拠・詳細解説

Cloud Deployのデリバリーパイプラインでは「ターゲット」としてdev・staging・production等の各デプロイ先環境（GKEクラスタ、Cloud Runサービス等）を定義し、パイプラインのステージごとに順序立ててプロモーション（昇格）させていく構造を取る。

正解: A. A. latestタグは可変であり、どのビルドが実際にデプロイされたかの追跡可能性（traceability）が損なわれる

正解の根拠・詳細解説

「latest」のような可変タグは常に最新のイメージを指すため上書きされ、どのバージョン・コミットがデプロイされているかの追跡可能性が損なわれる。コミットハッシュやセマンティックバージョンなど不変（immutable）なタグの使用が推奨される。

正解: A. A. コードのデプロイとフィーチャーの有効化を分離し、デプロイ後にリスクを抑えながら機能を段階的に有効化できる

正解の根拠・詳細解説

フィーチャーフラグを使うことで、コードのデプロイ（リリース）と機能の有効化（フィーチャーリリース）を分離でき、デプロイ後に問題が見つかった場合もコードの再デプロイなしにフラグをオフにするだけで機能を無効化できるため、リスクを抑えた段階的な機能展開が可能になる。

正解: A. A. 最大サロゲート数・最小稼働インスタンス数を設定し、可用性を保ちながら段階的に新しいインスタンステンプレートに更新する

正解の根拠・詳細解説

MIGのローリングアップデートでは、同時に更新する最大サロゲート数（maxSurge）と最小稼働インスタンス数（maxUnavailable）を設定することで、サービス可用性を維持しながら段階的に新しいインスタンステンプレートへ移行できる。

正解: A. A. プルリクエストのレビュー必須化・承認ゲート・Cloud Audit Logsによる証跡記録を組み合わせる

正解の根拠・詳細解説

変更管理やコンプライアンス監査が求めるのは「誰が、何を、いつ、誰の承認を得て本番に反映したか」を後から証明できることです。これは自動化の放棄ではなく、パイプラインの中に統制点を埋め込むことで満たせます。具体的には、ブランチ保護ルールでプルリクエストのレビュー承認を必須にして単独マージを防ぎ、本番デプロイの直前に承認ゲートを置いて責任者の明示的な承認を必要とし、Cloud Audit Logs で誰がどのリソースをいつ変更したかの証跡を残す、という組み合わせです。手作業の紙の記録に頼る方法は記録漏れや後追いの改ざんに弱く、証跡としての信頼性はむしろ下がります。すべての変更が同じ経路を必ず通る自動化されたパイプラインのほうが、監査時に一貫した証拠を提示しやすくなります。

正解: A. A. 可用性やレイテンシなど、サービスのパフォーマンスを測定する具体的な指標

正解の根拠・詳細解説

SLI（サービスレベル指標）は可用性・レイテンシ・エラー率など、サービスの健全性を定量的に測定する具体的な指標であり、SLO（目標値）やSLA（合意）の基礎となる測定対象。

正解: A. A. SLOで許容される失敗の余地（100%-SLO）を「予算」として捉え、その範囲内でリスクを取った新機能のリリースや変更を許容する

正解の根拠・詳細解説

エラーバジェットは「SLOで許容される失敗の余地」を予算として捉える考え方で、SLO 99.9%なら0.1%の「失敗の予算」があり、この予算内であれば新機能リリースのリスクを取ることを正当化し、予算を使い果たした場合はリリースを止めて安定性を優先する、という意思決定の指針になる。

正解: A. A. 可用性の桁を1つ上げるごとに必要なエンジニアリングコストは指数関数的に増加する傾向があり、目標設定はビジネス価値とのバランスで決定すべき

正解の根拠・詳細解説

可用性を99.9%から99.99%、99.999%へと桁を上げるには、冗長化・自動化・運用体制への投資が指数関数的に増加する傾向がある。SREの実践では、過剰な信頼性目標がイノベーションの速度を阻害する機会費用を考慮し、ビジネス要件に見合った適切なSLOを設定することが重視される。

正解: A. A. SLI/SLOの定義・モニタリング設定・オンコール体制・ランブックの整備状況の確認

正解の根拠・詳細解説

SREのサービスオンボーディングチェックリストには、SLI/SLOの定義、モニタリング・アラートの設定、オンコール対応体制の確立、インシデント対応のランブック整備など、サービスを安定的に運用するための前提条件が含まれる。

正解: A. A. 依存関係のあるサービス・クライアントを事前に特定し、移行期間と通知を十分に確保してから段階的に廃止する

正解の根拠・詳細解説

サービスの提供終了（デコミッション）では、他のサービスやクライアントとの依存関係を事前に調査し、十分な移行期間と関係者への通知を行った上で、トラフィックを段階的に減らしながら安全に廃止することが、予期しない障害を防ぐSREの実践。

正解: A. A. 需要の急増時にGoogle Cloudのリソース割り当て上限に達してサービス拒否が発生するリスクを事前に防ぐため

正解の根拠・詳細解説

各種Google CloudリソースにはプロジェクトやリージョンごとのQuota（割り当て上限）が存在し、需要急増時にこの上限に達すると新規リソースの作成やAPI呼び出しが拒否される可能性があるため、事前のキャパシティプランニングでQuotaの増加申請等を検討する必要がある。

正解: A. A. スケールアウトの判断指標としてCPU使用率以外（リクエストレイテンシ、キューの長さ等）も組み合わせ、サービス特性に合った指標を選ぶこと

正解の根拠・詳細解説

ワークロードの特性によってはCPU使用率がボトルネックを正確に反映しない場合があるため、リクエストレイテンシ・キューの長さ・カスタム指標など、サービスの実際の負荷特性に合った指標を組み合わせてスケーリングポリシーを設計することが推奨される。

正解: A. A. 予期しないトラフィック急増による過剰なコスト発生やバックエンドリソース（データベース等）への過負荷を防ぐ

正解の根拠・詳細解説

Cloud Runの最大インスタンス数を設定することで、予期しないトラフィック急増（DDoS等を含む）が発生した際の過剰なコンピューティングコストの発生や、バックエンドのデータベース等への接続過多による過負荷を防止できる。

正解: A. A. 問題のあるインスタンスやリージョンから新規トラフィックを切り離し、安全に切り離し作業やメンテナンスを行えるようにする

正解の根拠・詳細解説

トラフィックドレインは、問題のあるインスタンス・ゾーン・リージョンへの新規トラフィックのルーティングを停止し、既存の接続は完了させつつ新規リクエストを健全なリソースに振り向ける手法で、メンテナンスやインシデント対応時に安全な切り離しを実現する。

正解: A. A. 突発的なトラフィック増加によるリソース不足が原因で、追加のインスタンスやノードをスケールアウトすることで負荷を分散できる場合

正解の根拠・詳細解説

リソース不足（CPU・メモリ・接続数の枯渇等）が原因のインシデントでは、追加のインスタンスやノードをスケールアウトすることで負荷を分散し、ユーザー影響を緩和できる。一方、ソフトウェアバグが原因の障害には容量追加は効果がなく、コードの修正やロールバックが必要。

正解: A. A. リリースのタイミング・ロールバック手順・モニタリング体制・関係者への事前通知を含めた計画を立てる

正解の根拠・詳細解説

SREの観点からのリリース計画では、リリースタイミング（トラフィックの少ない時間帯等）、問題発生時のロールバック手順、モニタリング・アラート体制の事前準備、関係者（サポートチーム等）への通知を含めた包括的な計画が重要視される。

正解: A. A. 新機能のリリースを一時停止し、信頼性向上のための作業（バグ修正・インフラ改善等）を優先する

正解の根拠・詳細解説

エラーバジェットを使い果たした場合、SREのプラクティスでは新機能のリリースを一時的に止め、信頼性の回復（バグ修正・パフォーマンス改善・インフラの安定化）を優先するという明確なポリシーを適用することで、開発速度と信頼性のバランスを保つ。

正解: A. A. HPAはポッド数をワークロードの負荷に応じてスケールし、Cluster Autoscalerはノード数をポッドのスケジューリング要求に応じてスケールする

正解の根拠・詳細解説

HPA（Horizontal Pod Autoscaler）はCPU使用率等のメトリクスに基づきポッドのレプリカ数をスケールし、Cluster Autoscalerはスケジュールできないポッドが発生した際にノードプールのノード数を自動的に増減させる。両者は異なるレイヤーで連携して動作する。

正解: A. A. 顧客への契約上のペナルティ（サービスクレジット等）が発生する可能性がある

正解の根拠・詳細解説

SLA（Service Level Agreement）は顧客との契約であり、違反した場合は契約上のペナルティ（サービスクレジットの提供や返金等）が発生する可能性がある。SLOは内部目標であり、通常SLAよりも厳しく設定される。

正解: A. A. エラーバジェットを共通言語として、開発チームとSREチームが変更のリスクと信頼性目標について合意形成する

正解の根拠・詳細解説

SREの中核的な考え方は、エラーバジェットという共通言語を用いて開発チームとSREチームが「どれだけのリスクを取って良いか」について定量的に合意形成することで、変更速度（イノベーション）と信頼性のバランスを継続的に調整していくことにある。

正解: A. A. 過去のトラフィックデータを分析し、ピーク期間に向けた事前のスケールアップ計画とロードテストを実施する

正解の根拠・詳細解説

過去のトラフィックデータ（前年の同時期等）を分析してピーク時の負荷を予測し、事前のキャパシティ確保（インスタンスの事前プロビジョニング等）とロードテストを実施することで、セール期間等の急激なトラフィック増加に備えるのがSREのベストプラクティス。

正解: A. A. 手動で繰り返し発生する運用作業で、長期的な価値を生まず自動化すべき対象とされる

正解の根拠・詳細解説

トイル（Toil）は、手動・繰り返し的・自動化可能でありながら長期的な工学的価値を生まない運用作業を指すSRE用語であり、SREの実践では一定割合以下にトイルを抑え、自動化への投資にエンジニアリング時間を充てることが推奨される。

正解: A. A. 個人を責めることなくシステムやプロセスの構造的な問題を特定し、再発防止策に集中できる文化を作る

正解の根拠・詳細解説

Blameless Postmortemは、個人の過失を責めることを避け、システム・プロセス・ツールの構造的な問題に焦点を当てることで、エンジニアが率直に失敗を共有し、組織全体で学習し再発防止につなげる文化を醸成することを目的とする。

正解: A. A. エラー率・レイテンシ・SLI関連指標の異常を継続的に監視し、しきい値を超えたら自動または手動で停止する

正解の根拠・詳細解説

段階的ロールアウト（カナリア展開等）では、各段階でエラー率・レイテンシ・SLI関連の指標を継続的に監視し、異常を検知した場合は自動または手動でロールアウトを停止・ロールバックする仕組みを組み込むことが、安全な変更管理の基本。

正解: A. A. アラート疲れ（Alert Fatigue）を防ぐため、誤検知の少ない有意義なアラートのみをオンコール担当者に通知する

正解の根拠・詳細解説

過剰な誤検知アラートはオンコール担当者の疲弊（アラート疲れ）を招き、本当に重要なアラートへの反応が鈍る原因になる。SLI/SLOに基づく有意義でアクション可能なアラートのみを通知するよう設計し、ローテーションで負荷を分散することが重要。

正解: A. A. 技術的な指標をエラーバジェットの消費率等のビジネスにも理解しやすい形に変換して共有する

正解の根拠・詳細解説

SLOの達成状況やエラーバジェットの消費率を、ビジネス側にも理解しやすい形（残り予算の割合、リリース可否への影響等）で定期的にレポートすることで、技術的な信頼性目標とビジネス上の意思決定（新機能投資の判断等）を連携させられる。

正解: A. A. 過去のパターンに基づきリソースを事前にスケールアップすることで、急激な負荷増加時のレイテンシ悪化を防げる

正解の根拠・詳細解説

予測スケーリングは過去のメトリクスパターンを学習し、負荷が増加する前にリソースを事前にスケールアップすることで、リアクティブなスケーリング（負荷増加後に反応）で発生しがちな一時的なレイテンシ悪化やリクエスト失敗を防止できる。

正解: A. A. 障害の影響範囲（ブラストレディウス）を事前に把握し、インシデント対応や変更管理のリスク評価に活用する

正解の根拠・詳細解説

サービス間の依存関係を可視化することで、ある障害が他のどのサービスに影響を及ぼすか（ブラストレディウス）を事前に把握でき、インシデント対応の優先順位付けや、変更時のリスク評価に活用できる重要な運用情報となる。

正解: A. A. 意図的に障害を注入してシステムの耐障害性を本番に近い条件で検証し、想定外の弱点を事前に発見する

正解の根拠・詳細解説

カオスエンジニアリングは、意図的かつ制御された形で障害（インスタンス停止、レイテンシ注入等）をシステムに与え、本番に近い条件下での耐障害性・復旧能力を検証する手法で、想定していなかった弱点や依存関係を事前に発見するのに有効。

正解: A. A. 意図しない無制限のリソース消費（コスト超過や障害の連鎖）を防ぐためのセーフガードとして機能する

正解の根拠・詳細解説

リソースの上限（最大インスタンス数、API呼び出しレート制限等）を設定することで、予期しないバグやトラフィック急増による無制限のリソース消費・コスト超過・カスケード障害（連鎖的な障害の拡大）を防ぐセーフガードとして機能する。

正解: A. A. 過剰に高い信頼性目標を設定すると、開発速度の低下という別の形のコストが発生することを認識し、ビジネス要件に見合ったSLOを設定する

正解の根拠・詳細解説

99.999%のような過剰に高い信頼性目標を追求すると、それを実現するための工数が開発速度や新機能投資から奪われる「機会費用」が発生する。SREの実践では、ユーザーが実際に必要とする信頼性レベルを見極め、過剰投資を避けたSLO設定を行う。

正解: A. A. ユーザーへの影響を軽減すること（トラフィック制御・ロールバック等）を最優先し、根本原因の完全な特定は事後分析に委ねる

正解の根拠・詳細解説

インシデント対応の優先順位は、まずユーザーへの影響を軽減すること（トラフィックのリダイレクト、ロールバック、容量追加等の緩和策）であり、根本原因の完全な特定と詳細な分析はポストモーテム（事後分析）のフェーズで行うのがSREの標準的な対応順序。

正解: A. A. 個々のサービスのSLOの組み合わせがユーザー体感のエンドツーエンドの信頼性にどう影響するかを考慮し、依存関係の連鎖を踏まえて設計する

正解の根拠・詳細解説

マイクロサービス構成では、利用者が体感する信頼性は個々のサービスのSLOをそのまま写したものにはならず、依存関係の連鎖によって決まります。あるリクエストが3つのサービスを直列に経由する場合、それぞれが99.9%でも成功率は0.999の3乗、つまり約99.7%まで低下します。したがって「各サービスがSLOを守っていれば全体も守られる」という前提は成り立ちません。実務では、まず利用者体験に直結する重要な経路を特定し、エンドツーエンドの目標値を先に決めたうえで、各サービスに信頼性の予算を割り振る形で個別のSLOを逆算します。呼び出し回数が多いサービスや、多数のサービスから依存される共通基盤ほど、より高い目標が必要になります。逆に非同期でリトライが効く経路であれば、多少緩い目標でも体感を損ねません。

正解: A. A. VMやコンテナ上のログファイル・システムログをCloud Loggingに転送・集約する

正解の根拠・詳細解説

Cloud Loggingエージェント（Ops Agent）はGCEインスタンス等にインストールされ、アプリケーションログ・システムログ・メトリクスをCloud Loggingに自動的に転送・集約する役割を担う。

正解: A. A. VPCネットワーク内のトラフィックフロー（送信元/宛先IP、ポート等）を記録し、セキュリティ分析やトラブルシューティングに活用する

正解の根拠・詳細解説

VPCフローログはサブネット内の送受信トラフィック（5-tuple情報等）を記録し、不審な通信の検知・ネットワークトラブルシューティング・帯域使用状況の分析など、セキュリティとパフォーマンスの両面で活用される。

正解: A. A. 大量に発生する低優先度のログをすべて記録せず一部のみを保存することで、ストレージコストと処理負荷を削減する

正解の根拠・詳細解説

高頻度で発生するログ（デバッグログ等）をすべて記録するとコストと処理負荷が増大するため、サンプリング（一定割合のみ記録）を適用することで、必要な可視性を保ちつつコストを最適化できる。

正解: A. A. 長期保存とSQLによる柔度の高い分析・レポーティングが可能になる

正解の根拠・詳細解説

Cloud LoggingのログをBigQueryにエクスポートすることで、SQLクエリによる柔軟な分析・長期保存・他の構造化データとの結合分析、ダッシュボード（Looker Studio等）との連携など、監査やビジネス分析の幅が大きく広がる。

正解: A. A. コンプライアンス要件で定められた最低保持期間と、ストレージコストのバランス

正解の根拠・詳細解説

ログの保持期間は、業界・地域の規制（コンプライアンス要件）で定められた最低保持期間を満たしつつ、長期保存によるストレージコストの増加を抑えるバランスを考慮して設定する必要がある。

正解: A. A. Cloud Data Loss Prevention（DLP）等を使ってログ内の機密情報を検出・マスキング（編集）する

正解の根拠・詳細解説

Cloud DLP（Data Loss Prevention）等のサービスを使ってログ内の個人識別情報（PII）や保護医療情報（PHI）を自動検出し、マスキングや編集を行うことで、ログの分析・保存に伴うプライバシー・コンプライアンスリスクを低減できる。

正解: A. A. 既存のPrometheusベースの指標収集・クエリ（PromQL）をそのまま活用しつつ、マネージドなスケーラビリティと信頼性を得られる

正解の根拠・詳細解説

Google Cloud Managed Service for Prometheusは、オープンソースのPrometheusと互換性のあるPromQLクエリをそのまま使いながら、自己管理のPrometheusサーバーの運用負荷（スケーリング・可用性管理）をGoogleにオフロードできるマネージドサービス。

正解: A. A. 特定のエラーパターンの発生回数等、標準メトリクスでは取得できない業務固有の指標を数値化してモニタリング対象にする

正解の根拠・詳細解説

ログベースの指標は、ログメッセージ内の特定パターン（特定のエラーコードの出現回数等）を抽出してカスタムメトリクス化する機能で、標準のシステムメトリクスでは捉えられない業務固有・アプリケーション固有の指標をモニタリング・アラート対象にできる。

正解: A. A. 事前にダッシュボードを作成せずに、任意の指標とフィルタ条件を組み合わせて即座に可視化・調査できる

正解の根拠・詳細解説

Metrics ExplorerはCloud Monitoringの機能で、事前にダッシュボードを作成せずにその場で指標・フィルタ・集計方法を組み合わせて可視化できるため、インシデント調査時の迅速なアドホック分析に活用される。

正解: A. A. 実際のユーザートラフィックを使わずに定期的にエンドポイントへリクエストを送り、サービスの可用性・パフォーマンスを継続的に検証する

正解の根拠・詳細解説

合成モニター（アップタイムチェック等）は、実際のユーザートラフィックがない時間帯でも定期的に外形監視リクエストを送信し、サービスのエンドポイントが正常に応答しているか・レイテンシが許容範囲内かを継続的に検証する仕組み。

正解: A. A. ダッシュボードで異常を検知した際、対応すべき手順（ハンドブック/ランブック）に即座にアクセスでき、対応時間を短縮できる

正解の根拠・詳細解説

ダッシュボードから直接ランブック（ハンドブック）にリンクさせることで、異常を検知したオンコール担当者が次に取るべき対応手順に即座にアクセスできるようになり、インシデント対応の平均対応時間（MTTR）を短縮できる。

正解: A. A. ユーザー体感の信頼性に直結する指標に基づいてアラートを発火させることで、ノイズの多い些細な変動には反応しない有意義な通知にできる

正解の根拠・詳細解説

CPU使用率のような低レベルの指標だけでなく、SLI/SLOの消費率（エラーバジェットバーンレート等）に基づいてアラートを構成することで、ユーザー体感に直結する重要な異常のみを検知し、些細な変動による誤報（アラート疲れ）を減らせる。

正解: A. A. 予算のしきい値超過を早期に検知し、予期しないコスト超過への対応を迅速化する

正解の根拠・詳細解説

Cloud Billingの予算アラートを設定することで、月間予算のしきい値（50%・90%・100%等）に達した際に通知を受け取り、予期しないリソース消費やコスト超過を早期に検知して迅速に対応できる。

正解: A. A. 既存のインシデント管理・コミュニケーションワークフローにGoogle Cloudのアラートをシームレスに統合できる

正解の根拠・詳細解説

Cloud Monitoringの通知チャネル機能を使ってPagerDuty・Slack・Webhookなどのサードパーティツールと連携することで、既存のオンコール管理・チームコミュニケーションのワークフローにGoogle Cloudからのアラートをシームレスに統合できる。

正解: A. A. マイクロサービス間をまたがるリクエストの処理時間を可視化し、レイテンシのボトルネックとなっているサービスを特定する

正解の根拠・詳細解説

Cloud Traceは1つのリクエストが複数のマイクロサービスをまたいで処理される際の各サービスでの処理時間（スパン）を記録・可視化し、エンドツーエンドのレイテンシのうちどのサービスがボトルネックになっているかを特定するのに役立つ。

正解: A. A. OpenTelemetry等の標準的な計測ライブラリを使い、ログ・メトリクス・トレースを一貫した形式で収集する

正解の根拠・詳細解説

OpenTelemetry等の標準的なオブザーバビリティ計測ライブラリを使うことで、ベンダーロックインを避けつつログ・メトリクス・トレースを一貫した形式で収集でき、Cloud Trace・Cloud Monitoring等のバックエンドとの統合も容易になる。

正解: A. A. アプリケーションのエラー・例外を自動的に集約・グルーピングし、頻発するエラーパターンを優先的に把握できる

正解の根拠・詳細解説

Error Reportingはアプリケーションログ内の例外・スタックトレースを自動的に検出・グルーピングし、似たエラーをまとめて発生頻度・影響範囲を可視化するため、優先的に対応すべきエラーパターンを効率的に特定できる。

正解: A. A. 重要度の低いログのサンプリング・除外フィルタの設定、保持期間の見直しを組み合わせる

正解の根拠・詳細解説

オブザーバビリティ関連のコストは、重要度の低いログのサンプリングや除外フィルタの適用、必要以上に長い保持期間の見直し、メトリクスの収集頻度の調整などを組み合わせることで、可視性を維持しながら最適化できる。

正解: A. A. エラー率・レイテンシの推移グラフと、関連するログ・トレース情報を時系列で照合する

正解の根拠・詳細解説

パフォーマンス問題の調査では、まずダッシュボードでエラー率・レイテンシの推移を確認し、異常が発生した時間帯のログ・トレース情報を時系列で照合することで、問題発生の根本原因（特定のサービス、クエリ、デプロイ等）を効率的に特定できる。

正解: A. A. サービスメッシュのプロキシ層でトラフィックのメトリクス・ログ・トレースを自動収集し、アプリケーションコードの変更なしに可視性を得られる

正解の根拠・詳細解説

Cloud Service Mesh（Istio等ベース）はサイドカープロキシを通過するすべてのサービス間通信のメトリクス・アクセスログ・分散トレースを自動的に収集できるため、アプリケーションコード自体を変更せずにマイクロサービス間通信の可視性を獲得できる。

正解: A. A. JSON等の構造化形式でログを出力することで、フィールド単位でのフィルタリング・集計・分析が容易になる

正解の根拠・詳細解説

構造化ログ（JSON形式等）を採用することで、Cloud Logging上でフィールド単位の検索・フィルタリング・集計が容易になり、ログベースの指標作成やBigQueryでの分析時にも構造化されたデータとして効率的に扱える。

正解: A. A. 各環境のエージェントやOpenTelemetry Collectorを統一的に構成し、中央集約された監視基盤（Cloud Monitoring等）にデータを集める

正解の根拠・詳細解説

ハイブリッド/マルチクラウド環境では、各環境にOpenTelemetry Collector等の統一的なエージェントを配置し、収集した指標を中央の監視基盤（Cloud Monitoring等）に集約することで、環境をまたいだ一貫性のある可視性を確保できる。

正解: A. A. ログをリアルタイムで他のシステム（外部SIEM、カスタム処理パイプライン等）にストリーミング連携する場合

正解の根拠・詳細解説

Cloud LoggingからPub/Subへのログシンク設定は、ログをリアルタイムでストリーミングし、外部のSIEM（セキュリティ情報イベント管理）システムやカスタムのストリーム処理パイプラインに連携する際の典型的な構成パターンである。

正解: A. A. ダッシュボードの閲覧権限を必要なチーム・個人に限定し、機密性の高いメトリクスへの不要なアクセスを防ぐ

正解の根拠・詳細解説

Cloud Monitoring のダッシュボードそのものがGoogle CloudのリソースとしてIAMの対象になります。ダッシュボードには課金額の推移、エラー率、内部エンドポイント名、認証失敗の傾向など、社外はもちろん社内でも公開範囲を絞りたい情報が並ぶことがあります。そのため monitoring.viewer や monitoring.editor といったロールを必要なチーム・担当者に限定して付与し、閲覧と編集の権限を分けるのが基本です。組織全体へ無条件に公開すると、機密性の高い指標が意図しない相手に渡るだけでなく、誤ってダッシュボードを編集・削除される事故も起こりやすくなります。一方で権限を絞りすぎると障害対応時に必要な人が見られず復旧が遅れるため、オンコール担当者へ確実に閲覧権限が届くよう、個人単位ではなくGoogleグループ単位で付与する運用が現実的です。

正解: A. A. 直近のデプロイ・構成変更の履歴を確認し、レイテンシ増加のタイミングと相関がないか調査する

正解の根拠・詳細解説

パフォーマンス障害のトラブルシューティングでは、まず直近のデプロイやインフラ構成変更の履歴を確認し、問題発生のタイミングとの相関を調査することが、迅速な原因特定（多くの障害は変更に起因する）への近道となる。

正解: A. A. パイプラインの実行ログ・サービスアカウントの権限・依存ライブラリのバージョン変更

正解の根拠・詳細解説

CI/CDパイプラインの失敗調査では、実行ログでエラーメッセージを確認し、サービスアカウントの権限変更や依存ライブラリのバージョン更新等、直近の変更がパイプラインに影響していないかを確認するのが基本的な手順。

正解: A. A. モニタリングエージェントの稼働状況・ネットワーク接続・APIのQuota制限

正解の根拠・詳細解説

メトリクスのデータギャップは、モニタリングエージェントのクラッシュやネットワーク接続の問題、Cloud Monitoring APIのQuota制限への到達などが原因で発生することがあり、これらの要素を確認することで欠落の原因を特定できる。

正解: A. A. そのリージョン特有のネットワークレイテンシ・リソース割り当て・依存サービスの配置状況

正解の根拠・詳細解説

特定リージョンに限定された問題は、そのリージョンと依存サービス（データベース等）間のネットワークレイテンシ、リージョン固有のリソース割り当て状況、マルチリージョン構成における設定の差異などを確認することで原因を特定できる。

正解: A. A. 大幅な値引きで利用できるが、Googleの需要により最大30秒前の通知で強制終了される可能性があるため、フォールトトレラントなワークロードに適する

正解の根拠・詳細解説

Spot VMは通常のオンデマンド料金より大幅に安いが、Google Cloudの容量需要によって最大30秒前の通知で強制終了（プリエンプト）される可能性があるため、バッチ処理やステートレスなワークロード等、中断に耐えられるフォールトトレラントな用途に適している。

正解: A. A. 確約利用割引は1年または3年の利用を事前に確約することで大きな割引を得られ、継続利用割引は特定のインスタンスタイプの月間利用率に応じて自動的に適用される

正解の根拠・詳細解説

確約利用割引（CUD）は1年・3年の利用量を事前に確約することで適用される割引で、継続利用割引（SUD）は特定のマシンタイプを月間で継続して利用した割合に応じ事前のコミットメントなしに自動的に適用される割引である（Compute Engineの一部リソースに適用）。

正解: A. A. プレミアムティアはGoogleのグローバルネットワークを経由し低レイテンシだがコストが高く、スタンダードティアは公共インターネット経由でコストが低いがレイテンシが高くなる傾向がある

正解の根拠・詳細解説

プレミアムティアはGoogleの専用グローバルバックボーンネットワークを経由するため低レイテンシ・高品質だがコストが高く、スタンダードティアは一般的な公共インターネット経由でコストは抑えられるが、経路によってレイテンシが変動しやすい。

正解: A. A. コスト・セキュリティ・パフォーマンス・管理性・信頼性の観点から、リソース構成の改善提案を自動的に受け取れる

正解の根拠・詳細解説

Google Cloud Recommenderは、過大プロビジョニングされたVMのダウンサイズ提案、未使用IAM権限の削除提案、IPアドレスの解放提案など、コスト・セキュリティ・パフォーマンス・管理性・信頼性の複数の観点から自動的に改善提案を生成し、リソース最適化を支援する。

正解: A. A. ノードのCPU/メモリ使用率・ディスクI/O・ネットワークスループットの異常な変化

正解の根拠・詳細解説

インフラストラクチャ起因のパフォーマンス低下を調査する際は、該当するノード・インスタンスのCPU使用率・メモリ使用率・ディスクI/O・ネットワークスループットなどのリソース指標を確認し、リソース枯渇やハードウェア起因の異常がないかを特定する。

正解: A. A. 時間経過とともにメモリ使用率が一方的に増加し続け、最終的にOOM（メモリ不足）でプロセスが再起動するパターン

正解の根拠・詳細解説

メモリリークは典型的に、ガベージコレクション等で解放されるべきメモリが解放されず時間経過とともにメモリ使用率が一方的に増加し続け、最終的にOOM（Out of Memory）でプロセスが強制終了・再起動されるという特徴的なパターンを示す。

正解: A. A. デプロイ先のターゲット環境への権限・ネットワーク接続・リソースのQuota制限

正解の根拠・詳細解説

テストが成功してもデプロイが失敗する場合、デプロイ先のターゲット環境（GKEクラスタ、Cloud Run等）へのアクセス権限不足、ネットワーク接続の問題、リソースのQuota制限超過など、デプロイプロセス特有の問題を確認する必要がある。

正解: A. A. モニタリングエージェントのバージョン・稼働状況、Cloud Monitoring APIのレイテンシ・エラー率を確認する

正解の根拠・詳細解説

オブザーバビリティツール自体に問題が疑われる場合は、まずモニタリングエージェントのバージョンや稼働状況を確認し、Cloud Monitoring/Logging APIの応答レイテンシやエラー率を調査することで、データ収集経路のどこに問題があるかを特定する。

正解: A. A. バッチ処理やバックアップ等のスケジュールされたジョブが、その時間帯にリソースを競合させている可能性

正解の根拠・詳細解説

特定の時間帯に集中するパフォーマンス低下は、夜間バッチ処理・定期バックアップ・cronジョブ等のスケジュールされたタスクが同時間帯にCPU・I/O・ネットワークリソースを競合させていることが原因である場合が多く、スケジュールの見直しや時間帯の分散が対策となる。

正解: A. A. 使用されていない静的IPアドレスにも課金が発生するため、不要なコストを削減できる

正解の根拠・詳細解説

Google Cloudでは、インスタンスにアタッチされていない予約済み（未使用）の静的外部IPアドレスに対して課金が発生するため、Recommenderの提案等を活用して定期的に未使用IPアドレスを確認・解放することがコスト最適化に直結する。

正解: A. A. 平均値だけでは見えない、一部のユーザーが体感する極端に遅いケース（テールレイテンシ）を可視化できる

正解の根拠・詳細解説

平均レイテンシだけでは一部のユーザーが体感する極端に遅いリクエスト（テールレイテンシ）が隠れてしまうため、P95（95パーセンタイル）・P99（99パーセンタイル）等の指標を併用することで、大多数の体感に加えて「最も遅い数%」の状況も可視化し、ユーザー体験の全体像を把握できる。

正解: A. A. インスタンスの必要性を確認し、不要であれば停止・削除するか、必要であればより小さいマシンタイプへのダウンサイズを検討する

正解の根拠・詳細解説

Recommenderがアイドル状態（低いCPU/メモリ使用率が継続）のVMを検出した場合、まず業務上の必要性を確認し、不要であれば停止・削除、必要だが過剰スペックであればより小さいマシンタイプへのダウンサイズを検討することで、コストを最適化できる。

正解: A. A. 新しいコードに非効率なループやN+1クエリ等の性能上のリグレッション（劣化）が含まれている

正解の根拠・詳細解説

デプロイ直後から発生するCPU使用率の急上昇は、多くの場合新しいコードに含まれる性能上のリグレッション（非効率なアルゴリズム、N+1クエリ、無限ループに近い処理等）が原因であり、変更内容のコードレビューやプロファイリングで特定し、必要に応じてロールバックを行う。

正解: A. A. 業務時間外の不要なコンピューティングコストを削減できる

正解の根拠・詳細解説

Compute EngineのVMは稼働している時間に応じて課金されるため、誰も使っていない時間帯に起動したままにしておくと、その分がそのまま無駄なコストになる。開発・テスト環境は本番と違って利用が平日の業務時間帯に偏るのが一般的で、夜間と休日を停止すれば週168時間のうち稼働は50時間前後まで減り、コンピューティング費用を大幅に削減できる。実現手段としては、Compute Engineのインスタンススケジュール（リソースポリシー）で起動・停止の時刻を設定する方法や、Cloud Schedulerから処理を定期起動して対象インスタンスを停止する方法がある。注意点として、VMを停止しても接続された永続ディスクや予約済みの静的外部IPアドレスには課金が続くため、削減効果を見積もる際は主にvCPUとメモリ分が対象になると理解しておく必要がある。また停止中はそのVMが外部から攻撃を受ける余地がなくなるため、自動停止がセキュリティリスクを高めるという説明は成り立たない。本番環境と異なり常時稼働が前提ではない環境を見極めることが、コスト最適化の第一歩となる。