Services and Networking practice questions

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: Egress rules are for outbound traffic; also namespaceSelector is not needed here.

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

Why it fails: Egress rules control outbound traffic, not inbound.

kubectl port-forward deployment/web 8080:80

Why it fails: `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 it fails: `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 it fails: 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 it fails: Host is optional; you can use wildcard or no host.

The Ingress resource must have a TLS section.

Why it fails: TLS is optional.

NetworkPolicy can filter traffic based on source IP addresses.

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

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 it fails: 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 it fails: 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 it fails: 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 it fails: Incorrect. This YAML lacks a `selector`, so it cannot route traffic to any pods.

LoadBalancer

Why it fails: A LoadBalancer Service provisions an external IP address and an external load balancer through the underlying cloud provider (e.g., AWS ELB, GCP Load Balancer). While it exposes the service to external traffic, it does so by creating a dedicated, external IP endpoint, not by binding a static port directly on each individual cluster node's IP address. This type is designed for robust, cloud-native external access, abstracting away the underlying node IPs.

ExternalName

Why it fails: An ExternalName Service does not expose any service on a node's IP address or even within the cluster's network directly. Instead, it functions as a CNAME record within the cluster's DNS, mapping the service's internal name to an arbitrary external DNS name. This allows services within the cluster to reach external services using a familiar Kubernetes service name, without proxying any network traffic itself.

ClusterIP

Why it fails: A ClusterIP Service exposes the service on a stable, internal IP address that is only reachable from within the Kubernetes cluster. It provides a virtual IP that pods can use to communicate with each other, but it does not expose the service on any node's IP address or to traffic originating from outside the cluster. Its primary role is to enable internal service discovery and communication.

The kube-proxy is not running

Why it fails: While kube-proxy is responsible for implementing the data plane by configuring iptables or IPVS rules on nodes to route traffic to endpoints, it does not manage the lifecycle of the Endpoints resource itself. The control plane's EndpointSlice or Endpoint controller, running inside kube-controller-manager, is responsible for creating and updating Endpoints based on Pod and Service selectors, meaning Endpoints would still exist even if kube-proxy were completely stopped.

The Service is in a different namespace

Why it fails: If the Service existed in a different namespace than the one targeted by your current kubectl context, the command kubectl get endpoints my-service would return a 'Not Found' error rather than an empty list of IP addresses. Endpoints are namespace-scoped resources that are automatically created in the exact same namespace as their corresponding Service, so a mismatch in namespace would prevent the resource from being retrieved at all.

The Service type is ExternalName

Why it fails: An ExternalName Service acts as a simple CNAME redirect to an external DNS name and does not use label selectors to target Pods within the cluster. Because there are no internal Pods to track or route traffic to, Kubernetes does not generate or maintain an Endpoints or EndpointSlice resource for ExternalName Services, making this configuration irrelevant to active Pod readiness issues.

NetworkPolicy is a cluster-scoped resource

Why it fails: NetworkPolicy is not cluster-scoped; it is a namespaced resource. Each NetworkPolicy lives in a specific Kubernetes namespace and applies only to pods within that namespace. Its effect is limited by the namespace in which it is defined, and the spec.podSelector selects pods from that same namespace only.

NetworkPolicy can only allow traffic, not deny

Why it fails: NetworkPolicy is fundamentally deny-by-default: a policy defines allow rules, and any traffic that does not match an explicit allow rule is denied. It does not have a 'deny' action; instead, the absence of a matching allow rule causes packets to be dropped or rejected. Thus, while it only contains allow rules, the overall effect is to restrict traffic by implicitly denying everything else.

IngressClass must have a controller field set to the name of the ingress controller

Why it fails: While the "controller" field within an IngressClass resource is crucial for an ingress controller to identify which IngressClass instances it should manage, it is not strictly mandatory for the IngressClass resource to be valid according to the Kubernetes API schema. An IngressClass can be created without this field, though it might remain unclaimed by any specific controller. The field typically contains a string like "k8s.io/ingress-nginx" to declare the responsible controller.

IngressClass is namespaced

Why it fails: IngressClass resources are defined as cluster-scoped objects within Kubernetes, meaning they do not belong to any particular namespace. This design choice allows a single IngressClass definition to be globally available and referenced by Ingress resources deployed in any namespace across the entire cluster. Consequently, when querying for IngressClass resources, one does not specify a namespace.

IngressClass is automatically created by the ingress controller

Why it fails: IngressClass resources are not automatically generated by ingress controllers themselves. Instead, they are typically defined and deployed by a cluster administrator or an infrastructure provisioning system as part of the cluster's setup. These resources serve as a declarative configuration that ingress controllers then watch and utilize to determine which Ingress objects they should manage and how.

EndpointSlices are only used by headless Services

Why it fails: EndpointSlices are the standard resource for representing network endpoints of any Service that has a selector, regardless of whether that Service has a ClusterIP or is headless. The control plane automatically creates and manages EndpointSlices for all such Services, and kube-proxy consumes them for load balancing in both regular and headless cases. Headless Services also use them for DNS-based pod discovery, but that is an additional use case, not an exclusive one.

EndpointSlices replace the deprecated Endpoints resource

Why it fails: The Endpoints resource is not deprecated; it remains a supported API and is still automatically created for Services. Even when EndpointSlices are the primary representation, Kubernetes runs a conversion mechanism that mirrors EndpointSlice data back into Endpoints objects so legacy controllers and clients continue to work. Thus, EndpointSlices and Endpoints coexist today, and EndpointSlices are the recommended evolution, not a replacement for a deprecated resource.

EndpointSlices cannot be created manually

Why it fails: EndpointSlice objects are ordinary Kubernetes resources that can be defined in YAML and created with kubectl apply, just like ConfigMaps or Deployments. This is used in practice for Services with no selectors, where you manually define EndpointSlices to route to external IPs or endpoints that are not backed by Pods. The control plane's automatic management for selected Services does not prohibit manual creation, so this statement is factually incorrect.

curl app-svc.default.svc.cluster.local:3000

Why it fails: Incorrect. While the fully qualified domain name resolves to the same Service, the port 3000 is the pod's container port (target port), not the Service's listener port. The Service only accepts connections on its own port, which is not specified.

curl app-svc:3000

Why it fails: Correct. The Service DNS name 'app-svc' resolves to the Service's ClusterIP. Since the Service's target port is 3000, the Service listens on port 3000 and forwards to the pod. Thus, curling the Service on port 3000 successfully reaches the application.

curl app:3000

Why it fails: Incorrect. The pod name 'app' is not a resolvable service DNS name; only Service names can be used. Additionally, using port 3000 would attempt to contact the pod directly, not the Service.

spec.rules[0].host: example.com; spec.rules[0].http.paths[0].path: /api; backend.service.name: api-svc; spec.rules[1].host: example.com; spec.rules[1].http.paths[0].path: /web; backend.service.name: web-svc

Why it fails: This configuration is inefficient and represents poor design because it defines the same host ('example.com') across two separate rule elements in the 'spec.rules' array. While some Ingress controllers might attempt to merge duplicate hosts, this redundancy can lead to unpredictable routing behavior, validation warnings, or parsing conflicts. Best practice dictates that all path-based routing for a single domain should reside within a single rule block.

Services are only resolvable within their own namespace.

Why it fails: Services can be resolved across namespaces by appending the namespace.

Pods have A records that resolve to their container IP.

Why it fails: Pods do have A records, but they resolve to the Pod's IP address, not the container's IP address. The statement is incorrect because it says 'container IP' instead of 'Pod IP'.

spec.rules

Why it fails: spec.rules is a list of host and HTTP path rules in the Ingress spec that define how incoming requests are routed to backend services. IngressClass does not contain routing rules; its spec only includes controller and parameters fields. Therefore, spec.rules is not a valid field or annotation for an IngressClass.

spec.tls

Why it fails: spec.tls is an Ingress spec field that carries TLS termination settings, including hosts and a reference to a secret containing the certificate and key. IngressClass is a higher-level class identifier and does not handle TLS configuration; TLS is applied per-Ingress. Hence spec.tls cannot be considered an IngressClass annotation or field.

spec.defaultBackend

Why it fails: spec.defaultBackend is an optional Ingress spec field that defines a default service to receive traffic when no rule matches the request. IngressClass never references backends because it only describes how a class is implemented, not how traffic is forwarded. Consequently, spec.defaultBackend is invalid as an IngressClass annotation.

IngressClass is a namespaced resource.

Why it fails: IngressClass is a cluster-scoped resource, not namespaced. This aligns with its role: it defines a cluster-wide contract for routing that can be referenced from Ingresses in any namespace. Like StorageClass and ClusterRole, its lifecycle is managed by a cluster administrator, and it is not tied to a Kubernetes namespace or its boundaries.

Each cluster can only have one IngressClass.

Why it fails: A cluster may have multiple IngressClasses simultaneously, and this is a common design. Each class can point to a different controller (e.g., NGINX, Traefik, HAProxy) or to the same controller with distinct parameters, such as different ingress-class-specific configurations. The cluster is not limited to one class; instead, the absence of a class reference is what causes ambiguity, not the number of classes.

The pod's DNS policy is set to 'None'

Why it fails: If a pod's DNS policy is explicitly set to 'None', Kubernetes does not inject the standard cluster DNS settings, meaning the search domains like 'default.svc.cluster.local' would be completely absent from the pod's '/etc/resolv.conf' file. Since the scenario implies these search domains are present and active, the DNS policy cannot be set to 'None'. Instead, it is likely set to the default 'ClusterFirst' policy.

The pod is using hostNetwork and bypasses CoreDNS

Why it fails: Running a pod with 'hostNetwork: true' configures it to use the host's network namespace, but Kubernetes still configures its DNS policy to 'ClusterFirst' by default. Consequently, the pod will still query CoreDNS for name resolution rather than bypassing it entirely. To bypass CoreDNS, the DNS policy would need to be explicitly changed to 'Default' or 'None'.

The Service type is ExternalName

Why it fails: An 'ExternalName' Service is a special type of Service that maps to an external DNS name by returning a CNAME record instead of a ClusterIP. CoreDNS still creates and successfully resolves a DNS record for an 'ExternalName' Service within the cluster. Therefore, the query would not fail to resolve entirely; it would simply return the configured CNAME target.

All ingress traffic is denied, but egress is allowed

Why it fails: Both Ingress and Egress are specified as policyTypes, so both are denied.

All ingress and egress traffic is allowed

Why it fails: Empty rules in a NetworkPolicy default to deny.

Only traffic from pods in the same namespace is allowed

Why it fails: No rules are specified, so no traffic is allowed.

The Ingress must have a TLS section configured

Why it fails: TLS is an optional section in the Ingress spec. If omitted, the Ingress routes HTTP traffic only, which is perfectly valid. The provided snippet does not include a tls block, and there is no rule that one must be present for the Ingress to be created or processed. A TLS section is required only if you need HTTPS termination.

A Service named 'api-svc' of type NodePort must exist

Why it fails: An Ingress backend can point to any Service type that has a stable ClusterIP, and the most common backend for an Ingress is a ClusterIP Service. NodePort is not required because the Ingress controller itself is typically exposed via LoadBalancer or HostNetwork, and it routes traffic internally to the Service's ClusterIP. Requiring a NodePort Service is a common misconception; it would be redundant and not part of the Ingress API contract.