Section 3:
Ensuring the Successful Operation of a Cloud Solution
試験配点 ~30%(最重量セクション)。Compute Engine・GKE・Cloud Run・Storage・Networking・Monitoring/Logging の日常運用を中級〜上級者向けに完全解説。試験ガイド 063026(2026年6月30日改訂版)準拠。
📊 Section 3 — サブセクション別 出題比重(試験ガイド 063026 準拠)
3.1 コンピューティングリソースの管理
Compute Engine・GKE・Cloud Run の日常運用 — 接続・スナップショット・スケール・デプロイ管理
| 接続方法 | 外部 IP | セキュリティ | 推奨場面 |
|---|---|---|---|
| IAP トンネル SSH | 不要 | 🔒 最高 | 本番環境・外部 IP なし VM |
| OS Login + IAP | 不要 | 🔒 最高 | 組織管理環境・SSH 鍵一元管理 |
| gcloud SSH(直接) | 必要 | 🔓 中 | 開発・検証環境 |
| Cloud Console ブラウザ | 推奨なし | 🔓 中 | 簡易操作・緊急時 |
| Serial Console | 不要 | 🔓 中 | OS 起動不能時の緊急復旧のみ |
# IAP 経由 SSH(本番推奨)gcloud compute ssh INSTANCE_NAME --zone=ZONE --tunnel-through-iap# OS Login 有効化(プロジェクト全体)gcloud compute project-info add-metadata --metadata enable-oslogin=TRUE# OS Login IAM ロール付与gcloud projects add-iam-policy-binding PROJECT_ID \--member="user:user@example.com" \--role="roles/compute.osLogin"# インスタンス一覧・詳細確認gcloud compute instances listgcloud compute instances describe INSTANCE_NAME --zone=ZONE# 起動・停止・削除gcloud compute instances start INSTANCE_NAME --zone=ZONEgcloud compute instances stop INSTANCE_NAME --zone=ZONE
- 本番 VM には外部 IP を割り当てず、IAP トンネル経由でアクセスする
- OS Login を有効化して SSH 鍵の個別管理を廃止し IAM で一元制御する
- Serial Console は緊急時以外は無効にしておく
roles/iap.tunnelResourceAccessorは最小権限で付与する
| 比較項目 | スナップショット | カスタムイメージ |
|---|---|---|
| 主な用途 | バックアップ・PITR | VM テンプレート・大量展開 |
| 保存方式 | 増分(初回のみフル) | 完全コピー |
| スコープ | プロジェクト内 | グローバル(プロジェクト跨ぎ可) |
| 復元方法 | 新ディスクとして復元 | 新 VM を作成 |
| スケジュール | Snapshot Schedule Policy で自動化可 | 手動 / CI/CD パイプライン |
# スナップショット作成gcloud compute disks snapshot DISK_NAME \--snapshot-names=SNAPSHOT_NAME \--zone=ZONE \--storage-location=REGION# スナップショットスケジュール作成(毎日 04:00)gcloud compute resource-policies create snapshot-schedule POLICY_NAME \--region=REGION \--max-retention-days=7 \--daily-schedule \--start-time=04:00# ディスクへのスケジュール適用gcloud compute disks add-resource-policies DISK_NAME \--resource-policies=POLICY_NAME --zone=ZONE# イメージ作成(--family で最新版管理)gcloud compute images create IMAGE_NAME \--source-disk=DISK_NAME \--source-disk-zone=ZONE \--family=MY_IMAGE_FAMILY# 最新イメージの参照(常に最新版を使う)gcloud compute images describe-from-family MY_IMAGE_FAMILY \--project=PROJECT_ID
- Snapshot Schedule Policyで本番ディスクの定期バックアップを自動化する
- イメージは
--familyで管理しdescribe-from-familyで常に最新版を参照する - VM 停止中にスナップショットを取得してデータ整合性を確保する
--storage-locationでデータ主権要件に合わせてリージョンを指定する
| 比較項目 | Deployment | StatefulSet |
|---|---|---|
| Pod 名 | ランダムサフィックス | 順番付き(pod-0, pod-1…) |
| 起動順序 | 同時起動 | 順番に起動(0→1→2) |
| ストレージ | 共有可 | 各 Pod に固有の PV |
| ユースケース | ステートレス Web/API | DB・Kafka・ZooKeeper |
# クラスタ認証情報の取得gcloud container clusters get-credentials CLUSTER_NAME --zone=ZONE# インベントリ確認kubectl get nodes -o widekubectl get pods --all-namespaces -o widekubectl get services --all-namespaceskubectl get statefulsets --all-namespaces# ノードプール追加(GPU 対応)gcloud container node-pools create GPU_POOL \--cluster=CLUSTER_NAME --zone=ZONE \--machine-type=n1-standard-4 \--accelerator=type=nvidia-tesla-t4,count=1 \--enable-autoscaling \--min-nodes=0 --max-nodes=5# ノードプール削除gcloud container node-pools delete POOL_NAME \--cluster=CLUSTER_NAME --zone=ZONE# Deployment ローリングアップデートkubectl set image deployment/MY_DEPLOY container=NEW_IMAGE:TAG -n NAMESPACE# ロールバックkubectl rollout undo deployment/MY_DEPLOY -n NAMESPACE# Pod ログ確認kubectl logs POD_NAME -n NAMESPACE --tail=100 -f
- Artifact Registry アクセスはWorkload Identity Federation で SA キーなしに認証する
- GPU ノードプールは
--min-nodes=0に設定して未使用時のコストをゼロにする - StatefulSet 削除は必ず順番に行いデータ損失を防ぐ
- Autopilot では全コンテナに
resources.requestsを必ず設定する
| 比較項目 | HPA(Horizontal) | VPA(Vertical) |
|---|---|---|
| スケール方向 | Pod 数を増減 | Pod の CPU/Memory を増減 |
| Pod 再起動 | なし | あり(updateMode: Auto の場合) |
| ユースケース | ステートレスアプリのトラフィック対応 | DB・バッチ処理のリソース最適化 |
| GKE Autopilot | 自動管理 | Pod Resource Request を管理 |
# HPA 作成(CPU 70% でスケール)kubectl autoscale deployment MY_DEPLOY \--cpu-percent=70 \--min=2 \--max=20# HPA マニフェスト(CPU + Memory)apiVersion: autoscaling/v2kind: HorizontalPodAutoscalerspec:minReplicas: 2maxReplicas: 20metrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 70# VPA マニフェスト(updateMode: Initial 推奨)apiVersion: autoscaling.k8s.io/v1kind: VerticalPodAutoscalerspec:updatePolicy:updatePolicy:updateMode: "Initial"
minReplicasは2 以上に設定して単一障害点を排除する- VPA の
updateMode: Autoは Pod 再起動を伴うため本番ではInitialかOff推奨 - HPA とCluster Autoscalerを組み合わせてノード数も自動調整する
- Autopilot では全コンテナに
resources.requestsを必ず設定する(過剰課金防止)
| パラメータ | 説明 | 推奨値 |
|---|---|---|
| --min-instances | アイドル時も維持するインスタンス数 | レイテンシ重視: 1以上、コスト重視: 0 |
| --max-instances | スケールアップの上限 | DB コネクション数・外部 API 制限を考慮 |
| --concurrency | 1 インスタンスあたりの同時リクエスト数 | CPU バウンド: 1、I/O バウンド: 80〜1000 |
| --timeout | リクエストタイムアウト(秒) | 最大 3600 秒 |
# トラフィックを向けずに新バージョンをデプロイgcloud run deploy SERVICE_NAME \--image=IMAGE_URL \--region=REGION \--no-traffic# カナリアデプロイ(10% だけ新バージョンへ)gcloud run services update-traffic SERVICE_NAME \--to-revisions=revision-00002=10,revision-00001=90 \--region=REGION# 最新リビジョンに 100% 切り替えgcloud run services update-traffic SERVICE_NAME \--to-latest --region=REGION# ロールバックgcloud run services update-traffic SERVICE_NAME \--to-revisions=revision-00001=100 --region=REGION# オートスケーリング設定gcloud run services update SERVICE_NAME \--region=REGION \--min-instances=1 \--max-instances=100 \--concurrency=80
- 本番リリース前は
--no-trafficでデプロイし段階的にトラフィックを切り替える - レイテンシが重要なサービスは
--min-instances=1以上でコールドスタートを防ぐ --max-instancesはバックエンドの制約(DBコネクション数)に合わせて必ず設定する- Cloud Run Functions も同じトラフィック分割コマンドで管理可能
# GPU 搭載 VM インスタンス作成gcloud compute instances create GPU_VM \--zone=ZONE \--machine-type=n1-standard-4 \--accelerator="type=nvidia-tesla-t4,count=1" \--maintenance-policy=TERMINATE \--metadata="install-nvidia-driver=True"# Spot VM でコストを最大 90% 削減(学習ジョブ向け)gcloud compute instances create SPOT_GPU_VM \--provisioning-model=SPOT \--accelerator="type=nvidia-tesla-t4,count=1" \--maintenance-policy=TERMINATE# Cloud TPU VM の作成gcloud compute tpus tpu-vm create TPU_NAME \--zone=ZONE \--accelerator-type=v4-8 \--version=tpu-vm-tf-2.12.0
--maintenance-policy=TERMINATEが必須(ライブマイグレーション非対応)- GPU Driver は起動スクリプト(
install-nvidia-driver=True)で自動インストールを推奨 - 学習ジョブには
--provisioning-model=SPOTでコストを最大 90% 削減できる
3.2 ストレージとデータソリューションの管理
Cloud Storage・データベース操作・バックアップ・CMEK の運用管理
- バケット全体に IAM ポリシーを適用
- オブジェクト個別の ACL を無効化
- 権限管理が一元化されシンプル
- GDPR・コンプライアンス対応に有効
- オブジェクト個別に ACL を設定可能
- 管理が複雑で権限棚卸しが困難
- 設定ミスによる意図しない公開リスク
- 新規プロジェクトでは使用しない
| データ保護機能 | 説明 | 主な用途 |
|---|---|---|
| バージョニング | 過去バージョンを保持 | 誤削除・誤上書きからの復旧 |
| オブジェクトロック(WORM) | 一定期間の削除・変更を防止 | 規制対応・コンプライアンス |
| 保持ポリシー | バケット全体の最小保持期間を設定 | コンプライアンス・監査 |
| ソフトデリート | 削除オブジェクトを 7〜90 日間復元可能 | 誤削除からの素早い復旧 |
# Uniform Bucket-Level Access 有効化(推奨)gcloud storage buckets update gs://BUCKET_NAME \--uniform-bucket-level-access# 公開アクセス防止(誤公開防止)gcloud storage buckets update gs://BUCKET_NAME \--public-access-prevention# バージョニング有効化gcloud storage buckets update gs://BUCKET_NAME --versioning# 保持ポリシー(30 日間削除禁止)gcloud storage buckets update gs://BUCKET_NAME \--retention-period=30d# ソフトデリート(30 日間復元可能)gcloud storage buckets update gs://BUCKET_NAME \--soft-delete-duration=30d
- すべてのバケットでUniform Bucket-Level Access を有効化する
- Public Access Preventionを組織ポリシーで強制して誤公開を防ぐ
- 機密データには保持ポリシーとオブジェクトロックを設定する
- バケット名は
PROJECT_ID-bucket-nameのような命名規則でグローバル一意性を確保する
| ストレージクラス | 最小保存期間 | 用途目安 | GB/月コスト |
|---|---|---|---|
| Standard | なし | 頻繁アクセス・Web 配信 | $0.020 |
| Nearline | 30 日 | 月 1 回程度(バックアップ) | $0.010 |
| Coldline | 90 日 | 四半期 1 回(アーカイブ) | $0.004 |
| Archive | 365 日 | 年 1 回未満(法的保管) | $0.0012 |
{"lifecycle": {"rule": [{"action": { "type": "SetStorageClass", "storageClass": "NEARLINE" },"condition": { "age": 30, "matchesStorageClass": ["STANDARD"] }},{"action": { "type": "SetStorageClass", "storageClass": "COLDLINE" },"condition": { "age": 90 }},{"action": { "type": "Delete" },"condition": { "age": 365 }},{"action": { "type": "Delete" },"condition": { "numNewerVersions": 3, "isLive": false }}]}}# ポリシー適用gcloud storage buckets update gs://BUCKET_NAME \--lifecycle-file=lifecycle.json
age条件はオブジェクトの作成日からの日数です(最終アクセス日ではありません)。バージョニング有効時はnumNewerVersionsで古いバージョンを定期削除してコストを管理してください。
# BigQuery ドライランでコスト試算(必須手順)bq query --use_legacy_sql=false --dry_run \'SELECT col1, col2 FROM \`project.dataset.table\`WHERE DATE(_PARTITIONTIME)="2025-01-01"'# Cloud SQL Auth Proxy 経由で接続(推奨)./cloud-sql-proxy PROJECT_ID:REGION:INSTANCE --port=5432 &psql "host=127.0.0.1 port=5432 dbname=DB user=USER"# Cloud Spanner クエリgcloud spanner databases execute-sql DB_NAME \--instance=INSTANCE \--sql="SELECT * FROM Users WHERE UserId = 1"# Firestore データベース一覧gcloud firestore databases list
- BigQuery では
--dry_runで事前にコストを確認してから本番実行する($5/TB) - Cloud SQL へはCloud SQL Auth Proxy経由で接続し直接インターネット接続を避ける
- BigQuery 高コストクエリにはパーティション化とクラスタリングを適用する
| サービス | バックアップ種別 | 主なコマンド | PITR |
|---|---|---|---|
| Cloud SQL | 自動・オンデマンド・PITR(7日間) | gcloud sql backups create | ✅ 秒単位 |
| AlloyDB | 自動・オンデマンド・PITR | gcloud alloydb backups create | ✅ 秒単位 |
| Spanner | フルバックアップ・PITR(7日間) | gcloud spanner backups create | ✅ 秒単位 |
| Firestore | Managed Export(Cloud Storage) | gcloud firestore export | ❌ エクスポート時点 |
| Bigtable | マネージドバックアップ・GCS エクスポート | gcloud bigtable backups create | ❌ バックアップ時点 |
# Cloud SQL バックアップ作成gcloud sql backups create --instance=INSTANCE_NAME# Cloud SQL PITR(特定時点への復元)gcloud sql instances restore-backup TARGET_INSTANCE \--restore-instance=SOURCE_INSTANCE \--backup-time="2025-01-15T10:00:00Z"# Spanner バックアップ作成gcloud spanner backups create BACKUP_NAME \--instance=INSTANCE --database=DB \--expiration-date="2025-12-31T00:00:00Z"# Firestore エクスポートgcloud firestore export gs://BACKUP_BUCKET/backup \--collection-ids=COLLECTION1,COLLECTION2# Firestore インポートgcloud firestore import gs://BACKUP_BUCKET/backup
- Cloud SQL は PITR を有効化して最大 7 日間の任意時点に復元できるようにする
- Firestore エクスポートはCloud Scheduler + Cloud Run で定期自動化する
- バックアップは本番とは別リージョンに保存してリージョン障害に備える
# KMS キーリングとキーの作成gcloud kms keyrings create KEY_RING --location=REGIONgcloud kms keys create KEY_NAME \--keyring=KEY_RING --location=REGION \--purpose=encryption# Cloud SQL で CMEK を使用してインスタンス作成gcloud sql instances create INSTANCE_NAME \--database-version=POSTGRES_15 \--region=REGION \--disk-encryption-key=projects/PROJECT/locations/REGION/keyRings/KEY_RING/cryptoKeys/KEY_NAME# Cloud Storage バケットで CMEK を設定gcloud storage buckets create gs://BUCKET_NAME \--location=REGION \--default-encryption-key=projects/PROJECT/locations/REGION/keyRings/RING/cryptoKeys/KEY
CMEK を使う場合、KMS キーへのアクセスを失うとデータも失います。キーのバックアップと復旧手順を事前に整備し、キーローテーションポリシーを設定してください。
3.3 ネットワークリソースの管理
サブネット・IP アドレス・Cloud DNS・Cloud NAT・VPC ファイアウォール・Cloud NGFW の運用
--prefix-length に現在より小さい値(より広い範囲)を指定します。# サブネットの IP 範囲を拡張(/24 → /22)gcloud compute networks subnets expand-ip-range SUBNET_NAME \--region=REGION \--prefix-length=22# 静的内部 IP の予約gcloud compute addresses create INTERNAL_IP \--region=REGION \--subnet=SUBNET_NAME \--addresses=10.0.0.100# 静的外部 IP の予約(リージョナル)gcloud compute addresses create EXTERNAL_IP \--region=REGION# 静的外部 IP の予約(グローバル LB 用)gcloud compute addresses create GLOBAL_IP --global# 予約済み IP 一覧gcloud compute addresses list# 未使用 IP の解放(課金停止)gcloud compute addresses delete IP_NAME --region=REGION# カスタム静的ルートの追加gcloud compute routes create ROUTE_NAME \--network=VPC_NAME \--destination-range=10.20.0.0/16 \--next-hop-vpn-tunnel=VPN_TUNNEL \--next-hop-vpn-tunnel-region=REGION \--priority=1000
予約された静的 IP は VM に割り当てられていなくても課金されます。不要な予約 IP は速やかに解放してください。
# プライベート DNS ゾーンの作成(VPC 内部用)gcloud dns managed-zones create PRIVATE_ZONE \--dns-name="internal.example.com." \--visibility=private \--networks=VPC_NAME# DNS A レコードの追加gcloud dns record-sets create www.example.com. \--zone=ZONE_NAME --type=A \--ttl=300 --rrdatas=34.100.0.1# Cloud Router の作成(Cloud NAT の前提条件)gcloud compute routers create ROUTER_NAME \--region=REGION --network=VPC_NAME# Cloud NAT の作成gcloud compute routers nats create NAT_NAME \--router=ROUTER_NAME \--region=REGION \--auto-allocate-nat-external-ips \--nat-all-subnet-ip-ranges \--enable-logging# DNS レコード一覧gcloud dns record-sets list --zone=ZONE_NAME
- 本番 VM には外部 IP を割り当てずCloud NAT + IAPの組み合わせでセキュアに管理する
- プライベート DNS ゾーンで VPC 内のサービス名解決を設定する
- Cloud NAT のログを有効化(
--enable-logging)して通信の監査証跡を残す - Cloud NAT は Cloud Router が必須 — 先に Cloud Router を作成する
| 比較項目 | VPC ファイアウォールルール | Cloud NGFW ポリシー |
|---|---|---|
| 適用スコープ | プロジェクト内 VPC | 組織・フォルダ・プロジェクト |
| L7 フィルタリング | 不可 | 可能(FQDN・TLS inspection) |
| 集中管理 | 個別 VPC | 階層型ポリシーで一元管理 |
| 脅威防御 | なし | 侵入防御(IPS)対応 |
| 推奨場面 | 単一プロジェクト의 簡易制御 | 複数プロジェクト・組織全体の統一管理 |
# SSH を特定 IP からのみ許可(タグベース)gcloud compute firewall-rules create allow-ssh-corp \--network=VPC_NAME \--action=ALLOW \--direction=INGRESS \--rules=tcp:22 \--source-ranges=203.0.113.0/24 \--target-tags=ssh-allowed \--priority=1000# Egress ルール(送信トラフィック制御)gcloud compute firewall-rules create deny-egress \--network=VPC_NAME \--action=DENY \--direction=EGRESS \--rules=all \--destination-ranges=10.99.0.0/16# ルールの一時無効化(削除せず)gcloud compute firewall-rules update RULE_NAME --disabled# ファイアウォールログの有効化gcloud compute firewall-rules update RULE_NAME --enable-logging# Cloud NGFW ポリシーの作成gcloud compute network-firewall-policies create POLICY_NAME --global# NGFW ポリシーを VPC に関連付けgcloud compute network-firewall-policies associations create \--firewall-policy=POLICY_NAME \--network=VPC_NAME \--global-firewall-policy
- Default deny egress は適用せず 特定の宛先(
10.99.0.0/16)のみを明示的にブロックする - ターゲットタグやサービスアカウントを活用して適用対象 VM を動的に制御する
- 不要になった一時ルールは削除する代わりに
--disabledで無効化する - 複数 VPC や組織全体で統合管理する場合は Cloud NGFW 階層型ポリシー を使用する
3.4 モニタリングとロギングの運用
アラートポリシー・監査ログ・ログ転送(シンク)・Managed Prometheus・各種診断ツール
displayName: "High CPU Usage Alert"conditions:- displayName: "CPU utilization > 80% for 5min"conditionThreshold:filter: >resource.type = "gce_instance" ANDmetric.type = "compute.googleapis.com/instance/cpu/utilization"comparison: COMPARISON_GTthresholdValue: 0.8duration: "300s"aggregations:- alignmentPeriod: "60s"perSeriesAligner: ALIGN_MEANcombiner: ORnotificationChannels:- projects/PROJECT_ID/notificationChannels/CHANNEL_IDdocumentation:content: "CPU 使用率が 80% を超えました。\\nRunbook: https://wiki.example.com/runbooks/cpu"mimeType: "text/markdown"
- 症状ベースのアラート(エラー率・レイテンシ・可用性)を優先しノイズを削減する
- SLO ベースのバーンレートアラートを設定する
- アラートには必ず Playbook / Runbook の URL を documentation フィールドに含める
| ログ種別 | 記録内容 | デフォルト | 無効化 |
|---|---|---|---|
| Admin Activity | リソース設定変更(VM 作成・IAM 変更) | 常に有効 | ❌ 不可 |
| Data Access | データの読み取り・書き込み | 無効 | ✅ 可能 |
| System Event | Google システムの自動操作 | 常に有効 | ❌ 不可 |
| Policy Denied | VPC Service Controls によるブロック | 有効 | ✅ 可能 |
# VPC Flow Logs の有効化(サブネット単位)gcloud compute networks subnets update SUBNET_NAME \--region=REGION \--enable-flow-logs \--logging-flow-sampling=0.5# ファイアウォールログの有効化(ルール単位)gcloud compute firewall-rules update RULE_NAME --enable-logging# BigQuery へのログシンク作成gcloud logging sinks create bq-audit-sink \bigquery.googleapis.com/projects/PROJECT/datasets/DATASET \--log-filter='logName="projects/PROJECT/logs/cloudaudit.googleapis.com%2Factivity"'# シンク SA に BigQuery 権限付与(必須!)gcloud projects add-iam-policy-binding PROJECT_ID \--member="serviceAccount:SINK_SA@gcp-sa-logging.iam.gserviceaccount.com" \--role="roles/bigquery.dataEditor"# ログバケットの作成(1 年保持)gcloud logging buckets create BUCKET_NAME \--location=REGION \--retention-days=365# ログフィルタリング確認gcloud logging read 'severity="ERROR" AND resource.type="gce_instance"' \--limit=50 --freshness=1h
| フィルタ | 説明 | 例 |
|---|---|---|
severity | ログの重大度 | severity="ERROR" |
resource.type | リソースタイプ | resource.type="gce_instance" |
logName | ログ名 | logName=~"cloudaudit" |
timestamp | 時刻範囲 | timestamp>="2025-01-01T00:00:00Z" |
textPayload | テキスト検索 | textPayload:"OutOfMemory" |
jsonPayload.key | JSON フィールド | jsonPayload.httpRequest.status=500 |
- Admin Activity ログは常に有効で無効化不可 — Data Access ログは機密データ向けのみ有効化してコスト制御する
- ログシンク作成後は必ずシンクの SA に宛先への権限付与を行う(よくある設定ミス)
- BigQuery にエクスポートしてLog Analyticsで長期的な分析・コンプライアンスレポートに活用する
- VPC Flow Logs はサンプリング率(
--logging-flow-sampling)でコストを最適化する
| ツール | 主な用途 | 試験で問われるシナリオ |
|---|---|---|
| Cloud Trace | 分散アプリのレイテンシ分析・ボトルネック特定 | 「API の応答が遅い原因を調査するには?」 |
| Cloud Profiler | 本番 CPU・メモリのホットスポット特定 | 「本番でメモリ使用量が高騰している原因は?」 |
| Query Insights | Cloud SQL / AlloyDB スロークエリ分析 | 「Cloud SQL のクエリが遅い原因は?」 |
| Index Advisor | 追加すべきインデックスの自動提案 | 「DB パフォーマンスを改善するインデックスは?」 |
| Service Health Dashboard | Google Cloud のインシデントと自プロジェクトへの影響 | 「GCP 障害が自分のサービスに影響しているか確認するには?」 |
# Ops Agent のインストール(Debian/Ubuntu)curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.shsudo bash add-google-cloud-ops-agent-repo.sh --also-install# ステータス確認sudo systemctl status google-cloud-ops-agent# GKE で Managed Prometheus を有効化gcloud container clusters update CLUSTER_NAME \--zone=ZONE \--enable-managed-prometheus
# /etc/google-cloud-ops-agent/config.yamllogging:receivers:app_logs:type: filesinclude_paths: [/var/log/myapp/*.log]exporters:google: { type: google_cloud_logging }service:pipelines:app_pipeline:receivers: [app_logs]exporters: [google]---# Managed Prometheus PodMonitoringapiVersion: monitoring.googleapis.com/v1kind: PodMonitoringmetadata:name: my-app-monitoringspec:selector:matchLabels: { app: my-app }endpoints:- port: metricsinterval: 30spath: /metrics
- 全 Compute Engine VM にOps Agentをデプロイしてシステムメトリクスとアプリログを収集する
- GKE にはManaged Prometheusを有効化してアプリメトリクスを標準化する
- Ops Agent の設定変更後は
sudo systemctl restart google-cloud-ops-agentで反映する
| Active Assist 推奨種別 | 内容 |
|---|---|
| VM Right-sizing | 過剰スペックの VM のダウンサイズ提案 |
| Idle Resource | 未使用リソース(停止中 VM・未割当 IP)の削除提案 |
| IAM Recommender | 過剰な権限の最小化提案 |
| Firewall Insights | 未使用 FW ルールの削除提案 |
| BigQuery Recommender | 未使用テーブル・高コストクエリの最適化提案 |
- Active Assist の推奨を月次で確認してリソースの無駄を継続的に排除する
- Gemini Cloud Assist はアラート調査・ログ分析・クエリ最適化に積極的に活用する
- Cloud Hub をインシデント対応のファーストビューとして設定する
試験直前チェックリスト
Section 3 の頻出ポイントを最終確認。チェックを入れながら弱点を把握してください。
Google Cloud Associate Cloud Engineer — Section 3 完全攻略ガイド
試験ガイド 063026(2026年6月30日施行版)準拠 | 作成日: 2026年6月
※ 本ガイドは学習目的で作成されています。最新情報は必ず公式サイトでご確認ください。