Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 376–450

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because CQRS (Command Query Responsibility Segregation) is a pattern for separating read and write operations, typically used with event sourcing or complex query models; it does not address the gradual decomposition of a monolith or enable independent scaling of components during migration. Option C is wrong because implementing a database-per-service pattern prematurely would require breaking the shared database into multiple databases, which is a high-risk, all-at-once change that contradicts the gradual migration goal and can cause data consistency issues without first establishing service boundaries. Option D is wrong because deploying a sidecar container for each service is a deployment pattern for adding auxiliary functionality (e.g., logging, proxies) to a pod, but it does not help in decomposing the monolith or enabling independent scaling of components; it is an operational pattern applied after services are defined.

Why this answer

How to eliminate wrong answers

Option A is wrong because a ServiceAccount is an identity object used to control pod-level authentication to the Kubernetes API server, not for storing configuration data. Option B is wrong because a Secret is specifically designed for storing sensitive data (e.g., passwords, tokens, SSH keys) and is base64-encoded, not for non-confidential configuration. Option D is wrong because a PersistentVolume is a storage resource abstraction that provides persistent storage to pods, not a mechanism for injecting configuration data.

Why this answer

How to eliminate wrong answers

Option A (kubelet) is wrong because kubelet is the node agent that communicates with the control plane and manages pods, but it does not run containers directly—it delegates container operations to a CRI-compliant runtime like containerd. Option B (etcd) is wrong because etcd is a distributed key-value store used for cluster state persistence, not for running containers or implementing CRI. Option C (kube-proxy) is wrong because kube-proxy is a network proxy that handles service routing and load balancing using iptables or IPVS, and it has no role in container runtime operations or the CRI.

Why this answer

How to eliminate wrong answers

Option A is wrong because Ingress is not a stable IP/DNS resource for pods; it is an API object that manages external HTTP/HTTPS access to Services, typically providing host-based or path-based routing and TLS termination, but it does not itself assign a stable IP or DNS name to a set of pods. Option B is wrong because EndpointSlice is not a stable IP/DNS resource; it is a lower-level object that tracks the actual IP addresses and ports of pods matching a Service's selector, used for scalability and efficiency, but it does not provide a stable endpoint for clients. Option D is wrong because NetworkPolicy is a security resource that controls traffic flow at the IP address or port level (OSI layer 3 or 4) using pod selectors and namespace selectors; it does not provide any IP address or DNS name for accessing pods.

Why this answer

How to eliminate wrong answers

Option A is wrong because structured logging does not replace metrics and traces; it complements them as part of the three pillars of observability (logs, metrics, traces), each serving a distinct purpose. Option B is wrong because structured logging often increases log file size due to added metadata (e.g., JSON keys), not reduces it; compression or sampling is used for size reduction. Option C is wrong because while structured logs can be formatted for readability, their core design is for machine parsing, not human readability; unstructured plain-text logs are typically more human-readable.

Why this answer

How to eliminate wrong answers

Option A is wrong because if the container image does not exist, the pod would transition to 'ImagePullBackOff' or 'ErrImagePull' state, not remain in 'Pending' — the scheduler would still assign the pod to a node first. Option C is wrong because a failing readiness probe causes the pod to be marked as 'NotReady' but it remains in 'Running' state, not 'Pending'. Option D is wrong because a failing liveness probe triggers container restarts and eventually 'CrashLoopBackOff', but the pod is still scheduled and in 'Running' state, not 'Pending'.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a Service is an abstraction that defines a logical set of Pods and a policy to access them; it is not a deployable unit but rather a networking resource that sits on top of Pods. Option B is wrong because a Container is not a Kubernetes API object; Kubernetes manages containers only within the context of a Pod, and you cannot create or manage a standalone container via the Kubernetes API. Option D is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods; it is not the smallest deployable unit but rather a declarative way to manage Pod scaling and updates.

Why this answer

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it does not interpret PodSpecs or enforce desired state — it only executes container lifecycle operations when instructed by the kubelet. Option B is wrong because kube-proxy is a network proxy that runs on each node, handling service-to-pod traffic routing via iptables or IPVS rules, and has no role in container lifecycle management. Option D is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, but it does not run on worker nodes and does not manage running containers.

Why this answer

How to eliminate wrong answers

Option A is wrong because a failing liveness probe causes the kubelet to restart the pod, but it does not directly prevent the Service from routing traffic to the pod while it is still running; traffic can still reach a pod with a failing liveness probe until it is terminated. Option B is wrong because if Deployment replicas are set to zero, there are no pods to receive traffic at all, but the question states the pods are not receiving traffic as expected, implying pods exist but traffic is not reaching them. Option D is wrong because a NodePort Service type does not inherently block traffic; it simply exposes the Service on a static port on each node's IP, and traffic can still reach pods as long as the selector matches.

Why this answer

How to eliminate wrong answers

Option A is wrong because `extensions/v1beta1` was deprecated in Kubernetes v1.16 and removed in v1.22; it is not a valid apiVersion for Deployments in a modern cluster (v1.19+). Option B is wrong because `v1` is the core API group used for resources like Pods, Services, and ConfigMaps, but Deployments belong to the `apps` API group, not the core group. Option D is wrong because `apps/v1beta1` was deprecated in Kubernetes v1.16 and removed in v1.22; the stable `apps/v1` is the only correct version for Deployments in v1.19+.

Why this answer

How to eliminate wrong answers

Option A is wrong because etcd is a distributed key-value store that holds all cluster data, but it does not run controller loops or enforce desired state; it is a passive storage backend. Option B is wrong because kube-apiserver is the front-end for the Kubernetes API that validates and processes RESTful requests, but it does not execute controller reconciliation logic; it serves as the communication gateway. Option D is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for maintaining the overall desired state of the cluster via controller loops.

Why this answer

Why these pairings

Why this answer

How to eliminate wrong answers

Option B is wrong because deleting and recreating the pod will not resolve the underlying memory limit issue; the new pod will still be subject to the same memory limit and will likely crash again with OOMKilled. Option C is wrong because increasing the CPU request does not affect memory allocation; OOMKilled is a memory-related error, not a CPU issue, and CPU changes will not prevent the container from exceeding its memory limit. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that does not target the specific memory limit problem and would cause unnecessary disruption to other workloads.

Why this answer

How to eliminate wrong answers

Option A is wrong because load balancing distributes incoming traffic across healthy instances (e.g., via Round Robin or Least Connections), not preventing overload from a failing service. Option B is wrong because authentication between services is handled by mechanisms like OAuth2, JWT, or mTLS, not by the circuit breaker pattern. Option C is wrong because encrypting data in transit is achieved via TLS/SSL (e.g., HTTPS, gRPC with TLS), not by circuit breakers which operate at the application or network layer to manage fault tolerance.

Why this answer

How to eliminate wrong answers

Option A is wrong because OOMKilled would show a container exit code of 137 and a 'OOMKilled' reason in pod status, not just restarts with probe failures. Option B is wrong because a network policy blocking traffic to the database would cause persistent connection failures, but the exhibit shows no evidence of network policy configuration or related errors. Option D is wrong because readiness probe misconfiguration affects traffic routing, not container restarts; liveness probe failures cause restarts, and readiness probe failures only remove the pod from service endpoints.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a Deployment manages a set of identical Pods with a desired replica count, but it does not guarantee placement on every Node; it uses a scheduler to distribute Pods across available Nodes, which may leave some Nodes empty. Option C is wrong because a ReplicaSet is a lower-level resource that ensures a specified number of Pod replicas are running, but it has no mechanism to enforce per-Node scheduling; it is typically used by Deployments for replica management. Option D is wrong because a StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage, not for running a Pod on every Node; it uses ordinal indexing and can be scheduled on a subset of Nodes.

Why this answer

How to eliminate wrong answers

Option A is wrong because a Job is designed for batch processing tasks that run to completion, not for long-running Pods requiring stable DNS identities; a Service with a Job would still use a regular ClusterIP, which load-balances across Pods and does not provide unique per-Pod DNS names. Option B is wrong because a DaemonSet ensures one Pod per Node but does not guarantee stable, unique DNS names for each Pod; combined with a regular Service, DNS resolves to the Service IP, not individual Pods. Option D is wrong because a Deployment creates identical, interchangeable Pods with no stable identity; a regular Service provides a single DNS name that load-balances across all Pods, not unique per-Pod DNS names.

Why this answer

How to eliminate wrong answers

Option B (Canary) is wrong because while it reduces risk by routing a small percentage of traffic to the new version, it is not primarily designed to minimize downtime during updates; it focuses on validating changes with a subset of users and often requires additional service mesh or ingress configuration. Option C (Blue/Green) is wrong because it minimizes downtime by running two full environments and switching traffic instantly, but it doubles resource costs and is not the simplest or most cost-effective choice for a startup aiming to minimize downtime without extra overhead. Option D (Recreate) is wrong because it terminates all old Pods before creating new ones, causing guaranteed downtime during the update, which directly contradicts the goal of minimizing downtime.

Why this answer

How to eliminate wrong answers

Option A is wrong because an Ingress is not an IP/DNS provider for Pods; it is an API object that manages external HTTP/HTTPS routing to Services, typically using a load balancer or reverse proxy, and does not assign a stable IP to Pods directly. Option B is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs or files, and it has no networking or IP assignment functionality. Option D is wrong because a Deployment manages the desired state and lifecycle of Pods (e.g., scaling, rolling updates) but does not provide a stable network endpoint; Pods created by a Deployment receive ephemeral IPs that change on restart.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because each layer is created by any instruction in the Dockerfile (not just RUN), and layers are immutable after the image is built; they cannot be modified. Option B is wrong because layers are identified by their content hash (SHA256) and are shared between images that use the same base layers, such as multiple images based on the same Ubuntu base. Option D is wrong because at runtime, a thin writable container layer is added on top of the read-only image layers; the image layers themselves remain read-only.

Why this answer

How to eliminate wrong answers

Option B is wrong because persistent storage for pods is provided by PersistentVolume (PV) and PersistentVolumeClaim (PVC) resources, not by a Service. Option C is wrong because configuration data for pods is stored in ConfigMaps or Secrets, not in a Service. Option D is wrong because managing rolling updates of applications is the responsibility of a Deployment (or StatefulSet), which uses a ReplicaSet to control the update strategy; a Service only exposes the pods, it does not manage their lifecycle or updates.

Why this answer

Why this order

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl exec` is used to execute commands inside a running container, not to view logs; the syntax `-- logs` is invalid and would attempt to run a command named 'logs' inside the container. Option B is wrong because the correct subcommand is `kubectl logs`, not `kubectl log`; Kubernetes CLI does not accept 'log' as a valid verb. Option D is wrong because it omits the `-c` flag and instead passes the container name as a positional argument; `kubectl logs` expects the pod name as the first argument and the container name must be specified with `-c` or `--container`, not as a bare argument.

Why this answer

How to eliminate wrong answers

Option A is wrong because Deployments do not expose services externally; that is the role of a Service (e.g., NodePort, LoadBalancer) or an Ingress resource. Option C is wrong because Deployments do not automatically configure DNS; DNS resolution for Pods and Services is handled by CoreDNS (or kube-dns) based on Service objects, not Deployments. Option D is wrong because Deployments do not provide persistent storage; persistent storage is managed through PersistentVolumeClaims (PVCs) and StorageClasses, which are referenced by Pods in a Deployment's template, but the Deployment itself does not provision or attach storage.

Why this answer

How to eliminate wrong answers

Option B is wrong because `kubectl logs app sidecar` is invalid syntax; the command expects the pod name first, and the container name must be specified with the `-c` flag, not as a positional argument. Option C is wrong because `kubectl logs sidecar app` reverses the order, treating 'sidecar' as the pod name and 'app' as an unrecognized positional argument, which will fail or produce incorrect output. Option D is wrong because `kubectl logs sidecar -p app` uses the `-p` flag (for previous container logs) incorrectly; the `-p` flag does not accept a container name as its argument, and the pod name 'sidecar' is not the correct pod name in this scenario.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because 'kubectl describe pod <name>' provides detailed information about a specific pod, not 'kubectl get pods'. Option C is wrong because 'kubectl get pod <name> -o yaml' outputs the YAML definition of a pod, not the plain 'kubectl get pods' command. Option D is wrong because 'kubectl logs <pod-name>' retrieves logs for a specific pod, and 'kubectl logs --all-containers=true' can target multiple containers, but there is no single command to get logs of all pods simultaneously; 'kubectl get pods' does not display logs.

Why this answer

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 a DaemonSet ensures that a copy of a Pod runs on every (or selected) Node in the cluster, which is intended for long-running background services like log collection or monitoring, not for batch jobs that terminate. Option C is wrong because a Deployment manages a set of Pods to run continuously (e.g., web servers) and will restart Pods if they exit, which is the opposite of a batch job that should terminate after completion. Option D is wrong because a StatefulSet is used for stateful applications that require stable network identities and persistent storage (e.g., databases), not for ephemeral batch processing tasks.

Why this answer

How to eliminate wrong answers

Option A is wrong because RBAC Role controls access to Kubernetes API resources (e.g., pods, services) for users or service accounts, not network traffic between pods. Option C is wrong because PodSecurityPolicy (deprecated in v1.21, removed in v1.25) enforces security constraints on pod specifications (e.g., privileged containers, host namespaces), not network communication. Option D is wrong because a Service provides a stable endpoint for accessing a set of pods via DNS or cluster IP, but does not filter or restrict traffic based on source labels.

Why this answer

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning newly created pods to nodes based on resource requirements and policies, not for maintaining desired state via reconciliation loops. Option B is wrong because etcd is a distributed key-value store that holds the cluster's configuration and state data, but it does not run reconciliation logic or enforce desired state. Option C is wrong because kube-apiserver serves as the front-end for the Kubernetes control plane, exposing the REST API and validating requests, but it does not perform continuous reconciliation; it is the gateway through which controllers interact.

Why this answer

Why this answer

Why this answer

Why this order

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because a missing container image would cause an ImagePullBackOff or ErrImagePull error, not a Pending state with node taint events. Option C is wrong because resource requests exceeding capacity would produce events like 'Insufficient memory' or 'Insufficient cpu', not taint-related messages. Option D is wrong because a failing liveness probe only affects running pods (causing restarts or CrashLoopBackOff), not pods that have never been scheduled.

Why this answer

How to eliminate wrong answers

Option B is wrong because service endpoints are removed only when a readiness probe fails, not a liveness probe; readiness probes control traffic routing, while liveness probes control container lifecycle. Option C is wrong because a liveness probe failure does not delete the pod; the pod continues to exist and the container is restarted in place. Option D is wrong because rescheduling to another node only happens if the pod is deleted (e.g., by a node failure or higher-level controller), not from a liveness probe failure; the kubelet handles the restart locally without involving the scheduler.

Why this answer

How to eliminate wrong answers

Option A is wrong because it uses `requests.cpu` and `requests.memory` instead of `limits.cpu` and `limits.memory`, which would only limit the total requested resources, not the actual limits that pods can use. Option C is wrong because it defines a LimitRange, not a ResourceQuota; LimitRange sets default resource requests/limits per container, not aggregate namespace-wide quotas. Option D is wrong because it omits the `namespace` field in metadata, so the ResourceQuota would not be applied to the 'staging' namespace; also, the syntax `cpu: 5` and `memory: 10Gi` without the `limits.` prefix is ambiguous and not the standard way to specify resource quotas.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because assigning IP addresses to Services is the role of the cluster IP address range and the kube-proxy component, not Namespaces; Namespaces do not manage IP allocation. Option B is wrong because limiting the number of Pods that can be created is achieved through ResourceQuotas or LimitRanges applied to a Namespace, not by the Namespace itself; a Namespace is a logical boundary, not a quota mechanism. Option D is wrong because providing DNS names for Pods is handled by CoreDNS (or kube-dns) and the cluster DNS service, which resolves Pod IPs via headless Services or Pod hostnames, not by Namespaces; Namespaces only affect DNS name scoping (e.g., <service>.<namespace>.svc.cluster.local).

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because visualizing metrics is the role of Grafana or the Prometheus expression browser, not Alertmanager. Option C is wrong because long-term metrics storage is handled by remote storage integrations (e.g., Thanos, Cortex) or the Prometheus TSDB itself, not Alertmanager. Option D is wrong because collecting metrics from targets is the function of the Prometheus server via its scrape mechanism, not Alertmanager.

Why this answer

Why this answer

How to eliminate wrong answers

Option A (ExternalName) is wrong because it maps a service to a DNS name (e.g., an external CNAME record) and does not expose pods or provide any network connectivity to external traffic; it is used for internal DNS aliasing. Option B (LoadBalancer) is wrong because it provisions an external cloud load balancer (e.g., AWS ELB, GCP LB) which assigns a dynamic external IP and port, not a fixed node port like 30080; it is overkill and does not guarantee the specific port. Option D (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP, reachable only from within the cluster, and cannot be accessed from external traffic without additional components like an ingress or proxy.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because moving the deployment to a separate namespace does not affect pod availability or crash recovery; namespaces are for logical isolation, not high availability. Option C is wrong because storing configuration in a ConfigMap decouples configuration from the container image but does not prevent or recover from pod crashes. Option D is wrong because a readiness probe only controls whether a pod receives traffic; it does not keep the service available if the pod crashes—it merely stops sending traffic to an unhealthy pod, but with a single replica, no other pod exists to handle requests.

Why this answer

How to eliminate wrong answers

Option A is wrong because the sidecar container does not run application business logic; that is the responsibility of the main container. Option B is wrong because while the sidecar can collect telemetry data as a byproduct of traffic interception, its primary purpose is not logging and monitoring—those are separate concerns often handled by dedicated agents or the control plane. Option C is wrong because persistent storage is provided by volumes or CSI drivers, not by sidecar containers, which are ephemeral and focused on network functions.

Why this answer

How to eliminate wrong answers

Option A is wrong because it reverses the relationship: virtual machines do NOT share the host kernel (they have their own guest OS kernel), while containers share the host kernel. Option B is wrong because containers do not require a hypervisor; they run directly on the host OS using kernel features like cgroups and namespaces, whereas VMs require a hypervisor (Type 1 or Type 2) to manage guest OS instances. Option C is wrong because containers do not include a full guest operating system; they package only the application and its dependencies, relying on the host OS kernel for system calls.

Why this answer

How to eliminate wrong answers

Option B is wrong because scaling up the microservice deployment will create more pods that all try to connect to the same unreachable database, multiplying the failure without addressing the root cause. Option C is wrong because restarting the microservice pod will only reattempt the same connection to the same database endpoint, which will still be refused if the database Service or its backing pods are misconfigured. Option D is wrong because checking logs of other microservices is a distraction; the 'connection refused' error is specific to the database connectivity and does not require cross-service log analysis to diagnose.

Why this answer

How to eliminate wrong answers

Option B is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods, not the smallest deployable unit itself. Option C is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit; Pods are scheduled onto Nodes. Option D is wrong because a Container is the runtime process, but Kubernetes schedules and manages Pods, not individual containers; containers must be wrapped in a Pod to be deployed.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because Bulkhead isolates resources (e.g., thread pools) to prevent failures in one component from cascading, but it does not handle transient faults in API calls. Option B is wrong because Circuit breaker prevents repeated calls to a failing service by opening the circuit after a threshold of failures, which is designed for longer-term outages, not transient faults. Option C is wrong because Timeout sets a maximum wait time for a response but does not retry the call; it only prevents indefinite blocking, leaving the failure unhandled.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `--container sidecar` is not a valid flag; the correct flag is `-c sidecar` or `--container=sidecar`. Option B is wrong because the syntax `kubectl logs sidecar pod-name` reverses the expected order — the container name must follow the `-c` flag, not precede the pod name. Option C is wrong because `kubectl logs pod-name sidecar` treats `sidecar` as a second positional argument, which is not supported; the container name must be specified with the `-c` flag.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `spec.minReadySeconds` defines the minimum time a Pod must be ready before it is considered available, but it does not control the order or parallelism of Pod termination during a rolling update. Option C is wrong because `spec.replicas` sets the desired number of Pod replicas but has no direct influence on the update strategy or the readiness check before terminating old Pods. Option D is wrong because `spec.template.spec.containers[].resources` defines CPU and memory requests/limits for containers, which affects scheduling but not the rolling update behavior or Pod readiness gating.

Why these pairings

Why this answer

How to eliminate wrong answers

Option B is wrong because resource requests for local SSD storage are not supported in the standard Kubernetes resource model; storage is requested via PersistentVolumeClaims, not as a compute resource in the Pod spec. Option C is wrong because pod anti-affinity is used to avoid co-locating Pods on the same node or topology, not to select nodes based on hardware characteristics like SSD storage. Option D is wrong because taints and tolerations are used to repel Pods from nodes unless they have a matching toleration, but they do not actively select nodes with specific hardware; a toleration would allow the Pod to run on non-SSD nodes if they are not tainted, and tainting all non-SSD nodes is impractical and does not guarantee scheduling on SSD nodes.