KCNA sample questions — 25 answered and explained

A ReplicaSet maintains a stable number of identical Pod replicas, creating Pods from its template when too few match its selector and deleting extras when too many do.

The ReplicaSet's only job is the replica count, which gives self-healing and horizontal scale. Each distractor is a neighbouring object's job: a Service gives the stable address, a DaemonSet places one Pod per node, and a Deployment adds versioned rollouts and rollbacks on top of ReplicaSets.

1. Identify the one thing a ReplicaSet tracks: the count of matching Pods.
2. Map each other option to its owning object (Service, DaemonSet, Deployment).
3. Choose the replica-count option.

Exam tip: ReplicaSet = keep N identical Pods; Deployment = versions; DaemonSet = one per node; Service = stable address.

A Deployment manages ReplicaSets and adds declarative rolling updates, revision history and rollbacks. A ReplicaSet alone only keeps a replica count.

Changing a ReplicaSet's Pod template does not replace its running Pods, so a team managing ReplicaSets directly has to orchestrate version changes by hand. A Deployment does it for them: a new ReplicaSet per template change, a gradual scale-up/scale-down, and old ReplicaSets kept so `kubectl rollout undo` can return to a previous revision. Neither object provides a stable IP (that is a Service), and a Deployment still uses ReplicaSets underneath.

1. Recall what a ReplicaSet alone provides: a replica count.
2. Recall what a Deployment adds: versioned rollouts and rollbacks.
3. Reject options that belong to a Service or misstate the ownership chain.

Exam tip: Deployment -> ReplicaSet -> Pods; the Deployment layer exists for rollouts and rollbacks.

A ReplicaSet's controller continuously compares the number of Pods matching its selector with the desired replica count and creates or deletes Pods to close the gap.

Deleting a managed Pod is allowed, and it simply creates a gap between desired state (3) and observed state (2). The ReplicaSet controller closes that gap within moments by creating a brand-new Pod. The two tempting wrong ideas are that the old Pod comes back (Pods are ephemeral; the replacement has a new name and IP) and that someone must re-apply the manifest (reconciliation never stops).

1. Desired state is still replicas: 3 in the stored ReplicaSet.
2. Observed state drops to 2 matching Pods.
3. The controller creates a new Pod from the template - a new object, not the old one.

Exam tip: Deleting a Pod owned by a ReplicaSet just triggers a replacement; delete the owner to remove the Pods for good.

Pod IPs are ephemeral by design. The Service abstraction decouples clients from Pod churn by exposing a stable virtual IP (ClusterIP) and DNS name that always routes to the current healthy Pods.

A Service uses a label selector to track its backend Pods continuously; kube-proxy translates traffic hitting the Service IP into connections to whichever Pods currently match. A ReplicaSet is the tempting distractor because it also deals with Pod churn - but it solves the availability half (keeping Pods running), not the addressing half (reaching them consistently).

1. You create a Service whose selector matches the application's Pod labels.
2. Kubernetes assigns it a stable ClusterIP and a DNS name.
3. As Pods are replaced, the Service's endpoints update automatically and clients keep using the same address.

Exam tip: Services give a stable virtual IP and DNS name over an ever-changing set of Pods.

A Service selects its backend Pods with a label selector. Matching, ready Pods are recorded in EndpointSlices, and kube-proxy routes the Service's traffic to them.

Labels are the glue of the Kubernetes object model: a Service's selector is a label query, so any Pod - including replacements with new names and IPs - that carries the right labels and is ready joins the backend set automatically. Annotations look similar but are deliberately not selectable. Pod names are never listed, and sharing a namespace or a port does not make a Pod a backend.

1. Recall that Pods are replaced with new names and IPs.
2. A Service therefore needs a membership rule that survives churn: a label selector.
3. Readiness further filters which matching Pods get traffic.

Exam tip: Services find Pods by labels (plus readiness) - never by name, annotation or port alone.

Namespaces divide one cluster into virtual slices: object names must be unique only within a namespace, and access control (Roles, RoleBindings) and ResourceQuotas apply per namespace.

Three requirements point the same way. Duplicate names (two Deployments called api) are only possible in different namespaces. Namespaced RBAC lets each team be granted rights to its own namespace only, and a ResourceQuota caps one namespace's consumption. Labels and annotations are metadata on objects, and tainted node pools isolate where Pods run; none of them scopes names, permissions or quotas.

1. Spot the name collision: two Deployments called api.
2. Recall that names are unique per namespace.
3. Check the other needs: RBAC and quotas are also namespace-scoped.

Exam tip: Use namespaces to separate teams in one cluster: they scope names, permissions and quotas.

The kube-scheduler only binds unscheduled Pods to nodes. While it is down, new Pods are accepted but wait in Pending; already-scheduled Pods are unaffected.

Two facts combine here. First, creation and scheduling are separate steps: the API server accepts and stores a new Pod, and the scheduler later binds it to a node - so creation still succeeds. Second, running Pods are kept alive by the kubelet on their node, which needs no scheduler. Put together, the only effect is a backlog of Pending Pods that the scheduler places once it restarts.

1. The API server still accepts and stores new Pod objects.
2. Without the scheduler, no node binding is made: the Pods stay Pending.
3. Running Pods depend on their kubelet, not on the scheduler.

Exam tip: Scheduler down = new Pods Pending; nothing already running is affected.

The kube-apiserver is the only way to read or change cluster state. Running containers, however, are kept alive on each node by the kubelet and container runtime.

Two facts decide this item. The data plane keeps going: kubelets keep existing containers running even when they cannot report status. The control path stops: kubectl, controllers and the scheduler all need the API server, and nothing queues requests, falls back to etcd or lets another component answer. So workloads continue, kubectl requests fail and an in-progress rollout stalls (controllers cannot act) until the API server returns.

1. Separate running workloads (node side) from reading and changing state (API side).
2. Running containers survive because the kubelet and runtime keep them going.
3. Every client, kubectl and controllers included, needs the API server; there is no queue, etcd fallback or substitute endpoint.
4. So rollouts stall and kubectl fails until it returns.

Exam tip: An API server outage freezes changes, not running workloads.

kubectl is a thin client of the Kubernetes API: every command, including logs and exec, becomes an HTTPS request to kube-apiserver.

kube-apiserver is the cluster's single entry point. For kubectl logs it authenticates the caller, checks RBAC (the pods/log subresource) and then fetches the log stream from the kubelet on the target node, proxying it back. The kubelet and the runtime are where the logs come from, which makes them tempting, but neither is reachable from kubectl directly, and etcd holds only API objects.

1. Recall that kubectl only knows the API server address from its kubeconfig context.
2. Note that a node-level command still needs authentication and RBAC, which only the API server performs.
3. The API server then relays to the kubelet on the node, which reads the container's logs from the runtime.

Exam tip: Every kubectl command goes to kube-apiserver; node-level commands like logs and exec are relayed to the kubelet by the API server.

A kubeconfig file is kubectl's connection profile: clusters, users and the contexts that combine them.

kubectl needs two things before it can send a request: where the API server is and which credentials to present. kubeconfig supplies both, plus named contexts that let one workstation switch between clusters. Everything else in the options - desired state, RBAC grants and default limits - lives inside the cluster as API objects.

1. Ask whether the item is client-side connection information or cluster-side state.
2. Connection information (server URL, CA data, credentials, context) belongs in kubeconfig.
3. Workloads, RBAC objects and LimitRanges are API objects stored in the cluster.

Exam tip: kubeconfig tells kubectl where to connect and as whom; everything about what runs or who is allowed lives in the cluster.

kubeconfig separates clusters (where), users (who) and contexts (which cluster as which user, in which default namespace).

A context is a pointer pair plus an optional namespace: cluster X, user Y, namespace Z. The near-twin options describe the other two kubeconfig sections, which a context references by name, and the RoleBinding option mixes up client configuration with in-cluster RBAC.

1. List the three kubeconfig sections: clusters, users, contexts.
2. Clusters hold server addresses and CA data; users hold credentials.
3. A context names one of each and may add a default namespace.

Exam tip: A context = cluster + user (+ default namespace); switch it with kubectl config use-context.

kube-proxy is the per-node agent that implements Services by programming the kernel's packet-handling rules.

kube-proxy turns a Service's virtual IP into real Pod destinations: it watches the API server for Services and EndpointSlices and programs iptables (the default on Linux), IPVS or nftables rules, and the kernel then forwards matching connections to a ready Pod. The distractors are the jobs of its neighbours: the CNI plugin assigns Pod IPs, CoreDNS resolves names and an Ingress controller applies HTTP rules.

1. Recall that Service virtual IPs exist only as rules on each node.
2. Identify kube-proxy as the agent that programs those rules.
3. Assign the other jobs to their owners: CNI plugin, CoreDNS, Ingress controller.

Exam tip: kube-proxy makes Service IPs work; it does not assign Pod IPs, resolve names or route HTTP.

Service discovery in Kubernetes is implemented through an in-cluster DNS server.

CoreDNS runs as a cluster add-on, watching Services and Pods so that names like a Service's cluster.local address resolve to the correct virtual or Pod IP.

1. Recall that Kubernetes needs a name-to-IP resolution mechanism for Services and Pods.
2. Identify CoreDNS as the standard, pluggable DNS server used for this purpose.
3. Rule out etcd, kubelet, and kube-proxy, which serve unrelated functions.

Exam tip: CoreDNS is the cluster's default DNS server, powering Service name resolution.

CoreDNS publishes every Service at <service>.<namespace>.svc.cluster.local; the short name api resolves only within the Service's own namespace.

Because the caller is in a different namespace, the short name api would be searched in web first and miss. The fully qualified name puts the Service name, then its namespace, then svc and the cluster domain: api.shop.svc.cluster.local. The distractors swap one part each: the pod label instead of svc, the order of name and namespace, or the caller's namespace.

1. Note that caller and Service are in different namespaces.
2. Recall the pattern <service>.<namespace>.svc.cluster.local.
3. Fill it in: api, shop, svc, cluster.local.
4. Check each distractor for the one swapped component.

Exam tip: Cross-namespace: service.namespace.svc.cluster.local, Service name first.

An Ingress object holds layer 7 routing rules but does nothing on its own; an Ingress controller (Traefik, HAProxy Ingress, a cloud provider's controller) must run to implement it.

The symptoms show the backend Service is healthy and the Ingress has no address, which is what an Ingress looks like when no controller is watching it. Installing a controller gives the Ingress an entry point and makes its host rules live. Switching the backend to NodePort, adding a NetworkPolicy in a default-allow cluster, or adding an in-cluster DNS record changes nothing about who serves the Ingress.

1. Note the Service works internally, so the backend is fine.
2. Note the Ingress has no address: nothing has picked it up.
3. Recall that Ingress objects need a controller to take effect.
4. Reject fixes that target the Service type, policy or in-cluster DNS.

Exam tip: No Ingress controller, no Ingress: the object is only configuration.

CNI plugins such as Calico, Cilium and Flannel implement the Kubernetes Pod network.

Calico is a CNI plugin. The other three are real cloud native projects that sit next to networking: CoreDNS resolves names, Envoy proxies application traffic and containerd runs containers and calls the CNI plugin. A candidate who knows only that they are 'networking-ish' could pick any of them; recognising the plugin names is what the item tests.

1. Recall what a CNI plugin does: Pod IPs and Pod-to-Pod routing.
2. Recall the common plugins: Calico, Cilium, Flannel.
3. Place the others: DNS server, proxy, container runtime.

Exam tip: Calico, Cilium and Flannel are CNI plugins; CoreDNS, Envoy and containerd are not.

Ingress is a layer 7 API object: its rules map HTTP hostnames and URL paths to Services, which lets one external entry point serve many applications.

Services and kube-proxy work at layer 4 with addresses and ports. Ingress adds layer 7 routing on top: shop.example.com and blog.example.com, or /api and /static, can share one entry point and go to different Services, with optional TLS termination. The Gateway API is the newer, more expressive successor for the same job.

1. Recall what Ingress rules contain: hosts and paths.
2. Map hosts and paths to the HTTP layer, layer 7.
3. Contrast with Services, which work at layer 4.

Exam tip: Ingress routes by HTTP host and path: layer 7. Services balance by address and port: layer 4.

NetworkPolicy is an API object; whether it is enforced depends on the CNI plugin. Calico and Cilium enforce it, while plain Flannel does not.

The API server stores any valid NetworkPolicy, so applying one succeeds even when nothing will enforce it. Enforcement happens in the network plugin, and Flannel only provides connectivity, so the policy has no effect until a policy-capable plugin (Calico, Cilium, or Canal, which pairs Flannel with Calico) is used. kube-proxy and Ingress play no part in NetworkPolicy, and a restart does not change which plugin is running.

1. Note the policy was accepted but has no effect.
2. Recall that NetworkPolicy is enforced by the CNI plugin, not by Kubernetes itself.
3. Recall that Flannel does not implement NetworkPolicy.
4. Reject options that blame kube-proxy, Ingress or Pod restarts.

Exam tip: An accepted NetworkPolicy is not an enforced one: the CNI plugin must support it.

Continuous reconciliation makes GitOps self-healing: any live change that differs from Git is drift, and the controller restores the declared state.

The controller keeps comparing the cluster with what Git declares. A kubectl edit changes live state but not Git, so the Deployment shows as out of sync and self-healing reapplies replicas: 3. Nothing is written back to Git, nothing waits for a CI run, and the API server does not block the edit; it simply does not last.

1. Note that the change was made outside Git.
2. Recall that the controller treats Git as authoritative and compares it with live state continuously.
3. Apply self-healing: the drift is reverted to the Git value.
4. Reject options that update Git from the cluster or rely on a pipeline.

Exam tip: Change the cluster by hand and a self-healing GitOps controller changes it back; change Git instead.

In GitOps, a rollback is a Git change (usually a revert); the controller then reconciles the cluster back to the earlier state.

Because Git is the source of truth, any rollback made only in the cluster is drift: kubectl rollout undo and helm rollback both get overwritten when Flux reconciles, and suspending Flux only delays that. Reverting the commit changes the desired state itself, so the rollback lasts and the Git history records who did it and when.

1. Identify the two requirements: it must last, and it must be auditable.
2. Recall that the controller reapplies whatever Git declares.
3. Eliminate rollbacks made only in the cluster, which become drift.
4. Choose the Git revert, which changes the desired state.

Exam tip: In GitOps you roll back in Git, not in the cluster.

Argo CD is one of the two most widely used GitOps continuous delivery tools in the CNCF ecosystem.

Argo CD runs as a controller in or alongside a cluster, watches Git repositories and reconciles the cluster to match, with a web UI showing sync status and drift. Tekton builds pipelines and belongs to the Continuous Delivery Foundation; Helm and Kustomize produce manifests when invoked but do not continuously sync from Git.

1. Argo CD is installed into, or targeting, a cluster and pointed at a Git repository.
2. It compares the repository's manifests to the live cluster state.
3. It syncs, applying, any differences, either automatically or on manual approval.

Exam tip: Argo CD is a CNCF graduated, Kubernetes-native GitOps continuous delivery tool.

Flux is one of the two graduated CNCF GitOps tools, alongside Argo CD, and is built as a toolkit of composable controllers.

Flux is implemented as a family of Kubernetes controllers, each handling a piece of the GitOps loop, such as fetching sources or rendering Kustomize or Helm output, all following Kubernetes' own controller and reconciliation pattern.

1. Flux's controllers are installed into the cluster.
2. The source controller pulls the Git repository.
3. The kustomize or helm controller renders and applies the manifests, reconciling the cluster.

Exam tip: Flux is a set of composable GitOps controllers; Argo CD is an application controller with a UI.

metrics-server and Prometheus are separate: one serves current resource usage, the other stores queryable history.

kubectl top reads the Kubernetes Metrics API, which metrics-server implements by gathering current CPU and memory from kubelets and holding only the latest values in memory. It has no history, on disk or otherwise, and no PromQL interface. Historical questions such as last month's average need Prometheus (or another time-series store), which keeps scraped samples and answers PromQL; its default local retention is 15 days, so a month needs a longer retention setting or long-term storage.

1. Identify what backs kubectl top: metrics-server via the Metrics API.
2. Recall that metrics-server keeps only a current snapshot.
3. Recall that PromQL is Prometheus's query language, not metrics-server's.
4. Conclude that historical PromQL queries need Prometheus.

Exam tip: Current usage comes from metrics-server; history and PromQL come from Prometheus.

The cloud native logging convention is to write logs to stdout and stderr.

When a container writes to stdout and stderr, the container runtime captures those streams into files on the node. kubectl logs reads them, and a node-level agent can forward them to any store. The application never needs to know the destination. Writing to a file in the writable layer or on a volume bypasses that capture, and calling a log store's API from code ties the application to that store.

1. Notice both needs: kubectl logs must work, and the destination is the platform's choice.
2. Recall that kubectl logs reads what the runtime captured from standard streams.
3. Rule out files and direct API calls, which bypass capture or couple the code.
4. Choose stdout and stderr.

Exam tip: Log to stdout and stderr; let the platform decide where logs go.

Cluster-wide log collection uses a node-level agent deployed as a DaemonSet.

The container runtime writes each container's stdout and stderr to files on its node. A DaemonSet runs one logging agent, such as Fluent Bit or Fluentd, on every node; it tails those files, enriches records with Pod and namespace metadata and ships them to a central store. Nothing in the application Pods changes. A sidecar per Pod also works but requires editing every Pod spec, which the stem forbids.

1. Notice the scope: every container on every node.
2. Notice the constraint: no change to application Pod specs.
3. Recall that a DaemonSet runs one copy per node and container logs already sit on the node.
4. Rule out the sidecar (edits Pod specs) and API-server polling.
5. Choose the DaemonSet agent.

Exam tip: One logging agent per node, as a DaemonSet, collects every container's logs without touching the apps.