CKA Services and Networking Practice Test 8 — 15 Questions

Question 1

You apply the following NetworkPolicy to namespace 'ns1':
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []
What effect does this policy have?

Accepted Answer

Denies all ingress traffic to all pods in namespace ns1.. This NetworkPolicy selects all pods in namespace 'ns1' (via empty `podSelector: {}`), specifies `policyTypes: [Ingress]`, and defines an empty `ingress: []` rule list. In Kubernetes, an empty `ingress: []` explicitly denies all ingress traffic because no allow rules are present, overriding the default allow-all behavior. Therefore, all ingress traffic to any pod in ns1 is denied.

Answer

Denies all egress traffic as well.

Answer

Allows ingress traffic only from pods in the same namespace.

Answer

Allows all ingress traffic because no explicit deny rules are defined.

Question 2

A pod is unable to resolve DNS names of services in other namespaces. Which DNS configuration is most likely missing?

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 DNS resolution configuration, which typically points to the host's `/etc/resolv.conf` and does not include the cluster's DNS service (CoreDNS). This prevents the pod from resolving service DNS names like `..svc.cluster.local`, which are only resolvable via the cluster's DNS. Setting `dnsPolicy` to `ClusterFirst` (the default if not specified) ensures the pod uses CoreDNS for DNS queries, enabling cross-namespace service discovery.

Answer

CoreDNS is not deployed in the cluster.

Answer

The pod is in a different namespace than the service.

Answer

The service does not have a ClusterIP assigned.

Question 3

Which kube-proxy mode uses iptables rules to handle service traffic?

Accepted Answer

iptables. Kube-proxy's iptables mode uses Linux iptables rules to handle service traffic. In this mode, kube-proxy watches the Kubernetes API server for Service and Endpoint changes and programs iptables rules in the NAT table (specifically the PREROUTING and OUTPUT chains) to redirect traffic destined for a Service's ClusterIP to the backend Pod IPs via DNAT. This is the default mode in most Kubernetes distributions due to its reliability and moderate performance.

Answer

ipvs

Answer

nftables

Answer

userspace

Question 4

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 5

You have a Deployment with 3 replicas. You create a headless service (clusterIP: None) with a label selector. Which of the following is true about DNS resolution for this service?

Accepted Answer

DNS returns the IP addresses of all pods that match the selector.. A headless service (clusterIP: None) does not allocate a ClusterIP. Instead, DNS returns the IP addresses of all pods matching the label selector via A/AAAA records. This allows direct pod-to-pod communication without load balancing, commonly used for stateful workloads like databases.

Answer

DNS does not resolve the service name at all.

Answer

DNS returns the service name as a CNAME to the pod names.

Answer

DNS resolves the service name to a single ClusterIP.

Question 6

Which of the following is a valid CNI plugin for Kubernetes networking?

Accepted Answer

Calico. Calico is a valid CNI plugin that implements the Container Network Interface specification to provide networking and network policy for Kubernetes clusters. It uses BGP (Border Gateway Protocol) to route packets between nodes and supports overlay or non-overlay networking modes, making it a widely adopted choice for production environments.

Answer

etcd

Answer

Docker

Answer

Kubelet

Question 7

Which two of the following are valid methods for service discovery in Kubernetes?

Accepted Answer

Environment variables injected into pods. Option D is correct because Kubernetes automatically injects environment variables (e.g., _SERVICE_HOST and _SERVICE_PORT) into containers for each active Service, allowing pods to discover service endpoints without an external mechanism. Option E is correct because CoreDNS runs as the cluster DNS add-on and resolves Service names (e.g., my-svc.my-namespace.svc.cluster.local) to ClusterIPs, which is the standard in-cluster service discovery method. Option A is incorrect because an Ingress controller only routes external HTTP/HTTPS traffic to Services; it is not a service discovery mechanism. Option B is incorrect because Consul is a third-party tool, not a built-in Kubernetes service discovery method, and running a Consul agent per node is an external integration rather than a native Kubernetes mechanism. Option C is incorrect because kubectl proxy only creates a local proxy to the Kubernetes API server for accessing the API, not for discovering Services.

Answer

Ingress controller

Answer

Consul agent running on each node

Answer

kubectl proxy

Question 8

Which two of the following are correct statements about EndpointSlices?

Accepted Answer

EndpointSlices are automatically created by the EndpointSlice controller.. Option C is correct because the EndpointSlice controller in the Kubernetes control plane (kube-controller-manager) automatically creates and manages EndpointSlice objects for Services that have a selector, keeping them in sync with the matching Pods. Option E is correct because each EndpointSlice is limited to a default maximum of 100 endpoints, a value controlled by the --max-endpoints-per-slice flag on the kube-controller-manager, which improves scalability and reduces update churn compared to the single Endpoints object. Option A is wrong because EndpointSlices back Services of all types with selectors (ClusterIP, NodePort, LoadBalancer, and headless), not only LoadBalancer. Option B is wrong because EndpointSlices do not entirely replace the Endpoints resource; the legacy Endpoints API still exists and is maintained for compatibility, with EndpointSlices serving as the more scalable alternative. Option D is wrong because EndpointSlices graduated to stable (GA) in Kubernetes 1.21, so they are no longer an alpha feature requiring a feature gate.

Answer

EndpointSlices are only used for services of type LoadBalancer.

Answer

EndpointSlices replace the Endpoints resource entirely.

Answer

EndpointSlices are an alpha feature and must be enabled via feature gate.

Question 9

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 10

Which command forwards local port 8080 to port 80 of a pod named 'web-pod'?

Accepted Answer

kubectl port-forward pod/web-pod 8080:80. `kubectl port-forward` creates a direct tunnel from a local port to a specified port on a pod, allowing access to the pod's service without exposing it externally. The syntax `pod/web-pod 8080:80` forwards localhost:8080 to port 80 of the pod named 'web-pod'.

Answer

kubectl exec -it web-pod -- nc -l -p 8080

Answer

kubectl proxy --port=8080

Answer

kubectl expose pod web-pod --port=8080 --target-port=80

Question 11

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 12

Which kubectl command correctly retrieves the list of EndpointSlices for a Service named 'my-svc' in the 'default' namespace?

Accepted Answer

kubectl get endpointslice -n default --selector=kubernetes.io/service-name=my-svc. EndpointSlices are the modern, scalable replacement for Endpoints, and they use a specific label `kubernetes.io/service-name` to associate them with a Service. The command `kubectl get endpointslice -n default --selector=kubernetes.io/service-name=my-svc` correctly filters EndpointSlices by that label, retrieving all slices belonging to 'my-svc'.

Answer

kubectl get endpoints my-svc -n default

Answer

kubectl describe svc my-svc -n default

Answer

kubectl get endpointslices my-svc -n default

Question 13

Which DNS record does CoreDNS create for a headless Service named 'headless-svc' in the namespace 'default'?

Accepted Answer

A records for each pod IP backing the Service. CoreDNS creates A records for each pod IP backing a headless Service because headless Services (with clusterIP set to None) are designed to return pod IPs directly via DNS, rather than a single Service IP. For a headless Service named 'headless-svc' in the 'default' namespace, CoreDNS performs a DNS lookup that returns multiple A records, one for each ready pod endpoint, enabling direct pod-to-pod communication without load balancing.

Answer

No DNS record

Answer

A CNAME record pointing to an external DNS

Answer

An A record for the Service IP (ClusterIP)

Question 14

A NetworkPolicy allows ingress traffic from pods with label 'app: frontend' in any namespace. Which selector is used?

Accepted Answer

spec.ingress[0].from[0].namespaceSelector: {} and spec.ingress[0].from[0].podSelector: { matchLabels: { app: frontend } }. To allow ingress traffic from pods with label 'app: frontend' in any namespace, you must combine an empty namespaceSelector (which selects all namespaces) with a podSelector that matches the pod label. This combination tells Kubernetes to allow traffic from any pod matching the label, regardless of which namespace it resides in. Without the namespaceSelector, the podSelector would only apply to pods in the same namespace as the NetworkPolicy.

Answer

spec.ingress[0].from[0].podSelector: { matchLabels: { app: frontend } }

Answer

spec.ingress[0].from[0].ipBlock: { cidr: 0.0.0.0/0 }

Answer

spec.ingress[0].from[0].namespaceSelector: { matchLabels: { app: frontend } }

Question 15

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