Skip to content
Published on

CNPE(Certified Cloud Native Platform Engineer)完全ガイド — 試験範囲から実践技術スタックまで

Authors
  • Name
    Twitter

1. CNPEとは?

**CNPE(Certified Cloud Native Platform Engineer)は、CNCFが2025年11月に公式発表した最上級レベルの資格証である。エンタープライズ規模の内部開発者プラットフォーム(IDP)**を設計・運用する高度な実務能力を検証する。

CNCF CTOのChris Aniszczyk氏によると、この資格は「プラットフォームアーキテクチャ、GitOps、Observability、セキュリティ、開発者体験を網羅するプロダクションレベルのクラウドネイティブシステム能力」を認定する。

1.1 試験形式

項目内容
時間120分
形式100%実技型(Performance-based)、オンライン監督
環境Linuxベースのリモートデスクトップ(ターミナル+Webインターフェース)
オープンブックkubernetes.io/docsおよび課題別Quick Referenceドキュメント参照可能
受験料$445 USD
再受験1回無料付き
有効期間2年
シミュレーターKiller.sh 2回付き

1.2 前提条件

公式な必須前提条件はないが、CNPA(Certified Cloud Native Platform Associate)またはCKAレベルのKubernetes管理経験が強く推奨される。

1.3 対象者

  • 熟練したPlatform Engineer
  • Senior DevOps / SRE
  • Platform Architect
  • Infrastructure Engineer

2. 試験ドメイン概要

CNPE試験は5つのコアドメインで構成される。

ドメイン比重
GitOpsおよび継続的デリバリー(GitOps and Continuous Delivery)25%
プラットフォームAPIおよびセルフサービス(Platform APIs and Self-Service Capabilities)25%
観測性および運用(Observability and Operations)20%
プラットフォームアーキテクチャおよびインフラ(Platform Architecture and Infrastructure)15%
セキュリティおよびポリシー適用(Security and Policy Enforcement)15%

業界で頻繁に言及されるリファレンスアーキテクチャはBACKスタックBackstage + Argo CD + Crossplane + Kyvernoである。ただし、試験はベンダー中立であるため、Argo CDの代わりにFlux、Kyvernoの代わりにOPA/Gatekeeperなどに置き換え可能である。


3. Domain 1:GitOpsおよび継続的デリバリー(25%)

3.1 GitOpsの核心原則

OpenGitOps(opengitops.dev)で定義された4つの核心原則である。

原則説明
Declarativeシステムの望ましい状態を宣言的に表現する
Versioned and Immutable望ましい状態をGitに保存し、変更履歴を追跡する
Pulled Automaticallyエージェントがソースから望ましい状態を自動的に取得する(PushではなくPull)
Continuously Reconciled実際の状態と望ましい状態の差異を継続的に検知し自動復元する

3.2 Argo CDアーキテクチャ

Argo CDはKubernetes向けの宣言的GitOps CDツールで、3つのコアコンポーネントで構成される。

  • API Serverargocd-server):gRPC/RESTサーバーでWeb UIとCLI APIを提供する。アプリケーション管理、RBAC適用、Git Webhook受信を担当する。
  • Repository Serverargocd-repo-server):Gitリポジトリのローカルキャッシュを維持し、リビジョンとパスに基づくKubernetesマニフェストを生成する。
  • Application Controllerargocd-application-controller):実行中のアプリケーションを継続監視し、現在の状態とGitの目標状態を比較してOutOfSyncを検知する。

Application CRD例:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true # Gitから削除されたリソースを削除
      selfHeal: true # 手動変更を自動復元

3.3 Argo CD Syncポリシー

ポリシーデフォルト説明
automateddisabledOutOfSync検知時に自動同期
prunefalseGitで削除されたリソースをクラスタからも削除
selfHealfalseクラスタの手動変更(drift)をGit状態に自動復元
allowEmptyfalseマニフェストが0個の時に同期を許可するかどうか

3.4 ApplicationSetによるマルチクラスタデプロイ

ApplicationSetは単一テンプレートから複数のApplicationリソースを生成するCRDである。Generatorを通じてパラメータを動的に生成する。

主要Generator:

Generator説明
ClusterArgo CDに登録されたクラスタを自動検出
Git Directoryリポジトリのディレクトリ構造からアプリを生成
Matrix2つのGeneratorのパラメータを組み合わせ(直積)
Pull RequestオープンなPRごとにプレビュー環境を生成
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-apps
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: '{{.name}}-my-app'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/apps.git
        targetRevision: HEAD
        path: deploy/production
      destination:
        server: '{{.server}}'
        namespace: my-app

3.5 Flux CD

FluxはCNCF GitOps ToolkitベースのCDツールで、5つの専門化されたコントローラで構成される。

コントローラCRD役割
Source ControllerGitRepository, HelmRepository, OCIRepositoryGit/Helm/OCIからアーティファクト取得
Kustomize ControllerKustomizationKustomizeオーバーレイまたはプレーンな YAMLの適用
Helm ControllerHelmReleaseHelmチャートのライフサイクル管理
Notification ControllerProvider, Alert, Receiver通知発送およびインバウンドWebhook処理
Image AutomationImageRepository, ImagePolicyコンテナレジストリスキャンおよび自動更新

Flux Kustomization例:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: my-app
  path: ./deploy/production
  prune: true
  wait: true
  dependsOn:
    - name: cert-manager
    - name: ingress-nginx
  postBuild:
    substitute:
      CLUSTER_NAME: production
      DOMAIN: example.com

3.6 Progressive Delivery:Argo Rollouts

Argo RolloutsはCanary、Blue-Greenなどの段階的デプロイ戦略を自動化する。

Canaryデプロイ例:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    canary:
      canaryService: my-app-canary
      stableService: my-app-stable
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
        - setWeight: 100
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: myapp:v2

Blue-Greenデプロイの主要設定:

設定説明
autoPromotionEnabledプレビュー後の自動プロモーション(デフォルト:true)
autoPromotionSeconds自動プロモーションまでの待機時間
scaleDownDelaySeconds旧バージョンPod終了までの待機時間(デフォルト:30秒)
prePromotionAnalysisトラフィック切替前のメトリクス検証
postPromotionAnalysis切替後の検証、失敗時ロールバック

4. Domain 2:プラットフォームAPIおよびセルフサービス(25%)

4.1 Crossplaneによるセルフサービスインフラ構築

CrossplaneはKubernetesを汎用Control Planeに拡張し、クラウドインフラをKubernetes APIでプロビジョニングできるようにする。

アーキテクチャ: Provider -> Managed Resources -> Compositions -> Composite Resources(XRDs)

Composite Resource Definition(XRD):

apiVersion: apiextensions.crossplane.io/v2
kind: CompositeResourceDefinition
metadata:
  name: mydatabases.example.org
spec:
  scope: Namespaced
  group: example.org
  names:
    kind: XMyDatabase
    plural: mydatabases
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                region:
                  type: string
                size:
                  type: string
              required:
                - region
                - size

Composition(実装テンプレート):

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: example-database
spec:
  compositeTypeRef:
    apiVersion: example.org/v1alpha1
    kind: XMyDatabase
  mode: Pipeline
  pipeline:
    - step: patch-and-transform
      functionRef:
        name: function-patch-and-transform
      input:
        apiVersion: pt.fn.crossplane.io/v1beta1
        kind: Resources
        resources:
          - name: rds-instance
            base:
              apiVersion: rds.aws.m.upbound.io/v1beta1
              kind: Instance
              spec:
                forProvider:
                  region: us-east-2
                  engine: postgres
                  instanceClass: db.t3.micro
            patches:
              - type: FromCompositeFieldPath
                fromFieldPath: spec.region
                toFieldPath: spec.forProvider.region

セルフサービスパターンは以下の通りである:

  1. プラットフォームチームがXRD(APIスキーマ)とComposition(実装)を定義する。
  2. 開発者は自分のNamespaceでXRDインスタンスを作成する。
  3. Crossplaneが自動的にクラウドリソースをプロビジョニングし管理する。
  4. 開発者はクラウドProvider APIを直接扱わない。

4.2 Backstage:Internal Developer Portal

Backstage(CNCF Incubating)はSpotifyが開発したオープンソースIDPフレームワークである。

コア機能:

機能説明
Software Catalogすべてのソフトウェア資産の中央レジストリ
Software Templates標準化されたプロジェクト作成の自動化
TechDocsDocs-like-code方式の技術ドキュメント
Pluginアーキテクチャ拡張可能なプラグインシステム

Software Catalogエンティティ定義:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Payment processing microservice
  tags:
    - java
    - spring-boot
spec:
  type: service
  lifecycle: production
  owner: payments-team
  system: payment-platform
  dependsOn:
    - resource:default/payments-db
  providesApis:
    - payment-api

Software Template例:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: new-microservice
  title: Create New Microservice
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service Details
      required:
        - name
        - owner
      properties:
        name:
          title: Service Name
          type: string
        owner:
          title: Owner Team
          type: string
          ui:field: OwnerPicker
  steps:
    - id: fetchBase
      name: Fetch Template
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{parameters.name}}
    - id: publish
      name: Publish to GitHub
      action: publish:github
      input:
        repoUrl: github.com?owner=myorg&repo=${{parameters.name}}
    - id: register
      name: Register in Catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{steps.publish.output.repoContentsUrl}}
        catalogInfoPath: /catalog-info.yaml

4.3 CRDとOperatorパターン

プラットフォームAPIの基盤はKubernetesのCustom Resource Definitions(CRD)Operatorパターンである。

Operatorはドメイン固有の運用知識をKubernetesコントローラにエンコードする。

Control Loop:
  1. Observe: Custom Resourceの変更を監視
  2. Analyze: 現在の状態と目標状態を比較
  3. Act: 従属リソースの作成/更新/削除で状態を調整

主要Operatorフレームワーク:

フレームワーク言語
KubebuilderGo
Operator SDKGo, Ansible, Helm
KopfPython
kube-rsRust
Metacontrollerすべての言語(Webhook方式)

5. Domain 3:観測性および運用(20%)

5.1 OpenTelemetry

OpenTelemetry(OTel)はCNCF Observabilityフレームワークで、3つのコアシグナルを統合収集する。

シグナル説明用途
Traces分散システムでのリクエスト経路追跡マイクロサービス間リクエストフローの理解
Metricsランタイム測定値(Counter, Gauge, Histogram)パフォーマンス推移およびリソース使用率モニタリング
Logsタイムスタンプ付きイベント記録特定時点のデバッグコンテキスト

OTel Collector設定:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 2000
  batch:
    timeout: 10s

exporters:
  otlp/jaeger:
    endpoint: jaeger-collector:4317
    tls:
      insecure: true
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/jaeger]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus]

Kubernetes自動計装:

OTel Operatorを使用すればコード修正なしで自動計装が可能である。

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: demo-instrumentation
spec:
  exporter:
    endpoint: http://otel-collector:4318
  propagators:
    - tracecontext
    - baggage
  sampler:
    type: parentbased_traceidratio
    argument: '1'

Deploymentにアノテーション追加で自動計装を有効化:

metadata:
  annotations:
    instrumentation.opentelemetry.io/inject-java: 'true' # Java
    instrumentation.opentelemetry.io/inject-python: 'true' # Python
    instrumentation.opentelemetry.io/inject-nodejs: 'true' # Node.js

5.2 PrometheusとGrafanaスタック

Prometheusアーキテクチャ:

コンポーネント役割
Prometheus Server時系列データ収集および保存(Pull型)
Alertmanagerアラートルーティング、重複排除、送信
Exportersサードパーティシステムのメトリクスアダプタ
Service DiscoveryKubernetes、Consul、DNSなどによる自動ターゲット検出

ServiceMonitor CRD(Prometheus Operator):

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app-monitor
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

PromQLコアクエリ:

# 秒あたりリクエスト率(5分ウィンドウ)
rate(http_requests_total[5m])

# Jobごとの合計
sum by (job) (rate(http_requests_total[5m]))

# P99レイテンシ
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# エラー率
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Grafana Observabilityスタック:

                  +-----------+
                  |  Grafana  |  (ダッシュボード、アラート)
                  +-----+-----+
                        |
           +------------+------------+
           |            |            |
      +----+----+  +---+---+  +-----+-----+
      |  Mimir  |  |  Loki |  |   Tempo   |
      | Metrics |  |  Logs |  |  Traces   |
      +----+----+  +---+---+  +-----+-----+
           |            |            |
           +------------+------------+
                        |
               +--------+--------+
               | OTel Collector  |
               +-----------------+
                        |
                [Applications]
  • Mimir:水平スケール可能な長期メトリクスストレージ
  • Loki:ラベルベースインデックスの軽量ログ集約システム
  • Tempo:大規模分散トレーシングバックエンド

5.3 SLI/SLOとError Budget

概念定義
SLIサービス性能の定量的測定値リクエスト成功率、P99レイテンシ
SLOSLIの目標範囲「99.9%のリクエストが200ms以内に完了」
SLASLO未達時の責任を定める契約「可用性99.95%未満の場合サービスクレジット提供」

Error Budget計算:

Error Budget = 1 - SLO

SLO 99.9% -> Error Budget 0.1% -> 月間約43.2分のダウンタイム許容
SLO 99.99% -> Error Budget 0.01% -> 月間約4.32分のダウンタイム許容

Error Budgetポリシー:

消費率対応
0-50%(Green)通常の機能開発を継続
50-80%(Yellow)安定性重視の作業強化、コードレビュー強化
80-100%(Red)機能凍結、安定性作業に全力集中

5.4 DORAメトリクス

プラットフォーム効率を測定するコアメトリクスである。

メトリクス説明
Deployment Frequencyデプロイ頻度
Lead Time for Changesコードコミットからプロダクションデプロイまでの時間
Change Failure Rateデプロイ後に障害が発生した割合
Mean Time to Recovery障害発生から復旧までの平均時間

6. Domain 4:プラットフォームアーキテクチャおよびインフラ(15%)

6.1 マルチテナンシーパターン

パターン分離レベル適合する状況
Namespaceベース論理的分離信頼できる社内チーム
Clusterベース物理的分離強固なセキュリティ要件、規制環境
ハイブリッド混合環境別の差別化された分離が必要な場合

Namespaceベースの分離ツール:

# ResourceQuotaによるリソース制限
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: '10'
    requests.memory: 20Gi
    limits.cpu: '20'
    limits.memory: 40Gi
    pods: '50'
---
# NetworkPolicyによるネットワーク分離
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

6.2 コスト管理:OpenCost

OpenCost(CNCF Sandbox)はKubernetesのコスト可視性と割り当てを提供するオープンソースツールである。Namespace、チーム、サービス別のコストを追跡し、リソースRight-Sizingを支援する。

6.3 オートスケーリング戦略

スケーラー対象基準
HPAPod水平スケーリングCPU/メモリ/カスタムメトリクス
VPAPodリソースリクエスト調整実際の使用量分析
Cluster Autoscalerノード水平スケーリングPending Podの検知
KEDAイベント駆動スケーリングキュー長、HTTPリクエストなど

7. Domain 5:セキュリティおよびポリシー適用(15%)

7.1 OPA/Gatekeeper

OPA GatekeeperはConstraintTemplate(Regoでポリシーロジックを定義)とConstraint(ポリシー適用対象を指定)の2つのリソースで運用される。

ConstraintTemplate例(必須ラベル検証):

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }

Constraint適用:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
spec:
  match:
    kinds:
      - apiGroups: ['']
        kinds: ['Namespace']
  parameters:
    labels: ['team', 'environment']

7.2 Kyverno

KyvernoはKubernetesネイティブのポリシーエンジンで、YAML + CELベースのため別途言語を学ぶ必要がない。validate、mutate、generateの3種類のルールをサポートする。

ClusterPolicy例(リソース制限必須):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: 'CPU and memory resource limits are required.'
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: '?*'
                    memory: '?*'

7.3 OPA/Gatekeeper vs Kyverno比較

項目OPA/GatekeeperKyverno
ポリシー言語Rego(専用言語)YAML + CEL
学習曲線高い低い
Validateサポートサポート
Mutate制限的完全サポート
Generate制限的完全サポート(Namespace間同期)
汎用性マルチプラットフォーム(K8s外でも使用可能)Kubernetes専用
CNCF状態Graduated(OPA)Incubating

7.4 サプライチェーンセキュリティ

  • SBOM(Software Bill of Materials):ソフトウェア構成要素リストの生成と管理
  • コンテナイメージスキャン:CI/CDパイプラインへのShift Leftセキュリティ統合
  • Falco:ランタイムセキュリティ脅威検知(CNCF Graduated)

8. 推奨学習計画(12週間)

内容
1-3週Kubernetes基礎復習 + GitOps原則 + ArgoCD/Fluxハンズオン
4-5週Crossplane XRD/Composition設計 + CRD/Operator開発
6-7週Backstageセットアップ + Software Template作成
8-9週OpenTelemetry + Prometheus + Grafanaスタック構成
10週OPA/Kyvernoポリシー適用 + セキュリティパイプライン構築
11-12週統合プラットフォーム実習 + CNCF公式リソース復習 + Killer.sh模擬試験

9. 必須学習リソース

リソースURL
CNPE公式ページtraining.linuxfoundation.org/certification/cnpe
CNCFカリキュラム(オープンソース)github.com/cncf/curriculum
CNCF Platforms White Papertag-app-delivery.cncf.io/whitepapers/platforms
Platform Engineering Maturity Modeltag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model
Killer.shシミュレーター試験登録時に2回付き

関連補助資格: CKA, CNPA, CGOA(Certified GitOps Associate), OTCA(OpenTelemetry Certified Associate), CBA(Certified Backstage Associate)


References