Free KCNA practice questions

In Kubernetes, the atomic unit of deployment is the Pod, not the container. A Pod wraps one or more tightly coupled containers along with shared network and storage.

Every workload you deploy - whether through a Deployment, Job, or DaemonSet - ultimately runs as Pods, and the scheduler places whole Pods onto nodes. Containers are tempting because they are what actually run your code, but Kubernetes only ever handles them wrapped in a Pod. ReplicaSets and nodes sit above and below the Pod respectively: one manages Pods, the other hosts them.

1. You submit a workload (for example a Deployment) to the cluster.
2. Kubernetes creates Pod objects to represent the running instances.
3. The scheduler assigns each Pod to a node, and the kubelet there starts the Pod's containers.

Exam tip: The Pod - not the container - is the smallest deployable, schedulable unit in Kubernetes.

Kubernetes mandates a flat network model where every Pod gets a unique, cluster-wide routable IP address.

The Kubernetes networking model requires that every Pod receives its own IP, and that any Pod can reach any other Pod's IP directly without address translation, regardless of which node they run on.

1. Recall that Kubernetes networking is built on three fundamental requirements: unique Pod IPs, NAT-free Pod-to-Pod communication, and agent-to-Pod communication.
2. Eliminate options describing node-shared IPs, same-node-only communication, or a mandatory Service hop, since none matches the flat model.
3. Confirm the remaining option describes unique IPs plus direct, NAT-free reachability.

Exam tip: Every Pod gets its own IP, and Pods reach each other directly without NAT, this is the foundation the rest of Kubernetes networking builds on.

Kubernetes Deployments support exactly two strategy field values, RollingUpdate and Recreate, and RollingUpdate is used whenever the strategy is left unspecified.

RollingUpdate replaces Pods incrementally: the Deployment controller creates a new ReplicaSet, scales it up in steps bounded by maxSurge and maxUnavailable, and scales the old ReplicaSet down only as new Pods become ready. This keeps the application available throughout the update, which is why it is the sensible default.

1. You update the Pod template in a Deployment, for example a new container image.
2. The Deployment controller creates a new ReplicaSet for the updated template.
3. Because no strategy was specified, Kubernetes applies RollingUpdate and scales the new ReplicaSet up and the old one down gradually.

Exam tip: RollingUpdate is the Deployment default; Recreate must be chosen explicitly and causes downtime.

Observability rests on three complementary pillars: metrics, logs, and traces. Each answers a different question about a running system.

Metrics are numeric, time-stamped measurements collected at regular intervals and stored as time series. They are ideal for spotting trends, setting thresholds, and driving alerts and autoscaling decisions, but they cannot tell you the exact sequence of events or the path a single request took.

1. An application or node exposes numeric values such as request count or memory bytes used.
2. A collection system samples those values on a schedule and timestamps each sample.
3. The samples accumulate into a time series that can be graphed or queried for trends.

Exam tip: Metrics are the numeric, over-time pillar of observability; logs and traces cover events and request paths respectively.

The kube-apiserver is the hub of a Kubernetes cluster: it exposes the REST API, validates and processes requests, and is the only path to the cluster's state.

Everything in Kubernetes flows through the API server - kubectl commands, controller reconciliation, scheduler decisions, and kubelet status reports. etcd is a tempting answer because it holds the state, but it sits behind the API server and is never contacted directly by clients. The scheduler and kubelet are both consumers of the API, not providers of it.

1. A client such as kubectl sends an HTTPS request to the kube-apiserver.
2. The API server authenticates, authorizes, and validates the request.
3. The API server persists any change to etcd, and other components observe it through the API.

Exam tip: kube-apiserver is the single entry point to the cluster - all components and clients go through it.