75 of 436 questions · Page 4/6 · Kcna Kubernetes Fundamentals topic · Answers revealed
A Pod has two containers. You need to see the logs of the second container named 'sidecar'. Which kubectl command should you use?
-c specifies the container name.
Why this answer
When a pod has multiple containers, the -c flag specifies which container to get logs from.
A user wants to ensure that a Deployment undergoes a rolling update with zero downtime, and that new Pods are fully ready before old Pods are terminated. Which field in the Deployment spec controls this behavior?
These fields control how many Pods can be unavailable and how many can be created above the desired count during a rolling update.
Why this answer
Option B is correct because `spec.strategy.rollingUpdate.maxUnavailable` and `maxSurge` control how many Pods can be unavailable and how many can be created above the desired count during a rolling update. Setting `maxUnavailable=0` ensures no old Pods are terminated until new Pods are fully ready, achieving zero-downtime updates. `maxSurge` allows extra Pods to be created before old ones are removed, enabling a controlled rollout.
Exam trap
CNCF often tests the misconception that `minReadySeconds` controls the rolling update order, but it only affects the Pod's availability status after readiness, not the termination timing of old Pods.
How to eliminate wrong answers
Option A is wrong because `spec.minReadySeconds` defines the minimum time a Pod must be ready before it is considered available, but it does not control the order or parallelism of Pod termination during a rolling update. Option C is wrong because `spec.replicas` sets the desired number of Pod replicas but has no direct influence on the update strategy or the readiness check before terminating old Pods. Option D is wrong because `spec.template.spec.containers[].resources` defines CPU and memory requests/limits for containers, which affects scheduling but not the rolling update behavior or Pod readiness gating.
A company wants to ensure that a database pod runs on a node with SSD storage. How should this be achieved?
nodeSelector ensures the pod is scheduled only on nodes with the matching label.
Why this answer
Option A is correct because nodeSelector is a field in the Pod spec that constrains which nodes the Pod can be scheduled on, based on node labels. By labeling nodes with SSD storage as 'disk=ssd' and adding a nodeSelector with that label to the Pod, Kubernetes will only schedule the Pod on nodes that have the matching label, ensuring it runs on SSD storage.
Exam trap
Cisco often tests the distinction between scheduling constraints (nodeSelector/node affinity) and repulsion mechanisms (taints/tolerations), trapping candidates who confuse tolerations as a way to select nodes rather than as a way to bypass node restrictions.
How to eliminate wrong answers
Option B is wrong because resource requests for local SSD storage are not supported in the standard Kubernetes resource model; storage is requested via PersistentVolumeClaims, not as a compute resource in the Pod spec. Option C is wrong because pod anti-affinity is used to avoid co-locating Pods on the same node or topology, not to select nodes based on hardware characteristics like SSD storage. Option D is wrong because taints and tolerations are used to repel Pods from nodes unless they have a matching toleration, but they do not actively select nodes with specific hardware; a toleration would allow the Pod to run on non-SSD nodes if they are not tainted, and tainting all non-SSD nodes is impractical and does not guarantee scheduling on SSD nodes.
You notice that a newly created Pod remains in 'Pending' state. Which of the following is the MOST likely cause?
Scheduler cannot place the Pod, so it stays Pending.
Why this answer
The scheduler cannot find a node that satisfies the Pod's resource requirements (CPU/memory requests), node affinity, or taints/tolerations.
A Deployment named 'app-deploy' is configured with strategy type: RollingUpdate. You want to update the container image to a new version. What kubectl command should you use?
This directly updates the container image.
Why this answer
kubectl set image is the standard declarative command to update the container image in a Deployment.
Which THREE of the following are valid ways to expose a Service to external traffic? (Select exactly three.)
Ingress provides HTTP/HTTPS routing to services.
Why this answer
NodePort, LoadBalancer, and Ingress are methods to expose services externally. ClusterIP is internal only. ExternalName maps to an external DNS name but does not expose via external IP.
Which TWO of the following are true about Kubernetes Services? (Select 2)
Services use label selectors to target Pods.
Why this answer
Services provide a stable IP and DNS name, and they load balance traffic across Pods. Services are not used for stateful storage (use StatefulSet or PVC) and they do not manage Pod replicas (Deployment does).
What is the smallest deployable unit in Kubernetes?
A Pod is the smallest deployable unit in Kubernetes.
Why this answer
A Pod is the smallest and simplest Kubernetes object. It represents a single instance of a running process.
A pod is stuck in 'Pending' state. After running 'kubectl describe pod', you see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?
The scheduler reports insufficient CPU resources.
Why this answer
The pod requires more CPU than any node can allocate, so it remains pending.
Which of the following is the smallest deployable unit in Kubernetes?
A Pod is the smallest deployable unit that can be created and managed.
Why this answer
The Pod is the smallest deployable unit in Kubernetes because it represents a single instance of a running process in the cluster and encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. Containers are not directly scheduled onto Nodes; instead, Kubernetes always schedules and manages Pods, making the Pod the atomic unit of deployment.
Exam trap
CNCF often tests the misconception that a Container is the smallest unit because candidates come from Docker backgrounds, but Kubernetes abstracts containers into Pods as the fundamental scheduling and deployment atom.
How to eliminate wrong answers
Option A is wrong because a Container is not a standalone deployable unit in Kubernetes; containers are always wrapped inside a Pod and cannot be created or scheduled directly by the API server. Option B is wrong because a Node is a worker machine (physical or virtual) that hosts Pods, but it is not a deployable unit — you do not deploy a Node; you deploy Pods onto Nodes. Option D is wrong because a Deployment is a higher-level controller that manages the desired state and lifecycle of ReplicaSets and Pods, but it is not the smallest unit — it orchestrates Pods, which are the actual deployable entities.
Which control plane component is responsible for persisting the entire cluster state?
etcd is the distributed key-value store that stores all cluster data.
Why this answer
etcd is the key-value store that stores all cluster state data, including configuration, state, and metadata.
A team is designing a Kubernetes cluster for a production workload that requires high availability. They have three worker nodes in different availability zones. Which statement about scheduling Pods is correct?
Topology spread constraints explicitly spread Pods across zones for high availability.
Why this answer
Option D is correct because a Pod topology spread constraint with `topologyKey: topology.kubernetes.io/zone` explicitly instructs the scheduler to distribute Pods evenly across the specified failure domains (availability zones). This ensures that if one zone fails, the remaining zones still have running Pods, achieving high availability for the production workload.
Exam trap
Cisco often tests the distinction between mechanisms that merely allow placement (tolerations, nodeSelector) versus those that enforce distribution (topology spread constraints), leading candidates to confuse permission with active scheduling policy.
How to eliminate wrong answers
Option A is wrong because `nodeSelector` only matches Pods to nodes with specific labels, but it does not enforce distribution across zones; Pods could still be scheduled on a single zone if all matching nodes are there. Option B is wrong because tolerations allow Pods to be scheduled on tainted nodes (e.g., zone-specific taints), but they do not guarantee spread across zones; they merely permit scheduling on nodes that would otherwise repel the Pod. Option C is wrong because `podAntiAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` prevents Pods from being co-located on the same node (or topology), but it does not ensure balanced distribution across zones; it only avoids placing replicas together, which could still result in all replicas landing in one zone if only one zone has enough nodes.
Which TWO components run on every worker node in a Kubernetes cluster?
kubelet is the primary node agent that ensures containers are running in a Pod.
Why this answer
The kubelet is the primary node agent that runs on every worker node, responsible for managing pod lifecycle and ensuring containers are running as expected. kube-proxy runs on every node to handle network routing and load balancing for Kubernetes services, implementing rules via iptables or IPVS.
Exam trap
CNCF often tests the distinction between control plane components and worker node components, trapping candidates who assume that all core Kubernetes components (like kube-scheduler or etcd) run on every node.
Match each cloud native concept to its definition.
Drag a concept onto its matching description — or click a concept then click the description.
Lightweight, standalone executable package that includes everything needed
Architectural style that structures an app as a collection of loosely coupled services
Automated configuration, coordination, and management of containers
Approach where servers are never modified after deployment; replaced instead
Specifying the desired state, letting the system achieve and maintain it
Why these pairings
These are foundational cloud native principles and patterns.
Which component of the control plane is the only one that directly interacts with etcd?
The API server is the only component that directly reads and writes to etcd.
Why this answer
The kube-apiserver is the only component that communicates with etcd. All other components (scheduler, controller-manager) interact with etcd indirectly through the API server.
Which TWO of the following are valid uses of Kubernetes Namespaces? (Select 2)
NetworkPolicies can be applied within a namespace to control traffic between pods.
Why this answer
Option B is correct because Kubernetes NetworkPolicies are namespace-scoped resources that allow you to define ingress and egress traffic rules for pods within a specific namespace. By applying a NetworkPolicy to a namespace, you can isolate workloads from each other, controlling which pods can communicate based on labels and ports, which is a fundamental use of namespaces for security and segmentation.
Exam trap
CNCF often tests the misconception that namespaces can enforce resource limits directly, when in fact ResourceQuotas and LimitRanges are the mechanisms that operate within a namespace, not the namespace itself.
Which command is used to view detailed information about a specific pod, including events and conditions?
This command shows detailed information about a specific pod.
Why this answer
The 'kubectl describe pod' command provides detailed information about a pod, including its state, events, and conditions.
In a YAML manifest for a Deployment, which field defines the number of pod replicas?
spec.replicas is the correct field for setting the number of replicas.
Why this answer
In a Kubernetes Deployment manifest, the `spec.replicas` field is the correct place to define the desired number of pod replicas. This field is a top-level attribute under the Deployment's `spec` object, and the ReplicaSet controller uses this integer value to ensure the specified number of Pods are running at all times.
Exam trap
The trap here is that candidates confuse the `spec.replicas` field with `spec.template` or `metadata`, or incorrectly assume that replica count is nested under `strategy` or `template`, leading them to pick A, B, or D.
How to eliminate wrong answers
Option A is wrong because `spec.strategy.replicas` does not exist; the `strategy` field defines the update strategy (e.g., RollingUpdate or Recreate), not replica count. Option B is wrong because `metadata.replicas` is not a valid field; `metadata` contains labels, annotations, and the resource name, not replica configuration. Option D is wrong because `spec.template.replicas` is invalid; the `template` field describes the Pod template (e.g., containers, volumes) and does not include a replicas field.
You have a Deployment with the following rollout strategy: rollingUpdate: maxSurge: 1, maxUnavailable: 0. What behavior does this configuration enforce?
This strategy ensures at least desired replicas are always running.
Why this answer
Option D is correct because the rolling update strategy `maxSurge: 1, maxUnavailable: 0` ensures that during the rollout, one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees that the total number of available pods never drops below the desired count, achieving zero downtime. The `maxUnavailable: 0` setting prevents any pod from being taken down until a new one is ready, while `maxSurge: 1` allows one extra pod to be created temporarily.
Exam trap
The trap here is that candidates often confuse `maxSurge` and `maxUnavailable` with simple 'one-by-one' termination, failing to realize that `maxUnavailable: 0` forces the creation of a new pod before any old pod is removed, ensuring zero downtime.
How to eliminate wrong answers
Option A is wrong because terminating all old pods at once would violate `maxUnavailable: 0`, which explicitly prohibits any pods from being unavailable during the update. Option B is wrong because creating all new pods first would exceed the `maxSurge: 1` limit, which only allows one extra pod above the desired count, not a full parallel creation. Option C is wrong because terminating one old pod before creating a new one would temporarily reduce the available pod count below the desired replicas, violating `maxUnavailable: 0`; the correct behavior is to create a new pod first (surge) before terminating the old one.
You have a Service of type ClusterIP named 'my-svc' in the 'default' namespace. A Pod in the same cluster wants to reach this Service using DNS. What is the fully qualified domain name (FQDN) that resolves to the Service's cluster IP?
Correct format: <service>.<namespace>.svc.cluster.local.
Why this answer
Option A is correct because the standard DNS naming convention for a Kubernetes Service is `<service-name>.<namespace>.svc.cluster.local`. This FQDN resolves to the ClusterIP of the Service, allowing Pods to discover and communicate with the Service using DNS. The `svc` subdomain is a fixed part of the cluster domain, and `cluster.local` is the default cluster domain suffix.
Exam trap
The trap here is that candidates often forget the `svc` subdomain or mix up the order of service name and namespace, leading them to choose options that omit `svc` or reverse the components, which Cisco tests to see if you know the exact DNS format for Kubernetes Services.
How to eliminate wrong answers
Option B is wrong because it omits the required `svc` subdomain, which is part of the standard Kubernetes DNS schema; without `svc`, the DNS query will not match the Service record. Option C is wrong because it reverses the order of the service name and namespace, placing the namespace first, which does not follow the `<service>.<namespace>.svc.cluster.local` format. Option D is wrong because it places `svc` after the namespace instead of before it, and also incorrectly orders the components; the correct structure is `<service>.<namespace>.svc.cluster.local`.
You have a Service named 'my-svc' in namespace 'default'. A pod in namespace 'other' tries to reach it using the DNS name 'my-svc'. What is the correct DNS name for cross-namespace service discovery?
Why this answer
For cross-namespace service discovery, the DNS name is <service-name>.<namespace>.svc.cluster.local. So, to reach 'my-svc' in namespace 'default' from another namespace, the correct DNS name is 'my-svc.default.svc.cluster.local'. A shorter form 'my-svc.default' also works.
Which Kubernetes object is used to store non-sensitive configuration data that can be consumed by pods?
ConfigMaps store non-sensitive configuration.
Why this answer
ConfigMap is used to store non-sensitive configuration data as key-value pairs or files.
A team uses a Deployment with 3 replicas and a RollingUpdate strategy. They update the container image. During the update, one of the new pods fails to start. What will happen by default?
The rolling update stops when a new pod fails, ensuring availability of old pods.
Why this answer
By default, a Deployment with a RollingUpdate strategy uses a `maxUnavailable` of 25% and a `maxSurge` of 25%. When a new pod fails to start (e.g., CrashLoopBackOff or ImagePullBackOff), the ReplicaSet controller will not create additional new pods beyond the surge limit, and the update will effectively pause because the new ReplicaSet cannot reach its desired replica count. The old ReplicaSet remains running with its existing pods, ensuring availability is maintained.
Exam trap
Cisco often tests the misconception that a failed pod in a rolling update triggers an automatic rollback or deletion, when in fact the default behavior is to pause the update and keep old replicas running until the issue is resolved manually.
How to eliminate wrong answers
Option B is wrong because the Deployment does not automatically roll back or delete old pods; it only pauses the rollout, leaving old replicas running. Option C is wrong because a failed pod does not trigger an automatic rollback to the previous image; rollback requires manual intervention or a specific `kubectl rollout undo` command. Option D is wrong because the failed pod is not simply terminated and not retried; the ReplicaSet controller will retry creating the pod indefinitely (with exponential backoff) until the image issue is resolved or the rollout is manually paused.
A user runs 'kubectl get pods -n default' but receives an error: 'Error from server (Forbidden): pods is forbidden: User cannot list resource pods in API group'. What is the most likely cause?
The Forbidden error indicates insufficient permissions.
Why this answer
This error indicates a lack of RBAC permissions for the user to list pods in the default namespace.
A ClusterIP Service named 'db-service' in namespace 'prod' selects pods with label 'app: database'. A pod in the same cluster needs to reach this service using DNS. What is the fully qualified domain name (FQDN) for the service?
This is the standard FQDN for a Service.
Why this answer
The DNS name for a Service is <service>.<namespace>.svc.cluster.local.
Which THREE of the following are valid ways to expose a Service to external traffic?
ExternalName maps the Service to an external DNS name.
Why this answer
Option A (ExternalName) is correct because it exposes a Service to external traffic by mapping the Service to an external DNS name (e.g., `my-service.default.svc.cluster.local` to `example.com`) via a CNAME record. This allows internal pods to reach an external service using a stable Kubernetes Service name, effectively exposing the Service to external traffic through DNS resolution.
Exam trap
CNCF often tests the misconception that Headless Services can be used for external exposure because they lack a cluster IP, but in reality they only provide DNS-based pod discovery and no external connectivity.
Which TWO statements about Kubernetes namespaces are true?
Correct; namespaces provide logical isolation.
Why this answer
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.
Exam trap
The trap here is that candidates confuse namespaces with network isolation, assuming that simply placing resources in different namespaces automatically blocks cross-namespace traffic, when in fact Kubernetes allows all pod-to-pod communication across namespaces by default and requires explicit NetworkPolicy rules to restrict it.
A developer wants to run a stateless web application with 5 replicas and ensure that when a new version is released, Pods are updated one by one with no downtime. Which Kubernetes resource is best suited?
Deployment manages replicas and supports rolling updates.
Why this answer
Deployment with a RollingUpdate strategy is ideal for stateless applications requiring zero-downtime updates.
Which TWO of the following are characteristics of a Kubernetes Pod?
Pods are the atomic unit of scheduling.
Why this answer
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.
Exam trap
CNCF often tests the misconception that Pods are long-lived or that they can only run a single container, confusing Pods with virtual machines or containers themselves, while the key exam point is that Pods are the smallest deployable unit and share network namespaces.
A team wants to deploy a stateful application that requires each pod to have a unique, stable network identity and persistent storage that persists across rescheduling. Which Kubernetes resource is most appropriate?
StatefulSet gives each pod a sticky identity and can manage persistent storage per pod.
Why this answer
StatefulSet provides stable network identities and persistent storage for stateful applications.
You run 'kubectl get pods' and see a pod with status 'Pending'. Which is the most likely cause?
Pending often means the scheduler is unable to place the pod due to resource constraints.
Why this answer
A Pending pod usually indicates scheduling issues, such as insufficient resources or node constraints.
A cluster administrator wants to ensure that a specific pod only runs on nodes that have an SSD for local storage. The nodes with SSDs have the label 'disk-type: ssd'. How should the administrator configure the pod to enforce this constraint?
nodeSelector is the simplest way to constrain a pod to nodes with specific labels.
Why this answer
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.
Exam trap
The trap here is that candidates confuse tolerations (for taints) with node selectors (for labels), or think annotations or probes can influence scheduling, when only `nodeSelector` or node affinity directly control node placement based on labels.
How to eliminate wrong answers
Option A is wrong because tolerations are used to allow Pods to run on nodes with taints, not to select nodes based on labels; a toleration for `node.kubernetes.io/disk-type: ssd` would be meaningless as this is not a well-known taint key. Option C is wrong because a readiness probe checks whether a container is ready to serve traffic, not the hardware characteristics of the node; it cannot enforce node selection. Option D is wrong because annotations are metadata for non-identifying information and are not used by the scheduler for node placement decisions.
A developer created a Deployment with image 'myapp:v1' and then ran 'kubectl set image deployment/myapp myapp=myapp:v2'. What is the effect of this command?
The command modifies the Deployment's container image, initiating a rolling update.
Why this answer
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.
Exam trap
CNCF often tests the distinction between updating a Deployment's pod template (which triggers a rolling update) versus directly restarting pods or modifying Services, leading candidates to mistakenly think the command affects Service selectors or creates a new Deployment.
How to eliminate wrong answers
Option A is wrong because `kubectl set image` only modifies the Deployment's pod template; it does not update Service selectors, which are used to route traffic to pods based on labels, not image versions. Option C is wrong because the command updates the existing Deployment's pod template in place, not creating a new Deployment; Kubernetes Deployments are versioned through their pod template changes, not by creating separate Deployment objects. Option D is wrong because the command does not immediately restart all pods; it updates the desired state in the Deployment's pod template, and the Deployment controller performs a rolling update according to the `strategy` field (defaulting to RollingUpdate), which gradually replaces pods rather than restarting them all at once.
Which Kubernetes component is responsible for maintaining the desired state of the cluster by running controller loops?
The kube-controller-manager runs controller processes that reconcile the actual state with the desired state.
Why this answer
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.
Exam trap
CNCF often tests the misconception that the API server (kube-apiserver) is responsible for maintaining desired state because it is the central hub, but the API server only serves the API and stores state in etcd, while the actual reconciliation is done by the controller-manager's loops.
How to eliminate wrong answers
Option B (etcd) is wrong because etcd is a distributed key-value store used for cluster data persistence, not for running controller loops; it stores the desired and current state but does not reconcile them. Option C (kube-apiserver) is wrong because the API server is the front-end for the Kubernetes control plane that validates and processes RESTful requests, but it does not execute controller logic or maintain desired state through loops. Option D (kube-scheduler) is wrong because the scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for running controller loops to maintain desired state.
A developer creates a Deployment with the following YAML snippet: ```yaml apiVersion: apps/v1 kind: Deployment spec: replicas: 3 selector: matchLabels: app: frontend template: metadata: labels: app: frontend spec: containers: - name: nginx image: nginx:1.21 ``` What will happen if the label 'app: frontend' is omitted from the pod template's metadata?
Kubernetes requires the pod template's labels to match the selector; otherwise, the API rejects the deployment.
Why this answer
The Deployment's selector requires that the pod template has matching labels. Without them, the Deployment will fail validation or not manage any pods.
Which Kubernetes object is used to logically isolate resources within a cluster, such as for separating environments like dev and prod?
Namespaces partition the cluster into virtual sub-clusters.
Why this answer
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.
Exam trap
The trap here is that candidates often confuse Namespaces with other cluster-scoped or resource-limiting objects, mistakenly thinking a ClusterRole or ResourceQuota can provide logical isolation, when in fact Namespaces are the fundamental building block for environment separation.
How to eliminate wrong answers
Option A is wrong because a ClusterRole is a cluster-scoped RBAC object that defines permissions across the entire cluster, not a mechanism for isolating resources or environments. Option B is wrong because a ResourceQuota is an object that sets hard limits on resource consumption (e.g., CPU, memory) within a specific Namespace, but it does not itself create logical isolation or separate environments. Option C is wrong because a Node is a worker machine (physical or virtual) that runs Pods; it is a compute resource, not an object for logically separating environments within a cluster.
Which THREE of the following are valid ways to assign a pod to a specific node? (Choose three.)
Directly assigns the pod to a node.
Why this answer
nodeName, nodeSelector, and node affinity are all mechanisms to schedule pods on specific nodes.
A Deployment has a strategy of RollingUpdate with maxSurge=1 and maxUnavailable=0. The Deployment manages 3 replicas. The image is updated. What happens during the update?
This matches the rolling update behavior with maxSurge=1 and maxUnavailable=0.
Why this answer
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.
What is the purpose of a Kubernetes Service?
Services abstract access to pods and provide load balancing.
Why this answer
A Service provides a stable IP address and DNS name to access a set of pods, enabling load balancing and service discovery.
What is the smallest deployable unit in Kubernetes?
A Pod represents a single instance of a running process.
Why this answer
A Pod is the smallest and simplest unit in the Kubernetes object model.
Which THREE of the following are valid attributes in a Kubernetes Pod specification? (Select 3)
The 'volumes' field defines storage volumes that can be mounted by containers.
Why this answer
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.
Which TWO of the following are valid reasons that a PersistentVolumeClaim (PVC) may remain in 'Pending' state?
If there is no available PV that satisfies the PVC's spec, the PVC will remain Pending until a matching PV is created.
Why this answer
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.
A user reports that they can access a service by its ClusterIP but not by its DNS name from within the cluster. What is the most likely cause?
CoreDNS provides DNS resolution for services; if it's down, DNS names will not resolve.
Why this answer
CoreDNS is the cluster DNS component; if it is not running or misconfigured, DNS name resolution fails while direct IP access works.
A developer deploys a CronJob that runs a batch job every 5 minutes. After a while, they notice that the job fails with 'DeadlineExceeded' and the pod is stuck in 'PodInitializing' state. What is the most likely reason?
A stuck InitContainer prevents the main container from starting, causing the pod to remain in PodInitializing. If the job's activeDeadlineSeconds passes, the job is terminated with DeadlineExceeded.
Why this answer
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.
Exam trap
CNCF often tests the distinction between 'PodInitializing' (caused by InitContainers or image pull issues) and 'ContainerCreating' (caused by container runtime or volume mount problems), leading candidates to incorrectly blame the container runtime or schedule misconfiguration.
How to eliminate wrong answers
Option B is wrong because a misconfigured CronJob schedule (e.g., wrong cron expression) would cause the job to run at incorrect times or not at all, but it would not cause a pod to be stuck in 'PodInitializing' with a 'DeadlineExceeded' error. Option C is wrong because if the container runtime were not installed on the node, the pod would likely remain in 'Pending' state (with an event like 'FailedCreatePodSandBox') rather than reaching 'PodInitializing', and the kubelet would report a runtime error. Option D is wrong because a low backoffLimit affects the number of retries after a job fails (e.g., if the main container exits with non-zero), but it does not cause a pod to be stuck in 'PodInitializing'; the 'DeadlineExceeded' error here is about the pod's active deadline, not the retry limit.
Which component runs on every worker node and ensures that containers are running in a Pod as specified in the Pod manifest?
The kubelet communicates with the API server and ensures containers are healthy.
Why this answer
The kubelet is the agent that runs on each node and manages the lifecycle of containers based on PodSpecs.
A developer creates a Service of type ClusterIP in namespace 'default'. They attempt to reach the Service from another pod in the same namespace using the Service name 'my-svc'. The connection fails. What is the most likely cause?
DNS is required for Service name resolution.
Why this answer
ClusterIP Services are only accessible within the cluster via DNS. If DNS resolution is not working, the pod cannot resolve the Service name.
A developer creates a Deployment with 'replicas: 3'. After applying the manifest, only 2 pods are running. Which command would help identify why the third pod was not created?
This command shows deployment events and status that reveal issues.
Why this answer
'kubectl describe deployment' shows events and status conditions that explain why a pod might not have been created.
A pod is in CrashLoopBackOff state. 'kubectl logs pod' shows 'Error: cannot connect to database at db-service:5432'. The database Service exists and is reachable from other pods. What is the most likely cause?
Why this answer
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.
Which command would you use to view the current state of all Pods in the default namespace?
This retrieves and displays the list of Pods.
Why this answer
The 'kubectl get pods' command lists Pods in the current namespace (default if not specified).
Which TWO of the following are true about Kubernetes Pods?
Pods are the smallest and simplest Kubernetes object.
Why this answer
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.
Exam trap
The trap here is that candidates confuse the Pod's ability to run multiple containers with the requirement to run exactly one, or they mistakenly think the scheduler creates Pods instead of only assigning them to nodes.
Which THREE of the following are valid reasons to use a StatefulSet instead of a Deployment? (Select 3)
StatefulSet Pods have ordinal hostnames and stable network IDs.
Why this answer
StatefulSets are designed for stateful applications requiring stable network identities, persistent storage per Pod, and ordered deployment/termination.
A pod has both resource requests and limits defined. The container is using more CPU than the request but less than the limit. What will happen?
CPU usage between request and limit is allowed; the container is guaranteed the request amount and can burst up to the limit.
Why this answer
CPU is a compressible resource; if usage is between request and limit, the container can burst and is not throttled or killed.
You deploy a new version of your application by updating the container image in the Deployment manifest. The rollout seems to be progressing, but after a few minutes you notice that the new Pods are failing and the old Pods are still running. What is the most likely reason?
If readiness probes fail, the new Pods are not considered ready, and the Deployment controller will not continue the rollout, preserving the old replicas.
Why this answer
Option B is correct. By default, Deployments perform a rolling update with a strategy that may include maxSurge and maxUnavailable settings. If the new Pods fail readiness probes, the rollout will stop, and old Pods are kept running.
Option A would cause an error on apply. Option C is not a direct cause. Option D would cause the new Pods to be unavailable for traffic but not necessarily prevent them from starting.
Which command would you use to view the logs of a container named 'nginx' in a Pod named 'web-pod'?
The -c flag specifies the container name when there are multiple containers.
Why this answer
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.
A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?
OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.
Why this answer
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.
Exam trap
The trap here is that candidates may confuse OOMKilled with a generic crash or resource issue and choose to delete/recreate the pod (Option A) or adjust CPU (Option D), rather than recognizing that the specific OOMKilled message points directly to a memory limit problem that must be addressed by increasing the memory limit.
How to eliminate wrong answers
Option A is wrong because deleting and recreating the pod does not resolve the underlying memory limit issue; the new pod would still have the same resource constraints and would likely be OOMKilled again. Option B is wrong because deleting the entire namespace and redeploying all workloads is an extreme, disruptive action that unnecessarily affects other workloads and does not target the specific pod's memory problem. Option D is wrong because increasing the CPU request does not affect memory allocation; the OOMKilled error is caused by memory exhaustion, not CPU starvation, so this change would not prevent the container from being killed.
You run 'kubectl get pods' and see a pod in 'Pending' state for over 5 minutes. You describe the pod and see '0/1 nodes are available: 1 Insufficient memory'. What is the most likely cause?
If the memory request exceeds the available memory on all nodes, the scheduler cannot place the pod, leaving it in Pending.
Why this answer
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.
Exam trap
CNCF often tests the distinction between resource requests (used for scheduling) and resource limits (used for throttling/eviction), so candidates mistakenly think a large image or probe failure causes Pending state, but the scheduler only cares about resource requests and node availability.
How to eliminate wrong answers
Option A is wrong because a large container image affects image pull time and disk space, not the scheduler's memory allocation decision; the scheduler only considers resource requests and limits, not image size. Option C is wrong because a failing liveness probe would cause the pod to be restarted or become CrashLoopBackOff, not remain in Pending state; liveness probes only run after the pod is scheduled and running. Option D is wrong because if the kubelet were not running, the node would show as NotReady or be absent from 'kubectl get nodes', and the scheduler would report a different error like '0/1 nodes are available: 1 node(s) had taint that the pod didn't tolerate' or 'node(s) were unschedulable'.
Which THREE of the following are core components of a Kubernetes worker node?
Container runtime runs containers.
Why this answer
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.
Exam trap
The trap here is that candidates often confuse control plane components (etcd, kube-apiserver) with worker node components, especially when they see them listed together in a question about cluster architecture.
Which Kubernetes component is the primary entry point for all administrative tasks and API requests?
It is the front-end for the Kubernetes control plane.
Why this answer
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.
Exam trap
CNCF often tests the misconception that etcd is the primary entry point because it stores all cluster data, but the trap is that etcd is never accessed directly by users or external tools — all interactions must go through the kube-apiserver, which acts as the single gateway for security and consistency.
How to eliminate wrong answers
Option A is wrong because the kube-controller-manager is a control loop that watches the shared state via the API server and makes changes to move the current state toward the desired state; it does not accept external API requests directly. Option B is wrong because etcd is a distributed key-value store used for cluster state persistence, not an API endpoint; all reads and writes to etcd go through the kube-apiserver. Option D is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, and it receives its instructions from the API server, not from external administrative requests.
Which Kubernetes component is responsible for storing the cluster state?
etcd stores all cluster state, including configurations and desired state.
Why this answer
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.
Exam trap
CNCF often tests the misconception that kube-apiserver stores the cluster state because it is the central API gateway, but the trap is that kube-apiserver only mediates access while etcd is the actual persistent storage layer.
How to eliminate wrong answers
Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for storing cluster state. Option B is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes API requests, but it does not store data; it reads from and writes to etcd. Option D is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state, but it does not persist state itself.
Which TWO of the following are valid ways to expose a set of pods to traffic from outside the Kubernetes cluster?
Why this answer
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.
Exam trap
CNCF often tests the distinction between Ingress (a routing layer) and Service types (the actual exposure mechanism), leading candidates to mistakenly select Ingress as a direct exposure method.
Which kubectl command is used to view detailed information about a Kubernetes resource?
describe provides detailed information.
Why this answer
The 'describe' command provides detailed information about a resource, including events, configuration, and status.
You create a Service of type NodePort with nodePort: 30080. The cluster's nodes have IP addresses 10.0.0.1 and 10.0.0.2. From outside the cluster, which address and port can you use to access the Service?
NodePort makes the service accessible on each node's IP at the nodePort.
Why this answer
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.
You need to ensure that a pod runs on a specific node that has an SSD. The node has the label 'disktype=ssd'. How should you configure the pod to target this node?
NodeSelector is the simplest way to constrain a pod to nodes with a specific label.
Why this answer
NodeSelector with matching label ensures the pod is scheduled on nodes with that label.
Which two components are part of the Kubernetes worker node? (Choose two.)
kube-proxy runs on each worker node and manages network rules.
Why this answer
Worker nodes run kubelet, kube-proxy, and container runtime. kube-apiserver and etcd are control plane components.
What is the primary purpose of a Kubernetes Service?
Services abstract access to pods with a stable IP and DNS name, and load-balance traffic.
Why this answer
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.
A team runs a stateless web application in Kubernetes. They have a Deployment named 'web-app' with 5 replicas. They want to ensure that a Service named 'web-svc' distributes traffic evenly to all healthy pods. Which type of Service should they use?
A ClusterIP Service exposes the application on a cluster-internal IP and load-balances across all pods in the backing set.
Why this answer
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.
Exam trap
The trap here is that candidates may think NodePort or Headless Service are needed for load balancing, but the question specifically asks for internal traffic distribution to pods, and ClusterIP is the default and correct Service type for that purpose, while Headless Service actually removes load balancing entirely.
How to eliminate wrong answers
Option B (Headless Service) is wrong because it does not provide a single virtual IP or load balancing; instead, it returns the IP addresses of all healthy pods via DNS, requiring the client to implement its own load balancing logic. Option C (ExternalName Service) is wrong because it maps the Service to an external DNS name (e.g., an external domain) and does not route traffic to any Kubernetes pods at all. Option D (NodePort) is wrong because it exposes the Service on a static port on each node's IP, which is used for external access and does not change the internal load balancing behavior (it still uses ClusterIP under the hood), but the question asks for the type that distributes traffic evenly to pods, and ClusterIP is the fundamental type for that purpose.
Which Kubernetes component is the primary entry point for all administrative tasks and exposes the REST API?
The API server is the entry point for all REST API calls.
Why this answer
The kube-apiserver is the front-end of the Kubernetes control plane, exposing the REST API that all other components and kubectl interact with.
You have a Deployment defined with replicas: 5. You run 'kubectl scale deployment myapp --replicas=3'. Which component is responsible for ensuring the actual number of Pods matches the desired 3?
The Deployment controller watches the Deployment and manages the ReplicaSet to achieve the desired number of replicas.
Why this answer
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.
Exam trap
CNCF often tests the misconception that kubelet or kube-scheduler handles scaling, when in fact kubelet only manages local Pod lifecycle and the scheduler only places Pods on nodes, while the Deployment controller in the kube-controller-manager is the component that reconciles replica counts.
How to eliminate wrong answers
Option A is wrong because etcd is a distributed key-value store that holds cluster state, but it does not perform reconciliation or enforce desired replica counts; it only stores the data that controllers read and write. Option C is wrong because kubelet is an agent that runs on each node and manages Pods on that node, but it does not scale Deployments or manage replica counts across the cluster. Option D is wrong because kube-scheduler is responsible for assigning Pods to nodes based on resource availability and constraints, not for ensuring the number of Pods matches a desired replica count.
You have a YAML manifest for a Deployment with 'apiVersion: extensions/v1beta1'. When you run 'kubectl apply -f manifest.yaml', you get an error. What is the most likely cause?
Deployments should use 'apps/v1'.
Why this answer
The apiVersion 'extensions/v1beta1' for Deployments is deprecated and removed in newer Kubernetes versions. The correct apiVersion is 'apps/v1'.
Which TWO of the following are true about Pod resource limits? (Select TWO)
CPU limits are enforced via Completely Fair Scheduler (CFS) quotas.
Why this answer
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.
You need to update a running Deployment to use a new container image. Which kubectl command should you use?
This command directly updates the image.
Why this answer
kubectl set image updates the image of a container in a Deployment.
You need to expose a set of pods running a web application to internal cluster traffic on a stable IP address. Which resource should you create?
Why this answer
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.
Exam trap
CNCF often tests the distinction between internal and external exposure, and the trap here is that candidates may confuse a Service of type ClusterIP with NodePort, thinking NodePort is needed for any stable IP, when ClusterIP is the correct choice for internal-only traffic.
How to eliminate wrong answers
Option A is wrong because a Service of type NodePort exposes the service on a static port on each node's IP address, making it accessible from outside the cluster, not just internally. Option B is wrong because an Ingress is an API object that manages external HTTP/HTTPS access to services, typically requiring a Service of type NodePort or LoadBalancer to route traffic, and does not itself provide a stable internal IP. Option C is wrong because a NetworkPolicy is a security resource that controls ingress and egress traffic to/from pods based on labels and ports, but it does not expose pods or provide a stable IP address.
A developer deploys a pod that continuously restarts. 'kubectl describe pod' shows the container exits with code 137. What is the most likely cause?
Exit code 137 indicates SIGKILL, often from OOM.
Why this answer
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.
Exam trap
Cisco often tests the distinction between exit codes and probe failures; the trap here is that candidates confuse exit code 137 with a liveness probe failure, but exit code 137 specifically points to a SIGKILL, not a probe timeout or command failure.
How to eliminate wrong answers
Option B is wrong because a failing liveness probe causes a container restart with exit code 137 only if the probe failure leads to a SIGKILL (which is not typical; liveness probe failures result in exit code 0 or 1 depending on the probe command, not 137). Option C is wrong because init container failures block the main container from starting, but they do not cause the main container to exit with code 137; the main container would never run. Option D is wrong because a namespace-level resource quota limit prevents pod creation or scheduling, not causing a running container to exit with code 137; quota enforcement happens at admission time, not during runtime.
Which component of the Kubernetes control plane is responsible for storing the cluster state?
etcd is the cluster state store.
Why this answer
etcd is a distributed key-value store that stores all cluster data. The API server is the only component that interacts with etcd directly.
A Pod is stuck in Pending state. Which of the following is the MOST likely cause?
Scheduler cannot place the Pod, so it remains Pending.
Why this answer
Pending usually indicates that the scheduler cannot find a suitable node, often due to insufficient resources.
Ready to test yourself?
Try a timed practice session using only Kcna Kubernetes Fundamentals questions.