Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 826–900

Option D is correct because deploying a Prometheus instance per tenant enforces strong tenant isolation by preventing cross-tenant metric access or resource contention, while Thanos provides a global view by aggregating metrics from all tenants via sidecar-based or query-frontend federation. This approach satisfies both isolation and aggregated dashboards without compromising security or scalability.

Namespaces provide a scope for resource names and can be used to divide cluster resources between multiple users.

The liveness probe is configured to check the /healthz endpoint, but the default nginx container does not serve a /healthz endpoint. This causes the liveness probe to fail, and Kubernetes restarts the container according to the probe's failure threshold. Since the container keeps restarting, it never reaches the Ready state, even though the container starts and runs initially.

Knative is a Kubernetes-based platform to build, deploy, and manage serverless workloads that can scale to zero. AWS Lambda is a proprietary offering, not CNCF. OpenFaaS and Kubeless are also serverless frameworks but Knative is the most prominent CNCF serverless project.

Terraform and Pulumi are popular IaC tools that allow infrastructure provisioning via code.

Namespaces provide logical isolation for resources. Option C is correct.

ConfigMaps, Secrets, and environment variables defined directly in the pod spec are all legitimate methods to inject configuration.

Knative Serving uses the 'Service' resource to manage serverless workloads. 'Deployment' is a lower-level resource, 'Function' is not a Kubernetes resource, and 'Pod' is too granular.

Resource constraints (insufficient CPU or memory) can prevent the scheduler from placing all pods. Other issues like image pull errors would result in different states.

A Deployment manages a ReplicaSet and provides declarative updates, rolling updates, and rollback capabilities, making it ideal for stateless applications.

Namespaces provide logical isolation and scoping for resource names. However, some resources like Nodes and PersistentVolumes are cluster-scoped and cannot be namespaced. Also, namespaces do not provide network isolation by default; NetworkPolicies do.

Option A is correct because Kubernetes NetworkPolicies are namespace-scoped resources that can restrict ingress and egress traffic between Pods in different Namespaces. By default, all Pods can communicate across Namespaces, but applying a NetworkPolicy with a podSelector and namespaceSelector allows you to enforce isolation. Option C is correct because Namespaces provide a logical boundary for resource names, preventing naming collisions when multiple teams or projects deploy objects with the same name within the same cluster.

Option C is correct because `kubectl create deployment` is the imperative command specifically designed to create a Deployment resource in Kubernetes. The `--image` flag specifies the container image, and `--replicas=3` sets the desired number of pod replicas, which matches the requirement exactly.

Knative is the correct answer because it is a CNCF project built on Kubernetes that provides a serverless platform specifically designed to scale workloads to zero when not in use. It achieves this through its Serving component, which automatically scales pods down to zero replicas based on traffic, and scales up from zero on the first request, enabling true serverless behavior.

Option A is correct because using an external secrets operator (e.g., AWS Secrets Manager, HashiCorp Vault) allows secrets to be injected directly into Pods at runtime without ever storing them in the Helm chart or as Kubernetes Secrets in plaintext. This approach leverages the Kubernetes CSI (Container Storage Interface) or a sidecar pattern to mount secrets from an external store, ensuring sensitive data never resides in the cluster's etcd or version control.

The control plane includes kube-apiserver, etcd, kube-scheduler, and kube-controller-manager. kubelet and kube-proxy are node components.

The Open Container Initiative (OCI) image specification defines a standard format for container images, ensuring that any OCI-compliant image can be run by any OCI-compliant runtime (e.g., runc, crun). This specification covers the image manifest, filesystem layers, and configuration, enabling interoperability across different container platforms like Docker, Podman, and containerd. Option A is correct because the OCI specifically standardizes both the image format and the runtime behavior, not higher-level orchestration or infrastructure concerns.

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

Option C is correct because Kubernetes DNS resolves services across namespaces using the format <service>.<namespace>.svc.cluster.local. Since the 'cache-svc' service is in the 'prod' namespace, the 'db' pod in the 'default' namespace must use 'cache-svc.prod.svc.cluster.local' to reach it. The default cluster domain is 'cluster.local', and the 'svc' subdomain is part of the standard DNS schema for services.

kubectl create configmap supports the --from-file flag to create a ConfigMap from a file. Option A uses an invalid flag; option B has incorrect flag; option D uses --from-env-file which is for loading environment variables from a file, but the question asks for a ConfigMap from a file generally.

etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data.

Config is a core principle of the 12-factor app methodology, which mandates strict separation of configuration from code. Configuration (such as database URLs, credentials, or hostnames) must be stored in environment variables, not hardcoded in the application source. This allows the same codebase to be deployed across different environments (development, staging, production) without modification, adhering to the principle of config-driven behavior.

Kubernetes is a container orchestration platform designed to automate deployment, scaling, and management of containerized applications.

An event broker acts as a central intermediary that receives events from producers, stores them durably (often in a log or queue), and delivers them to consumers asynchronously. This decouples producers and consumers, allowing them to operate independently without blocking or direct knowledge of each other. Technologies like Apache Kafka, RabbitMQ, or AWS Kinesis exemplify this role by persisting events and enabling replay, fan-out, and load-leveling.

The error 'exec: "app": executable file not found in $PATH' indicates that the container image does not contain the binary or script specified in the pod's command field (e.g., `command: ["app"]`). This typically happens when the image is built without the expected executable, the command path is incorrect, or the image tag points to a different version. The container fails to start because the runtime cannot locate the entrypoint.

The kube-controller-manager is a core control plane component that runs controller processes, including the node controller, which monitors node health by checking the NodeStatus and NodeLease objects. If a node becomes unreachable (e.g., the node controller fails to receive a heartbeat within the --node-monitor-grace-period, default 40 seconds), it marks the node as Unhealthy and eventually taints it to trigger pod eviction. This makes option D correct because the node controller is a built-in controller within the kube-controller-manager.

Service mesh provides improved observability and enables traffic management features like canary deployments.

The deployment controller uses a readiness probe to determine if a pod is ready. If the probe fails, the pod is not marked as available, even if it is running.

Terraform is a cloud-agnostic IaC tool that supports multiple providers, enabling consistent management across clouds.

Option A is correct because kube-proxy is the component responsible for implementing the ClusterIP Service abstraction by managing iptables or IPVS rules on each node. If kube-proxy is not running, traffic destined for the Service's ClusterIP will not be forwarded to the backend pods, making the Service unreachable from within the cluster.

kubectl get pods -n team-a shows all pods in the namespace, regardless of status. The default output includes pods in any state. Option B ignores the namespace; option C shows pods from all namespaces; option D only shows pods with a specific label.

Option B is correct because setting `sessionAffinity: ClientIP` on a Kubernetes Service ensures that all requests from the same client IP are routed to the same Pod. This is the standard Kubernetes mechanism for implementing sticky sessions without requiring changes to the application or ingress layer.

When you scale a Deployment, the Deployment controller updates the replica count on the existing ReplicaSet that matches the pod template. The ReplicaSet controller then observes the desired count and creates the additional pods to reach the new target. This ensures that the Deployment's rollout history and rollback capabilities remain intact.

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes REST API. All administrative tasks, such as creating pods, scaling deployments, and querying cluster state, are performed by sending HTTP requests to this component. It validates and processes these requests before storing the resulting state in etcd.

ConfigMap is designed to hold non-sensitive configuration data that can be injected into containers as env vars or files.

DaemonSet ensures that a copy of a pod runs on each node (or a subset), which is ideal for daemons like log collectors.

The 'kubectl create deployment' command creates a Deployment, and '--expose' also creates a Service.

A is correct because a Kubernetes Service provides a stable virtual IP address and a DNS name (via CoreDNS) that remains constant even as the underlying Pods are created, destroyed, or scaled. This decouples clients from the ephemeral nature of Pod IPs, ensuring reliable connectivity.

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

The principle of loose coupling ensures that each microservice can be developed, deployed, and scaled independently by minimizing dependencies between services. In Kubernetes, this is achieved through well-defined APIs and service boundaries, allowing teams to update or scale one service without affecting others. This directly supports the team's goal of independent lifecycle management for each microservice.

Option C is correct because nodeSelector is the simplest and most direct way to constrain a Pod to run only on nodes that have a specific label, such as 'disktype=ssd'. When you add a nodeSelector field to the Pod spec, the kube-scheduler filters nodes that do not have the matching label, ensuring the Pod lands on a node with an SSD.

These are fundamental Kubernetes objects with distinct roles.

Event-driven architecture is based on producing, detecting, and reacting to events, with loose coupling between components and asynchronous communication.

Option D is correct because a monorepo with a directory per environment and overlays (e.g., using Kustomize or Helm) allows you to manage environment-specific differences declaratively while keeping a single source of truth. Argo CD can sync each environment's directory to its respective cluster, and overlays minimize duplication by applying only the necessary patches (e.g., replica counts, ingress hosts) on top of a common base. This approach aligns with GitOps best practices for multi-environment deployments.

nodeSelector is a simple field in the pod spec that schedules the pod onto nodes with matching labels.

Docker Compose is designed for single-host container orchestration with a simple YAML file, while Kubernetes is a multi-host container orchestration platform with advanced features like auto-scaling and self-healing.

The service reports no endpoints because the readiness probe is failing. A readiness probe determines whether a pod should receive traffic; if it does not return a 200 OK on the configured path (/ready), the pod is removed from the service’s endpoint list. Since the pods are running (liveness probe passes), the most likely cause is that the /ready endpoint is not serving a successful response.

CRI is a plugin interface that enables kubelet to use different container runtimes without recompiling. containerd and CRI-O are CRI-compliant runtimes. Docker was deprecated as a Kubernetes runtime and is not CRI-native; it uses dockershim.

Node affinity allows you to constrain which nodes a pod can be scheduled on based on node labels, such as labeling nodes with 'gpu: true' and using requiredDuringSchedulingIgnoredDuringExecution.

etcd is a distributed key-value store that stores all cluster state. It is part of the control plane and should be backed up.

A Kubernetes Job is designed specifically for batch processing tasks that need to run to completion exactly once. It creates one or more Pods and ensures that a specified number of them successfully terminate, making it ideal for workloads like data processing or backups that must finish without retries or restarts.

ConfigMap is for non-sensitive configuration, Secret is for sensitive data like passwords.

The 'kubectl scale' command changes the desired replica count, and the Deployment controller creates additional pods to match.

A Pod is the smallest and simplest Kubernetes object, representing a group of one or more containers with shared storage/network.

OCI defines standards for container images and runtimes to ensure interoperability.

Deployment is a stable resource since Kubernetes 1.9, and the correct API version is apps/v1.

The API gateway acts as a reverse proxy and routes requests to the correct backend service.

The 12-factor app includes 'Config' (store config in environment variables) and 'Disposability' (start fast and shut down gracefully). 'Monolithic architecture' is not a principle; 12-factor encourages microservices. 'Stateful sessions' are discouraged; apps should be stateless. 'Manual deployment' is not a principle; CI/CD is recommended.

Option C is correct because the scheduler event explicitly states '3 nodes had insufficient memory', which directly indicates that the pod's resource requests (specifically memory) exceed the available allocatable memory on those three nodes. The fourth node is unavailable due to taints, leaving zero schedulable nodes, hence the 'Pending' state.

The `kubectl apply` command uses a declarative approach to manage Kubernetes resources. It sends a PATCH request to the API server, which compares the desired state in the provided manifest (YAML/JSON) with the current state of the resource in the cluster. If the resource does not exist, it creates it; if it does exist, it updates only the fields specified in the manifest, preserving any fields not mentioned.

Service mesh focuses on internal service-to-service communication within the cluster, while API gateway handles external traffic entering the cluster (north-south traffic). Both can perform traffic management, but their scopes differ.

Option B is correct because `kubectl describe service <service-name>` displays the service's selector field under the 'Selector' section, allowing you to directly compare it with the Pod's labels. This is the most straightforward way to verify if the selector matches the Pod labels, which is essential for traffic routing.

Option A is correct because Kubernetes Namespaces are a mechanism to partition a single cluster into virtual sub-clusters, enabling multi-tenancy by isolating resources (e.g., Pods, Services) and controlling access via RBAC. This allows different users or teams to work in separate scopes within the same cluster, preventing naming conflicts and enabling resource governance.

Option C is correct because nodeSelector is the built-in Kubernetes mechanism for constraining a pod to nodes with specific labels. By labeling a node with disktype=ssd and adding that same label selector to the pod spec, the scheduler will only place the pod on nodes that have that label, ensuring it lands on SSD-equipped nodes.

Immutable infrastructure means that once a server or container is deployed, it is never modified in place. Instead, any change requires building a new image and redeploying. Option D describes exactly this: rebuilding from a pre-baked image and replacing the old server, which is the core pattern of immutability in container orchestration (e.g., Kubernetes rolling updates or Recreate deployments).

FaaS (Function-as-a-Service) platforms like AWS Lambda are event-driven and can scale to zero when idle, making them ideal for sporadic event-triggered workloads.

The kube-controller-manager runs controllers that handle node lifecycle (Node Controller) and ensure the correct number of pods are running (Replication Controller).

A pod enters the 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is insufficient cluster resources (CPU, memory, or ephemeral storage) on any available node to satisfy the pod's resource requests. The Kubernetes scheduler continuously evaluates node resource availability and will leave the pod in Pending until a suitable node is found or the request times out.

A service mesh provides observability, traffic management, and security (mTLS) without changing application code. It does not reduce the number of microservices, replace Kubernetes, or provide storage.

The Application Controller in ArgoCD is the component that continuously monitors the Git repository and compares the desired state (in Git) with the live state (in the cluster). It triggers sync operations when differences are detected.

Secrets are designed to store sensitive data, such as passwords, and can be exposed to Pods via environment variables or volumes.

kubectl describe pod provides detailed information including events. kubectl get pod -o yaml outputs YAML, but describe is the standard command for detailed info.