The Certified Kubernetes Administrator (CKA) assesses Kubernetes administration through performance-based command-line tasks. This guide builds foundations before applying them to configuration and diagnosis. Each concept explains a rule, resolves an original example, and identifies a specific error to avoid. Use the examples to connect resource definitions with the cluster behavior you should observe.
Cluster architecture and access
1. Control-plane and node responsibilities
The API server exposes the Kubernetes API, etcd stores cluster state, controllers reconcile resources, and the scheduler assigns eligible unscheduled Pods to nodes. On each node, the kubelet coordinates container execution through a container runtime. These responsibilities form separate diagnostic boundaries: accepting a Pod definition does not prove that scheduling or execution succeeded.
Worked example: A Pod exists but has no assigned node. Investigate scheduling conditions before container-runtime logs because container execution has not yet begun.
Mistake to avoid: Assuming the scheduler starts containers or the kubelet decides normal cluster-wide placement.
2. Desired state and reconciliation
A resource's spec expresses desired state, while status reports observations. Controllers repeatedly work toward the desired state rather than completing every change during the original API request. Successful creation therefore confirms acceptance, not application health. Verify the resulting status, conditions, and dependent resources to determine whether reconciliation achieved the intended outcome.
Worked example: A Deployment requests three replicas but reports two available. Its definition was accepted; the missing available replica still requires investigation.
Mistake to avoid: Treating a successful apply response as proof that all requested workloads are healthy.
3. Resource identity and namespace scope
A resource is identified by its API resource type, name, and namespace when namespaced. Namespaces separate namespaced objects, but resources such as Nodes and PersistentVolumes are cluster-scoped. A namespace is an organizational boundary; network isolation and permissions require their own controls. Always determine scope before selecting an object or granting access.
Worked example: Services named ledger can exist in both finance and sandbox. Querying ledger in sandbox does not inspect the finance Service.
Mistake to avoid: Assuming every resource belongs to a namespace or namespaces automatically block network traffic.
4. Kubeconfig contexts and explicit targets
A kubeconfig context associates a cluster, user credentials, and an optional default namespace. Context selection changes where kubectl sends requests and which identity it uses. Inspect the active context before making changes, and use explicit context and namespace arguments when ambiguity matters. Authentication information and the server endpoint are separate configuration elements.
Worked example: With staging active, kubectl --context=production -n billing get pods reads production billing Pods without changing the active context.
Mistake to avoid: Assuming that changing namespaces also changes clusters or authentication credentials.
5. Labels, selectors, and annotations
Labels provide structured identifiers for grouping and selection; annotations hold supplementary metadata that ordinary label selectors do not match. Equality and set-based selectors express different selection rules. Multiple requirements in one selector must all match. Choose stable labels for controller relationships so that routine metadata changes do not accidentally alter workload membership.
Worked example: A selector requiring app=ledger and tier=api excludes a Pod labeled app=ledger, tier=worker even though the application label matches.
Mistake to avoid: Putting selection-critical information in annotations or assuming selector requirements are alternatives.
6. RBAC rules and least privilege
RBAC rules grant verbs on resources within specified API groups. Reading Pods, reading their logs, and executing commands inside them involve different resources or subresources and permissions. Grant the operations a task actually needs, then verify authorization. Permissions are additive across applicable grants; ordinary RBAC rules do not provide explicit deny entries.
Worked example: A support identity can get Pods but cannot read logs. Add the necessary get permission for pods/log rather than granting every Pod operation.
Mistake to avoid: Using wildcard permissions to solve a narrowly identified authorization failure.
7. Bindings determine permission reach
Roles define namespaced permissions, while ClusterRoles can describe cluster-scoped or reusable permissions. A RoleBinding grants its referenced permissions within its namespace, even when referencing a ClusterRole. A ClusterRoleBinding grants the referenced ClusterRole across the cluster. ServiceAccount subjects must include their namespace because their names alone are not globally unique.
Worked example: A RoleBinding in reports references a Pod-reader ClusterRole for a ServiceAccount in automation. It grants Pod reading in reports, not every namespace.
Mistake to avoid: Assuming that referencing a ClusterRole through a RoleBinding automatically creates cluster-wide access.
8. Custom resources and controllers
A CustomResourceDefinition extends the API with a resource type, schema, and scope. A controller can then watch those objects and implement the behavior their specifications describe. Defining an API and implementing its behavior are separate responsibilities. Inspect both the accepted custom resource and the responsible controller when an extension appears inactive.
Worked example: A Backup object is accepted, but no backup occurs because its controller is absent. The CRD enables storage of the object, not execution of backups.
Mistake to avoid: Expecting a CRD alone to perform the operational behavior named by its resources.
Installation, configuration, and lifecycle
9. Installation prerequisites and network planning
Cluster installation depends on compatible node preparation, a CRI-compatible runtime, kubelet configuration, and a working Pod-network implementation. Plan node, Pod, and Service address spaces so they do not overlap in ways that create routing ambiguity. Installation tools bootstrap components, but they cannot compensate for incompatible runtime settings or missing network integration.
Worked example: A proposed Pod range overlaps the organization's routed office network. Select a nonoverlapping range before installing the network implementation.
Mistake to avoid: Treating successful control-plane bootstrap as proof that nodes and Pod networking are ready.
10. High availability and etcd quorum
Control-plane availability requires both a reachable API endpoint and healthy supporting components. An etcd cluster needs a majority of members to agree on updates. Additional API servers cannot compensate for lost etcd quorum. Evaluate independent failure boundaries rather than counting machines alone when judging whether a control-plane design tolerates failures.
Worked example: Three etcd members require two for quorum and tolerate one unavailable member. Losing two prevents normal consensus even if API servers remain reachable.
Mistake to avoid: Assuming every surviving etcd member can independently continue accepting cluster-state updates.
11. Upgrade sequencing and compatibility
An upgrade coordinates control-plane components, node components, and workload availability. Follow the documented sequence and supported version-skew rules for the target release rather than assuming arbitrary combinations work. In a kubeadm-managed cluster, plan control-plane upgrades before corresponding worker upgrades, and assess workload disruption before node maintenance.
Worked example: A worker-first proposal lacks a compatibility check. Revise it to the documented control-plane-first sequence and validate supported component versions before proceeding.
Mistake to avoid: Inferring supported upgrade paths from version numbers without checking the applicable documentation.
12. Etcd snapshots and recovery boundaries
An etcd snapshot preserves Kubernetes cluster state, not application data stored on external volumes. A recovery plan also needs appropriate credentials, configuration, and a documented restore procedure compatible with the environment. Validate recovery in an isolated setting. Snapshot creation alone does not demonstrate that the cluster or its applications can be restored.
Worked example: A snapshot includes database Deployment and PVC objects. It does not include the database files on the associated storage backend, which need separate protection.
Mistake to avoid: Calling an etcd snapshot a complete backup of every application's persistent data.
13. Helm charts, values, and releases
A Helm chart packages Kubernetes templates and related defaults. Values customize the rendered resource definitions, while a release represents an installation of the chart. Review the rendered manifests and relevant chart version before applying changes. A chart's convenience does not remove the need to understand generated permissions, workloads, Services, or storage resources.
Worked example: A chart's replicaCount value is set to three. Its rendered Deployment requests three replicas; actual availability still depends on successful Kubernetes reconciliation.
Mistake to avoid: Assuming a values-file change has the intended effect without inspecting the resulting manifests.
14. ConfigMaps and Secrets
ConfigMaps separate ordinary configuration from container images; Secrets hold sensitive values that require restricted access. Either can supply environment variables or mounted files, but applications must consume the chosen form correctly. Base64 representation of Secret data is encoding, not encryption. Environment variables already loaded by a running process do not automatically refresh when their source changes.
Worked example: A process reads its endpoint from an environment variable. Updating the ConfigMap requires replacing the Pod to supply the new value.
Mistake to avoid: Assuming encoded Secret values are confidential without appropriate access controls and storage protection.
15. Container identity and security context
A security context configures execution constraints such as user identity, privilege escalation, and filesystem-related settings. These controls must fit the application's actual needs. Running as a non-root user can reduce privileges, but that user still needs appropriate access to mounted files. Security settings affect execution; ServiceAccount permissions govern API access separately.
Worked example: A container runs as user 2400, but its mounted directory allows writes only by user 1000. The process starts yet cannot write until permissions are aligned.
Mistake to avoid: Solving a file-permission mismatch by granting broad privileges without identifying the required access.
Workloads and scheduling
16. Choosing a workload controller
Choose controllers according to lifecycle and identity requirements. Deployments manage interchangeable application replicas, StatefulSets support stable per-replica identity and storage associations, and DaemonSets place Pods on eligible nodes. A controller supplies management behavior; it does not make an application correctly replicate data or recover from failures by itself.
Worked example: A log collector must run on every eligible worker. A DaemonSet matches that placement requirement better than a Deployment with a guessed replica count.
Mistake to avoid: Choosing a StatefulSet merely because an application writes files, without considering identity requirements.
17. Pod sharing and ordinary init containers
Containers in one Pod share its network namespace and can share explicitly mounted volumes. They remain separate processes with their own images and filesystems. Ordinary init containers run to successful completion in sequence before application containers start. Use them for prerequisites that should finish before the main application begins.
Worked example: An init container writes a generated configuration into a shared volume. The application container reads that file after initialization completes, despite having a different image.
Mistake to avoid: Expecting files in an init container's private image filesystem to appear in another container.
18. Rolling-update availability budgets
Deployment rolling updates balance replacement capacity through maxSurge and maxUnavailable. Surge permits additional replicas; unavailability permits fewer available desired replicas during the rollout. These settings guide controller behavior rather than guaranteeing application uptime through unrelated failures. Terminating Pods can temporarily make observed Pod counts exceed the simple desired-plus-surge calculation.
Worked example: Four desired replicas with maxSurge=1 and maxUnavailable=1 allow five nonterminating Pods and a rollout availability target of at least three replicas.
Mistake to avoid: Interpreting the rollout budget as a guarantee against node failures or application errors.
19. Resource requests and limits
Requests influence scheduling by reserving capacity in the scheduler's accounting. Limits constrain runtime resource consumption. CPU limits generally produce throttling, while exceeding a container's memory limit can lead to termination. Compare requests with node allocatable resources, not only physical capacity, and include all relevant containers when evaluating whether a Pod fits.
Worked example: Three Pods each request 200m CPU and 256Mi memory. Together they request 600m CPU and 768Mi memory.
Mistake to avoid: Sizing scheduling capacity from limits or assuming a CPU limit causes memory-style termination.
20. Node selectors and node affinity
A nodeSelector requires matching node labels. Node affinity provides richer required and preferred placement expressions. Required rules constrain eligibility; preferred rules influence ranking among eligible nodes but do not guarantee placement. These mechanisms normally affect scheduling rather than continuously moving already-running Pods whenever labels change.
Worked example: A Pod requires disk=ssd and prefers zone=east. If only a west-zone SSD node is eligible, the preferred rule does not prevent placement there.
Mistake to avoid: Using a preferred affinity rule when placement must be strictly limited to particular nodes.
21. Taints and tolerations
Taints discourage or prevent placement on nodes unless a Pod has a matching toleration. NoSchedule blocks new placement without a suitable toleration, while NoExecute can also affect existing Pods. A toleration permits consideration of a tainted node; it does not attract a Pod there or override resource and affinity constraints.
Worked example: A Pod tolerates dedicated=batch:NoSchedule but requires nodes labeled pool=general. The toleration does not override that conflicting placement requirement.
Mistake to avoid: Assuming that adding a toleration ensures scheduling onto the node carrying the taint.
22. Pod affinity and anti-affinity
Pod affinity and anti-affinity express placement relationships with other Pods selected by labels. A topology key defines the comparison boundary, such as a node or zone. Required anti-affinity can prevent scheduling when there are too few eligible boundaries. Namespace selection also matters because related Pods may reside outside the workload's namespace.
Worked example: Three replicas require separation by hostname, but only two eligible nodes exist. The third replica remains unscheduled rather than sharing a node.
Mistake to avoid: Assuming anti-affinity creates additional capacity or overlooking the topology labels on nodes.
23. Topology spread constraints
Topology spread constraints limit imbalance among eligible topology domains for a selected Pod population. maxSkew defines the permitted difference under the constraint's rules. The unsatisfiable behavior determines whether placement is blocked or merely influenced. Spread constraints distribute Pods; they do not guarantee equal traffic or equal application performance.
Worked example: Two eligible zones contain two and one matching Pods. With maxSkew=1 and strict enforcement, placing another in the less-populated zone preserves an acceptable balance.
Mistake to avoid: Assuming a spread rule balances requests between zones after Pods have been scheduled.
24. Jobs, CronJobs, and repeatable work
Jobs manage work intended to finish successfully; CronJobs create Jobs according to a schedule. Retries, controller reconciliation, and scheduling conditions mean application logic should not assume an operation runs exactly once. Concurrency controls govern overlapping scheduled Jobs, but external effects still need safeguards against duplicate processing and partially completed attempts.
Worked example: A scheduled invoice task uses an invoice identifier as a deduplication key. A retried Job detects the existing invoice instead of issuing a second one.
Mistake to avoid: Treating a successful schedule configuration as an exactly-once execution guarantee.
Services and networking
25. Pod networking and CNI responsibilities
Pods receive network identities that applications can use independently of container names. Containers within a Pod communicate through their shared network namespace. A network implementation supplies Pod connectivity and may also implement policy enforcement. Distinguish basic routing from access restrictions: successful address assignment does not prove cross-node reachability or policy support.
Worked example: Two containers in one Pod communicate through localhost. Containers in different Pods use network addresses or service discovery instead.
Mistake to avoid: Using localhost to reach a separate Pod because both Pods run on the same node.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
26. Service selectors and EndpointSlices
A selector-based Service identifies matching Pods in its own namespace. Kubernetes represents the associated backend endpoints through EndpointSlices, which change as Pods and their readiness change. The Service provides a stable access abstraction while backend identities change. Inspect both selection and endpoint conditions when determining which Pods can receive traffic.
Worked example: A Service in shop selects app=checkout. An identically labeled Pod in analytics is excluded because it belongs to another namespace.
Mistake to avoid: Assuming a Service selector searches every namespace or that a matching label proves readiness.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
27. Service ports and backend ports
A Service's port is the client-facing port; targetPort identifies the destination port on its backend. A named targetPort resolves against named Pod ports and can support backend port changes. Protocol must also match the intended traffic. Declaring containerPort documents a port but does not cause an application to listen there.
Worked example: Clients connect to catalog:8080, while targetPort=9090 sends traffic to the application's listener on port 9090.
Mistake to avoid: Changing containerPort alone when the application still listens on a different port.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
28. Choosing a Service type
ClusterIP supplies an internal virtual address. NodePort exposes an assigned port through eligible node addresses, subject to implementation and network configuration. LoadBalancer requests integration with an external load-balancing implementation. Choose the type according to the required access path, then verify the supporting infrastructure rather than treating resource creation as proof of external reachability.
Worked example: An internal worker needs a database endpoint. ClusterIP satisfies that requirement without requesting an external load balancer.
Mistake to avoid: Assuming LoadBalancer automatically provisions working external infrastructure in every cluster.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
29. Service DNS and namespace qualification
Cluster DNS provides names for Services. A short name usually resolves within the querying Pod's namespace; cross-namespace access requires qualification, such as service.namespace. Fully qualified names also include the configured cluster domain, which should not be assumed universally. DNS discovery avoids the creation-order dependency associated with Service environment variables.
Worked example: A Pod in frontend needs the archive Service in records. It queries archive.records instead of the namespace-local name archive.
Mistake to avoid: Interpreting a short-name lookup failure as proof that a Service in another namespace is missing.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
30. Headless Services and direct discovery
A headless Service sets clusterIP to None, so Kubernetes does not allocate the usual virtual Service IP. With a selector, DNS can return backend Pod addresses directly. Clients must handle the discovered endpoints appropriately because the headless Service does not provide the ordinary virtual-IP proxying and load-balancing behavior.
Worked example: A client needs to choose a particular peer from discovered replicas. A headless Service exposes individual endpoint addresses instead of one virtual IP.
Mistake to avoid: Assuming headless discovery itself distributes requests evenly or guarantees durable Pod addresses.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
31. ExternalName and hostname-sensitive protocols
An ExternalName Service provides a DNS alias to an external hostname rather than proxying traffic to selected Pods. The client still connects using its chosen hostname, which matters for HTTP Host headers and TLS certificate verification. A DNS alias does not rewrite these application-layer identities or automatically make certificates match.
Worked example: A client requests partner-link.apps while the server certificate covers api.partner.example. DNS resolution can succeed even though TLS hostname verification fails.
Mistake to avoid: Treating ExternalName as a reverse proxy that rewrites hostnames and terminates TLS.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
32. Ingress rules and controller execution
Ingress describes HTTP or HTTPS routing to backend Services, commonly using host and path matches. An Ingress controller implements those rules; creating the resource alone does not establish an entry point. TLS termination and routing behavior depend on the controller configuration. Ingress is a separate API resource, not another Service type.
Worked example: A rule sends shop.example's /orders path to the orders Service. Without a functioning controller, the rule remains a definition rather than a working route.
Mistake to avoid: Expecting an Ingress object to expose arbitrary protocols without implementation-specific support.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
33. Gateway API responsibilities
Gateway API separates infrastructure selection, listeners, and application routing through extension resources and an implementing controller. A GatewayClass identifies an implementation, a Gateway describes listeners, and route resources attach routing intent. Installed APIs, controller support, attachment permissions, and status conditions all matter. Resource acceptance does not necessarily mean a route is attached and serving traffic.
Worked example: An HTTPRoute exists but reports that its parent Gateway reference is not accepted. Correct the attachment relationship before debugging the backend application.
Mistake to avoid: Assuming Gateway API resources work without their CRDs and a compatible implementation.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
34. NetworkPolicy isolation and additive rules
NetworkPolicy controls selected Pods' ingress or egress when the network implementation supports enforcement. Isolation is directional. Allowed traffic is the union of applicable policy rules, rather than an ordered firewall rule list. For a connection between isolated Pods, both the source's egress rules and destination's ingress rules must permit the traffic.
Worked example: A server permits frontend ingress, but the frontend's egress policy excludes the server. The connection remains blocked despite the server-side allowance.
Mistake to avoid: Expecting one permissive ingress policy to override a separate egress restriction.
35. NetworkPolicy peer selector logic
Within one NetworkPolicy peer entry, namespaceSelector and podSelector combine to identify Pods matching both criteria. Separate peer entries offer alternative allowed sources or destinations. A podSelector without a namespaceSelector selects peers in the policy's namespace. Small structural changes can therefore expand access far beyond the intended population.
Worked example: One peer entry combining namespace label team=payments with Pod label role=client admits only matching client Pods in matching namespaces.
Mistake to avoid: Splitting those selectors into separate peer entries when both restrictions must apply together.
36. Selectorless Services and managed endpoints
A Service without a selector does not receive automatically selected Pod endpoints. Its EndpointSlices must be supplied and linked through the kubernetes.io/service-name label. Endpoint addresses must satisfy Kubernetes restrictions and cannot simply be other Services' cluster IPs. API-server proxy operations also have restrictions when endpoints are not mapped to Pods.
Worked example: A selectorless reporting Service points to an approved external database through a linked EndpointSlice. Creating only the Service would leave it without those backend endpoints.
Mistake to avoid: Expecting automatic endpoint creation or using another Service's virtual IP as a backend.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
Persistent storage
37. Volume lifetime and data persistence
A container's writable filesystem, a Pod-scoped volume, and persistent storage have different lifetimes. An emptyDir survives container restarts within its Pod but is removed when that Pod is removed. PersistentVolumes can outlive individual Pods, subject to backend and reclaim behavior. Match the storage lifetime to the application's recovery requirements.
Worked example: A processor restarts its container and retains scratch files in emptyDir. Replacing the Pod removes those files, so durable results belong elsewhere.
Mistake to avoid: Assuming survival of one container restart proves that data survives Pod replacement.
38. PersistentVolume and claim matching
A PersistentVolume represents available storage; a PersistentVolumeClaim requests storage for a workload. Binding considers requirements such as capacity, access modes, storage class, and volume mode. Requested capacity is a minimum, not necessarily an exact-size match. A bound claim supplies an association, while successful mounting and application access require further conditions.
Worked example: A 6Gi claim can bind to an otherwise compatible 8Gi volume. A 4Gi volume cannot satisfy that requested capacity.
Mistake to avoid: Checking capacity alone while ignoring storage class, access modes, or volume mode.
39. StorageClasses and dynamic provisioning
A StorageClass describes a provisioning approach through a provisioner and associated parameters. Dynamic provisioning can create storage when a suitable claim requests that class, provided the implementation is available. A class is not the storage itself. Inspect the claim, class, provisioner, and backend conditions separately when requested storage does not appear.
Worked example: A claim requests class fast-block, but no matching StorageClass exists. Supplying more worker capacity does not resolve the missing provisioning configuration.
Mistake to avoid: Assuming any named StorageClass works without a corresponding provisioner and backend.
40. Access modes and mount expectations
ReadWriteOnce describes read-write mounting by one node, not necessarily one Pod. Multiple Pods on that node may share the volume when the implementation and workload permit it. ReadWriteMany supports multi-node access only with a suitable backend. Access modes express storage capabilities and constraints; they are not general filesystem permission controls.
Worked example: Two Pods on the same node use a ReadWriteOnce volume. That arrangement does not inherently violate its single-node access requirement.
Mistake to avoid: Interpreting ReadWriteOnce as an exclusive single-Pod lock or automatic protection against concurrent writes.
41. Reclaim policy and deletion consequences
A PersistentVolume's reclaim policy determines the intended handling of storage after its claim is released. Retain preserves the backing asset for administrator-managed recovery, while Delete requests removal through the supporting implementation. Confirm the actual volume policy and backend behavior before deleting claims. Retained storage also requires deliberate cleanup and reassignment procedures.
Worked example: A test claim binds to a volume with Delete policy. Removing the claim can lead to deletion of its backing disk, so needed data must be protected first.
Mistake to avoid: Assuming claim deletion removes only Kubernetes metadata while always preserving stored data.
42. Storage topology and delayed binding
Some storage is usable only from particular nodes or zones. Delayed binding, commonly configured through WaitForFirstConsumer, lets provisioning or binding consider the consuming Pod's scheduling constraints. This helps align storage placement with compute placement. A claim awaiting a consumer may therefore be behaving correctly rather than indicating a failed storage backend.
Worked example: A claim uses delayed binding and has no consuming Pod. Its Pending state is expected; creating the intended workload provides placement context.
Mistake to avoid: Forcing an early binding that places storage where the workload cannot run.
Workload troubleshooting
43. Pod phase versus container state
Pod phase summarizes lifecycle, while container states and conditions provide more specific evidence. A Running Pod can contain a restarting or unready container. Pending can reflect scheduling delays or later preparation steps such as image retrieval. Inspect conditions, assigned node, container states, and events rather than drawing a diagnosis from one displayed status.
Worked example: A Pod is Running but Ready=False because its application container fails readiness checks. It is executing, yet should not receive normal Service traffic.
Mistake to avoid: Equating Running with application health or Pending exclusively with scheduler failure.
44. Unscheduled Pods and constraint conflicts
For an unscheduled Pod, scheduler events identify unmet placement conditions such as insufficient requested resources, taints, affinity rules, or storage topology. Compare the complete Pod requirements with eligible nodes. Available physical capacity on an excluded node is irrelevant. Resolve the identified constraint rather than repeatedly deleting the Pod and expecting different placement.
Worked example: An event reports insufficient memory on the only SSD-labeled node. Free CPU on an unlabeled node cannot satisfy the Pod's SSD requirement.
Mistake to avoid: Removing placement restrictions indiscriminately before determining why they were required.
45. Image retrieval failures
Image pull failures occur before the application process starts. Events help distinguish an unknown image reference, unavailable registry, denied credentials, or node-side connectivity problem. Check the exact image name and tag, relevant pull credentials, and affected nodes. A valid local image on one node does not prove all nodes can retrieve it.
Worked example: Events report registry authorization denied for a private image. Correct the applicable pull credentials rather than changing the application's command.
Mistake to avoid: Debugging application code when Kubernetes has not yet obtained its container image.
46. Crash loops and previous termination evidence
CrashLoopBackOff describes delayed restart attempts after repeated container failures; it does not identify their cause. Inspect the last termination reason, exit code, events, and previous container logs. Separate process exits from probe-triggered restarts and resource-related termination. Current logs may omit the evidence from the instance that already failed.
Worked example: kubectl -n tools logs parser -c worker --previous shows a missing configuration file. Restore the expected configuration source before investigating scheduler behavior.
Mistake to avoid: Treating the backoff delay as the root cause or reading only the latest container instance.
47. Readiness, liveness, and startup probes
Readiness determines whether a container is ready to serve traffic. Liveness failure can cause a restart, while a startup probe protects initialization by delaying liveness and readiness probing until it succeeds. Design each check for its purpose. Temporary dependence on a remote service may justify lost readiness without proving the local process needs restarting.
Worked example: A slow-initializing application is healthy after startup. A startup probe accommodates initialization instead of allowing an early liveness check to restart it repeatedly.
Mistake to avoid: Using identical dependency checks for readiness and liveness without considering restart consequences.
48. Container memory failure versus node eviction
A container can be terminated after exceeding its memory limit, while a Pod can be evicted because the node is under resource pressure. These are different failure paths. Examine termination reasons, Pod events, node conditions, limits, and usage together. Increasing a container limit without checking node capacity can worsen pressure elsewhere.
Worked example: The container's last state reports OOMKilled, while the Pod has no eviction event. Investigate the container's memory demand and limit first.
Mistake to avoid: Treating every disappearance or memory-related restart as the same event with the same remedy.
49. Process startup and filesystem access
A successfully pulled image can still fail because its command, arguments, working directory, or file permissions are incompatible with the container environment. Kubernetes does not automatically invoke a shell for every command. Diagnose the actual process invocation and execution identity before changing unrelated networking or scheduling settings.
Worked example: A container runs under a restricted user and reports permission denied when opening its configuration. Align file access with that identity rather than changing its Service.
Mistake to avoid: Assuming shell operators work in command arguments without an explicitly invoked shell.
50. Selecting the right logs
Logs must be associated with the correct Pod, container, and execution instance. Multi-container Pods require explicit container selection when investigating a particular process, and failed init containers can provide evidence before application startup. Standard container logs capture output written to the logging streams; files inside the container may need a different inspection path.
Worked example: The application logs are empty because initialization failed. Inspecting the config-builder init container reveals the failed prerequisite.
Mistake to avoid: Concluding that no error occurred because the main container has not produced output.
51. Owner references and recurring changes
Controllers manage dependent objects through ownership and desired state. Editing or deleting an individual managed Pod may be temporary because its controller creates replacements from a template. Trace owner references to find the resource that controls the relevant setting. Make the intended change at that level and verify the resulting managed objects.
Worked example: Deleting a ReplicaSet-managed Pod does not reduce the Deployment's requested replica count. A replacement appears because the desired count remains unchanged.
Mistake to avoid: Repeatedly modifying child Pods while leaving the controlling workload template unchanged.
Cluster and infrastructure troubleshooting
52. Node readiness and local dependencies
Node readiness reflects information reported through the kubelet and its supporting environment. Investigate node conditions, recent events, kubelet health, runtime availability, resource pressure, and connectivity to the API server. Distinguish one-node failures from cluster-wide symptoms. A reachable machine can still be unsuitable for Kubernetes workloads.
Worked example: Only one node becomes NotReady, and its container runtime is unavailable. Investigate that local dependency before changing cluster-wide application definitions.
Mistake to avoid: Using successful host connectivity as proof that the kubelet and runtime are functioning.
53. Locating API access failures
API access follows a chain: endpoint resolution, network connection, TLS verification, authentication, authorization, and request handling. Error messages identify different boundaries. A timeout differs from an authentication rejection or forbidden operation. Check the configured endpoint and the earliest failing layer before investigating components that the request never reached.
Worked example: kubectl reaches the API server but receives Forbidden when listing Nodes. Investigate authorization rather than DNS or container networking.
Mistake to avoid: Treating all kubectl failures as API-server downtime or bypassing security checks to hide the cause.
54. Etcd health and consensus failures
Etcd problems can prevent reliable cluster-state reads or updates even while some API endpoints remain reachable. Diagnose member availability, connectivity, storage health, and quorum before considering recovery. Preserve evidence and data; membership changes and restore operations require the documented procedure for the actual deployment. More API-server replicas do not repair consensus.
Worked example: Two members of a three-member etcd cluster are unavailable. Restoring API-server connectivity alone cannot restore the required two-member quorum.
Mistake to avoid: Deleting etcd data or reinitializing members before identifying the failure and preserving recoverable state.
55. Certificate trust, names, and time
TLS verification checks the certificate's trust chain, validity interval, and identity match for the endpoint. Failures can arise from expired certificates, incorrect names, an untrusted issuer, or incorrect system time. These checks differ from Kubernetes authorization. Repair the identified configuration through the applicable certificate-management procedure rather than disabling verification.
Worked example: A certificate covers api.cluster.example, but kubeconfig connects to an unrelated hostname. Use a correctly covered endpoint or an appropriately issued certificate.
Mistake to avoid: Interpreting a TLS identity mismatch as an RBAC problem.
56. DNS failure isolation
Separate name resolution from transport and application behavior. Test the intended name, its namespace qualification, and a known destination address under equivalent conditions. If address-based access works while resolution fails, inspect Pod resolver configuration, DNS endpoints, DNS-service health, and policies affecting DNS traffic. Both UDP and TCP may matter for DNS.
Worked example: A backend responds through its Service IP, but its qualified Service name fails to resolve. Investigate the DNS path before changing the backend listener.
Mistake to avoid: Assuming a successful lookup proves the resolved endpoint is reachable or healthy.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
57. Tracing a Service traffic path
A Service request depends on discovery, the client-facing port, selected ready endpoints, backend port mapping, and the cluster's forwarding implementation. Test progressively from backend access to Service access and then external exposure. Preserve the same protocol and request assumptions. Each successful step narrows the remaining fault boundary.
Worked example: A Pod responds directly on port 9080, but its Service targets 9081. Correcting targetPort resolves the mismatch without replacing the healthy application.
Mistake to avoid: Recreating a working backend before inspecting Service selection and destination-port configuration.
Reference: Certified Kubernetes Administrator (CKA) | CNCF; Service | Kubernetes
58. Cross-node network diagnosis
Compare same-node and cross-node Pod communication to locate network failures. If same-node traffic works but cross-node traffic fails, investigate the network implementation's inter-node path, routing, encapsulation where used, and relevant firewall restrictions. Also verify policy and address overlap. Avoid assuming every network implementation uses identical transport mechanisms or ports.
Worked example: Two Pods communicate when colocated but fail when separated across nodes. That pattern points toward an inter-node path issue rather than a missing application listener.
Mistake to avoid: Opening guessed ports without identifying the installed network implementation and its requirements.
59. Provisioning, attachment, mounting, and file access
Storage failures occur at different stages: provisioning a volume, binding a claim, attaching storage, mounting it, or accessing files from the application. Pod events and claim status help identify the stage. A bound PVC does not prove the volume mounted, and a successful mount does not prove the process has suitable filesystem permissions.
Worked example: The PVC is Bound, but Pod events report a mount failure. Investigate node-side mounting and driver conditions rather than creating another claim.
Mistake to avoid: Treating every storage error as a capacity shortage or assuming Bound means application-ready.
60. Safe node maintenance and disruption budgets
Cordoning prevents ordinary new scheduling onto a node but does not move existing Pods. Draining requests workload evacuation and can encounter disruption budgets, unmanaged Pods, DaemonSet Pods, and local-data constraints. A PodDisruptionBudget limits supported voluntary disruptions; it does not prevent every failure. Assess replacement capacity and data consequences before authorized maintenance.
Worked example: Two replicas have a disruption budget requiring both available. Evicting one is blocked; restore suitable availability or revise the approved maintenance plan.
Mistake to avoid: Bypassing an eviction safeguard without understanding availability requirements and local-data loss.
Sources
Sources checked:
All study guides