Services and Networking practice questions

Headless Service

Why it fails: 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 it fails: 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 it fails: 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.

The Service name 'payment' is not resolvable by DNS

Why it fails: 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 it fails: 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 it fails: 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.

The pods are in a different namespace

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

replicas: Defines the number of Pods in a ReplicaSet

Why it fails: Incorrect—the `replicas` field in a Deployment manifest does not directly define a ReplicaSet's Pod count; it defines the desired number of Pods for the Deployment itself. The Deployment controller translates that desired count into the underlying ReplicaSet's `replicas` field, meaning the ReplicaSet's count is derived from the Deployment, not separately specified. Saying it "defines the number of Pods in a ReplicaSet" conflates the Deployment's declarative intent with the resulting ReplicaSet configuration.

selector: Defines the container image to use

Why it fails: Incorrect—the `selector` is a label-matching mechanism, not a container image definition. The image is specified in the `template.spec.containers[].image` field inside the Pod template. The selector only matches Pods by their labels, enabling the Deployment to identify and manage its Pods; it has no role in defining what images or containers run. Misunderstanding this would place image data in a label selector, which would fail Kubernetes schema validation and confuse controller ownership.

Init Container: Runs alongside main container to add functionality.

Why it fails: This description is incorrect because it fundamentally conflates Init containers with sidecar containers. Init containers execute before any main containers start, perform their setup work, and then exit; they do not run alongside or add runtime functionality. A container that runs alongside the main container to enhance functionality, such as logging or monitoring, is by definition a sidecar container — so this statement inverts the core temporal distinction between the two patterns.

Sidecar Container: Runs before main containers to perform setup tasks.

Why it fails: This statement wrongly assigns the pre-main startup role to sidecar containers. Sidecar containers run concurrently with the main application container for the entire Pod lifetime, providing ongoing services like proxying, log shuttling, or metrics collection. In contrast, init containers are the ones that run before main containers, and they terminate after completing setup tasks — so labeling a sidecar as 'runs before' reverses their lifecycle characteristics and leads to incorrect assumptions about availability and persistence.

spec: rules: - host: "*" http: paths: - path: / pathType: Prefix backend: service: name: app2 port: number: 80 - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: app1 port: number: 80

Why it fails: Incorrect. Using 'host: "*"' is not valid in Kubernetes Ingress. To match all hosts, omit the host field entirely. This rule would not match any traffic because no host is actually '*'; it would only match requests with host literally '*', which is not intended.

spec: rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: app2 port: number: 80 - http: paths: - path: / pathType: Prefix backend: service: name: app1 port: number: 80

Why it fails: For an Ingress rule, the host field selects traffic by the request's Host header; a rule without a host is a fallback that matches any host not claimed by a host-specific rule. In this spec, the named rule for app.example.com points to app2, while the hostless rule points to app1, so all traffic to app.example.com reaches app2 and all other hosts reach app1. Because the requirement is exactly the opposite—app.example.com should hit app1 and the catch-all should hit app2—this spec inverts the intended routing and fails the requirement. The controller evaluates the most specific rule first, so the named host rule always takes precedence for that hostname.

backend.default.svc.cluster.local

Why it fails: This option presents the Service's Fully Qualified Domain Name (FQDN). While this name *does* resolve to the ClusterIP, it is not the most direct answer for a pod *within the same namespace*. Kubernetes' DNS search paths, configured in the pod's `/etc/resolv.conf`, automatically append the current namespace and `svc.cluster.local` to unqualified service names. Therefore, the simple service name `backend` is sufficient. This FQDN would be the correct choice if the query originated from a pod in a *different namespace* or from *outside* the cluster, requiring explicit specification of the full domain.

backend.svc.cluster.local

Why it fails: This FQDN omits the required namespace segment. The correct fully qualified format is <service>.<namespace>.svc.cluster.local, so it should be backend.default.svc.cluster.local. Because 'backend.svc.cluster.local' has only three dots and is thus treated as unqualified, the resolver appends search domains like default.svc.cluster.local, producing nonsense names and ultimately failing; even as an absolute query it doesn't correspond to a DNS record.

backend.default.cluster.local

Why it fails: This string incorrectly replaces the 'svc' subdomain with 'cluster'. Kubernetes Services are published under the 'svc' subdomain of the cluster domain, so the FQDN pattern is <service>.<namespace>.svc.cluster.local. 'backend.default.cluster.local' points to the cluster's base domain, which has no service records; it would not resolve for a Service, and the resolver's search list would not correct a name that already contains 'cluster.local' in the wrong place.

ingress: - from: - namespaceSelector: matchLabels: role: frontend

Why it fails: A namespaceSelector matches entire Kubernetes namespaces by their own labels, not individual pods. If a namespace carries the label role: frontend, every pod inside that namespace becomes eligible for ingress, regardless of each pod's individual labels. The question explicitly asks for pods with a specific pod label, so this rule would allow traffic from pods that do not have the required label, making it broader than the intended selection.

ingress: - from: - ipBlock: cidr: 0.0.0.0/0

Why it fails: The ipBlock element restricts traffic based on source IP address ranges, not on pod metadata such as labels. Using cidr: 0.0.0.0/0 matches every possible IPv4 address, effectively allowing ingress from any network source, including pods not labeled role: frontend. Since the requirement is to select only pods with that specific label, ipBlock cannot express label-based selection and makes the rule far too permissive.

kubectl port-forward pod/myservice 8080:80

Why it fails: This targets a Pod named 'myservice' rather than the Kubernetes Service object. Unless a Pod with that exact name exists, the command fails immediately with a 'pod/myservice not found' error; even if it does exist, port-forwarding directly to a Pod bypasses the Service's ClusterIP and selector-based load balancing, so it does not exercise the Service abstraction the developer actually wants to test.

kubectl port-forward myservice 8080:80

Why it fails: The bare argument 'myservice' is ambiguous because kubectl port-forward requires a full resource identifier in the form 'resource/name'. Without the 'service/' or 'pod/' prefix, kubectl cannot determine which API resource type to resolve, so the command aborts with a usage error ('expected resource/name') instead of forwarding any traffic.

kubectl port-forward service/myservice 80:8080

Why it fails: The positional order of ports is reversed: kubectl port-forward expects the syntax 'local:remote', so '8080:80' means local 8080 to remote 80. Here '80:8080' attempts to bind local port 80 (a privileged port requiring root) and forwards to remote port 8080, which the Service is not listening on because its targetPort is 80 — the connection will be refused or fail to establish.

Using kubectl create service clusterip myservice --tcp=80:80

Why it fails: While kubectl create service clusterip myservice --tcp=80:80 does generate a Service object, it creates a ClusterIP Service with no selector field in its spec. As a result, the Service has no backing pod endpoints and will not route traffic to anything unless you manually add a selector and possibly create Endpoints, making this an incomplete way to expose an application.

Using kubectl create deployment mydeploy --image=nginx --expose

Why it fails: kubectl create deployment mydeploy --image=nginx --expose is not valid because the kubectl create deployment command does not accept an --expose flag. It only creates a Deployment; to create a Service you must use a separate command such as kubectl expose deployment or provide a Service manifest, so this command will fail with an unknown flag error.

Using kubectl run mypod --image=nginx --expose

Why it fails: kubectl run mypod --image=nginx --expose does actually create a Service (along with a workload), but it is not a typical or recommended way to create a Service in cluster administration. The --expose flag also creates a Deployment (or Pod) and auto-generates a Service with limited configurability, which is convenient for quick tests but obscures the Service spec and does not align with best practices for managing resources.

kubectl run my-service --image=nginx --port=80 --expose

Why it fails: `kubectl run my-service --image=nginx --port=80 --expose` creates a brand-new Pod (or Deployment in older kubectl versions) and a Service that selects that generated workload's labels, rather than consuming an existing Deployment. The Service type is not explicitly set, and although it defaults to ClusterIP, you cannot control `targetPort` and the selector is tied to the transient run workload, so it won't correctly front the intended Deployment's Pods.

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

Why it fails: `kubectl create service clusterip my-service --tcp=80:80` generates a ClusterIP Service, but it does not attach any pod selector. With no selector, the Service cannot discover the Deployment's Pods and its Endpoints object remains empty, so traffic sent to it has no backend; you would have to manually create Endpoints, making this an incomplete and non-functional solution for exposing a Deployment.

kubectl expose pod my-pod --port=80 --target-port=80 --type=NodePort --name=my-service

Why it fails: `kubectl expose pod my-pod --port=80 --target-port=80 --type=NodePort --name=my-service` explicitly creates a NodePort Service, not a ClusterIP, and it targets a single Pod rather than a Deployment. While a NodePort Service includes an underlying ClusterIP, its external node-port behavior and pod-level targeting make it incorrect for the stated requirement of exposing a Deployment as type ClusterIP.

CoreDNS is configured to reject cross-namespace queries

Why it fails: CoreDNS does not impose any restrictions on cross-namespace queries; it resolves any service FQDN as long as the service exists. A misconfiguration such as a 'rewrite' or 'template' policy might alter queries, but that would affect all namespaces, not just short names. Therefore, this option incorrectly blames DNS policy for a problem that stems from how the pod formulated the query.

The 'prod' namespace does not exist

Why it fails: The namespace 'prod' must exist for the Service to have been created and for the pod to run in it; if it were absent, the API would reject the Service and the pod would not run. A nonexistent namespace would cause NXDOMAIN for any DNS lookup targeting that namespace, including fully qualified names, not only unresolvable short names. Hence, 'prod' not existing cannot be the cause of the particular behavior described.

The pod is using the short name 'backend' without the namespace suffix

Why it fails: Within Kubernetes, a pod's resolv.conf includes a search list containing its own namespace, e.g., 'prod.svc.cluster.local svc.cluster.local cluster.local', so an unqualified name like 'backend' is expanded only to 'backend.prod.svc.cluster.local'. That lookup succeeds only if the Service is in the same namespace as the pod. To reach a Service in another namespace, the pod must use the fully qualified domain name 'backend.prod.svc.cluster.local' (or at least 'backend.prod.svc'), which is exactly why the short name fails.

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: db spec: podSelector: {} ingress: - {}

Why it fails: Incorrect: An empty rule `{}` in `ingress` allows all ingress traffic, contradicting the requirement.

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

Why it fails: Incorrect: This policy only denies egress (no ingress rule), so ingress traffic is not denied.

The container is listening on port 8080 instead of 80

Why it fails: The command `kubectl port-forward pod/my-pod 8080:80` maps local port 8080 to remote port 80 on the pod. If the container were actually listening on 8080, you would need to specify `8080:8080` or another local port, but the scenario states the pod is known to have port 80 open. Therefore, the remote port is correct, so a mismatch in the container's listening port is not the cause of the connection failure. The failure, if any, would stem from something else, such as the local port binding or an issue with the pod's network.

Local port 8080 is already in use by another process

Why it fails: The port-forward command opens a listening socket on the local machine at 127.0.0.1:8080. If another process has already bound that port, kubectl cannot bind to it and aborts with a bind error like 'address already in use'. This error occurs before any tunnel is created, so when the user attempts to connect to localhost:8080, they see a connection refused because nothing is listening there. This is a common cause and explains the symptom.

The service must exist for port-forwarding to work

Why it fails: Port-forwarding works at the pod level, not the service level. `kubectl port-forward pod/my-pod` directly targets a pod resource via the API server, which establishes a connection to the pod's IP and port without requiring a Service object. Services are only abstractions for pod selection and load balancing; they are entirely irrelevant to the port-forward mechanism. Thus, the absence of a Service does not prevent port-forwarding from working.

ingress: - from: - namespaceSelector: {} - podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8

Why it fails: Three separate list items under 'from' OR them together, so any pod in any namespace (empty namespaceSelector) is admitted, not just app: frontend pods. It is tempting because the structure looks like it expresses both requirements, and empty namespaceSelector is genuinely used to mean all namespaces.

ingress: - from: - podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8

Why it fails: Incorrect. Missing `namespaceSelector: {}` means the `podSelector` only applies to current namespace, not all namespaces. Also, `ipBlock` is combined in the same `from` entry.

ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8

Why it fails: Nesting podSelector inside namespaceSelector's map makes both selectors apply to the same peer, so only pods labelled app: frontend in any namespace match; the ipBlock sits in a separate list item and still works. It is tempting because combining selectors this way is valid syntax for ANDing namespace and pod criteria.

kubectl create service clusterip web --tcp=80

Why it fails: The kubectl create service clusterip web --tcp=80 command generates a ClusterIP service that has no selector field in its spec. Without a selector, Kubernetes cannot build an Endpoints object automatically, so the service's IP address will have no backing pods to receive traffic. To make it work, you would have to manually edit the service to add a selector matching the 'frontend' deployment's labels, which is not a one-command solution and does not meet the requirement.

kubectl expose deployment web --port=80 --type=NodePort

Why it fails: The --type=NodePort flag creates a NodePort service, which exposes the service on a high-port on every node, not a ClusterIP as required. Additionally, this command targets the deployment named "web" rather than "frontend", so even if the type were correct, the service's selector would not match the intended pods. NodePort also inherits ClusterIP, but the question explicitly asks for type ClusterIP, so this is incorrect.

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

Why it fails: The kubectl run command with --expose creates a pod (or deployment in older versions) named "web" and a service that selects pods based on the label "run=web". This is an auto-generated label assigned by the run command, not the "tier: frontend" label that the "frontend" deployment uses. Consequently, the service will not route traffic to the frontend pods; it would only target the newly created resource, which is unrelated to the required deployment.

egress: - to: - ipBlock: cidr: 192.168.0.0/16 ports: - port: 53 protocol: UDP - to: - podSelector: {}

Why it fails: Although the first part of this egress rule correctly targets the ipBlock and port, the additional `to` entry with `podSelector: {}` changes the meaning. In a rule, multiple `to` peers are OR'ed, and an empty podSelector matches every pod in the policy's namespace, so this rule permits egress to the specified CIDR and also to all other pods, making it broader than the requirement. Thus it is invalid for the intended purpose.

egress: - to: - ipBlock: cidr: 192.168.0.0/16 ports: - port: 53 protocol: UDP

Why it fails: This option is technically identical to Option C and would behave exactly the same when applied, so the NetworkPolicy snippet itself is valid. However, in a multiple-select question a duplicate of another correct option is not a separate correct answer; selecting it as an additional answer would still be scored wrong because it does not represent a distinct valid rule. The provided marking of `[wrong]` reflects that duplication, not a syntax error.

egress: - from: - ipBlock: cidr: 192.168.0.0/16 ports: - port: 53 protocol: UDP

Why it fails: This rule uses the `from` field in an egress rule, but `from` is only valid in an ingress section to specify source pods/IP blocks; egress rules use `to` for destinations. If you apply a YAML with `from` inside `egress`, the manifest will fail validation with an error about an unknown field, and the policy will not be created. This is a common mistake when confusing ingress and egress syntax.