CNCF Certified Cloud Native Platform Engineer
最終確認：2026年5月
CNPE 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
Kubernetesネイティブな宣言型APIを使用して、マルチクラウドインフラストラクチャをプロビジョニングおよび管理する。
Crossplaneを使用する。クラウドプロバイダーのCRD（例：provider-aws）をインストールする。CompositionおよびCompositeResourceDefinition（XRD）でプラットフォームの抽象化を定義する。
理由: アプリケーションとインフラストラクチャの管理を単一のコントロールプレーンとGitOpsワークフローに統合し、開発者からプロバイダー固有の詳細を抽象化する。
複数のKubernetesクラスターのライフサイクル（作成、アップグレード、削除）を異なるプロバイダー間で宣言的に管理する。
関連するインフラストラクチャプロバイダー（例：AWS向けのCAPA、Azure向けのCAPZ）とともにCluster API (CAPI) を実装する。管理クラスター内でKubernetesリソースとしてクラスターを定義する。
理由: クラスターのライフサイクルをコードとして扱い、クラスター自体のGitOpsを可能にする。CAPI MachineHealthChecksは自動ノード修復を提供する。
共有Kubernetesプラットフォーム上のテナントワークロード間で強力な分離を提供する。
専用ノードプール（コンピューティング）、NetworkPolicies（ネットワーク）、RBAC（API）、ResourceQuotas（リソース）、およびPod Security Standards（セキュリティ）を組み合わせる。コントロールプレーンの分離にはvirtual clusters (vCluster) を検討する。
理由: 多層防御戦略が必要である。単一の機能では完全な分離は提供されない。各層がテナンシーの異なる側面に対処する。
多数のダウンストリームクラスターの構成とワークロードを中央から管理する。
プラットフォームのコントロールプレーンツール（ArgoCD、Flux、Crossplane、ポリシーエンジン）をホストする「ハブ」クラスターを指定する。「スポーク」クラスターはワークロードを実行し、ハブから管理される。
理由: 管理、ポリシー適用、およびオブザーバビリティを集中化し、マルチクラスター運用を簡素化し、一貫性を確保する。
開発チームに、物理クラスターのオーバーヘッドなしで、分離されたクラスター管理者ライクな環境を提供する。
vClusterを使用する。各vClusterは、ホストクラスターの名前空間内のPodとして個別のK8sコントロールプレーンを実行し、ホストワーカーノードを共有する。
理由: フルクラスターよりも低コストで強力なAPIレベルの分離を提供する。vClusterシンカーは、必要なリソースをホストクラスター上に具現化する。
低いRPO/RTOでステートフルワークロードの災害復旧を確保する。
同期または非同期のクロスリージョン/クロスクラスターデータレプリケーションをサポートするCSIドライバー（例：Rook-Ceph、Portworx）を使用する。
理由: レプリケーションは、リージョン障害におけるデータ可用性にとって重要である。ローカルスナップショットや高性能ティアでは、クロスサイトDRには対処できない。
障害ドメイン全体にレプリカを分散することで、アプリケーションの可用性を向上させる。
ワークロードのspecでPod Topology Spread Constraintsを使用する。`topologyKey`（例：`topology.kubernetes.io/zone`）と`whenUnsatisfiable: ScheduleAnyway`または`DoNotSchedule`を定義する。
理由: サービスのすべてのレプリカが単一のゾーンまたは単一のノードにスケジュールされるのを防ぎ、局所的なインフラストラクチャ障害による影響を軽減する。
階層的な組織構造を持つチームのポリシーとRBACを管理する。
Hierarchical Namespace Controller (HNC) を実装する。親子名前空間関係を作成し、RBAC、NetworkPolicies、およびResourceQuotasを伝播させる。
理由: HNCは、プラットフォーム管理者がチーム/組織レベル（親名前空間）でポリシーを設定することを可能にし、それらがすべてのサブ名前空間に自動的に継承されることで管理を簡素化する。
メトリックベースの分析とロールバックを伴う、カナリアまたはブルーグリーンなどの高度な自動デプロイ戦略を実装する。
Argo Rolloutsを使用する。トラフィックルーティング構成（サービスメッシュ用）と、Prometheusのようなメトリクスプロバイダーを参照するAnalysisTemplateを含む戦略（例：カナリア）を持つRolloutリソースを定義する。
理由: デプロイをアプリケーションロジックから分離する。トラフィックのシフトと分析を自動化し、安全にリリースを昇格させ、障害時に自動的にロールバックすることで、デプロイのリスクを軽減する。
Gitにプレーンテキストの認証情報を保存せずに、GitOpsワークフローでシークレットを管理する。
Sealed Secrets（特定のクラスターのシークレットを暗号化する）またはExternal Secrets Operator（Vault、AWS/GCP/Azureシークレットマネージャーから同期する）を使用する。暗号化されたシークレットまたは参照リソースのみをGitにコミットする。
理由: 機密データをGitから分離しつつ、GitOpsワークフローの一部としてシークレットを宣言的に管理できるようにし、単一の真実のソースを維持する。
複数のクラスター、環境、またはマイクロサービス向けのArgoCD Applicationの作成と管理を自動化する。
ApplicationSetを使用する。Applicationのテンプレートを定義し、ジェネレーター（例：クラスター、Git、マトリックス）を使用して、クラスターリスト、Gitディレクトリ、またはその他のソースに基づいてApplicationを動的に作成する。
理由: 手動でのApplication作成を排除し、単一の定義から数百のアプリケーションまたはクラスターのスケーラブルな管理を可能にする。
開発者がプルリクエストでの変更をテストするための、一時的なプレビュー環境を提供する。
Pull Requestジェネレーター付きのArgoCD ApplicationSetを使用する。PRがオープンされたときにApplicationを自動的に作成し、PRがクローズ/マージされたときに削除する。
理由: 開発者がマージ前にライブ環境で変更を検証できるようにし、コード品質を向上させ、統合の問題を減らし、手動での環境管理を不要にする。
大規模で複雑なアプリケーションとプラットフォームコンポーネントのセットを、構造化された方法でArgoCDを使用して管理する。
App-of-Appsパターンを実装する。ルートApplicationは他の子Applicationを管理し、子Applicationはさらに他のApplicationを管理することで、階層構造を作成する。
理由: クラスターや環境をブートストラップするための単一のエントリポイントを提供し、個々のアプリケーションセットのモジュール式でチームベースの管理を可能にする。
リソースが正しい順序でデプロイされることを保証する（例：CRDの後にCR、アプリケーションの前にインフラストラクチャ）。
ArgoCDではSync Wavesとリソースヘルスチェックを使用する。FluxではKustomizationまたはHelmReleaseリソースで`dependsOn`を使用する。
理由: 宣言型システムはデフォルトでリソースを並行して適用する。リソース間の依存関係を管理するには、明示的な順序付けメカニズムが必要である。
Fluxを使用して完全なGitOpsパイプラインを実装する。
Fluxコントローラーを組み合わせる：Source Controller（Git/Helm/OCIソース用）、Kustomize Controller（マニフェスト適用用）、およびHelm Controller（HelmReleases用）。アラートにはNotification Controllerを使用する。
理由: Fluxは特化されたコントローラーの構成可能なセットである。それぞれの役割を理解することは、Fluxベースの継続的デリバリーを構築し、トラブルシューティングする上で重要である。
ライブクラスターの状態がGitの希望する状態に継続的に一致し、手動での変更を元に戻すことを保証する。
ArgoCD Applicationを`syncPolicy.automated.selfHeal: true`で構成する。ArgoCDはドリフトを検出し、自動的に同期して不正な変更を元に戻す。
理由: 自己修復は、Gitを唯一の真実のソースとして強制し、コンプライアンスと安定性にとって重要な構成ドリフトを防ぐ、GitOpsの核となる原則である。
適切な監査および承認ゲートを使用して、アプリケーションバージョンを環境間（開発 -> ステージング -> プロダクション）で昇格させる。
Gitで環境ごとに個別のディレクトリまたはブランチを使用する。プルリクエストを作成して変更を昇格させる（例：ステージングから本番ブランチ/ディレクトリへ）。PRレビューを強制する。
理由: 監査証跡と承認のためにGitを活用する。PRプロセスが正式な昇格ゲートとなり、変更が本番環境に到達する前にレビューされることを保証する。
共有ArgoCDインスタンスでマルチテナンシーを実装し、チームを自身の特定のリソースに制限する。
各チーム用にArgoCD Projectを作成する。ソースGitリポジトリ、デスティネーションクラスター/名前空間、および許可されるリソースの種類を制限するようにプロジェクトを構成する。SSOと統合し、グループをプロジェクトロールにマッピングする。
理由: ProjectはArgoCDにおけるマルチテナント分離とRBACの主要なメカニズムであり、セキュアなセルフサービスアプリケーションデプロイメントを可能にする。
開発者がクラウド固有の知識を必要とせずにインフラストラクチャをプロビジョニングするためのセルフサービスAPIを設計する。
CompositeResourceDefinition (XRD) を使用して高レベルAPIを定義する。高レベルのフィールドを基盤となる管理対象リソースにマッピングするCompositionでAPIを実装する。開発者はシンプルなComposite Resource Claim (XRC) を操作する。
理由: この3層モデル（Claim -> Composition -> Managed Resource）は、ユーザー向けAPIを実装から分離し、クリーンな抽象化を提供し、プラットフォームガバナンスを可能にする。
開発者が新しいプロジェクト、マイクロサービス、またはインフラストラクチャを宣言的に、かつ組織標準に準拠してブートストラップできるようにする。
Backstageソフトウェアテンプレートを作成する。テンプレートは入力パラメーター（フォームUI）と一連のスカフォルダーアクション（例：スケルトンのフェッチ、Gitリポジトリの作成、カタログへの登録）を定義する。
理由: 「ゴールデンパス」ワークフローを自動化し、開発者の認知負荷を軽減し、一貫性を確保し、プロジェクト設定を数分から数秒に短縮する。
組織内のすべてのソフトウェア、サービス、API、およびその所有権を発見するための単一の集中型プレースを作成する。
Backstage Software Catalogを実装する。Gitリポジトリから`catalog-info.yaml`エンティティ記述子を取り込み、ソフトウェアコンポーネントとその関係の検索可能なグラフを構築する。
理由: カタログはIDPの中核であり、発見可能性と、TechDocs、APIドキュメント、CI/CDステータスの可視性などの他の機能の基盤を提供する。
Kubernetesオペレーターが、カスタムリソースが削除されたときに外部リソース（例：クラウドストレージ、DNSレコード）をクリーンアップする必要がある。
ファイナライザーを使用する。コントローラーで、CR作成時にファイナライザーを追加する。調停ループで、`deletionTimestamp`が設定されている場合、クリーンアップロジックを実行してからファイナライザーを削除する。
理由: ファイナライザーは、コントローラーがクリーンアップタスクを正常に完了するまでKubernetesがリソースを削除するのを防ぎ、孤立した外部リソースを防止する。
静的な認証情報を管理することなく、KubernetesワークロードにクラウドプロバイダーAPIへのセキュアで短期間のアクセスを提供する。
クラウドプロバイダーのWorkload Identityソリューション（AWS IRSA、GCP Workload Identity、Azure Workload Identity）を使用する。これにより、Kubernetes ServiceAccountがクラウドIAMロールにリンクされ、Podが一時的な認証情報を取得できるようになる。
理由: 長期間有効な静的認証情報の危険性を排除する。Podにクラウド権限を付与するための最もセキュアなパターンである。
カスタムリソースの調整の状態と進捗状況をユーザーと自動化ツールに伝達する。
CRD定義でstatusサブソースを有効にする。コントローラーは、条件（例：`Type: Ready`、`Status: True`）と観測された状態を含むステータスを更新する必要がある。
理由: 期待される状態（spec）と観測された状態（status）を分離する。クライアントがリソースの健全性と準備状況を理解するための標準的で監視可能なメカニズムを提供する。
既存のクライアントやユーザーを壊すことなく、プラットフォームAPI（CRD）を進化させる。
Kubernetes APIのバージョン管理規則（v1alpha1 -> v1beta1 -> v1）に従う。破壊的変更を導入する場合は、新しいバージョンを作成し、保存されたバージョンと提供されるバージョン間で変換するためのconversion webhookを実装する。
理由: Conversion webhookは、APIサーバーが単一のストレージバージョンを維持しながら、複数のバージョンのリソースを同時に提供できるようにし、スムーズなAPIの進化を可能にする。
サービス信頼性目標に基づき、感度とアラート疲労回避のバランスをとった、実行可能なアラートを作成する。
SLOを定義し、エラーバジェットを計算する。エラーバジェットの消費率がSLOを脅かすときにトリガーされる、マルチウィンドウ、マルチバーンレートのアラートを実装する。
理由: エラーバジェットの燃焼に基づくアラートは、単純なしきい値アラートよりも意味がある。ユーザーに影響を与える事象やSLO違反に直接アラートを結びつける。
オブザーバビリティシグナル（トレース、メトリクス、ログ）の収集、処理、エクスポートのための、ベンダー非依存の統合パイプラインを実装する。
OpenTelemetry Collectorをデプロイする。レシーバー（例：OTLP、Jaeger）、プロセッサー（例：バッチ、属性）、およびエクスポーター（例：Prometheus、Loki、Tempo、ベンダーバックエンド）を持つパイプラインを構成する。
理由: インスツルメンテーションをオブザーバビリティバックエンドから分離し、アプリケーションを再計測することなくプラットフォームがバックエンドを切り替えたり追加したりできるようにする。処理とエンリッチメントのための中心点を提供する。
PrometheusがKubernetesワークロードからメトリクスを検出し、スクレイピングするように宣言的に構成する。
Prometheus Operatorを使用する。ラベルセレクターを使用して、PrometheusがスクレイピングするサービスまたはPodを定義する`ServiceMonitor`または`PodMonitor`カスタムリソースを作成する。
理由: スクレイピング構成を管理するためのKubernetesネイティブな方法を提供し、アプリケーションのデプロイやGitOpsワークフローとシームレスに統合する。
インシデント調査中に、異常なメトリクス（例：レイテンシースパイク）から、それを引き起こした特定の要求に素早く移動する。
Prometheusエクゼンプラーを使用する。アプリケーションを計測して、トレースIDをメトリクス観測に添付する。PrometheusとGrafanaを設定してエクゼンプラーを表示し、メトリクスからTempoやJaegerのようなトレースバックエンドへの直接リンクを提供する。
理由: 「何が起きたか」（メトリクス）を「なぜ起きたか」（トレース）に直接リンクすることで、MTTRを劇的に短縮し、手動での相関作業を不要にする。
ユーザー向けまたは重要なサービスの健全性を監視するためのベースラインを確立する。
4つの「ゴールデンシグナル」を監視する：レイテンシー（応答時間）、トラフィック（1秒あたりのリクエスト数）、エラー（失敗したリクエストの割合）、および飽和（リソース使用率）。
理由: これら4つのシグナルは、サービスの状態とユーザーエクスペリエンスに関する包括的な高レベルのビューを提供し、ほぼすべての種類のサービスに適用できる。
チームにチャージバックまたはショーバックのために、Kubernetesワークロードのコストに関する可視性を提供する。
OpenCostやKubecostのようなオープンソースツールをデプロイする。これらのツールは、リソース要求と使用量に基づいて、クラウドコストをKubernetesリソース（Pod、名前空間、ラベル）に割り当てる。
理由: インフラストラクチャの請求書を、意味のあるアプリケーション中心のコストデータに変換し、チームがリソース消費を理解し最適化できるようにする。
大規模な障害発生時に、症状を示すアラートを抑制することで、アラートノイズを減らす。
Alertmanagerで`inhibit_rules`を構成する。例えば、「ClusterUnreachable」アラートが既に発報している場合、特定のクラスターに対するすべてのアラートを抑制する。
理由: 優先度の高い根本原因のアラートの症状である低優先度のアラートを抑制することで、「アラートストーム」を防ぎ、オンコールが真の問題に集中できるようにする。
制御された方法で障害を注入することにより、プラットフォームとアプリケーションの回復力を積極的にテストする。
Chaos MeshやLitmusなどのカオスエンジニアリングツールを使用する。限られた影響範囲（例：特定の名前空間やラベル）と、SLOまたは重要なメトリクスに基づく自動停止条件を持つ実験を定義する。
理由: 受動的なインシデント対応を超え、本番環境の障害を引き起こす前にシステムの弱点を積極的に見つける。
Kubernetesプラットフォームでガードレールを適用するためのポリシーエンジンを選択する。
KubernetesネイティブのYAMLベースポリシーにはKyvernoを、より強力な汎用ポリシー言語（Rego）にはOPA/Gatekeeperを選択する。
理由: KyvernoはKubernetesエンジニアにとって参入障壁が低い。OPA/Gatekeeperはより柔軟でKubernetes以外でも使用できるが、学習曲線が急である。
非準拠リソースをブロックしたり、デフォルト値を追加したり、関連リソースを自動的に作成したりできるプラットフォームポリシーを実装する。
Kyvernoのようなポリシーエンジンを使用する。`validate`ルールを使用してブロック/監査を行い、`mutate`ルールを使用してデフォルト値（例：securityContext、ラベル）を追加し、`generate`ルールを使用してリソース（例：デフォルトのNetworkPolicy）を作成する。
理由: 異なるポリシータイプは異なる目的を果たす。それらを組み合わせることで、強制とユーザーの準拠支援の両方を行う堅牢で多面的なガバナンス戦略が可能になる。
プラットフォームで実行されるすべてのPodに対して、ベースラインセキュリティの強化を強制する。
組み込みのPod Security Admissionコントローラーを介してPod Security Standards (PSS) を使用する。名前空間に`pod-security.kubernetes.io/enforce=baseline`または`restricted`のラベルを付ける。
理由: PSSは、特権昇格やホスト名前空間アクセスなどの一般的なセキュリティ問題を防止するための標準化された組み込みメカニズムを提供し、基礎的なセキュリティ層を形成する。
公式のCI/CDパイプラインによって構築された、信頼できるコンテナイメージのみがクラスターにデプロイされることを保証する。
Sigstore/Cosignを使用してCIでイメージ署名を実装する。Podの作成を許可する前に、ポリシーエンジン（Kyverno、Gatekeeper）をアドミッションコントローラーとして使用し、信頼されたキーに対してイメージ署名を検証する。
理由: 暗号検証はイメージの出所と整合性について強力な保証を提供し、改ざんされたイメージや不正なイメージのデプロイを防ぐ。
サービス間の通信がネットワークロケーションではなく、暗号化されたワークロードIDによって認証されるゼロトラストセキュリティモデルを実装する。
SPIFFE/SPIREを使用して、ワークロードに短命でローテーション可能な暗号ID（SVID）を発行する。すべてのリクエストでSVIDを検証するサービスメッシュを使用して相互TLS（mTLS）を強制する。
理由: セキュリティをネットワーク境界制御からワークロード中心のIDに移行し、内部トラフィックに対しても強力な認証を提供し、侵害されたノードやPodの影響範囲を制限する。
ネットワークレベルでワークロードを分離し、「デフォルト拒否」の姿勢を強制し、必要な通信パスのみを許可する。
Kubernetes NetworkPoliciesを実装する。各名前空間にデフォルト拒否ポリシーを適用し、次にPod/名前空間ラベルに基づいてトラフィックを許可する特定のイングレス/エグレスポリシーを追加する。
理由: 横方向の移動攻撃の表面積を削減する。1つのPodの侵害が、クラスター内の他のすべてのサービスへのネットワークアクセスを自動的に付与するわけではない。
セキュリティとコンプライアンスのために、Kubernetes APIサーバーで実行されたすべてのアクションの包括的で改ざん防止された監査証跡を作成する。
APIサーバーでKubernetes監査ロギングを有効にする。関連するイベント（例：すべての書き込みリクエスト）をログに記録する監査ポリシーを構成する。監査ログをセキュアで不変のストレージバックエンドまたはSIEMに転送する。
理由: 監査ログは、インシデント調査、コンプライアンスレポート（例：PCI-DSS、SOC2）、および異常なAPIアクティビティの検出に不可欠である。
