CKA Practice Test 24 — 15 Questions

Question 1

Which kubeconfig context field defines the set of users, clusters, and namespaces for kubectl operations?

Accepted Answer

contexts. The `contexts` field in a kubeconfig file defines a named context that bundles together a specific cluster, user, and default namespace. When you run `kubectl` commands, the current context determines which cluster to authenticate against, which user credentials to use, and which namespace to operate in by default. This is why option A is correct.

Answer

namespaces

Answer

clusters

Answer

users

Question 2

A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?

Accepted Answer

db-service.backend.svc.cluster.local. Kubernetes DNS resolves services using the format `..svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).

Answer

db-service.svc.cluster.local

Answer

db-service

Answer

db-service.backend.cluster.local

Question 3

An administrator needs to expand an existing PersistentVolumeClaim. Which TWO conditions must be met?

Accepted Answer

The StorageClass used by the PVC must have 'allowVolumeExpansion: true'.. The StorageClass must have `allowVolumeExpansion: true` to permit resizing of a PersistentVolumeClaim. This field is a prerequisite in the StorageClass definition; without it, the PVC cannot be expanded even if the underlying volume supports resizing. The CKA exam expects you to know that volume expansion is gated by this StorageClass setting.

Answer

The PVC must be currently mounted by at least one pod.

Answer

The underlying PersistentVolume must be deleted first.

Answer

The PersistentVolume's reclaim policy must be Recycle.

Question 4

A StorageClass named 'fast-ssd' uses the provisioner 'kubernetes.io/gce-pd' and has volumeBindingMode: WaitForFirstConsumer. A PVC 'my-pvc' requests 100Gi storage from this StorageClass. A pod using the PVC is scheduled to a node in zone 'us-central1-a'. When is the PV provisioned?

Accepted Answer

When the pod is scheduled to a node. The StorageClass 'fast-ssd' has volumeBindingMode set to WaitForFirstConsumer. This mode delays volume binding and provisioning until a pod using the PVC is scheduled to a node. When the pod is scheduled to a node in zone 'us-central1-a', the scheduler triggers the provisioning of a PV in that specific zone, ensuring the volume is created in the same zone as the pod.

Answer

Immediately when the PVC is created

Answer

When the pod starts running

Answer

The PV is never provisioned automatically; it must be pre-created

Question 5

Which command initializes a Kubernetes control plane node using kubeadm?

Accepted Answer

kubeadm init. `kubeadm init` is the specific command used to bootstrap and initialize a Kubernetes control plane node. It performs pre-flight checks, generates certificates, creates the static Pod manifests for core control plane components (API server, controller manager, scheduler, etcd), and configures the admin kubeconfig file. This is the standard kubeadm workflow for setting up a new cluster.

Answer

kubeadm create

Answer

kubeadm setup

Answer

kubeadm start

Question 6

What is the default DNS name for a Service named 'my-svc' in namespace 'my-ns'?

Accepted Answer

my-svc.my-ns.svc.cluster.local. Kubernetes constructs the default DNS name for a Service using the format `..svc.cluster.local`. This is defined by the cluster DNS specification (CoreDNS or kube-dns) and allows Pods to resolve the Service by its fully qualified domain name (FQDN) within the cluster. For 'my-svc' in namespace 'my-ns', the FQDN is 'my-svc.my-ns.svc.cluster.local'.

Answer

my-svc.svc.cluster.local

Answer

my-svc.my-ns.cluster.local

Answer

my-svc.cluster.local

Question 7

Which command retrieves logs from a container that has crashed and restarted?

Accepted Answer

kubectl logs pod-name --previous. B is correct because the `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container that has crashed and restarted. When a container restarts, its logs are preserved for the terminated instance, and this flag allows you to access those logs to debug the crash. Without `--previous`, you would only see logs from the currently running container.

Answer

kubectl describe pod pod-name

Answer

kubectl logs pod-name -c container-name

Answer

kubectl logs pod-name --tail=100

Question 8

Which TWO statements about Ingress in Kubernetes are correct?

Accepted Answer

Ingress can terminate TLS connections for backend Services.. Option B is correct because an Ingress resource can reference a TLS Secret via spec.tls, allowing the Ingress controller to terminate TLS connections and forward decrypted HTTP traffic to the backend Services. Option E is correct because Ingress rules use the host field to match the HTTP Host header and route requests to different backend Services accordingly. Option A is wrong because spec.ingressClassName selects which Ingress controller should handle the resource; it does not disable the default controller. Option C is wrong because gRPC support is not native to Ingress and typically requires controller-specific annotations or a Gateway API/HTTPRoute setup. Option D is wrong because Ingress operates at Layer 7 (HTTP/HTTPS), while Layer 4 TCP/UDP load balancing requires a Service of type LoadBalancer or a Gateway API TCPRoute.

Answer

Setting spec.ingressClassName to 'nginx' disables the default Ingress controller.

Answer

Ingress natively supports gRPC services without any additional configuration.

Answer

Ingress can provide Layer 4 (TCP/UDP) load balancing.

Question 9

Which TWO of the following are valid ways to expose a Service externally in a Kubernetes cluster running on-premises (no cloud provider)?

Accepted Answer

NodePort. NodePort (B) is correct because it exposes a Service on each node's IP at a static port in the 30000-32767 range, which works on any on-premises cluster without a cloud provider's load-balancer integration. Ingress (C) is correct because an Ingress resource plus an Ingress controller (e.g., NGINX, Traefik) provides HTTP/HTTPS routing from outside the cluster to internal Services, and it functions on-premises as long as the controller is deployed and reachable. LoadBalancer (A) is not valid here because it relies on a cloud provider's load-balancer implementation (or a bare-metal solution like MetalLB) to allocate an external IP, which is absent in a plain on-premises cluster. ClusterIP (D) only provides an internal virtual IP reachable within the cluster, so it does not expose the Service externally. ExternalName (E) merely returns a CNAME DNS record pointing to an external hostname and does not expose a Service running in the cluster.

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName

Question 10

Which TWO of the following are valid ways to inject a ConfigMap into a pod as environment variables? (Select 2)

Accepted Answer

Using env with valueFrom.configMapKeyRef. Option C is correct because the env.valueFrom.configMapKeyRef field lets you map a single specific key from a ConfigMap to one environment variable in the container spec. Option D is correct because envFrom.configMapRef imports all key/value pairs from a referenced ConfigMap as environment variables in the container, which is the bulk-injection mechanism. Option A is incorrect because volumeMounts mounts volumes into the filesystem and does not use configMapKeyRef, which is an env-source field, not a volume field. Option B is incorrect because the env list does not support a configMapRef field; the correct env-level reference is valueFrom.configMapKeyRef, while configMapRef belongs under envFrom. Option E is incorrect because volumes with configMap project ConfigMap data as files in a mounted volume, not as environment variables.

Answer

Using volumeMounts with configMapKeyRef

Answer

Using env with configMapRef

Answer

Using volumes with configMap

Question 11

Which THREE of the following are true about NetworkPolicy in Kubernetes? (Select 3)

Accepted Answer

NetworkPolicy supports both ingress and egress rules. Option B is correct because a NetworkPolicy spec can include both an ingress array and an egress array, allowing you to control inbound and outbound traffic for the selected pods (with policyTypes declaring which directions are enforced). Option C is correct because the podSelector within an ingress/egress rule can be combined with a namespaceSelector, and when both are used in the same peer element they match pods in the namespaces selected by namespaceSelector, enabling cross-namespace pod selection. Option E is correct because Kubernetes NetworkPolicy is additive and default-allow: if no NetworkPolicy selects a given pod, that pod is not isolated and all ingress and egress traffic is permitted. Option A is not correct because NetworkPolicy peers are defined by ipBlock CIDRs, podSelector, and namespaceSelector — not by DNS names. Option D is not correct because NetworkPolicy is a namespaced resource (it lives in a namespace and selects pods within that namespace, though rules can reference other namespaces).

Answer

NetworkPolicy can define rules based on DNS names

Answer

NetworkPolicy is a cluster-scoped resource

Question 12

A developer needs to access the Kubernetes API from a pod using a ServiceAccount. Which of the following is the recommended way to mount the ServiceAccount token into a pod?

Accepted Answer

Use a projected service account token with a mount path.. The recommended way to mount a ServiceAccount token into a pod is by using a projected service account token volume. This approach, introduced in Kubernetes 1.20, provides a time-bound, audience-scoped, and automatically rotated token that is mounted as a file at a specified mount path, enhancing security over static secrets.

Answer

Use the downward API to inject the token as an environment variable.

Answer

Set the token in the pod spec using the 'serviceAccountToken' field.

Answer

Mount the secret directly using a volume.

Question 13

A pod is in Pending state. You run 'kubectl describe pod pending-pod' and see an event: '0/3 nodes are available: 3 Insufficient memory'. However, you believe there is enough memory across the cluster. What could be the issue?

Accepted Answer

The pod's memory request is higher than any node's allocatable memory. The '0/3 nodes are available: 3 Insufficient memory' event indicates that the scheduler could not place the pod because each node lacks enough allocatable memory to satisfy the pod's memory request. Even if the cluster has plenty of total memory, the scheduler evaluates each node individually against the pod's resource requests, not the cluster-wide sum. Therefore, if the pod's memory request exceeds the allocatable memory on every node, the pod will remain Pending.

Answer

The cluster is using a resource quota that is exhausted

Answer

The pod's memory limit is set too low

Answer

The nodes have taints that the pod does not tolerate

Question 14

A Deployment named 'web-app' has 5 replicas. You want to perform a rolling update with a maximum of 3 pods unavailable during the update and a maximum of 2 extra pods above the desired count. Which YAML snippet correctly sets the rolling update strategy?

Accepted Answer

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 3
      maxSurge: 2. The rolling update strategy specifies `maxUnavailable: 3` and `maxSurge: 2`. With 5 desired replicas, this allows up to 3 pods to be unavailable during the update (so at least 2 pods remain running) and up to 2 extra pods above the desired count (so a maximum of 7 pods total). This matches the requirement exactly.

Answer

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
      maxSurge: 3

Answer

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
      maxSurge: 2

Answer

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 3
      maxSurge: 3

Question 15

Which TWO of the following are valid ways to specify resource requests and limits for a container in a pod? (Select 2)

Accepted Answer

spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "1"
        memory: "1Gi". Options C and D are both correct. Option C uses the correct YAML structure with a `resources` block containing both `requests` and `limits`, and specifies CPU as a string (e.g., "500m") and memory as a string (e.g., "512Mi"). Option D is also valid because Kubernetes allows specifying only `limits` without `requests`; the request defaults to the limit if omitted. Both options conform to the Kubernetes API specification for resource management in Pod containers. Options A, B, and E contain invalid syntax: A uses CPU and memory directly under the container without a resources block; B uses the singular `resource` instead of the plural `resources`; E uses invalid units ('millicores' and 'MB').

Answer

spec:
  containers:
  - name: app
    cpu: 0.5
    memory: 512Mi

Answer

spec:
  containers:
  - name: app
    resource:
      request:
        cpu: 1
        memory: 1Gi
      limit:
        cpu: 2
        memory: 2Gi

Answer

spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: "500 millicores"
        memory: "512 MB"