Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 76–150

Pending state indicates the Pod has not been scheduled. Insufficient cluster resources (CPU/memory) is a common reason.

A Service provides a stable endpoint (IP and DNS) that load-balances traffic to a set of pods selected by labels.

Option D is correct because a Kubernetes Service provides a stable virtual IP address that remains constant even as the underlying Pods are created, destroyed, or rescheduled. This decouples clients from the ephemeral nature of Pod IPs, ensuring reliable connectivity within the cluster.

If no pods exist in the namespace, kubectl returns no output (no resources found).

When a container exceeds its memory limit, the kernel OOM killer terminates the container. The container may be restarted by the kubelet depending on the restart policy.

Option A is correct because the `replicas` field is a standard part of the Deployment spec under `apps/v1`, defining the desired number of Pod replicas. Option B is correct because the `template` field is mandatory, containing the Pod template that describes the Pods to be created. Option C is correct because the `selector` field is required to match the Pods managed by the Deployment, ensuring the ReplicaSet controls the correct Pods.

A Service of type ClusterIP provides a stable internal IP and DNS name for a set of pods.

Scale command, check pods, verify deployment, monitor rollout, and adjust resources if needed.

Kubernetes is a container orchestration platform designed to automate the deployment, scaling, and management of containerized applications across a cluster of nodes. Its primary purpose is to abstract the underlying infrastructure and provide a declarative way to run and manage containers, ensuring desired state and self-healing. This directly corresponds to orchestrating containers across a cluster, not compiling code, running VMs, or managing physical servers.

Prometheus supports counter, gauge, histogram, and summary. Options A and D are valid; B (timer) and C (quantile) are not; E (meter) is from OpenTelemetry.

Option D is correct because `kubectl describe pod <pod-name>` provides a comprehensive view of a pod's metadata, spec, status, conditions, container resource usage, and a chronological list of events (e.g., scheduling, pulling images, container restarts). This command aggregates information from the Kubernetes API server, including the pod's current state and lifecycle events, which is essential for debugging pod failures or unexpected behavior.

CoreDNS provides DNS service discovery for Services. If it is not running or misconfigured, DNS resolution will fail.

A Kubernetes Job is designed for one-time batch processing tasks that run to completion and are not restarted. It creates one or more Pods and ensures they successfully terminate, making it the correct choice for a non-repeating, finite workload.

The OpenTelemetry Collector is a vendor-agnostic agent that receives, processes, and exports telemetry data.

kubectl get pods and kubectl describe pod are standard commands.

Bulkhead isolates resources into pools (e.g., thread pools) so that a failure in one pool does not cascade. Circuit breaker stops calls after failures, retry repeats failed calls, and timeout limits wait time.

Alertmanager handles alerts sent by Prometheus server, deduplicates, groups, and routes them to receivers (email, Slack, etc.), and manages silencing and inhibition.

The OOMKilled status indicates the container was terminated because it exceeded its memory limit. Increasing the memory limit in the pod's container resource specification directly addresses the root cause by allowing the container to use more memory before being killed. This is the most appropriate action because the pod was running successfully for days, suggesting a gradual memory growth or a recent workload change rather than a configuration error.

The control plane consists of kube-apiserver, etcd, kube-scheduler, and kube-controller-manager. kubelet and kube-proxy run on nodes.

Container orchestration provides high availability (self-healing, automated restarts) and scaling (automatically adjusting replicas based on load).

Docker Compose is the most appropriate tool for running a containerized application locally during development because it allows you to define and manage multi-container applications using a simple YAML file. It handles container lifecycle, networking, and volume mounts with a single `docker compose up` command, making it ideal for local development workflows where rapid iteration and simplicity are key.

Prometheus is a graduated CNCF project, indicating it has reached a high level of maturity and adoption.

StatefulSet is the correct workload type because it provides stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that persist across Pod rescheduling). This makes it ideal for stateful applications like databases, where each Pod requires a stable identity and dedicated storage that survives restarts.

etcd is a distributed key-value store that stores the entire configuration and state of the Kubernetes cluster.

Option C is correct because cloud-native applications are typically packaged as lightweight containers (e.g., Docker) that encapsulate the application and its dependencies, enabling fast startup, portability, and efficient resource utilization. Containers share the host OS kernel and have minimal overhead compared to virtual machines, which aligns with the cloud-native principle of agility and scalability.

An API gateway handles cross-cutting concerns like authentication, rate limiting, routing, and aggregation. Direct database access (A) is an antipattern, managing container orchestration (C) is Kubernetes' job, and storing application state (D) is not a gateway function.

Kubernetes, as a container orchestrator, provides built-in Horizontal Pod Autoscaling (HPA) that automatically adjusts the number of pod replicas based on observed CPU utilization (or custom metrics). This is a core benefit because it allows applications to handle varying load without manual intervention, improving resource efficiency and availability.

The control plane consists of kube-apiserver, etcd, kube-scheduler, and kube-controller-manager. kubelet and kube-proxy run on worker nodes.

Access the node, save snapshot, verify, store securely, and restore when necessary.

Option B is correct because a global load balancer with active-passive regional failover provides a straightforward way to route traffic to a healthy secondary region when the primary fails, without the complexity of multi-region Kubernetes control planes or synchronous replication. This approach leverages DNS-based or anycast routing to detect region failure and redirect traffic, ensuring high availability while keeping the operational overhead low.

The container runtime (e.g., containerd) is the component responsible for actually running containers on a Kubernetes node. It pulls container images, manages container lifecycles, and handles low-level operations such as starting and stopping containers via the CRI (Container Runtime Interface). Without a container runtime, the kubelet cannot launch or manage any containers on the node.

You can update the Deployment's pod template to include the missing environment variables, then perform a rolling update.

containerd and CRI-O are CRI-compliant container runtimes. Docker is not directly CRI-compatible (uses dockershim, deprecated). runc is a low-level runtime that is used by containerd and CRI-O but is not itself a CRI implementation.

maxUnavailable in the rolling update strategy controls how many Pods can be unavailable during the update.

Secrets are designed to store sensitive information like passwords, tokens, or keys.

Option C is correct because Kubernetes includes a built-in controller (the kubelet and ReplicaSet controller) that continuously monitors the desired state of pods. If a container fails or its process crashes, the kubelet automatically restarts it based on the pod's restart policy (e.g., Always), ensuring high availability without manual intervention. This self-healing capability is a core benefit of container orchestration, reducing downtime and operational overhead.

Envoy proxy is the correct answer because in Istio, each pod is deployed with an Envoy sidecar proxy that intercepts all inbound and outbound traffic. This proxy enforces traffic policies (e.g., routing rules, fault injection, rate limiting) and collects telemetry data (e.g., metrics, logs, traces) at the pod level, sending it to the observability backends. The sidecar model ensures policy enforcement and telemetry collection happen without modifying the application code.

High availability and self-healing are key benefits. Manual deployment and static scaling are not benefits of orchestration.

Option A is correct because a Secret is a dedicated Kubernetes resource type designed to store sensitive data, such as passwords, OAuth tokens, and SSH keys, in a base64-encoded format. Secrets are stored in etcd and can be mounted as volumes or exposed as environment variables, with optional encryption at rest to protect sensitive configuration data.

A segmentation fault (segfault) is a specific error caused by a program attempting to access memory it does not have permission to access, typically due to a bug in the application code (e.g., null pointer dereference, buffer overflow). Since the container starts but then crashes repeatedly (CrashLoopBackOff), the segfault indicates the application itself is failing, not the infrastructure or configuration. This is the most direct cause of the pod entering CrashLoopBackOff.

GitOps uses Git as the single source of truth and automatically reconciles cluster state with the repository.

The bulkhead pattern isolates resources into separate pools (e.g., thread pools) to limit the impact of a failure in one service on others.

Each workload resource addresses specific operational requirements.

The Rolling update strategy is the correct answer because it incrementally replaces old pods with new ones while maintaining application availability. In Kubernetes, a rolling update updates pods one by one (or in small batches), ensuring that a specified number of pods remain available throughout the process. This is achieved by gradually scaling down the old ReplicaSet and scaling up the new one, controlled by parameters like `maxSurge` and `maxUnavailable` in the Deployment spec.

Option B is correct because `kubectl exec my-pod -- cat /var/log/app.log` runs the `cat` command inside the container of the pod, allowing you to read a specific log file directly from the filesystem. This is a valid method when the application writes logs to a file rather than stdout/stderr, or when you need to inspect a log file that is not captured by the standard logging driver.

RollingUpdate with maxSurge=1 and maxUnavailable=0 ensures one pod is updated at a time and the update pauses if the new pod is not healthy.

Option B is correct because `kubectl run nginx --image=nginx` creates a Pod imperatively, which is a valid way to create a Kubernetes resource directly from the command line without a manifest file. This command generates a Pod named 'nginx' using the specified container image, and it is a supported method for quick testing or ad-hoc resource creation.

Option A is correct because `kubectl logs app-12345 -c web` explicitly specifies the container name 'web' within the Pod 'app-12345' using the `-c` flag. This is the standard syntax for viewing logs of a specific container in a multi-container Pod, as the `kubectl logs` command defaults to the first container if `-c` is omitted.

The 'envFrom' field in a container spec allows injecting all key-value pairs from a ConfigMap as environment variables.

Envoy proxy is the most common sidecar proxy in service meshes like Istio and Linkerd. Istiod is the control plane component, Kiali is a visualization tool, and Prometheus is a monitoring system.

Option D is correct because `spec.strategy.rollingUpdate.maxUnavailable` controls the maximum number of Pods that can be unavailable during a rolling update. Setting this to 1 ensures that at most one Pod is unavailable at any time, meeting the administrator's requirement. This field is part of the Deployment's rolling update strategy and directly governs the availability guarantee during the update process.

CI automates building and testing code changes to catch integration issues early, ensuring that code is always in a deployable state.

Istio is correct because it provides native support for multi-cluster and multi-cloud deployments through its mesh federation capabilities, including features like multi-primary and primary-remote cluster models, as well as east-west gateways for cross-cluster traffic. It leverages Envoy proxies and a unified control plane to enable service discovery, traffic management, and security across clusters, making it the only option among the listed that offers built-in, production-ready multi-cluster support.

The 'maxUnavailable' field in the rolling update strategy specifies the maximum number of pods that can be unavailable during the update. Setting it to a lower value ensures more pods remain available.

A Job with a specified number of completions and parallelism can run pods to completion, handling failures by restarting or marking as failed.

The kube-controller-manager runs various controllers, including the ReplicaSet controller, which ensures that the desired number of pods is maintained.

Secrets are designed to store sensitive information and can be mounted as volumes or environment variables.

The kube-controller-manager runs the ReplicaSet controller, which detects the mismatch and creates a new pod.

Option B is correct because `kubectl get endpoints db-service` directly shows whether the service has any endpoints (i.e., pod IPs) associated with it. If the endpoints list is empty, it indicates that the service's label selector is not matching any pods, which is the most common cause of connectivity failure. This is the fastest way to verify the fundamental prerequisite for service-to-pod traffic.

Option B is correct because the `kubectl logs` command requires the pod name first, and the `-c` flag (or `--container`) specifies the container name within that pod. Since the pod 'web-1' contains a container named 'app', `kubectl logs web-1 -c app` retrieves the logs from that specific container. This is the standard syntax for targeting a container in a multi-container pod.

The default restart policy is Always, so the container will restart. The solution is to increase the memory limit and consider using a liveness probe to detect and restart earlier.

The three pillars of observability are logs, metrics, and traces. Alerting is derived from metrics, not a pillar itself.

The 'kubectl set image' command updates the container image in the Deployment, triggering a rolling update by default.

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the REST API and handling all requests.

'kubectl rollout undo deployment/my-deployment' rolls back to the previous revision.

NodePort, LoadBalancer, and Ingress are all valid methods to expose services externally. ClusterIP only exposes internally within the cluster.

The `kubectl set image` command is the correct way to perform a rolling update on a Deployment. It directly updates the container image in the pod template, triggering a rolling update where the ReplicaSet gradually replaces old pods with new ones, ensuring zero downtime. Option A specifies the exact container name and new image, which matches the required syntax for a targeted update.

A counter is a cumulative metric that only increases, ideal for counting requests.