Services and Networking practice questions

The service type is ClusterIP, which does not support endpoints.

Why wrong: ClusterIP is the default Service type and it fully supports endpoints. Kubernetes automatically creates an Endpoints object (or EndpointSlices) for any ClusterIP Service that has a selector, using the IPs of matching pods. A missing endpoint list is never caused by the Service type itself; an Endpoints object may be empty because no pods match the selector, not because ClusterIP lacks endpoint capability.

The service's port does not match the container port.

Why wrong: A service port and container port mismatch prevents traffic from getting through, but it does not affect whether endpoints are created. When a Service has a selector, the endpoint controller writes each matching pod's IP and the targetPort (filling in the default if omitted) into the Endpoints object, regardless of the Service's own port number. If the port were the issue, you would still see endpoints listed but connectivity would fail; no endpoints at all points squarely to a selector or readiness problem.

The service is misconfigured and needs to be deleted and recreated.

Why wrong: Deleting and recreating a Service does not change the fact that endpoints are generated from pod label selectors, not from the Service object's existence. If no pods match the selector or the matching pods are not Ready, the new Service will also have an empty Endpoints list. This option incorrectly assumes a malformed spec is to blame when in practice the most common reason for missing endpoints is absent or unready pods, not a need for recreation.

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

Why wrong: Correct. If nodePort is set to 0, the service will not get a valid NodePort and will show 0.

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

Why wrong: Incorrect. There is no standard mutating webhook that changes NodePort to ClusterIP. The service type is NodePort, so it should get a port. The issue is more likely due to A or B.

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

Why wrong: Incorrect. The pod is created directly by 'kubectl run', so labels match the service selector.

An ingress rule with namespaceSelector matching the same namespace.

Why wrong: This would allow traffic from all pods in the namespace, not just those with label 'app: web'.

An egress rule with namespaceSelector and podSelector.

Why wrong: Egress rules are for outbound traffic; also namespaceSelector is not needed here.

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

Why wrong: Egress rules control outbound traffic, not inbound.

my-svc.default.cluster.local

Why wrong: my-svc.default.cluster.local omits the mandatory '.svc' subdomain that designates the service namespace within the cluster's DNS zone. In CoreDNS, the zone for cluster services is '<namespace>.svc.cluster.local', and a name without '.svc' falls outside this zone, so kube-dns/CoreDNS will not have a record for it. Even though it includes the correct namespace 'default', the missing '.svc' makes the FQDN invalid for service resolution.

my-svc.svc.cluster.local

Why wrong: my-svc.svc.cluster.local leaves out the namespace, which is a required component of any service DNS record. Because services are namespaced objects, CoreDNS maintains a separate subzone for each namespace under '.svc.cluster.local', e.g., 'default.svc.cluster.local'. Without the namespace label, the name tries to resolve a service named 'my-svc' directly under the '.svc' subdomain, but no such record exists.

my-svc.cluster.local

Why wrong: my-svc.cluster.local is missing both the namespace and the '.svc' subdomain, so it does not correspond to any record in the cluster's DNS zone. The cluster domain 'cluster.local' is the parent zone, and services are defined under '<namespace>.svc.cluster.local', not directly beneath the top-level cluster domain. This name would fail resolution because there is no object registered at that path.

It creates a proxy that routes traffic from the service's ClusterIP to the local machine on port 8080.

Why wrong: This option incorrectly reverses the direction of the traffic flow. The port-forward command initiates a local listener on your workstation at port 8080 and tunnels traffic into the Kubernetes cluster, rather than routing traffic originating from the ClusterIP back to your local machine.

It exposes the service as a NodePort on port 8080.

Why wrong: Port forwarding is a temporary, client-side diagnostic tool that does not alter the Kubernetes resource definitions. It does not modify the Service's specification to change its type to NodePort, nor does it open any ports on the cluster's physical worker nodes.

It creates a new service of type LoadBalancer on port 8080.

Why wrong: This command does not provision any new Kubernetes resources or interact with cloud provider APIs to spin up an external load balancer. It simply establishes a temporary network tunnel between your local machine and an existing Service resource for debugging purposes.

kubectl get pod my-service

Why wrong: This command treats `my-service` as a Pod name, but a Service and a Pod are distinct resource types in different API groups (v1 Service vs. v1 Pod). Unless a Pod literally labeled with that name exists, kubectl returns a NotFound error, and even if it existed it would show one Pod's details rather than the aggregated set of backend endpoints for the Service.

kubectl get service my-service -o yaml

Why wrong: Fetching the Service with `-o yaml` returns the Service object's full manifest, including spec (selector, ports) and status, but Service status does not contain the resolved backend IPs. The backend list is stored in a separate Endpoints resource, so YAML output of the Service alone will not show the actual pod IP:port pairs that the Service routes to.

kubectl get svc my-service --show-endpoints

Why wrong: The `--show-endpoints` flag does not exist for `kubectl get svc`; it is not a valid kubectl global or resource-level flag. The `svc` shorthand only supports standard get options such as `-o`, `-n`, or `--label-columns`. To inspect the endpoints, you must explicitly query a separate resource: `kubectl get endpoints my-service`.

nftables

Why wrong: nftables is the modern Linux kernel packet-classification framework that replaces iptables, but it is not a kube-proxy operating mode. As of Kubernetes v1.29, kube-proxy offers only three modes: userspace (deprecated), iptables, and ipvs. The default remains the iptables mode, which configures legacy netfilter rules. Therefore, selecting nftables as a kube-proxy mode is incorrect.

userspace

Why wrong: The userspace mode was kube-proxy's original implementation, where traffic is processed in user space and then re-injected into the kernel, causing significant overhead and latency. This mode is deprecated and has been replaced by the iptables mode, which handles traffic entirely in kernel space. In v1.29, userspace is not the default and is only retained for backward compatibility in very old clusters.

ipvs

Why wrong: ipvs is an alternative kube-proxy mode that leverages the Linux IPVS kernel module, which supports multiple load-balancing algorithms such as round-robin, least-connection, and consistent hashing. While ipvs offers better scalability and performance for large clusters, it is not enabled by default. To use ipvs, you must explicitly set --proxy-mode=ipvs when starting kube-proxy, so it is incorrect to state that it is the default in v1.29.

kubectl port-forward deployment/web 8080:80

Why wrong: `kubectl port-forward` only forwards traffic from a local port to a Pod, it does not create a Service object. This is not a valid way to expose a Deployment as a service.

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

Why wrong: `kubectl run --expose` is deprecated and creates a standalone Pod with an `app` label and a temporary Service. It does not create a Deployment and is not considered a standard way to expose a Deployment.

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

Why wrong: Incorrect. `kubectl create service clusterip web --tcp=80:80` creates a Service named 'web' without setting a selector, so it does not target any Pods and cannot expose the Deployment.

The Ingress resource must specify a host.

Why wrong: Host is optional; you can use wildcard or no host.

The Ingress resource must have a TLS section.

Why wrong: TLS is optional.

NetworkPolicy can filter traffic based on source IP addresses.

Why wrong: NetworkPolicy selectors are fundamentally label-based: podSelector and namespaceSelector identify pods by Kubernetes labels and namespaces, not by literal IP addresses. Although an ipBlock field exists and can specify source or destination CIDRs, it is designed for external or non-pod endpoints like a database VM, and it is not the primary mechanism for filtering pod traffic. The blanket statement 'can filter by source IP' is incorrect because standard pod-to-pod selection is label-driven, and relying on IPs conflicts with Kubernetes' dynamic environment where pod IPs change frequently.

NetworkPolicy is a cluster-scoped resource.

Why wrong: A NetworkPolicy is a namespaced resource: it lives in a single Kubernetes namespace and, when it contains a podSelector, it only selects pods within that same namespace. The only way to affect pods in other namespaces is to reference them via a namespaceSelector inside a rule, but the policy object itself is never cluster-scoped. This is distinct from resources like CustomResourceDefinitions or namespaces, which are cluster-scoped in the API.

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

Why wrong: In a fresh cluster with no NetworkPolicies, pods are non-isolated, meaning all traffic to and from every pod is allowed by default; this is the opposite of a security-first default-deny model. Only when a NetworkPolicy selects a pod does the pod become isolated, and then any traffic that does not match an explicitly allowed ingress or egress rule is rejected. Therefore, simply installing a NetworkPolicy controller does not lock down the cluster—you must author policies to create isolation.

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

Why wrong: This command fails because the imperative generator syntax is incorrect for creating a NodePort service. While 'kubectl create service' can generate certain service types, attempting to use this exact syntax will result in a command-line error, making 'kubectl expose' the preferred and standard method for deriving a NodePort service from an existing deployment.

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

Why wrong: While this command successfully exposes the deployment, it omits the crucial '--type' flag, which causes Kubernetes to default the service type to 'ClusterIP'. Consequently, the service will only be reachable from within the cluster network rather than being exposed on a static port across each node's IP as required for a NodePort configuration.

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

Why wrong: This command explicitly instructs the Kubernetes API to provision a 'ClusterIP' service instead of a 'NodePort' service. Although the syntax is valid for creating an internal load balancer, it restricts traffic routing strictly to the internal cluster network and fails to expose the application on a dedicated port on the cluster nodes.

Only a pod named 'nginx'

Why wrong: While kubectl run primarily provisions a single Pod, appending the --expose flag instructs Kubernetes to additionally generate an associated Service. This Service is automatically configured to target the newly created Pod's port, meaning the command does not limit its output to just a Pod resource.

A pod named 'nginx' and a LoadBalancer service named 'nginx'

Why wrong: The --expose flag defaults to creating a ClusterIP service type for internal cluster communication. To provision a LoadBalancer service, which integrates with cloud provider infrastructure to assign an external IP address, you would need to explicitly define the service type using additional configuration parameters or separate commands.

A deployment named 'nginx' and a NodePort service named 'nginx'

Why wrong: Modern versions of Kubernetes restrict the kubectl run command to generating individual Pods rather than Deployments, which are instead created via kubectl create deployment. Furthermore, the --expose flag defaults strictly to a ClusterIP service type rather than exposing the workload on a static port on each node via NodePort.

Only traffic from pods with label 'role: frontend' is allowed

Why wrong: This statement is incorrect because the NetworkPolicy does not define any ingress allow rules targeting the 'role: frontend' label. When a policy selects a pod but lacks an explicit ingress whitelist block, all incoming traffic is blocked by default, regardless of the source pod's labels.

Both ingress and egress traffic are denied

Why wrong: This option is incorrect because the policy's default isolation behavior only applies to the direction specified in the policyTypes field. If policyTypes only contains Ingress, or defaults to it, egress traffic remains completely unaffected and allowed, meaning egress is not denied.

All ingress traffic is allowed

Why wrong: This option is incorrect because Kubernetes operates on a default-allow model only when no NetworkPolicies select a pod. Once a pod is matched by a NetworkPolicy's podSelector, it becomes isolated, and all ingress traffic is blocked unless an explicit whitelist rule permits it.

The ingress controller does not support TLS termination

Why wrong: Standard Kubernetes Ingress controllers, such as ingress-nginx, Traefik, or HAProxy, natively support TLS termination as a core feature. Attributing a TLS failure to a lack of controller support is incorrect, as decrypting HTTPS traffic at the edge is one of the primary use cases for deploying an Ingress controller in production.

The path type is Prefix but should be Exact

Why wrong: Using a pathType of Prefix is a standard and highly flexible configuration, especially when routing all traffic under a root path like '/'. Changing this to Exact would restrict routing strictly to the literal root path, breaking routing for any sub-paths (such as '/login' or '/api') and is therefore not the cause of the TLS issue.

The secret name does not match the TLS section host

Why wrong: There is no requirement in Kubernetes for the name of the Secret resource to match the domain name specified in the hosts array. The Secret name is simply an arbitrary identifier used to reference the TLS asset, while the hosts field defines which SNI headers the controller should match to present that specific certificate.

kind: Service\napiVersion: v1\nmetadata:\n name: my-service\nspec:\n selector:\n app: my-app\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080\ntype: ClusterIP

Why wrong: Correct. This YAML defines a Service with `type: ClusterIP` inside `spec` and targets port 80 to container port 8080.

kind: Service\napiVersion: v1\nmetadata:\n name: my-service\nspec:\n selector:\n app: my-app\n type: NodePort\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080

Why wrong: Incorrect. This YAML specifies `type: NodePort`, not ClusterIP.

kind: Service\napiVersion: v1\nmetadata:\n name: my-service\nspec:\n selector:\n app: my-app\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080\n type: LoadBalancer

Why wrong: Incorrect. This YAML specifies `type: LoadBalancer`, not ClusterIP.

kind: Service\napiVersion: v1\nmetadata:\n name: my-service\nspec:\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080

Why wrong: Incorrect. This YAML lacks a `selector`, so it cannot route traffic to any pods.

db-service

Why wrong: The unqualified name 'db-service' only resolves to a Service in the same namespace as the querying pod. Because the pod is in the default namespace, DNS search domains such as default.svc.cluster.local are appended, so 'db-service' becomes 'db-service.default.svc.cluster.local' — not the production Service. Without an explicit namespace, the production Service is completely unreachable via this short name.

db-service.production.pod.cluster.local

Why wrong: The substring 'pod.cluster.local' indicates a Pod DNS name, not a Service DNS name. Kubernetes exposes Services under the 'svc.cluster.local' subdomain, while individual Pods have FQDNs like <hostname>.<namespace>.pod.cluster.local for headless Services or for Pods with hostNetwork. Using 'pod.cluster.local' for a Service will fail because no DNS record for 'db-service' exists in the 'production' namespace under that zone; Services are only registered under 'svc'.

production.db-service.svc.cluster.local

Why wrong: This reverses the DNS label order defined by Kubernetes. The canonical FQDN places the Service name first and the namespace second: <service>.<namespace>.svc.cluster.local. Here the name is parsed as a Service named 'production' in a namespace called 'db-service', which does not exist, so DNS resolution fails. The namespace must always follow the Service name in the FQDN, not precede it.

All traffic is allowed because no ingress/egress rules are specified

Why wrong: In Kubernetes NetworkPolicies, specifying `policyTypes` containing both `Ingress` and `Egress` without defining any corresponding `ingress` or `egress` rule blocks creates an isolation boundary. This configuration acts as an explicit "default deny" mechanism rather than a "default allow". Consequently, all incoming and outgoing network connections are blocked for the selected pods, rather than permitted.

Only ingress traffic is denied; egress traffic is allowed

Why wrong: Because the `policyTypes` list explicitly includes both `Ingress` and `Egress`, the policy enforces isolation on both traffic directions simultaneously. If only `Ingress` were listed, egress traffic would indeed remain unaffected and allowed. However, since `Egress` is declared without any matching whitelist rules, all outbound traffic from the selected pods is blocked.

The policy is invalid because podSelector is empty

Why wrong: In Kubernetes API design, an empty `podSelector: {}` is syntactically valid and has a specific semantic meaning: it selects all pods within the namespace where the NetworkPolicy is applied. This is a standard pattern used by administrators to establish a baseline security posture. It should not be confused with omitting the `podSelector` field entirely, which can lead to different default behaviors depending on the schema version.

userspace

Why wrong: The userspace mode is a legacy kube-proxy mode where all Service traffic is proxied through kube-proxy's user-space process. This introduces a double hop: packets from clients are accepted by kube-proxy, which then creates a new connection to a backend pod, causing high CPU and memory overhead. It supports simple round-robin load balancing but performs poorly, making it generally deprecated in favor of kernel-space modes.

iptables

Why wrong: iptables mode is the default in many kube-proxy versions and uses iptables NAT rules to redirect Service traffic to backend pods. These rules are processed in the kernel but in a linear, chain-based manner, and kube-proxy only generates rules that randomly select a backend per new connection. It does not use IPVS and lacks advanced scheduling algorithms like least-connection or hash-based routing, which makes its rule set large and expensive to update as Services scale.

kube-proxy

Why wrong: kube-proxy is the Kubernetes daemon that runs on nodes and implements Service networking—it is not a proxy mode itself. kube-proxy manages the actual modes (userspace, iptables, ipvs, and kernelspace for Windows) by configuring the appropriate kernel or user-space mechanism. Entering 'kube-proxy' as a mode is a category error, because it is the control-loop component, not one of the selectable load-balancing implementations.

kubectl expose pod my-pod --port=8080

Why wrong: This command attempts to create a new Service resource exposing the specified pod, which is a permanent cluster-level change rather than a temporary local access mechanism. It does not establish a direct tunnel from your local machine to the pod's port, making it unsuitable for quick, temporary debugging.

kubectl proxy --port=8080

Why wrong: This command runs a local proxy server to access the Kubernetes API server securely from your localhost. While it allows you to query API endpoints and access services via the API proxy path, it does not establish a direct TCP port-forwarding tunnel to a specific application pod's port.

kubectl port-forward service/my-service 8080:8080

Why wrong: This command sets up port forwarding to a Service resource rather than directly targeting a specific pod. While it eventually routes traffic to an underlying pod selected by the service, it fails to meet the requirement of directly and temporarily targeting a specific pod instance.

spec.ingress

Why wrong: The Ingress API does not define a spec.ingress field. In networking.k8s.io/v1, the IngressSpec contains only rules, tls, defaultBackend, and ingressClassName. Any attempt to set spec.ingress would be rejected by the API server because the field is not recognized, so it cannot hold routing information.

spec.tls

Why wrong: The spec.tls field configures Transport Layer Security, listing hosts that need HTTPS and referencing a Kubernetes Secret that contains the certificate and private key. It does not define how requests are routed to services; instead, routing is entirely handled by the rules field with host, path, and backend maps. TLS only governs encryption, not traffic distribution.

spec.backend

Why wrong: spec.backend is a legacy alias not present in networking.k8s.io/v1; the correct field is defaultBackend, which specifies a fallback backend for requests that do not match any rule in spec.rules. It functions as a catch-all service, not as a routing rule itself. Since it only handles unmatched traffic, it cannot replace or define host/path-based routing.