Services and Networking practice questions

Service of type NodePort

Why wrong: A NodePort Service exposes the Pods on a static port (30000–32767) on every node, making them reachable from outside the cluster via nodeIP:nodePort. For internal-only Pod-to-Pod communication, this is unnecessary and creates an external network exposure surface that increases security risk and consumes a node port that may conflict with other services. Since the frontend Pods only need to reach the backend inside the cluster, a ClusterIP Service provides the required stable internal IP without opening any external ingress path.

Service of type LoadBalancer

Why wrong: A LoadBalancer Service provisions a cloud provider load balancer (e.g., AWS ELB, GCP LB, Azure LB) and assigns a public IP address, providing external access to the Pods from the internet. This is completely overkill for internal access because the frontend Pods and backend Pods are already in the same cluster, and the load balancer introduces public exposure, additional cost, and cloud provider dependency. The correct internal solution is a ClusterIP Service, which is not exposed outside the cluster and is automatically discoverable by other Pods via DNS.

Ingress resource

Why wrong: An Ingress resource is not a Service type; it is a Kubernetes API object that manages external HTTP(S) traffic to Services, typically via an Ingress controller like NGINX or HAProxy. To route traffic, Ingress must point to a backend Service (often ClusterIP) that ultimately targets the Pods, so it does not itself provide a stable internal IP for frontend-to-backend communication. Adding an Ingress would introduce an unnecessary external routing layer and still require a Service, making it an incorrect and over-engineered choice for internal-only access.

The Service port name does not match the container port

Why wrong: A mismatch between the Service's port name and the container's port name does not prevent the Service from finding Pods; the selector matches labels, not ports. Even if the names differ, the Endpoints controller still populates endpoints for any Pod that matches the selector. A port name mismatch would only cause connection failures if references by that name are used (e.g., in some ingress or other service), but it is not the reason endpoints are missing. Thus, this option is wrong because it does not explain the absence of endpoints.

The Service type is ClusterIP but should be NodePort

Why wrong: The Service type (ClusterIP, NodePort, LoadBalancer) determines how the Service is exposed externally, but it has absolutely no effect on how the Service selects Pods or on which namespaces are searched. A ClusterIP Service still performs label-based selection within its own namespace, just like a NodePort does. Changing the type to NodePort would not magically create matching Pods or alter the scope of the selector. Therefore, this option is incorrect because the described symptom (no reachable endpoints) is independent of the Service type.

DNS resolution is broken in the staging namespace

Why wrong: DNS resolution for a Service is cluster-wide and works across namespaces, provided the Service exists and the request uses the full FQDN like 'backend.prod.svc.cluster.local'. If a Pod in the 'staging' namespace queries that name, CoreDNS returns the ClusterIP of the 'backend' Service as long as the Service object exists, regardless of whether that Service has any endpoints. If DNS were broken, you would get a NXDOMAIN error, but the actual symptom is a reachable IP that refuses connections. Thus, broken DNS in the staging namespace is not a plausible cause for the service being unreachable.

Headless Service

Why wrong: A headless Service (clusterIP: None) intentionally omits a stable virtual IP, so its DNS name resolves to the individual pod IPs (or node IPs under hostNetwork) rather than a consistent endpoint. That means clients cannot rely on a fixed address for the Service, and any pod restart or reschedule changes the DNS results. Although useful for stateful pod discovery, it fails when an application requires a stable, load-balanced communication endpoint.

Endpoints resource

Why wrong: The Endpoints resource is merely an internal API object that enumerates the backing pod IPs and ports selected by a Service; it is not a separate traffic-routing mechanism. In practice, the Service controller populates Endpoints automatically, and clients never address the Endpoints object directly. Even with hostNetwork, Endpoints carry no stable IP or DNS name of their own, so relying on Endpoints alone for pod communication is not a valid architectural choice.

Ingress

Why wrong: Ingress is a Layer-7 construct designed to route external HTTP/HTTPS traffic from outside the cluster to Services, usually through an Ingress controller. It does not provide internal service discovery or a stable IP for pod-to-pod communication within the cluster. Even if the application uses hostNetwork, Ingress remains irrelevant and cannot substitute for a ClusterIP Service's DNS name and stable endpoint for East-West traffic.

LoadBalancer

Why wrong: A LoadBalancer Service provisions a cloud-provider load balancer with a public IP to expose an internal set of pods to external traffic. It does not resolve or alias external DNS names; it is an ingress mechanism, not a DNS-level redirect, so it cannot make db.example.com reachable as a cluster-local name.

NodePort

Why wrong: NodePort exposes a Service on a static high-port on every node, allowing external clients to connect using nodeIP:port. It only opens a port to reach backend pods; it has no DNS resolution capability and cannot create a CNAME or otherwise map a Service name to an external database.

ClusterIP

Why wrong: ClusterIP is the default Service type, assigning a virtual IP that is only routable inside the cluster for pod-to-pod communication. It has no link to external DNS — creating a ClusterIP Service for db.example.com would merely allocate an internal IP that cannot forward traffic to the database.

The Service port is already in use

Why wrong: This is not the cause of a pending external IP. Service ports are logical and can be reused across different Services because each Service has its own ClusterIP and kube-proxy rules; the API server does not enforce global port uniqueness for Service objects. A genuine port conflict would surface as a validation or binding error, not as a status field remaining '<pending>' after a successful creation.

The Service selector does not match any Pods

Why wrong: Even if the Service's selector matches no Pods, the cloud controller will still provision the load balancer and assign an external IP, because endpoint discovery is a separate kube-controller-manager function. The lack of endpoints only means the cloud LB's backend pool will be empty, so traffic forwarded to the LB will fail, but the IP is still allocated. Thus, a pending external IP points to the LB provisioning step, not to endpoint health.

The Pods are not listening on the container port

Why wrong: The container port defined on the Pod spec is only a declaration used by the Service's targetPort to route traffic; it does not affect control-plane operations. Even if no Pod is listening on that port, the cloud provider will still create the load balancer and set the external IP, because health checks and endpoint readiness are determined after the IP is provisioned. The external IP pending issue is unrelated to the actual liveness of the backend Pods.

Ensure that the Service type is ClusterIP

Why wrong: Ingress controllers can route to any Service type that exposes a valid set of endpoints; the default Service type is ClusterIP, and it is fully compatible with Ingress. A 503 response typically means the Ingress controller cannot find any healthy Pod backends, not that the Service is of the wrong type. Changing the Service type to ClusterIP would have no effect on readiness or endpoint population, so it would not resolve the 503. The real issue is almost always elsewhere, such as Pod readiness or network reachability, not the Service type.

Verify that the Service port matches the Pod's container port

Why wrong: If the Service port and the Pod's container port did not match, the Endpoints controller would not populate the Endpoints object, and the Ingress would receive a connection error or an empty upstream — not necessarily a clean 503, but a different failure signature. In this scenario, the fact that the Ingress is returning 503 implies the Service is correctly resolving to the Pods, which means the ports likely align. While validating port alignment is good practice, it is not the root cause here because the endpoint list is already populated. The 503 is more likely due to the readiness state of those endpoints.

Check the Ingress controller logs

Why wrong: Ingress controller logs will mostly show the routing decision and upstream connection attempts, but they will not reveal why the application Pod is unhealthy or unready. A 503 can be generated entirely by the Ingress controller itself when there are no ready endpoints; the request may never reach the application, so the controller logs cannot show application-level failures. To diagnose the actual cause, you need to inspect the Pod's status, readiness probe results, and events with kubectl describe pod — not just the controller logs. The logs are useful for verifying that the Ingress resource is being honored, but they won't tell you why the backend is unavailable.

<namespace>.<service>.svc.cluster.local

Why wrong: This format places the namespace before the service name. In Kubernetes DNS, the service name comes first, followed by the namespace, so the correct FQDN is <service>.<namespace>.svc.cluster.local. Using <namespace>.<service> would cause DNS to look for a service named after the namespace in a namespace named after the service, which will not resolve. The 'svc' zone is always under the namespace subdomain, not above it.

<service>.<namespace>.pod.cluster.local

Why wrong: The 'pod' subdomain is used for pod DNS records, which are based on the pod's IP address (e.g., 10-244-0-1.default.pod.cluster.local), not for Service discovery. A Service is accessed via its service name, not a pod name, and the record type for Services is 'svc', not 'pod'. Therefore, this FQDN cannot be used to reach a Service, and even for pods it would require the pod's IP with hyphens in place of dots, not the service's name.

<service>.svc.cluster.local

Why wrong: Omitting the namespace makes this FQDN only resolvable within the same namespace as the client pod. Kubernetes DNS applies the pod's search domains, so a query for <service>.svc.cluster.local would be resolved in the pod's own namespace. Since the question asks about communicating with a pod in the same cluster, which may be in a different namespace, this format is insufficient for cross-namespace communication. The namespace is a required component of a Service's fully qualified domain name for cluster-wide resolution.

The Service port was changed

Why wrong: Changing the Service port affects the port number that clients use to reach the Service, but it does not influence pod discovery. The endpoints controller selects pods solely based on the Service's selector and the pods' labels, ignoring the Service port field. As long as the selector matches the pods' labels, endpoints are generated even if the port number changes. Therefore, a port change cannot explain the absence of endpoints; the real culprit is a selector mismatch.

The Service type changed to ExternalName

Why wrong: ExternalName is a special Service type that maps the Kubernetes Service to a DNS name using the externalName field, and it intentionally does not contain a selector. If the Service were switched to ExternalName, the endpoints controller would not create endpoints at all because the spec.selector is absent. However, the scenario specifically mentions updating the pods' labels, not modifying the Service type, so the fundamental cause remains a selector mismatch in a normal ClusterIP/NodePort Service.

The Pods have a different container port

Why wrong: A pod's containerPort is an informational field used to identify the targetPort for Service traffic, but it has no bearing on whether the pod matches the Service selector. The endpoints controller only cares about the pod's labels and readiness; it will add the pod IP (and the correct port mapping) to the Endpoints resource as long as the labels align with the Service's selector. Even if the container port were changed and the Service's targetPort updated accordingly, endpoints would still be populated if the selector matched.

Service type ClusterIP

Why wrong: Service type ClusterIP exposes the Service only on a cluster-internal virtual IP, which is routable solely from within the cluster's network. This IP cannot be reached from outside the cluster without an additional component such as a node port, load balancer, or Ingress controller. Therefore, ClusterIP by itself is not a valid way to expose a Service to external clients.

Service type ExternalName

Why wrong: Service type ExternalName returns a CNAME record for an external DNS name rather than creating a real proxy or route to Pods. It enables cluster workloads to refer to an external service by a local alias, but it does not accept inbound traffic from outside the cluster. As a result, it is not a method for exposing a Service to external clients; it is merely a DNS-level indirection.

Ingress resource with ClusterIP Service

Why wrong: Ingress is not a Service type but an API object that requires an Ingress controller to accept external traffic at a single entry point and route it to a backend Service. The backend Service is often ClusterIP, which remains internal; the actual external exposure is provided by the Ingress controller, which itself must be exposed via a NodePort or LoadBalancer. Therefore, using an Ingress resource with a ClusterIP Service is not a direct way to expose the Service to external clients; the underlying Service is still not externally reachable on its own.

Exposing the service externally via cloud load balancer

Why wrong: Headless Services intentionally omit a ClusterIP, and a Service of type LoadBalancer requires a ClusterIP to allocate a cloud provider's external load balancer (or a stable VIP) that forwards to the Endpoints. Setting type: LoadBalancer on a headless Service is not a supported valid use case; external exposure should rely on a regular ClusterIP/NodePort or an Ingress backed by a Service.

Providing a stable virtual IP for load balancing

Why wrong: A headless Service has spec.clusterIP set to None, meaning no stable virtual IP is assigned and kube-proxy does not create cluster-wide iptables/IPVS rules for it. Therefore it cannot provide a stable VIP for traffic clustering or simple round-robin load balancing at the cluster layer; those behaviors require a normal ClusterIP Service. Choosing a headless Service specifically removes the stable virtual IP guarantee.

Pod readiness probes

Why wrong: Readiness probes determine when a pod is able to accept traffic, and are managed by kubelet via the Service's endpoint selector. However, Ingress routing only requires a backend Service to exist; the Service's endpoints can include pods that have the default Ready condition if no probes are defined. Therefore, lack of readiness probes doesn't prevent Ingress from routing, though probes are still recommended for rolling updates and reliable traffic distribution.

A Service of type LoadBalancer

Why wrong: A LoadBalancer-type Service is often used to expose the Ingress controller itself to external clients, but it is not a required component for Ingress routing internally. Ingress rules point to a Service backend, which can be a ClusterIP Service, NodePort, or even another Ingress controller's service. Requiring a LoadBalancer for every backend would eliminate the cost-saving layer that Ingress provides, so it is incorrect.

A TLS certificate for HTTPS

Why wrong: TLS in Ingress is an optional feature enabled by providing a certificate and key in a Secret, and then referencing that Secret in the Ingress `tls` section. Even with no TLS, an Ingress can route plain HTTP traffic, and many clusters use TLS termination at the ingress controller only for public endpoints. A certificate is only required when you explicitly configure HTTPS, so it is not a prerequisite for routing.

The Service name 'payment' is not resolvable by DNS

Why wrong: A DNS failure would produce a 'could not resolve host' error rather than a connection timeout. CoreDNS automatically creates an A record for any Service named 'payment', so as long as the Service object exists, the name resolves to the ClusterIP. Since traffic is reaching the Pod (as implied by the scenario), DNS is functioning and cannot be the root cause of the connectivity problem.

The targetPort in the Service does not match the containerPort in the Pod spec

Why wrong: If targetPort did not match the containerPort on the Pod, the Service's endpoints would never become ready — because kube-proxy would not find a valid target and the endpoints would be empty. Since the problem involves endpoints existing and traffic reaching the Pod, the targetPort clearly matches. A mismatch would produce a different symptom: no endpoints and no connectivity at all, not a refused or dropped connection.

The Service type should be NodePort instead of ClusterIP

Why wrong: Changing the Service type to NodePort would not fix the underlying issue because NodePort still routes traffic through the same ClusterIP and iptables rules to the Pod IP. If the Pod's application is listening on localhost, it will reject those forwarded connections regardless of the Service type. ClusterIP is the correct choice for internal microservice communication; NodePort is meant for external access and does not alter the Pod's network namespacing.

An EndpointSlice

Why wrong: An EndpointSlice is a low-level API object that tracks the IP addresses and ports of the pods backing a Service, but it is not designed for application-level discovery. Instead, kube-proxy and other internal controllers consume EndpointSlices to program load-balancing rules. Applications should rely on a Service's stable DNS name and virtual IP, not directly query EndpointSlices, which are an implementation detail of the control plane.

An Ingress resource

Why wrong: An Ingress resource is a layer-7 routing object that controls external HTTP/HTTPS traffic from outside the cluster to Services, typically through an Ingress controller. It does not provide internal service discovery or a stable cluster IP for pod-to-pod communication. Using Ingress for internal traffic would unnecessarily expose the application externally and is not its intended purpose.

A headless Service

Why wrong: A headless Service intentionally has no cluster IP; instead, it returns the DNS records of the individual backing pods, enabling direct pod-to-pod resolution. This is useful for stateful workloads that need a stable pod identity, but it does not provide a load-balanced virtual IP. For the web app, which likely needs simple, stable service discovery, a ClusterIP Service is more appropriate.

The pods are in a different namespace

Why wrong: A Service is namespaced and its label selector is only evaluated against Pods in the same namespace; the endpoint controller never attempts to include Pods from another namespace. Even if labels match, a Pod in a different namespace is invisible, resulting in an empty Endpoints object. In this scenario the engineer has presumably confirmed the Pods are in the Service's namespace, so this is not the root cause, but rather a potential cause that has been ruled out.

The Service type is NodePort instead of ClusterIP

Why wrong: NodePort and ClusterIP Services share the exact same endpoint selection and population logic; the type only determines how traffic is exposed externally. A NodePort Service still creates an Endpoints object whenever the selector matches and targetPort is correct. Changing the type to ClusterIP would not fix endpoint creation because the underlying selector and port matching mechanisms remain unchanged. Thus, this is not the cause of missing endpoints.

The pods have a different label than 'app: api'

Why wrong: If the Pods' labels differed from 'app: api', the Service's selector would not match them, leaving the EndpointSlice empty. However, the engineer explicitly noted that the Pods carry the correct label, meaning the label selector requirement is already satisfied. A label mismatch is a different failure mode and would not be present in this scenario, so it can be excluded as the root cause.

An Ingress resource with TLS

Why wrong: Ingress is an API object that manages external HTTP(S) access to services within the cluster, typically via a load balancer or ingress controller. TLS termination at the ingress controller secures the external connection but does not regulate or filter traffic between internal pods. The audit concern is east-west pod-to-pod traffic, while Ingress addresses north-south external traffic. Therefore, an Ingress resource cannot control which pods are allowed to access the running pod.

A Service of type ClusterIP with a firewall rule

Why wrong: A ClusterIP service exposes a stable virtual IP for a set of pods within the cluster, but it does not restrict which clients can connect; it is a load-balancing abstraction. Firewall rules are typically cloud-provider security group rules applied to host-level networking, not to pod-to-pod traffic inside the cluster's virtual network. Kubernetes-native network security is enforced via NetworkPolicy, which uses label selectors to define allowed traffic between pods, and a ClusterIP service combined with a firewall would not affect intra-cluster pod communication.

A PodSecurityPolicy

Why wrong: PodSecurityPolicy (now deprecated in favor of Pod Security Standards) is a cluster-level resource that governs security-sensitive attributes of pod configuration, such as privileged mode, hostNetwork, volume types, and Linux capabilities. It does not influence network communication between pods; it constrains what a pod is allowed to do, not whom it can talk to. Applying a PodSecurityPolicy for a network access audit finding would be ineffective, since it cannot block inbound connections to a running pod.

Services can only route traffic based on named ports.

Why wrong: Kubernetes Services accept both numeric port numbers and named ports in their port definitions. Named ports are a convenience that lets you reference a port by a symbolic name, but the Service ultimately resolves to a concrete TCP/UDP number; there is no restriction that only named ports can be used. In fact, the vast majority of Services define ports numerically, so this statement is false.

Services can only route traffic to pods in the same namespace.

Why wrong: A Service object lives in a single namespace and its label selector is evaluated only against Pods in that same namespace; you cannot use a selector to target Pods from another namespace. However, this does not mean the Service's traffic routing is permanently confined to same-namespace Pods — you can manually create an Endpoints object (or use an ExternalName Service) to point to arbitrary IPs or DNS names, including Pods in other namespaces or external systems. Thus the categorical 'only' in the statement is incorrect.

Every Service must have a cluster IP assigned.

Why wrong: The only field truly required in a Service's IP configuration is optional: when `clusterIP` is set to `None`, Kubernetes creates a headless Service that has no virtual ClusterIP and does not perform load balancing or proxying. For headless Services, DNS lookup returns the IP addresses of the backing Pods directly, which is useful for stateful workloads that need identifying each Pod instance. Consequently, a ClusterIP assignment is not mandatory for every Service.

A Deployment of the application

Why wrong: While a Deployment is responsible for managing the application's Pod replicas and ensuring the desired state, it is a workload controller, not a networking endpoint. The Ingress controller routes traffic to a Service, which then selects and load-balances to the Pods created by the Deployment. An Ingress backend must reference a Service's DNS name and port, because a Deployment has no stable ClusterIP or hostname to route to.

A NetworkPolicy allowing traffic from the Ingress controller

Why wrong: A NetworkPolicy that explicitly allows traffic from the Ingress controller is an optional security measure, not a building block of Ingress functionality. In a default Kubernetes cluster, all traffic is permitted unless a NetworkPolicy is in place to restrict it. The Ingress controller can reach the Service and Pods without any policy unless a strict default-deny configuration has been added, in which case a policy becomes necessary for routing to work.

8080

Why wrong: The value 8080 is the Service's targetPort, which identifies the container port on the pod. It is only used internally by the Service to route traffic to the backend application, not as a port exposed on the node. External clients must connect to the nodePort 30007 rather than 8080, since targetPort is never directly reachable from outside the cluster.

80

Why wrong: Port 80 is the Service's port, which defines the virtual ClusterIP port that other in-cluster resources use to reach the Service. This port is not bound to the host network interface and does not accept traffic from outside the cluster. NodePort services map an external nodePort to this internal service port, but the service port itself remains private to the cluster.

30000

Why wrong: 30000 is not defined anywhere in the Service manifest, and unlike the explicitly set nodePort 30007, there is no automatic allocation that would choose 30000 in this case. While 30000 is the lower bound of Kubernetes' default nodePort range and could be auto-assigned in a different Service, the actual configuration clearly selects 30007. Assuming 30000 is reachable would be incorrect because the Service does not bind to that port.

apiVersion: v1\nkind: Service\nmetadata:\n name: web-svc\nspec:\n type: NodePort\n ports:\n - port: 80\n targetPort: 8080\n selector:\n app: web-app

Why wrong: Adding 'type: NodePort' unnecessarily expands the Service's visibility beyond the cluster. The default ClusterIP type is sufficient for internal access, and NodePort reserves a port on every node, allowing external traffic to bypass usual cluster ingress controls. Unless there's a specific requirement for node-level access, this extra setting is redundant and may expose the app unintentionally.

apiVersion: v1\nkind: Service\nmetadata:\n name: web-svc\nspec:\n ports:\n - port: 8080\n targetPort: 80\n selector:\n app: web-app

Why wrong: This YAML inverts the port relationship: it exposes the Service on port 8080 and forwards to container port 80. Clients would need to reach web-svc on 8080, but the actual container is listening on 8080, so the traffic arrives at the wrong process. The correct setup is port 80 (Service entry point) and targetPort 8080 (container listening port).

apiVersion: v1 kind: Service metadata: name: web-svc spec: ports: - port: 80 targetPort: 8080 selector: name: web-app

Why wrong: The selector uses 'name: web-app', but the deployment's Pods are labeled 'app: web-app'. For a Service to route traffic, its selector must exactly match the labels on the target Pods. With this mismatch, the Endpoints controller creates no endpoints, so the Service has no IPs to forward requests to, and all connections to web-svc will fail.

A Service of type LoadBalancer to expose backend pods

Why wrong: A LoadBalancer service exposes the backend pods to external clients by provisioning a cloud provider load balancer and assigning a public or cloud-visible IP address; it has no concept of internal source-based traffic filtering. It merely forwards incoming external traffic to the service's selector targets, so it cannot express 'allow only frontend pods' or any intra-cluster source restriction. Network policies are enforced by the data plane (CNI) at the pod networking layer, completely independent of how services expose pods, so this option does nothing to implement the rule.

A pod anti-affinity rule to ensure frontend pods are not scheduled on the same nodes as backend pods

Why wrong: Pod anti-affinity rules influence the Kubernetes scheduler's placement of pods relative to other pods (e.g., do not co-locate frontend and backend pods on the same node), which is a scheduling constraint that affects availability and failure domains. They do not inspect, filter, or route network packets, and they have no bearing on whether one pod is allowed to initiate a TCP connection to another. Even if the pods are on different nodes or the same node, network policy is what governs the permission to communicate.

A CNI plugin that supports NetworkPolicy enforcement, such as Calico

Why wrong: A CNI plugin like Calico provides the underlying data-plane enforcement mechanism: the kubelet/CNI programs iptables or eBPF rules based on the NetworkPolicy resources in the cluster. However, the CNI plugin itself does not know anything about the business rule 'frontend pods may access backend on 8080' until a NetworkPolicy object declares it; the plugin only executes whatever policies are defined. For this scenario, the required component is the NetworkPolicy object itself, with a plugin being a necessary prerequisite but not the implementation of the rule.