KCNA Kubernetes and Cloud Native Associate Exam Topics and Questions

Nearly half the exam lives here, so this is where the pass or fail decision is made. Kubernetes Fundamentals covers the mechanics of running a cluster: what the control plane components do, how workloads are defined and placed, and how containers are packaged and launched. Gaps in any of these areas compound quickly because later topics assume this knowledge. Get this domain solid before anything else.

– Control plane, API objects and cluster mechanics

The API server, etcd, the controller manager, and the scheduler are not just names to memorise: you need to know what each one owns and what breaks when it misbehaves. The kubectl command surface matters here too. You will be tested on how to read, create, and modify resources using manifests and imperative commands. Know the difference between a Deployment, a ReplicaSet, and a Pod at the object level, not just conceptually. Namespaces, labels, selectors, and annotations all appear in scenario items, and the exam will expect you to choose the right mechanism for a given isolation or grouping requirement. ConfigMaps and Secrets are part of this layer as well: how they are created, how they are mounted, and what scope they carry.

– Scheduling and workload placement

The scheduler decides which node a Pod lands on, and the exam tests your ability to influence that decision. Node selectors, affinity and anti-affinity rules, taints, and tolerations each do something distinct, and items will present a placement requirement that maps to exactly one of them. Knowing the mechanism is not enough: you need to know when the scheduler will refuse to place a Pod at all versus when it will place it on a suboptimal node. Resource requests and limits feed directly into scheduling decisions, so expect scenarios that connect the two. DaemonSets and StatefulSets have their own placement behaviour and appear in items that distinguish them from plain Deployments.

– Containerisation and image fundamentals

Kubernetes runs containers, and the exam expects you to know what that means at the boundary between the container runtime and the cluster. You should understand what a container image is, how layers work at a conceptual level, and what a container runtime interface does. Multi-container Pod patterns, specifically init containers and sidecar containers, appear frequently. Know why you would use each pattern and what the lifecycle differences are. The exam also touches on image pull policies and what happens when an image is unavailable, so understand the three policy options and when each one applies. Liveness, readiness, and startup probes sit in this space too: each one has a different effect on scheduling and traffic routing, and items reward picking the right probe for a described failure mode.

How Kubernetes Fundamentals is tested

At 44% of the exam, this domain generates the largest share of items, and they tend to be scenario-based rather than definition-based. An item will describe a cluster state or a requirement and ask you to identify the resource, command, or configuration that satisfies it. Items reward knowing which object owns which responsibility: confusing a ReplicaSet's job with a Deployment's job, or a readiness probe's effect with a liveness probe's effect, is exactly where marks are lost.

Scheduling items are a common trap. Candidates who know taints and tolerations in isolation often miss items that combine them with affinity rules, because the item describes a placement outcome and expects you to work backwards to the mechanism. Similarly, items on resource requests and limits reward understanding their effect on the scheduler, not just their syntax.

Expect a mix of straightforward recall and multi-step reasoning. The straightforward items test whether you know the right kubectl subcommand or the right API object. The reasoning items present a broken or misconfigured scenario and reward identifying the root cause from the described symptoms.

Once you can define and place workloads, the next pressure point is making them communicate, securing them, and keeping them running reliably. Container Orchestration at 28% is the second-largest domain, and it is where candidates who have memorised object definitions start to lose ground. The items here demand applied reasoning: a network policy that blocks the wrong traffic, a misconfigured volume, a Pod that will not start. Abstract knowledge is not enough.

– Networking inside and outside the cluster

Kubernetes networking rests on a flat Pod network model, and the exam tests whether you understand the implications. Every Pod gets its own IP, Services abstract over Pod IPs, and DNS is how workloads find each other by name. You need to know the four Service types and when each one is appropriate: ClusterIP for internal traffic, NodePort and LoadBalancer for external exposure, and ExternalName for mapping to outside services. NetworkPolicies control which Pods can talk to which, and items in this area reward understanding that the default is permissive: a NetworkPolicy only restricts traffic if one exists. Ingress resources add HTTP routing on top of Services, and you should know where an Ingress controller fits in the picture and why the resource alone does nothing without one.

– Security posture and access control

Security items in this domain concentrate on how Kubernetes limits what workloads and users can do. Role-Based Access Control is the primary mechanism: Roles and ClusterRoles define permissions, RoleBindings and ClusterRoleBindings attach them to subjects. Items reward knowing the scope difference between the two pairs. ServiceAccounts give Pods an identity within the cluster, and the exam tests when you would attach a non-default ServiceAccount and what that changes. Security contexts at the Pod and container level control runtime behaviour: running as a non-root user, dropping Linux capabilities, and setting the filesystem as read-only are all testable. Secrets management sits here too, particularly the difference between mounting a Secret as a volume versus injecting it as an environment variable and what each approach exposes.

– Storage and stateful workload concerns

Persistent storage in Kubernetes separates the claim from the underlying volume, and the exam tests that boundary. A PersistentVolume represents actual storage capacity; a PersistentVolumeClaim is what a Pod requests. The access modes, ReadWriteOnce, ReadOnlyMany, and ReadWriteMany, determine which Pods can use a volume simultaneously, and items will present a multi-Pod scenario where the access mode is the deciding factor. StorageClasses enable dynamic provisioning, and you should know what dynamic provisioning means for a PVC that has no pre-created PV waiting. Volume types such as emptyDir and configMap-backed volumes appear in items that test whether you know their lifecycle: emptyDir is ephemeral and tied to the Pod, not the container.

– Troubleshooting running workloads

Troubleshooting items describe a broken state and expect you to identify the cause. The most common patterns involve Pods stuck in Pending, CrashLoopBackOff, or ImagePullBackOff states. Each state has a distinct set of causes, and items reward mapping the symptom to the right diagnostic step rather than the right fix in isolation. kubectl describe and kubectl logs are the primary tools, and you should know what each one surfaces and what it does not. Node-level issues, such as resource pressure or a node marked as NotReady, produce different symptoms than misconfigured application manifests, and the exam will expect you to tell them apart. Events are a key signal: knowing where they appear and what they report is part of this sub-topic.

How Container Orchestration is tested

At 28%, this domain generates a substantial share of items, and they skew toward scenario and diagnosis rather than definition. A networking item might describe a connection that should work but does not, and reward identifying that a NetworkPolicy is blocking it. A storage item might describe a PVC stuck in Pending and reward recognising that no PV matches the requested access mode.

The security sub-topic is a frequent source of lost marks because candidates conflate the scope of Roles with ClusterRoles, or assume a Pod has no ServiceAccount when it always has the default one. Items reward precision about what each object controls.

Troubleshooting items are the most time-consuming in this domain. They require you to read a described state, reason about what Kubernetes would report, and select the diagnostic step or the cause. The trap is jumping to a fix before identifying the cause: items reward the right diagnosis, not the most aggressive remediation. Work through troubleshooting scenarios under timed conditions before the exam, because the reasoning chain is longer than it looks on paper.

After two domains of hands-on cluster mechanics, this one shifts register. Cloud Native Architecture at 12% covers how you observe a running system, the principles that distinguish cloud native design from traditional approaches, and the ecosystem of projects and communities that surround Kubernetes. It is lighter on commands and heavier on concepts. Candidates who focus only on kubectl tend to underestimate it and drop marks on items that reward understanding why a design decision was made, not just what it does.

How Cloud Native Architecture is tested

At 12%, this domain produces a smaller share of items, but they carry a character that differs from the rest of the exam. Observability items reward knowing what each signal type, metrics, logs, and traces, is suited for and where it falls short. An item might describe a production issue and reward selecting the signal type that would surface it fastest. The trap is treating all three as interchangeable: they are not, and items are written to distinguish them.

Cloud native principles items test whether you understand the reasoning behind microservices, immutable infrastructure, and declarative configuration, not just the labels. Items reward identifying which principle a described practice violates or satisfies.

Ecosystem and community items cover the CNCF project landscape at a recognition level: knowing which graduated projects address which problem, and understanding how the community governs them. Candidates lose marks here by assuming these items are trivial. They require specific knowledge of which projects sit in which category, and guessing from first principles is unreliable. A timed pass through practice items on this domain before the exam is the most efficient way to confirm your coverage.

The final domain brings everything together at the delivery layer: how applications get from source code to running in a cluster, and how you identify what is wrong when they do not behave as expected. At 16%, it is heavier than Cloud Native Architecture and rewards candidates who understand the pipeline, not just the runtime. The concepts here connect directly to practices your team likely uses today, which makes it easy to assume familiarity you do not actually have at the exam's level of precision.

How Cloud Native Application Delivery is tested

At 16%, this domain generates a meaningful share of items and tests two distinct skills. Application delivery items cover CI/CD pipelines, GitOps principles, and the role of tools like Helm in packaging and deploying workloads. Items reward understanding what Helm charts abstract, when a values file overrides a default, and what GitOps means for the relationship between a repository and a cluster state. The trap is treating GitOps as a synonym for CI/CD: items are written to distinguish them, and the distinction matters for selecting the strongest option.

Debugging items describe a delivery failure, a failed rollout, a misconfigured Helm release, or an application that starts but does not serve traffic correctly, and reward tracing the failure to its source. These items sit at the intersection of this domain and the troubleshooting material from Container Orchestration, so strong candidates treat the two domains as connected rather than separate.

The most common source of lost marks is surface-level familiarity. Knowing that Helm exists is not enough: items reward knowing what Helm does at each stage of a release lifecycle.