Services and Networking — CKA practice questions

A NetworkPolicy egress rule that lets pods reach CoreDNS requires:

1. namespaceSelector for kube-system plus k8s-app=kube-dns on port 53
2. hostNetwork: true on the pod so DNS bypasses the policy entirely
3. A privileged securityContext granting the pod raw socket access
4. Listing the DNS ClusterIP as a NodePort exception in the policy

Answer: A — namespaceSelector for kube-system plus k8s-app=kube-dns on port 53

A is right: CoreDNS pods run in kube-system carrying the label k8s-app=kube-dns, so the egress rule selects that namespace and those pods and permits port 53 on UDP and usually TCP as well. Forgetting it is the classic reason a default-deny egress policy breaks every name lookup. B works around the policy by removing the pod from the pod network, which is a serious escalation, not a fix. C confuses privileges with connectivity. D misunderstands the model: policies match pod selectors and ports, not Service addresses.

A cluster has the Gateway API CRDs installed and a Gateway is created, but its status stays unprogrammed with no address. What is the MOST likely reason?

1. The CRDs must be installed after the controller, so their ordering has to be reversed
2. Gateway addresses are only assigned once a Service of type LoadBalancer is created
3. The Gateway is missing an HTTPRoute, without which no address can be allocated
4. No controller is running for the GatewayClass the Gateway references by name

Answer: D — No controller is running for the GatewayClass the Gateway references by name

D) Correct — installing the CRDs only adds the types; a Gateway stays unprogrammed until an implementation whose controllerName matches the referenced GatewayClass reconciles it. A) invents an ordering constraint that does not exist. C) reverses the dependency, as Gateways are addressable before any route attaches. B) describes what many implementations do internally, but the operator does not create that Service and its absence is a symptom, not the cause.

Which Service type exposes a Service on a static port on every node's IP address?

1. ClusterIP, the default type, reachable only from inside the cluster on a virtual IP
2. NodePort, which exposes the Service on <NodeIP>:<port> from the 30000-32767 range
3. Headless, with clusterIP None, returning pod IPs directly through DNS A records
4. ExternalName, which returns a CNAME to an external name and proxies no traffic
5. Ingress, an HTTP routing object rather than a Service type, needing a controller

Answer: B — NodePort, which exposes the Service on <NodeIP>:<port> from the 30000-32767 range

B is the answer: a NodePort Service allocates a port in the default 30000-32767 range and every node forwards it to the Service's endpoints. A is internal only. C gives DNS records instead of a virtual IP. D is a DNS alias with no proxying. E tempts because it also handles external traffic, but Ingress is a separate API object, not a Service type. LoadBalancer builds on NodePort by adding a cloud load balancer.

A cluster was built with a /24 pod CIDR and a per-node mask of /24. New nodes join but their pods stay pending with no address available. What is the BEST explanation?

1. The cluster pod CIDR is too small to be subdivided, so only one node can receive a range
2. The Service CIDR has been exhausted, and pods borrow addresses from that same pool
3. The kubelet must be restarted on each new node before it requests its podCIDR allocation
4. Nodes joined after the control plane was upgraded cannot be allocated a pod subnet

Answer: A — The cluster pod CIDR is too small to be subdivided, so only one node can receive a range

A) Correct — the controller manager carves per-node subnets out of the cluster CIDR, and a /24 cluster range with a /24 node mask yields exactly one allocatable block. B) confuses the two ranges, which are independent. C) invents a manual step; the node controller assigns podCIDR as part of node registration. D) states a version constraint that does not exist for address allocation.

Which statement about NodePort Services is MOST accurate?

1. Traffic to the node port is only accepted on the specific node hosting a backing pod
2. A NodePort Service has no cluster IP; the node port replaces it as the access path
3. The port is allocated from a configurable range and answers on every node in the cluster
4. NodePort requires an Ingress controller to translate the port into a Service endpoint

Answer: C — The port is allocated from a configurable range and answers on every node in the cluster

C) Correct — the API server allocates from the service-node-port-range (30000-32767 by default) and kube-proxy programs every node to accept on that port, forwarding to a backend wherever it runs. A) is the common misconception that node ports are node-local; that behaviour only appears when externalTrafficPolicy is set to Local. B) is wrong because NodePort is a superset of ClusterIP — the cluster IP is still allocated and still works. D) inverts the relationship: an Ingress controller is often *exposed* via NodePort, not required by it.

Namespace `prod` has a default-deny ingress policy. A second policy is added allowing ingress from pods labelled `role=frontend`. Which statement is MOST accurate?

1. The second policy must delete the first, since two policies on one pod conflict
2. Policies are additive, so the union of their allow rules determines what is permitted
3. The most recently applied policy wins outright and fully replaces earlier ones
4. The deny policy takes precedence because explicit denials outrank any allow rule

Answer: B — Policies are additive, so the union of their allow rules determines what is permitted

B) Correct — NetworkPolicy has no deny rules and no precedence order; a connection is allowed if any policy selecting the pod permits it, so adding the second policy opens exactly the frontend path. C) imports last-write-wins semantics from other firewall systems that do not apply here. D) assumes deny rules exist, but the first policy denies only by omitting allowances. A) is unnecessary and would remove the baseline restriction the team wants to keep.

Which resource provides L7 host and path routing to multiple Services?

1. A Service of type LoadBalancer, distributing traffic at layer 4
2. Ingress, implemented by a controller such as NGINX or Traefik
3. NetworkPolicy, which filters pod traffic by label and by port
4. EndpointSlice, which tracks the addresses behind a given Service

Answer: B — Ingress, implemented by a controller such as NGINX or Traefik

B is right: Ingress is the routing configuration and an Ingress controller is what implements it, so rules do nothing until a controller and a matching ingressClassName are present. Gateway API now covers the same ground with a richer, role-oriented model and sits alongside Ingress rather than replacing it. A operates at layer 4 and cannot route on host or path. C controls which traffic is permitted, not where it is sent. D is an internal object the endpoints controller maintains for a Service.

An administrator applies a correct Ingress manifest, but its ADDRESS field stays empty and no HTTP routing occurs. What is the MOST likely explanation?

1. The Ingress lacks a default backend, which the API server requires before admission
2. The referenced Services are ClusterIP, and Ingress can only target NodePort Services
3. The path type is Prefix, which needs a rewrite annotation before any address is assigned
4. No ingress controller is deployed or none claims the resource's ingressClassName

Answer: D — No ingress controller is deployed or none claims the resource's ingressClassName

D) Correct — Ingress is only a declarative record; without a running controller that claims it via IngressClass, nothing programs a data path or reports an address. A) is false, a default backend is optional. B) is a persistent myth: controllers routinely route to ClusterIP Services and many bypass the Service VIP to reach pod endpoints directly. C) confuses pathType semantics with address assignment, which is unrelated to rewriting.

A Service of type ClusterIP:

1. Exposes the Service outside the cluster on a port opened on every node's address
2. Allocates a routable public address through the cloud provider's load balancer
3. Is the default type, exposing the Service on an internal virtual IP for in-cluster use
4. Behaves like a pod IP, changing whenever the backing pods are replaced or rescheduled
5. Reserves a port in the 30000-32767 range on each node, which is what NodePort does

Answer: C — Is the default type, exposing the Service on an internal virtual IP for in-cluster use

C is the answer: ClusterIP is the default and allocates a stable virtual IP plus a DNS name that only in-cluster clients can reach, with kube-proxy programming iptables or IPVS rules to the current endpoints. A and E describe NodePort, B describes LoadBalancer. D is the problem a Service solves — the virtual IP stays constant while pod IPs churn.

Service of type LoadBalancer is created on a bare-metal kubeadm cluster. What happens?

1. A cloud load balancer is provisioned at no cost to the cluster owner
2. kube-proxy assigns a synthetic external IP from the node's subnet
3. The Service quietly downgrades itself to type NodePort instead
4. EXTERNAL-IP stays Pending unless something like MetalLB is installed

Answer: D — EXTERNAL-IP stays Pending unless something like MetalLB is installed

D is right: provisioning an external load balancer needs a cloud-controller-manager or a bare-metal controller such as MetalLB or kube-vip; without one the EXTERNAL-IP never leaves Pending. A assumes a cloud that is not there. B credits kube-proxy with address allocation it does not perform. C is wrong because the NodePort is allocated in addition, not as a downgrade.

If two NetworkPolicies select the same pod, how are they combined?

Additively — the union of their allow rules applies. NetworkPolicies have no deny rules, no ordering and no priority, so adding a policy can only widen what is permitted for an already-selected pod.

What is a headless Service and when do you use one?

A Service with clusterIP: None. No virtual IP or proxying is allocated; DNS returns the pod IPs directly (and per-pod records when backing a StatefulSet). Use it when the client needs to address individual pods, as with databases and peer-to-peer clustering.

Name the three core Gateway API resources and the role each plays.

GatewayClass: cluster-scoped, names the controller implementation • Gateway: an actual listener with protocol, port and TLS, usually owned by the infrastructure team • HTTPRoute: hostname and path rules attached to a Gateway, owned by the application team.

ClusterIP?

Default. Only accessible within cluster.