Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 601–675

Option D is correct because namespaces are a fundamental mechanism in Kubernetes for dividing cluster resources among multiple users or teams, enabling multi-tenancy and resource management through policies like Role-Based Access Control (RBAC) and ResourceQuotas. Option E is correct because ResourceQuotas are Kubernetes objects that can be applied to a namespace to enforce aggregate limits on CPU, memory, and other resources, preventing any single team from exhausting cluster capacity.

Option C is correct because reducing the CPU request of the inventory deployment to 1 CPU per pod allows the scheduler to pack pods more efficiently on existing nodes, alleviating immediate 'Insufficient cpu' and 'Insufficient memory' failures while the cluster autoscaler provisions new nodes. This approach balances short-term scheduling needs with the ability to scale the inventory service later, as requests can be adjusted upward once the cluster has more capacity.

The 12-factor app recommends strict separation of config from code, storing config in environment variables.

Deployment with a RollingUpdate strategy is ideal for stateless applications requiring zero-downtime updates.

Kubernetes is the correct answer because it is the only CNCF project at the 'Graduated' maturity level that is specifically designed and widely adopted for container orchestration. It automates deployment, scaling, and management of containerized applications, making it the de facto standard in cloud-native environments.

B is correct because Pods are the smallest and most fundamental deployable units in Kubernetes, representing a single instance of a running process in the cluster. A Pod encapsulates one or more containers, storage resources, and a unique network IP, and is the atomic unit of scheduling. This is defined in the Kubernetes core API and is a foundational concept for the KCNA exam.

These are essential kubectl commands for daily operations.

StatefulSet provides stable network identities and persistent storage for stateful applications.

A Pending pod usually indicates scheduling issues, such as insufficient resources or node constraints.

Immutable infrastructure means that once a container image is built, it is never modified; updates are done by replacing the entire container with a new image.

Option B is correct because the `nodeSelector` field in a Pod spec is the standard Kubernetes mechanism for constraining a Pod to run only on nodes that match specific labels. By setting `nodeSelector: { disk-type: ssd }`, the scheduler will ensure the Pod is placed exclusively on nodes with that label, enforcing the administrator's requirement.

The circuit breaker pattern prevents an application from repeatedly trying to execute an operation that is likely to fail, allowing it to recover gracefully.

Signing container images (e.g., using Cosign or Notary) and verifying those signatures during deployment ensures that only trusted, unmodified images are deployed, preventing supply chain attacks. This practice enforces image integrity and provenance, which is a core security requirement for cloud native CI/CD pipelines.

The 12-factor app includes principles such as explicit dependency declaration (Dependencies) and strict separation of config from code (Config).

Option C is correct because 'kubectl describe pod my-pod' provides detailed information about the pod's current state, including events, conditions, and resource constraints. When a pod is stuck in 'Pending', it typically means the scheduler cannot place it on a node due to issues like insufficient CPU/memory, persistent volume claims not being bound, or node selector mismatches. The 'describe' command surfaces these specific reasons in the 'Events' section and 'Conditions' field, making it the most direct diagnostic tool.

The `kubectl set image deployment/myapp myapp=myapp:v2` command updates the pod template within the Deployment's specification to use the new image `myapp:v2`. This change triggers a rolling update, where the Deployment controller creates new pods with the updated image and gradually terminates old pods, ensuring zero downtime. The command does not affect Services, create new Deployments, or restart pods immediately without a rolling update strategy.

The kube-controller-manager is the component that runs controller loops to regulate the state of the cluster. Each controller (e.g., Node Controller, Replication Controller) watches the shared state via the API server and makes changes to drive the actual cluster state toward the desired state defined in the control plane. This is the core mechanism for self-healing and maintaining declarative configuration.

The Deployment's selector requires that the pod template has matching labels. Without them, the Deployment will fail validation or not manage any pods.

D is correct because a Namespace is the Kubernetes object designed to logically isolate resources within a single cluster. By creating separate Namespaces for environments like dev and prod, you can apply distinct policies, quotas, and access controls without needing multiple physical clusters.

The OOMKilled status indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, which allows the container to use more memory without being killed by the Out-Of-Memory (OOM) killer. This resolves the root cause by providing sufficient memory for the workload.

nodeName, nodeSelector, and node affinity are all mechanisms to schedule pods on specific nodes.

By default, the Deployment controller will stop the rollout if the new pods are unhealthy, and the old ReplicaSet remains running.

Factor III of the 12-factor app methodology states that config should be stored in environment variables to keep it separate from code.

Containers share the host OS kernel, while VMs include a full guest OS. This makes containers more lightweight and portable.

An SLO is a target level of reliability, expressed as a percentage of a metric over a time window.

The query should calculate the average CPU usage rate over 5 minutes and compare it to 0.8 (80%).

The Graduated maturity level is the highest in the CNCF project lifecycle, indicating that a project has successfully adopted CNCF governance, demonstrated long-term stability, and is considered safe for production use. This requires meeting rigorous criteria including adoption by multiple end users, a defined governance structure, and completion of a security audit.

With maxUnavailable=0, no Pod can be unavailable during update. With maxSurge=1, one extra Pod can be created, so a new Pod is created first, then an old one is terminated, ensuring all 3 replicas are always available.

Continuous delivery ensures code is always in a deployable state but requires manual approval for production deployment. Continuous deployment automatically deploys every change to production without manual intervention.

Image scanning, signing, and using minimal base images are key security practices. Hardcoding credentials and running containers as root are anti-patterns.

A Service provides a stable IP address and DNS name to access a set of pods, enabling load balancing and service discovery.

DaemonSet ensures that a copy of a pod runs on all (or some) nodes, commonly used for cluster-wide services like log collection or monitoring agents.

A Pod is the smallest and simplest unit in the Kubernetes object model.

Options A, C, and D are correct. 'containers' defines the list of containers in the Pod, 'volumes' defines volumes that can be mounted by containers, and 'nodeSelector' constrains which nodes the Pod can run on. Option B is incorrect because 'ports' is not a top-level field; ports are defined within containers. Option E is incorrect because 'clusterIP' is an attribute of a Service, not a Pod.

Infrastructure automation (B) is a key principle of cloud native architecture because it enables consistent, repeatable, and error-free provisioning and management of infrastructure through code (e.g., Terraform, AWS CloudFormation, Ansible). This aligns with the cloud native goal of reducing manual toil and enabling rapid, reliable deployments. Microservices (C) is also a core principle, as it structures applications as a collection of loosely coupled, independently deployable services that can be scaled and updated individually, which is fundamental to cloud native agility and resilience.

The Open Container Initiative (OCI) is a Linux Foundation project that defines open industry standards for container image formats and container runtimes. Its two main specifications are the OCI Image Spec (which standardizes the container image layout, including layers and manifests) and the OCI Runtime Spec (which defines the lifecycle and configuration for running containers). This ensures interoperability between different container tools and platforms, such as Docker, Podman, and containerd.

A PVC stays Pending if no matching PV exists that satisfies its requirements (storage class, access mode, size) or if there are insufficient resources on available nodes to bind the PV. The PV must be manually bound or dynamically provisioned.

CoreDNS is the cluster DNS component; if it is not running or misconfigured, DNS name resolution fails while direct IP access works.

The 'PodInitializing' state indicates that the pod is stuck before its main containers can start, which is typically caused by an InitContainer that is failing or hanging. Since the job fails with 'DeadlineExceeded', the pod's activeDeadlineSeconds (or the CronJob's startingDeadlineSeconds) has been reached while the InitContainer is still running, preventing the main container from executing. This is the most likely reason because InitContainers run sequentially to completion before any main containers start, and a stuck InitContainer blocks the entire pod lifecycle.

NodeSelector is the simplest way to constrain pods to nodes with specific labels.

The kubelet is the agent that runs on each node and manages the lifecycle of containers based on PodSpecs.

ClusterIP Services are only accessible within the cluster via DNS. If DNS resolution is not working, the pod cannot resolve the Service name.

'kubectl describe deployment' shows events and status conditions that explain why a pod might not have been created.

These are graduated CNCF projects commonly used in cloud native environments.

The error indicates the application cannot connect to the database. Since other pods can reach the database, the issue is specific to this pod. A common cause is that the pod's configuration (e.g., environment variables, config file) contains wrong connection details, such as incorrect service name, port, or credentials.

The CNCF's mission is to make cloud native computing ubiquitous by fostering and sustaining open source projects that follow cloud native principles.

The 'kubectl get pods' command lists Pods in the current namespace (default if not specified).

Option C is correct because a Pod is the smallest and most basic deployable unit in Kubernetes. It represents a single instance of a running process and encapsulates one or more containers, storage resources, and a unique network IP. You cannot deploy a container directly; you must always wrap it in a Pod.

Pod anti-affinity with a requiredDuringSchedulingIgnoredDuringExecution rule and a topologyKey of 'kubernetes.io/hostname' ensures that pods are not co-located on the same node.

Option C is correct because a service mesh, such as Istio or Linkerd, provides fine-grained traffic control through features like traffic splitting, header-based routing, and weighted load balancing. This enables canary deployments by directing a small percentage of traffic to a new version of a service, allowing safe testing in production without affecting all users.

StatefulSets are designed for stateful applications requiring stable network identities, persistent storage per Pod, and ordered deployment/termination.

Exit code 137 (128 + 9) indicates the container was terminated by SIGKILL. Combined with 'Killed' in logs, this is the definitive signature of an OOMKill event, where the Linux kernel's Out-Of-Memory (OOM) killer terminates the container process because it exceeded its memory limit (specified in the pod's resource limits). Kubernetes enforces memory limits via cgroups, and when the container's memory usage surpasses the limit, the OOM killer sends SIGKILL, resulting in exit code 137.

Option D is correct because the 12-factor app methodology mandates strict separation of config from code. Config includes things like database connection strings, API keys, and environment-specific values that vary between deployments. Storing these in environment variables (or external config files not checked into version control) ensures that the same codebase can be deployed to different environments without modification, which is a core principle for cloud-native portability and security.

The correct answer is C because a readiness probe that fails (e.g., the /health endpoint does not exist in the nginx container) will cause the pod to be marked as not ready. Kubernetes removes pods with failing readiness probes from the Service's endpoints list, resulting in an empty endpoints list even though the Service selector matches the pod labels. This is a common misconfiguration where the probe endpoint is not actually served by the container.

A trace consists of spans, which are individual units of work.

CPU is a compressible resource; if usage is between request and limit, the container can burst and is not throttled or killed.

Option A is correct. 'kubectl logs web-pod -c nginx' is the correct syntax to get logs from a specific container in a multi-container pod. Option B is for a single-container pod only. Option C describes events, and Option D exec runs a command.

The pod is in CrashLoopBackOff due to OOMKilled, which means the container's memory usage exceeded its configured memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to use more memory without being terminated by the Out-Of-Memory (OOM) killer. This directly addresses the root cause—insufficient memory allocation—while preserving the existing pod configuration and data.

Option C is correct because `nodeSelector` is a simple and direct mechanism in Kubernetes to constrain a pod to run only on nodes that have a specific label, such as `disktype=ssd`. By labeling nodes with SSDs and adding the corresponding `nodeSelector` in the pod spec, the scheduler ensures the pod is placed exclusively on those nodes. This approach is straightforward and does not require complex scheduling constraints or resource management.

The CNCF hosts, supports, and sustains open-source cloud-native projects, ensuring they are vendor-neutral and fostering community collaboration. It does not develop projects itself but provides a governance model.

Prometheus pulls metrics from targets at regular intervals, which is the pull-based model.

Alertmanager uses routes to match alerts and receivers to send notifications. Routes define grouping and routing logic.

The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler could not place the pod because no node has enough allocatable memory to satisfy the pod's memory request. Option B is correct because the pod's memory request exceeds the available memory on any node, causing the pod to remain in Pending state indefinitely until sufficient resources become available.

Option C is correct because a container runtime is a core component of a Kubernetes worker node. It is responsible for actually running the containers (e.g., containerd, CRI-O) and is required by the kubelet to manage pod lifecycle. Without a container runtime, the kubelet cannot start or stop containers on the node.

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all administrative tasks and API requests. It validates and processes RESTful API calls (using JSON/YAML over HTTP/HTTPS) before persisting state to etcd or delegating work to other controllers. Without the API server, no kubectl command, automation script, or internal component can interact with the cluster.

etcd is a distributed, consistent key-value store used by Kubernetes to store all cluster data, including configuration, state, and metadata. It is the single source of truth for the cluster; without etcd, the cluster cannot maintain or recover its state. The kube-apiserver is the only component that communicates directly with etcd, but it is etcd itself that physically stores the data.

A Service of type NodePort exposes the service on a static port on each node's IP address. Traffic sent to that port on any cluster node is forwarded to the underlying service, making it accessible from outside the cluster without requiring a cloud load balancer.

A Service of type ClusterIP (the default) provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that resolves to the Pods selected by its label selector. This allows Pods to discover each other using consistent DNS names, regardless of Pod IP changes due to scaling or restarts. The kube-dns or CoreDNS addon automatically creates DNS records for Services, enabling service discovery within the cluster.

The 'describe' command provides detailed information about a resource, including events, configuration, and status.

The bulkhead pattern isolates resources to prevent failure propagation. Circuit breaker stops calls after failures, retry reattempts, and timeout limits wait time.