ExamFinch.com My Study

Study guide

11.6 Platform Engineering & Developer Self-Service

Practice this exam

Kubernetes and Cloud Native Associate KCNA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the KCNA Exam & Certification Path 1.2 How to Use This Study Guide

2 Chapter 2: Kubernetes Fundamentals - Cluster Architecture & the API

2.1 Kubernetes Architecture & Control Plane Components 2.2 Worker Node Architecture & Node Components 2.3 Kubernetes API, Declarative Management & kubectl 2.4 Kubernetes Releases, API Versioning & Deprecation Policy

3 Chapter 3: Kubernetes Fundamentals - Workloads & Configuration

3.1 Core Workload Objects (Pods, Deployments & ReplicaSets) 3.2 Advanced Controllers (StatefulSets, DaemonSets, Jobs & CronJobs) 3.3 Namespaces, Labels, Selectors & Annotations 3.4 ConfigMaps, Secrets & Application Configuration 3.5 Pod & Container Lifecycle, Restart Policies & Graceful Termination

4 Chapter 4: Kubernetes Fundamentals - Scheduling & Autoscaling

4.1 Scheduling, Resource Management & Node Selection 4.2 Advanced Scheduling: Affinity, Topology Spread, Priority & Disruption Budgets 4.3 Autoscaling Workloads & Clusters (HPA, VPA, Cluster Autoscaler, KEDA)

5 Chapter 5: Kubernetes Fundamentals - Cluster Administration & Extensibility

5.1 Kubernetes Distributions, Installation Tools & Managed Services 5.2 Cluster Administration: Node Maintenance, Upgrades & etcd Backup 5.3 Extending Kubernetes: CRDs, Operators & the Controller Pattern

6 Chapter 6: Kubernetes Fundamentals - Containerization

6.1 Container Fundamentals, Runtimes & Registries 6.2 Container Image Anatomy: Layers, Tags, Digests & Pull Policy

7 Chapter 7: Container Orchestration - Networking & Service Discovery

7.1 Kubernetes Networking, Services & Ingress 7.2 Cluster DNS & Service Discovery with CoreDNS 7.3 NetworkPolicies, Zero-Trust Segmentation & the Gateway API

8 Chapter 8: Container Orchestration - Storage

8.1 Storage Concepts (PVs, PVCs, StorageClasses & CSI) 8.2 Volume Types, Snapshots & Stateful Storage Operations

9 Chapter 9: Container Orchestration - Security

9.1 Kubernetes Security & Access Control (RBAC & ServiceAccounts) 9.2 The 4C's of Cloud Native Security & Supply-Chain Trust 9.3 Service Mesh, mTLS & Zero-Trust Service Identity

10 Chapter 10: Container Orchestration - Troubleshooting

10.1 Container Troubleshooting & Health Probes 10.2 Cluster & Node-Level Troubleshooting

11 Chapter 11: Cloud Native Application Delivery

11.1 Cloud Native CI/CD Pipelines & Build Tooling 11.2 GitOps & Package Management (Helm, Kustomize, Argo CD & Flux) 11.3 Deployment Strategies & Release Management 11.4 Progressive Delivery Automation: Argo Rollouts, Flagger & Feature Flags 11.5 Application Debugging & Developer Workflows in Kubernetes 11.6 Platform Engineering & Developer Self-Service

12 Chapter 12: Cloud Native Architecture - Observability & Principles

12.1 Cloud Native Observability (Logging, Metrics & Tracing) 12.2 Cloud Native Principles & Architecture Patterns 12.3 Serverless, FaaS & Event-Driven Architecture

13 Chapter 13: Cloud Native Architecture - CNCF Ecosystem & Community

13.1 The CNCF Landscape, Governance & Project Lifecycle 13.2 Cloud Native Community, Collaboration & Contribution

11.6 Platform Engineering & Developer Self-Service

Key Takeaways Explain This Topic AI

Platform engineering builds an internal developer platform that offers golden paths, reducing the cognitive load Kubernetes places on application teams.

Backstage is a CNCF incubating developer portal providing a software catalogue, scaffolding templates, and integrated technical documentation.

Crossplane is a CNCF graduated project that manages cloud infrastructure through Kubernetes custom resources, turning the cluster into a universal control plane.

A platform should be an opinionated product with paved paths rather than a mandatory gate, since teams route around platforms that block them.

The four DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — are the standard measure of delivery performance.

Last updated: August 2026

11.6 Platform Engineering & Developer Self-Service

Quick Answer: Platform engineering is the discipline of building an Internal Developer Platform (IDP) on top of Kubernetes so that application teams get golden paths — opinionated, self-service, paved routes to production — instead of being handed raw YAML and a cluster endpoint. Backstage (CNCF incubating) provides the developer portal; Crossplane (CNCF graduated) turns the cluster into a control plane for cloud infrastructure; the DORA metrics tell you whether any of it is working.

This matters to KCNA because it explains why the ecosystem keeps producing abstraction layers. Kubernetes is a platform for building platforms, not an end-user product.

1. The Cognitive Load Problem

To ship one service safely on raw Kubernetes, a developer must produce and understand: Deployment · Service · Ingress or HTTPRoute · ConfigMap · Secret · ServiceAccount

  • Role + RoleBinding · NetworkPolicy · HPA · PodDisruptionBudget · resource requests
  • readiness/liveness/startup probes · securityContext · topology spread · Helm chart
  • CI pipeline · image scanning · signing · GitOps application manifest · dashboards
  • alert rules · SLOs · runbook

That is a full-time specialism, and asking every product engineer to master it produces three predictable outcomes: copy-pasted manifests nobody understands, wildly inconsistent quality between teams, and a platform team that becomes a ticket queue and therefore a bottleneck.

Platform engineering treats this as a product problem : the platform team's customers are internal developers, and the product is a paved path.

2. Golden Paths

A golden path is the supported, opinionated route to production for a common case — "a stateless HTTP service in Go" or "a scheduled batch job". Choosing it should give you, without a ticket:

  • a repository scaffolded with a working build,
  • a CI pipeline that already scans, signs, and publishes,
  • manifests generated from a template with sane defaults for probes, requests, PDBs, and NetworkPolicy,
  • a GitOps registration so it deploys,

dashboards, alerts, and an on-call routing entry created automatically.

The defining characteristic is that a golden path is the easy option, not the mandatory one . Teams with genuinely unusual requirements can step off it and take on the extra work themselves. A platform that forbids deviation gets routed around, and shadow platforms are worse than no platform.

3. Backstage

Backstage , contributed to the CNCF by Spotify and currently an incubating project, is the most widely adopted developer portal. Three capabilities carry most of the value:

Capability What it does

Software Catalog A registry of every service, library, API, and resource, with its owner, lifecycle stage, dependencies, and links. Answers "who owns this and what breaks if it goes down?"

Software Templates (Scaffolder) One form creates the repository, the pipeline, the manifests, and the catalog entry — the golden path made executable

TechDocs Docs-as-code rendered next to the component they describe, so documentation stops rotting in a separate wiki

A plugin architecture surfaces CI status, Kubernetes workload health, cost data, security findings, and on-call rotation on the same component page — one pane instead of eight browser tabs.

The catalogue is described by a YAML descriptor committed alongside the code: apiVersion: backstage.io/v1alpha1

kind: Component

metadata:

name: payments-api

annotations:

backstage.io/kubernetes-id: payments-api

spec:

  • type: service
  • lifecycle: production
  • owner: team-payments
  • system: checkout
  • dependsOn: [component:postgres-orders, component:auth-api]
  • 4. Crossplane

Applications need more than Pods: a managed database, an object storage bucket, a message queue, a DNS record. Crossplane — CNCF graduated — extends the Kubernetes API so that cloud infrastructure is managed as Kubernetes objects, reconciled by the same control loop as everything else.

The pattern is the one from section 5.3, applied to infrastructure:

A provider installs CRDs for a cloud's resources ( RDSInstance , Bucket , SQSQueue ).

A platform team authors a Composition and a CompositeResourceDefinition that bundle those primitives into a simple, opinionated claim.

A developer creates the claim; Crossplane reconciles the real infrastructure and writes the connection details into a Secret. apiVersion: platform.example.com/v1alpha1

kind: PostgresInstance # a claim defined by the platform team

metadata:

name: orders-db

spec:

parameters:

  • size: medium
  • version: "16"

writeConnectionSecretToRef:

name: orders-db-conn

Those eight lines expand, behind the scenes, into a VPC-attached managed database with encryption, backups, a parameter group, and an access policy — all chosen by the platform team once. The developer never writes Terraform and never opens a ticket. Because the claim is a Kubernetes object, it also inherits RBAC, GitOps, and audit logging for free.

5. Where Abstraction Layers Fit

  • Layer Examples Audience
  • Raw Kubernetes Deployments, Services, Ingress Platform engineers
  • Templating Helm, Kustomize Platform and senior application engineers
  • Application abstraction KubeVela (OAM), Score, Shipa Application developers
  • Infrastructure control plane Crossplane, Cluster API Platform engineers
  • Portal / catalogue Backstage, Port, Cortex Everyone
  • PaaS on Kubernetes Knative, OpenShift Developer Console, Cloud Foundry Korifi Application developers

A useful heuristic: expose the smallest surface that still lets a team do their job, and make the next layer down available when they need it. Abstractions that cannot be opened up become the thing everyone fights.

6. Measuring the Platform: DORA

The four DORA metrics from the DevOps Research and Assessment programme are the standard evidence that a platform is helping:

  • Metric Question it answers Elite performance
  • Deployment frequency How often does code reach production? On demand, multiple times per day
  • Lead time for changes Commit to running in production? Less than one day
  • Change failure rate What share of releases cause a degradation? 0–15%
  • Failed deployment recovery time How long to restore service after a bad change? Less than one hour

The first two measure throughput , the last two stability , and the central research finding is that they are not in tension: teams that deploy more often also fail less often, because small changes are easier to verify and to reverse. That result is the empirical justification for continuous delivery, progressive rollouts, and platform investment. A fifth measure, reliability , is often added to capture whether the service actually meets its SLOs.

Platform teams increasingly track developer experience alongside DORA — time to first deploy for a new engineer, time waiting on the platform team, and satisfaction surveys — because a platform can improve deployment metrics while making engineers miserable.

7. Common Failure Modes

  • Anti-pattern Why it fails
  • Platform as a ticket queue Reintroduces the bottleneck self-service was meant to remove
  • Platform as a mandatory gate Teams build shadow platforms; you lose visibility as well as adoption
  • Abstracting so hard nobody can debug When something breaks, the abstraction hides the evidence
  • Building for imagined future needs Golden paths must come from observed, repeated demand
  • No product ownership An unowned platform decays into an unmaintained internal fork