CCNA Kcna Kubernetes Fundamentals Questions

Option A is correct because it uses the `configMapKeyRef` field under `valueFrom` to reference a specific key (`database.url`) from the ConfigMap named `app-config`. This is the standard Kubernetes syntax for injecting a single key from a ConfigMap as an environment variable into a Pod.

Services provide stable endpoints, load balance across pods, and support multiple types. They do not replace Ingress; Ingress provides HTTP routing. Services do not store configuration; ConfigMaps do.

kubelet is the primary node agent that interacts with the container runtime to ensure containers are healthy and running.

The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers described in Pod manifests (typically provided via the API server) are running and healthy. The kubelet does not manage containers directly; instead, it interacts with the container runtime (e.g., containerd, CRI-O) to create, start, and stop containers as specified.

A pod enters a Pending state when it cannot be scheduled onto a node. A `nodeSelector` constraint requires the node to have specific labels; if no node matches, the scheduler cannot place the pod, leaving it Pending. This is a common scheduling failure cause.

Option A is correct because it exposes the existing deployment named 'web' (which manages pods with label 'app: web') as a ClusterIP service, providing a stable internal IP and DNS name within the cluster. The `--port=80` sets the service port, and `--target-port=8080` maps to the container port, ensuring traffic reaches the pods correctly in the 'dev' namespace.

The Deployment YAML is syntactically correct and valid, but it will never create Pods because the `spec.selector` field is missing. In Kubernetes, a Deployment requires a `spec.selector` to identify which Pods it manages; without it, the Deployment controller cannot match the Pod template to a ReplicaSet, so no Pods are created. The provided YAML has `selector` under `spec`, but it is not the required `spec.selector` — the field is present but incorrectly placed or missing entirely in the context of the Deployment spec.

A Deployment manages ReplicaSets and provides declarative updates, including self-healing by recreating failed pods. A DaemonSet runs a pod on each node, a Job runs a batch task, and a StatefulSet is for stateful applications.

Option C is correct because the `kubectl logs` command uses the `-c` flag to specify a container name within a multi-container Pod. The correct syntax is `kubectl logs <pod-name> -c <container-name>`, which targets the 'app' container inside 'web-pod'.

kubelet is the primary node agent that ensures containers are running and healthy according to Pod specifications.

A Service provides a stable IP and DNS name, and distributes traffic across Pods matching its selector.

Kubernetes is a container orchestration platform that automates deployment, scaling, and management of containerized applications.

Option B is correct because the `kubectl logs` command requires the pod name as the first positional argument, and the `-c` flag specifies the container name when a pod has multiple containers. The `-n` flag sets the namespace. The correct syntax is `kubectl logs <pod-name> -c <container-name> -n <namespace>`, which matches option B exactly.

When a ConfigMap is mounted as a volume in a Pod, updates to the ConfigMap are automatically propagated to the mounted files, but the running process inside the container does not automatically reload the configuration. The Pod must be restarted (e.g., by rolling update or manual deletion) for the application to read the new values. This is the most common reason for stale configuration in a Deployment.

The Kubernetes control plane manages the cluster and makes global decisions. kube-apiserver is the front-end for the control plane, exposing the Kubernetes API for all interactions. etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data, making it a core control plane component.

A Job resource is designed for running a finite task to completion, such as a batch job or a one-time computation. Unlike controllers that maintain a desired number of replicas indefinitely, a Job creates one or more Pods and tracks their successful termination. Once the specified number of completions is reached, the Job is considered finished and no further Pods are created.

The kubelet is the primary node agent that runs on each worker node. It receives PodSpecs (via the API server or a file) and ensures that the containers described in those PodSpecs are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers as required.

kube-proxy runs on each node and handles network proxying and load balancing for Services.

The correct answer is B because a Deployment's default update strategy is 'RollingUpdate', which automatically replaces old Pods with new ones in a controlled manner, ensuring zero downtime by incrementally scaling down old replicas and scaling up new replicas. When you update the container image in the Deployment's pod template, Kubernetes triggers a rolling update that maintains the desired number of replicas throughout the process.

The correct approach is to update the Deployment's pod template (e.g., spec.template.spec.containers[0].image) and apply the change. The Deployment controller then performs a rolling update by gradually replacing pods with the new image.

Option B is correct because `kubectl get -o wide` is a valid output format that displays additional details such as node names and internal IPs for pods, or cluster IPs and ports for services, beyond the default summary columns. This is a standard kubectl output flag for human-readable extended output.

Ingress is correct because it provides HTTP/HTTPS-based external access to services using host-based or path-based routing rules, typically via an Ingress controller (e.g., NGINX, Traefik). It exposes a service externally by defining rules that map external traffic to internal ClusterIP services, making it a valid method for external exposure.

Option C is correct because a taint on a node causes the scheduler to avoid placing pods on that node unless the pod explicitly tolerates the taint. By adding a toleration in the pod spec that matches the taint key, effect, and optionally the value, the pod becomes eligible to be scheduled on the tainted node. This is the standard Kubernetes mechanism for allowing pods to run on control-plane or other specially tainted nodes.

kubectl set image deployment/<name> <container>=<image> --record records the command in the rollout history.

Service DNS names are scoped to namespaces. To access a service in another namespace, you must use the fully qualified name: <service>.<namespace>.svc.cluster.local.

A LoadBalancer Service type provisions an external cloud load balancer (e.g., AWS ELB, GCP TCP/UDP Load Balancer) that exposes the application on a fixed port (typically 80/443) and distributes traffic to the Pods. This is the correct choice because the requirement explicitly asks for a cloud load balancer with a fixed external port, which is exactly what LoadBalancer provides by integrating with the underlying cloud provider's API.

kube-proxy runs on each node and implements network rules (e.g., iptables, IPVS) to manage service-to-pod communication.

kubectl logs <pod-name> fetches logs from the container(s) in the pod.

ClusterIP, NodePort, and LoadBalancer are standard Service types. ExternalName is also valid, but InternalIP is not a Service type.

Option C is correct because kube-proxy is the component responsible for implementing network rules on each worker node, enabling service abstraction by managing IP tables or IPVS rules to route traffic to the appropriate pods. It handles service discovery and load balancing for ClusterIP, NodePort, and LoadBalancer service types, ensuring that traffic destined for a service is correctly forwarded to healthy pod endpoints.

A Service is the correct Kubernetes resource because it provides a stable virtual IP (ClusterIP) and DNS name that persists independently of pod lifecycles, enabling reliable service discovery and client-side load balancing across a set of pods selected by labels. This abstraction decouples clients from ephemeral pod IPs, ensuring traffic is routed to healthy pods via kube-proxy and iptables/IPVS rules.

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.

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.

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.

kubectl get pods and kubectl describe pod are standard commands.

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

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

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

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 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.

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.

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.

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.

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.

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 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.

Option B is correct because the recommended approach to update a Deployment's application image is to modify the pod template in the Deployment specification. The Deployment controller then automatically performs a rolling update, creating a new ReplicaSet with the updated image and gradually scaling down the old ReplicaSet, ensuring zero-downtime updates and maintaining desired replica count.

etcd is a distributed key-value store that holds all cluster data, including configuration, state, and metadata.

Option B is correct because a Pod is the smallest and most basic deployable unit in Kubernetes, representing a single instance of a running process in the cluster. Pods encapsulate one or more containers, storage resources, and a unique network IP, and they are the atomic unit for scheduling, scaling, and lifecycle management.

If minReadySeconds or maxSurge/maxUnavailable are set incorrectly, the rollout can progress despite failures. The most common cause is that the Deployment's 'progressDeadlineSeconds' may be exceeded, but the question implies both old and new are being terminated. The correct answer is that maxSurge and maxUnavailable are misconfigured, causing the rollout to continue even when new Pods are unhealthy.