CKA Practice Test 10 — 10 Questions

Question 1

Which of the following is a valid use case for a Headless Service?

Accepted Answer

To enable DNS-based service discovery for stateful applications like StatefulSets. A Headless Service (with clusterIP: None) is used to enable DNS-based service discovery, returning the IP addresses of all backing pods rather than a single virtual IP. This is essential for stateful applications like StatefulSets, where each pod requires a stable network identity and direct pod-to-pod communication without load balancing.

Answer

To provide a stable IP address for a deployment

Answer

To load balance traffic across pods using iptables

Answer

To allow external traffic to reach pods without a load balancer

Question 2

Which kube-proxy mode uses IP Virtual Server (IPVS) for load balancing and supports more algorithms than the default mode?

Accepted Answer

ipvs. The IP Virtual Server (IPVS) mode in kube-proxy leverages the Linux kernel's IPVS module, which is built on the Netfilter framework and operates in the kernel space. Unlike the default iptables mode, IPVS supports a variety of load-balancing algorithms (e.g., round-robin, least-connection, source-hashing) and provides better scalability and performance for large clusters by using a hash table for service-to-endpoint mapping.

Answer

userspace

Answer

iptables

Answer

kube-proxy

Question 3

You want to temporarily access a pod's HTTP endpoint on port 8080 from your local machine on port 9090. Which command should you use?

Accepted Answer

kubectl port-forward pod/my-pod 9090:8080. `kubectl port-forward` creates a direct tunnel from a local port (9090) to a pod's port (8080) over the Kubernetes API server, enabling temporary access to a pod's HTTP endpoint without exposing a service. This is the standard method for debugging or testing a pod's network endpoint from a local machine.

Answer

kubectl exec -it my-pod -- /bin/bash

Answer

kubectl proxy --port=9090

Answer

kubectl expose pod my-pod --port=9090 --target-port=8080

Question 4

What is the purpose of a headless Service (clusterIP: None)?

Accepted Answer

To allow direct DNS resolution to pod IPs. A headless Service (clusterIP: None) disables the virtual IP and load balancing, causing DNS queries to return the IP addresses of the backing pods directly. This allows clients to perform DNS-based service discovery and connect to specific pod IPs, which is essential for stateful applications like databases that require direct pod-to-pod communication.

Answer

To expose the Service externally via a cloud load balancer

Answer

To provide load balancing across pods

Answer

To map the Service to an external DNS name

Question 5

A developer runs `kubectl run nginx --image=nginx --port=80` and then `kubectl expose pod nginx --port=80 --target-port=80 --type=NodePort`. What is the name of the created Service?

Accepted Answer

nginx. The `kubectl expose pod nginx --port=80 --target-port=80 --type=NodePort` command creates a Service that inherits its name from the resource being exposed, which is the pod named 'nginx'. By default, `kubectl expose` uses the name of the referenced resource (in this case, the pod) as the Service name, resulting in a Service named 'nginx'. This is consistent with Kubernetes behavior where the Service name is derived from the resource name unless overridden with the `--name` flag.

Answer

expose-nginx

Answer

nginx-service

Answer

nginx-pod

Question 6

Which Service type exposes a Service externally via a cloud provider's load balancer?

Accepted Answer

LoadBalancer. (LoadBalancer) is correct because the LoadBalancer Service type automatically 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 expose the Service externally. This is achieved by the cloud-controller-manager component, which watches for Services of type LoadBalancer and creates the corresponding cloud resource.

Answer

ExternalName

Answer

ClusterIP

Answer

NodePort

Question 7

You have a NetworkPolicy that selects pods with label 'app: db'. The policy has an ingress rule allowing traffic from pods with label 'app: frontend'. A pod with label 'app: frontend' is in a different namespace. No namespaceSelector is specified in the ingress rule. Will traffic from that pod be allowed?

Accepted Answer

No, because the frontend pod is in a different namespace and no namespaceSelector is specified. A NetworkPolicy's ingress rule without a namespaceSelector only applies to pods within the same namespace as the policy. Since the frontend pod is in a different namespace and no namespaceSelector is specified, the rule does not match it, and traffic is denied by default (as NetworkPolicy enforces default-deny for selected pods).

Answer

Yes, because podSelector selects pods across all namespaces

Answer

No, because NetworkPolicy only works within the same namespace

Answer

Yes, because all ingress traffic is allowed by default

Question 8

You run `kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort` and the Service is created. What is the effect of this command?

Accepted Answer

It creates a NodePort Service, making the deployment accessible on each node's IP on a high port.. The `kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort` command creates a NodePort Service. This Service exposes the deployment on each node's IP address on a static port (in the range 30000-32767 by default), making it accessible from outside the cluster via `:`. The `--type=NodePort` flag explicitly overrides the default ClusterIP type, and the Service will also automatically allocate a ClusterIP for internal routing.

Answer

It creates a LoadBalancer Service and provisions a cloud load balancer.

Answer

It creates a ClusterIP Service that is only accessible within the cluster.

Answer

It creates an ExternalName Service that maps to an external DNS name.

Question 9

An administrator needs to create a PersistentVolume with 10Gi capacity, ReadWriteOnce access mode, and a reclaim policy of Retain. Which YAML snippet correctly defines this PV?

Accepted Answer

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/pv. It defines a PersistentVolume with the required 10Gi capacity, ReadWriteOnce access mode (using the correct plural 'accessModes' field), and the Retain reclaim policy. The hostPath volume type is also specified correctly.

Answer

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/pv

Answer

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi
  accessMode:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/pv

Answer

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /data/pv

Question 10

Which of the following is a correct Ingress resource snippet that routes traffic to service 'web-svc' on port 80 for the host 'example.com'?

Accepted Answer

spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80. It follows the exact structure required by the Kubernetes Ingress v1 API (networking.k8s.io/v1). It specifies the host `example.com`, defines an HTTP rule with a path of `/` and `pathType: Prefix`, and correctly references the backend service `web-svc` on port 80 using the `service.name` and `port.number` fields. This configuration ensures that traffic for `example.com` is routed to the target service.

Answer

spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: web-svc
            port:
              number: 80

Answer

spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: web-svc
          servicePort: 80

Answer

spec:
  rules:
  - host: example.com
    backend:
      serviceName: web-svc
      servicePort: 80