Associate Cloud Engineer
完全マスター教材
GCP の基盤構築から運用管理まで——ACE 試験に必要な知識を体系的に学ぶ
出題セクション別 比重と内容
クラウドソリューション環境のセットアップ
プロジェクト・組織・課金・IAM・ネットワークの初期設定。GCPを使い始める前に必要な基盤構築を理解する。
GCPのリソースは 組織 → フォルダ → プロジェクト → リソース の4層構造で管理される。ポリシーは上位から下位へ継承される。
- フォルダで環境(prod/dev/staging)を分離し、本番へのアクセスを最小限に制限する
- 組織ポリシーで
constraints/compute.requireShieldedVm等のセキュリティ制約を一括適用する - プロジェクトはアプリ・サービス単位で分割し、課金・権限・サービス制限を独立させる
- Terraform などの IaC でプロジェクト作成を自動化し、設定ドリフトを防ぐ
# 組織ポリシーの確認 gcloud org-policies list --organization=ORG_ID # フォルダの作成 gcloud resource-manager folders create \ --display-name="Production" \ --organization=ORG_ID # プロジェクトの作成(フォルダ配下) gcloud projects create my-project-id \ --folder=FOLDER_ID \ --name="My Project"
IAMは「誰が(Member)・何を(Permission)・どのリソースに(Resource)できるか」を定義する。ロールはアクセス制御の最小単位。
| ロール種別 | 内容 | 代表例 |
|---|---|---|
| 基本ロール(Basic) | プロジェクト全体に適用される粗い粒度のロール。本番環境では非推奨。 | Owner / Editor / Viewer |
| 事前定義ロール(Predefined) | 特定サービスに最適化されたロール。Google が管理・更新する。推奨。 | compute.instanceAdmin / storage.objectAdmin |
| カスタムロール(Custom) | 必要な権限のみを集めた自作ロール。最小権限の原則を厳密に実現できる。 | 組織・プロジェクトレベルで作成可能 |
- IAM ポリシーは「誰(member)にどのロール(role)を与えるか」のバインディングの集合
- ポリシーは加算的(additive)——より高いリソースで与えた権限は下位でも有効
- 拒否ポリシー(Deny Policy)は許可ポリシーより優先される(GCPの新機能)
- Cloud Identity でグループを管理し、個人ではなくグループにロールを付与するのがベスト
# IAMポリシーの確認 gcloud projects get-iam-policy PROJECT_ID # ロールの付与 gcloud projects add-iam-policy-binding PROJECT_ID \ --member="user:alice@example.com" \ --role="roles/compute.instanceAdmin.v1" # カスタムロール作成 gcloud iam roles create myCustomRole \ --project=PROJECT_ID \ --file=role-definition.yaml
- 個人アカウントではなくグループ(group:)にロールを付与する——管理が大幅に簡素化
- MFA(多要素認証)を全ユーザーに強制する(Cloud Identity の Security Policy で設定)
- サービスアカウントキーを発行せず Workload Identity Federation で代替する
- 退職者のアカウントを即時無効化できるよう Cloud Identity と HR システムを連携する
GCP の各サービスは使用前に API を有効化する必要がある。大規模トラフィックの前には Quota 増加を事前申請すること。クォータ超過はアプリダウンの原因となる。
# APIの有効化 gcloud services enable compute.googleapis.com gcloud services enable container.googleapis.com gcloud services enable sqladmin.googleapis.com # 有効なAPIの一覧確認 gcloud services list --enabled # クォータの確認 gcloud compute project-info describe --project=PROJECT_ID
請求の支払い主体となるエンティティ。1つの課金アカウントに複数プロジェクトをリンク可能。請求書払い・クレジットカード払いに対応。
プロジェクトは必ず1つの課金アカウントにリンクする。リンクを外すと有料サービスが停止。異なる部門に別々の課金アカウントを割り当て可能。
月次予算を設定し、50%・90%・100%消費時にメールや Pub/Sub 通知を受け取る。自動的にプロジェクトを停止するわけではない(Cloud Functions で自動化可能)。
課金データを BigQuery または Cloud Storage にエクスポートし、コスト分析・FinOps を実施。Looker Studio でダッシュボード化できる。
- 全プロジェクトにラベル(label)を付与し、BigQuery エクスポートでチーム別・環境別コストを可視化
- 予算アラートは Pub/Sub → Cloud Functions で課金アカウントの自動停止に活用できる
- committed use discounts(CUD)と sustained use discounts(SUD)の違いを理解する
- Billing IAM で billing.accounts.viewer を制限し、課金情報へのアクセスを最小化する
クラウドソリューションの計画と実装
コンピューティング・ストレージ・ネットワーク・IaCの選定と実装。GCPの主要サービスを実際にデプロイする技術を習得する。
ワークロードの性質に応じて最適なコンピューティングプラットフォームを選択することが、ACE試験の最重要テーマの一つ。
| サービス | 管理範囲 | 主なユースケース | スケール単位 |
|---|---|---|---|
| Compute Engine | IaaS:OS・MW まで自己管理 | レガシー移行、特定OS要件、GPU/TPU ワークロード、リフト&シフト | VM インスタンス |
| GKE(Autopilot) | マネージドコンテナ基盤 | マイクロサービス、バッチ処理、ステートフルアプリ(StatefulSet) | Pod(ノードは自動管理) |
| GKE(Standard) | コンテナ基盤(ノード管理あり) | 細かいノード制御が必要、GPU ノードプール、特殊OS設定 | Pod / Node Pool |
| Cloud Run | サーバーレスコンテナ | HTTP/gRPC API、イベント処理、スパイクトラフィック対応 | コンテナインスタンス(0→N) |
| Cloud Run functions | FaaS(Function as a Service) | Pub/Sub トリガー、GCS イベント、軽量処理、Eventarc 連携 | 関数インスタンス(0→N) |
| App Engine | PaaS(言語ランタイム管理) | Web アプリ(Standard:Node.js/Python等、Flex:カスタムランタイム) | インスタンス(スケール自動) |
- OS レベルの制御が必要 → Compute Engine
- コンテナ + ステートフル or 長時間処理 → GKE
- コンテナ + ステートレス HTTP API → Cloud Run
- イベント駆動 + 短時間処理 → Cloud Run functions
- 0 スケール(アイドル時コスト 0)が必要 → Cloud Run / Cloud Run functions
Compute Engine の主要設定
# インスタンステンプレートの作成 gcloud compute instance-templates create web-template \ --machine-type=e2-medium \ --image-family=debian-11 \ --image-project=debian-cloud \ --metadata-from-file startup-script=startup.sh # マネージドインスタンスグループの作成(オートスケール) gcloud compute instance-groups managed create web-mig \ --template=web-template \ --size=3 \ --zone=us-central1-a # オートスケーリングの設定 gcloud compute instance-groups managed set-autoscaling web-mig \ --min-num-replicas=2 \ --max-num-replicas=10 \ --target-cpu-utilization=0.6 \ --zone=us-central1-a
GKE の主要設定
| 設定 | Autopilot | Standard |
|---|---|---|
| ノード管理 | Google が完全管理 | ユーザーが管理(ノードプール) |
| 課金単位 | Pod のリソース(vCPU/MEM) | ノード VM の費用 |
| セキュリティ | Shielded Nodes・Workload Identity が強制 | オプション設定 |
| 推奨場面 | 運用負荷を最小化したい場合 | 特殊なノード設定・GPU が必要な場合 |
# GKE Autopilot クラスタの作成 gcloud container clusters create-auto my-cluster \ --region=us-central1 # GKE Standard(プライベートクラスタ)の作成 gcloud container clusters create private-cluster \ --zone=us-central1-a \ --enable-private-nodes \ --enable-private-endpoint \ --master-ipv4-cidr=172.16.0.0/28 # kubectl の設定 gcloud container clusters get-credentials my-cluster \ --region=us-central1
| サービス | タイプ | 特徴・ユースケース |
|---|---|---|
| Cloud Storage | オブジェクトストレージ | 画像・動画・バックアップ・ログ保管。グローバル一意のバケット名。4段階ストレージクラス。 |
| Cloud SQL | マネージドRDBMS | MySQL・PostgreSQL・SQL Server。垂直スケール主体。HA構成・自動バックアップ・フェイルオーバー。 |
| Cloud Spanner | グローバル分散RDBMS | 99.999% SLA。グローバル一貫性のあるトランザクション。銀行・在庫管理等の金融システムに最適。 |
| Firestore | NoSQL ドキュメント DB | サーバーレス・リアルタイム同期。モバイル/Web アプリのバックエンドに最適。 |
| Bigtable | NoSQL ワイドカラム | 時系列データ・IoT・広告データ等の超高スループット低遅延アクセス。 |
| BigQuery | データウェアハウス | サーバーレス SQL 分析。スキャン課金。数 TB のクエリを秒単位で実行。 |
| AlloyDB | PostgreSQL 互換 DB | Cloud SQL PostgreSQL より最大4倍高速な分析クエリ性能。TP+AP統合(HTAP)。 |
| Memorystore | インメモリ DB | マネージド Redis / Memcached。セッション管理・キャッシュ・リーダーボードに最適。 |
| Pub/Sub | メッセージキュー | 非同期メッセージング。イベント駆動アーキテクチャ。Dataflow・Cloud Run との統合。 |
| Filestore | マネージドNFS | VM や GKE からのファイル共有。HPC ワークロードや CMS に使用。 |
Cloud Storage ストレージクラスの使い分け
| クラス | 最小保存期間 | ユースケース | コスト特性 |
|---|---|---|---|
| Standard | なし | 頻繁にアクセスするデータ、Web 配信 | ストレージ高・取得無料 |
| Nearline | 30日 | 月1回程度のアクセス(バックアップ等) | ストレージ低・取得課金 |
| Coldline | 90日 | 四半期1回程度のアクセス(アーカイブ) | ストレージ格安・取得高コスト |
| Archive | 365日 | 年1回未満(規制対応・長期保存) | ストレージ最安・取得最高コスト |
- RDB + グローバル展開 + 強一貫性 → Cloud Spanner
- RDB + リージョン + MySQL/PG 互換 → Cloud SQL
- 大量時系列データ + 低遅延 → Bigtable
- モバイルアプリ + リアルタイム同期 → Firestore
- 分析・DWH + 大規模 SQL → BigQuery
- キャッシュ + セッション管理 → Memorystore(Redis)
# Cloud Storage バケット作成(マルチリージョン) gsutil mb -l US -c STANDARD gs://my-bucket-name # ライフサイクルポリシーの設定 gsutil lifecycle set lifecycle.json gs://my-bucket-name # Cloud SQL インスタンスの作成(HA構成) gcloud sql instances create my-sql \ --database-version=POSTGRES_15 \ --tier=db-n1-standard-4 \ --region=us-central1 \ --availability-type=REGIONAL
ロードバランサーの種類と使い分け
| ロードバランサー | レイヤー | スコープ | ユースケース |
|---|---|---|---|
| グローバル外部 HTTP(S) LB | L7 | グローバル | Web アプリ、Cloud CDN 統合、URL ルーティング |
| リージョン外部 HTTP(S) LB | L7 | リージョン | リージョン内の HTTP アプリ、プロキシ |
| 外部 TCP/UDP NLB(パススルー) | L4 | リージョン | 高性能 TCP/UDP、Game サーバー、非 HTTP プロトコル |
| 内部 HTTP(S) LB | L7 | リージョン内 | マイクロサービス間の内部 HTTP トラフィック |
| 内部 TCP/UDP LB | L4 | リージョン内 | 内部サービス間の TCP/UDP トラフィック |
Network Service Tiers(ネットワークサービス階層)
- Google のプレミアムグローバルバックボーン使用
- 低レイテンシ・高信頼性
- グローバルロードバランサー対応
- コストは高め
- 一般的なインターネット(ISP)経由
- レイテンシはやや高い
- リージョナルロードバランサーのみ
- コストは低め(約30%削減)
# カスタムモードVPCの作成 gcloud compute networks create my-vpc \ --subnet-mode=custom # サブネットの作成 gcloud compute networks subnets create my-subnet \ --network=my-vpc \ --region=us-central1 \ --range=10.0.0.0/24 # ファイアウォールルールの作成(タグベース) gcloud compute firewall-rules create allow-http \ --network=my-vpc \ --allow=tcp:80,tcp:443 \ --target-tags=web-server \ --source-ranges=0.0.0.0/0
- Terraform State ファイルは必ず GCS バックエンドに保存し、ローカルに保持しない
- State ロックに Cloud Spanner または GCS オブジェクトロックを使用してコンフリクトを防ぐ
- 環境(dev/stg/prod)ごとに Terraform workspace またはディレクトリを分離する
- CI/CD パイプライン(Cloud Build)で
terraform planを PR レビュー時に自動実行する - モジュールでリソースを再利用可能にし、環境間の設定差分を変数で吸収する
# Terraform でGCS バックエンドを設定する例(main.tf) terraform { backend "gcs" { bucket = "my-tfstate-bucket" prefix = "terraform/state" } } # Cloud Build で terraform plan を自動実行 gcloud builds submit --config cloudbuild.yaml .
クラウドソリューションの運用管理
コンピュート・ストレージ・ネットワークの日常運用と、Cloud Monitoring/Logging を用いた観測・問題解決を習得する。
# IAP 経由で外部IPなしのVMにSSH接続 gcloud compute ssh my-instance \ --zone=us-central1-a \ --tunnel-through-iap # スナップショットの作成 gcloud compute disks snapshot my-disk \ --snapshot-names=my-snapshot \ --zone=us-central1-a # Cloud Run のトラフィック分割(カナリアデプロイ) gcloud run services update-traffic my-service \ --to-revisions=rev1=90,rev2=10 \ --region=us-central1 # GKE の Pod 一覧確認 kubectl get pods -n default -o wide kubectl get services --all-namespaces
# ライフサイクルポリシーJSON例 { "rule": [{ "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"} "condition": {"age": 30} },{ "action": {"type": "Delete"} "condition": {"age": 365} }] } # BigQuery クエリ実行(コスト確認付き) bq query --use_legacy_sql=false \ --dry_run \ 'SELECT * FROM `project.dataset.table` LIMIT 100' # Cloud SQL のバックアップ作成 gcloud sql backups create \ --instance=my-sql-instance
# 静的外部IPの予約 gcloud compute addresses create my-static-ip \ --region=us-central1 # Cloud NAT の設定(Cloud Router 経由) gcloud compute routers create my-router \ --network=my-vpc \ --region=us-central1 gcloud compute routers nats create my-nat \ --router=my-router \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges \ --region=us-central1
Cloud Monitoring・Cloud Logging・Cloud Trace・Cloud Profiler を組み合わせて可観測性(Observability)を実現する。ACEで頻出の実践的トピック。
| サービス | 役割 | 主な機能 |
|---|---|---|
| Cloud Monitoring | メトリクス監視 | アラートポリシー・アップタイムチェック・ダッシュボード。Ops Agent でカスタムメトリクス収集。Prometheus 統合。 |
| Cloud Logging | ログ管理 | 全GCPサービスのログを一元収集。ログバケット・シンク(BigQuery/GCS/Pub/Sub 転送)・ログアナリティクスで SQL 分析。 |
| Cloud Trace | 分散トレーシング | リクエストのレイテンシ分析。マイクロサービス間の依存関係を可視化。ボトルネック特定に使用。 |
| Cloud Profiler | プロファイリング | 本番アプリの CPU/メモリ使用プロファイルを継続的収集。パフォーマンス劣化箇所の特定。 |
| Ops Agent | エージェント | Compute Engine VM へインストールするエージェント。Fluent Bit + OpenTelemetry で ログ+メトリクスを送信。 |
監査ログの種類(試験頻出)
| ログ種別 | 内容 | デフォルト |
|---|---|---|
| Admin Activity | リソース構成変更(VM 作成・削除・IAM 変更等) | 常に有効・無効化不可 |
| Data Access | データの読み書き(GCS ファイル読み取り等) | デフォルト無効(有効化推奨) |
| System Event | Google システムが自動実行する操作(ライブマイグレーション等) | 常に有効 |
| Policy Denied | VPC Service Controls でブロックされたアクセス | 有効化で記録 |
- Ops Agent を全 Compute Engine VM に必ず導入し、ログとメトリクスを集中管理する
- Data Access 監査ログを有効化し、機密データへのアクセスを記録する(コスト増に注意)
- ログシンクで BigQuery へ転送し、Log Analytics で長期分析・コンプライアンスレポートを作成
- SLO に基づいたアラートを設定し、ノイズを減らす(症状ベース vs 原因ベースのアラート)
- Active Assist(Recommender)の推奨を定期チェックし、リソースの最適化に活用する
# Cloud Monitoring アラートポリシーの作成 gcloud alpha monitoring policies create \ --policy-from-file=alert-policy.json # ログシンクの作成(BigQueryへ転送) gcloud logging sinks create my-bq-sink \ bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET \ --log-filter='resource.type="gce_instance"' # Ops Agent のインストール(Compute Engine VM内で実行) curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh bash add-google-cloud-ops-agent-repo.sh --also-install # 監査ログの確認 gcloud logging read \ 'logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"' \ --limit=50
アクセスとセキュリティの構成
IAMポリシーの管理、サービスアカウントの適切な利用、最小権限の原則を徹底する。
get-iam-policy で現在のポリシー確認、add-iam-policy-binding で個別追加、set-iam-policy でファイルから全体を上書き。# IAMポリシーの確認 gcloud projects get-iam-policy PROJECT_ID \ --format=json # 特定ロールの付与(条件付き) gcloud projects add-iam-policy-binding PROJECT_ID \ --member="group:dev-team@example.com" \ --role="roles/compute.viewer" \ --condition='expression=request.time.getHours("Asia/Tokyo") >= 9 && request.time.getHours("Asia/Tokyo") <= 18,title=BusinessHoursOnly' # ロールの削除 gcloud projects remove-iam-policy-binding PROJECT_ID \ --member="user:alice@example.com" \ --role="roles/editor"
- 基本ロール(Owner/Editor/Viewer)は本番環境では使用せず、事前定義ロールを使う
- 個人ではなくグループにロールを付与する(管理の簡素化・監査の容易化)
- 最小権限の原則:必要最小限の権限のみを付与し、定期的にレビューする
- Policy Analyzer で権限の棚卸しを定期実施し、不要なバインディングを削除する
サービスアカウントは 「人間ではなくアプリケーション・VM・サービスのための IAM メンバー」。適切に管理しないとセキュリティリスクになる。
roles/iam.serviceAccountTokenCreator ロールを持つユーザーが他のサービスアカウントとして一時的に行動できる。監査ログに記録される。generateIdToken や generateAccessToken で短期間(1時間)のトークンを発行する。- キーファイルは漏洩すると長期間悪用される危険がある(有効期限なし)
- 組織ポリシーで
constraints/iam.disableServiceAccountKeyCreationを適用し、キー作成を禁止できる - どうしてもキーが必要な場合:90日以下のローテーション、Secret Manager での安全な保管が必須
# サービスアカウントの作成 gcloud iam service-accounts create my-app-sa \ --display-name="My App Service Account" \ --project=PROJECT_ID # サービスアカウントにロールを付与 gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:my-app-sa@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer" # GKE Workload Identity の設定 # 1. K8s ServiceAccount と GCP SA をバインド gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" # 2. K8s SA にアノテーション付与 kubectl annotate serviceaccount KSA_NAME \ --namespace=NAMESPACE \ iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
Cloud Skills Boost の「Google Cloud Fundamentals: Core Infrastructure」を受講。GCP コンソールとgcloud CLI を毎日触る。無料クレジット($300)で実際に操作する。
Compute Engine・GKE・Cloud Run のハンズオンラボを複数実施。gcloud コマンドを暗記ではなく理解して使えるようにする。
各 DB サービスの特性を比較表で整理。VPC・ファイアウォール・LB の設定をハンズオンで実践。Terraform で実際に GCP リソースをデプロイしてみる。
Cloud Monitoring でアラートを設定。Cloud Logging でログフィルタを作成。IAM の各ロール種別とサービスアカウントの使い方を完全理解する。
公式サンプル問題を繰り返し解く。間違えた問題の公式ドキュメントを必ず読む。Udemy 等の有料模擬問題集(400問以上)も活用すると合格率が上がる。