CKA Services and Networking Practice Test 3 — 15 Questions

Question 1

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

Accepted Answer

To allow DNS queries to return all pod IPs for a StatefulSet. A Headless Service (clusterIP: None) is used when you want to discover individual pod IPs directly, rather than having a single virtual IP load-balance traffic. When a Service has clusterIP set to None, DNS queries return the A/AAAA records for all ready pod IPs, which is essential for StatefulSets where each pod has a unique identity and needs to be addressed individually, such as in clustered databases like Cassandra or Kafka.

Answer

To expose the Service externally via a cloud load balancer

Answer

To provide load balancing across pods

Answer

To assign a static ClusterIP

Question 2

A developer reports that a pod can resolve 'my-service.my-namespace.svc.cluster.local' but not 'my-service'. Both the pod and the Service are in the same namespace. What is the most likely cause?

Accepted Answer

The pod's dnsPolicy is set to 'Default'. When a pod's `dnsPolicy` is set to `Default`, the pod inherits the node's `/etc/resolv.conf`, which typically contains only the cluster's DNS resolver IP (e.g., `10.96.0.10`) and a search domain list that may not include the pod's own namespace. This means the pod can resolve fully qualified domain names (FQDNs) like `my-service.my-namespace.svc.cluster.local` but fails to resolve short names like `my-service` because the search domains do not include `<namespace>.svc.cluster.local` for the pod's namespace. The default `dnsPolicy` for pods is `ClusterFirst`, which adds the necessary search domains to resolve short Service names.

Answer

The Service does not have a valid ClusterIP

Answer

The Service is of type ExternalName

Answer

The kube-dns Service is not running

Question 3

You are implementing NetworkPolicies. You have a namespace 'db' with a pod running PostgreSQL. You want to allow only pods with label 'role: frontend' in namespace 'app' to connect to PostgreSQL on TCP port 5432. What is the correct Ingress rule?

Accepted Answer

podSelector: matchLabels: app: postgres; from: - namespaceSelector: matchLabels: name: app. To allow only pods with a specific label in a specific namespace, the `namespaceSelector` and `podSelector` must be defined within the same list item under the `from` block (an AND relation). If they are defined as separate list items (each prefixed with a `-`), it creates an OR relation, which would incorrectly allow all pods in the 'app' namespace as well as any pod with the 'role: frontend' label in the local namespace.

Answer

podSelector: {}; from: - namespaceSelector: matchLabels: role: frontend

Answer

podSelector: {}; from: - namespaceSelector: matchLabels: name: app - podSelector: matchLabels: role: frontend

Answer

podSelector: {}; from: - podSelector: matchLabels: role: frontend

Question 4

You create a Deployment with replicas=3 and a Service of type ClusterIP. You notice that traffic to the Service is not evenly distributed. What is the most likely cause?

Accepted Answer

kube-proxy is running in iptables mode. When kube-proxy runs in iptables mode, it uses random selection (not round-robin) to choose a backend pod for each new connection. This randomness can lead to uneven traffic distribution, especially with a small number of replicas or short-lived connections, because iptables uses a probabilistic match based on the `statistic` module with `mode random`.

Answer

kube-proxy is running in ipvs mode

Answer

The Service has sessionAffinity set to ClientIP

Answer

The pods have different resource limits

Question 5

Which TWO of the following are valid CNI plugins used in Kubernetes? (Select 2)

Accepted Answer

Calico. Calico (A) is a valid CNI plugin that provides pod networking and network policy enforcement in Kubernetes clusters. Flannel (B) is a valid CNI plugin that creates an overlay network to provide pod-to-pod connectivity across nodes. Weave (E) is also a valid CNI plugin (Weave Net) that builds a mesh overlay network for pod communication and supports network policies. kube-proxy (C) is not a CNI plugin; it is a Kubernetes component that implements Service load balancing via iptables/IPVS rules. CoreDNS (D) is not a CNI plugin; it is the cluster DNS server that resolves service and pod DNS names.

Answer

kube-proxy

Answer

CoreDNS

Question 6

Which TWO of the following are valid modes for kube-proxy? (Select 2)

Accepted Answer

iptables. kube-proxy supports iptables mode (A), which programs iptables NAT rules to implement Service load balancing and is the most common default on Linux nodes. It also supports ipvs mode (C), which uses the kernel IPVS subsystem for Layer 4 load balancing with better scalability and more load-balancing algorithms than iptables. nftables (B) is not a kube-proxy mode; although newer Kubernetes releases have added nftables support in some contexts, the classic valid modes are iptables, ipvs, and userspace. userspace (D) was a legacy kube-proxy mode but is no longer a valid/current mode in modern Kubernetes. ebpf (E) is not a kube-proxy mode; eBPF-based service handling is provided by alternative CNIs such as Cilium, not by kube-proxy.

Answer

nftables

Answer

userspace

Answer

ebpf

Question 7

A ClusterIP service named 'svc' in namespace 'default' is not reachable from a pod in the same namespace. The service selector matches the pod's labels. Which command should you run first to verify the endpoint list?

Accepted Answer

kubectl get endpoints svc. To resolve the ambiguity and create a better test of knowledge, Option A should be changed to 'kubectl get svc svc'. The 'kubectl get svc' command only shows the Service's ClusterIP, type, and ports, but does not display the backend endpoints. To verify the actual backend endpoint IPs, you must query the endpoints resource directly using 'kubectl get endpoints svc' (or 'kubectl get ep svc').

Answer

kubectl describe svc svc

Answer

kubectl get endpoints svc -n kube-system

Answer

kubectl describe pod <pod-name>

Question 8

You have an Ingress resource with TLS configured. You verify that the TLS secret exists in the same namespace. However, accessing the service via HTTPS returns a certificate error. What is the most likely cause?

Accepted Answer

The certificate in the TLS secret is self-signed, not signed by a trusted CA.. A self-signed certificate is not trusted by any public Certificate Authority (CA). When a browser or client accesses the service via HTTPS, it validates the certificate against its trust store. Since a self-signed certificate is not in that store, the client displays a certificate error. The Ingress controller serves the certificate correctly, but the client rejects it due to lack of trust.

Answer

The TLS secret name in the Ingress spec does not match the actual secret name.

Answer

The TLS secret's certificate does not match the hostname used in the Ingress rule.

Answer

The Ingress controller must be configured with the --default-ssl-certificate flag.

Question 9

Which TWO statements about Headless Services are correct?

Accepted Answer

A Headless Service is created by setting clusterIP: None.. Option D is correct because a Headless Service is defined by explicitly setting `clusterIP: None` in the Service spec, which tells Kubernetes not to allocate a virtual ClusterIP or perform kube-proxy load balancing. Option E is correct because, with no ClusterIP, DNS returns A/AAAA records for each backing pod's IP (e.g., via the service's name), letting clients enumerate all pod IPs directly. Options A, B, and C are not marked correct: while a Headless Service can omit a selector (for manual Endpoints) and can be used with StatefulSets for stable identities, those are not the defining statements here, and round-robin load balancing is a property of normal ClusterIP Services, not Headless Services.

Answer

A Headless Service does not require a selector.

Answer

A Headless Service provides round-robin load balancing across pods.

Answer

A Headless Service is used to provide a stable network identity for pods.

Question 10

You are troubleshooting a Service connectivity issue. A pod in namespace 'frontend' cannot reach a Service in namespace 'backend' by its DNS name. CoreDNS is running. Which statements are true? (Select TWO.)

Accepted Answer

Cross-namespace DNS resolution requires the pod to use the full FQDN of the service.. Option D is correct because Kubernetes DNS search domains are namespace-scoped: a pod in 'frontend' resolving a short name like 'backend-service' will have the search path 'frontend.svc.cluster.local' appended, so reaching a Service in another namespace requires the fully qualified domain name. Option E is correct because the canonical FQDN format for a Service is '..svc.', which here is 'backend-service.backend.svc.cluster.local', and this name resolves via CoreDNS regardless of the pod's own namespace. Option A is wrong because Service DNS records are created automatically by CoreDNS (kube-dns), not disabled, and environment variables are only a supplementary mechanism. Option B is wrong because the default cluster domain is 'cluster.local', not 'cluster'. Option C is wrong because NetworkPolicy can block the DNS traffic (UDP/TCP port 53) to kube-dns/CoreDNS, thereby indirectly breaking service name resolution.

Answer

Service DNS is automatically disabled in Kubernetes; pods must use environment variables.

Answer

The default cluster domain for Kubernetes services is 'cluster'.

Answer

NetworkPolicy cannot affect service DNS resolution.

Question 11

Which of the following service types exposes a service on a static port on each node's IP address?

Accepted Answer

NodePort. NodePort is the correct answer because it exposes a service on a static port (in the range 30000-32767) on every node's IP address. When you create a NodePort service, Kubernetes allocates a port from that range and opens that port on all nodes, forwarding traffic to the service's ClusterIP and then to the pods.

Answer

ExternalName

Answer

LoadBalancer

Answer

ClusterIP

Question 12

You run 'kubectl get svc my-service -o yaml' and see 'type: ClusterIP'. The service has no endpoints. What is the most likely cause?

Accepted Answer

No pods with labels matching the service selector are running and ready.. A Kubernetes Service of type ClusterIP relies on a label selector to identify target Pods. If no Pods match the selector and are in the Ready state, the Service will have no endpoints, causing traffic to be dropped. The absence of endpoints directly indicates a mismatch or absence of matching, ready Pods.

Answer

The service type is ClusterIP, which does not support endpoints.

Answer

The service's port does not match the container port.

Answer

The service is misconfigured and needs to be deleted and recreated.

Question 13

You have a Service named 'my-service' in namespace 'ns1'. Another pod in namespace 'ns2' needs to resolve 'my-service' using DNS. What FQDN should the pod use?

Accepted Answer

my-service.ns1.svc.cluster.local. Kubernetes DNS resolves services using the FQDN format `..svc.cluster.local`. Since the pod in namespace 'ns2' needs to resolve 'my-service' which resides in namespace 'ns1', the FQDN must include the target namespace 'ns1' to perform a cross-namespace DNS lookup. Omitting the namespace would default to the pod's own namespace, which would fail to resolve the service.

Answer

my-service.svc.cluster.local

Answer

my-service.cluster.local

Answer

my-service.ns2.svc.cluster.local

Question 14

An Ingress resource is created with the following spec:

spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

The backend service 'api-service' is in the same namespace as the Ingress. What must be true for the Ingress to route traffic to the service?

Accepted Answer

The service 'api-service' must have a valid ClusterIP and at least one endpoint.. For an Ingress to route traffic to a backend service, the service must have a valid ClusterIP (so the Ingress controller can reach it via the cluster network) and at least one healthy endpoint (i.e., pods matching the service’s selector must be running and ready). The Ingress controller forwards traffic to the service’s ClusterIP on the specified port, not directly to pods, so a ClusterIP and endpoints are essential.

Answer

The Ingress controller must be configured to use the NodePort of the service.

Answer

The service 'api-service' must be of type NodePort.

Answer

The Ingress must have an IngressClass annotation.

Question 15

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

Accepted Answer

my-svc.default.svc.cluster.local. In Kubernetes, the default DNS name for a service follows the pattern `..svc.cluster.local`. For a service named 'my-svc' in the 'default' namespace, the fully qualified domain name (FQDN) is `my-svc.default.svc.cluster.local`. This is defined by the cluster DNS specification (CoreDNS or kube-dns) and allows pods to resolve the service by name within the cluster.

Answer

my-svc.default.cluster.local

Answer

my-svc.svc.cluster.local

Answer

my-svc.cluster.local