Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 676–750

NodePort exposes the service on each node's IP at the specified nodePort (30080). The service is reachable via <NodeIP>:<NodePort>. The internal ClusterIP is not reachable externally unless using a proxy or Ingress.

Kubernetes DNS resolves services in the form <service>.<namespace>.svc.cluster.local. If the pod is in a different namespace, it must use the full DNS name.

Automated CI/CD pipelines are a key principle of cloud-native architecture because they enable rapid, reliable, and repeatable delivery of microservices. By automating build, test, and deployment stages, teams can achieve continuous integration and continuous delivery, which aligns with the cloud-native goals of agility, scalability, and resilience. This automation reduces human error and accelerates the feedback loop, essential for managing distributed systems in dynamic cloud environments.

NodeSelector with matching label ensures the pod is scheduled on nodes with that label.

Prometheus is the correct choice because it is a monitoring and alerting toolkit designed to collect and store time-series metrics, such as CPU, memory, and request error rates. By querying Prometheus with PromQL, you can correlate 5xx error spikes with resource usage across all pods of a service, as it scrapes metrics from each pod's /metrics endpoint. This direct correlation of application-level errors with infrastructure metrics is not natively provided by the other tools listed.

Worker nodes run kubelet, kube-proxy, and container runtime. kube-apiserver and etcd are control plane components.

Option A is correct because microservices architecture is designed to allow each service to be developed, tested, and deployed independently without affecting other services. This independence is achieved through well-defined APIs and versioning strategies, enabling continuous delivery and rapid iteration. In Kubernetes, for example, each microservice can be packaged as a separate container and deployed via its own Deployment resource, allowing updates to one service without downtime for the entire application.

StatefulSet is the correct choice because it is designed specifically for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that are retained across Pod rescheduling). Unlike Deployments, StatefulSets guarantee ordered deployment, scaling, and termination, which is essential for databases or message queues.

Option A is correct because Deployments inherently support rolling updates and rollbacks through their declarative update strategy. When you change the pod template in a Deployment, it creates a new ReplicaSet and gradually scales it up while scaling down the old ReplicaSet, ensuring zero-downtime updates. If the update fails, you can roll back to a previous revision using `kubectl rollout undo`, which reverts the Deployment to a prior ReplicaSet state.

Option D is correct because a GitOps workflow relies on an operator (such as Argo CD or Flux) that continuously reconciles the actual cluster state with the desired state declared in a Git repository. This operator automatically detects drift and applies changes to ensure the cluster matches the Git source, which is the core feedback loop of GitOps.

A Service provides a stable IP address and DNS name for a set of pods, enabling load-balanced access even as pods are created and destroyed. It does not store configuration data, manage updates, or replace kube-proxy.

Containers are more portable and lightweight than virtual machines because they share the host OS kernel, eliminating the need for a separate guest OS per instance. This shared kernel approach reduces resource overhead (CPU, memory, and disk) and enables faster startup times, as containers only package the application and its dependencies without duplicating the operating system.

A ClusterIP Service is the correct choice because it provides a stable virtual IP address and round-robin load balancing across healthy pods in the Deployment. By default, kube-proxy uses iptables or IPVS rules to distribute traffic evenly to all ready pod endpoints, ensuring stateless web application requests are balanced without requiring external exposure.

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the REST API that all other components and kubectl interact with.

CRI-O is a lightweight container runtime specifically designed to implement the Kubernetes Container Runtime Interface (CRI), allowing Kubernetes to use OCI-compliant runtimes directly without relying on Docker. It is a valid CRI implementation because it provides the gRPC-based CRI API server and manages container lifecycle using runc or Kata Containers as the underlying OCI runtime.

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., Docker, containerd) to manage the container lifecycle—starting, stopping, and monitoring containers based on PodSpecs received from the API server.

Event-driven architecture decouples producers and consumers via an event broker (e.g., message queue or event bus), enabling asynchronous communication. Direct synchronous calls would couple them.

ArgoCD automatically syncs the cluster state to the desired state defined in Git (self-healing) and displays health status of applications. It does not generate manifests from templates natively (that's Kustomize's role) nor does it manage secrets directly.

ArgoCD and Flux are two popular GitOps tools that automate deployment of applications from Git repositories.

Option B is correct because a service mesh provides advanced traffic management capabilities such as fine-grained routing, canary deployments, and circuit breaking through sidecar proxies (e.g., Envoy). These capabilities allow operators to control traffic flow between microservices without modifying application code, enabling resilient and observable communication patterns.

Option B is correct because microservices architecture emphasizes loose coupling, where each service communicates via well-defined APIs (e.g., REST, gRPC) and does not share internal implementation details. This allows services to evolve independently without affecting others, which is a core principle of the architecture.

First deploy the app, then define and create the LoadBalancer service, retrieve the IP, and access it.

The Deployment controller, which runs as part of the kube-controller-manager, is responsible for reconciling the desired state of a Deployment. When you run 'kubectl scale deployment myapp --replicas=3', the Deployment controller detects the change in the Deployment's replica count and creates or deletes Pods via the ReplicaSet controller to match the desired 3 replicas.

The apiVersion 'extensions/v1beta1' for Deployments is deprecated and removed in newer Kubernetes versions. The correct apiVersion is 'apps/v1'.

Limits can be higher than requests, and if a container exceeds its memory limit, it may be OOMKilled. Limits cannot be lower than requests (Kubernetes enforces that limits >= requests). CPU limits are not always guaranteed; they are a hard cap for CPU time.

A Job resource is designed for batch processing tasks that run to completion and then terminate. It creates one or more Pods and ensures they successfully finish their work, making it the correct choice for a one-time data processing job.

kubectl set image updates the image of a container in a Deployment.

Helm provides templating for reusable configurations and allows for easy rollback to previous releases.

Terraform is a widely used IaC tool that allows declarative definition of infrastructure across multiple cloud providers.

Immutable infrastructure in Kubernetes means that instead of modifying running Pods or their containers (e.g., patching a binary or updating a config file in place), you replace the entire Pod with a new version. This is enforced by Kubernetes' declarative model: when you update a Deployment's Pod template, the controller creates new Pods with the new image and terminates the old ones. This ensures consistency, repeatability, and eliminates configuration drift, as every change results in a fresh, identical instance from the same image.

The OCI defines the image spec and runtime spec, ensuring interoperability between container tools. containerd is an OCI-compliant runtime. Docker images are OCI-compliant. Docker itself is not a runtime spec but a platform that uses runtimes.

A Job is the correct Kubernetes resource for a batch job that processes data and then terminates. Unlike controllers that maintain a desired state (like Deployments), a Job creates one or more Pods and ensures they run to successful completion. Once the specified number of Pods terminate successfully, the Job is considered complete and does not restart the Pods, making it ideal for one-off or finite processing tasks.

Kustomize's commonLabels field adds labels to all resources, including selectors.

A Service of type ClusterIP exposes the set of pods on a stable, internal IP address that is only reachable within the cluster. This is the default Service type and is specifically designed for internal cluster traffic, providing a stable virtual IP (VIP) that load-balances requests to the underlying pods.

Exit code 137 (128 + 9) indicates the container was killed by SIGKILL. In Kubernetes, this most commonly occurs when the container exceeds its memory limit, triggering the OOM (Out-Of-Memory) killer. The kubelet enforces the resource limits specified in the pod spec, and when memory usage surpasses the limit, the kernel terminates the process with SIGKILL, resulting in exit code 137.

kubectl scale changes the number of replicas in a Deployment, ReplicaSet, or similar resource.

etcd is a distributed key-value store that stores all cluster data. The API server is the only component that interacts with etcd directly.

Argo Rollouts supports progressive delivery with features like canary, blue-green, and integration with service mesh for traffic shifting, and can be combined with feature flag systems.

Lead time for changes measures the time from code commit to running in production.

Pending usually indicates that the scheduler cannot find a suitable node, often due to insufficient resources.

The Container Runtime Interface (CRI) is a plugin protocol that enables the kubelet to use any OCI-compliant container runtime (e.g., containerd, CRI-O) without needing to recompile Kubernetes. It defines gRPC APIs for runtime and image service operations, abstracting the runtime implementation from the kubelet's pod lifecycle management.

Progressive delivery reduces risk by gradual rollout and provides the ability to test new versions with a subset of users. It does not eliminate the need for monitoring nor does it replace CI/CD pipelines.

Context propagation allows trace context to be passed between services, enabling distributed tracing correlation.

Option B is correct. The kubelet is the primary node agent that communicates with the container runtime and ensures containers are running and healthy. kube-proxy manages network rules, the container runtime runs containers but is not directly responsible for enforcing the spec, and the scheduler assigns pods to nodes.

kubectl logs fetches the standard output and standard error logs from a container in a pod.

Argo CD is a declarative, GitOps continuous delivery tool specifically designed for Kubernetes that automatically synchronizes the live cluster state with the desired state defined in a Git repository. It continuously monitors the cluster and Git, applying any drift to ensure the cluster matches the repository, which is the core requirement of a GitOps workflow.

kubectl scale deployment my-deploy --replicas=5 is the direct command to change the replica count.

Container images are built in layers and can be stored in registries. They are not immutable once built (they can be overwritten), and they include only the application and dependencies, not a full OS kernel.

The kube-controller-manager is the component that runs controller processes, which are control loops that watch the shared state of the cluster through the API server and make changes to move the current state toward the desired state. It is responsible for ensuring that the cluster's actual state matches the desired state defined in Kubernetes objects such as Deployments, ReplicaSets, and StatefulSets.

The error 'address already in use' on port 8080 indicates that when the container restarts, the previous process is still holding the port. This typically happens when the application does not handle SIGTERM properly and does not shut down within the terminationGracePeriodSeconds (default 30s), so the old process lingers while the new one tries to bind to the same port, causing a CrashLoopBackOff.

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes API. It validates and processes RESTful requests (using JSON/YAML over HTTP/HTTPS) that create, update, or delete cluster resources, and it is the only component that communicates directly with etcd. Without the API server, no control plane operations can be performed.

Fluent Bit is a lightweight log processor and forwarder, often used as a DaemonSet to collect logs.

Factor III (Config) states that configuration should be stored in environment variables to decouple it from code.

When a pod is stuck in Terminating state, the most likely cause is that the node where the pod was running is unreachable or the kubelet is not responding. The kubelet is responsible for executing the pod's termination lifecycle, including sending SIGTERM and, after the grace period, SIGKILL. If the kubelet cannot communicate with the API server (e.g., due to node failure, network partition, or kubelet crash), the pod's finalizer cannot be removed, leaving it stuck in Terminating.

Immutable infrastructure means that servers or containers are never modified after deployment; any change requires replacing the resource with a new version.

Option D is correct because the CPU usage spikes to 90% during peak hours, indicating that the payment service pods are CPU-bound. Increasing CPU limits allows the pods to burst and utilize more CPU resources, reducing response times and preventing timeouts. This directly addresses the bottleneck without adding unnecessary replicas or changing memory settings.

Option A is correct because Namespaces in Kubernetes provide a mechanism for partitioning a single cluster into multiple virtual clusters, enabling resource quota management and access control for different users or teams. This allows administrators to divide cluster resources (like CPU, memory, and storage) among multiple users via ResourceQuotas and LimitRanges, without requiring separate physical clusters.

The CNCF fosters the adoption of cloud-native technologies by hosting and nurturing open-source projects like Kubernetes, Prometheus, and Envoy.

Scanning images in CI catches vulnerabilities before the image is deployed, preventing vulnerable images from reaching production.

Option C is correct because it uses a golden AMI built with Packer to create identical, immutable nodes that are reproducible via Auto Scaling groups and launch templates. This approach ensures that every EC2 instance launched has the exact same kernel parameters, packages, and configuration, eliminating configuration drift. Instance refresh allows rolling updates to the AMI without manual intervention, aligning with the goal of immutable infrastructure.

Option C is correct because a MutatingAdmissionWebhook intercepts Pod creation requests and automatically injects a sidecar container (e.g., Envoy or Linkerd-proxy) into the Pod spec. This is the standard mechanism used by service mesh control planes like Istio and Linkerd to transparently add the proxy without modifying application manifests.

The most likely cause is that Pods in other namespaces are using the short Service name (e.g., `my-service`) without appending the namespace suffix (e.g., `my-service.other-namespace.svc.cluster.local`). Kubernetes DNS resolves short names only within the same namespace; cross-namespace resolution requires the fully qualified domain name (FQDN) or at least the `<service>.<namespace>.svc` form. Without this, the DNS lookup fails, making the Service unreachable from other namespaces.

A Kubernetes Service provides a stable, virtual IP address and DNS name that acts as a consistent endpoint for accessing a set of pods, regardless of pod IP changes due to scaling, restarts, or scheduling. It decouples frontend clients from backend pods by using label selectors to route traffic, ensuring high availability and load balancing across the pod group.

kubelet is the primary node agent that ensures containers are running as expected in a pod.

A pod remains in 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is that the scheduler cannot find a node that meets the pod's resource requests (CPU/memory) or constraints (node selectors, affinity rules, taints/tolerations). Until a suitable node is found, the pod stays in Pending, waiting for scheduling.

The event broker (e.g., Apache Kafka, RabbitMQ, or AWS EventBridge) acts as an intermediary that receives events from producers and forwards them to consumers. By decoupling the two, the producer does not need to know the consumer's location or status, and the consumer does not need to be actively listening when the event is published. This enables asynchronous, scalable, and fault-tolerant communication in event-driven architectures.

Option B is correct because a Service of type ExternalName provides a DNS-based abstraction for external resources, mapping a Kubernetes service name to an external DNS name (the database hostname). This allows the pod to access the database via a stable in-cluster DNS name without needing to manage IP changes or network policies for external endpoints. It is the simplest and most Kubernetes-native way to expose a stable external IP to a pod.

Progressive delivery uses gradual rollout, feature flags, and analysis to reduce risk.