Google Cloud Certification — ACE 試験対策

Section 3:
Ensuring the Successful Operation of a Cloud Solution

試験配点 ~30%(最重量セクション)。Compute Engine・GKE・Cloud Run・Storage・Networking・Monitoring/Logging の日常運用を中級〜上級者向けに完全解説。試験ガイド 063026(2026年6月30日改訂版)準拠。

配点
~30%
サブセクション
3.1 〜 3.4
試験ガイド
063026
対象レベル
中級〜上級

📊 Section 3 — サブセクション別 出題比重(試験ガイド 063026 準拠)

3.1 コンピューティング管理
★★★★
3.2 ストレージ・データ管理
★★★
3.3 ネットワーク管理
★★★
3.4 モニタリング・ロギング
★★★★
Section 3 — Day2 Operations 全体フロー
🖥️

3.1 コンピューティングリソースの管理

Compute Engine・GKE・Cloud Run の日常運用 — 接続・スナップショット・スケール・デプロイ管理

最重要 ★★★★
🔐 Compute Engine へのリモート接続 3.1
接続方法外部 IPセキュリティ推奨場面
IAP トンネル SSH不要🔒 最高本番環境・外部 IP なし VM
OS Login + IAP不要🔒 最高組織管理環境・SSH 鍵一元管理
gcloud SSH(直接)必要🔓 中開発・検証環境
Cloud Console ブラウザ推奨なし🔓 中簡易操作・緊急時
Serial Console不要🔓 中OS 起動不能時の緊急復旧のみ
IAP トンネル SSH — 認証フロー
bash
# 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 list
gcloud compute instances describe INSTANCE_NAME --zone=ZONE
 
# 起動・停止・削除
gcloud compute instances start INSTANCE_NAME --zone=ZONE
gcloud compute instances stop INSTANCE_NAME --zone=ZONE
✅ ベストプラクティス — リモート接続
  • 本番 VM には外部 IP を割り当てず、IAP トンネル経由でアクセスする
  • OS Login を有効化して SSH 鍵の個別管理を廃止し IAM で一元制御する
  • Serial Console は緊急時以外は無効にしておく
  • roles/iap.tunnelResourceAccessorは最小権限で付与する
📸 スナップショットとイメージ管理 3.1
比較項目スナップショットカスタムイメージ
主な用途バックアップ・PITRVM テンプレート・大量展開
保存方式増分(初回のみフル)完全コピー
スコーププロジェクト内グローバル(プロジェクト跨ぎ可)
復元方法新ディスクとして復元新 VM を作成
スケジュールSnapshot Schedule Policy で自動化可手動 / CI/CD パイプライン
スナップショット vs イメージ — 使い分けフロー
bash
# スナップショット作成
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でデータ主権要件に合わせてリージョンを指定する
☸️ GKE クラスタの運用管理 3.1
比較項目DeploymentStatefulSet
Pod 名ランダムサフィックス順番付き(pod-0, pod-1…)
起動順序同時起動順番に起動(0→1→2)
ストレージ共有可各 Pod に固有の PV
ユースケースステートレス Web/APIDB・Kafka・ZooKeeper
GKE から Artifact Registry へのアクセス設定
bash
# クラスタ認証情報の取得
gcloud container clusters get-credentials CLUSTER_NAME --zone=ZONE
 
# インベントリ確認
kubectl get nodes -o wide
kubectl get pods --all-namespaces -o wide
kubectl get services --all-namespaces
kubectl 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
✅ ベストプラクティス — GKE 運用
  • Artifact Registry アクセスはWorkload Identity Federation で SA キーなしに認証する
  • GPU ノードプールは--min-nodes=0に設定して未使用時のコストをゼロにする
  • StatefulSet 削除は必ず順番に行いデータ損失を防ぐ
  • Autopilot では全コンテナにresources.requests を必ず設定する
📈 Pod オートスケーリング(HPA / VPA)3.1
比較項目HPA(Horizontal)VPA(Vertical)
スケール方向Pod 数を増減Pod の CPU/Memory を増減
Pod 再起動なしあり(updateMode: Auto の場合)
ユースケースステートレスアプリのトラフィック対応DB・バッチ処理のリソース最適化
GKE Autopilot自動管理Pod Resource Request を管理
bash / yaml
# HPA 作成(CPU 70% でスケール)
kubectl autoscale deployment MY_DEPLOY \
--cpu-percent=70 \
--min=2 \
--max=20
 
# HPA マニフェスト(CPU + Memory)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
 
# VPA マニフェスト(updateMode: Initial 推奨)
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
spec:
updatePolicy:
updatePolicy:
updateMode: "Initial"
✅ ベストプラクティス — オートスケーリング
  • minReplicas2 以上に設定して単一障害点を排除する
  • VPA の updateMode: Auto は Pod 再起動を伴うため本番では InitialOff 推奨
  • HPA とCluster Autoscalerを組み合わせてノード数も自動調整する
  • Autopilot では全コンテナにresources.requests を必ず設定する(過剰課金防止)
🚀 Cloud Run の運用管理 3.1
カナリアデプロブとトラフィック分割フロー
パラメータ説明推奨値
--min-instancesアイドル時も維持するインスタンス数レイテンシ重視: 1以上、コスト重視: 0
--max-instancesスケールアップの上限DB コネクション数・外部 API 制限を考慮
--concurrency1 インスタンスあたりの同時リクエスト数CPU バウンド: 1、I/O バウンド: 80〜1000
--timeoutリクエストタイムアウト(秒)最大 3600 秒
bash
# トラフィックを向けずに新バージョンをデプロイ
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
✅ ベストプラクティス — Cloud Run
  • 本番リリース前は --no-traffic でデプロイし段階的にトラフィックを切り替える
  • レイテンシが重要なサービスは--min-instances=1 以上でコールドスタートを防ぐ
  • --max-instancesはバックエンドの制約(DBコネクション数)に合わせて必ず設定する
  • Cloud Run Functions も同じトラフィック分割コマンドで管理可能
⚡ GPU / TPU アタッチメント 3.1
bash
# 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
⚠️ GPU VM の必須設定
  • --maintenance-policy=TERMINATE必須(ライブマイグレーション非対応)
  • GPU Driver は起動スクリプト(install-nvidia-driver=True)で自動インストールを推奨
  • 学習ジョブには--provisioning-model=SPOT でコストを最大 90% 削減できる
💾

3.2 ストレージとデータソリューションの管理

Cloud Storage・データベース操作・バックアップ・CMEK の運用管理

重要 ★★★
🪣 Cloud Storage の操作とセキュリティ 3.2
✅ Uniform Bucket-Level Access(推奨)
  • バケット全体に IAM ポリシーを適用
  • オブジェクト個別の ACL を無効化
  • 権限管理が一元化されシンプル
  • GDPR・コンプライアンス対応に有効
❌ Fine-grained ACL(非推奨・レガシー)
  • オブジェクト個別に ACL を設定可能
  • 管理が複雑で権限棚卸しが困難
  • 設定ミスによる意図しない公開リスク
  • 新規プロジェクトでは使用しない
データ保護機能説明主な用途
バージョニング過去バージョンを保持誤削除・誤上書きからの復旧
オブジェクトロック(WORM)一定期間の削除・変更を防止規制対応・コンプライアンス
保持ポリシーバケット全体の最小保持期間を設定コンプライアンス・監査
ソフトデリート削除オブジェクトを 7〜90 日間復元可能誤削除からの素早い復旧
bash
# 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
✅ ベストプラクティス — Cloud Storage
  • すべてのバケットでUniform Bucket-Level Access を有効化する
  • Public Access Preventionを組織ポリシーで強制して誤公開を防ぐ
  • 機密データには保持ポリシーオブジェクトロックを設定する
  • バケット名はPROJECT_ID-bucket-nameのような命名規則でグローバル一意性を確保する
🔄 ライフサイクル管理ポリシー 3.2
ストレージクラス最小保存期間用途目安GB/月コスト
Standardなし頻繁アクセス・Web 配信$0.020
Nearline30 日月 1 回程度(バックアップ)$0.010
Coldline90 日四半期 1 回(アーカイブ)$0.004
Archive365 日年 1 回未満(法的保管)$0.0012
json — lifecycle.json
{
"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 条件の注意点

age条件はオブジェクトの作成日からの日数です(最終アクセス日ではありません)。バージョニング有効時はnumNewerVersionsで古いバージョンを定期削除してコストを管理してください。

🔍 データベースクエリと操作 3.2
BigQuery クエリコスト管理フロー
bash
# 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
✅ ベストプラクティス — DB クエリ
  • BigQuery では--dry_run事前にコストを確認してから本番実行する($5/TB)
  • Cloud SQL へはCloud SQL Auth Proxy経由で接続し直接インターネット接続を避ける
  • BigQuery 高コストクエリにはパーティション化とクラスタリングを適用する
🔒 バックアップとリストア 3.2
サービスバックアップ種別主なコマンドPITR
Cloud SQL自動・オンデマンド・PITR(7日間)gcloud sql backups create✅ 秒単位
AlloyDB自動・オンデマンド・PITRgcloud alloydb backups create✅ 秒単位
Spannerフルバックアップ・PITR(7日間)gcloud spanner backups create✅ 秒単位
FirestoreManaged Export(Cloud Storage)gcloud firestore export❌ エクスポート時点
Bigtableマネージドバックアップ・GCS エクスポートgcloud bigtable backups create❌ バックアップ時点
bash
# 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 で定期自動化する
  • バックアップは本番とは別リージョンに保存してリージョン障害に備える
🔑 Database Center と CMEK 3.2
Database Center — フリート管理の全体像
bash — CMEK 設定
# KMS キーリングとキーの作成
gcloud kms keyrings create KEY_RING --location=REGION
gcloud 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 の重要注意事項

CMEK を使う場合、KMS キーへのアクセスを失うとデータも失います。キーのバックアップと復旧手順を事前に整備し、キーローテーションポリシーを設定してください。

🌐

3.3 ネットワークリソースの管理

サブネット・IP アドレス・Cloud DNS・Cloud NAT・VPC ファイアウォール・Cloud NGFW の運用

重要 ★★★
📡 サブネット・IP アドレス管理 3.3
📌 試験頻出の落とし穴
VPC サブネットは拡張(広げる)のみ可能です。縮小はできません。--prefix-length に現在より小さい値(より広い範囲)を指定します。
bash
# サブネットの 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 の課金

予約された静的 IP は VM に割り当てられていなくても課金されます。不要な予約 IP は速やかに解放してください。

🔀 Cloud DNS と Cloud NAT 3.3
Cloud NAT — 外部 IP なし VM のアウトバウンド接続
bash
# プライベート 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
✅ ベストプラクティス — DNS / NAT
  • 本番 VM には外部 IP を割り当てずCloud NAT + IAPの組み合わせでセキュアに管理する
  • プライベート DNS ゾーンで VPC 内のサービス名解決を設定する
  • Cloud NAT のログを有効化(--enable-logging)して通信の監査証跡を残す
  • Cloud NAT は Cloud Router が必須 — 先に Cloud Router を作成する
🛡️ VPC ファイアウォールと Cloud NGFW 3.3
比較項目VPC ファイアウォールルールCloud NGFW ポリシー
適用スコーププロジェクト内 VPC組織・フォルダ・プロジェクト
L7 フィルタリング不可可能(FQDN・TLS inspection)
集中管理個別 VPC階層型ポリシーで一元管理
脅威防御なし侵入防御(IPS)対応
推奨場面単一プロジェクト의 簡易制御複数プロジェクト・組織全体の統一管理
bash
# 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・各種診断ツール

最重要 ★★★★
🔔 Cloud Monitoring アラートポリシー 3.4
アラートポリシーの処理フロー
yaml — アラートポリシー
displayName: "High CPU Usage Alert"
conditions:
- displayName: "CPU utilization > 80% for 5min"
conditionThreshold:
filter: >
resource.type = "gce_instance" AND
metric.type = "compute.googleapis.com/instance/cpu/utilization"
comparison: COMPARISON_GT
thresholdValue: 0.8
duration: "300s"
aggregations:
- alignmentPeriod: "60s"
perSeriesAligner: ALIGN_MEAN
combiner: OR
notificationChannels:
- projects/PROJECT_ID/notificationChannels/CHANNEL_ID
documentation:
content: "CPU 使用率が 80% を超えました。\\nRunbook: https://wiki.example.com/runbooks/cpu"
mimeType: "text/markdown"
✅ ベストプラクティス — アラート設計
  • 症状ベースのアラート(エラー率・レイテンシ・可用性)を優先しノイズを削減する
  • SLO ベースのバーンレートアラートを設定する
  • アラートには必ず Playbook / Runbook の URL を documentation フィールドに含める
📋 ログ管理・監査ログ・エクスポート 3.4
ログ種別記録内容デフォルト無効化
Admin Activityリソース設定変更(VM 作成・IAM 変更)常に有効❌ 不可
Data Accessデータの読み取り・書き込み無効✅ 可能
System EventGoogle システムの自動操作常に有効❌ 不可
Policy DeniedVPC Service Controls によるブロック有効✅ 可能
ログルーター — ログ転送アーキテクチャ
bash
# 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.keyJSON フィールドjsonPayload.httpRequest.status=500
✅ ベストプラクティス — ログ管理
  • Admin Activity ログは常に有効で無効化不可 — Data Access ログは機密データ向けのみ有効化してコスト制御する
  • ログシンク作成後は必ずシンクの SA に宛先への権限付与を行う(よくある設定ミス)
  • BigQuery にエクスポートしてLog Analyticsで長期的な分析・コンプライアンスレポートに活用する
  • VPC Flow Logs はサンプリング率(--logging-flow-sampling)でコストを最適化する
🔬 診断ツール群(Trace / Profiler / Query Insights)3.4
ツール主な用途試験で問われるシナリオ
Cloud Trace分散アプリのレイテンシ分析・ボトルネック特定「API の応答が遅い原因を調査するには?」
Cloud Profiler本番 CPU・メモリのホットスポット特定「本番でメモリ使用量が高騰している原因は?」
Query InsightsCloud SQL / AlloyDB スロークエリ分析「Cloud SQL のクエリが遅い原因は?」
Index Advisor追加すべきインデックスの自動提案「DB パフォーマンスを改善するインデックスは?」
Service Health DashboardGoogle Cloud のインシデントと自プロジェクトへの影響「GCP 障害が自分のサービスに影響しているか確認するには?」
🤖 Ops Agent と Managed Prometheus 3.4
bash — Ops Agent インストール
# Ops Agent のインストール(Debian/Ubuntu)
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo 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
yaml — Ops Agent カスタムログ / Managed Prometheus PodMonitoring
# /etc/google-cloud-ops-agent/config.yaml
logging:
receivers:
app_logs:
type: files
include_paths: [/var/log/myapp/*.log]
exporters:
google: { type: google_cloud_logging }
service:
pipelines:
app_pipeline:
receivers: [app_logs]
exporters: [google]
 
---
# Managed Prometheus PodMonitoring
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
name: my-app-monitoring
spec:
selector:
matchLabels: { app: my-app }
endpoints:
- port: metrics
interval: 30s
path: /metrics
✅ ベストプラクティス — Ops Agent / Prometheus
  • 全 Compute Engine VM にOps Agentをデプロイしてシステムメトリクスとアプリログを収集する
  • GKE にはManaged Prometheusを有効化してアプリメトリクスを標準化する
  • Ops Agent の設定変更後はsudo systemctl restart google-cloud-ops-agentで反映する
✨ AI 支援ツール群(Gemini / Active Assist / Cloud Hub)3.4
Gemini Cloud Assist for Monitoring
メトリクスの異常分析・アラートの根本原因特定・対処方法を AI が自然言語で提案。Cloud Console から「Ask Gemini」ボタンで即時利用可能。
Active Assist(Recommender)
AI ベースのリソース最適化推奨エンジン。VM Right-sizing・未使用リソース削除・IAM 権限最小化・FW ルール最適化を自動提案。
Cloud Hub
アクティブなインシデントとアプリケーション健全性を一元表示。Personalized Service Health で自分のリソースへの影響を優先表示。
Active Assist 推奨種別内容
VM Right-sizing過剰スペックの VM のダウンサイズ提案
Idle Resource未使用リソース(停止中 VM・未割当 IP)の削除提案
IAM Recommender過剰な権限の最小化提案
Firewall Insights未使用 FW ルールの削除提案
BigQuery Recommender未使用テーブル・高コストクエリの最適化提案
✅ ベストプラクティス — AI 支援ツール
  • Active Assist の推奨を月次で確認してリソースの無駄を継続的に排除する
  • Gemini Cloud Assist はアラート調査・ログ分析・クエリ最適化に積極的に活用する
  • Cloud Hub をインシデント対応のファーストビューとして設定する

試験直前チェックリスト

Section 3 の頻出ポイントを最終確認。チェックを入れながら弱点を把握してください。

Google Cloud Associate Cloud Engineer — Section 3 完全攻略ガイド

試験ガイド 063026(2026年6月30日施行版)準拠 | 作成日: 2026年6月

※ 本ガイドは学習目的で作成されています。最新情報は必ず公式サイトでご確認ください。