CKA - Certified Kubernetes Administrator Cheat Sheet

This sheet covers the Certified Kubernetes Administrator (CKA) exam from the Cloud Native Computing Foundation (CNCF) and The Linux Foundation, currently aligned to Kubernetes v1.34. CKA is a two-hour, performance-based exam: every task is solved live from a terminal against a real cluster, so the bar is not recall but doing, fast, with only the official kubernetes.io docs open. The five domains weight toward Troubleshooting (30%) and Cluster Architecture (25%), so command-line fluency in diagnosing failures and building clusters with kubeadm matters more than memorizing definitions. Use each table as a checklist of the exact objects, flags, and recovery moves the exam expects you to reach for under time pressure.

What This Cheat Sheet Covers

This topic spans 24 focused tables and 245 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Storage Classes and Dynamic Volume ProvisioningTable 2: Persistent Volumes, Claims, Access Modes and Reclaim PoliciesTable 3: Troubleshoot Clusters and NodesTable 4: Troubleshoot Control Plane and Cluster ComponentsTable 5: Monitor Cluster and Application Resource UsageTable 6: Container Logs and Output StreamsTable 7: Troubleshoot Services and NetworkingTable 8: Deployments, Rolling Updates and RollbacksTable 9: ConfigMaps and SecretsTable 10: Workload Autoscaling (HPA and VPA)Table 11: Self-Healing Workload PrimitivesTable 12: Pod Scheduling, Affinity and Admission ControlTable 13: Role-Based Access Control (RBAC)Table 14: Prepare Infrastructure and Install Clusters with kubeadmTable 15: Cluster Lifecycle: Upgrades, Drain and etcd BackupTable 16: Highly-Available Control PlaneTable 17: Install Cluster Components with Helm and KustomizeTable 18: Extension Interfaces: CNI, CSI and CRITable 19: CRDs, Operators and Cluster ExtensionTable 20: Pod Connectivity and the Cluster Network ModelTable 21: Network PoliciesTable 22: Service Types and EndpointsTable 23: Ingress, Ingress Controllers and the Gateway APITable 24: CoreDNS and Cluster DNS

Table 1: Storage Classes and Dynamic Volume Provisioning

CKA exam domain Storage (10%): implement storage classes and dynamic volume provisioning. Covers the StorageClass object and the fields that drive on-demand volume creation; the PersistentVolume and PersistentVolumeClaim objects, access modes and standalone reclaim policies are covered in Table 2.

Concept	Example	Description
Dynamic Provisioning	A user creates a PVC with `storageClassName: fast` and a volume is auto-created to match	Creates storage on demand when a PVC is made, so admins do not pre-create PVs by hand. • Built entirely on the StorageClass API object • Static provisioning is the opposite: an admin makes PVs ahead of time
StorageClass	`kind: StorageClass` `provisioner: ebs.csi.aws.com`	The object that describes a class of storage and how to provision it. Its name is how a PVC requests it. • Holds `provisioner`, `parameters`, `reclaimPolicy`, `volumeBindingMode`, `allowVolumeExpansion` • Most fields are immutable after creation
provisioner	`provisioner: ebs.csi.aws.com` `provisioner: kubernetes.io/no-provisioner`	The required field naming the volume plugin (CSI driver) that creates the volume. Determines what backend is used. • Internal names start with `kubernetes.io`; external ones do not • `kubernetes.io/no-provisioner` means no dynamic provisioning
Default StorageClass	`kubectl patch storageclass gold -p` `'{"metadata":{"annotations":` `{"storageclass.kubernetes.io/is-default-class":"true"}}}'`	The class used when a PVC omits `storageClassName` entirely, set by the `is-default-class` annotation. • Needs the DefaultStorageClass admission controller enabled • If several are marked default, the most recently created one wins
volumeBindingMode	`volumeBindingMode: WaitForFirstConsumer` (default is `Immediate`)	Controls WHEN the volume binds and provisions. • `Immediate` (default): at PVC creation, before any Pod, so topology may not fit • `WaitForFirstConsumer`: waits for a Pod, then provisions in that Pod's zone

Table 1: Storage Classes and Dynamic Volume Provisioning

Concept	Example	Description
Dynamic Provisioning	A user creates a PVC with `storageClassName: fast` and a volume is auto-created to match	Creates storage on demand when a PVC is made, so admins do not pre-create PVs by hand. • Built entirely on the StorageClass API object • Static provisioning is the opposite: an admin makes PVs ahead of time
StorageClass	`kind: StorageClass` `provisioner: ebs.csi.aws.com`	The object that describes a class of storage and how to provision it. Its name is how a PVC requests it. • Holds `provisioner`, `parameters`, `reclaimPolicy`, `volumeBindingMode`, `allowVolumeExpansion` • Most fields are immutable after creation
provisioner	`provisioner: ebs.csi.aws.com` `provisioner: kubernetes.io/no-provisioner`	The required field naming the volume plugin (CSI driver) that creates the volume. Determines what backend is used. • Internal names start with `kubernetes.io`; external ones do not • `kubernetes.io/no-provisioner` means no dynamic provisioning
Default StorageClass	`kubectl patch storageclass gold -p` `'{"metadata":{"annotations":` `{"storageclass.kubernetes.io/is-default-class":"true"}}}'`	The class used when a PVC omits `storageClassName` entirely, set by the `is-default-class` annotation. • Needs the DefaultStorageClass admission controller enabled • If several are marked default, the most recently created one wins
volumeBindingMode	`volumeBindingMode: WaitForFirstConsumer` (default is `Immediate`)	Controls WHEN the volume binds and provisions. • `Immediate` (default): at PVC creation, before any Pod, so topology may not fit • `WaitForFirstConsumer`: waits for a Pod, then provisions in that Pod's zone