CNCF Certification Exams
Cloud-native engineering is not simply the ability to start a container. A useful production platform must schedule applications safely, maintain service connectivity, recover from failed nodes, manage persistent state, protect credentials, and produce evidence when a rollout goes wrong. The Cloud Native Computing Foundation (CNCF), working with The Linux Foundation, maintains certifications that distinguish operational Kubernetes competence from application development, security, observability, GitOps, and platform-engineering specialisations. A candidate should choose based on the problems they need to solve in real clusters.
The portfolio now extends well beyond the three familiar Kubernetes exams. In addition to Certified Kubernetes Administrator (CKA), Certified Kubernetes Application Developer (CKAD), and Certified Kubernetes Security Specialist (CKS), the CNCF lists knowledge-based credentials such as KCNA, KCSA, and several project-focused associate qualifications for Prometheus, Istio, Cilium, Argo, OpenTelemetry, Kyverno, and other ecosystems. A broad awareness badge is not interchangeable with a practical command-line examination; both can be valuable, but they validate different levels and kinds of capability.
CKA: Operating a cluster rather than describing one
The Certified Kubernetes Administrator (CKA) validates the ability to perform administrative tasks in a Kubernetes environment. CNCF describes it as an online, proctored, performance-based exam that requires candidates to solve operational problems through the command line in two hours. The distinction is important: a person may recognize correct Kubernetes terminology and still be unable to recover an unhealthy control plane or restore application access under time pressure.
Understanding the Kubernetes cluster architecture starts with the API server, etcd, controllers, scheduling and node agents. The control plane represents desired state and coordinates reconciliation, but it depends on durable cluster state, working node communication, and valid configuration. When an application does not schedule, the cause may be insufficient resources, incompatible placement constraints, missing storage, or a control-plane problem. The administrator's task is to isolate the right cause before changing the workload specification.
Workloads and scheduling require fluency with Pods, Deployments, ReplicaSets, resource requests and limits, tolerations, node selectors and affinity. A taints-and-tolerations strategy can reserve special-purpose capacity, but it also creates the possibility of unschedulable Pods when labels or node conditions differ from assumptions. Administrators need to distinguish what Kubernetes is trying to do from why the actual state has not reached the requested state.
Networking covers Services, service discovery, network paths, and access from outside the cluster. A Kubernetes Service is not itself a guarantee that reachable, healthy endpoints exist. DNS resolution, endpoint readiness, ingress or Gateway API configuration, and network policy can each change user-visible behavior. The Ingress and Gateway API discussion is useful when differentiating external routing, TLS handling, application health, and service-level traffic control.
Storage and recovery are equally central. Persistent volumes and storage classes do not magically create unlimited durable capacity; topology, access modes and the underlying service influence whether a workload can recover or relocate. CKA candidates should know how to diagnose pending claims and attach failures and how to plan a recovery rather than assuming a redeployed Pod restores lost data. The etcd backup and cluster recovery work provides a concrete example of why backup commands are only one part of tested recovery capability.
Application development: CKAD and the responsibilities of deployable software
CKAD focuses on the developer's ability to build, configure, observe, and troubleshoot applications deployed in Kubernetes. A developer needs to create appropriate container images, express resource requirements, expose services, supply configuration, manage probes, and execute rollouts that can be observed and reversed. Kubernetes may restart a process that fails its liveness probe, but a badly designed probe can turn a transient downstream latency spike into repeated application restarts.
Configuration separation helps teams deploy the same image into different environments. ConfigMaps and Secrets support part of that separation, but their existence does not automatically solve secret rotation, encryption, access control, or configuration drift. Developers must consider what happens when configuration changes while a process is running and whether the application can handle a missing credential or a temporarily unavailable dependent service safely.
Readiness and liveness are operational contracts between an application and its platform. A readiness probe determines whether a Pod should receive traffic; a liveness probe can trigger restart. Neither proves the business transaction works end to end. Developers should choose appropriate probe semantics, maintain meaningful logs, and expose metrics that help platform teams distinguish application faults from cluster faults.
CKAD is especially useful for developers who already write services but need to understand production deployment mechanics. Familiarity with a cloud console or a managed Kubernetes wizard is not enough; candidates should be able to explain the underlying Kubernetes objects and determine how they interact when scaling, rollout, configuration, and service discovery disagree.
Kubernetes security is not a single product
CKS assesses security knowledge and practice involving cluster hardening, workload protection, supply-chain risk and runtime defence. The Kubernetes and Cloud Native Security Associate (KCSA) introduces security principles at a less operationally demanding level. Container security starts before a Pod runs: image provenance, dependency risk, registries and build processes determine what software is allowed to reach a cluster. The container image supply chain is relevant because a correct Deployment manifest cannot compensate for an untrusted artifact.
Once workloads are deployed, security boundaries depend on service accounts, RBAC, namespace structure, network policies, Pod security settings, admission controls, and runtime visibility. Kubernetes RBAC answers who may perform which API operations, while workload network policies regulate network communications where supported by the cluster networking implementation. Neither guarantees that an application is safe simply because it occupies a dedicated namespace.
Secrets management in Kubernetes is a distinct requirement: storing a token as a Secret does not establish access governance, encryption policy or safe rotation. An application may be authorized to read one secret while the underlying cloud identity can still perform a much more consequential action. Security specialists should review the chain from Pod identity through secret storage to downstream permissions, including what will happen when an exposed credential is revoked.
A strong security candidate can reason about privilege escalation. A container running as root with excessive host mounts has different risk from a constrained workload using least-privilege identities and tightly controlled capabilities. Admission policy may prevent deployment of dangerous settings, but policy enforcement must be verified under real rollout conditions. Operational response also requires logs, audit records, clear ownership, and safe means of isolating a compromised workload.
CNCF introduced an important renewal arrangement under its CARE programme: from June 18, 2026, passing or recertifying CKS can reinstate or extend CKA. This is a specific policy, not a general claim that any CNCF exam renews all others. Candidates planning maintenance should check the official programme rules and their own credential dates before relying on such an extension.
Understanding cloud-native systems beyond Kubernetes
The Kubernetes and Cloud Native Associate (KCNA) covers cloud-native fundamentals across containers, orchestration, networking, security and observability. It helps candidates see Kubernetes as one part of a larger operating model, rather than the complete software platform. The control-plane components illustrate how declarative desired state, scheduling and reconciliation work together. This knowledge is relevant for platform administrators, developers and technical managers who must understand why the system behaves as it does.
Observability is often what makes a distributed system governable. A service may pass health checks while one tenant experiences slow queries, a dependency times out intermittently, or a new version causes increased error rates. The concepts behind cloud-native observability connect metrics, logs, traces, service-level objectives and operational alerts. A platform that produces thousands of alerts without useful context is not necessarily better monitored than one with a smaller set of decisive signals.
GitOps brings change management into the platform conversation. Declarative configuration stored in version control can make intended state reviewable and recoverable, but only if teams understand reconciliation, repository permissions, secret handling, and the risk of uncontrolled automation. GitOps for Kubernetes should be understood as an operational discipline with ownership and rollback, not as a guarantee that every change committed to a repository is safe.
Other CNCF certifications are aligned with particular technologies: Prometheus for monitoring, Istio or Cilium for networking and traffic control, Argo for delivery, and OpenTelemetry for telemetry collection. Platform-engineering credentials add a broader focus on how internal platforms are designed to enable application teams. Those specialisations are valuable when the candidate's actual responsibilities include the underlying project; otherwise they risk becoming an attractive list of disconnected product names.
Turning an exam plan into operational competence
An effective learning path begins with a realistic failure scenario. For a CKA candidate, build a cluster, deploy a workload, make a scheduling rule that prevents placement, and recover using observation rather than guessed commands. Then break service discovery, restrict access in RBAC, and restore from a known backup in a controlled environment. This teaches the same judgment used during incidents: establish expected state, locate where observation differs, form a hypothesis, test it, and verify recovery.
For developers, start with a small service and make its image, configuration, readiness behaviour, rollout, and logs reliable. For security specialists, inspect image provenance, service accounts, admission policies and runtime controls as a chain rather than as separate tools. For platform engineers, examine how an application team requests capacity, receives feedback, deploys safely, and identifies an outage. Those exercises connect the exams to maintainable systems.
CNCF credentials are most useful when they identify a real level of responsibility. KCNA and related associate exams support conceptual understanding; CKA and CKAD demonstrate operational and development competence; CKS addresses protection of those systems; and project-specific or platform credentials make sense as work becomes more specialized. The durable outcome is a professional who can explain and repair the system when Kubernetes stops doing what its manifests say it should do.
