CKA Practice Test 5 — 25 Questions

Question 1

Which Kubernetes Service type exposes the Service on a static port on each Node's IP address, allowing external access without a LoadBalancer?

Accepted Answer

NodePort. A NodePort Service exposes the Service on a static port (in the range 30000-32767) on every Node's IP address. This allows external traffic to reach the Service by targeting any cluster node's IP and the assigned NodePort, without requiring a cloud LoadBalancer. The kube-proxy component on each node creates iptables or IPVS rules to forward traffic from that port to the corresponding ClusterIP Service and then to the selected Pods.

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName

Question 2

You need to expose a service named 'my-svc' on a static port 30080 on every node. Which service type should you use?

Accepted Answer

NodePort. NodePort is the correct service type because it exposes the service on a static port (30080) on every node's IP address. When you create a NodePort service, Kubernetes allocates a port from the range 30000-32767 (by default) and opens that port on all nodes, forwarding traffic to the service's ClusterIP and then to the pods. This allows external access to the service via any node's IP and the specified NodePort.

Answer

LoadBalancer

Answer

ExternalName

Answer

ClusterIP

Question 3

After creating a NetworkPolicy that selects pods with label 'role: db' and allows ingress on TCP port 3306 from pods with label 'role: api', you notice that pods with label 'role: db' are still reachable on port 3306 from pods without 'role: api' label. What is the most likely cause?

Accepted Answer

The NetworkPolicy is not in the same namespace as the pods.. NetworkPolicies are namespaced resources. If the NetworkPolicy is created in a different namespace than the pods with label 'role: db', it will not apply to those pods. The policy must reside in the same namespace as the pods it targets; otherwise, the default behavior (allow all ingress) remains in effect for those pods.

Answer

The NetworkPolicy uses the wrong protocol.

Answer

The NetworkPolicy has an egress rule that overrides ingress.

Answer

The NetworkPolicy requires an explicit 'deny all' rule.

Question 4

Which NetworkPolicy rule will allow ingress traffic from pods with label 'role: frontend' in the same namespace?

Accepted Answer

ingress:
- from:
  - podSelector:
      matchLabels:
        role: frontend. A NetworkPolicy ingress rule with a `podSelector` matches pods in the same namespace as the policy. By specifying `matchLabels: role: frontend`, it allows inbound traffic from any pod in the same namespace that has that label, which is exactly what the question requires.

Answer

ingress:
- from:
  - ipBlock:
      cidr: 0.0.0.0/0

Answer

egress:
- to:
  - podSelector:
      matchLabels:
        role: frontend

Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        role: frontend

Question 5

Which Ingress resource field is used to specify the hostname for which traffic should be routed?

Accepted Answer

spec.rules[].host. In Kubernetes Ingress resources, host-based routing is defined under `spec.rules[].host`. Each rule can specify a hostname, and the Ingress controller uses this field to match the `Host` header of incoming HTTP requests, directing traffic to the appropriate backend service. This is the standard field for routing traffic based on hostname as defined in the Kubernetes Ingress API.

Answer

spec.tls[].hosts

Answer

spec.defaultBackend

Answer

spec.host

Question 6

In a Kubernetes cluster using CoreDNS, what is the DNS name for a Service named 'api' in namespace 'backend'?

Accepted Answer

api.backend.svc.cluster.local. In Kubernetes, CoreDNS resolves Service DNS names using the format `..svc.cluster.local`. For a Service named 'api' in namespace 'backend', the fully qualified DNS name is `api.backend.svc.cluster.local`. This allows Pods to discover the Service via DNS, with CoreDNS serving as the cluster DNS provider.

Answer

backend.api.svc.cluster.local

Answer

api.backend.cluster.local

Answer

api.svc.backend.cluster.local

Question 7

Which of the following is a core component of the Gateway API?

Accepted Answer

GatewayClass. The Gateway API is a Kubernetes SIG-Network project that defines a set of resources for configuring service networking. Its core components are GatewayClass, Gateway, and HTTPRoute (or TCPRoute, etc.). GatewayClass is analogous to IngressClass in the Ingress API, defining a class of gateways that a controller can implement, making it a foundational core component.

Answer

VirtualService

Answer

IngressController

Answer

ServiceEntry

Question 8

A cluster has kube-proxy running in ipvs mode. An administrator creates a Service of type ClusterIP. Which of the following is true about how traffic is forwarded to the pods?

Accepted Answer

kube-proxy creates IPVS virtual servers that use scheduling algorithms like round-robin. When kube-proxy runs in ipvs mode, it creates IPVS virtual servers for each ClusterIP Service. These virtual servers use kernel-level scheduling algorithms (e.g., round-robin, least connections) to forward traffic directly to the selected backend pods, bypassing iptables for per-packet decisions. This provides better performance and more sophisticated load-balancing policies compared to iptables mode.

Answer

kube-proxy uses userspace mode to proxy traffic

Answer

kube-proxy uses iptables rules to randomly select a pod

Answer

kube-proxy does nothing; the cluster DNS does the load balancing

Question 9

You have a NetworkPolicy that denies all ingress traffic by default, and you want to allow traffic only from pods with label 'app: monitoring' in the same namespace. What should the policy spec look like?

Accepted Answer

ingress: - from: - podSelector: matchLabels: app: monitoring. A NetworkPolicy with an ingress rule using only a podSelector allows traffic from pods matching the specified labels within the same namespace. Since the default policy denies all ingress traffic, this rule explicitly permits traffic from pods labeled 'app: monitoring' in the same namespace, which satisfies the requirement.

Answer

ingress: - from: - ipBlock: cidr: 0.0.0.0/0

Answer

ingress: - from: - podSelector: matchLabels: app: monitoring - namespaceSelector: matchLabels: name: my-namespace

Answer

ingress: - from: - namespaceSelector: matchLabels: app: monitoring

Question 10

An administrator applies the following YAML:
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: ""
---
What does setting storageClassName to an empty string achieve?

Accepted Answer

It ensures the PVC binds only to a PV with no storage class defined. Setting `storageClassName` to an empty string (`""`) explicitly tells Kubernetes to bind the PVC only to a PV that also has no `storageClassName` defined (i.e., a static PV with an empty or omitted storage class). This bypasses any default StorageClass in the cluster, preventing dynamic provisioning and ensuring the PVC matches only pre-provisioned PVs with no storage class.

Answer

It disables storage for the PVC

Answer

It triggers dynamic provisioning using the default StorageClass

Answer

It assigns the default StorageClass automatically

Question 11

Which Service type is used to expose a service externally with a cloud provider's load balancer?

Accepted Answer

LoadBalancer. The LoadBalancer service type provisions an external load balancer from the underlying cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer, Azure Load Balancer) and assigns a public IP or DNS name to route external traffic to the Kubernetes service. It is the only built-in service type that directly integrates with a cloud provider's infrastructure to expose a service externally with a managed load balancer.

Answer

NodePort

Answer

ClusterIP

Answer

ExternalName

Question 12

A PersistentVolume is created with the following spec:
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    namespace: default
    name: my-pvc
After the PVC 'my-pvc' is deleted, what happens to the PV?

Accepted Answer

The PV enters Released state and must have its claimRef manually removed to be reused. When a PersistentVolume (PV) has a reclaim policy of 'Retain' and its bound PVC is deleted, the PV enters the 'Released' state. It is not automatically deleted or recycled; instead, its data is preserved but the PV cannot be reused until the `claimRef` field is manually removed by an administrator. This is because the `claimRef` still references the deleted PVC, preventing automatic re-binding.

Answer

The PV is automatically deleted

Answer

The PV remains Available and can be bound to a new PVC

Answer

The PV is recycled and its contents are wiped

Question 13

An administrator creates a PersistentVolume named 'pv-nfs' with a reclaim policy of 'Retain'. After a user deletes the PVC bound to this PV, what state does the PV enter?

Accepted Answer

Released. When a PVC bound to a PV with a reclaim policy of 'Retain' is deleted, the PV does not automatically become available for reuse. Instead, it enters the 'Released' state, indicating that the volume's data is still intact but the PV is no longer bound to a claim. The administrator must manually intervene to reclaim or delete the underlying storage before the PV can be made available again.

Answer

Available

Answer

Failed

Answer

Bound

Question 14

What is the default reclaim policy for a PersistentVolume?

Accepted Answer

Retain. The default reclaim policy for a PersistentVolume (PV) in Kubernetes is 'Retain'. This means that when a PersistentVolumeClaim (PVC) bound to the PV is deleted, the PV will not be automatically deleted or recycled; instead, it remains in a 'Released' state, preserving the underlying storage and data for manual administrator intervention. This is defined in the PV's spec.persistentVolumeReclaimPolicy field, which defaults to 'Retain' if not explicitly set.

Answer

Recycle

Answer

None

Answer

Delete

Question 15

A PersistentVolumeClaim named 'my-pvc' is created and remains in 'Pending' state. Which command should the administrator use to investigate the reason?

Accepted Answer

kubectl describe pvc my-pvc. `kubectl describe pvc my-pvc` provides detailed events and status information for the PVC, including any errors or conditions that prevent it from binding to a PersistentVolume (PV). A 'Pending' state typically indicates that the PVC cannot find a matching PV or that the storage class is not available, and the describe command surfaces these reasons in the 'Events' section.

Answer

kubectl get pv

Answer

kubectl get pvc my-pvc -o yaml

Answer

kubectl describe pod my-pvc

Question 16

Which resource type is used to define a template for dynamically provisioning PersistentVolumes?

Accepted Answer

StorageClass. StorageClass is the correct resource because it defines a 'class' of storage with a provisioner (e.g., kubernetes.io/aws-ebs) and parameters that Kubernetes uses to dynamically create PersistentVolumes when a PersistentVolumeClaim requests storage. Without a StorageClass, dynamic provisioning cannot occur, as the cluster needs a template to know which storage backend to use and how to configure it.

Answer

PersistentVolume

Answer

VolumeAttachment

Answer

PersistentVolumeClaim

Question 17

A Pod is configured with a volume that uses a ConfigMap. The ConfigMap is updated after the Pod is running. How can the Pod access the updated data without restarting?

Accepted Answer

The Pod will automatically see the updated data within minutes.. When a ConfigMap is mounted into a Pod as a volume (without using subPath), updates to the ConfigMap are automatically reflected in the Pod's filesystem after a short delay (typically within minutes, controlled by the kubelet's sync period). However, if the ConfigMap is consumed via environment variables or mounted using subPath, the Pod must be restarted to see the changes. In this question, the volume uses a ConfigMap (presumably without subPath), so the Pod will automatically see the updated data within minutes.

Answer

The ConfigMap must be deleted and recreated.

Answer

The Node must be rebooted.

Answer

The Pod must be deleted and recreated.

Question 18

Which of the following is a required field when defining a PersistentVolume?

Accepted Answer

capacity. In Kubernetes, a PersistentVolume (PV) must define its storage capacity using the `capacity` field, which specifies the amount of storage the PV provides (e.g., `storage: 10Gi`). This is a required field because the PV represents a piece of storage in the cluster, and the scheduler and PersistentVolumeClaim (PVC) binding logic need to know the available size to match claims. Without `capacity`, the PV definition is invalid and will be rejected by the API server.

Answer

storageClassName

Answer

nodeAffinity

Answer

persistentVolumeReclaimPolicy

Question 19

You have a PVC that is bound to a PV with a filesystem volume mode. You want to use the volume as a block device in a pod. What should you do?

Accepted Answer

Create a new PVC with volumeMode: Block and bind it to a new PV.. A PVC with `volumeMode: Block` must be created and bound to a PV that also has `volumeMode: Block` to use the volume as a block device in a pod. The existing PVC is bound to a PV with `volumeMode: Filesystem`, which cannot be used as a block device without recreating the underlying storage. You cannot change the volume mode of an existing PV or PVC; you must provision new resources with the correct mode.

Answer

Use a hostPath volume instead.

Answer

Set volumeDevices in the pod spec instead of volumeMounts.

Answer

Modify the PV's volumeMode to Block.

Question 20

A cluster has a CSI driver installed. A pod using a CSI volume is in CrashLoopBackOff. 'kubectl describe pod' shows: 'failed to mount volume: rpc error: code = DeadlineExceeded desc = context deadline exceeded'. What is the MOST likely cause?

Accepted Answer

The CSI driver is failing to respond in time.. The error 'context deadline exceeded' indicates that the CSI driver's gRPC call to mount the volume did not complete within the default timeout (typically 30 seconds). This is most commonly caused by the CSI driver being unresponsive due to resource starvation, network issues, or a bug in the driver itself. Since the CSI driver is installed and the pod is attempting to mount, the failure is in the driver's response time, not in the PVC binding or volume mode.

Answer

The PVC is not bound.

Answer

The CSI driver is not installed.

Answer

The volume mode is Block but the pod expects Filesystem.