Kubernetes 1.33 & CKA/CKAD 2026 Exam Changes

Why Kubernetes 1.33 matters for certification candidates

CNCF ties the CKA and CKAD exam environments to a specific Kubernetes minor version, updating each exam approximately two to three months after the relevant release reaches general availability. Candidates who prepared against a 1.28 or 1.29 curriculum and are sitting the exam in 2026 are operating from an outdated knowledge base. Kubernetes 1.33 introduced several features that moved from alpha or beta to stable — which means they are now examinable and expected knowledge rather than optional preview content.

The most consequential changes for exam candidates fall into four categories: the graduation of sidecar containers to stable (affects both CKA and CKAD), the promotion of Gateway API to GA (primarily CKAD, increasingly CKA), the Job API improvements including success policy and managed-by (primarily CKAD), and the continued removal of in-tree volume plugins in favour of CSI drivers (primarily CKA). Understanding which exam tests which feature is the first step toward efficient exam preparation.

One structural note before the details: both exams are performance-based, delivered in a live terminal environment with a running Kubernetes cluster. The exam environment runs the same Kubernetes version documented on the CNCF certification pages at the time of sitting — verify the exact version when you register. This article covers the features that became stable in 1.33 and are therefore testable on exams administered against a 1.33 or later cluster.

Change 1: Sidecar containers graduated to stable

What changed in Kubernetes 1.33

Sidecar containers — auxiliary containers within a Pod that share its lifecycle but have clearly defined startup and shutdown semantics relative to the main application container — became a stable Kubernetes feature in 1.33. The mechanism was introduced in 1.28 as an alpha feature and promoted through beta in 1.29 and 1.30. The stable graduation means the behaviour is now guaranteed, the API is non-experimental, and the CNCF considers it examinable content.

The core mechanism is the initContainers spec with restartPolicy: Always. A container defined this way starts before the main application containers (preserving init container ordering semantics), but unlike a traditional init container it does not terminate before the main container starts — it runs alongside the main container for the full Pod lifetime, receiving the same termination signal when the Pod is deleted. This solves the canonical problem with the traditional sidecar pattern: a sidecar running as a regular container had no guaranteed startup order relative to the application container, creating race conditions where an application started before its logging agent, service mesh proxy, or secrets-injecting sidecar was ready.

Startup ordering: native sidecars start in the order they appear in initContainers, and each must reach a Ready state (pass its readiness probe) before the next starts. Application containers in containers do not start until all native sidecars are Ready. This is the hard guarantee that the traditional sidecar pattern lacked.
Termination ordering: when a Pod terminates, native sidecars receive SIGTERM only after all regular containers in containers have exited. This ensures the logging agent drains its buffer and the service mesh proxy finishes in-flight requests before the Pod disappears from the mesh.
Resource accounting: native sidecars contribute to the Pod’s total resource requests and limits. Exam questions test whether candidates can calculate the correct resource allocation for a Pod that includes sidecar containers alongside application containers.
Job compatibility: in a Kubernetes Job, native sidecars do not prevent Job completion. The Job controller considers the Job complete when all non-sidecar containers in the Pod exit successfully — sidecars are then terminated automatically. Without native sidecar support, logging sidecars in batch Jobs required manual workarounds to signal the sidecar to exit.

CKA vs CKAD scope

Both exams test sidecar containers. The CKA tests sidecar containers in the context of Pod design, troubleshooting, and multi-container Pod patterns. The CKAD tests them more heavily, including writing Pod specs with native sidecars, understanding the startup and shutdown ordering, and using sidecars for logging and service mesh integration patterns. Expect at least one hands-on task on either exam that requires defining a native sidecar container with a readiness probe.

Change 2: Gateway API graduates to GA

What changed in Kubernetes 1.33

The Kubernetes Gateway API reached general availability in the 1.33 release cycle. Gateway API is the successor to the Ingress resource, addressing the long-standing limitations of Ingress: lack of role-based management (cluster operators vs. application developers), limited support for advanced traffic routing (header-based routing, traffic weighting for canary deployments, cross-namespace references), and the proliferation of vendor-specific annotations that broke portability between ingress controllers.

Gateway API introduces three resource kinds that replace the single Ingress kind with a layered model reflecting how real organisations operate Kubernetes networking:

GatewayClass: defines the type of gateway (implemented by a controller, e.g. Envoy Gateway, Istio, NGINX Kubernetes Gateway). Cluster administrators manage GatewayClass resources. The GatewayClass is analogous to a StorageClass: it names the implementation and sets the parameters that apply to all Gateways created from it.
Gateway: instances of a GatewayClass, representing a specific network endpoint (load balancer, IP address, port). Platform teams or namespace admins own Gateways. A Gateway defines which listeners accept traffic (protocol, port, TLS configuration) and which Routes may bind to it via label selectors or namespace references.
HTTPRoute: defines traffic routing rules from a Gateway listener to backend Services. Application developers own HTTPRoutes in their own namespaces. An HTTPRoute can reference a Gateway in another namespace (cross-namespace binding) if the Gateway’s allowedRoutes policy permits it — this is the role separation that Ingress annotations could never cleanly model.

Advanced routing features that were annotation-only in Ingress are first-class HTTPRoute fields in Gateway API: matches filters traffic by HTTP method, headers, query parameters, or URL path prefix/exact/regex; filters rewrite headers, redirect requests, or mirror traffic; backendRefs with weight fields implement canary and blue-green traffic splitting at the routing layer rather than requiring a service mesh.

CKAD scope (primary)

The CKAD exam now includes Gateway API as a testable networking topic. Candidates must be able to create HTTPRoute resources that route traffic by path and header, configure cross-namespace backend references, and implement simple traffic splitting using weight on backendRefs. The CKA exam tests Gateway API at the cluster administration level: creating and inspecting GatewayClass and Gateway resources, verifying listener configuration, and troubleshooting route binding failures. Both exams still test the Ingress resource for legacy cluster management scenarios.

Change 3: Job API improvements — success policy and managed-by

What changed in Kubernetes 1.33

Kubernetes Jobs gained two significant API additions that reached stable in 1.33: a formal success policy and a managed-by field for external Job orchestrators. Both affect how CKAD candidates must think about batch workloads.

Job success policy (spec.successPolicy) allows defining what constitutes a successful Job completion without requiring all Pods to have succeeded. This is particularly valuable for indexed Jobs running distributed computations where certain indexed workers completing successfully is sufficient — the classical use case is a simulation or ML training job where 80% completion constitutes a usable result. The success policy can specify a minimum number of succeeded Pods (successfulIndexes), or specific Pod indexes that must succeed (succeededIndexes), before the Job is marked complete and remaining Pods are terminated. Without this feature, such jobs required application-level coordination logic to signal completion.

Job managed-by (spec.managedBy) allows an external controller (a workflow engine, an ML training operator, or a batch scheduler) to claim ownership of a Job, suppressing the default Kubernetes Job controller from acting on it. This enables tools like Kueue, Argo Workflows, and Kubeflow to implement their own Job lifecycle management without conflicting with the built-in Job controller. The field accepts a string that identifies the managing controller. Jobs with spec.managedBy set to a non-empty, non-kubernetes.io/job-controller value are left entirely to the named controller.

Indexed Jobs: the spec.completionMode: Indexed field assigns each Pod a unique index available in the JOB_COMPLETION_INDEX environment variable, enabling distributed workloads that partition data by worker index. Indexed Jobs are now a stable feature heavily tested on CKAD.
Pod failure policy: complements success policy by defining rules for handling specific Pod failure exit codes — certain exit codes can be treated as permanent failures (fail the Job immediately) while others trigger Pod replacement (retry). This replaces trial-and-error retry logic with declarative failure classification.
Backoff limit per index: in indexed Jobs, the retry budget can now be applied per-index rather than globally. A single high-retry-count index no longer consumes the entire global backoff budget, preventing one problematic partition from causing the whole Job to fail.

Study tip

CKAD Job questions in 2026 test the full Job configuration lifecycle: creating indexed Jobs with success policies, inspecting Job status (both kubectl describe job and reading .status.completedIndexes), and configuring Pod failure policies with exit-code-based rules. Practice creating Jobs from scratch in a live cluster rather than relying on multiple-choice familiarity with Job field names — the exam is entirely hands-on.

Change 4: In-tree volume plugin removals and CSI migration

What changed in Kubernetes 1.33

Kubernetes 1.33 completed the removal of the last significant in-tree volume plugins that had active CSI replacements. The storage architecture has been moving from in-tree volume drivers (code compiled directly into the kube-controller-manager and kubelet` binaries) to out-of-tree CSI (Container Storage Interface) drivers since Kubernetes 1.14. The 1.33 release removed the in-tree implementations of several cloud provider volumes, requiring clusters that were still using legacy volume configurations to migrate to the corresponding CSI driver.


        For CKA candidates, the practical implication is that all storage configuration tasks on the exam use CSI drivers and CSI-backed StorageClasses rather than legacy volume type names. The exam environment provides a cluster with CSI drivers pre-installed; candidates are expected to work with PersistentVolume, PersistentVolumeClaim, and StorageClass resources using CSI driver names in the provisioner field, not the legacy in-tree names.
        
          StorageClass provisioner field: legacy in-tree provisioner names like kubernetes.io/aws-ebs or kubernetes.io/gce-pd are replaced by the CSI driver names of their successors (e.g., ebs.csi.aws.com, pd.csi.storage.gke.io). The CKA exam tests creating StorageClasses that reference CSI provisioners correctly.
          Volume mode and access mode combinations: CSI drivers support a wider matrix of volume modes (Filesystem vs Block) and access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany, ReadWriteOncePod) than the in-tree drivers did. The exam tests selecting the correct access mode for a given workload pattern — a StatefulSet with one writer per Pod uses ReadWriteOncePod for strongest isolation, not ReadWriteOnce which allows multiple Pods on the same node to mount the same volume.
          Volume snapshots: VolumeSnapshot, VolumeSnapshotContent, and VolumeSnapshotClass resources provide a Kubernetes-native mechanism for point-in-time volume snapshots, backed by CSI driver snapshot support. These are testable on CKA as a storage management topic: creating a snapshot of a PVC, creating a new PVC from a snapshot for data recovery or environment cloning.
          Ephemeral volumes: CSI ephemeral volumes (spec.volumes[].csi.driver with no backing PVC) provide temporary, driver-backed storage that is provisioned and deleted with the Pod. The exam distinguishes between ephemeral volumes, emptyDir, and PVC-backed volumes by their persistence, sharing, and sizing characteristics.



      Additional 1.33 changes with exam relevance

      Beyond the four headline changes, several smaller 1.33 improvements appear in the CKA and CKAD exam domains:

      
        Node resource topology awareness: improvements to the TopologyManager in 1.33 affect how NUMA-aware workloads are scheduled on multi-socket nodes. CKA candidates with enterprise infrastructure backgrounds may see questions about resource topology policies, though this is a lower-weight topic than networking or storage.
        Structured parameters for dynamic resource allocation: the DRA (Dynamic Resource Allocation) API, which models GPU and accelerator resources more flexibly than the legacy requests/limits model, moved further toward stability in 1.33. While not yet a primary CKA domain, candidates should understand the conceptual distinction between ResourceClaim-based allocation and traditional resource requests for questions about AI/ML workload scheduling.
        Improved kubectl output for resource status: several kubectl subcommands received structured output improvements in 1.33. The exam is entirely kubectl-driven; being comfortable with kubectl get and kubectl describe output for Gateway, HTTPRoute, Job, and VolumeSnapshot resources is as important as knowing the resource specs themselves.
        Pod scheduling readiness: spec.schedulingGates allows external controllers to hold a Pod in an unschedulable state until a named gate is cleared. This is primarily relevant to batch scheduling systems (Kueue) that use it to implement queue-based admission. CKA candidates should recognise it as the mechanism that explains why a Pod shows SchedulingGated rather than Pending when inspecting cluster resources.
      

      
        Ready to practice CKA and CKAD questions covering Kubernetes 1.33 content?
        Explore Kubernetes Practice Packs
      

      How to update your study plan for 2026

      Candidates who started studying for CKA or CKAD before mid-2025 have preparation gaps that correspond directly to the feature graduations above. The most effective way to update a study plan is to map each new stable feature to its exam domain weight and prioritise accordingly.

      For CKA, storage is the highest-priority update area: complete CSI driver familiarity, PVC-to-snapshot workflows, and the access mode matrix cover the ground where in-tree knowledge is now stale. Networking is the second update priority: understanding Gateway API resource hierarchy and the difference between GatewayClass, Gateway, and HTTPRoute in an exam context where you must create and inspect them at the terminal. Workload-level changes (sidecar containers, Job improvements) are lower weight on CKA but appear in multi-container Pod troubleshooting tasks.

      For CKAD, the update priority order is essentially reversed: workloads first (sidecar containers, Job success policy, indexed Jobs), networking second (Gateway API HTTPRoute authoring), and storage third (CSI ephemeral volumes, snapshot-based PVC creation). CKAD candidates should note that native sidecar containers have largely replaced the “ambassador” and “adapter” sidecar patterns as exam content — the exam now tests the native mechanism rather than architectural pattern descriptions.

      The CKA and CKAD exams are two hours of terminal work with no documentation beyond the kubernetes.io/docs and the CNCF exam portal. Knowing which kubectl command produces the output you need to answer a question is more valuable than memorising YAML field names. Build the muscle memory to navigate the documentation efficiently under time pressure — candidates who pass in 2026 spend less than 30 seconds locating reference YAML they cannot recall from memory.

      Practice environments matter more than flashcard review for these exams. The hands-on, terminal-based format means that candidates who have typed the commands hundreds of times in a practice cluster will outperform candidates who have only read about the concepts, regardless of how thoroughly they understand the underlying theory. The CertQuests practice packs for CKA and CKAD cover the 1.33 curriculum changes, including Gateway API topology, sidecar container lifecycle semantics, and the Job success policy API.