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 defines a flat network: every Pod gets its own IP address, and every Pod can reach every other Pod on any node without network address translation.

Because the model forbids NAT between Pods, the packet reaches Pod B carrying Pod A's own IP as its source. The tempting wrong answers import other mechanisms: hiding behind the node IP is how containers behave on a single Docker host, a Service is an optional stable front door rather than a requirement, and kube-proxy only acts on traffic addressed to a Service's virtual IP.

1. Note that the connection targets a Pod IP directly, not a Service.
2. Recall the model's rules: unique Pod IPs and Pod-to-Pod reachability across nodes without NAT.
3. Eliminate options that add NAT, a mandatory Service or kube-proxy to direct Pod traffic.
4. Conclude Pod B sees Pod A's real IP.

Exam tip: Pod to Pod means real IP to real IP, across nodes, with no NAT in between.

RollingUpdate is the default Deployment strategy: a changed Pod template produces a new ReplicaSet that replaces the old one gradually.

When strategy is omitted, Kubernetes fills in strategy.type: RollingUpdate with maxSurge and maxUnavailable of 25%. The controller creates a new ReplicaSet and scales it up while scaling the old one down, so the application keeps serving. Recreate must be chosen explicitly, and blue-green and canary are release patterns built on top of Kubernetes rather than behaviours of a plain Deployment.

1. Note that the manifest leaves the strategy field empty, so the default applies.
2. Recall that the default is RollingUpdate and that the only other built-in value is Recreate.
3. Match RollingUpdate to its mechanism: a new ReplicaSet grows while the old one shrinks.
4. Discard the blue-green and canary descriptions, which need extra tooling or manual steps.

Exam tip: No strategy set means RollingUpdate: a new ReplicaSet scales up while the old one scales down.

Observability data falls into three pillars: metrics, logs and traces, each answering a different question.

Metrics are numeric measurements sampled over time and stored as time series. Because they are just numbers with labels, they are cheap to keep for long periods, easy to aggregate and the natural source for trend dashboards and threshold alerts. Logs carry detail about single events, traces show one request's path, and Kubernetes Events record object state changes rather than numeric trends.

1. Notice the need: numeric values (rate, CPU) over a long window.
2. Notice the second need: a threshold alert.
3. Match numeric trends and thresholds to the metrics pillar.

Exam tip: Trends and thresholds across many requests come from metrics.

The kube-apiserver is the front end of the Kubernetes control plane. Every client - kubectl, the kubelet on each node, the scheduler and the controllers - talks to the cluster only through its REST API.

The stem describes the component that receives requests from every other component and checks them (authentication, authorization, validation) before persisting them. That is the kube-apiserver. etcd is tempting because it is where the data ends up, but nothing except the API server talks to etcd. The scheduler and controller-manager are clients of the API server, not the endpoint other clients call.

1. List who sends the requests: kubectl, kubelets and controllers.
2. Ask which single component all of them talk to.
3. Remember that the scheduler and controllers are clients, and etcd sits behind the API server.
4. Conclude: the kube-apiserver.

Exam tip: Every request in Kubernetes goes through the kube-apiserver; nothing else is a front door.