PCDE 試験頻出のサービス・概念を 15 カテゴリ × 重要度 ★★★（必出） で網羅した直前確認用リファレンス。日英対応・リネーム前後の対応を意識して暗記しましょう。用語数：138 用語（★★★ のみ）。
表示: 138 用語
GCP のサーバーレス CI/CD サービス。cloudbuild.yaml の steps を順次または並列実行。
特徴：分単位課金、デフォルト Timeout 60 分（最大 24h）、無料枠 120 ビルド分/日、トリガー 7 種類（push / PR / tag / Pub/Sub / Webhook / Scheduled / Manual）、waitFor: ['-'] で並列、ユーザー定義置換は _ から開始、SLSA Level 3 相当の provenance を自動生成。
試験：「サーバーレス CI」「VPC 内アクセス」→ Private Pool。
GKE / Cloud Run / GKE Enterprise 向けマネージド CD サービス。
階層：Delivery Pipeline → Target → Release → Rollout → Phase。レンダリングエンジンは Skaffold。Kubernetes / Kustomize / Helm に対応。Canary 戦略は percentages: [10, 25, 50] 等。各 Phase に predeploy hook / deploy / verify / postdeploy hook。
非対応：App Engine、Cloud Functions。
試験：「マネージド CD」「承認者と作成者を分離」→ roles/clouddeploy.releaser vs roles/clouddeploy.approver + requireApproval: true。
マルチフォーマット対応のアーティファクト管理サービス。Container Registry の後継。
特徴：ホスト名 <region>-<format>.pkg.dev、対応形式 Docker / Maven / npm / Python / Helm / Apt / Yum / Go / Kubeflow、タグ上書き禁止（--immutable-tags）、Remote Repository（外部キャッシュ）、Virtual Repository（複数集約）、Cleanup Policies。
CNCF の K8s 開発ツールキット。Cloud Deploy の render エンジン。skaffold build / render / dev / debug でローカル CI 相当を再現可能。Kustomize / Helm 連携。
試験：「ローカルで CI と同じビルドを再現」→ Skaffold。
Kubernetes 標準の宣言的設定パッチツール。base + overlay で環境別 manifest を生成。kubectl -k で組込み利用可能、テンプレート言語不要（純粋な YAML）。Cloud Deploy / Skaffold が対応。
Kubernetes のパッケージマネージャ。Chart 単位で再利用可能なテンプレート配布。helm install / upgrade / rollback。Chart.yaml + values.yaml + templates/ 構成。Artifact Registry が Helm リポジトリ対応、Cloud Deploy が Helm Chart デプロイに対応。
コンテナイメージの CVE スキャン と SBOM 生成。旧 Container Analysis。
特徴：AR への push 時に 自動スキャン、On-Demand Scanning で CI 中に scan、SBOM = Software Bill of Materials（部品表）、重大度 CRITICAL / HIGH / MEDIUM / LOW / MINIMAL。
試験：「脆弱性検出 → Artifact Analysis、署名検証 → Binary Authorization」を混同しない。
Cloud Deploy の最上位リソース。1 本のリリースフロー（dev → staging → prod 等）を定義。
Cloud Deploy のデプロイ先環境（GKE / Cloud Run クラスタ等）。requireApproval: true で職務分掌実装。
Cloud Deploy のバージョンスナップショット。イメージ + render 済み manifest を含む。1 つの Release から複数 Target に Promote される。
Cloud Deploy が 1 つの Target に対して Release を実際に展開する実行単位。
Cloud Build のプライベートワーカープール。VPC 内 / プライベート GKE / Cloud SQL / オンプレ DB へアクセスする際に必須。
特徴：VPC ピアリングで顧客 VPC へ接続、カスタムマシンタイプ、静的 IP / NW egress 制御。デフォルトの公開プールよりコスト高。
試験：「Cloud Build からプライベートリソース・オンプレ」→ Private Pool が即答。
GCP のマネージド Kubernetes。Standard と Autopilot の 2 モード。
特徴：Release Channel = Rapid / Regular（デフォルト）/ Stable、ノード自動アップグレード / 自動修復、Autopilot は Pod 単位課金、Standard はノード単位課金。
ノード管理を Google が行う GKE モード。Pod の vCPU/Memory 単位課金。ノードプール・OS パッチ・スケーリングが自動、セキュリティのベストプラクティス強制。
制約：DaemonSet 等の特権ワークロード制限。
従来型 GKE モード。ノードプール・マシンタイプ・OS を自分で選択。
特徴：1 ノードあたり 最大 110 Pod、カスタムノードイメージ可能、Cluster Autoscaler / NAP と組み合わせ運用。
Kubernetes の最小実行単位。1 つ以上のコンテナを共有ネットワーク・ストレージ namespace で実行。
Pod のレプリカ管理 / Rolling Update / Rollback を担う Kubernetes リソース。kubectl rollout undo でロールバック。strategy: RollingUpdate / Recreate。ReplicaSet を内部管理。
Pod 群への安定したネットワーク到達点。ClusterIP / NodePort / LoadBalancer / ExternalName の 4 種類。
CPU / メモリ / カスタムメトリクスに基づき Pod レプリカ数 を増減。最小スケール間隔 15 秒。VPA と組み合わせると競合する点に注意。
Pod のリクエスト・リミット（CPU/Mem） を自動調整。Off / Initial / Auto モード。Auto モードは Pod 再起動を伴う。HPA と同 metric では併用不可。
Pod スケジュール失敗時にノードを追加・余剰時に削除。NAP と組み合わせるとマシンタイプ自動選択も可能。
Voluntary Disruption（ノードメンテ・アップグレード）時に 最低稼働 Pod 数を保証。minAvailable / maxUnavailable。Surge Upgrade 中の可用性確保に必須。
GKE Enterprise のマルチクラスタ管理単位。Config Sync / Policy Controller / Cloud Service Mesh を Fleet 全体に適用。Multi-cluster Ingress / Services の基盤。
複数 GKE クラスタにまたがる Global LB を構築。Fleet 必須。リージョン障害自動フェイルオーバー、トラフィック分散。
Git → Fleet 内全クラスタへマニフェスト一括同期する GitOps ツール。RootSync / RepoSync の 2 種類。旧 Anthos Config Management の一部。
試験：「マルチクラスタへ Git からマニフェスト同期」→ Config Sync。
OPA/Gatekeeper ベースの K8s ポリシー強制。Constraint Template で team ラベル必須・特権コンテナ禁止等を宣言。Fleet 全体に適用。
旧 Anthos Service Mesh（ASM）。マネージド Istio。
自動収集：Metrics → Cloud Monitoring（GMP 互換）、Access logs → Cloud Logging、Traces → Cloud Trace。
試験：「アプリ無改造で mTLS / 4 Golden Signals / 詳細トラフィック制御」→ Cloud Service Mesh。
K8s ServiceAccount を Google ServiceAccount にバインドし、Pod が SA キーなし で GCP API を呼べる。
試験：「GKE Pod から GCP API、SA 鍵なし」→ Workload Identity for GKE（WIF とは別物）。
GCP マネージド Terraform 実行サービス。State 管理・Lock 制御を GCP が代行、IAM ベースで API 呼び出し可能。Cloud Build から gcloud infra-manager deployments apply で実行可能。
試験：「マネージド Terraform 実行サービス」→ Infrastructure Manager。Deployment Manager は新規利用非推奨。
HashiCorp の IaC ツール。GCP は公式 Provider を提供。State は GCS バケットに保存、Lock は GCS のオブジェクトロックで実装。大規模では State を環境・サービス別に分割し、terraform_remote_state / data ソースで参照する。
試験：「Terraform Workspaces で環境分離」は不正解（blast radius が減らない）。
Git を信頼源とする宣言的同期方式。Push 型（CI/CD）と Pull 型（Argo CD / Flux / Config Sync）。差分検出・自動修復が特徴。
外部 IdP（GitHub Actions / AWS / OIDC）→ STS → SA Impersonation のフローで、SA 鍵なし に外部 CI/CD から GCP API を呼べる仕組み。
構造：Workload Identity Pool → Provider（OIDC）→ attribute-mapping → attribute-condition → principalSet://... 形式で SA に roles/iam.workloadIdentityUser を付与。
試験：「外部 CI/CD → GCP の認証 / SA キー廃止」→ WIF が即答。SA キーを Secret Manager に置き換えるのはキー廃止にならない。
デプロイ前にイメージの 署名・属性検証 を行う Admission Controller。
設定：evaluationMode: REQUIRE_ATTESTATION で署名必須、enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG でブロック＋監査ログ、admissionWhitelistPatterns で例外指定（例：gcr.io/google_containers/*）。
Continuous Validation (CV)：ランタイムでも違反を検出。
Breakglass：緊急時の強制デプロイ（監査ログ記録あり）。
Binary Authorization の署名検証者。PGP / KMS 鍵で公開鍵を登録。Cloud Build のステップで gcr.io/cloud-builders/binauthz-attestation から attestation を生成。
Binary Authorization の署名情報。「このイメージはテストパス済み」「このイメージは脆弱性スキャン済み」等の事実を Attestor が署名して付与。
Binary Authorization のランタイム検証機能。デプロイ後に Policy 違反イメージが動いていないかを継続的にチェックし違反を Logging へ。
サプライチェーン信頼性レベルのフレームワーク。
Level 1：ビルドプロセス文書化。
Level 2：バージョン管理 + 認証ビルドサービス + provenance。
Level 3：hermetic build + 改ざん防止 provenance。
Level 4：two-person review + reproducible build。
Cloud Build は Level 3 相当の provenance を自動生成。
ビルドのメタデータ（誰が・いつ・何を・どのソースから・どのビルダーで作ったか）。Cloud Build が SLSA Level 3 相当の Provenance を provenance.json として自動生成し AR の Image に付与。
ソフトウェアの部品表（依存ライブラリ・バージョン一覧）。Artifact Analysis が SPDX / CycloneDX 形式で自動生成。脆弱性発生時の影響範囲特定に必須。
サプライチェーン保護の統合製品。Cloud Build + Artifact Registry + Artifact Analysis + Binary Authorization + Assured OSS を統合し SDLC 全体を保護。
Google が CVE スキャン・脆弱性修正済みの OSS パッケージ（Java / Python など）を提供。AR の Maven / PyPI Remote として利用可能。サプライチェーン信頼性向上。
マネージドな秘密情報ストア。API キー、DB パスワード、証明書などを保管。
特徴：自動 Rotation、Version 管理、IAM で粒度細かいアクセス制御、Pub/Sub で変更通知、Cloud Build / Cloud Deploy / Cloud Run / GKE と統合（CSI Driver）。
マネージド鍵管理サービス。Software / HSM / EKM の 3 種類のキー保護レベル。
Rotation：自動・手動。HSM：FIPS 140-2 Level 3。EKM：外部鍵管理サービスとの統合。
Cloud Build の availableSecrets や CMEK の基盤。
顧客が Cloud KMS で管理する鍵で GCP リソースを暗号化。GCS / Cloud SQL / GKE 等で対応。鍵ローテーション・無効化が顧客側で可能。
TLS 証明書のマネージド管理サービス。
機能：Google-managed（Let's Encrypt 連携自動更新）、Self-managed（持ち込み）、1 LB に 100K 証明書、Wildcard / SAN 対応、Certificate Map で複数証明書振り分け。
2024 GA。Cloud Run / Compute / GKE 向けの構成パラメータ集中管理。Secret ではない設定値（feature flag、URL、サイズ等）に最適。Version 管理 + IAM 制御。
旧 Cloud DLP。PII / PHI / クレジットカード番号など機密情報を 検出・分類・マスキング・トークン化。ログ・BigQuery・GCS・Pub/Sub に組み込み可能。GDPR / HIPAA / PCI DSS 対応。
GCP のメトリクス・ダッシュボード・アラート統合サービス。Metrics Explorer で MQL / PromQL クエリ、Dashboard、Alerting Policy、Notification Channel（メール / SMS / Slack / PagerDuty）、SLO 設定。
マネージド Prometheus。OSS Prometheus と PromQL 100% 互換、最大 24 ヶ月保持、自動スケール・HA。
2 モード：Managed Collection（GKE Add-on、新規推奨）／ Self-deployed Collection（既存 prometheus.yml / Operator を踏襲）。
試験：「既存 Prometheus がある」→ Self-deployed、「新規 GKE」→ Managed。
Prometheus Query Language。GMP で公式採用、Cloud Monitoring も対応。
主要関数：rate()、histogram_quantile()、sum by()、increase()、topk()、avg_over_time()。
Istio: histogram_quantile(0.99, sum by (le, destination_workload) (rate(istio_request_duration_milliseconds_bucket[5m])))。
信頼性の 社内目標。例：「99.9% のリクエストが 500ms 以内に完了」。SLA より厳しく、SLI より緩い。30 / 60 / 90 日 rolling が一般的。
数値関係：SLI（実測）> SLO（社内目標）> SLA（顧客契約）。
サービスの 実測指標。ユーザーが直接気にすることを測る原則：(1) ユーザーが気にする、(2) 集計可能、(3) シンプル、(4) 構造化。
主要タイプ：Request-based（API 向け）、Window-based（バッチ・freshness 向け）。
顧客との 法的契約。違反時にクレジット返還等のペナルティ。SLO より緩く設定（バッファを持たせる）。
1 − SLO で算出される「失敗の予算」。リリース判断の客観基準。
主要数値：99.9% → 43.2 分/月、99.95% → 21.6 分/月、99.99% → 4.32 分/月、99.999% → 25.9 秒/月。
予算枯渇時は新機能リリース停止、信頼性改善に集中（Error Budget Policy）。
Error Budget の消費速度。式 = エラー率 / (1 − SLO)。
例：エラー率 6% / (1 − 0.999) = 60×。1× で SLO 期間ちょうど予算枯渇、60× で約 12h で枯渇。
SRE Workbook Ch.5 の推奨アラート設計。short / long window の AND で誤検知防止 + 見落とし防止。
Fast：14.4× / 1h / 5m（予算 2% を 1h で消費）。Medium：6× / 6h / 30m（予算 5% を 6h で消費）。Slow：1× / 3d / 6h（予算 10% を 3d で消費）。
Cloud Monitoring のアラート設定。条件式 + Notification Channel + Auto-close + Documentation（playbook URL）。Multi-burn-rate / SLO ベースが推奨。
アラート通知先。Email / SMS / Slack / PagerDuty / Webhook / Pub/Sub / Google Chat / Cloud Mobile App。PagerDuty 統合は on-call ローテーションに使用。
外部からの HTTP / TCP / SSL の死活監視。単一エンドポイント用。複数地点（US / EU / APAC / South America）から監視。複数ステップは Synthetic Monitor。
Cloud Functions ベースの能動監視。複数ステップ・セッション維持・JSON 検証・ログイン → 検索 → カート → 決済のような E2E シナリオ。Cloud Monitoring に成功率・レイテンシメトリクスを送信。
ログから派生させるメトリクス。Counter（カウント）と Distribution（数値分布、ヒストグラム）の 2 種類。例：エラーログ件数、ログ内の処理時間。
SRE の 4 大監視指標。Latency / Traffic / Errors / Saturation。Cloud Service Mesh は Envoy サイドカーがこれらを自動収集。
VM 用の統合エージェント（fluentbit + OpenTelemetry 統合）。Legacy Logging Agent / Monitoring Agent の後継、Google の今後の機能追加基盤。config.yaml で receivers / processors / exporters を宣言。
試験：「Legacy → Ops Agent への移行」が頻出。
GCP のログ統合サービス（旧 Stackdriver Logging）。
構成：Logs Router → Sink（Storage / BigQuery / Pub/Sub / 他 Logging Bucket）+ Log Bucket（_Required：400 日固定、_Default：30 日変更可）+ Log Analytics（バケットで SQL 直接実行）。
取り込み課金：$0.50/GB、保持課金：別。
Cloud Console のログ検索 UI。LQL（Logging Query Language）でフィルタ。ヒストグラム / Live tail / Save query / Quick filter。Aggregated Sink の検証にも使う。
Logs Explorer のクエリ言語。例：resource.type="k8s_container" AND severity>=ERROR、jsonPayload.message=~"timeout"、httpRequest.status>=500、protoPayload.authenticationInfo.principalEmail="alice@example.com"。`labels.team="payment"` でラベルフィルタ。
取り込み直後のログを Sink へルーティングするコンポーネント。Inclusion filter / Exclusion filter で振り分け。Exclusion で ingestion 課金を直接削減。
ログのエクスポート先設定。宛先別ユースケース：
BigQuery：SQL 分析・ダッシュボード。
Pub/Sub：リアルタイム通知 / SIEM 連携。
Cloud Storage：長期保管・低コスト（10 年保管に最適）。
Logging Bucket：別プロジェクトのバケットへ。
Organization / Folder レベルで作成する Sink。--include-children 付きで 配下の全プロジェクト・全 Sink のログを 1 個の Sink で集約。新規プロジェクト追加時も自動でカバー。
試験：「組織横断ログ集約」→ Aggregated Sink が即答。
Log Router の Exclusion filter。ingestion 課金前 にログを破棄するためコスト削減効果が大きい。例：httpRequest.userAgent="kube-probe/1.27" のような大量ノイズログ。
優先順：Exclusion → Sampling → Retention 短縮。
ログの保存先。_Required：400 日固定変更不可、Admin Activity / System Event / Policy Denied 用、無料。_Default：30 日（変更可）、Data Access 用。Custom Bucket：ユーザ定義保持期間、Log Analytics 対応。
Logging Bucket 内のログに対して BigQuery 風 SQL を直接実行できる機能。Sink で BQ へエクスポートしなくても分析可能。Log Bucket を Upgrade して有効化。
GCP の監査ログ 4 種：Admin Activity（常時有効・無料）、Data Access（明示有効化必須・課金）、System Event（常時有効）、Policy Denied（常時有効・課金）。
試験：「HIPAA / SOX / PCI 対応で誰がデータ読んだか」→ Data Access logs を有効化。
IAM 変更、リソース作成 / 削除など管理操作。常時有効・無効化不可・無料。_Required バケット保管 400 日固定。
BigQuery 以外は デフォルト無効。コンプラ対応では明示的に有効化必須。データ読み取り（READ）・更新（WRITE）の細粒度ログ。課金あり（誤って全 API 有効化すると大量課金）。
VPC SC / IAM 拒否ログ。常時有効、課金あり。セキュリティインシデント分析に必須。
分散トレースサービス。OpenTelemetry / Stackdriver Trace SDK / Zipkin / Jaeger 互換。
機能：Trace Waterfall、p50/p99 分布、Span 検索、Logging との trace ID 紐付け（trace=projects/PROJECT/traces/TRACE_ID）。保持 30 日。
トレース内の 1 つの操作単位（例：DB クエリ、HTTP リクエスト）。親子関係を持ち、Waterfall として可視化。OTel SDK が自動生成。
1 リクエストを横断的に識別する ID。Logging / Profiler / Error Reporting と紐付け。Cloud Run / Functions は自動付与、GKE は OTel SDK 必要。
CNCF 標準の可観測性 SDK + プロトコル。言語非依存でメトリクス・ログ・トレースを統一。
構成：SDK（auto / manual instrumentation）→ Collector（OTLP）→ Backend（Cloud Trace / GMP / Cloud Logging）。Google 推奨。
OpenTelemetry のテレメトリ収集・処理・転送エージェント。Sidecar / DaemonSet / 集中 deployment。Tail-based sampling はここでしか実現できない。Receivers / Processors / Exporters で構成。
分散トレースの 標準ヘッダ仕様。traceparent / tracestate。GCP 旧式の X-Cloud-Trace-Context から W3C 標準へ移行推奨。マルチクラウド・OSS 連携で互換性が高い。
トレース完了後に内容を見てサンプリング判定する方式。エラー span や高レイテンシ span を 100% 保持しつつ、それ以外を低レートで採取。OTel Collector でのみ実現可能（SDK 側 Head-based では不可）。
試験：「エラー trace を必ず残しつつコスト削減」→ Tail-based Sampling。
本番アプリの継続的プロファイラ。CPU、Heap、Wall time、Contention（ロック待ち）、Threads。
言語別対応：Python は CPU / Wall のみ（Heap 不可）、Node は Wall なし、Java は Heap allocation 不可、Go は全種対応。
選定：「レイテンシ長 + CPU 低」→ Wall-clock、「CPU 高」→ CPU、「メモリ膨張」→ Heap。
現在のメモリ割当のスナップショット。OOM 調査やメモリリーク特定に使用。Go / Java / Node.js で取得可能（Python 不可）。1 時間後と 6 時間後で diff を取り増加箇所を特定するパターンが頻出。
例外・エラーログを 自動グルーピング し、頻度・初出・最新発生時刻を集約。Cloud Logging のエラーから自動検出。GitHub Issue / Jira 連携。修正検知時に自動 close。
手作業・繰り返し可能・自動化可能・戦術的・長期的価値なし・サービス成長と線形比例する運用作業。SRE Book は 運用作業の 50% 未満をトイルにと規定。Toil を定量化し削減ターゲットを設定。
Google が提唱したエンジニアリングの方法論。「class SRE implements DevOps」。
柱：SLI/SLO/SLA / Error Budget / Toil 削減 / Blameless Postmortem / 4 Golden Signals / SRE-Dev 共有責任。
DevOps の理想を実装する一形態と位置付け。
開発と運用の壁を取り払う文化・実践。
5 つの柱：(1) 組織サイロ削減、(2) 失敗を当然視、(3) 段階的変更、(4) ツール / 自動化、(5) 全てを計測。
DORA Research で実装の成熟度を測定（4 Keys）。
インシデント後の振り返り文書。Blameless 原則。タイムライン、影響範囲、根本原因、復旧手順、再発防止策。Action items を担当者付きで明記。Game Day / Wheel of Misfortune で訓練。
失敗を個人の責めにせず、システムやプロセスの改善材料とする文化。Five Whys で根本原因を追究。「誰が」ではなく「なぜ」「次にどうするか」を問う。
インシデント対応の指揮官。技術的判断ではなく コーディネーション・優先順位判断を担当。ICS の 4 役割：IC / Ops Lead / Communications Lead / Planning Lead。
米国消防由来の指揮統制体系。SRE の大規模インシデント対応で標準。役割：
IC (Incident Commander)：全体指揮。
Ops Lead：実作業の責任。
Communications Lead：ステークホルダー連絡・Status Page 更新。
Planning Lead：シフト交代・引き継ぎ・記録。
インシデント対応の最優先原則。原因調査より影響緩和を先に。手順：(1) drain（トラフィック誘導）→ (2) redirect（別リージョン）→ (3) capacity（容量追加）→ (4) rollback（ロールバック）。原因調査は緩和後。
機能の有効化 / 無効化を デプロイなし に動的切替できる仕組み。Canary や Kill switch の実装に使用。デプロイとリリースを分離する DORA 推奨プラクティス。LaunchDarkly / Split.io / 自前実装。
GCP の IaaS 仮想マシン。OS 自由、Custom Machine Type、Sole Tenant、Confidential VM、Spot 対応。レガシー移行、特殊 OS、ステートフルワークロード、BYOL/ライセンス用途で選定。
同一テンプレートから VM を 自動スケール・自動回復・自動更新。Regional MIG（複数ゾーンに分散）、Stateful MIG（永続ディスク・IP 維持）。Rolling Update / Canary Update 対応。Cloud Load Balancing のバックエンド。
余剰キャパシティを利用した 最大 91% 割引 の VM。Preemptible VM の後継。24h 強制停止なし（Preemptible は 24h 強制）。中断通知 30 秒。ステートレス・中断許容バッチに最適。GKE Spot ノードプールでも利用可。
サーバーレスコンテナサービス。Knative ベース。
特徴：自動スケール（0 → N）、Concurrency / Min instances / CPU always allocated / CPU boost、Traffic Splitting（複数 Revision）、自動 HTTPS、複数リージョン同時デプロイ、Eventarc 統合。
1 インスタンスが同時処理するリクエスト数。デフォルト 80、最大 1000。低くするとレイテンシ改善、高くするとコスト効率改善。WebSocket / SSE では 1 が必須。
常時起動する最小インスタンス数。Cold start 回避に有効だが、idle 時間も課金。レイテンシ厳しいアプリは 1 以上に設定。
GPU / TPU 向けのキュー型スケジューラ。
Flex-start mode：最大 7 日まで待機、リソース確保時に開始。
Calendar mode：将来時刻を指定して予約。
LLM 学習・ML バッチで GPU/TPU の availability を解決。
VM のキャパシティ予約。Single-project / Shared / Specific machine type。CUD と組み合わせて 確実な availability + コスト削減。重要バッチ・DR 用に確保。
GCP の仮想ネットワーク。Global 単位（リージョン跨ぎ）。Subnet はリージョン単位、Auto / Custom モード。Firewall Rule、Routes、Cloud Router を含む。1 Project に複数 VPC 可能。
1 つの Host Project の VPC を複数 Service Project で共有。中央 Network チームが集中管理しつつ、各 Service Project は IAM / リソース管理を独立保有。
試験：「複数プロジェクトでネットワーク集中管理 + リソース分散管理」→ Shared VPC が即答。
マネージドサービス（Cloud SQL / Memorystore / 自社内 SaaS）へ サービスごとのエンドポイント IP でプライベートアクセス。サブネット重複可、推移性問題なし。
試験：「マネージドサービスにプライベート接続（2024 以降）」→ PSC が Google 推奨。Private Services Access の後継。
L4 / L7 のグローバル / リージョナル LB。
主要タイプ：Global External Application LB（L7、Global Anycast）、Cross-region Internal Application LB（リージョン障害 auto failover）、Regional External Network LB（L4）、Internal Network LB（L4 passthrough）。Cloud CDN / Cloud Armor / Identity-Aware Proxy と統合。
Premium Tier：Google グローバル NW 経由、低レイテンシ・高信頼。デフォルト。
Standard Tier：リージョナル ISP 経由、コスト削減。
試験：「コスト最優先・同一リージョン内」→ Standard、「グローバル品質」→ Premium。
オブジェクトストレージ。クラス：Standard / Nearline（30 日）/ Coldline（90 日）/ Archive（365 日）。Autoclass で自動最適化。Object Lifecycle Management でクラス変更・削除。Object Versioning、Uniform Bucket-Level Access、Customer-Managed Encryption Keys (CMEK)、Signed URL。ログの長期保管先（10 年保管）に最適。
誰が（Principal）何を（Resource）どう操作できるか（Role）を制御。
3 種類のロール：Basic（Owner/Editor/Viewer、非推奨）、Predefined（細粒度、推奨）、Custom（独自定義）。
継承：親（Org / Folder / Project）→ 子に伝播。
原則：最小権限、Group ベース付与、SA 鍵廃止。
Google 提供の細粒度ロール（例：roles/clouddeploy.releaser、roles/storage.objectViewer）。Basic Role より権限を絞れる。試験では Custom より Predefined を選ぶ。
非人間（アプリ / VM / GKE Pod）が GCP API を呼ぶための ID。
主要：SA Email、SA Key（廃止推奨）、Workload Identity（GKE）、WIF（外部 IdP）、SA Impersonation（短期トークン）。
原則：SA 鍵を作らない、必要なら Secret Manager + 短期ローテーション。
GCP リソース階層の最上位。Cloud Identity / Workspace と紐づく。Org Policy の一元適用、課金管理、IAM の根。
Org 配下のグルーピング単位。部署・環境（dev/stg/prod）を表現。最大 10 階層ネスト可能、IAM 継承。Org Policy / Aggregated Sink の境界。
GCP の リソース・課金・API の基本単位。すべてのリソースは Project に属する。Project ID は世界一意・変更不可、Project Number は数値 ID。
組織レベルの制約（リソース作成制限、SA 鍵無効化、データ常駐リージョン制限等）。階層に継承（親 → 子）、子で上書き可。Dry Run モード（2024 GA）で本番適用前に違反検出可能。
例：gcp.resourceLocations（データ常駐）、iam.disableServiceAccountKeyCreation、compute.requireOsLogin。
Org Policy の制約条件。List（許可 / 拒否リスト）/ Boolean（オン / オフ）。Built-in と Custom Constraint（CEL ベース）。Custom Constraint は API レベルで細かい制限が可能。
Organization → Folder → Project → Resource の 4 階層。IAM / Org Policy が 継承 される。環境分離・部署分離は Folder、論理境界は Project。
1 年 / 3 年 commit で割引。
Resource-based CUD：vCPU / Mem 固定、最大 57-70% 割引（3y）。
適用：Compute Engine / Cloud SQL / Spanner 等のリージョン単位。
余剰時にプロジェクト間で適用可。
$ ベースの commit。柔軟にマシンタイプ・リージョン跨ぎで適用可。
1y で 28%、3y で 46% 割引。Cloud Run / GKE Autopilot にも適用可（Resource-based は不可）。
GCP の最適化推奨エンジン。
5 カテゴリ：Cost / Security / Performance / Manageability / Reliability。
主要 Recommendation：Idle VM、Idle PD、Idle IP、Right-sizing、IAM rightsizing、Firewall insight。
3 経路：API / BigQuery Export / Recommendation Hub。組織横断 + 自動化なら BigQuery Export + Pub/Sub パターン。
Recommender の上位概念。Insights（事実）+ Recommendations（処方箋）の二段構成。
4 大 Insight：Lateral movement insight、Firewall insight、Policy insight、Reliability insight。
試験：「過剰 IAM 権限の検出 + 縮小」→ Lateral movement insight + IAM Recommender。
クラウドコスト運用フレームワーク。
3 フェーズ：
Inform：可視化（Cost Dashboard、Billing Export to BQ、ShowBack）。
Optimize：Rightsizing、Spot、CUD、Recommender。
Operate：継続改善、Budget アラート、Forecast。
マネージドな ブラウザ / IDE ベースの開発環境。VPC 内に配置、Persistent Disk、Custom Container Image、Gemini Code Assist 統合。
構成：Cluster → Configuration → Workstation。Container Image でツール標準化、SSH / VS Code / IntelliJ で接続。
試験：「セキュアな開発環境（VPC 内、データ持出禁止）」→ Cloud Workstations。
VS Code / IntelliJ / Cloud Workstations / Cloud Shell Editor 向けの AI コーディング支援。旧 Duet AI for Developers。
機能：コード補完、関数生成、リファクタリング、テスト生成、コードレビュー、コード説明、複数ファイル対話。Enterprise エディションは社内コードベース学習可能。
GCP Console 全体に統合された AI 運用支援。旧 Duet AI in Google Cloud。
機能：自然言語によるリソース操作、トラブルシュート、ログ要約、異常検知、最適化提案、IAM 推奨、設計レビュー、Investigations（インシデント解析）、Cost / Security 提案。
2024 GA。ターミナル統合の AI アシスタント。gemini コマンドで自然言語からシェルコマンド生成、エラー解析、bash / gcloud / kubectl のヘルプ。Cloud Shell / Workstations にプリインストール。
DevOps Research and Assessment による 4 大成熟度指標。
1. Deployment Frequency：デプロイ頻度（Elite: 日次以上）。
2. Lead Time for Changes：commit → 本番までの時間（Elite: 1 日以内）。
3. Change Failure Rate：本番デプロイの失敗率（Elite: 0-15%）。
4. MTTR (Mean Time To Restore)：障害復旧時間（Elite: 1 時間以内）。
Google が DORA を買収、毎年 State of DevOps Report を発行。
DORA #1。デプロイの頻度。Elite = 日次以上 / High = 週次 / Medium = 月次 / Low = 半年に 1 回未満。小さくリリースする文化の指標。
DORA #2。コミットから本番リリースまでの時間。Elite = 1 日以内。短いほど Feedback loop が速く改善サイクルが回る。
DORA #3。本番デプロイの失敗率（ロールバック含む）。Elite = 0-15%。テスト品質と CI の充実度の指標。
DORA #4。障害復旧までの平均時間。Elite = 1 時間以内。Feature Flag / Canary / 自動ロールバックで短縮。
関連：MTTD（検出時間）+ MTTR = 障害時間。
2 つの環境（Blue=現行 / Green=新）を準備し、ロードバランサで瞬時切替。高速ロールバックが利点。リソースコスト 2 倍がデメリット。Cloud Deploy で対応。
少数のトラフィック（5-10%）を新バージョンに流して検証 → 段階的に拡大。Cloud Deploy の canaryDeployment.percentages: [10, 25, 50] + verify: true で実装。自動ロールバック対応。
1 Pod ずつ順次置換。Kubernetes の strategy: RollingUpdate がデフォルト。maxSurge（増加上限）/ maxUnavailable（停止上限）で速度制御。リソース効率良いが Rollback はやや遅い。
複数 Revision にトラフィックを比率で分配。Cloud Run / Cloud Deploy（Gateway API）。A/B Testing、Canary、Blue-Green の基盤。
開発者の変更を頻繁にメインブランチへ統合し、自動ビルド・自動テストする実践。Trunk-Based Development と相性が良い。Cloud Build がデフォルト。
main ブランチがいつでも本番リリース可能な状態に維持。承認後にリリース。Cloud Deploy がデフォルト。
vs Continuous Deployment：CD は手動承認、Continuous Deployment は完全自動。
| 略語 | 正式名 | カテゴリ |
|---|---|---|
| AR | Artifact Registry | CI/CD |
| ASM | Anthos Service Mesh（→ Cloud Service Mesh） | K8s |
| BinAuth | Binary Authorization | Security |
| CD | Continuous Delivery / Deployment | DevOps |
| CFT | Cloud Foundation Toolkit | IaC |
| CI | Continuous Integration | DevOps |
| CMEK | Customer-Managed Encryption Keys | Security |
| CRD | Custom Resource Definition（K8s） | K8s |
| CUD | Committed Use Discount | FinOps |
| CV | Continuous Validation（BinAuth） | Security |
| CVE | Common Vulnerabilities and Exposures | Security |
| DLP | Data Loss Prevention（→ Sensitive Data Protection） | Security |
| DWS | Dynamic Workload Scheduler | Compute |
| EKM | External Key Manager | Security |
| GCE | Google Compute Engine | Compute |
| GCR | Google Container Registry（→ Artifact Registry） | CI/CD |
| GCS | Google Cloud Storage | Storage |
| GKE | Google Kubernetes Engine | K8s |
| GMP | Google Managed Service for Prometheus | Observability |
| HPA | Horizontal Pod Autoscaler | K8s |
| HSM | Hardware Security Module | Security |
| IaC | Infrastructure as Code | IaC |
| IAM | Identity and Access Management | Security |
| IAP | Identity-Aware Proxy | Security |
| IC | Incident Commander | SRE |
| ICS | Incident Command System | SRE |
| IM | Infrastructure Manager | IaC |
| KMS | Key Management Service | Security |
| LQL | Logging Query Language | Observability |
| MIG | Managed Instance Group | Compute |
| MTTD | Mean Time To Detection | DevOps |
| MTTR | Mean Time To Recovery / Restore | DevOps |
| NAP | Node Auto-Provisioning | K8s |
| OIDC | OpenID Connect | IaC |
| OPA | Open Policy Agent | K8s |
| OTel | OpenTelemetry | Observability |
| OTLP | OpenTelemetry Protocol | Observability |
| PCDE | Professional Cloud DevOps Engineer | — |
| PDB | Pod Disruption Budget | K8s |
| PromQL | Prometheus Query Language | Observability |
| PSC | Private Service Connect | Network |
| RBAC | Role-Based Access Control | K8s |
| RCA | Root Cause Analysis | SRE |
| SA | Service Account | Security |
| SBOM | Software Bill of Materials | Security |
| SDS | Software Delivery Shield | Security |
| SLA | Service Level Agreement | SRE |
| SLI | Service Level Indicator | SRE |
| SLO | Service Level Objective | SRE |
| SLSA | Supply-chain Levels for Software Artifacts | Security |
| SRE | Site Reliability Engineering | SRE |
| SUD | Sustained Use Discount | FinOps |
| TPU | Tensor Processing Unit | Compute |
| VPA | Vertical Pod Autoscaler | K8s |
| VPC | Virtual Private Cloud | Network |
| VPC SC | VPC Service Controls | Security |
| WAF | Web Application Firewall（Cloud Armor） | Network |
| WIF | Workload Identity Federation | IaC |