This guide is for candidates preparing for the Kubernetes and Cloud Native Associate (KCNA) exam. It starts with containers and Kubernetes foundations, then develops networking, security, storage, observability, and application delivery. Use the examples to connect each concept to a concrete situation, and the mistakes to check whether you understand the distinction being taught.
Container Foundations
1. Containers and virtual machines
A container packages an application and its user-space dependencies while using the host operating system’s kernel. A virtual machine runs a guest operating system through virtualization. This distinction explains why containers are often lightweight, but also why their isolation and operating-system compatibility differ from those of virtual machines.
Worked example: Two Linux containers can use different application libraries while sharing one Linux kernel. Updating a library inside one image does not update the host kernel.
Mistake to avoid: Assuming every container includes its own independently running kernel.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
2. Image layers and writable container state
A container image is a packaged template built from filesystem layers and configuration. Running a container adds writable state over that image. Changes made in the running container do not automatically become part of the original image, so rebuilding or replacing the container can lose changes kept only in its writable layer.
Worked example: An operator edits a configuration file inside a running container. A replacement created from the unchanged image receives the original configuration.
Mistake to avoid: Treating an interactive container edit as a durable image update.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
3. Image tags and content digests
A tag is a readable reference that a registry can move to another image. A digest identifies specific image content. Using a digest improves reproducibility because repeated pulls identify the same content. Neither a familiar tag nor a digest alone establishes that an image is trusted or free of vulnerabilities.
Worked example: If the tag release points to image A today and image B tomorrow, two deployments can differ. Referencing A’s digest fixes the selected content.
Mistake to avoid: Assuming an unchanged tag guarantees an unchanged image.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
4. Linux namespaces and control groups
On Linux, namespaces isolate views of resources such as processes and networking, while control groups account for and constrain resource use. They solve different problems: isolation changes what a process can see; resource controls influence what it can consume. These mechanisms contribute to container operation without providing an absolute security boundary.
Worked example: A container can see its own process list through a process namespace while a control group constrains its CPU consumption.
Mistake to avoid: Expecting process isolation by itself to limit memory use.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
5. Container standards and runtime interfaces
Open Container Initiative specifications describe interoperable image and runtime formats. Kubernetes uses the Container Runtime Interface to communicate with compatible runtimes. These occupy different layers: image standards support portable packaging, while the runtime interface lets Kubernetes request container operations. An image-building tool does not have to be the runtime used on cluster nodes.
Worked example: A team builds an OCI-compatible image on a workstation and runs it through a CRI-compatible runtime in Kubernetes.
Mistake to avoid: Treating OCI and CRI as interchangeable names for one interface.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
6. The container’s main process
A container’s lifecycle is tied to its main process. If that process exits, the container stops; an orchestration policy may then restart it. Long-running services and finite tasks therefore need different expectations. A successfully completed batch process can be healthy even though its container is no longer running.
Worked example: A report generator writes its output and exits successfully. A Job can record completion instead of requiring the process to run indefinitely.
Mistake to avoid: Assuming every stopped container represents an application failure.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
Kubernetes Architecture and Administration
7. Clusters, nodes, and the control plane
A Kubernetes cluster combines a control plane with nodes that run workloads. The control plane manages cluster state and placement decisions; node components execute and monitor assigned workloads. A Pod is a workload unit, not a machine. Understanding these layers helps locate responsibility when an application or infrastructure component fails.
Worked example: A failed worker node affects its Pods. The remaining control plane can still coordinate replacement workloads on suitable healthy nodes.
Mistake to avoid: Using Pod, node, and cluster as equivalent terms.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
8. The API server as the management entry point
The API server exposes Kubernetes resources to clients and components. Requests pass through controls such as authentication, authorization, and admission before accepted changes are persisted. Tools such as kubectl interact with this API. Acceptance of a resource records desired state; it does not prove that the workload has already started successfully.
Worked example: Creating a Deployment succeeds, but its Pods remain Pending because no node can satisfy their requirements.
Mistake to avoid: Equating successful API submission with a healthy application.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
9. etcd and stored cluster state
etcd is the key-value store used by Kubernetes to persist cluster state. It holds resource data rather than serving as an application’s general-purpose database. Protecting and recovering this state matters for cluster management, but restoring it does not automatically restore application data stored on separate persistent volumes or external systems.
Worked example: Recovering Deployment definitions from cluster state does not recover customer records held in an external database.
Mistake to avoid: Assuming a cluster-state backup includes every application’s data.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
10. The scheduler’s placement responsibility
The scheduler selects suitable nodes for Pods that have not yet been assigned. It considers constraints and available requested resources, then records an assignment. It does not execute application processes itself. Scheduling and execution are separate steps, so a successfully assigned Pod can still encounter image, configuration, or runtime failures.
Worked example: A Pod is assigned to node cedar but cannot pull its image. Placement succeeded; container startup did not.
Mistake to avoid: Expecting the scheduler to download images or launch containers.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
11. Controllers and reconciliation
Controllers repeatedly compare desired state with observed state and take actions to reduce differences. This reconciliation model supports recovery after failures and changes. It is continuous rather than a one-time installation step. Controllers manage their own resource relationships, so directly editing an object they control may produce only a temporary result.
Worked example: A controller manages three replicas. When one managed Pod disappears, it creates a replacement to restore the requested count.
Mistake to avoid: Expecting a manually deleted managed Pod to stay absent.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
12. The kubelet and node execution
The kubelet runs on a node and works to keep assigned Pod containers running according to their specifications. It coordinates with the container runtime and reports status to the control plane. This local execution role differs from scheduling: the scheduler chooses placement, while the kubelet handles workloads already assigned to its node.
Worked example: A Pod is assigned successfully, but the node’s runtime is unavailable. The node execution path needs investigation.
Mistake to avoid: Assuming node execution problems always originate in the scheduler.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
13. Desired specification and observed status
Many Kubernetes resources separate spec, which expresses desired state, from status, which reports observed conditions. Comparing them reveals whether reconciliation has achieved the requested outcome. Status can change asynchronously, so a recent specification update may take time to appear as healthy running resources.
Worked example: A Deployment requests four replicas while status reports two available. The request exists, but availability has not reached the desired level.
Mistake to avoid: Reading the requested replica count as proof of actual availability.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
14. kubectl contexts and namespaces
A kubectl context associates a cluster, a user identity, and optionally a default namespace. The active context determines where commands are directed unless overridden. Namespaced commands also depend on the selected namespace. Checking both resolves many apparent missing-resource problems and reduces the chance of changing the wrong environment.
Worked example: A Deployment exists in namespace billing, but kubectl get deployments checks default. Selecting billing makes the resource visible.
Mistake to avoid: Assuming an empty listing means the resource is absent from every namespace.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
Workloads and Configuration
15. Pods as shared execution units
A Pod contains one or more containers that share a network identity and can share declared volumes. Containers belong together when they require close coordination and a shared lifecycle. Independent services usually need separate Pods so that they can scale, update, and fail independently.
Worked example: A helper that processes files written by the main container can share a Pod volume. An unrelated payment service belongs in its own workload.
Mistake to avoid: Packing unrelated services into one Pod solely to reduce object count.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
16. Deployments and ReplicaSets
A Deployment manages updates to a replicated workload through ReplicaSets. A ReplicaSet maintains the requested number of matching Pods, while the Deployment coordinates changes to the Pod template. Changing application configuration in the template can create a new rollout; scaling changes replica count without necessarily changing the application version.
Worked example: Increasing replicas from two to five adds capacity. Changing the container image initiates a version rollout.
Mistake to avoid: Treating scaling and updating the Pod template as the same operation.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
17. Labels and selectors
Labels attach identifying metadata to resources. Selectors match resources using those labels, creating relationships such as a Service selecting its backend Pods. Labels do not have built-in application meaning: their usefulness depends on consistent matching. A resource name alone does not establish a selector relationship.
Worked example: A Service selects app=ledger, but Pods carry app=ledger-api. The selector matches no Pods until the intended labels and selector agree.
Mistake to avoid: Assuming similarly named resources automatically connect to each other.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
18. Namespaces and resource boundaries
Namespaces organize namespaced resources and provide a scope for controls such as access rules and quotas. Some resources, including nodes, are cluster-scoped. A namespace is not an automatic network or security boundary: isolation requires appropriate policies and permissions in addition to organizational separation.
Worked example: Teams amber and violet use separate namespaces, but network communication can remain possible unless applicable network policies restrict it.
Mistake to avoid: Assuming namespace separation alone prevents cross-team communication.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
19. ConfigMaps and application configuration
ConfigMaps hold non-confidential configuration separately from container images. Applications can consume their values through mechanisms such as environment variables or mounted files. Updating the ConfigMap does not guarantee immediate application behavior changes: environment variables require container recreation, and mounted-file consumers must support observing or reloading changed configuration.
Worked example: A container receives REGION through an environment variable. Updating the ConfigMap does not change that existing process’s environment.
Mistake to avoid: Assuming all ConfigMap updates automatically reconfigure running applications.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
20. StatefulSets and stable workload identity
StatefulSets support workloads that need stable Pod identities and associations with persistent storage. These properties help applications whose members are not interchangeable. The controller supplies workload identity and lifecycle coordination; the application still needs its own data replication, consistency, and recovery mechanisms where required.
Worked example: A database member needs a stable identity and its associated volume after replacement. A StatefulSet can support that relationship.
Mistake to avoid: Assuming a StatefulSet automatically replicates database data or provides backups.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
21. DaemonSets and node-local services
A DaemonSet maintains a Pod on each eligible node, making it suitable for node-local functions such as log collection or networking agents. Eligibility depends on workload and node constraints. Its placement follows nodes rather than a fixed application replica target.
Worked example: A log collector should run on every eligible worker. Adding another eligible worker causes the DaemonSet to provide a collector there.
Mistake to avoid: Choosing a DaemonSet for an application that simply needs four replicas.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
Resources and Scheduling
22. Resource requests and limits
Resource requests inform scheduling and resource allocation; limits constrain consumption where supported. CPU limits can cause throttling, while exceeding a memory limit can lead to termination. Requests do not guarantee that an application will never need more resources, and limits do not create additional node capacity.
Worked example: A container requests 250 millicores and has a 500-millicore CPU limit. Placement uses its request; sustained excess CPU demand can be throttled.
Mistake to avoid: Using a low request as evidence that the application’s peak demand is low.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
23. Calculating scheduling capacity
Scheduling capacity depends on node allocatable resources minus requests already assigned, together with other placement constraints. Calculate each resource independently; sufficient CPU does not compensate for insufficient memory. Use allocatable capacity rather than the machine’s advertised hardware total because some resources support system and cluster functions.
Worked example: A node has 2,000 millicores allocatable and 1,250 requested. Three Pods requesting 250 each fit the remaining 750 millicores, assuming other constraints permit.
Mistake to avoid: Estimating schedulability from current CPU usage instead of resource requests.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education
24. Node selectors and affinity
Node selectors and node affinity express placement requirements or preferences using node labels. Required constraints exclude nodes that do not match; preferred constraints influence selection without guaranteeing it. Placement rules must agree with actual labels and resource availability, otherwise a Pod may remain unscheduled.
Worked example: A Pod requires disk=ssd. Only nodes carrying that label qualify, even if an unlabeled node has more free CPU.
Mistake to avoid: Treating a preferred placement rule as an absolute requirement.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
25. Taints and tolerations
Taints discourage or prevent placement on nodes according to their effect. A matching toleration allows a Pod to tolerate a taint, but does not require placement on that node. Positive placement constraints, such as node affinity, may also be needed when a workload must use a particular node group.
Worked example: A Pod tolerates a dedicated-node taint. It can still run on an untainted suitable node unless another rule constrains placement.
Mistake to avoid: Assuming a toleration selects or reserves a node.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education
26. Resource quotas and namespace capacity
ResourceQuota constrains aggregate resource consumption or object counts within a namespace. It controls whether proposed resource changes fit the namespace’s allowance; it does not add physical cluster capacity. Namespace quota availability and node scheduling availability are separate checks, and a workload must satisfy both.
Worked example: A namespace has room for another Pod under its quota, but every eligible node lacks sufficient requested memory. The Pod can remain Pending.
Mistake to avoid: Interpreting unused namespace quota as guaranteed space on a node.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education
Cloud Native Principles and Community
27. Microservices and distributed boundaries
Microservices divide an application into independently deployable services with explicit interfaces. This can support separate ownership and scaling, but introduces network failures, latency, and distributed coordination. A useful boundary follows a coherent capability; splitting every small function into a service can increase operational complexity without providing meaningful independence.
Worked example: Separating catalog search from checkout allows independent scaling, but checkout must handle a slow or unavailable catalog dependency.
Mistake to avoid: Assuming more services automatically produce a more reliable architecture.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
28. Horizontal scaling and resilience
Horizontal scaling adds workload instances; resilience concerns continuing useful service despite failures. Multiple replicas help only when traffic can reach healthy instances and necessary state is managed appropriately. Shared dependencies and common failure locations can still defeat replication, so replica count alone does not establish fault tolerance.
Worked example: Four API replicas share one unavailable database. Adding two API replicas does not restore database-dependent requests.
Mistake to avoid: Expecting additional application replicas to repair every dependency failure.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
29. Immutable infrastructure
Immutable infrastructure favors replacing deployed units from defined artifacts instead of repeatedly modifying them in place. This reduces configuration drift and makes changes easier to reproduce. Persistent business data still needs explicit storage and lifecycle management; replacing an application unit should not imply discarding the data it serves.
Worked example: A team fixes a library vulnerability by rebuilding an image and replacing workloads, while retaining customer data in persistent storage.
Mistake to avoid: Confusing immutable application deployment with disposable business data.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
30. CNCF projects and open collaboration
The CNCF ecosystem contains projects with different technical responsibilities, rather than one product that supplies every capability. Kubernetes orchestrates workloads; other projects address areas such as monitoring, proxies, and logging. Open collaboration relies on project documentation, contribution processes, and interoperable interfaces. Project affiliation alone does not determine suitability for a specific architecture.
Worked example: A team evaluates Prometheus for metrics and Fluentd for log handling because they solve different observability tasks.
Mistake to avoid: Selecting a project solely because it appears in the cloud native landscape.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
Networking and Service Communication
31. Pod networking and localhost
Containers in the same Pod share a network namespace and can communicate through localhost. Containers in different Pods normally use Pod addresses or Services rather than each other’s localhost. Pod networking is supplied by cluster networking components, and actual reachability can also depend on policies and application listening addresses.
Worked example: A helper reaches its same-Pod application at localhost:8080. A separate client Pod must use an appropriate network address instead.
Mistake to avoid: Using localhost to reach an application running in another Pod.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
32. Services, backends, and ports
A Service provides a stable way to reach a changing set of backends. For selector-based Services, matching Pods supply backend endpoints, with readiness influencing normal traffic eligibility. The Service port is the client-facing port; targetPort identifies the backend port. Both selector matching and port alignment matter.
Worked example: Clients use Service port 80 while targetPort is 8080. The application must listen on the intended backend port, 8080.
Mistake to avoid: Assuming the Service port must equal the container’s listening port.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
33. Service discovery through DNS
Cluster DNS lets workloads discover Services by name instead of depending on changing Pod addresses. Short names are resolved using the caller’s namespace context; names that include the target namespace help identify cross-namespace Services. DNS resolution and successful application communication are separate stages of diagnosis.
Worked example: A client in reports reaches the database Service in finance using database.finance. Resolving that name does not prove the database accepts connections.
Mistake to avoid: Treating successful DNS lookup as proof of application health.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
34. Service exposure types
ClusterIP supplies an internal Service address. NodePort exposes a Service through a port on cluster nodes. LoadBalancer requests integration with an external load-balancing mechanism, whose availability depends on the environment. Choose exposure according to the required access path rather than assuming every Service needs public reachability.
Worked example: An internal inventory API can use ClusterIP. An external entry point needs an exposure mechanism supported by its cluster environment.
Mistake to avoid: Assuming a LoadBalancer Service always receives a public address automatically.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
35. Ingress and HTTP routing
Ingress describes HTTP and HTTPS routing to Services, commonly using hostnames and paths. An Ingress controller implements those rules; creating an Ingress resource alone does not supply the controller. The routing configuration must also align with reachable backends and any intended TLS setup.
Worked example: Rules send shop.example to a storefront Service and api.example to an API Service. A functioning controller must process those rules.
Mistake to avoid: Expecting an Ingress manifest alone to create a working external router.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
36. NetworkPolicy and traffic isolation
NetworkPolicy expresses allowed traffic for selected Pods when the networking implementation supports enforcement. Isolation applies separately to ingress and egress. Allowances from applicable policies combine, and when both sides are isolated, the source’s egress and destination’s ingress rules must permit the connection. Policies do not provide application authentication or encryption.
Worked example: An API allows database egress, but the database’s ingress rules exclude the API Pods. The connection remains blocked.
Mistake to avoid: Checking only one side of an isolated connection.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
37. Service meshes and application traffic
A service mesh adds a layer for managing service-to-service traffic, often using proxies. Depending on its implementation and configuration, it can provide traffic policy, telemetry, and mutual TLS. Kubernetes Services supply discovery and connectivity, while a mesh addresses additional communication behavior and introduces its own operational complexity.
Worked example: A team needs authenticated, encrypted communication between internal services and evaluates a mesh that can enforce mutual TLS.
Mistake to avoid: Assuming installing a mesh automatically applies every intended security policy.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
Security and Operational Diagnosis
38. Authentication, authorization, and RBAC
Authentication establishes an identity; authorization decides which actions that identity may perform. Kubernetes RBAC grants permissions through roles and bindings. Namespace-scoped and cluster-scoped permissions differ, and a workload’s service account can require a different permission set from a human administrator. Successful authentication does not imply permission to access every resource.
Worked example: A user can authenticate but receives a forbidden response when listing Secrets because their bound permissions do not allow that action.
Mistake to avoid: Responding to every forbidden error by changing authentication credentials.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
39. Secrets and sensitive configuration
Secrets hold sensitive configuration separately from ordinary application settings. Base64 encoding represents data; it does not encrypt it. Effective protection also depends on access controls, storage protection, and careful handling by workloads and operators. Avoid exposing secret values through logs, broadly readable configuration, or unnecessary API permissions.
Worked example: A password stored as base64 remains recoverable by anyone who can read that Secret’s data. Restricting read access is therefore essential.
Mistake to avoid: Treating base64-encoded values as encrypted credentials.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
40. Least privilege across workload boundaries
Least privilege means granting only the access needed for a defined task. Apply it to API permissions, container execution privileges, host access, and network reachability. These are separate controls: restricting API permissions does not remove filesystem or operating-system privileges from a container. Review each boundary according to the workload’s actual function.
Worked example: A web application that reads one configuration resource does not need permission to delete workloads or privileged access to its host.
Mistake to avoid: Granting broad administrator privileges simply to eliminate configuration errors.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
41. Interpreting Pod and container symptoms
Diagnostic labels identify stages or symptoms, not complete root causes. Pending can include scheduling or setup delays; ImagePullBackOff points toward repeated image-pull failure; CrashLoopBackOff indicates repeated container failure with restart backoff. Examine detailed status and events before selecting a remedy, because similar visible symptoms can arise from different causes.
Worked example: A Pod shows ImagePullBackOff and an event reports an unknown image tag. Correcting the image reference addresses the identified failure.
Mistake to avoid: Treating every non-running Pod as an application code crash.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education
42. Readiness, liveness, and startup probes
Readiness checks whether a container should receive normal Service traffic. Liveness checks whether it should be restarted. A startup probe gives initialization its own check before liveness and readiness begin. Probe design should reflect these purposes; a dependency outage should not automatically trigger repeated restarts of an otherwise functioning application.
Worked example: An API temporarily cannot serve requests while loading data. Readiness can withhold traffic without using that condition as a restart signal.
Mistake to avoid: Assuming a failed readiness probe restarts the container.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
43. Events and container logs
Events describe Kubernetes-level observations such as scheduling and image-pull problems. Container logs expose application output and can explain startup or request failures. These evidence sources complement each other. In multi-container Pods, select the relevant container, and after a restart, previous-container logs may contain the failure that current logs no longer show.
Worked example: Events show successful startup, but previous logs reveal that the application exited because a required configuration value was missing.
Mistake to avoid: Inspecting only current logs after a repeatedly restarting container has failed.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
Storage Foundations
44. Ephemeral volumes and Pod lifetime
An ephemeral volume such as emptyDir can share files among containers in one Pod and survives individual container restarts within that Pod. Its lifetime remains tied to the Pod. It is appropriate for temporary working data, but replacement of the Pod removes that storage rather than transferring it to the replacement.
Worked example: A helper reads files from an emptyDir after the main container restarts. Deleting the Pod removes those files.
Mistake to avoid: Using Pod-lifetime storage as the only copy of durable business data.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
45. PersistentVolumes and PersistentVolumeClaims
A PersistentVolume represents storage available to the cluster, while a PersistentVolumeClaim requests storage for a workload. Claims connect application requirements to compatible volumes. Persistent storage has a lifecycle separate from a container, but retention after claim deletion depends on the configured reclaim behavior and the underlying storage system.
Worked example: A replacement application Pod mounts the same claim and accesses existing files. Deleting the claim requires checking the storage retention behavior.
Mistake to avoid: Assuming persistent means data survives every resource deletion.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
46. StorageClasses and dynamic provisioning
A StorageClass describes a storage provisioning option and its associated behavior. With a compatible provisioner, a claim can trigger dynamic creation of storage instead of requiring a pre-created volume. A named class alone does not supply a working storage backend; provisioning also depends on the driver, infrastructure, and requested characteristics.
Worked example: A claim requests class fast-disk, but its provisioner cannot create storage. The claim remains unfulfilled until the provisioning problem is resolved.
Mistake to avoid: Assuming a StorageClass definition guarantees available storage capacity.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
47. Storage access modes and writers
Access modes express supported mounting arrangements. ReadWriteOnce concerns read-write access from one node and can permit multiple Pods on that node. ReadWriteMany supports multiple-node access when the backend supports it. These modes do not by themselves establish application-level locking, safe concurrent writes, or database consistency.
Worked example: Two Pods on one node may use a ReadWriteOnce volume, but their application must still coordinate conflicting file writes.
Mistake to avoid: Interpreting ReadWriteOnce as a universal one-Pod-only guarantee.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
Observability and Reliability Signals
48. Metrics, logs, and traces
Metrics summarize numerical behavior over time, logs record events or messages, and traces follow operations across components. Each answers a different diagnostic question. Combining them helps connect a broad symptom to a specific request path and its failure details, provided identifiers and timestamps allow the evidence to be correlated.
Worked example: A latency metric rises, a trace locates a slow database call, and a correlated log explains that the query retried.
Mistake to avoid: Expecting one aggregate metric to identify the exact failing request.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
49. Prometheus metrics and label cardinality
Prometheus collects metrics as time series, commonly by scraping exposed endpoints. Labels distinguish dimensions such as service or status. Every distinct label combination creates a separate series, so unbounded values can make collection and querying expensive. Counters track cumulative events; rates describe how quickly those events occur.
Worked example: A request counter increases from 900 to 1,020 over 60 seconds, with no reset. Its average rate is 2 requests per second.
Mistake to avoid: Using unique request identifiers as routine metric labels.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
50. Service indicators, objectives, and error budgets
A service-level indicator measures an aspect of service behavior, while a service-level objective sets a target for that indicator over a defined window. The error budget is the tolerated shortfall. Define eligible events and success consistently so that the calculation represents the user experience rather than a convenient infrastructure statistic.
Worked example: For 10,000 eligible requests, a 99% success objective permits 100 failures. If 70 fail, 30 failures remain within that budget.
Mistake to avoid: Choosing a high CPU-utilization target as a substitute for request success.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
Application Delivery and Debugging
51. Continuous integration and delivery
Continuous integration combines changes with automated validation to expose integration problems early. Continuous delivery keeps validated changes ready for release; continuous deployment automatically releases qualifying changes to production. Distinguish the release decision from building and testing, because an automated pipeline can still include a deliberate approval gate.
Worked example: A pipeline tests every merge and prepares a deployable package, but a person approves production release. This is compatible with continuous delivery.
Mistake to avoid: Assuming continuous delivery always means automatic production deployment.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
52. Build validation and artifact promotion
A delivery pipeline should connect source changes to a validated deployable artifact. Promoting the same artifact between environments reduces differences caused by rebuilding with changed dependencies or tools. Environment-specific configuration can remain separate. Tests and security checks provide evidence about an artifact, but passing them does not guarantee correct behavior under every production condition.
Worked example: An image tested in staging is promoted unchanged to production, where it receives production configuration.
Mistake to avoid: Rebuilding for production and assuming the result matches the tested artifact.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
53. Declarative deployment with kubectl apply
Declarative deployment records intended resource configuration in manifests and submits it to the Kubernetes API. A basic sequence is to apply the manifest, inspect the resource, and check workload readiness. Manifest acceptance and controller reconciliation remain distinct, so basic deployment knowledge includes verifying the resulting state rather than stopping after submission.
Worked example: After kubectl apply creates an API Deployment, inspection shows unavailable replicas. The deployment still needs diagnosis before it is considered operational.
Mistake to avoid: Treating a successful apply response as proof that requests can be served.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
54. Helm charts and rendered resources
Helm packages Kubernetes resource templates as charts and combines them with values to produce manifests. Values influence what is rendered; Kubernetes ultimately acts on the resulting resources. Inspecting rendered configuration helps identify unexpected names, images, or settings before installation. A chart cannot make unsupported infrastructure or incompatible application configuration work automatically.
Worked example: A value sets three replicas, but a template ignores it. The rendered Deployment reveals the actual replica setting before release.
Mistake to avoid: Assuming a values file proves what Kubernetes will receive.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education
55. GitOps and reconciliation from version control
GitOps uses version-controlled desired state with automated reconciliation against the running environment. Changes become reviewable through repository history, while a controller detects and addresses drift. Secrets require an appropriate protection mechanism rather than careless plaintext storage. Direct changes to managed resources may be overwritten when they conflict with the recorded desired state.
Worked example: An operator manually changes replicas to five, but the repository specifies three. Reconciliation can restore three.
Mistake to avoid: Making a permanent change only in the cluster when GitOps manages that field.
Source reference: Kubernetes and Cloud Native Associate (KCNA) | CNCF
56. Rolling updates and availability
A rolling update gradually replaces old workload instances with new ones. Availability depends on readiness behavior, rollout settings, spare capacity, and application compatibility while versions coexist. The strategy reduces abrupt replacement, but it does not guarantee uninterrupted service when the new version fails or shared dependencies become incompatible.
Worked example: New Pods fail readiness, so they do not become normal Service backends. Rollout progress can stall while investigation proceeds.
Mistake to avoid: Assuming a rolling update automatically makes every application change safe.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
57. Rollback and state compatibility
Rollback restores an earlier application configuration or version when a release causes problems. It does not automatically reverse database migrations, external side effects, or changes to stored data. A rollback decision therefore needs compatibility checks between the previous application and the system’s current state.
Worked example: A release removes a database column required by the old version. Restoring the old image alone cannot restore correct behavior.
Mistake to avoid: Assuming deployment rollback also rolls back every data change.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education
58. Blue-green deployment
Blue-green deployment maintains separate old and new environments, validates the new environment, and switches traffic when it is ready. This supports a clear traffic transition but requires capacity for coexistence and careful handling of shared state. Switching traffic back is useful only if the earlier environment remains compatible with current data and dependencies.
Worked example: The new API environment passes checks before routing moves from blue to green. Both use a backward-compatible database schema.
Mistake to avoid: Planning traffic reversal without checking shared-state compatibility.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education
59. Canary deployment and representative evidence
A canary deployment exposes a new version to a limited portion of traffic before broader release. Evaluate behavior using meaningful signals and comparable workloads. A small traffic share reduces exposure but can miss rare paths or user groups. The rollout decision should depend on observed service behavior rather than elapsed time alone.
Worked example: A canary serves 5% of traffic, but payment requests never reach it. Successful browsing does not validate its payment behavior.
Mistake to avoid: Promoting a canary after observing only unrepresentative requests.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education
60. Debugging the application dependency path
Application debugging follows the request path and tests each boundary: configuration, name resolution, connectivity, authentication, and application behavior. Identify where evidence first diverges from expectations. A running Pod can still serve errors, and a healthy network connection can still reach a dependency that rejects credentials or returns invalid responses.
Worked example: An API resolves its database name and connects successfully, but logs show rejected credentials. Investigate secret consumption and database authorization.
Mistake to avoid: Changing network settings after evidence already demonstrates a successful connection.
Source reference: Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education; Kubernetes and Cloud Native Associate (KCNA) | CNCF
Sources
Credential and scope verified:
- Kubernetes and Cloud Native Associate (KCNA) - Linux Foundation - Education
- Kubernetes and Cloud Native Associate (KCNA) | CNCF