12 real KCNA sample questions, each with an explanation of why every option is right or wrong. No account, no card. This is the reasoning the KCNA tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real KCNA is Not published by CNCF questions in 90 minutes, pass mark 75%. For a domain-by-domain breakdown and a study plan, read the KCNA study guide. The full bank has 305 questions.
lock_openFree sampleKubernetes Fundamentalseasy
A cluster administrator needs a log-collection agent to run on every node, including any new node that later joins the cluster, with exactly one copy of the agent per node. Which Kubernetes workload object is purpose-built to guarantee one Pod on each node automatically?
- AA Deployment, because it keeps a fixed number of identical Pod replicas running across the cluster
- BA StatefulSet, because it gives each Pod a stable network identity tied to a specific node
- CA Job, because it runs one Pod per node until each completes its task
- DA DaemonSet, because it schedules one copy of the Pod onto every eligible node and onto new nodes as they joincheck_circle Correct
A DaemonSet runs exactly one copy of a Pod on every eligible node, including nodes that join later. The DaemonSet controller watches the set of nodes and reconciles one matching Pod per eligible node, adding Pods when nodes join and removing them when nodes leave, which is why it fits cluster-wide agents like log or metrics collectors.
Why A is wrong: A Deployment maintains a chosen replica count and lets the scheduler place those Pods anywhere, so it is tempting for any 'run this everywhere' need, but it cannot guarantee one Pod per node and will not react to new nodes joining.
Why B is wrong: A StatefulSet provides ordered, stably named Pods for stateful apps, which sounds node-related, but its replica count is fixed and its Pods are not placed one-per-node, so it does not track node membership.
Why C is wrong: A Job runs Pods to completion for batch work, which can feel like a per-node task, but it targets a completion count rather than node coverage and does not maintain a long-running agent on every node.
Why D is correct: A DaemonSet ensures each eligible node runs exactly one copy of the Pod, and it automatically adds a Pod to any node that later joins, which is precisely the node-agent pattern described.
lock_openFree sampleKubernetes Fundamentalseasy
A team is deploying a clustered database where each replica needs a stable, predictable network identity and its own persistent storage that survives rescheduling, and Pods must be created and terminated in a defined order. Which Kubernetes workload object is designed for this?
- AA StatefulSet, because it gives each Pod a stable ordinal name, stable storage, and ordered lifecycle operationscheck_circle Correct
- BA Deployment, because it manages Pod replicas and supports rolling updates
- CA ReplicaSet, because it maintains a stable set of running Pod replicas
- DA DaemonSet, because it ensures one database Pod runs on each node with local storage
A StatefulSet provides stable identities, per-Pod persistent storage, and ordered lifecycle for stateful workloads. The StatefulSet controller gives each Pod a stable ordinal name and a persistent volume claim template so storage follows the identity across reschedules, and it sequences creation and deletion, which is what a clustered stateful application relies on.
Why A is correct: A StatefulSet assigns each Pod a stable ordinal identity and hostname, binds each to its own persistent volume that follows it across reschedules, and creates or deletes Pods in order, exactly matching a clustered database.
Why B is wrong: A Deployment is the standard controller for scalable workloads, so it is a natural first guess, but its Pods are interchangeable with random names and no per-Pod stable identity or ordered lifecycle, which a clustered database needs.
Why C is wrong: A ReplicaSet does keep a fixed number of Pods running, which sounds like the stability required, but it treats all replicas as identical and gives no stable names, ordering, or per-Pod persistent volumes.
Why D is wrong: A DaemonSet places one Pod per node, which can look like a way to spread database replicas, but node coverage is not the same as a fixed set of individually identified members with ordered startup.
lock_openFree sampleKubernetes Fundamentalseasy
A developer wants to run a stateless web application, scale it to a chosen number of interchangeable replicas, and roll out new image versions gradually with the option to roll back. Which Kubernetes object is the standard choice for managing this?
- AA single Pod, because it directly runs the application container and can be scaled by editing its spec
- BA Deployment, because it declaratively manages replica count and performs controlled rolling updates and rollbackscheck_circle Correct
- CA ReplicaSet, because it maintains the desired number of replicas and handles version rollouts
- DA Job, because it runs the application replicas and restarts them to apply new versions
A Deployment manages stateless replicas with declarative scaling, rolling updates, and rollbacks. A Deployment creates and updates ReplicaSets on your behalf, shifting Pods from the old ReplicaSet to a new one during an update while keeping availability, and it records revision history so a previous version can be restored.
Why A is wrong: A Pod is the smallest deployable unit and does run the container, so it seems sufficient, but a bare Pod has no replica management, no self-healing, and no rolling-update mechanism, so it cannot scale or upgrade safely.
Why B is correct: A Deployment is the standard controller for stateless apps: it manages an underlying ReplicaSet, scales replicas declaratively, and orchestrates rolling updates and rollbacks, which matches every part of the requirement.
Why C is wrong: A ReplicaSet does keep the desired replica count and self-heals, which covers scaling, but it has no built-in rolling-update or rollback logic; that orchestration is provided by the Deployment that owns it.
Why D is wrong: A Job manages Pods that run to completion for batch tasks, which can be confused with running replicas, but it is not intended for long-running services and offers no rolling-update behaviour.
lock_openFree sampleContainer Orchestrationmedium
A team runs a Redis cache Pod that only other Pods inside the same cluster need to reach. They want a stable virtual IP and DNS name for the cache, but the cache must never be reachable from outside the cluster. Which Service type meets this requirement with the least exposure?
- AA ClusterIP Service, which allocates an internal virtual IP and cluster DNS name reachable only from within the cluster.check_circle Correct
- BA NodePort Service, which reserves a port on every node so internal Pods can connect through any node address reliably.
- CA LoadBalancer Service, which provisions an external cloud load balancer to front the cache with a stable public address.
- DAn ExternalName Service, which maps the cache name to an external DNS record through a returned CNAME entry.
Select ClusterIP when a workload only needs a stable internal address reachable from within the cluster. ClusterIP is the default Service type and allocates a virtual IP from the service CIDR plus a cluster DNS name that kube-proxy routes only to backing Pods, so traffic never leaves the cluster boundary.
Why A is correct: ClusterIP provides a stable internal virtual IP and DNS record while remaining unreachable from outside the cluster, which exactly matches an internal-only cache.
Why B is wrong: NodePort is tempting because it also gives a stable target, but it opens a port on every node's external IP, exposing the cache beyond the cluster, which the requirement forbids.
Why C is wrong: LoadBalancer looks safe because it also yields a stable address, but it provisions an externally reachable cloud load balancer, violating the internal-only constraint.
Why D is wrong: ExternalName seems relevant because it involves DNS, but it aliases to an external hostname rather than fronting an in-cluster Pod, so it does not expose the local cache at all.
lock_openFree sampleContainer Orchestrationmedium
A platform team hosts three HTTP microservices and wants a single external entry point that routes requests to each service by URL path, such as forwarding /orders and /users to different backends, while terminating TLS in one place. Which Kubernetes object is designed to provide this layer-7 path-based routing?
- AOne LoadBalancer Service per microservice, each provisioning its own cloud load balancer for the individual backend.
- BAn Ingress with an associated Ingress controller, which routes external HTTP traffic to Services based on host and URL path rules.check_circle Correct
- CA NodePort Service fronting all three microservices through one shared node port number opened on every cluster node.
- DA headless ClusterIP Service that returns the Pod addresses of all three microservices to callers.
Choose an Ingress for host and path-based layer-7 routing of external HTTP traffic to multiple Services. Ingress is an API object that expresses layer-7 routing rules; an Ingress controller reads those rules and configures a reverse proxy to route by host and path and terminate TLS, which layer-4 Services cannot do.
Why A is wrong: LoadBalancer Services can expose each app, but they operate at layer 4 and cannot route by URL path, and using one per service defeats the single-entry-point goal.
Why B is correct: Ingress defines host and path routing rules for HTTP traffic and, with a controller, gives one entry point that fans out by path and can terminate TLS centrally.
Why C is wrong: NodePort is tempting as an external entry, but it forwards a raw port to a single Service and has no awareness of HTTP paths, so it cannot split /orders from /users.
Why D is wrong: A headless Service returns Pod IPs for direct discovery, but it stays internal and performs no path-based HTTP routing or TLS termination.
lock_openFree sampleContainer Orchestrationmedium
An application must be reachable from the public internet on a managed cloud provider, and the team wants Kubernetes to automatically provision an external load balancer with a public IP that forwards traffic to the backing Pods. Which Service type triggers this automatic provisioning?
- AA ClusterIP Service, which the cloud provider then upgrades to a public endpoint once external traffic arrives.
- BA NodePort Service, which the cloud controller manager pairs with a public IP the moment the port opens.
- CA LoadBalancer Service, which instructs the cloud controller manager to provision an external load balancer with a public IP.check_circle Correct
- DAn ExternalName Service, which requests a public IP by resolving to an external DNS name.
Use a LoadBalancer Service to have the cloud provider provision an external load balancer and public IP. A LoadBalancer Service builds on NodePort and ClusterIP and asks the cloud controller manager to create a provider-managed load balancer with an external address that directs inbound traffic to the Service's endpoints.
Why A is wrong: ClusterIP is internal only and is never auto-upgraded by the cloud provider, so it cannot obtain a public IP on its own.
Why B is wrong: NodePort does expose a port on each node, but it does not itself provision a cloud load balancer or public IP; that behaviour belongs to the LoadBalancer type built on top of it.
Why C is correct: LoadBalancer signals the cloud controller manager to create a provider load balancer and public IP that forwards to the Service, which is exactly the requested behaviour.
Why D is wrong: ExternalName only returns a CNAME to an external hostname and provisions no infrastructure, so it cannot create a cloud load balancer or public IP.
lock_openFree sampleCloud Native Application Deliverymedium
A platform team wants to adopt GitOps for cluster configuration. Which statement best captures the defining principle that distinguishes GitOps from other delivery approaches?
- AA Git repository holds the declared desired state, and an in-cluster agent continuously reconciles the running state to match what is committed.check_circle Correct
- BA CI server holds the authoritative configuration and issues kubectl apply commands to the cluster whenever a build succeeds.
- CDevelopers connect to the cluster with kubectl and make live changes directly, then export the result back into a Git repository as a backup.
- DContainer images are signed and stored in a registry, and the cluster pulls the newest image tag on a fixed schedule regardless of any repository.
Understand that GitOps means a Git-declared desired state continuously reconciled into the cluster by an agent. GitOps rests on two pillars: a declarative desired state versioned in Git, and a reconciliation loop running in or against the cluster that continuously drives actual state to match the committed state, making Git the single source of truth.
Why A is correct: This is correct because GitOps uses a versioned declarative source of truth in Git and a reconciliation agent that continuously converges actual cluster state towards the committed desired state.
Why B is wrong: This is tempting because CI pipelines do deploy to clusters, but it describes a push model where an external system imperatively applies changes rather than a Git repository being the declarative source of truth that the cluster reconciles against.
Why C is wrong: This inverts the flow and is tempting because it involves Git, but here Git is a passive backup rather than the authoritative source, so live manual edits are the real source of truth, which GitOps forbids.
Why D is wrong: This is tempting because it uses the word pull, but it describes image polling, not reconciliation of declared manifests from Git, and it ignores the declarative desired-state repository entirely.
lock_openFree sampleCloud Native Application Deliverymedium
In a traditional push-based deployment pipeline, an external CI runner applies manifests to the cluster after each build. A team switches to a pull-based GitOps model. What fundamentally changes about where the deployment action originates?
- AThe deployment is triggered by developers manually running apply commands from their laptops instead of by the CI system.
- BAn agent running inside the cluster pulls the desired state from Git and applies it, rather than an external system pushing changes into the cluster.check_circle Correct
- CThe cluster no longer stores any desired state and instead trusts whatever the most recent pipeline run pushed to it.
- DAn external pipeline still needs cluster admin credentials to push changes, but it now pushes to Git first rather than to the cluster.
Contrast push pipelines, where an external system applies changes, with pull GitOps, where an in-cluster agent fetches and applies them. The essential difference is directionality and credential ownership: a push pipeline reaches into the cluster from outside with cluster access, whereas a pull model places an agent inside the cluster that pulls declared state from Git and applies it, so no external cluster credentials are required.
Why A is wrong: This is tempting because both involve people committing code, but pull-based GitOps removes manual apply steps entirely; the change does not move the trigger to laptops, it moves it to an in-cluster agent.
Why B is correct: This is correct because the defining shift is direction: in pull-based GitOps an in-cluster agent fetches and applies committed state, so the cluster pulls changes instead of an external runner pushing them.
Why C is wrong: This is tempting because push pipelines do rely on the last run, but pull-based GitOps keeps a durable declared state in Git and reconciles to it, so the cluster is not left trusting a transient push.
Why D is wrong: This is tempting because Git does sit upstream, but it wrongly keeps external cluster credentials in the pipeline, whereas a pull model lets the in-cluster agent hold access so external systems need no cluster credentials.
lock_openFree sampleCloud Native Application Deliverymedium
A team lists the benefits it expects from moving cluster delivery to GitOps. Which benefit follows most directly from keeping the entire desired state as declarative configuration committed to Git?
- AContainer images build faster because Git compresses the application source before the CI system compiles it.
- BPods automatically receive more CPU and memory because Git enforces resource limits at commit time.
- CEvery change to cluster state is versioned and auditable, and a previous known-good state can be restored by reverting the commit.check_circle Correct
- DSecrets stored in the repository become encrypted at rest inside the cluster with no additional tooling required.
Explain that storing desired state declaratively in Git yields versioned, auditable changes and commit-based rollback. Because the desired state lives in Git, it gains full version history, review, and audit for free, and recovery is achieved by reverting to a known-good commit which the reconciliation controller then applies back onto the cluster.
Why A is wrong: This is tempting because Git and CI sit near each other in the toolchain, but build speed is unrelated to storing desired state declaratively; GitOps governs deployment, not image compilation.
Why B is wrong: This is tempting because resource limits are declared in manifests, but Git does not allocate or enforce runtime resources; the scheduler and kubelet enforce limits, and committing does not grant capacity.
Why C is correct: This is correct because a declarative state in Git inherits version control history, so changes are reviewable and auditable and a rollback is simply reverting to an earlier commit that the controller then reconciles.
Why D is wrong: This is tempting because secret handling is a real GitOps concern, but committing plain manifests does not encrypt anything; protecting secrets needs extra tooling and is not an automatic consequence of using Git.
lock_openFree sampleCloud Native Architectureeasy
A platform team follows the principle of immutable infrastructure for their cloud native workloads. When they need to change the configuration of a running service, which approach is consistent with this principle?
- AOpen a shell into each running container and edit the configuration files directly so no redeploy is needed
- BAttach a configuration volume and hot-patch the binary on each host while the service keeps serving
- CBuild a new container image with the change and roll out fresh replacement instances, discarding the old onescheck_circle Correct
- DRun a configuration management agent that periodically reconciles and rewrites files on the live servers
Immutable infrastructure replaces instances with new artifacts rather than modifying running ones in place. The defining behaviour of immutable infrastructure is that no change is applied to a live instance; instead a new versioned artifact is built and deployed as a replacement, which eliminates configuration drift and makes rollbacks predictable.
Why A is wrong: Editing files inside a live container is tempting because it seems faster, but it mutates the running instance in place, which is the mutable pattern immutable infrastructure exists to avoid.
Why B is wrong: Hot-patching a running binary sounds efficient and zero-downtime, but it modifies existing instances rather than replacing them, so it violates immutability and causes environment drift.
Why C is correct: Immutable infrastructure means a running instance is never modified in place; a change produces a new image or artifact that replaces the existing instances entirely, which is exactly what this describes.
Why D is wrong: An agent that continuously mutates live servers is a classic mutable-infrastructure workflow; it changes instances in place instead of replacing them, so it is the opposite of the immutable approach.
lock_openFree sampleCloud Native Architectureeasy
A candidate is comparing a declarative API with an imperative API in the context of Kubernetes. Which statement best captures what makes an API declarative?
- AThe client issues an ordered list of commands that the system executes step by step to reach an end state
- BThe client must poll the system and manually re-issue each change whenever actual state drifts from the target
- CThe client sends one-off action requests that change the system but store no persistent record of intent
- DThe client submits the desired end state and the system continuously works to make actual state match itcheck_circle Correct
A declarative API records desired state and lets controllers reconcile actual state toward it automatically. Declarative APIs work by storing the user's desired state as an object and running control loops that repeatedly compare actual state with desired state and take corrective action, rather than executing a fixed command sequence once.
Why A is wrong: Issuing an ordered sequence of commands is the imperative model; it describes how to reach a state rather than what the state should be, so it is not declarative.
Why B is wrong: Manual polling and re-issuing changes is tempting because drift is real, but a declarative system reconciles automatically; requiring the client to correct drift describes an imperative loop, not a declarative API.
Why C is wrong: One-off actions with no stored intent are imperative commands; a declarative API persists the desired state so the system can keep reconciling to it, so this is incorrect.
Why D is correct: A declarative API takes a description of the desired state and relies on controllers to reconcile actual state toward it, which is precisely how Kubernetes objects are managed.
lock_openFree sampleCloud Native Architectureeasy
An architect explains the microservices style to a team used to a single monolithic application. Which characteristic most distinguishes a microservices architecture from a monolith?
- AThe application is split into small independently deployable services that communicate over the networkcheck_circle Correct
- BThe whole system is built, versioned, and deployed as one unit so every change ships together
- CAll components share a single in-process function call boundary and one runtime process
- DThe codebase is organised into modules that are compiled separately but still released as one artifact
Microservices split an application into small, independently deployable, network-communicating services. The defining trait of microservices is that each service can be developed, deployed, and scaled independently and communicates with others over the network, in contrast to a monolith that ships as a single unit.
Why A is correct: Independent deployability of small services that talk to each other over the network is the core distinguishing property of a microservices architecture.
Why B is wrong: Building and deploying everything as a single unit describes a monolith; microservices exist specifically to break that coupling, so this is the pattern being contrasted, not microservices.
Why C is wrong: A shared in-process boundary and single runtime is a monolithic trait; microservices run as separate processes communicating over the network, so this is incorrect.
Why D is wrong: Separately compiled modules released together is a modular monolith; it improves code organisation but keeps a single deployable artifact, so it lacks the independent deployability that defines microservices.
Examworthy is not affiliated with or endorsed by Cloud Native Computing Foundation. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. KCNA and related marks belong to their respective owners.
