CKA Services & Networking Practice Test 1 — 15 Questions

Question 1

A developer created a Deployment with 3 replicas and a ClusterIP Service named 'app-service' on port 80 targeting port 8080 on the pods. Pod logs show that the container is listening on 8080, but curl from another pod in the same namespace to http://app-service:80 fails with 'Connection refused'. What is the most likely cause?

Accepted Answer

The Service selector does not match the pod labels.. The most likely cause is that the Service's selector does not match the pod labels. A ClusterIP Service routes traffic to pods based on label selectors; if the selector does not match the labels on the pods (e.g., the pods have labels like 'app: myapp' but the Service selector is 'app: frontend'), the endpoints controller will not populate the Service's endpoints, and traffic will be dropped, resulting in a 'Connection refused' error.

Answer

The container port is 8080 but the Service targetPort is 80.

Answer

The Service type should be NodePort for inter-pod communication.

Answer

The DNS resolution for 'app-service' is failing.

Question 2

An administrator needs to expose a set of pods running a stateful application that require stable network identities. The pods must be reachable from outside the cluster via a DNS name that resolves to individual pod IPs. Which Service type should be used?

Accepted Answer

Headless Service (ClusterIP: None). A Headless Service (ClusterIP: None) is correct because it allows clients to discover individual pod IPs via DNS lookups, returning A/AAAA records for each pod rather than a single ClusterIP. This provides stable network identities for stateful pods, as each pod gets a unique DNS name (e.g., pod-name.service-name.namespace.svc.cluster.local) that resolves directly to its IP, enabling external access through a DNS-based discovery mechanism.

Answer

ExternalName Service

Answer

NodePort Service

Answer

ClusterIP with a regular Service

Question 3

A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?

Accepted Answer

db-service.backend.svc.cluster.local. Option D is correct because Kubernetes DNS resolves services using the format `..svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).

Answer

db-service.svc.cluster.local

Answer

db-service

Answer

db-service.backend.cluster.local

Question 4

A pod is running with the default DNS policy. The cluster DNS service is at 10.96.0.10. The node's /etc/resolv.conf has nameserver 8.8.8.8. When the pod tries to resolve an external hostname like 'example.com', which DNS server will it query first?

Accepted Answer

The cluster DNS service (10.96.0.10). With the default DNS policy (ClusterFirst), pods are configured to use the cluster DNS service (10.96.0.10) as the first nameserver in their /etc/resolv.conf. This is achieved by kubelet injecting the cluster DNS IP and a search domain into the pod's resolv.conf. Therefore, the pod will query the cluster DNS service first for any hostname resolution, including external names like 'example.com'.

Answer

The node's DNS server (8.8.8.8)

Answer

There is no DNS resolution; the pod cannot resolve external names by default

Answer

The pod's own /etc/resolv.conf which contains the node's DNS

Question 5

An administrator notices that traffic to a Service is not being forwarded to any pod. The Service has selector 'app: web' and there are pods with that label. However, 'kubectl get endpoints' shows no endpoints. What is the most likely cause?

Accepted Answer

The pods are not in Ready state (e.g., failing readiness probes).. The most likely cause is that the pods are not in Ready state, often due to failing readiness probes. Kubernetes endpoints are only populated for pods that pass their readiness checks; if a pod is not Ready, it is removed from the Service's endpoint list, even if it is running and has the correct labels.

Answer

The Service port name does not match the container port name.

Answer

The Service type is ClusterIP.

Answer

The Service targetPort is not specified.

Question 6

A Kubernetes cluster uses Calico as the CNI plugin. Two pods on different nodes cannot communicate, but pods on the same node can. Network policies are not enforced. What is the most likely cause?

Accepted Answer

The nodes' firewalls are blocking required ports for Calico (e.g., BGP port 179 or VXLAN port 4789).. Option D is correct because Calico relies on specific ports for inter-node communication. When using BGP (default), port 179 must be open; when using VXLAN overlay, port 4789 is required. If node firewalls block these ports, Calico cannot establish routes or encapsulate traffic between nodes, causing cross-node pod communication to fail while same-node communication (which uses the local bridge) remains unaffected.

Answer

Calico is not configured with an overlay network.

Answer

A NetworkPolicy is blocking inter-node traffic.

Answer

The pods are using different Service types.

Question 7

A company wants to expose a web application running as a Deployment with 3 replicas to external users. They need a stable IP address that does not change and the ability to terminate TLS. Which resource should they use?

Accepted Answer

Ingress resource with a TLS certificate. An Ingress resource with a TLS certificate is the correct choice because it provides a stable IP address (via the underlying LoadBalancer or NodePort Service) and terminates TLS at the ingress controller, allowing the web application to serve HTTPS traffic without modifying the Deployment. This meets the requirements of exposing the application externally with a fixed IP and TLS termination.

Answer

LoadBalancer Service

Answer

ClusterIP Service

Answer

NodePort Service

Question 8

Which TWO of the following are valid reasons to use a Headless Service?

Accepted Answer

To enable a client to discover all pod IPs for a StatefulSet.. Option C is correct because a Headless Service (with `clusterIP: None`) does not provide a single stable IP or load balancing. Instead, it returns DNS A/AAAA records for all pod IPs that match the service's selector. This is essential for StatefulSets, where each pod has a unique identity and clients need to discover and connect to specific pods directly, such as in a database cluster.

Answer

To provide a single stable IP address for the service.

Answer

To expose a service externally via a cloud load balancer.

Answer

To provide load-balanced access to a set of pods.

Question 9

Which THREE of the following are true about Network Policies in Kubernetes?

Accepted Answer

They are namespaced resources.. Network Policies are namespaced resources in Kubernetes, meaning they are defined within a specific namespace and only apply to pods in that namespace. This is confirmed by the Kubernetes API, where NetworkPolicy is a namespaced resource under the networking.k8s.io/v1 API group, and it cannot be applied cluster-wide without additional tooling like a cluster-scoped policy engine.

Answer

They can block traffic at the node level.

Answer

They can modify packet contents.

Question 10

A pod in the same namespace tries to reach 'my-service' on port 80, but gets 'Connection refused'. The pod's labels are 'app: my-app'. What is the most likely cause?

Accepted Answer

No pods match the selector or the matching pods are not ready.. A 'Connection refused' error indicates that the TCP connection request reached the target IP and port, but no process was listening there. For a Kubernetes Service, this most commonly occurs when the Service's selector does not match any pod labels, or the matching pods are not in a Ready state, so the endpoints controller does not populate the Service's endpoints list, and kube-proxy has no backends to forward traffic to.

Answer

The Service type is ClusterIP, which cannot be accessed from within the cluster.

Answer

The port name 'http' is invalid.

Answer

The targetPort is 8080, but the container port is not 8080.

Question 11

After applying this NetworkPolicy, a pod in the default namespace tries to curl an external website (e.g., google.com) and fails. What is the reason?

Accepted Answer

The Egress rule is defined but has no allow rules, so all egress is denied.. Option A is correct because the NetworkPolicy defines an Egress rule with an empty `rules` array, which means no egress traffic is explicitly allowed. In Kubernetes, when a NetworkPolicy selects a pod, it defaults to denying all traffic of the specified direction unless explicitly allowed. Since the Egress rule has no allow rules, all outbound traffic from the selected pods, including HTTP/HTTPS requests to external websites like google.com, is blocked by the policy.

Answer

The Ingress rule blocks all incoming traffic, preventing DNS responses.

Answer

The policy is applied to all namespaces, causing a conflict.

Answer

The policy only applies to pods with specific labels.

Question 12

You are tasked with troubleshooting a web application that is deployed in a Kubernetes cluster. The application consists of a Deployment named 'web-app' with 3 replicas, each running a container that listens on port 3000. A Service named 'web-service' of type ClusterIP with selector 'app: web' and port 80 targeting port 3000 has been created. Additionally, an Ingress resource named 'web-ingress' is configured with a host rule for 'example.com' and backend service 'web-service' on port 80. Users report that accessing http://example.com results in a 503 Service Unavailable error. You verify that all pods are running and ready (kubectl get pods shows 3/3 ready). The Ingress controller logs show 'upstream connect error or disconnect/reset before headers'. You check the endpoints: 'kubectl get endpoints web-service' shows no endpoints. The pods have the label 'app: web'. What should you do to resolve the issue?

Accepted Answer

Check the container port and readiness probe configuration; the pods may not be listening on the expected port or the readiness probe is failing.. Option C is correct because the absence of endpoints for the Service indicates that the Service's selector is not matching any pods, or the pods are not listening on the correct port. Since the pods have the label 'app: web' and the Service uses 'app: web', the issue is likely that the container port (3000) is misconfigured or the readiness probe is failing, causing the pods to be removed from the Service's endpoints. The Ingress controller's 'upstream connect error' confirms that traffic cannot reach the pods, which aligns with the missing endpoints.

Answer

Change the Service type to NodePort to bypass the Ingress.

Answer

Update the Ingress to use a different backend service.

Answer

Modify the Service selector to match the pod labels exactly.

Question 13

A company deploys a web application with multiple replicas in a Kubernetes cluster. Users report intermittent connectivity issues. The application pods are exposed via a ClusterIP Service. To ensure stable connectivity, which action should be taken?

Accepted Answer

Set service.spec.sessionAffinity to ClientIP. Intermittent connectivity issues with multiple replicas often stem from requests being distributed across different pods, which can break session state if the application is not stateless. Setting `service.spec.sessionAffinity` to `ClientIP` ensures that all requests from a given client IP are routed to the same pod, providing stable connectivity for stateful sessions without changing the service type or removing the ClusterIP.

Answer

Change the Service type to NodePort

Answer

Remove the ClusterIP Service and use headless service

Answer

Add a readiness probe to the pods

Question 14

A Kubernetes cluster uses a NetworkPolicy to restrict traffic to a set of pods labeled 'app: db'. Which TWO statements about the following NetworkPolicy are correct?

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
spec:
  podSelector:
    matchLabels:
      app: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - port: 5432

Accepted Answer

The database pods can initiate outbound connections to any destination.. Option C is correct because NetworkPolicy only restricts inbound (Ingress) traffic when `policyTypes` includes only `Ingress`. By default, if no Egress rules are defined and `policyTypes` does not include `Egress`, outbound traffic is unrestricted. Thus, the database pods can initiate connections to any destination.

Answer

The database pods can accept traffic on any port from pods with label 'app: api'.

Answer

Pods in other namespaces with label 'app: api' cannot reach the database pods.

Answer

Pods from the same namespace but without matching labels can still access the database pods.

Question 15

Given the exhibit, a pod in the same namespace tries to reach my-service on port 80. What is the most likely outcome?

Accepted Answer

The connection succeeds and reaches the pod on port 8080.. Option D is correct because a Kubernetes Service without an explicit `targetPort` defaults to the same value as the `port` field. In this case, `my-service` is defined with `port: 80` and no `targetPort`, so traffic sent to port 80 is forwarded to the pod's port 80. However, the exhibit shows the pod container listening on port 8080, so the connection would actually fail unless the Service explicitly sets `targetPort: 8080`. The question implies the Service has `targetPort: 8080` (or the pod is on port 80), but based on standard Kubernetes behavior, if the Service has `port: 80` and no `targetPort`, it defaults to port 80, not 8080. Given the answer key marks D as correct, the intended scenario is that the Service's `targetPort` is set to 8080, so traffic reaches the pod on port 8080.

Answer

The connection succeeds but reaches the pod on port 80.

Answer

The connection fails because the endpoints list is empty.

Answer

The connection is randomly dropped due to missing port specification.