KCNA Kubernetes Fundamentals Practice Test 6 — 15 Questions

Question 1

Which kubectl command would you use to view the logs of a container named 'web' inside a Pod named 'app-12345'?

Accepted Answer

kubectl logs app-12345 -c web. `kubectl logs app-12345 -c web` explicitly specifies the container name 'web' within the Pod 'app-12345' using the `-c` flag. Option C is also correct because `--container=web` is the long-form equivalent of `-c`, and it is a standard syntax accepted by kubectl. Options B and D are incorrect due to wrong order and flag usage.

Answer

kubectl logs -p web app-12345

Answer

kubectl logs web app-12345

Question 2

Which of the following is true about Kubernetes Namespaces?

Accepted Answer

Namespaces allow you to divide cluster resources between multiple users. Kubernetes Namespaces provide a mechanism for partitioning a single cluster into multiple virtual clusters, enabling resource quota management and access control for different users or teams. This allows administrators to divide cluster resources (e.g., CPU, memory, storage) among multiple users via ResourceQuotas and Role-Based Access Control (RBAC), ensuring isolation of resource usage without requiring separate physical clusters.

Answer

Objects in different namespaces cannot communicate with each other

Answer

Namespaces are global across all clusters

Answer

Namespaces provide network isolation by default

Question 3

A production issue arises: a Deployment with 10 replicas is updated, but the new Pods are failing health checks and being terminated. The old Pods are also being terminated. What is the most likely cause?

Accepted Answer

maxSurge and maxUnavailable are set to values that allow termination of old Pods before new ones are ready. When maxSurge and maxUnavailable are set to values that allow termination of old Pods before new ones are ready, the RollingUpdate strategy can scale down old ReplicaSets even if the new Pods are failing health checks. This happens because maxUnavailable defines the maximum number of Pods that can be unavailable during the update, and if set to a value like 1 (or a percentage), the controller will terminate old Pods to meet that threshold, even if the new Pods are not yet healthy. The result is a cascading failure where both old and new Pods are terminated, leading to a service disruption.

Answer

The Deployment's 'paused' field is set to true

Answer

The Deployment's 'revisionHistoryLimit' is set to 1

Answer

The RollingUpdate strategy has maxSurge=0 and maxUnavailable=0

Question 4

You apply the following YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

But the Deployment never creates any Pods. Which field is missing or incorrect?

Accepted Answer

The field 'spec.selector' is missing, which is required for Deployment. The provided YAML is valid. The 'spec.selector' field is present and correctly matches the template labels. The 'replicas' is set to 3, not 0. 'containers' is spelled correctly, and 'apiVersion: apps/v1' is correct for Deployment. Therefore, none of the listed options describe a real issue, and the Deployment should create Pods as expected.

Answer

The 'replicas' field is set to 0

Answer

The 'containers' field is misspelled as 'container'

Answer

The 'apiVersion' should be 'v1'

Question 5

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?

Accepted Answer

my-svc.default.svc.cluster.local. The standard DNS naming convention for a Kubernetes Service is `..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.

Answer

my-svc.default.cluster.local

Answer

default.my-svc.svc.cluster.local

Answer

my-svc.svc.default.cluster.local

Question 6

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?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The 'OOMKilled' status indicates the pod's container was terminated by the Linux kernel Out-of-Memory (OOM) killer because it exceeded its configured memory limit. Since the pod ran successfully for days, this suggests a gradual memory leak or increased workload demand. Increasing the memory limit in the pod's container resource specification allows the container to use more memory before being killed, directly addressing the root cause.

Answer

Increase the CPU request for the container

Answer

Delete the namespace and redeploy all workloads

Answer

Delete and recreate the pod to clear the crash loop

Question 7

A user reports that their application's DNS resolution is failing for a Service named 'my-service' in the same namespace. They are able to reach the Service by its cluster IP. Which of the following is the most likely cause?

Accepted Answer

The CoreDNS pod is not running or misconfigured. DNS resolution for a Service in the same namespace relies on CoreDNS, which is the cluster DNS provider in Kubernetes. If CoreDNS is not running or misconfigured, DNS queries for the Service name (e.g., 'my-service') will fail, even though the Service is reachable via its cluster IP. The user's ability to reach the Service by IP confirms that kube-proxy and networking are functional, isolating the issue to DNS resolution.

Answer

The application container is using an incorrect DNS policy

Answer

The kube-proxy is misconfigured on the node

Answer

The Service is of type ExternalName

Question 8

You have a Deployment that uses a ConfigMap for configuration. You update the ConfigMap with new data. However, the pods in the Deployment continue to use the old configuration. What is the most likely reason?

Accepted Answer

The ConfigMap is mounted as a volume, and the pods have not been restarted. 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.

Answer

The ConfigMap data is immutable and cannot be updated

Answer

The ConfigMap is referenced by a different name in the pod spec

Answer

The Deployment's update strategy is set to Recreate

Question 9

Which THREE of the following are valid reasons to use a StatefulSet instead of a Deployment? (Select 3)

Accepted Answer

You need stable, unique network identifiers (e.g., pod hostnames) that persist across reschedules. Option B is correct because StatefulSets give each pod a stable, unique network identity via a headless Service, so pod hostnames like web-0, web-1, etc. remain consistent across rescheduling, which Deployments do not guarantee. Option C is correct because StatefulSets use volumeClaimTemplates to bind a distinct PersistentVolumeClaim to each pod, providing per-pod dedicated persistent storage rather than a shared volume. Option E is correct because StatefulSets provide ordered, graceful deployment and scaling (pod-0 is created and Ready before pod-1), plus ordered reverse termination, which Deployments do not enforce. Option A is not a valid reason, since a single instance can be run with a Deployment (replicas: 1) just as easily. Option D is not a valid reason, because stateless multi-replica web applications are exactly the workload Deployments are designed for, with no need for stable identities or per-pod storage.

Answer

You only need a single instance of the application

Answer

You need to deploy a stateless web application with multiple replicas

Question 10

What is the primary purpose of a Kubernetes Service?

Accepted Answer

To expose a set of pods as a network service with a stable endpoint. A Kubernetes Service provides a stable network endpoint (IP address and DNS name) to access a set of pods, which are ephemeral and can be rescheduled with different IPs. It acts as an abstraction layer, enabling load-balanced traffic to the pods via kube-proxy and iptables/IPVS rules. This is the core purpose of a Service, as defined in the Kubernetes API.

Answer

To provide persistent storage for pods

Answer

To store configuration data for pods

Answer

To manage rolling updates of applications

Question 11

You have a Deployment named 'frontend' with 3 replicas. You want to perform a rolling update to a new container image. Which command should you use?

Accepted Answer

kubectl set image deployment/frontend container1=nginx:1.20. 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.

Answer

kubectl replace deployment frontend --image=nginx:1.20

Answer

kubectl edit deployment frontend --image=nginx:1.20

Answer

kubectl update deployment frontend --image=v2

Question 12

A pod is stuck in 'Pending' state. Which of the following is the MOST likely cause?

Accepted Answer

There are no nodes with enough resources to run the pod. A pod remains in 'Pending' state when it cannot be scheduled onto a node. The most common reason is insufficient resources (CPU, memory, or ephemeral storage) on any available node to satisfy the pod's resource requests. The Kubernetes scheduler continuously evaluates node conditions and resource availability; if no node meets the pod's requirements, the pod stays unscheduled and pending.

Answer

The pod has been deleted

Answer

The container image is invalid

Answer

The pod's liveness probe is failing

Question 13

Which TWO of the following statements about Kubernetes namespaces are true?

Accepted Answer

Deleting a namespace will delete all objects in it. Option C is correct because deleting a namespace triggers cascading deletion of all resources contained within it, so every object scoped to that namespace is removed along with it. Option D is correct because ResourceQuota objects are applied at the namespace level, allowing administrators to cap aggregate CPU, memory, and object counts per namespace. Option A is false because Services in different namespaces can communicate via fully qualified DNS names such as service.namespace.svc.cluster.local. Option B is false because cluster-scoped objects like Nodes, PersistentVolumes, and ClusterRoles are not created in a namespace. Option E is misleading because namespaces alone do not divide resources; resource division is enforced through quotas and limit ranges, not by the namespace object itself.

Answer

Services in different namespaces cannot communicate with each other

Answer

Every Kubernetes object must be created in a namespace

Answer

Namespaces provide a way to divide cluster resources between multiple users

Question 14

What is the primary purpose of a Kubernetes Service?

Accepted Answer

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

Answer

To manage container image versions

Answer

To store configuration data as key-value pairs

Answer

To schedule pods onto nodes

Question 15

A Deployment named 'nginx' is failing to update. You run 'kubectl rollout status deployment nginx' and see 'Waiting for deployment "nginx" rollout to finish: 0 out of 3 new replicas have been updated...'. The pod template has an image that does not exist. What is the most likely cause?

Accepted Answer

The new image tag is incorrect or does not exist in the registry. The rollout status shows that no new replicas have been created, which is a classic symptom of a container image pull failure. When the image tag specified in the pod template does not exist in the registry, the kubelet cannot pull the image, so the ReplicaSet controller cannot start new pods. This prevents the rollout from progressing past 0 out of 3 new replicas.

Answer

The cluster is out of memory

Answer

The deployment has exceeded the revision history limit

Answer

The deployment is paused