Services &amp; Networking practice questions

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?

Trap 1: The container port is 8080 but the Service targetPort is 80.

The Service targetPort is 8080, which matches the container port.

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

ClusterIP is sufficient for inter-pod communication within the cluster.

Trap 3: The DNS resolution for 'app-service' is failing.

DNS resolution would result in a different error (name resolution failure).

A
The Service selector does not match the pod labels.
If labels don't match, the Service has no endpoints, causing connection refused.
B
The container port is 8080 but the Service targetPort is 80.
Why wrong: The Service targetPort is 8080, which matches the container port.
C
The Service type should be NodePort for inter-pod communication.
Why wrong: ClusterIP is sufficient for inter-pod communication within the cluster.
D
The DNS resolution for 'app-service' is failing.
Why wrong: DNS resolution would result in a different error (name resolution failure).

Question 2mediummultiple choice

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?

Trap 1: ExternalName Service

ExternalName is used to alias an external DNS name, not for internal pods.

Trap 2: NodePort Service

NodePort exposes on each node's port but does not provide per-pod DNS.

Trap 3: ClusterIP with a regular Service

Regular ClusterIP Service provides a single virtual IP, not per-pod DNS.

A
ExternalName Service
Why wrong: ExternalName is used to alias an external DNS name, not for internal pods.
B
NodePort Service
Why wrong: NodePort exposes on each node's port but does not provide per-pod DNS.
C
ClusterIP with a regular Service
Why wrong: Regular ClusterIP Service provides a single virtual IP, not per-pod DNS.
D
Headless Service (ClusterIP: None)
Headless Service returns individual pod IPs via DNS, suitable for stateful apps.

Question 3hardmultiple choice

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?

Trap 1: db-service.svc.cluster.local

Missing the namespace component.

Trap 2: db-service

This only works if the Service is in the same namespace.

Trap 3: db-service.backend.cluster.local

Incorrect domain; should be 'svc.cluster.local'.

A
db-service.svc.cluster.local
Why wrong: Missing the namespace component.
B
db-service
Why wrong: This only works if the Service is in the same namespace.
C
db-service.backend.cluster.local
Why wrong: Incorrect domain; should be 'svc.cluster.local'.
D
db-service.backend.svc.cluster.local
This is the correct FQDN for cross-namespace access.

Question 4easymultiple choice

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?

Trap 1: The node's DNS server (8.8.8.8)

The pod does not directly use the node's resolv.conf; it uses the cluster DNS.

Trap 2: There is no DNS resolution; the pod cannot resolve external names…

External resolution works via cluster DNS forwarding.

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

The pod's resolv.conf is set by kubelet to point to cluster DNS.

A
The node's DNS server (8.8.8.8)
Why wrong: The pod does not directly use the node's resolv.conf; it uses the cluster DNS.
B
There is no DNS resolution; the pod cannot resolve external names by default
Why wrong: External resolution works via cluster DNS forwarding.
C
The cluster DNS service (10.96.0.10)
Default policy sends queries to the cluster DNS first.
D
The pod's own /etc/resolv.conf which contains the node's DNS
Why wrong: The pod's resolv.conf is set by kubelet to point to cluster DNS.

Question 5mediummultiple choice

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?

Trap 1: The Service port name does not match the container port name.

Port names are optional; if not used, matching is by port number.

Trap 2: The Service type is ClusterIP.

ClusterIP Services can have endpoints.

Trap 3: The Service targetPort is not specified.

If targetPort is omitted, it defaults to the same as port.

A
The Service port name does not match the container port name.
Why wrong: Port names are optional; if not used, matching is by port number.
B
The Service type is ClusterIP.
Why wrong: ClusterIP Services can have endpoints.
C
The Service targetPort is not specified.
Why wrong: If targetPort is omitted, it defaults to the same as port.
D
The pods are not in Ready state (e.g., failing readiness probes).
Only Ready pods are included as endpoints.

Question 6hardmultiple choice

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?

Trap 1: Calico is not configured with an overlay network.

Calico can work without an overlay using BGP; lack of overlay is not the issue.

Trap 2: A NetworkPolicy is blocking inter-node traffic.

The scenario says network policies are not enforced.

Trap 3: The pods are using different Service types.

Service type does not affect pod-to-pod communication.

A
Calico is not configured with an overlay network.
Why wrong: Calico can work without an overlay using BGP; lack of overlay is not the issue.
B
A NetworkPolicy is blocking inter-node traffic.
Why wrong: The scenario says network policies are not enforced.
C
The pods are using different Service types.
Why wrong: Service type does not affect pod-to-pod communication.
D
The nodes' firewalls are blocking required ports for Calico (e.g., BGP port 179 or VXLAN port 4789).
Calico needs inter-node communication; firewall blocking can prevent pod-to-pod across nodes.

Read the full NAT/PAT explanation →

Question 7mediummultiple choice

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?

Trap 1: LoadBalancer Service

LoadBalancer provides a stable IP but TLS termination requires additional configuration (e.g., an Ingress or a cloud LB).

Trap 2: ClusterIP Service

ClusterIP is only accessible within the cluster.

Trap 3: NodePort Service

NodePort does not provide a stable IP; uses node IPs that may change.

A
LoadBalancer Service
Why wrong: LoadBalancer provides a stable IP but TLS termination requires additional configuration (e.g., an Ingress or a cloud LB).
B
ClusterIP Service
Why wrong: ClusterIP is only accessible within the cluster.
C
Ingress resource with a TLS certificate
Ingress provides a stable IP and can terminate TLS.
D
NodePort Service
Why wrong: NodePort does not provide a stable IP; uses node IPs that may change.

Question 8easymulti select

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

Trap 1: To provide a single stable IP address for the service.

Headless Service does not have a ClusterIP.

Trap 2: To expose a service externally via a cloud load balancer.

External exposure requires NodePort or LoadBalancer Service.

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

Load balancing requires a ClusterIP Service.

A
To provide a single stable IP address for the service.
Why wrong: Headless Service does not have a ClusterIP.
B
To expose a service externally via a cloud load balancer.
Why wrong: External exposure requires NodePort or LoadBalancer Service.
C
To enable a client to discover all pod IPs for a StatefulSet.
Headless Service is used with StatefulSets for pod identity.
D
To enable DNS to return individual pod IPs for stateful applications.
Headless Service returns pod IPs via DNS.
E
To provide load-balanced access to a set of pods.
Why wrong: Load balancing requires a ClusterIP Service.

Question 9hardmulti select

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

Trap 1: They can block traffic at the node level.

Network Policies operate at the pod level, not node level.

Trap 2: They can modify packet contents.

Network Policies only allow/deny; they do not modify packets.

A
They can block traffic at the node level.
Why wrong: Network Policies operate at the pod level, not node level.
B
They are namespaced resources.
Network Policies are defined within a namespace and apply to pods in that namespace.
C
They are enforced by the network plugin (CNI).
Network Policy enforcement depends on the CNI plugin.
D
They can allow ingress traffic from pods with specific labels.
Ingress rules can select pods by label.
E
They can modify packet contents.
Why wrong: Network Policies only allow/deny; they do not modify packets.

Question 10mediummultiple choice

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?

Exhibit

Refer to the exhibit.

```
$ kubectl describe svc my-service
Name:              my-service
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          app=my-app
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.100.10
IPs:               10.96.100.10
Port:              http  80/TCP
TargetPort:        8080/TCP
Endpoints:         <none>
```

Trap 1: The Service type is ClusterIP, which cannot be accessed from within…

ClusterIP is designed for internal access.

Trap 2: The port name 'http' is invalid.

Port names are optional and 'http' is valid.

Trap 3: The targetPort is 8080, but the container port is not 8080.

The exhibit does not show container ports, but if it were wrong, endpoints would still exist but traffic would fail.

A
The Service type is ClusterIP, which cannot be accessed from within the cluster.
Why wrong: ClusterIP is designed for internal access.
B
No pods match the selector or the matching pods are not ready.
Endpoints are empty, so no ready pods are available.
C
The port name 'http' is invalid.
Why wrong: Port names are optional and 'http' is valid.
D
The targetPort is 8080, but the container port is not 8080.
Why wrong: The exhibit does not show container ports, but if it were wrong, endpoints would still exist but traffic would fail.

Question 11hardmultiple choice

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?

Exhibit

Refer to the exhibit.

```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
```

Trap 1: The Ingress rule blocks all incoming traffic, preventing DNS…

The problem is egress, not ingress; DNS responses are not blocked by egress rules.

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

The policy is in the default namespace and only affects that namespace.

Trap 3: The policy only applies to pods with specific labels.

The podSelector is empty, meaning it applies to all pods.

A
The Egress rule is defined but has no allow rules, so all egress is denied.
With policyTypes including Egress and no egress rules, all egress is denied.
B
The Ingress rule blocks all incoming traffic, preventing DNS responses.
Why wrong: The problem is egress, not ingress; DNS responses are not blocked by egress rules.
C
The policy is applied to all namespaces, causing a conflict.
Why wrong: The policy is in the default namespace and only affects that namespace.
D
The policy only applies to pods with specific labels.
Why wrong: The podSelector is empty, meaning it applies to all pods.

Question 12hardmultiple choice

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?

Trap 1: Change the Service type to NodePort to bypass the Ingress.

Changing Service type does not affect endpoint creation; the root cause is missing endpoints.

Trap 2: Update the Ingress to use a different backend service.

The Ingress is correctly configured; the issue is with the Service itself.

Trap 3: Modify the Service selector to match the pod labels exactly.

The selector already matches 'app: web'; this would not change anything.

A
Change the Service type to NodePort to bypass the Ingress.
Why wrong: Changing Service type does not affect endpoint creation; the root cause is missing endpoints.
B
Update the Ingress to use a different backend service.
Why wrong: The Ingress is correctly configured; the issue is with the Service itself.
C
Check the container port and readiness probe configuration; the pods may not be listening on the expected port or the readiness probe is failing.
Empty endpoints indicate no ready pods matching the selector; despite 'Ready' status, the readiness probe might be failing if not configured, or the container might not be listening on 3000.
D
Modify the Service selector to match the pod labels exactly.
Why wrong: The selector already matches 'app: web'; this would not change anything.

Question 13mediummultiple choice

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?

Trap 1: Change the Service type to NodePort

NodePort exposes the service externally but does not affect internal session stickiness.

Trap 2: Remove the ClusterIP Service and use headless service

Headless service returns pod IPs directly, which may cause DNS caching issues and worsen connectivity.

Trap 3: Add a readiness probe to the pods

Readiness probes ensure pods are ready but do not provide session stickiness.

A
Change the Service type to NodePort
Why wrong: NodePort exposes the service externally but does not affect internal session stickiness.
B
Set service.spec.sessionAffinity to ClientIP
ClientIP session affinity ensures requests from the same client are routed to the same pod, resolving intermittent connectivity due to session state.
C
Remove the ClusterIP Service and use headless service
Why wrong: Headless service returns pod IPs directly, which may cause DNS caching issues and worsen connectivity.
D
Add a readiness probe to the pods
Why wrong: Readiness probes ensure pods are ready but do not provide session stickiness.

Question 14hardmulti select

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

Trap 1: The database pods can accept traffic on any port from pods with…

The rule only allows traffic on port 5432.

Trap 2: Pods in other namespaces with label 'app: api' cannot reach the…

NetworkPolicy by default only applies within the same namespace; cross-namespace traffic is blocked unless explicitly allowed.

Trap 3: Pods from the same namespace but without matching labels can still…

The policy is namespace-scoped; pods without matching labels are not allowed unless explicitly allowed.

A
The database pods can accept traffic on any port from pods with label 'app: api'.
Why wrong: The rule only allows traffic on port 5432.
B
Pods in other namespaces with label 'app: api' cannot reach the database pods.
Why wrong: NetworkPolicy by default only applies within the same namespace; cross-namespace traffic is blocked unless explicitly allowed.
C
The database pods can initiate outbound connections to any destination.
Since only Ingress is specified, egress is allowed by default.
D
Pods from the same namespace but without matching labels can still access the database pods.
Why wrong: The policy is namespace-scoped; pods without matching labels are not allowed unless explicitly allowed.
E
Pods with label 'app: api' can connect to the database pods on TCP port 5432.
The ingress rule explicitly allows pods with label app:api on port 5432.

Question 15easymultiple choice

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

Exhibit

Refer to the exhibit.

$ kubectl get svc my-service -o yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  clusterIP: 10.96.0.1
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: my-app
  type: ClusterIP
status:
  loadBalancer: {}

$ kubectl get endpoints my-service
NAME         ENDPOINTS          AGE
my-service   192.168.1.10:8080  5m

Trap 1: The connection succeeds but reaches the pod on port 80.

The targetPort is 8080, not 80.

Trap 2: The connection fails because the endpoints list is empty.

The endpoints list is not empty; it contains one endpoint.

Trap 3: The connection is randomly dropped due to missing port…

The port specification is present and correct.

A
The connection succeeds but reaches the pod on port 80.
Why wrong: The targetPort is 8080, not 80.
B
The connection fails because the endpoints list is empty.
Why wrong: The endpoints list is not empty; it contains one endpoint.
C
The connection is randomly dropped due to missing port specification.
Why wrong: The port specification is present and correct.
D
The connection succeeds and reaches the pod on port 8080.
The service is correctly configured with endpoints mapping port 80 to targetPort 8080.

Question 16hardmultiple choice

You are a platform engineer managing a multi-tenant Kubernetes cluster. A development team deploys a StatefulSet for a database with the following configuration: 3 replicas, headless service 'db-headless' for DNS-based discovery, and a regular ClusterIP service 'db' for read/write operations. The cluster uses Calico CNI with default NetworkPolicy enforcement. The team reports that applications in the same namespace can connect to the ClusterIP service but cannot connect to individual pod DNS names (e.g., db-0.db-headless.namespace.svc.cluster.local). You verify that the DNS resolution works (nslookup returns the pod IP). However, a curl to the pod IP on the database port (5432) times out. You check the endpoints and they are correct. Which action should you take to resolve the connectivity issue?

Trap 1: Modify the CoreDNS configuration to use a different DNS policy.

DNS resolution is working correctly; the issue is network policy, not DNS.

Trap 2: Remove the headless service and use a regular ClusterIP service for…

Headless service is the recommended pattern for StatefulSet DNS-based pod identity. Removing it would break pod identity.

Trap 3: Change the ClusterIP service 'db' to NodePort to expose the…

Changing service type does not affect direct pod IP connectivity within the cluster.

A
Modify the CoreDNS configuration to use a different DNS policy.
Why wrong: DNS resolution is working correctly; the issue is network policy, not DNS.
B
Create a NetworkPolicy that allows ingress traffic from all pods in the namespace to the database pods on port 5432.
This policy would explicitly allow direct pod-to-pod traffic, which is currently blocked by a default-deny policy.
C
Remove the headless service and use a regular ClusterIP service for pod discovery.
Why wrong: Headless service is the recommended pattern for StatefulSet DNS-based pod identity. Removing it would break pod identity.
D
Change the ClusterIP service 'db' to NodePort to expose the database on each node.
Why wrong: Changing service type does not affect direct pod IP connectivity within the cluster.

Question 17easymulti select

Which TWO of the following are valid ways to expose a Kubernetes Service to external traffic?

Trap 1: ClusterIP

ClusterIP is only reachable within the cluster.

Trap 2: ExternalName

ExternalName maps to an external DNS name, not exposing a service.

Trap 3: Headless

Headless services are used for stateful workloads; they don't expose external traffic.

A
LoadBalancer
LoadBalancer provisions an external load balancer from the cloud provider.
B
ClusterIP
Why wrong: ClusterIP is only reachable within the cluster.
C
ExternalName
Why wrong: ExternalName maps to an external DNS name, not exposing a service.
D
NodePort
NodePort exposes the service on a static port on each node, allowing external traffic.
E
Headless
Why wrong: Headless services are used for stateful workloads; they don't expose external traffic.

Question 18hardmultiple choice

You are a Kubernetes administrator overseeing a multi-tier application in a production cluster. The application consists of a front-end web server (Deployment 'frontend') and a backend API (Deployment 'backend'). The frontend needs to communicate with the backend using the DNS name 'backend-service' within the same namespace 'prod'. Users report intermittent 'Connection Refused' errors when accessing the frontend, which then cannot reach the backend. After checking the backend pods, they are all running and ready. The backend Service is defined as a ClusterIP service with no ports specified in the YAML manifest. What is the most likely cause of the failure?

Trap 1: The backend pods are listening on a different port than expected by…

That would cause connection timeout, not immediate refusal.

Trap 2: The 'kube-proxy' is not running on the node where the frontend pod…

This would affect all services, not just backend.

Trap 3: A NetworkPolicy in the 'prod' namespace is blocking traffic from…

NetworkPolicy would drop packets (timeout), not immediately refuse.

A
The backend Service manifest is missing the 'ports' field, so it has no endpoints.
Without ports, the Service does not forward traffic, leading to connection refused.
B
The backend pods are listening on a different port than expected by the frontend.
Why wrong: That would cause connection timeout, not immediate refusal.
C
The 'kube-proxy' is not running on the node where the frontend pod is scheduled.
Why wrong: This would affect all services, not just backend.
D
A NetworkPolicy in the 'prod' namespace is blocking traffic from the frontend to the backend.
Why wrong: NetworkPolicy would drop packets (timeout), not immediately refuse.

Question 19mediumdrag order

Drag and drop the steps to upgrade a Kubernetes cluster using kubeadm into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 20mediumdrag order