Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 751–825

Option B is correct because immutable infrastructure treats container images as immutable artifacts that are versioned and promoted through environments (e.g., dev, staging, prod) without modification. This ensures consistency and reproducibility, as the same image is deployed across all stages without patching or altering it in place.

The 'kubectl logs' command is used to fetch logs from containers in a pod.

The Pod is the smallest and simplest unit in the Kubernetes object model that you can create and manage. It represents a single instance of a running process in the cluster and encapsulates one or more containers, shared storage, and a unique cluster IP. While containers are the runtime units, Kubernetes does not manage containers directly; it manages Pods, which are the atomic scheduling unit.

containerd is a core container runtime that implements the CRI and is commonly used in Kubernetes.

A Kubernetes Job is designed for batch processing workloads that run to completion and then terminate. Unlike controllers that maintain a desired number of running Pods (like Deployments or StatefulSets), a Job creates one or more Pods and ensures they successfully exit. Once the specified number of successful completions is reached, the Job stops, making it the ideal choice for a one-time data processing task.

Option C is correct because containers virtualize at the operating system level, sharing the host OS kernel while running in isolated user-space instances. This eliminates the need for a full guest OS per workload, making containers significantly more lightweight in terms of memory, disk usage, and startup time compared to virtual machines, which each require a separate kernel and hypervisor.

Containers are lightweight because they share the host operating system kernel, avoiding the overhead of a separate guest OS per instance. Unlike VMs, which each include a full OS and require hypervisor mediation, containers run as isolated user-space processes on the same kernel, enabling faster startup times and higher density. This kernel sharing is the fundamental architectural advantage that makes containers more resource-efficient than virtual machines.

Namespaces provide logical isolation and can be used to separate environments, but not all objects are namespaced (e.g., nodes).

The 'kubectl apply' command is used to apply a configuration to a resource by file or stdin. It also supports declarative management, tracking changes for updates.

kubectl logs with the -c flag allows you to specify a container name when a pod has multiple containers.

GitOps is a practice where the entire system state is described declaratively in Git, and automated tools synchronize the cluster to match. ArgoCD and Flux are popular GitOps tools.

Logs and Metrics are two of the three pillars of observability (alongside Traces). Logs provide immutable, timestamped records of discrete events, while Metrics are numeric aggregations of data over time (e.g., Prometheus counters, histograms). Together they form the foundation for understanding system behavior in cloud-native environments.

Argo Rollouts is a Kubernetes controller and set of CRDs that provides advanced deployment capabilities such as blue-green and canary deployments with automated promotion and rollback.

Option D is correct because the rollout status shows that no new replicas have been created, which is a classic symptom of a container image pull failure. When the image tag specified in the pod template does not exist in the registry, the kubelet cannot pull the image, so the ReplicaSet controller cannot start new pods. This prevents the rollout from progressing past 0 out of 3 new replicas.

Option B is correct because the YAML defines resource limits and requests using standard Kubernetes units: '128Mi' for memory (mebibytes) and '500m' for CPU (millicores). These are valid and will be applied to the container, creating the Pod with the specified limits.

The -c flag specifies the container name when a pod has multiple containers.

StatefulSet is the correct choice because it is specifically designed for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage per pod instance (via PersistentVolumeClaims that are not shared across replicas). Unlike Deployments, StatefulSet maintains a sticky identity for each pod, ensuring that on rescheduling, the pod retains its name, network identity, and bound storage.

A service mesh provides observability, traffic management, and security for microservices communication, offloading these concerns from application code.

A Deployment is the correct controller because it manages a ReplicaSet, which ensures a specified number of pod replicas are running at all times. If the main process in a pod crashes, the ReplicaSet detects the pod failure (via the kubelet's liveness probe or the pod's phase becoming 'Failed') and automatically creates a new pod to replace it, thereby restarting the application. This self-healing behavior is a core feature of Deployments, making them ideal for stateless applications that need continuous availability.

Option D is correct because `kubectl exec` uses the `-c` flag (or `--container`) to specify a target container within a multi-container pod. The syntax `kubectl exec -it mypod -c sidecar -- /bin/sh` opens an interactive shell in the 'sidecar' container of the pod named 'mypod'. Without the `-c` flag, the command defaults to the first container in the pod's spec, which would be 'app'.

A Service provides a stable IP and DNS name, and load balances traffic across pods selected by labels.

Kubernetes is a container orchestration platform that automates deployment, scaling, and management of containerized applications.

The source controller fetches artifacts (e.g., from Git, Helm repos) and the kustomize controller applies manifests, but the reconciliation of desired state from Git is primarily managed by the source controller and kustomize controller working together. However, the source controller is the one that monitors sources.

Terraform (B) is an Infrastructure as Code (IaC) tool that uses declarative configuration files (HashiCorp Configuration Language, HCL) to define and provision cloud and on-premises resources. It manages the full lifecycle of infrastructure through a state file and provider plugins, enabling version-controlled, repeatable deployments.

The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to communicate with different container runtimes (e.g., containerd, CRI-O) without needing to know their internal implementation details. It defines a gRPC-based protocol for managing container lifecycles, image operations, and pod sandboxes, allowing Kubernetes to remain runtime-agnostic.

A failed Helm upgrade usually means the Kubernetes API rejected the manifests (e.g., invalid YAML, resource conflict).

StatefulSets provide stable, unique network identifiers (e.g., pod hostnames) that persist across reschedules because each pod gets a fixed ordinal index (e.g., pod-0, pod-1) and a corresponding DNS name (e.g., pod-0.statefulset.namespace.svc.cluster.local). This is essential for applications like databases (e.g., Cassandra, ZooKeeper) that rely on consistent peer discovery and identity, which Deployments cannot guarantee since they assign random pod names and IPs.

OpenTelemetry (OTel) is the industry standard for observability data collection and export, providing vendor-agnostic instrumentation.

Namespaces provide a mechanism for isolating groups of resources within a single cluster, but they do not provide network isolation by default (that requires NetworkPolicies).

The Pod is the smallest deployable unit in Kubernetes because it represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. While containers are the runtime units, Kubernetes schedules and manages Pods, not individual containers, making the Pod the atomic building block for deployment.

The correct command uses 'kubectl create deployment' with the --image and --replicas flags.

Option C is correct because setting `maxSurge=1` and `maxUnavailable=0` in a RollingUpdate strategy ensures that one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees zero downtime by maintaining full capacity during the rollout, as new pods become ready before old ones are removed.

Kubernetes is a container orchestration platform used to automate the deployment, scaling, and management of containerized applications.

Distributed tracing is designed to track the flow of a single request across multiple microservices, recording timing and causality. Option B is correct because tracing systems like Jaeger or Zipkin automatically build a dependency graph by analyzing the parent-child relationships between spans, which reveals how services interact. This is a core use case for understanding service topology and identifying bottlenecks in a distributed system.

Containers share the host OS kernel and run as isolated processes, requiring no separate guest OS per instance. This makes them significantly more lightweight and faster to start than VMs, which must boot a full guest OS. For application deployment, this translates to higher density, lower resource overhead, and near-instant startup times.

The -c flag specifies the container name.

kubectl apply and kubectl create are used to create/update resources by declarative or imperative approach. Direct API calls also work. kubectl update does not exist.

The Retry pattern is a fundamental resiliency mechanism in cloud-native applications. When a transient failure occurs (e.g., a network timeout or a temporary database unavailability), the application automatically reattempts the failed operation. This pattern is often implemented with exponential backoff and jitter to avoid overwhelming the downstream service, as seen in libraries like Netflix Hystrix or Kubernetes client-go retry logic.

'kubectl apply' uses a declarative approach to create or update resources defined in a file.

Kubernetes provides self-healing (restart failed containers), scaling (automatic horizontal scaling), and declarative management (desired state reconciliation). Option A is a benefit of containers themselves, not orchestration; Option E is a feature of container runtimes.

The PVC requests ReadWriteOnce, so PV2 (ReadOnlyMany) does not match. PV1 matches AccessModes and storageClassName is empty (implies no storage class), but PV1's capacity (3Gi) is less than the request (5Gi). No PV matches, so the PVC remains unbound.

The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected, by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers based on PodSpecs received from the API server.

kubectl logs <pod-name> fetches the standard output/error logs from the pod's containers.

Knative scales to zero when idle, meaning no pods are running, thus no cost incurred.

Option D is correct because the Deployment's `spec.strategy.type` must be set to `RollingUpdate` to enable a controlled, incremental update of pods. The `rollingUpdate` field then allows you to specify `maxSurge: 1` (one extra pod above the desired count during update) and `maxUnavailable: 0` (ensure all existing pods remain available during the update), which is the exact configuration for a zero-downtime rolling update with a single surge pod.

'kubectl describe pod <pod-name>' provides detailed information about a pod, including events, state, and configuration.

SLA stands for Service Level Agreement, a contract specifying expected service level.

If a pod has no memory limit, it can use as much memory as needed. When the node is under memory pressure, the kernel's OOM killer may target the pod, leading to OOMKilled.

Option B is correct because Kubernetes set-based selectors support operators like 'In', 'NotIn', 'Exists', and 'DoesNotExist', allowing more flexible matching than equality-based selectors. This is defined in the Kubernetes API specification for label selectors, enabling complex filtering of resources.

A Job is the correct Kubernetes resource because it is designed to run a finite task to completion, such as a batch job that processes data every hour and then exits. Unlike a Deployment, which maintains a desired number of continuously running Pods, a Job ensures that a specified number of Pods successfully terminate, making it ideal for one-off or scheduled batch workloads.

Service mesh provides traffic management (routing, canary releases), observability (metrics, tracing), and security (mTLS, authorization). Auto-scaling is handled by Horizontal Pod Autoscaler or custom metrics, not by the service mesh. Service discovery is often built into Kubernetes itself, though service mesh can enhance it, but it's not a core feature.

NetworkPolicy is the correct resource because it acts as a firewall for Kubernetes Pods, controlling ingress and egress traffic at the IP address and port level using layer 3/4 rules. By applying a NetworkPolicy that denies all traffic between the Pods of the two Deployments (e.g., using podSelector and ingress/egress rules with an empty `from` or `to` block), the administrator can enforce network isolation. This is the native Kubernetes mechanism for restricting Pod-to-Pod communication within a cluster.

A Service of type ClusterIP (default) provides a stable endpoint and load balancing across pods matching its selector.

A Service of type NodePort exposes a set of pods on a static port on each node's IP address, making the service accessible from outside the cluster. This is a valid Kubernetes resource for exposing pods as a network service, as it creates a mapping from a node port to the ClusterIP and then to the target pods.

A Pod is the smallest and simplest unit that can be created and managed in Kubernetes.

The Kubernetes API server provides a consistent interface regardless of the underlying infrastructure. Namespaces organize resources, Services provide networking abstractions, and ConfigMaps store configuration.

Option A is correct because the Service's selector 'app: myapp' matches both pods 'app-v1' and 'app-v2', which both carry the label 'app: myapp'. The Service controller automatically creates endpoints for all pods matching the selector, regardless of their readiness state, unless a headless service or custom endpoint logic is involved. Initially, both pods are considered ready by default (unless a readiness probe fails), so the Service will have two endpoints.

Canary deployment releases the new version to a small percentage of users initially, then gradually increases traffic.

The error 'unable to bind to port 8080' indicates that the container process cannot open port 8080 for listening. The most likely cause is that another process on the host node is already using port 8080, preventing the container from binding to it. This is a classic port conflict scenario, where the host's network namespace has a port already allocated, and the container (even with its own network namespace) may be using host networking or the port is mapped from the host.

Option C is correct because structured logging (e.g., JSON) enables automated parsing, filtering, and querying by log aggregation tools like Fluentd, Logstash, or cloud-native observability backends (e.g., Elasticsearch, Loki). This format ensures each log entry has consistent key-value pairs, making it machine-readable and facilitating correlation across distributed services without manual text parsing.

A Pod is the smallest deployable unit in Kubernetes because it encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. While containers are the runtime processes, Kubernetes schedules and manages Pods as atomic units, meaning you cannot deploy a container directly without a Pod wrapper.

The bottleneck is caused by the database being CPU-bound, meaning it cannot process requests fast enough. Implementing read replicas offloads read queries from the primary database, reducing its CPU load and allowing it to handle write operations more efficiently. The application can be configured to route read operations to the replicas, which directly addresses the latency caused by waiting on database responses.

These concepts control how pods are scheduled and allocated resources.

Node affinity is a set of rules used by the scheduler to determine which nodes a pod can be placed on. Labels on nodes can be used to indicate hardware characteristics like SSD storage.

The taint `node.kubernetes.io/unreachable` is automatically added by the node controller when a node becomes unreachable (e.g., network failure, kubelet stops heartbeating). The error shows all 4 nodes have this taint and the pod has no matching toleration, meaning the scheduler cannot place the pod. This directly indicates all nodes are unreachable or have been cordoned (which also adds the `node.kubernetes.io/unschedulable` taint, but here the specific taint is `unreachable`).

ConfigMap is the correct Kubernetes object for storing non-sensitive configuration data, such as key-value pairs or configuration files. It is designed to decouple configuration artifacts from container images, allowing Pods to consume this data as environment variables, command-line arguments, or mounted files in a volume. Unlike Secrets, ConfigMaps do not provide encryption or base64 encoding by default, making them suitable only for non-sensitive information.

The -c flag specifies the container name. The correct command is 'kubectl logs app-pod -c sidecar'.

'kubectl describe pod <pod-name>' shows events and conditions that explain why the pod is pending, such as resource shortages or node selector mismatches.

Pending means the scheduler cannot place the pod. Insufficient resources on nodes is a common cause. Option D is correct.

The Deployment creates a new ReplicaSet for the new version and scales it up while scaling down the old ReplicaSet. Pods are managed by ReplicaSets, not by the Deployment directly.

kubectl logs <pod-name> retrieves logs from the container. If the pod has multiple containers, you use -c to specify.

Option C is correct because when a Pod and a Service are in the same namespace, Kubernetes DNS resolves the Service using just the Service name (e.g., 'api'). The DNS search domain configured in the Pod's resolv.conf (e.g., <namespace>.svc.cluster.local) appends the namespace and cluster suffix automatically, so a short query like 'api' resolves correctly without needing the full FQDN.