Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 526–600

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because containers are faster to start than VMs, not slower — containers start in milliseconds to seconds since they only need to launch a process, while VMs require booting a full guest OS. Option B is wrong because VMs provide stronger isolation than containers — VMs use a hypervisor to create hardware-level isolation between guest OSes, whereas containers rely on kernel namespaces and cgroups, which share the host kernel and have a weaker security boundary. Option C is wrong because containers are more portable than VMs — a container image bundles only the application and its dependencies, making it portable across any Linux host with the same kernel, while a VM image includes a full OS and is tied to specific hypervisor formats (e.g., OVF, VMDK).

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because Incubating is an intermediate stage where projects have shown initial adoption and are working toward graduation, but they are not yet considered fully stable for production use. Option B is wrong because Experimental is not a CNCF maturity level; the CNCF uses Sandbox, Incubating, and Graduated, while Experimental is a term used by other foundations or early-stage projects outside the CNCF. Option D is wrong because Sandbox is the entry-level stage for early-stage projects that are not yet ready for production use and have not fully adopted CNCF governance.

Why this answer

How to eliminate wrong answers

Option A is wrong because it describes a Recreate strategy, not a RollingUpdate; with maxSurge=1, only one new Pod is created at a time, not all three simultaneously. Option C is wrong because terminating all old Pods before starting new ones violates maxUnavailable=0, which prohibits any Pods from being unavailable during the update. Option D is wrong because maxUnavailable=0 is a valid and commonly used setting to ensure zero downtime; the update does not fail as long as there is capacity to surge (maxSurge>0).

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because storing configuration data as key-value pairs is the purpose of a ConfigMap or Secret, not a Service. Option C is wrong because managing rolling updates of container images is handled by a Deployment or StatefulSet controller, not a Service. Option D is wrong because scheduling pods onto nodes is the responsibility of the Kubernetes Scheduler, which uses resource requests, constraints, and affinity rules, while a Service only handles network abstraction and traffic routing.

Why this answer

How to eliminate wrong answers

Option A is wrong because a batch job that must complete once is a use case for a Job or CronJob, not a DaemonSet, which runs continuously on each node. Option B is wrong because a stateless web application with multiple replicas is typically deployed as a Deployment, which manages replicas across nodes without requiring one pod per node. Option C is wrong because a stateful application with persistent storage is best handled by a StatefulSet, which provides stable network identities and persistent storage per pod, unlike a DaemonSet which does not guarantee unique identities or ordered scaling.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit; Pods are scheduled onto Nodes, but Nodes themselves are not deployed as application units. Option C is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, providing declarative updates and scaling; it is not the smallest deployable unit. Option D is wrong because a Container is the runtime environment for an application process, but Kubernetes does not deploy containers directly; it wraps them inside a Pod, which is the smallest schedulable and deployable entity.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because hosting public container images is the role of container registries like Docker Hub, Quay.io, or Google Container Registry, not the OCI. Option B is wrong because providing a default container runtime for Kubernetes is not the OCI's responsibility; Kubernetes uses container runtimes like containerd or CRI-O, which may implement OCI specs but are not provided by the OCI itself. Option C is wrong because managing container orchestration is the function of orchestrators like Kubernetes, Docker Swarm, or Nomad, not the OCI, which focuses solely on standardization.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because a misconfigured CronJob schedule (e.g., wrong cron expression) would cause the job to run at incorrect times or not at all, but it would not cause a pod to be stuck in 'PodInitializing' with a 'DeadlineExceeded' error. Option C is wrong because if the container runtime were not installed on the node, the pod would likely remain in 'Pending' state (with an event like 'FailedCreatePodSandBox') rather than reaching 'PodInitializing', and the kubelet would report a runtime error. Option D is wrong because a low backoffLimit affects the number of retries after a job fails (e.g., if the main container exits with non-zero), but it does not cause a pod to be stuck in 'PodInitializing'; the 'DeadlineExceeded' error here is about the pod's active deadline, not the retry limit.

Why this answer

How to eliminate wrong answers

Option B is wrong because `topologySpreadConstraints` controls how pods are distributed across topology domains (e.g., zones, nodes) to achieve even spreading, not to enforce placement on nodes with a specific label. Option C is wrong because `affinity.nodeAffinity` can also enforce placement on labeled nodes, but it is a more advanced and flexible field that supports both required and preferred rules; the question asks for the field that should be used, and `nodeSelector` is the simplest and most direct answer for a simple label match. Option D is wrong because `tolerations` allow pods to be scheduled on nodes with matching taints, but they do not enforce placement on nodes with a specific label; they only permit scheduling on otherwise tainted nodes.

Why this answer

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs on the control plane, not on worker nodes; it manages controllers like the ReplicaSet controller and Node controller, but does not directly ensure containers are running on a specific node. Option B is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for actually running containers, but it does not interpret Pod manifests or enforce the desired state; it only executes commands from the kubelet via the Container Runtime Interface (CRI). Option D is wrong because kube-proxy runs on each node but handles network proxying and service load balancing (e.g., iptables or IPVS rules), not container lifecycle management.

Why this answer

How to eliminate wrong answers

Option A is wrong because a port mismatch would cause a connection timeout or connection refused at the transport layer, but the question states the connection fails entirely, which is more indicative of a DNS resolution failure. Option C is wrong because a ClusterIP Service is perfectly reachable from within the same namespace by its DNS name; NodePort is only needed for external access. Option D is wrong because if the Service selector does not match any pod labels, the Service would have no endpoints, but the connection attempt would still resolve the DNS name and reach the ClusterIP, resulting in a connection refused or timeout, not a complete failure to connect.

Why these pairings

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because exceeding CPU limits causes CPU throttling (container runs slower) but never triggers a kill or exit code 137; the container continues running. Option B is wrong because a liveness probe failure results in Kubernetes restarting the container with exit code 143 (SIGTERM) or 0, not 137, and the logs would show 'Liveness probe failed' not 'Killed'. Option D is wrong because node disk pressure leads to pod eviction (not container OOM kill) with a different exit code and a Kubernetes event like 'Evicted', not exit code 137 and 'Killed' in container logs.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the question states that the Service selector matches 'app: web', and the pods are created with that label, so the selector does match. Option B is wrong because the containerPort and Service targetPort are independent; the Service routes traffic to the containerPort, not the targetPort, and a mismatch would not cause an empty endpoints list—it would cause connection failures to the pod. Option D is wrong because an unavailable container image would prevent the pod from running (e.g., ImagePullBackOff), but the question says the pods are created and not receiving traffic, implying they are running; an unavailable image would not lead to an empty endpoints list.

Why this answer

How to eliminate wrong answers

Option A is wrong because 'kubectl create deployment' and 'kubectl apply' both create a Deployment resource; the command used does not affect rollout behavior or cause Pod failures. Option C is wrong because a Service selector mismatch would prevent traffic from reaching new Pods, but it would not cause the old Pods to remain running during a rollout; the Deployment would still replace old Pods with new ones. Option D is wrong because the 'Recreate' strategy terminates all old Pods before creating new ones, so old Pods would not still be running; the scenario describes old Pods remaining, which matches a rolling update with a paused rollout due to failed readiness probes.

Why this answer

How to eliminate wrong answers

Option B is wrong because `kubectl logs web-pod nginx` omits the required `-c` flag; in kubectl syntax, the container name must be preceded by `-c` or `--container`, otherwise the command will fail or misinterpret the argument. Option C is wrong because `kubectl describe pod web-pod` shows the Pod's metadata, status, and events, but does not display the live container logs; it only provides a snapshot of the Pod's configuration and recent events, not the actual log output. Option D is wrong because `kubectl exec web-pod -- cat /var/log/nginx/access.log` attempts to read a file from the container's filesystem, but container logs in Kubernetes are typically written to stdout/stderr and captured by the container runtime, not stored in a file at that path unless explicitly configured; this approach is non-standard and may fail if the file does not exist or the container does not have a shell.

Why this answer

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod does not resolve the underlying memory limit issue; the new pod would still have the same resource constraints and would likely be OOMKilled again. Option B is wrong because deleting the entire namespace and redeploying all workloads is an extreme, disruptive action that unnecessarily affects other workloads and does not target the specific pod's memory problem. Option D is wrong because increasing the CPU request does not affect memory allocation; the OOMKilled error is caused by memory exhaustion, not CPU starvation, so this change would not prevent the container from being killed.

Why this answer

How to eliminate wrong answers

Option A is wrong because taints and tolerations are used to repel pods from nodes (or allow them to tolerate repulsion), not to positively select nodes with specific hardware; they control which pods can run on a node but do not guarantee a pod will only run on nodes with SSDs. Option B is wrong because pod anti-affinity is used to prevent pods from co-locating on the same node or topology, not to select nodes based on hardware attributes like SSDs. Option D is wrong because a ResourceQuota limits resource consumption within a namespace and cannot influence node selection based on hardware characteristics.

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a large container image affects image pull time and disk space, not the scheduler's memory allocation decision; the scheduler only considers resource requests and limits, not image size. Option C is wrong because a failing liveness probe would cause the pod to be restarted or become CrashLoopBackOff, not remain in Pending state; liveness probes only run after the pod is scheduled and running. Option D is wrong because if the kubelet were not running, the node would show as NotReady or be absent from 'kubectl get nodes', and the scheduler would report a different error like '0/1 nodes are available: 1 node(s) had taint that the pod didn't tolerate' or 'node(s) were unschedulable'.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager is a control loop that watches the shared state via the API server and makes changes to move the current state toward the desired state; it does not accept external API requests directly. Option B is wrong because etcd is a distributed key-value store used for cluster state persistence, not an API endpoint; all reads and writes to etcd go through the kube-apiserver. Option D is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, and it receives its instructions from the API server, not from external administrative requests.

Why this answer

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for storing cluster state. Option B is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes API requests, but it does not store data; it reads from and writes to etcd. Option D is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state, but it does not persist state itself.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store configuration data as key-value pairs, not to provide network endpoints or DNS names for Pod discovery. Option B is wrong because an Ingress manages external HTTP/HTTPS traffic routing to Services, not internal Pod-to-Pod DNS-based discovery. Option D is wrong because a Deployment manages the desired state and lifecycle of Pods (replicas, updates), but does not create a stable network identity or DNS name for Pods to discover each other.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because port 80 is the default ClusterIP port, not the nodePort; NodePort services require the nodePort (30080) to be accessed externally. Option C is wrong because ClusterIP is only reachable from within the cluster, not from outside; external traffic must use a node's IP and the nodePort. Option D is wrong because 10.0.0.2:8080 uses an incorrect port (8080 instead of 30080) and implies a different service or port mapping; the nodePort must match the configured value (30080).

Why this answer

How to eliminate wrong answers

Option B is wrong because manual configuration management contradicts the cloud-native principle of declarative, automated infrastructure (e.g., using Kubernetes manifests or Terraform), leading to configuration drift and reduced scalability. Option C is wrong because tight coupling of services violates the microservices tenet of loose coupling, which is fundamental to independent deployability and fault isolation in cloud-native architectures. Option D is wrong because cloud-native architecture prefers stateless applications over stateful ones, as stateless services scale horizontally more easily and are simpler to manage; state is typically offloaded to external stores like databases or caches.

Why this answer

How to eliminate wrong answers

Option B (Grafana) is wrong because Grafana is a visualization and dashboarding tool, not a data source; it cannot collect or correlate metrics on its own and relies on Prometheus or other backends for data. Option C (Fluentd) is wrong because Fluentd is a log collector and forwarder, focused on unstructured log data, not on time-series metrics or direct correlation with resource usage. Option D (Jaeger) is wrong because Jaeger is a distributed tracing tool for tracking request paths across services, not for correlating error rates with resource usage metrics like CPU or memory.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because Deployment is intended for stateless applications and creates Pods with random, ephemeral identities and no guaranteed storage persistence; it does not provide stable network identities. Option B is wrong because DaemonSet ensures that a copy of a Pod runs on each node (or a subset of nodes) for node-level services like logging or monitoring, not for stateful workloads requiring stable identities and persistent storage. Option D is wrong because Job is designed for batch or one-time tasks that run to completion, not for long-running stateful applications that need persistent storage and stable network identities.

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs; VMs use a hypervisor to run separate guest OS kernels, offering stronger security boundaries, whereas containers rely on kernel namespaces and cgroups, which share the host kernel. Option B is wrong because containers use less disk space than VMs, as they do not include a full guest OS image and leverage layered filesystems (e.g., overlay2) to share common layers. Option C is wrong because containers do not require a hypervisor; they run directly on the host OS using container runtime engines like containerd or Docker, whereas VMs require a hypervisor (Type 1 or Type 2) to virtualize hardware.

Why this answer

How to eliminate wrong answers

Option B (Headless Service) is wrong because it does not provide a single virtual IP or load balancing; instead, it returns the IP addresses of all healthy pods via DNS, requiring the client to implement its own load balancing logic. Option C (ExternalName Service) is wrong because it maps the Service to an external DNS name (e.g., an external domain) and does not route traffic to any Kubernetes pods at all. Option D (NodePort) is wrong because it exposes the Service on a static port on each node's IP, which is used for external access and does not change the internal load balancing behavior (it still uses ClusterIP under the hood), but the question asks for the type that distributes traffic evenly to pods, and ClusterIP is the fundamental type for that purpose.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning Pods to nodes based on resource availability and constraints, not for managing container lifecycles on a node. Option B is wrong because kube-controller-manager runs controller processes (e.g., ReplicaSet, Deployment controllers) that regulate cluster state, but it does not directly interact with containers on individual nodes. Option C is wrong because kube-apiserver serves as the front-end for the Kubernetes control plane, exposing the Kubernetes API, but it does not manage container lifecycles on nodes; it only provides the interface for kubelet to retrieve Pod specifications.

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

Why this order

Why this answer

How to eliminate wrong answers

Option A is wrong because etcd is a distributed key-value store that holds cluster state, but it does not perform reconciliation or enforce desired replica counts; it only stores the data that controllers read and write. Option C is wrong because kubelet is an agent that runs on each node and manages Pods on that node, but it does not scale Deployments or manage replica counts across the cluster. Option D is wrong because kube-scheduler is responsible for assigning Pods to nodes based on resource availability and constraints, not for ensuring the number of Pods matches a desired replica count.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures a Pod runs on every node (or a subset) for continuous daemon-like services, not for a one-time batch job. Option B is wrong because a CronJob is used for scheduled, recurring tasks, not a single run. Option C is wrong because a Deployment manages long-running, stateless applications with desired replicas and rolling updates, not a terminating batch job.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl replace -f deployment.yaml` would replace the entire Deployment object, which is not the standard way to update just the image; it requires a complete YAML file and can cause downtime if not handled carefully. Option C is wrong because `kubectl edit deployment <name>` opens an interactive editor, which is not a single command for automation and can introduce human error or syntax issues. Option D is wrong because `kubectl patch` can technically update the image, but it requires a complex JSON patch string and is more error-prone than the simpler `kubectl set image` command; it is not the recommended or most straightforward approach for this common task.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because storing configuration only in environment variables is a specific pattern (e.g., 12-factor app), but it does not define immutability; immutable infrastructure requires replacing the entire unit, not just how config is injected. Option B is wrong because rebuilding containers from the same base image every time describes a build practice (e.g., using Dockerfile layers), but immutability is about the runtime behavior of replacing Pods, not the image build process. Option C is wrong because it describes mutable infrastructure (e.g., SSHing into a server to apply updates), which is the exact opposite of immutability; immutable infrastructure mandates that components are never updated in place—they are destroyed and recreated.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a CronJob is designed for scheduling recurring tasks on a time-based schedule (e.g., every hour), not for a single batch job that runs once and terminates. Option C is wrong because a Deployment is meant to run a set of Pods continuously, ensuring a specified number of replicas are always running; it will restart Pods if they exit, which is the opposite of a terminating batch job. Option D is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) node in the cluster, typically for long-running system services like log collectors or monitoring agents, not for one-off batch processing.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a Service of type NodePort exposes the service on a static port on each node's IP address, making it accessible from outside the cluster, not just internally. Option B is wrong because an Ingress is an API object that manages external HTTP/HTTPS access to services, typically requiring a Service of type NodePort or LoadBalancer to route traffic, and does not itself provide a stable internal IP. Option C is wrong because a NetworkPolicy is a security resource that controls ingress and egress traffic to/from pods based on labels and ports, but it does not expose pods or provide a stable IP address.