Free KCNA practice test: 30 questions with answers

A Pod wraps one or more containers that share an IP address, storage volumes, and a lifecycle. Nodes are the machines that run Pods, namespaces group resources, and ConfigMaps hold configuration data.

etcd is a consistent key-value store that holds all cluster state. The kubelet runs on nodes, kube-proxy handles service networking, and CoreDNS provides name resolution.

The kube-scheduler watches for unscheduled Pods and selects nodes based on resources, constraints, and affinity rules. The API server stores and serves requests, kubectl is a client, and etcd only stores state.

The kubelet is the node agent that receives Pod specifications and makes sure the containers run as described. The controller manager reconciles cluster objects, etcd stores state, and an Ingress controller routes external HTTP traffic.

A Deployment manages ReplicaSets to keep a desired number of Pods running and performs rolling updates. A bare Pod is not self-healing, a Service provides networking, and a PersistentVolume stores data.

NodePort opens a static port on each node that forwards to the Service. ClusterIP is only reachable inside the cluster, a headless Service returns Pod addresses directly, and ExternalName maps to a DNS name.

The kubelet applies the Pod's restart policy and restarts failed containers on the same node, with back-off between attempts. Scheduling, scaling, and DNS are separate concerns.

The scheduler cannot place a Pod whose resource requests no node can satisfy, so the Pod remains Pending. The kubelet only runs Pods that have been assigned to its node.

Requests are used by the scheduler to find a node with enough capacity, while limits cap usage at runtime. Ports and volume mounts do not influence placement by CPU need.

A PodDisruptionBudget limits voluntary disruptions, such as drains, so a minimum number of Pods stays available. LimitRanges and ResourceQuotas govern resource allocation, and NetworkPolicies control traffic.

The Horizontal Pod Autoscaler changes the replica count of a workload based on metrics. The Vertical Pod Autoscaler adjusts resource requests rather than replica count, and the other options do not scale Pods.

Jobs run Pods to completion and track successful completions, which suits batch and one-time work. They are not long-running services, and they can retry failed Pods within configured limits.

Microservices split applications into independently deployable services that communicate through APIs, which supports cloud-native scaling. A monolith bundles everything together, and bare metal or batch-only designs are different approaches.

Self-healing systems detect failed components and replace or restart them automatically, often through controllers. Manual failover and static provisioning rely on people, and vertical locking is not a cloud-native property.

A container image packages application code, runtime, libraries, and configuration so it runs consistently across environments. The other options are not packaging formats for applications.

Kubernetes is the foundational orchestration project of the CNCF and was contributed by Google. Prometheus, Envoy, and Helm are also CNCF projects but do not perform container orchestration.

Cloud-native applications are built to scale out and are commonly packaged as containers or similar deployable units. Manual configuration, single shared servers, and vendor lock-in are the opposite of cloud-native goals.

A sidecar container runs alongside the main container and shares its network and storage to add capabilities such as proxying or log shipping. The other patterns do not describe co-located helper containers.

Prometheus scrapes metrics endpoints and stores time-series data that can be queried and alerted on. Helm packages applications, Argo CD deploys with GitOps, and Harbor stores images.

Logs capture timestamped records of events, which are useful for diagnosing errors. The other items do not record application events.

Distributed tracing links spans across services for one request, which shows where time is spent. Image scanning, code analysis, and password rotation do not measure request latency across services.

Latency percentiles and resource usage show where slowness originates, such as saturation or slow dependencies. Dashboard colours, maintainer counts, and owner names do not reflect performance.

A counter is a monotonically increasing value that is useful for rates, such as requests per second. A gauge can go up and down, bucket boundaries define histogram ranges, and label selectors are not metric types.

Grafana is widely used to build dashboards over Prometheus and other data sources. Helm packages applications, Istio manages service traffic, and etcd is a data store.

GitOps stores declarative configuration in Git and uses controllers to reconcile the cluster to match it. Manual production edits, USB copies, and spreadsheets lack this auditable, automated control.

A Helm chart bundles templates and default values, which can be overridden for each environment. Namespaces, Ingress rules, and affinity settings are cluster objects rather than packaging units.

CI/CD pipelines automatically build, test, and deploy changes as they are committed. Manual, spreadsheet-based, and hand-copied releases are the opposite of that automation.

Canary releases limit exposure to a new version and expand traffic as health signals stay good. Big-bang releases expose everyone at once, recreate deployments cause downtime, and manual copying is not a strategy.

A digest identifies exact image content, so the deployed image cannot change silently when a tag is updated. Latest tags are mutable, in-place edits break traceability, and removing versions erases history.

Harbor is a CNCF registry that stores images with role-based access and vulnerability scanning. Prometheus collects metrics, Argo Workflows runs pipelines, and Linkerd is a service mesh.