CKA Services and Networking Practice Test 7 — 15 Questions

Question 1

Which kube-proxy mode uses iptables rules to handle service traffic and is the default in many distributions?

Accepted Answer

iptables. The iptables mode is the default kube-proxy mode in many Kubernetes distributions, including kubeadm-based clusters. In this mode, kube-proxy watches the Kubernetes API server for Service and Endpoint changes and programs iptables rules in the kernel's netfilter framework to direct traffic to the appropriate backend Pods, providing efficient NAT-based load balancing without requiring a userspace proxy.

Answer

userspace

Answer

ipvs

Answer

nftables

Question 2

Which resource is used to configure TLS termination and path-based routing for HTTP(S) traffic into a cluster?

Accepted Answer

Ingress. An Ingress resource provides HTTP and HTTPS routing to services within a Kubernetes cluster, enabling TLS termination and path-based routing. It acts as a layer 7 load balancer, directing external traffic to the appropriate backend Service based on hostnames and paths defined in its rules.

Answer

Service

Answer

NetworkPolicy

Answer

Gateway

Question 3

Which TWO statements about EndpointSlices are true? (Choose 2)

Accepted Answer

EndpointSlices are automatically created and managed by the EndpointSlice controller. The EndpointSlice controller is a core Kubernetes controller that automatically creates and manages EndpointSlice objects based on Services with a selector. It monitors Service and Pod changes, then updates the corresponding EndpointSlices to reflect the current set of ready endpoints, ensuring efficient network routing without manual intervention.

Answer

EndpointSlices are only used for Services of type ClusterIP

Answer

EndpointSlices replace Endpoints in all Kubernetes versions

Answer

EndpointSlices can contain up to 100 endpoints each

Question 4

Which THREE are correct ways to configure a default deny all ingress traffic NetworkPolicy? (Choose 3)

Accepted Answer

A NetworkPolicy with podSelector: {} and ingress: []. Setting `ingress: []` in a NetworkPolicy with `podSelector: {}` explicitly defines an empty ingress rules list, which means no ingress traffic is allowed. This is a standard pattern for creating a default deny all ingress policy, as the policy applies to all pods in the namespace and the empty rules list blocks all incoming traffic.

Answer

A NetworkPolicy with podSelector: {} and an ingress rule with from: []

Answer

A NetworkPolicy with podSelector: {} and an ingress rule with from: [{}]

Question 5

Which TWO commands can be used to test DNS resolution for a Service named 'my-svc' in namespace 'default' from within a temporary pod? (Choose 2)

Accepted Answer

kubectl run test --image=busybox --rm -it --restart=Never -- nslookup my-svc. Both `nslookup` and `dig` are standard DNS lookup utilities used to query DNS servers (like CoreDNS in Kubernetes) to resolve domain names. To run these utilities in a temporary pod, we use the official Kubernetes DNS troubleshooting image `gcr.io/kubernetes-e2e-test-images/dnsutils:1.3` because the standard `busybox` image does not contain `dig`. Since the temporary pod is running in the same namespace (`default`), the short name `my-svc` resolves correctly.

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- wget my-svc

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- ping my-svc

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- curl my-svc

Question 6

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 7

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 8

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 9

You want to forward local port 8080 to port 80 of a pod named 'nginx-pod'. Which command should you use?

Accepted Answer

kubectl port-forward pod/nginx-pod 8080:80. `kubectl port-forward` is the Kubernetes command used to forward a local port to a port on a specific pod. The syntax `kubectl port-forward pod/nginx-pod 8080:80` correctly specifies the pod resource, the local port (8080), and the target pod port (80), enabling access to the pod's port 80 from the local machine.

Answer

kubectl proxy pod/nginx-pod 8080:80

Answer

kubectl forward pod/nginx-pod 8080 80

Answer

kubectl port-forward service/nginx-pod 8080:80

Question 10

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 11

Which of the following is NOT a valid Service type in Kubernetes?

Accepted Answer

Headless. Headless is not a valid Service type in Kubernetes; it is a configuration of a ClusterIP service where the cluster IP is set to 'None' to return individual pod DNS records instead of a single virtual IP. The valid Service types are ClusterIP, NodePort, LoadBalancer, and ExternalName.

Answer

ExternalName

Answer

NodePort

Answer

ClusterIP

Question 12

You need to expose a Service externally using an Ingress. The Ingress controller requires a specific IngressClass. How do you specify the IngressClass in the Ingress resource?

Accepted Answer

Set spec.ingressClassName: nginx. The `spec.ingressClassName` field is the standard way to specify the IngressClass for an Ingress resource in Kubernetes v1.18+ (GA in v1.22). This field references the name of an IngressClass resource, which defines the controller (e.g., nginx, haproxy) and its configuration. Using this field ensures the Ingress controller selects the correct implementation.

Answer

Set spec.class: nginx

Answer

Add an annotation: kubernetes.io/ingress.class: nginx

Answer

Create an IngressClass resource and reference it via spec.ingressClassRef

Question 13

You have a Service 'my-svc' with ClusterIP None (headless). You create a StatefulSet with 3 replicas and a headless Service. How do you reach individual pods?

Accepted Answer

Use the pod DNS name: .my-svc..svc.cluster.local. In a headless Service (ClusterIP: None), Kubernetes creates DNS A/AAAA records for each pod in a StatefulSet using the pattern ...svc.cluster.local. This allows direct, stable network identity for each pod, which is essential for stateful applications like databases that require consistent hostnames.

Answer

Use the Service name 'my-svc' which will round-robin between pods

Answer

Use the Service's ClusterIP (None) to reach all pods

Answer

You cannot reach individual pods directly; you must use the Service name

Question 14

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

Accepted Answer

Calico. Calico, Flannel, and Weave are all valid CNI plugins used in Kubernetes. kube-proxy and CoreDNS are Kubernetes components, not CNI plugins. Since the question asks for two but three exist, the marked answer (A and B) is incomplete; E is also correct.

Answer

kube-proxy

Answer

CoreDNS

Question 15

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

Accepted Answer

NetworkPolicy supports both ingress and egress rules. NetworkPolicy supports both ingress and egress traffic rules, allowing you to define which pods can receive incoming traffic (ingress) and which pods can initiate outgoing traffic (egress). This is explicitly defined in the Kubernetes NetworkPolicy API, where the `policyTypes` field can include 'Ingress', 'Egress', or both, enabling fine-grained network segmentation.

Answer

NetworkPolicy can define rules based on DNS names

Answer

NetworkPolicy is a cluster-scoped resource