CKA Services and Networking — Timed 25 Questions

Question 1

An administrator runs 'kubectl run nginx --image=nginx --port=80' and then 'kubectl expose pod nginx --port=80 --type=NodePort'. Later, they run 'kubectl get svc nginx' and see that the NodePort is set to 0. What is the most likely reason?

25 minute time limit — choose an answer to begin.

Accepted Answer

The pod was not ready when the service was created, so NodePort assignment was delayed.. By default, Kubernetes restricts NodePort allocations to the range 30000-32767. If a user specifies a nodePort outside of this range (such as 8080) in the Service manifest, the API server will reject the creation with a validation error. This range can be customized using the `--service-node-port-range` flag on the kube-apiserver.

Answer

The nodePort field was explicitly set to 0 in the service YAML, but the administrator used a flag that was ignored.

Answer

The cluster has a mutating webhook that converted the service type to ClusterIP because NodePort is disabled.

Answer

The pod was created by a Deployment, so its labels do not match the service selector.

Question 2

A cluster has a NetworkPolicy that denies all ingress traffic by default. An administrator wants to allow TCP traffic on port 8080 from pods with label 'app: web' in the same namespace. Which NetworkPolicy egress rule is needed?

Accepted Answer

An ingress rule with podSelector matching 'app: web' and ports.. To allow incoming traffic to a pod that has a default-deny ingress policy, an ingress rule must be defined on that pod's NetworkPolicy. The rule needs to specify a podSelector matching the source pods ('app: web') and the destination port (8080).

Answer

An ingress rule with namespaceSelector matching the same namespace.

Answer

An egress rule with namespaceSelector and podSelector.

Answer

An egress rule with podSelector matching 'app: web' and ports.

Question 3

Which TWO of the following are valid ways to expose a Deployment named 'web' as a service?

Accepted Answer

kubectl expose deployment web --port=80. Option C is correct because `kubectl expose deployment web --port=80` is the canonical imperative command that creates a Service whose selector is automatically derived from the Deployment's pod template labels, targeting the pods managed by the 'web' Deployment. Option D is correct because applying a Service manifest with `selector: app: web` creates a Service that selects the pods labeled `app: web`, which is the standard declarative way to expose a Deployment's pods (assuming the Deployment's pod template carries that label). Option A is not a Service at all; `kubectl port-forward` only tunnels a local port to a pod/Deployment for debugging and does not create a persistent Service object. Option B uses `kubectl run --expose`, which creates a new pod (and a Service for it), not a Service exposing the existing 'web' Deployment. Option E creates a ClusterIP Service named 'web' but with no selector tied to the Deployment's pods, so it would not route traffic to the Deployment's replicas.

Answer

kubectl port-forward deployment/web 8080:80

Answer

kubectl run web --image=nginx --port=80 --expose

Answer

kubectl create service clusterip web --tcp=80:80

Question 4

Which THREE of the following are requirements for an Ingress resource to work?

Accepted Answer

An Ingress controller must be deployed in the cluster.. Option B is correct because an Ingress resource is only a declarative specification; without an Ingress controller (e.g., ingress-nginx, Traefik, HAProxy) running in the cluster, no component watches the Ingress object and programs the underlying load balancer or proxy, so no routing occurs. Option D is correct because the Ingress routes traffic to backend Services, and those Services must exist with ready endpoints (pods passing readiness probes) for requests to be forwarded; otherwise the controller returns 503 errors. Option E is correct because an Ingress spec requires rules containing at least one path (e.g., path: / with pathType: Prefix) mapping to a backend service and port; a rule with no path rules provides nothing to route. Option A is not required because the host field is optional — a rule without a host matches all inbound HTTP traffic. Option C is not required because TLS is optional; an Ingress can serve plain HTTP without a tls section.

Answer

The Ingress resource must specify a host.

Answer

The Ingress resource must have a TLS section.

Question 5

Which TWO of the following statements about NetworkPolicy are true?

Accepted Answer

A NetworkPolicy can have both ingress and egress rules.. Option A is correct because a single NetworkPolicy object can define both an ingress section (rules for incoming traffic to the selected pods) and an egress section (rules for outgoing traffic from the selected pods), allowing bidirectional control. Option C is correct because NetworkPolicies are additive: if multiple policies select the same pod, the union of all their rules applies, so a pod can be governed by several NetworkPolicies simultaneously. Option B is not correct because NetworkPolicy selectors work on pod, namespace, and IPBlock labels/selectors for peers, but the statement as phrased about filtering by source IP addresses alone is not the defining behavior being tested. Option D is not correct because NetworkPolicy is a namespaced resource, not cluster-scoped. Option E is not correct because by default pods are non-isolated and all ingress and egress traffic is allowed; isolation only occurs once a policy selects the pod.

Answer

NetworkPolicy can filter traffic based on source IP addresses.

Answer

NetworkPolicy is a cluster-scoped resource.

Answer

By default, pods are isolated and all traffic is denied.

Question 6

Which kubectl command creates a service of type NodePort that exposes a deployment named 'web' on port 80?

Accepted Answer

kubectl expose deployment web --type=NodePort --port=80. The `kubectl expose deployment web --type=NodePort --port=80` command creates a Service of type NodePort that exposes the 'web' deployment on port 80. The `--type=NodePort` flag explicitly sets the Service type to NodePort, and `--port=80` defines the port the Service listens on. By default, `kubectl expose` uses the container's target port from the deployment's pod template, so no `--target-port` is required if it matches the container port.

Answer

kubectl create service nodeport web --tcp=80:8080

Answer

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

Answer

kubectl create service clusterip web --tcp=80:8080

Question 7

Which of the following is a valid ClusterIP service definition that exposes port 80 and targets container port 8080?

Accepted Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080. Option B is correct. In Kubernetes, if the `spec.type` field is omitted, it defaults to `ClusterIP`. Thus, Option B is a valid ClusterIP service. Option A is incorrect because `type: ClusterIP` is defined at the root level of the YAML instead of under the `spec` field, which is invalid. Option C defines a NodePort service. Option D defines a LoadBalancer service. Option E lacks a selector to target the application pods.

Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
type: ClusterIP

Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: LoadBalancer

Answer

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Question 8

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 Service type that exposes a Service on a static port (in the range 30000-32767) on each node's IP address. When a NodePort Service is created, Kubernetes allocates a port from that range and opens that port on every node in the cluster, forwarding traffic to the Service's ClusterIP and then to the pods. This allows external traffic to reach the Service by hitting any node's IP address and the allocated NodePort.

Answer

LoadBalancer

Answer

ExternalName

Answer

ClusterIP

Question 9

You run `kubectl get endpoints my-service` and see no endpoints listed. The Service's selector matches labels on pods that are running. What is the most likely cause?

Accepted Answer

The pods are not passing their readiness probes. When a Service's selector matches running pods but no endpoints are listed, the most common cause is that the pods are failing their readiness probes. Kubernetes only includes a pod's IP address as an endpoint if the pod's readiness probe (if defined) succeeds. If the readiness probe fails, the pod is considered not ready to receive traffic, and its IP is removed from the endpoints list, even though the pod is running and its labels match the Service selector.

Answer

The kube-proxy is not running

Answer

The Service is in a different namespace

Answer

The Service type is ExternalName

Question 10

Which THREE of the following are true about NetworkPolicy? (Select THREE.)

Accepted Answer

NetworkPolicy requires a CNI plugin that supports it. Option C is correct because NetworkPolicy objects are only enforced by CNI plugins that implement the NetworkPolicy API (e.g., Calico, Cilium, Weave Net); with a plugin that does not support it (such as basic Flannel), policies are silently ignored. Option D is correct because Kubernetes NetworkPolicy is additive and default-allow: if no policy selects a given pod, all ingress and egress traffic to and from that pod is permitted. Option E is correct because a NetworkPolicy uses spec.podSelector to choose which pods in its namespace the policy applies to, allowing rules to target only a subset of pods rather than the whole namespace. Option A is wrong because NetworkPolicy is a namespaced resource, not cluster-scoped. Option B is wrong because NetworkPolicy supports both ingress and egress rules, and while it is additive (no explicit deny rules), it can effectively deny traffic by selecting a pod and not allowing the undesired traffic, so the blanket claim that it can 'only allow, not deny' is inaccurate.

Answer

NetworkPolicy is a cluster-scoped resource

Answer

NetworkPolicy can only allow traffic, not deny

Question 11

Which of the following is true about IngressClass resources?

Accepted Answer

IngressClass replaces the deprecated 'kubernetes.io/ingress.class' annotation. The IngressClass resource is a cluster-scoped resource that is the recommended way to specify which ingress controller should implement an Ingress, replacing the deprecated `kubernetes.io/ingress.class` annotation. It does not contain routing rules (which are defined in the Ingress resource itself via `spec.rules`).

Answer

IngressClass must have a controller field set to the name of the ingress controller

Answer

IngressClass is namespaced

Answer

IngressClass is automatically created by the ingress controller

Question 12

Which two statements are true about EndpointSlices? (Choose two.)

Accepted Answer

EndpointSlices can contain multiple endpoints per slice. Option B is correct because an EndpointSlice is designed to hold up to 100 endpoints by default (controlled by the --max-endpoints-per-slice kube-controller-manager flag), allowing a single slice to represent multiple pod IP/port combinations rather than one endpoint per object. Option E is correct because EndpointSlices are namespaced resources, just like the Services they back, so they live under a specific namespace and are addressed as endpointslices.discovery.k8s.io within that namespace. Option A is wrong because EndpointSlices back all Services with selectors, not only headless Services (clusterIP: None); regular ClusterIP Services also get EndpointSlices. Option C is wrong because the Endpoints resource is not deprecated and EndpointSlices do not replace it outright; both coexist, with the EndpointSlice controller mirroring data into Endpoints for compatibility. Option D is wrong because EndpointSlices can be created manually via kubectl or the API, which is useful for manually managing endpoints for Services without selectors.

Answer

EndpointSlices are only used by headless Services

Answer

EndpointSlices replace the deprecated Endpoints resource

Answer

EndpointSlices cannot be created manually

Question 13

You deploy a pod named 'app' that listens on port 3000. You create a Service named 'app-svc' with selector 'app: app'. From another pod in the same namespace, which command will successfully reach the service?

Accepted Answer

curl app-svc:80. When connecting to a Kubernetes Service, clients must send traffic to the Service's own port (`port`), not the Pod's port (`targetPort`). The Service (via kube-proxy) then routes and translates this traffic to the Pod's `targetPort`. Since the Service 'app-svc' is configured with `port: 80` and `targetPort: 3000`, other pods in the cluster must access it using the Service's port (80), making `curl app-svc:80` the correct command.

Answer

curl app-svc.default.svc.cluster.local:3000

Answer

curl app-svc:3000

Answer

curl app:3000

Question 14

You are designing an Ingress to expose multiple services on the same hostname based on path. Which Ingress specification is valid?

Accepted Answer

spec.rules[0].host: example.com; spec.rules[0].http.paths[0].path: /api; backend.service.name: api-svc; spec.rules[0].http.paths[1].path: /web; backend.service.name: web-svc. It defines a single rule with multiple paths under the same host, which is the standard method for path-based routing to multiple services. Option B is incorrect because it uses separate rules for each path; this is not the recommended approach and can lead to unpredictable behavior, as Ingress controllers may only evaluate the first matching rule, potentially ignoring later paths. Therefore, the proper specification is to consolidate all paths under one rule for the same host.

Answer

spec.rules[0].host: example.com; spec.rules[0].http.paths[0].path: /api; backend.service.name: api-svc; spec.rules[1].host: example.com; spec.rules[1].http.paths[0].path: /web; backend.service.name: web-svc

Question 15

Which THREE of the following statements about Kubernetes DNS are correct?

Accepted Answer

A pod's hostname is set to its pod name by default.. Option C is correct because Kubernetes sets a pod's hostname to its pod name by default (via the kubelet's --hostname-override behavior and the pod's metadata.name), so the pod's hostname matches the pod name unless overridden. Option D is correct because a Service's DNS name (e.g., my-svc.my-namespace.svc.cluster.local) resolves to the Service's ClusterIP, which is the stable virtual IP used for load balancing to backing pods. Option E is correct because CoreDNS creates SRV records for Services that define named ports, allowing clients to discover port numbers via DNS SRV lookups (e.g., _http._tcp.my-svc.my-namespace.svc.cluster.local). Option A is incorrect because Services are resolvable across namespaces using the fully qualified form ..svc.cluster.local, not only within their own namespace. Option B is incorrect because pods do not get A records resolving to their container IP by default; pod DNS records are typically headless Service-based or hostname-based, and the container IP is not exposed via a standard pod A record.

Answer

Services are only resolvable within their own namespace.

Answer

Pods have A records that resolve to their container IP.

Question 16

Which TWO of the following are valid IngressClass annotations or fields?

Accepted Answer

spec.ingressClassName. Option A, spec.ingressClassName, is correct because the Ingress resource includes a spec.ingressClassName field that references the name of an IngressClass object, allowing the Ingress to be associated with a specific controller implementation. Option D, spec.controller, is correct because the IngressClass resource itself defines a spec.controller field that specifies the name of the controller responsible for handling Ingresses of that class (for example, k8s.io/ingress-nginx). Options B, C, and E are not valid IngressClass annotations or fields: spec.rules, spec.tls, and spec.defaultBackend are fields of the Ingress resource's spec, not of the IngressClass resource, and they define routing rules, TLS configuration, and a default backend respectively.

Answer

spec.rules

Answer

spec.tls

Answer

spec.defaultBackend

Question 17

Which three of the following are true about IngressClass?

Accepted Answer

An IngressClass can be marked as default by adding the annotation 'ingressclass.kubernetes.io/is-default-class: true'.. Option A is correct because Kubernetes designates a default IngressClass via the annotation 'ingressclass.kubernetes.io/is-default-class: true', which causes Ingresses lacking an ingressClassName to use that class. Option B is correct because an IngressClass contains a required 'controller' field that names the controller responsible for handling the class, e.g. 'nginx.org/ingress-controller'. Option E is correct because when multiple IngressClasses exist and no default is set, an Ingress must explicitly specify its class via spec.ingressClassName (or the deprecated annotation) so the correct controller handles it. Option C is wrong because IngressClass is a cluster-scoped resource, not namespaced. Option D is wrong because a cluster may define many IngressClasses, though only one should be marked as default.

Answer

IngressClass is a namespaced resource.

Answer

Each cluster can only have one IngressClass.

Question 18

An administrator creates a Service of type ClusterIP named 'my-svc' in the namespace 'default'. A pod in the same namespace tries to resolve the hostname 'my-svc' but fails. The pod's resolv.conf shows 'search default.svc.cluster.local svc.cluster.local cluster.local'. What is the most likely cause?

Accepted Answer

The Service does not exist or is in a different namespace. The pod's resolv.conf includes 'default.svc.cluster.local' as a search domain, meaning the pod will attempt to resolve 'my-svc' as 'my-svc.default.svc.cluster.local'. If the Service does not exist in the 'default' namespace, or if it exists in a different namespace, CoreDNS will return NXDOMAIN, causing resolution to fail. The search domains are automatically appended based on the pod's namespace, so a missing Service in the same namespace is the most likely cause.

Answer

The pod's DNS policy is set to 'None'

Answer

The pod is using hostNetwork and bypasses CoreDNS

Answer

The Service type is ExternalName

Question 19

A cluster administrator applies the following NetworkPolicy. What is the effect on pods matching the podSelector?

Accepted Answer

All ingress and egress traffic is denied. The NetworkPolicy shown has a `podSelector` that matches specific pods, but it has no `ingress` or `egress` rules defined under the `spec` (the rules arrays are empty). According to Kubernetes NetworkPolicy semantics, if a policy selects a pod, that pod's traffic is isolated: any empty `ingress` rules block all ingress traffic, and any empty `egress` rules block all egress traffic. Since both `ingress` and `egress` are present with empty rules, all ingress and egress traffic to/from the matched pods is denied.

Answer

All ingress traffic is denied, but egress is allowed

Answer

All ingress and egress traffic is allowed

Answer

Only traffic from pods in the same namespace is allowed

Question 20

An Ingress resource is defined with the following spec snippet. What is the minimal requirement for this Ingress to work correctly?

Accepted Answer

An IngressClass named 'nginx' must be defined and a compatible Ingress controller must be running. For an Ingress to work, an Ingress controller must be running and the referenced IngressClass must exist (if specified). Additionally, the backend Service must be in the same namespace as the Ingress. Both are required; the controller is often the overlooked part, but the namespace constraint is also a mandatory condition.

Answer

The Ingress must have a TLS section configured

Answer

A Service named 'api-svc' of type NodePort must exist