- Published on
CNPE(Certified Cloud Native Platform Engineer) 완벽 가이드 - 시험 범위부터 실전 기술 스택까지
- Authors
- Name
- 1. CNPE란?
- 2. 시험 도메인 개요
- 3. Domain 1: GitOps 및 지속적 배포 (25%)
- 4. Domain 2: 플랫폼 API 및 셀프 서비스 (25%)
- 5. Domain 3: 관측성 및 운영 (20%)
- 6. Domain 4: 플랫폼 아키텍처 및 인프라 (15%)
- 7. Domain 5: 보안 및 정책 적용 (15%)
- 8. 추천 학습 계획 (12주)
- 9. 필수 학습 리소스
- References
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 기반 원격 데스크톱 (터미널 + 웹 인터페이스) |
| 오픈북 | 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 Server (
argocd-server): gRPC/REST 서버로 Web UI와 CLI API를 제공한다. 애플리케이션 관리, RBAC 적용, Git webhook 수신을 담당한다. - Repository Server (
argocd-repo-server): Git 저장소의 로컬 캐시를 유지하고, 리비전과 경로에 따른 Kubernetes 매니페스트를 생성한다. - Application Controller (
argocd-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 정책
| 정책 | 기본값 | 설명 |
|---|---|---|
automated | disabled | OutOfSync 감지 시 자동 동기화 |
prune | false | Git에서 삭제된 리소스를 클러스터에서도 제거 |
selfHeal | false | 클러스터의 수동 변경(drift)을 Git 상태로 자동 복원 |
allowEmpty | false | 매니페스트가 0개일 때 동기화 허용 여부 |
3.4 ApplicationSet으로 멀티 클러스터 배포
ApplicationSet은 단일 템플릿에서 여러 Application 리소스를 생성하는 CRD다. Generator를 통해 파라미터를 동적으로 생성한다.
주요 Generator:
| Generator | 설명 |
|---|---|
| Cluster | Argo CD에 등록된 클러스터 자동 탐지 |
| Git Directory | 리포지토리의 디렉토리 구조에서 앱 생성 |
| Matrix | 두 Generator의 파라미터를 조합 (Cartesian Product) |
| 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 Controller | GitRepository, HelmRepository, OCIRepository | Git/Helm/OCI에서 아티팩트 가져오기 |
| Kustomize Controller | Kustomization | Kustomize 오버레이 또는 Plain YAML 적용 |
| Helm Controller | HelmRelease | Helm 차트 라이프사이클 관리 |
| Notification Controller | Provider, Alert, Receiver | 알림 발송 및 인바운드 웹훅 처리 |
| Image Automation | ImageRepository, 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
셀프 서비스 패턴은 다음과 같다:
- 플랫폼 팀이 XRD(API 스키마)와 Composition(구현)을 정의한다.
- 개발자는 자신의 네임스페이스에서 XRD 인스턴스를 생성한다.
- Crossplane이 자동으로 클라우드 리소스를 프로비저닝하고 관리한다.
- 개발자는 클라우드 Provider API를 직접 다루지 않는다.
4.2 Backstage: Internal Developer Portal
Backstage(CNCF Incubating)는 Spotify가 개발한 오픈소스 IDP 프레임워크다.
핵심 기능:
| 기능 | 설명 |
|---|---|
| Software Catalog | 모든 소프트웨어 자산의 중앙 레지스트리 |
| Software Templates | 표준화된 프로젝트 생성 자동화 |
| TechDocs | Docs-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 프레임워크:
| 프레임워크 | 언어 |
|---|---|
| Kubebuilder | Go |
| Operator SDK | Go, Ansible, Helm |
| Kopf | Python |
| kube-rs | Rust |
| Metacontroller | 모든 언어 (웹훅 방식) |
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 Auto-Instrumentation:
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 Discovery | Kubernetes, 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 관측성 스택:
+-----------+
| Grafana | (대시보드, 알림)
+-----+-----+
|
+------------+------------+
| | |
+----+----+ +---+---+ +-----+-----+
| Mimir | | Loki | | Tempo |
| Metrics | | Logs | | Traces |
+----+----+ +---+---+ +-----+-----+
| | |
+------------+------------+
|
+--------+--------+
| OTel Collector |
+-----------------+
|
[Applications]
- Mimir: 수평 확장 가능한 장기 메트릭 저장소
- Loki: 라벨 기반 인덱싱의 경량 로그 집계 시스템
- Tempo: 대규모 분산 트레이싱 백엔드
5.3 SLI/SLO와 Error Budget
| 개념 | 정의 | 예시 |
|---|---|---|
| SLI | 서비스 성능의 정량적 측정값 | 요청 성공률, P99 지연시간 |
| SLO | SLI의 목표 범위 | "99.9%의 요청이 200ms 이내 완료" |
| SLA | SLO 미달 시 책임이 있는 계약 | "가용성 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 비용 가시성과 할당을 제공하는 오픈소스 도구다. 네임스페이스, 팀, 서비스별 비용을 추적하고 리소스 Right-Sizing을 지원한다.
6.3 오토스케일링 전략
| 스케일러 | 대상 | 기준 |
|---|---|---|
| HPA | Pod 수평 확장 | CPU/메모리/커스텀 메트릭 |
| VPA | Pod 리소스 요청 조정 | 실제 사용량 분석 |
| Cluster Autoscaler | 노드 수평 확장 | Pending Pod 감지 |
| KEDA | 이벤트 기반 확장 | 큐 길이, HTTP 요청 등 |
7. Domain 5: 보안 및 정책 적용 (15%)
7.1 OPA/Gatekeeper
OPA Gatekeeper는 ConstraintTemplate(Rego로 정책 로직 정의)과 Constraint(정책 적용 대상 지정) 두 리소스로 운영된다.
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 세 가지 유형의 룰을 지원한다.
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/Gatekeeper | Kyverno |
|---|---|---|
| 정책 언어 | Rego (전용 언어) | YAML + CEL |
| 학습 곡선 | 높음 | 낮음 |
| Validate | 지원 | 지원 |
| Mutate | 제한적 | 완전 지원 |
| Generate | 제한적 | 완전 지원 (네임스페이스 간 동기화) |
| 범용성 | 멀티 플랫폼 (K8s 외 사용 가능) | Kubernetes 전용 |
| CNCF 상태 | Graduated (OPA) | Incubating |
7.4 Supply Chain 보안
- 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 Paper | tag-app-delivery.cncf.io/whitepapers/platforms |
| Platform Engineering Maturity Model | tag-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
- CNCF CNPE Certification. https://www.cncf.io/training/certification/cnpe/
- Linux Foundation CNPE Page. https://training.linuxfoundation.org/certification/certified-cloud-native-platform-engineer-cnpe/
- CNCF Curriculum Repository. https://github.com/cncf/curriculum
- CNCF Platforms White Paper. https://tag-app-delivery.cncf.io/whitepapers/platforms/
- Argo CD Documentation. https://argo-cd.readthedocs.io/en/stable/
- Flux CD Documentation. https://fluxcd.io/flux/
- Argo Rollouts Documentation. https://argo-rollouts.readthedocs.io/en/stable/
- OpenGitOps Principles. https://opengitops.dev/
- Crossplane Documentation. https://docs.crossplane.io/latest/
- Backstage Documentation. https://backstage.io/docs/
- OpenTelemetry Documentation. https://opentelemetry.io/docs/
- Prometheus Documentation. https://prometheus.io/docs/
- Grafana Loki Documentation. https://grafana.com/docs/loki/latest/
- OPA Gatekeeper Documentation. https://open-policy-agent.github.io/gatekeeper/website/docs/
- Kyverno Documentation. https://kyverno.io/docs/
- Google SRE Book - Service Level Objectives. https://sre.google/sre-book/service-level-objectives/
- Google SRE Workbook - Error Budget Policy. https://sre.google/workbook/error-budget-policy/