Google Cloud Certification

Associate Cloud Engineer
完全マスター教材

GCP の基盤構築から運用管理まで——ACE 試験に必要な知識を体系的に学ぶ

Duration
2 時間
Questions
50〜60問
Fee
$125
Validity
2 年間
Language
日本語対応

出題セクション別 比重と内容

Section 1: クラウド環境のセットアップ
~23%
Section 2: クラウドソリューションの計画・実装
~30%
Section 3: クラウドソリューションの運用
~27%
Section 4: アクセスとセキュリティの構成
~20%
01

クラウドソリューション環境のセットアップ

プロジェクト・組織・課金・IAM・ネットワークの初期設定。GCPを使い始める前に必要な基盤構築を理解する。

~23%
1.1.1リソース階層(Resource Hierarchy)の設計

GCPのリソースは 組織 → フォルダ → プロジェクト → リソース の4層構造で管理される。ポリシーは上位から下位へ継承される。

組織(Organization)
Cloud Identity または Google Workspace ドメインに紐づく最上位ノード。全プロジェクトのルート。組織ポリシーは全リソースに適用される。
フォルダ(Folder)
プロジェクトをグループ化する中間層。部門・環境(dev/stg/prod)・チーム単位での権限分離に活用。フォルダは入れ子可能。
プロジェクト(Project)
GCPリソースの基本コンテナ。すべてのAPIとリソースはプロジェクトに属する。課金・IAM・サービスはプロジェクト単位で管理。
組織ポリシー(Org Policy)
組織・フォルダ・プロジェクトに適用する制約。例:特定リージョン以外でのリソース作成禁止、外部IPの無効化。継承は下位に伝播。
リソース階層設計のベストプラクティス
  • フォルダで環境(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"
1.1.2IAM(Identity and Access Management)の基礎

IAMは「誰が(Member)・何を(Permission)・どのリソースに(Resource)できるか」を定義する。ロールはアクセス制御の最小単位。

ロール種別内容代表例
基本ロール(Basic)プロジェクト全体に適用される粗い粒度のロール。本番環境では非推奨。Owner / Editor / Viewer
事前定義ロール(Predefined)特定サービスに最適化されたロール。Google が管理・更新する。推奨。compute.instanceAdmin / storage.objectAdmin
カスタムロール(Custom)必要な権限のみを集めた自作ロール。最小権限の原則を厳密に実現できる。組織・プロジェクトレベルで作成可能
試験頻出:IAM バインディングの仕組み
  • 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
1.1.3Cloud Identity とユーザー管理
Cloud Identity
Google のIDaaS(Identity as a Service)。ユーザー・グループを管理し、GCP・Google Workspace・外部アプリへのSSOを提供。
グループ管理
ユーザーをグループ化して権限を一括管理。個人ではなくグループにIAMロールを付与することで管理負荷を低減。
SAML / OIDC フェデレーション
社内 IdP(Active Directory、Okta 等)と連携し、既存の認証基盤を活用。ユーザープロビジョニングの自動化(SCIM対応)。
Workload Identity Federation
AWS・Azure・オンプレのワークロードが、サービスアカウントキーなしに GCP リソースへアクセスする仕組み。
ユーザー管理のベストプラクティス
  • 個人アカウントではなくグループ(group:)にロールを付与する——管理が大幅に簡素化
  • MFA(多要素認証)を全ユーザーに強制する(Cloud Identity の Security Policy で設定)
  • サービスアカウントキーを発行せず Workload Identity Federation で代替する
  • 退職者のアカウントを即時無効化できるよう Cloud Identity と HR システムを連携する
1.1.4API 有効化・割り当て(Quota)管理
重要ポイント

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.2課金設定(Billing Configuration)
1
課金アカウントの作成

請求の支払い主体となるエンティティ。1つの課金アカウントに複数プロジェクトをリンク可能。請求書払い・クレジットカード払いに対応。

2
プロジェクトへのリンク

プロジェクトは必ず1つの課金アカウントにリンクする。リンクを外すと有料サービスが停止。異なる部門に別々の課金アカウントを割り当て可能。

3
予算・アラートの設定

月次予算を設定し、50%・90%・100%消費時にメールや Pub/Sub 通知を受け取る。自動的にプロジェクトを停止するわけではない(Cloud Functions で自動化可能)。

4
課金データのエクスポート

課金データを 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 を制限し、課金情報へのアクセスを最小化する

02

クラウドソリューションの計画と実装

コンピューティング・ストレージ・ネットワーク・IaCの選定と実装。GCPの主要サービスを実際にデプロイする技術を習得する。

~30%
2.1コンピューティングサービスの選択と実装

ワークロードの性質に応じて最適なコンピューティングプラットフォームを選択することが、ACE試験の最重要テーマの一つ。

サービス管理範囲主なユースケーススケール単位
Compute EngineIaaS: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 functionsFaaS(Function as a Service)Pub/Sub トリガー、GCS イベント、軽量処理、Eventarc 連携関数インスタンス(0→N)
App EnginePaaS(言語ランタイム管理)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 の主要設定

マシンタイプ
E2(コスト重視)、N2/N4(汎用)、C3(コンピューティング最適化)、M3(メモリ最適化)。カスタムマシンタイプで vCPU・メモリを個別指定も可能。
Spot VM(旧 Preemptible)
通常 VM より最大 91% 安価。ただし最大24時間で停止され得る。バッチ処理・耐障害性のあるワークロードに最適。
マネージドインスタンスグループ(MIG)
インスタンステンプレートから同一VMを複数作成・自動スケーリング・自己修復(autohealing)を提供。高可用性の基本。
OS Login
SSH公開鍵の管理をIAMで統合。個人の Google アカウントで SSH 接続でき、鍵の個別管理が不要になる。
Persistent Disk vs Hyperdisk
PD:標準のブロックストレージ(zonal/regional)。Hyperdisk:高IOPSが必要な DB ワークロード向け。容量とIOPSを独立してスケールできる。
VM Manager
OS パッチ管理・インベントリ収集・設定管理を統合。パッチコンプライアンスの自動化に使用。
# インスタンステンプレートの作成
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 の主要設定

設定AutopilotStandard
ノード管理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
2.2ストレージとデータソリューションの計画・実装
サービスタイプ特徴・ユースケース
Cloud Storageオブジェクトストレージ画像・動画・バックアップ・ログ保管。グローバル一意のバケット名。4段階ストレージクラス。
Cloud SQLマネージドRDBMSMySQL・PostgreSQL・SQL Server。垂直スケール主体。HA構成・自動バックアップ・フェイルオーバー。
Cloud Spannerグローバル分散RDBMS99.999% SLA。グローバル一貫性のあるトランザクション。銀行・在庫管理等の金融システムに最適。
FirestoreNoSQL ドキュメント DBサーバーレス・リアルタイム同期。モバイル/Web アプリのバックエンドに最適。
BigtableNoSQL ワイドカラム時系列データ・IoT・広告データ等の超高スループット低遅延アクセス。
BigQueryデータウェアハウスサーバーレス SQL 分析。スキャン課金。数 TB のクエリを秒単位で実行。
AlloyDBPostgreSQL 互換 DBCloud SQL PostgreSQL より最大4倍高速な分析クエリ性能。TP+AP統合(HTAP)。
Memorystoreインメモリ DBマネージド Redis / Memcached。セッション管理・キャッシュ・リーダーボードに最適。
Pub/Subメッセージキュー非同期メッセージング。イベント駆動アーキテクチャ。Dataflow・Cloud Run との統合。
FilestoreマネージドNFSVM や GKE からのファイル共有。HPC ワークロードや CMS に使用。

Cloud Storage ストレージクラスの使い分け

クラス最小保存期間ユースケースコスト特性
Standardなし頻繁にアクセスするデータ、Web 配信ストレージ高・取得無料
Nearline30日月1回程度のアクセス(バックアップ等)ストレージ低・取得課金
Coldline90日四半期1回程度のアクセス(アーカイブ)ストレージ格安・取得高コスト
Archive365日年1回未満(規制対応・長期保存)ストレージ最安・取得最高コスト
DB 選択のベストプラクティス
  • 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
2.3ネットワークリソースの計画・実装
VPC(Virtual Private Cloud)
GCPのソフトウェア定義ネットワーク。グローバルに展開(リージョンをまたぐ)。カスタムモードVPCでサブネットを自分で定義するのが推奨。
Shared VPC
Host プロジェクトのVPCを複数の Service プロジェクトで共有。ネットワーク管理を集中化しつつ、アプリ開発チームは独立したプロジェクトで作業できる。
VPC Network Peering
異なるVPC(異なる組織も可)間でプライベートIPルーティングを設定。推移的ルーティングは不可(A-B-C の場合、A-Cは直接ピアリングが必要)。
Cloud VPN
オンプレミスと GCP を IPsec トンネルで接続。HA VPN(99.99% SLA)と Classic VPN(99.9% SLA)がある。帯域は各トンネル最大 3Gbps。
Cloud Interconnect
オンプレミスと GCP を専用回線(Dedicated Interconnect:10/100Gbps)またはパートナー経由(Partner Interconnect:50Mbps〜50Gbps)で接続。
Cloud NGFW(次世代ファイアウォール)
ステートフルなファイアウォール。ルールは優先度(priority)で評価。デフォルト拒否ルールが最低優先度(65535)で存在する。

ロードバランサーの種類と使い分け

ロードバランサーレイヤースコープユースケース
グローバル外部 HTTP(S) LBL7グローバルWeb アプリ、Cloud CDN 統合、URL ルーティング
リージョン外部 HTTP(S) LBL7リージョンリージョン内の HTTP アプリ、プロキシ
外部 TCP/UDP NLB(パススルー)L4リージョン高性能 TCP/UDP、Game サーバー、非 HTTP プロトコル
内部 HTTP(S) LBL7リージョン内マイクロサービス間の内部 HTTP トラフィック
内部 TCP/UDP LBL4リージョン内内部サービス間の TCP/UDP トラフィック

Network Service Tiers(ネットワークサービス階層)

Premium Tier(デフォルト)
  • Google のプレミアムグローバルバックボーン使用
  • 低レイテンシ・高信頼性
  • グローバルロードバランサー対応
  • コストは高め
Standard Tier
  • 一般的なインターネット(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
2.4Infrastructure as Code(IaC)による実装
Terraform
HashiCorp 製の最もポピュラーなIaCツール。HCL 言語で記述。GCP プロバイダーで全リソースを管理可能。State ファイル管理が重要(GCS バックエンド推奨)。
Fabric FAST
Google 公式の Terraform ファウンデーションフレームワーク。組織・課金・VPC等の基盤構成を短時間で構築するための Terraform モジュール集。
Config Connector
Kubernetes CRD 経由で GCP リソースを宣言的に管理。GKE 上で動作し、kubectl apply で GCP リソース(SQL・GCS等)を作成できる。
Helm
Kubernetes アプリケーションのパッケージマネージャ。Chart という単位でアプリをテンプレート化。GKE アプリのデプロイに使用。
IaC ベストプラクティス
  • 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 .

03

クラウドソリューションの運用管理

コンピュート・ストレージ・ネットワークの日常運用と、Cloud Monitoring/Logging を用いた観測・問題解決を習得する。

~27%
3.1コンピューティングリソースの運用管理
リモート接続(SSH/RDP)
Console SSH ボタン、gcloud compute ssh、IAP(Identity-Aware Proxy)トンネル経由が推奨。外部IPなしの VM にも IAP 経由で接続可能。
スナップショット管理
Persistent Disk の増分スナップショット。スケジュールスナップショットで定期的に自動取得。RPO 要件に応じて頻度を設定する。
カスタムイメージ
OS・ミドルウェアを含む VM イメージ。ゴールデンイメージとして管理し、MIG のテンプレートに利用。イメージファミリーでバージョン管理。
GKE Node Pool 管理
Node Pool の追加・変更・削除。クラスタを停止せずにノードプールのサイズや機種を変更可能。Node Auto Provisioning で自動最適化。
Pod オートスケーリング
HPA(Horizontal Pod Autoscaler):CPU/メモリでPod数をスケール。VPA(Vertical Pod Autoscaler):Pod のリソースリクエストを動的調整。
Cloud Run トラフィック分割
Cloud Run の複数リビジョン間でトラフィックを % で分割。カナリアデプロイ・Blue/Green デプロイに活用。
# 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
3.2ストレージ・データの運用管理
Cloud Storage オブジェクト管理
ACL・IAM でオブジェクトレベルのアクセス制御。バージョニング・保持ポリシー・オブジェクトロック(WORM)で誤削除・改竄を防止。
ライフサイクル管理
条件(経過日数・バージョン数)に基づき自動でストレージクラスを変更またはオブジェクトを削除。コスト最適化に重要。
データベースバックアップ
Cloud SQL:自動バックアップ(7日保持デフォルト)・オンデマンドバックアップ・ポイントインタイムリカバリ(PITR)。Spanner:マネージドバックアップ。
Database Center
GCPの全データベースの一元管理ダッシュボード。ヘルス・セキュリティ・コンプライアンス状況を一覧表示。
# ライフサイクルポリシー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
3.3ネットワークリソースの運用管理
サブネット拡張
既存のサブネット CIDR を拡張(縮小は不可)。例:/24 → /22 に拡大。ダウンタイムなしで変更可能。既存 VM の IP アドレスは変わらない。
静的外部 IP の予約
VM・ロードバランサーに固定 IP を割り当て。未使用の静的 IP は課金される。リージョナルとグローバルで利用可能な LB の種類が異なる。
Cloud DNS
マネージド DNS サービス。プライベートゾーン(VPC 内部解決)とパブリックゾーンを提供。DNSSEC 対応。100% SLA。
Cloud NAT
外部 IP を持たないVM が インターネットに outbound アクセスするための NAT ゲートウェイ。インバウンドは不可。ソフトウェア定義で高可用性。
# 静的外部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
3.4監視・ロギング(Cloud Observability)

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 EventGoogle システムが自動実行する操作(ライブマイグレーション等)常に有効
Policy DeniedVPC 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

04

アクセスとセキュリティの構成

IAMポリシーの管理、サービスアカウントの適切な利用、最小権限の原則を徹底する。

~20%
4.1IAM ポリシーの管理
IAM ポリシーの確認と付与
get-iam-policy で現在のポリシー確認、add-iam-policy-binding で個別追加、set-iam-policy でファイルから全体を上書き。
条件付き IAM(Conditional IAM)
時間帯・リソース属性・IP アドレスなどの条件に基づいて IAM を制御。例:業務時間内のみアクセス許可、特定リージョンのリソースのみ操作可能。
拒否ポリシー(Deny Policy)
許可ポリシーよりも優先して適用される拒否ルール。Owner でも上書きできない強制的な制約を作成可能。組織・フォルダ・プロジェクトに適用。
Policy Analyzer
「このユーザーはこのリソースに何ができるか?」を分析するツール。誰が特定リソースにアクセスできるかを可視化。
# 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"
IAM 管理のベストプラクティス
  • 基本ロール(Owner/Editor/Viewer)は本番環境では使用せず、事前定義ロールを使う
  • 個人ではなくグループにロールを付与する(管理の簡素化・監査の容易化)
  • 最小権限の原則:必要最小限の権限のみを付与し、定期的にレビューする
  • Policy Analyzer で権限の棚卸しを定期実施し、不要なバインディングを削除する
4.2サービスアカウントの管理

サービスアカウントは 「人間ではなくアプリケーション・VM・サービスのための IAM メンバー」。適切に管理しないとセキュリティリスクになる。

サービスアカウントの作成
プロジェクトに専用のサービスアカウントを作成し、アプリごとに分離する。1アプリ = 1サービスアカウントが原則。
VM へのサービスアカウント割り当て
VM 作成時またはサービスアカウントの変更で割り当て。VM 上のアプリは Application Default Credentials (ADC) で自動認証される。鍵ファイル不要。
サービスアカウントなりすまし(Impersonation)
roles/iam.serviceAccountTokenCreator ロールを持つユーザーが他のサービスアカウントとして一時的に行動できる。監査ログに記録される。
短期間の認証情報
長期間有効なサービスアカウントキーを使わず、generateIdTokengenerateAccessToken で短期間(1時間)のトークンを発行する。
GKE Workload Identity
Kubernetes ServiceAccount と GCP ServiceAccount をバインドする仕組み。Pod から GCP リソースへ鍵ファイルなしにアクセス可能。GKE のベストプラクティス。
サービスアカウントキーの廃止
サービスアカウントキー(JSON ファイル)の発行は最終手段。代わりに Workload Identity Federation や VM へのサービスアカウント割り当てを使う。
セキュリティリスク:サービスアカウントキー
  • キーファイルは漏洩すると長期間悪用される危険がある(有効期限なし)
  • 組織ポリシーで 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

ACE 試験合格ロードマップ(推奨 8〜12 週)
W1-2
GCP 基礎とリソース階層を理解する

Cloud Skills Boost の「Google Cloud Fundamentals: Core Infrastructure」を受講。GCP コンソールとgcloud CLI を毎日触る。無料クレジット($300)で実際に操作する。

W3-4
コンピューティングサービスを習得する(Section 2 の核心)

Compute Engine・GKE・Cloud Run のハンズオンラボを複数実施。gcloud コマンドを暗記ではなく理解して使えるようにする。

W5-6
ストレージ・ネットワーク・IaC を習得する

各 DB サービスの特性を比較表で整理。VPC・ファイアウォール・LB の設定をハンズオンで実践。Terraform で実際に GCP リソースをデプロイしてみる。

W7-8
運用管理・監視・IAM を習得する

Cloud Monitoring でアラートを設定。Cloud Logging でログフィルタを作成。IAM の各ロール種別とサービスアカウントの使い方を完全理解する。

W9-10
模擬試験と弱点補強

公式サンプル問題を繰り返し解く。間違えた問題の公式ドキュメントを必ず読む。Udemy 等の有料模擬問題集(400問以上)も活用すると合格率が上がる。

2時間・50〜60問推奨:6ヶ月の実務経験日本語受験可オンライン受験対応$125 / 更新 $75