Services &amp; Networking practice questions

A developer created a Deployment with 3 replicas and a ClusterIP Service named 'app-service' on port 80 targeting port 8080 on the pods. Pod logs show that the container is listening on 8080, but curl from another pod in the same namespace to http://app-service:80 fails with 'Connection refused'. What is the most likely cause?

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

This option is incorrect because the Service's targetPort is already correctly configured to match the container's listening port of 8080. If a mismatch actually existed, traffic would be routed to an inactive port on the container, but the configuration details confirm that the ports are aligned. Therefore, port mismatch is not the root cause of the connectivity issue.

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

The default ClusterIP service type is specifically designed and sufficient for secure, internal inter-pod communication within a Kubernetes cluster. Changing the service type to NodePort is unnecessary and introduces security risks by exposing the service on a static port across all cluster nodes. Internal workloads should always use ClusterIP to communicate with each other.

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

If DNS resolution for the service name were failing, the client pod would throw a 'name not resolved' or 'host not found' error rather than a connection timeout or refusal. The ability to attempt a connection indicates that CoreDNS successfully resolved 'app-service' to its ClusterIP. The failure occurs at the network routing layer because no backend endpoints are associated with that IP.

A
The Service selector does not match the pod labels.
Kubernetes Services rely on label selectors to dynamically discover and route traffic to backend Pods. If the Service's selector does not match the labels defined in the Deployment's Pod template, the Service will fail to populate its Endpoints or EndpointSlice resources. Consequently, any traffic sent to the Service IP will result in a connection failure because there are no active backend Pods registered to receive the traffic.
B
The container port is 8080 but the Service targetPort is 80.
Why wrong: This option is incorrect because the Service's targetPort is already correctly configured to match the container's listening port of 8080. If a mismatch actually existed, traffic would be routed to an inactive port on the container, but the configuration details confirm that the ports are aligned. Therefore, port mismatch is not the root cause of the connectivity issue.
C
The Service type should be NodePort for inter-pod communication.
Why wrong: The default ClusterIP service type is specifically designed and sufficient for secure, internal inter-pod communication within a Kubernetes cluster. Changing the service type to NodePort is unnecessary and introduces security risks by exposing the service on a static port across all cluster nodes. Internal workloads should always use ClusterIP to communicate with each other.
D
The DNS resolution for 'app-service' is failing.
Why wrong: If DNS resolution for the service name were failing, the client pod would throw a 'name not resolved' or 'host not found' error rather than a connection timeout or refusal. The ability to attempt a connection indicates that CoreDNS successfully resolved 'app-service' to its ClusterIP. The failure occurs at the network routing layer because no backend endpoints are associated with that IP.

Question 2mediummultiple choice

An administrator needs to expose a set of pods running a stateful application that require stable network identities. The pods must be reachable from outside the cluster via a DNS name that resolves to individual pod IPs. Which Service type should be used?

Trap 1: ExternalName Service

ExternalName Service maps a service to a DNS name external to the cluster, such as an internet hostname or an external database endpoint. It does not route traffic to internal pods at all, and it does not provide per-pod DNS records. For a stateful set of pods, this would be irrelevant because it cannot reference pod IPs or selectors.

Trap 2: NodePort Service

NodePort Service exposes a service on a static port on every cluster node, allowing external traffic to reach the pods. It does not create per-pod DNS entries; instead, it provides a single cluster-level service IP and node port. The requirement here is per-pod DNS names, which NodePort cannot deliver.

Trap 3: ClusterIP with a regular Service

A regular ClusterIP Service gives a stable virtual IP and a single DNS name that load-balances across the backing pods. It does not create individual DNS records for each pod, so clients cannot resolve specific pod identities. For stateful applications requiring stable per-pod network identities, this is insufficient because the service hides individual pod addresses.

A
ExternalName Service
Why wrong: ExternalName Service maps a service to a DNS name external to the cluster, such as an internet hostname or an external database endpoint. It does not route traffic to internal pods at all, and it does not provide per-pod DNS records. For a stateful set of pods, this would be irrelevant because it cannot reference pod IPs or selectors.
B
NodePort Service
Why wrong: NodePort Service exposes a service on a static port on every cluster node, allowing external traffic to reach the pods. It does not create per-pod DNS entries; instead, it provides a single cluster-level service IP and node port. The requirement here is per-pod DNS names, which NodePort cannot deliver.
C
ClusterIP with a regular Service
Why wrong: A regular ClusterIP Service gives a stable virtual IP and a single DNS name that load-balances across the backing pods. It does not create individual DNS records for each pod, so clients cannot resolve specific pod identities. For stateful applications requiring stable per-pod network identities, this is insufficient because the service hides individual pod addresses.
D
Headless Service (ClusterIP: None)
A Headless Service, created by setting clusterIP to None, does not allocate a virtual IP. Instead, DNS queries for the service return the IP addresses of the backing pods, enabling per-pod DNS names such as pod-name.service.namespace.svc.cluster.local. This is essential for stateful applications like databases that need stable network identities for each pod.

Question 3hardmultiple choice

A Kubernetes cluster uses Calico as the CNI plugin. Two pods on different nodes cannot communicate, but pods on the same node can. Network policies are not enforced. What is the most likely cause?

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

Calico supports non-overlay networking (flat routed networks) using BGP to distribute routes directly to the physical network infrastructure. The absence of an overlay network (like VXLAN or IP-in-IP) is a valid architectural choice and does not inherently break pod-to-pod communication across nodes, provided the underlying network is routed correctly.

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

Since the scenario specifies that NetworkPolicies are not enforced or configured in this cluster, they cannot be the cause of the traffic disruption. Even if they were, NetworkPolicies typically regulate traffic at the pod selector level rather than targeting inter-node transport paths directly.

Trap 3: The pods are using different Service types.

Pod-to-pod communication in Kubernetes relies on direct IP routing provided by the CNI plugin, bypassing the Service layer entirely. The configuration or type of a Kubernetes Service (such as ClusterIP or NodePort) has no bearing on direct IP-based connectivity between individual pod endpoints.

A
Calico is not configured with an overlay network.
Why wrong: Calico supports non-overlay networking (flat routed networks) using BGP to distribute routes directly to the physical network infrastructure. The absence of an overlay network (like VXLAN or IP-in-IP) is a valid architectural choice and does not inherently break pod-to-pod communication across nodes, provided the underlying network is routed correctly.
B
A NetworkPolicy is blocking inter-node traffic.
Why wrong: Since the scenario specifies that NetworkPolicies are not enforced or configured in this cluster, they cannot be the cause of the traffic disruption. Even if they were, NetworkPolicies typically regulate traffic at the pod selector level rather than targeting inter-node transport paths directly.
C
The pods are using different Service types.
Why wrong: Pod-to-pod communication in Kubernetes relies on direct IP routing provided by the CNI plugin, bypassing the Service layer entirely. The configuration or type of a Kubernetes Service (such as ClusterIP or NodePort) has no bearing on direct IP-based connectivity between individual pod endpoints.
D
The nodes' firewalls are blocking required ports for Calico (e.g., BGP port 179 or VXLAN port 4789).
Calico relies on specific control and data plane ports to establish inter-node connectivity, such as TCP port 179 for BGP routing or UDP port 4789 for VXLAN encapsulation. If host-level firewalls block these ports, nodes cannot exchange routing information or encapsulate cross-node pod traffic, breaking inter-node pod communication.

Question 4easymulti select

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

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

A headless service is deliberately created with clusterIP: None, so it does not receive a stable, virtual ClusterIP address in the cluster network. Instead of presenting a single IP endpoint, it exposes the individual IPs of its backing pods via DNS; thus, using it for a stable service IP would defeat its design and a regular ClusterIP Service would be the appropriate choice for that need.

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

Cloud load balancer integration requires a Service type of LoadBalancer (with a cloud-provider controller) or at least a NodePort for external reachability. A headless service has neither a ClusterIP nor an externally routable address; it operates purely as a DNS-based discovery mechanism within the cluster, so it cannot be used to expose a workload to external clients.

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

A conventional ClusterIP Service uses kube-proxy rules (iptables, IPVS) to spread traffic across the pod endpoints, providing transparent load balancing. A headless service, however, has no ClusterIP and no proxy rules; DNS returns all endpoints, so any load distribution must be implemented by the client or application itself. Therefore, using a headless service to achieve built-in load balancing is incorrect because that feature belongs to ClusterIP Services.

A
To provide a single stable IP address for the service.
Why wrong: A headless service is deliberately created with clusterIP: None, so it does not receive a stable, virtual ClusterIP address in the cluster network. Instead of presenting a single IP endpoint, it exposes the individual IPs of its backing pods via DNS; thus, using it for a stable service IP would defeat its design and a regular ClusterIP Service would be the appropriate choice for that need.
B
To expose a service externally via a cloud load balancer.
Why wrong: Cloud load balancer integration requires a Service type of LoadBalancer (with a cloud-provider controller) or at least a NodePort for external reachability. A headless service has neither a ClusterIP nor an externally routable address; it operates purely as a DNS-based discovery mechanism within the cluster, so it cannot be used to expose a workload to external clients.
C
To enable a client to discover all pod IPs for a StatefulSet.
When a StatefulSet creates pods, a headless service provides a stable DNS name for each pod (e.g., podname.servicename.namespace.svc.cluster.local) and also allows the service's own DNS name to return a list of A records for all matching pod IPs. Clients can then obtain the entire set of pod addresses directly, which is exactly what stateful peers need to discover one another and join the cluster without a proxy.
D
To enable DNS to return individual pod IPs for stateful applications.
In a headless service, the DNS controller sets the service's A record set to the IP addresses of the underlying pods rather than a single virtual IP. For stateful applications, this means DNS resolution returns unique IPs for each pod, letting app logic query and connect to each member individually instead of sending traffic to a shared load-balancing address. The absence of a ClusterIP makes this possible because kube-proxy does not intercept or translate the DNS answers.
E
To provide load-balanced access to a set of pods.
Why wrong: A conventional ClusterIP Service uses kube-proxy rules (iptables, IPVS) to spread traffic across the pod endpoints, providing transparent load balancing. A headless service, however, has no ClusterIP and no proxy rules; DNS returns all endpoints, so any load distribution must be implemented by the client or application itself. Therefore, using a headless service to achieve built-in load balancing is incorrect because that feature belongs to ClusterIP Services.

Question 5hardmulti select

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

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

NetworkPolicy objects never act on node-level interfaces or host paths; they are scoped to pods selected in a single namespace. Node-level traffic filtering is handled by external security groups, host iptables, or CNI host-level features, none of which are managed through the NetworkPolicy API. Thus, a NetworkPolicy can neither block nor permit traffic before it reaches the pod network.

Trap 2: They can modify packet contents.

NetworkPolicy is an access-control construct; it either permits or blocks connections based on protocol, port, and selectors, but it never rewrites packets. It does not perform NAT, payload encryption, header modification, or any form of traffic mutation. Data-path features like IP masquerading, load balancing, or transparent proxy insertion require separate CNI capabilities beyond the NetworkPolicy API.

A
They can block traffic at the node level.
Why wrong: NetworkPolicy objects never act on node-level interfaces or host paths; they are scoped to pods selected in a single namespace. Node-level traffic filtering is handled by external security groups, host iptables, or CNI host-level features, none of which are managed through the NetworkPolicy API. Thus, a NetworkPolicy can neither block nor permit traffic before it reaches the pod network.
B
They are namespaced resources.
A NetworkPolicy belongs to a namespace, exactly like a ConfigMap or Service, and its podSelector only matches pods running in that same namespace. It cannot be cluster-scoped or directly target pods in other namespaces, although its ingress and egress rules can reference namespaceSelectors or IPBlocks. This namespace scoping is fundamental to how policies isolate workloads in multi-tenant clusters.
C
They are enforced by the network plugin (CNI).
The NetworkPolicy object is merely declarative; it only takes effect when the installed CNI plugin has a controller that watches these objects and programs the data plane. Plugins such as Calico, Cilium, and Antrea translate the spec into eBPF, iptables, or IPVS rules to enforce allow/deny decisions. If the cluster's CNI does not support NetworkPolicy, the object is silently ignored.
D
They can allow ingress traffic from pods with specific labels.
Ingress rules can contain a from section with a podSelector that identifies source pods by label, and this is one of three selectors, alongside namespaceSelector and ipBlock. For example, a policy can allow only pods labeled app=frontend to reach database pods labeled role=db. This label-based selection is the native Kubernetes way to express L3/L4 allowlists.
E
They can modify packet contents.
Why wrong: NetworkPolicy is an access-control construct; it either permits or blocks connections based on protocol, port, and selectors, but it never rewrites packets. It does not perform NAT, payload encryption, header modification, or any form of traffic mutation. Data-path features like IP masquerading, load balancing, or transparent proxy insertion require separate CNI capabilities beyond the NetworkPolicy API.

Question 6mediummultiple choice

A pod in the same namespace tries to reach 'my-service' on port 80, but gets 'Connection refused'. The pod's labels are 'app: my-app'. What is the most likely cause?

Exhibit

Refer to the exhibit.

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

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

ClusterIP is the default service type in Kubernetes and is specifically designed to expose a service on an internal IP address within the cluster. It is fully accessible by other pods in the same namespace or cluster, making the claim that it cannot be accessed internally technically incorrect.

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

Kubernetes allows port names to be defined as alphanumeric strings containing lowercase letters, numbers, and hyphens up to 63 characters. The name 'http' is a perfectly valid and standard port name that adheres to RFC 6335 guidelines and Kubernetes API specifications.

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

If there is a mismatch between the Service's targetPort and the actual containerPort exposed by the pod, the Endpoints controller will still populate the Endpoints resource with the pod IPs. The connection would fail at the network layer when traffic reaches the container, rather than resulting in missing or unpopulated endpoints.

A
The Service type is ClusterIP, which cannot be accessed from within the cluster.
Why wrong: ClusterIP is the default service type in Kubernetes and is specifically designed to expose a service on an internal IP address within the cluster. It is fully accessible by other pods in the same namespace or cluster, making the claim that it cannot be accessed internally technically incorrect.
B
No pods match the selector or the matching pods are not ready.
For a Service to route traffic, its label selector must match active pods, and those pods must pass their readiness probes. If no pods match the selector, or if the matching pods are failing readiness checks, the Service's Endpoints object will be empty, causing connection attempts to fail.
C
The port name 'http' is invalid.
Why wrong: Kubernetes allows port names to be defined as alphanumeric strings containing lowercase letters, numbers, and hyphens up to 63 characters. The name 'http' is a perfectly valid and standard port name that adheres to RFC 6335 guidelines and Kubernetes API specifications.
D
The targetPort is 8080, but the container port is not 8080.
Why wrong: If there is a mismatch between the Service's targetPort and the actual containerPort exposed by the pod, the Endpoints controller will still populate the Endpoints resource with the pod IPs. The connection would fail at the network layer when traffic reaches the container, rather than resulting in missing or unpopulated endpoints.

Question 7hardmultiple choice

After applying this NetworkPolicy, a pod in the default namespace tries to curl an external website (e.g., google.com) and fails. What is the reason?

Exhibit

Refer to the exhibit.

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

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

Kubernetes NetworkPolicies are stateful, meaning that if outbound traffic (egress) is blocked, the initial DNS query cannot be sent. The failure is not caused by an ingress rule blocking the incoming DNS response, but rather by the egress policy preventing the outbound request from ever leaving the pod.

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

NetworkPolicies are namespace-scoped resources and can only select and affect pods within the specific namespace where they are created. This policy is deployed in the `default` namespace, meaning it cannot globally apply to or conflict with resources in other namespaces across the cluster.

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

An empty `podSelector` (defined as `{}`) in a NetworkPolicy selects all pods within that policy's namespace. Rather than targeting a specific subset of labeled pods, this configuration applies the default-deny behavior globally to every single pod running in the default namespace.

A
The Egress rule is defined but has no allow rules, so all egress is denied.
When a NetworkPolicy includes `Egress` in its `policyTypes` but contains an empty or missing `egress` rule list, it acts as a default-deny for all outbound traffic. Because there are no explicit allow rules defined under the egress section, the policy isolates the matching pods, blocking all outbound connections, including DNS queries.
B
The Ingress rule blocks all incoming traffic, preventing DNS responses.
Why wrong: Kubernetes NetworkPolicies are stateful, meaning that if outbound traffic (egress) is blocked, the initial DNS query cannot be sent. The failure is not caused by an ingress rule blocking the incoming DNS response, but rather by the egress policy preventing the outbound request from ever leaving the pod.
C
The policy is applied to all namespaces, causing a conflict.
Why wrong: NetworkPolicies are namespace-scoped resources and can only select and affect pods within the specific namespace where they are created. This policy is deployed in the `default` namespace, meaning it cannot globally apply to or conflict with resources in other namespaces across the cluster.
D
The policy only applies to pods with specific labels.
Why wrong: An empty `podSelector` (defined as `{}`) in a NetworkPolicy selects all pods within that policy's namespace. Rather than targeting a specific subset of labeled pods, this configuration applies the default-deny behavior globally to every single pod running in the default namespace.

Question 8hardmultiple choice

You are tasked with troubleshooting a web application that is deployed in a Kubernetes cluster. The application consists of a Deployment named 'web-app' with 3 replicas, each running a container that listens on port 3000. A Service named 'web-service' of type ClusterIP with selector 'app: web' and port 80 targeting port 3000 has been created. Additionally, an Ingress resource named 'web-ingress' is configured with a host rule for 'example.com' and backend service 'web-service' on port 80. Users report that accessing http://example.com results in a 503 Service Unavailable error. You verify that all pods are running and ready (kubectl get pods shows 3/3 ready). The Ingress controller logs show 'upstream connect error or disconnect/reset before headers'. You check the endpoints: 'kubectl get endpoints web-service' shows no endpoints. The pods have the label 'app: web'. What should you do to resolve the issue?

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

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

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

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

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

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

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

Question 9mediummultiple choice

A company deploys a web application with multiple replicas in a Kubernetes cluster. Users report intermittent connectivity issues. The application pods are exposed via a ClusterIP Service. To ensure stable connectivity, which action should be taken?

Trap 1: Change the Service type to NodePort

Changing the Service type to NodePort merely exposes the application on a static port across each cluster node's IP address. It does not alter the underlying load-balancing behavior of kube-proxy, meaning client requests will still be distributed across all backend pods randomly or via round-robin, failing to solve the session stickiness issue.

Trap 2: Remove the ClusterIP Service and use headless service

Utilizing a headless service bypasses the ClusterIP proxying mechanism entirely, forcing clients to resolve pod IPs directly via DNS. This approach often exacerbates session issues because client-side DNS caching can lead to uneven traffic distribution, and it lacks any native mechanism to guarantee that a client consistently connects to the same pod replica.

Trap 3: Add a readiness probe to the pods

While readiness probes are crucial for ensuring that traffic is only routed to healthy pods that have finished initializing, they do not manage traffic routing logic for active sessions. Implementing a readiness probe will not prevent kube-proxy from routing successive requests from a single client to different, healthy backend replicas, leaving the session-state issue unresolved.

A
Change the Service type to NodePort
Why wrong: Changing the Service type to NodePort merely exposes the application on a static port across each cluster node's IP address. It does not alter the underlying load-balancing behavior of kube-proxy, meaning client requests will still be distributed across all backend pods randomly or via round-robin, failing to solve the session stickiness issue.
B
Set service.spec.sessionAffinity to ClientIP
Configuring service.spec.sessionAffinity to ClientIP instructs kube-proxy to direct all subsequent requests from a specific client IP to the same backend pod for a designated timeout period. This maintains session state on the target pod, preventing the intermittent failures that occur when stateless load balancing distributes a single user's session across multiple replicas.
C
Remove the ClusterIP Service and use headless service
Why wrong: Utilizing a headless service bypasses the ClusterIP proxying mechanism entirely, forcing clients to resolve pod IPs directly via DNS. This approach often exacerbates session issues because client-side DNS caching can lead to uneven traffic distribution, and it lacks any native mechanism to guarantee that a client consistently connects to the same pod replica.
D
Add a readiness probe to the pods
Why wrong: While readiness probes are crucial for ensuring that traffic is only routed to healthy pods that have finished initializing, they do not manage traffic routing logic for active sessions. Implementing a readiness probe will not prevent kube-proxy from routing successive requests from a single client to different, healthy backend replicas, leaving the session-state issue unresolved.

Question 10hardmultiple choice

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

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

CoreDNS configuration primarily governs how DNS queries are resolved within the cluster, mapping service names and pod hostnames to IP addresses. Since pods can successfully resolve the database service and individual pod hostnames, DNS resolution is functioning as expected. Modifying CoreDNS settings, such as changing the `policy` or `forward` directives, would not address a connectivity issue that arises *after* a successful DNS lookup, which points to network-level blocking, not name resolution failures.

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

A headless service (ClusterIP: None) is crucial for StatefulSets because it allows DNS resolution to return the IP addresses of individual pods, enabling direct pod-to-pod communication and stable network identities (e.g., `db-0.db.mynamespace.svc.cluster.local`). Replacing it with a regular ClusterIP service would only provide a single, stable IP for the service, load-balancing traffic across pods but preventing direct, individual pod addressing required for certain database clustering or peer-to-peer communication patterns. This would fundamentally break the existing pod identity mechanism.

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

Changing a service type to NodePort exposes the service on a static port on each node's IP address, primarily for external access to the cluster. This modification does not alter or bypass internal Kubernetes NetworkPolicies that govern direct pod-to-pod communication within the cluster. The issue described is about pods communicating directly with other pods' IPs internally, not about external access to a service via node IPs, making NodePort irrelevant to the problem's scope and resolution.

A
Modify the CoreDNS configuration to use a different DNS policy.
Why wrong: CoreDNS configuration primarily governs how DNS queries are resolved within the cluster, mapping service names and pod hostnames to IP addresses. Since pods can successfully resolve the database service and individual pod hostnames, DNS resolution is functioning as expected. Modifying CoreDNS settings, such as changing the `policy` or `forward` directives, would not address a connectivity issue that arises *after* a successful DNS lookup, which points to network-level blocking, not name resolution failures.
B
Create a NetworkPolicy that allows ingress traffic from all pods in the namespace to the database pods on port 5432.
When a default-deny NetworkPolicy is active in a namespace, all ingress traffic to pods is blocked unless explicitly permitted by a policy. Creating a NetworkPolicy that targets the database pods (e.g., via their labels) and explicitly allows ingress traffic from all pods within the same namespace (using `podSelector: {}`) on TCP port 5432 would specifically open the necessary communication path. This policy directly addresses the blocked pod-to-pod communication by creating an explicit allow rule.
C
Remove the headless service and use a regular ClusterIP service for pod discovery.
Why wrong: A headless service (ClusterIP: None) is crucial for StatefulSets because it allows DNS resolution to return the IP addresses of individual pods, enabling direct pod-to-pod communication and stable network identities (e.g., `db-0.db.mynamespace.svc.cluster.local`). Replacing it with a regular ClusterIP service would only provide a single, stable IP for the service, load-balancing traffic across pods but preventing direct, individual pod addressing required for certain database clustering or peer-to-peer communication patterns. This would fundamentally break the existing pod identity mechanism.
D
Change the ClusterIP service 'db' to NodePort to expose the database on each node.
Why wrong: Changing a service type to NodePort exposes the service on a static port on each node's IP address, primarily for external access to the cluster. This modification does not alter or bypass internal Kubernetes NetworkPolicies that govern direct pod-to-pod communication within the cluster. The issue described is about pods communicating directly with other pods' IPs internally, not about external access to a service via node IPs, making NodePort irrelevant to the problem's scope and resolution.

Question 11easymulti select

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

Trap 1: ClusterIP

ClusterIP is the default Service type, assigning a stable virtual IP that is reachable only from within the cluster, such as from pods, nodes, and cluster networking. It is not a valid way to expose a Service to external traffic because the IP exists on a cluster-internal network with no route from outside; even using kubectl proxy creates a temporary, API-server-mediated tunnel that is not a direct exposure mechanism. Its purpose is internal service discovery and East-West load balancing between workloads inside the same cluster. For external access, you would need to combine ClusterIP with NodePort or LoadBalancer.

Trap 2: ExternalName

An ExternalName Service does not route traffic to any Kubernetes endpoints; instead, it returns a CNAME record that maps the Service's DNS name to an external DNS name (e.g., db.example.com). This is not a valid way to expose a Service to clients because no proxy, selector, or port is involved — the traffic never enters the cluster, and the Service simply provides a DNS alias for external consumers. It is designed to let internal workloads reach services outside the cluster through the same DNS abstraction, not to expose an in-cluster Service externally. Therefore, it has no external endpoint to receive incoming traffic.

Trap 3: Headless

A headless Service is configured by setting clusterIP: None, meaning it has no virtual IP or load-balanced proxy; instead, DNS A/AAAA records return the IP addresses of the selected Pods directly. It is not a valid way to expose a Service to external traffic because it provides no stable endpoint, no load balancing, and no external access path — external clients would receive a list of Pod IPs and would have to handle routing themselves. Headless Services are used for stateful workloads (like StatefulSets) that require pod-specific DNS records or for integrating with existing service discovery systems. It is a control-plane DNS feature, not an ingress mechanism.

A
LoadBalancer
A Service of type LoadBalancer requests the cloud provider's control plane to provision an external load balancer (e.g., AWS ELB, GCP LB, Azure Load Balancer) that routes traffic from a public IP to the Service's underlying NodePort or ClusterIP. It is a valid exposure method because it provides a stable, externally reachable IP address and integrates with cloud-native health checks, auto-scaling, and DNS. However, it depends on a cloud provider or an external controller like MetalLB; without that, the Service remains in a pending state and behaves like a NodePort, so it is not universally available in all environments.
B
ClusterIP
Why wrong: ClusterIP is the default Service type, assigning a stable virtual IP that is reachable only from within the cluster, such as from pods, nodes, and cluster networking. It is not a valid way to expose a Service to external traffic because the IP exists on a cluster-internal network with no route from outside; even using kubectl proxy creates a temporary, API-server-mediated tunnel that is not a direct exposure mechanism. Its purpose is internal service discovery and East-West load balancing between workloads inside the same cluster. For external access, you would need to combine ClusterIP with NodePort or LoadBalancer.
C
ExternalName
Why wrong: An ExternalName Service does not route traffic to any Kubernetes endpoints; instead, it returns a CNAME record that maps the Service's DNS name to an external DNS name (e.g., db.example.com). This is not a valid way to expose a Service to clients because no proxy, selector, or port is involved — the traffic never enters the cluster, and the Service simply provides a DNS alias for external consumers. It is designed to let internal workloads reach services outside the cluster through the same DNS abstraction, not to expose an in-cluster Service externally. Therefore, it has no external endpoint to receive incoming traffic.
D
NodePort
NodePort is a valid external exposure method because it opens a static port in the range 30000–32767 on every node's IP address, and kube-proxy forwards traffic arriving on that nodePort to the Service's ClusterIP and then to the selected Pods. Clients can reach the Service using nodeIP:nodePort from outside the cluster, even in bare-metal environments without a cloud provider, provided that the node IPs are routable and firewall rules allow the port. This is the foundation for LoadBalancer Services, which use the NodePort they automatically allocate. NodePort is the simplest way to get external traffic into a cluster when a cloud LB is not available or not desired.
E
Headless
Why wrong: A headless Service is configured by setting clusterIP: None, meaning it has no virtual IP or load-balanced proxy; instead, DNS A/AAAA records return the IP addresses of the selected Pods directly. It is not a valid way to expose a Service to external traffic because it provides no stable endpoint, no load balancing, and no external access path — external clients would receive a list of Pod IPs and would have to handle routing themselves. Headless Services are used for stateful workloads (like StatefulSets) that require pod-specific DNS records or for integrating with existing service discovery systems. It is a control-plane DNS feature, not an ingress mechanism.

Question 12hardmultiple choice

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

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

If the backend pods are listening on a different port than expected, kube-proxy will still attempt to forward traffic to the designated target port on the pod IP. Because the packet reaches the destination node but finds no active process listening on that specific port, the connection handshake fails to complete. This mismatch typically results in a connection timeout or a reset, rather than an immediate refusal at the Service abstraction layer.

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

If the 'kube-proxy' daemon is inactive on the node hosting the frontend pod, the iptables or IPVS routing rules for all services on that node would fail to function. This systemic failure would disrupt connectivity to every Service in the cluster from that node, rather than selectively blocking traffic only to the specific backend Service while leaving other cluster communications intact.

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

Kubernetes NetworkPolicies are typically implemented by the Container Network Interface (CNI) plugin using packet-filtering frameworks like iptables or eBPF. When a NetworkPolicy blocks traffic, it silently drops the packets rather than sending a TCP RST packet back to the client. This silent dropping behavior results in a connection timeout on the frontend client, rather than an immediate 'connection refused' error.

A
The backend Service manifest is missing the 'ports' field, so it has no endpoints.
A Kubernetes Service requires a defined 'ports' array to map incoming traffic to target ports on the backend pods. If the 'ports' field is omitted or empty, the control plane cannot generate corresponding Endpoint or EndpointSlice resources. Consequently, attempts to connect to the Service's ClusterIP fail immediately with a 'connection refused' error because there are no active listeners or routing rules configured for that IP.
B
The backend pods are listening on a different port than expected by the frontend.
Why wrong: If the backend pods are listening on a different port than expected, kube-proxy will still attempt to forward traffic to the designated target port on the pod IP. Because the packet reaches the destination node but finds no active process listening on that specific port, the connection handshake fails to complete. This mismatch typically results in a connection timeout or a reset, rather than an immediate refusal at the Service abstraction layer.
C
The 'kube-proxy' is not running on the node where the frontend pod is scheduled.
Why wrong: If the 'kube-proxy' daemon is inactive on the node hosting the frontend pod, the iptables or IPVS routing rules for all services on that node would fail to function. This systemic failure would disrupt connectivity to every Service in the cluster from that node, rather than selectively blocking traffic only to the specific backend Service while leaving other cluster communications intact.
D
A NetworkPolicy in the 'prod' namespace is blocking traffic from the frontend to the backend.
Why wrong: Kubernetes NetworkPolicies are typically implemented by the Container Network Interface (CNI) plugin using packet-filtering frameworks like iptables or eBPF. When a NetworkPolicy blocks traffic, it silently drops the packets rather than sending a TCP RST packet back to the client. This silent dropping behavior results in a connection timeout on the frontend client, rather than an immediate 'connection refused' error.

Question 13mediumdrag order

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

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Upgrade kubeadm, drain the node, upgrade kubelet and kubectl,…

Upgrading kubeadm before draining the node is a risky practice that violates the official Kubernetes upgrade workflow. Draining must occur first to safely evict running workloads to other nodes, preventing unexpected pod disruption or state loss while the node's control plane components or packages are being updated.

Trap 2: Drain the node, upgrade kubelet and kubectl, upgrade kubeadm,…

This sequence is incorrect because kubeadm must always be upgraded before the kubelet and kubectl binaries on a node. Upgrading the node's kubelet first can cause severe version skew issues and compatibility conflicts, as kubeadm is responsible for orchestrating the upgrade process and expects the local kubelet to be at an equal or lower version during execution.

Trap 3: Drain the node, upgrade kubeadm, upgrade kubelet and kubectl,…

This is incorrect because uncordoning before restarting kubelet would allow pods to schedule on a node that still has the old kubelet version running. The kubelet must be restarted after upgrading to apply the changes.

A
Drain the node, upgrade kubeadm, upgrade kubelet and kubectl, restart kubelet, uncordon the node
This is the correct order because you must first drain the node to evict pods safely, then upgrade kubeadm, then upgrade kubelet/kubectl, restart kubelet to apply the new version, and finally uncordon the node to resume scheduling.
B
Upgrade kubeadm, drain the node, upgrade kubelet and kubectl, restart kubelet, uncordon the node
Why wrong: Upgrading kubeadm before draining the node is a risky practice that violates the official Kubernetes upgrade workflow. Draining must occur first to safely evict running workloads to other nodes, preventing unexpected pod disruption or state loss while the node's control plane components or packages are being updated.
C
Drain the node, upgrade kubelet and kubectl, upgrade kubeadm, restart kubelet, uncordon the node
Why wrong: This sequence is incorrect because kubeadm must always be upgraded before the kubelet and kubectl binaries on a node. Upgrading the node's kubelet first can cause severe version skew issues and compatibility conflicts, as kubeadm is responsible for orchestrating the upgrade process and expects the local kubelet to be at an equal or lower version during execution.
D
Drain the node, upgrade kubeadm, upgrade kubelet and kubectl, uncordon the node, restart kubelet
Why wrong: This is incorrect because uncordoning before restarting kubelet would allow pods to schedule on a node that still has the old kubelet version running. The kubelet must be restarted after upgrading to apply the changes.

Question 14mediumdrag order

Drag and drop the steps to configure RBAC for a user to list pods in a specific namespace into the correct order.

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Create a RoleBinding first, then create the Role, then generate…

This ordering violates a hard dependency in Kubernetes RBAC: a RoleBinding contains a roleRef, and the API server rejects it if the referenced Role does not already exist (e.g., returning 'NotFound' for the Role). The binding and the Role are separate objects, and the binding's purpose is to bind an existing Role to a user, so it cannot create the privilege itself. Even if you could somehow create the binding first, it would grant nothing until the Role exists, and the subsequent test might fail because the subject still has no permissions at binding creation time.

Trap 2: Generate kubeconfig file first, then create Role, then create…

Generating a kubeconfig file first is premature because a kubeconfig is only a client-side configuration—it stores the server URL, user credentials, and context, not any authorization policies. Kubernetes RBAC evaluates permissions at request time by consulting the RoleBindings and ClusterRoleBindings that currently exist, so a kubeconfig generated before creating the RoleBinding will work at the network level but the user will receive 'forbidden' when attempting to list pods. The proper sequence writes the kubeconfig only after RBAC objects are in place, so the user's first test is meaningful and does not mislead you into debugging a bad certificate or server endpoint.

Trap 3: Create Role, then generate kubeconfig, then create RoleBinding,…

This order mishandles the dependency between the RoleBinding and the eventual test: although it creates the Role first (correct), it drops the kubeconfig generation in before the RoleBinding has been created. A kubeconfig generated in this window is functionally identical to one generated later, but the workflow is wrong because the user could use it immediately and see a permission error, since the RoleBinding that grants 'list' is not yet attached to the subject. In the correct workflow, the Role and RoleBinding are created consecutively, then the kubeconfig is produced, so the user's kubeconfig is never associated with an unauthorized or partially authorized state.

A
Create a Role with list pods permission in the namespace, then create a RoleBinding to bind the role to the user, then generate a kubeconfig file for the user, then verify access by listing pods, and finally optionally revoke the access.
This is the correct order because the Role must exist before binding, the binding must exist before the user can have permissions, generating the config can be done after RBAC is set up, testing confirms the setup, and revocation is optional at the end.
B
Create a RoleBinding first, then create the Role, then generate kubeconfig, then test, then revoke.
Why wrong: This ordering violates a hard dependency in Kubernetes RBAC: a RoleBinding contains a roleRef, and the API server rejects it if the referenced Role does not already exist (e.g., returning 'NotFound' for the Role). The binding and the Role are separate objects, and the binding's purpose is to bind an existing Role to a user, so it cannot create the privilege itself. Even if you could somehow create the binding first, it would grant nothing until the Role exists, and the subsequent test might fail because the subject still has no permissions at binding creation time.
C
Generate kubeconfig file first, then create Role, then create RoleBinding, then test, then revoke.
Why wrong: Generating a kubeconfig file first is premature because a kubeconfig is only a client-side configuration—it stores the server URL, user credentials, and context, not any authorization policies. Kubernetes RBAC evaluates permissions at request time by consulting the RoleBindings and ClusterRoleBindings that currently exist, so a kubeconfig generated before creating the RoleBinding will work at the network level but the user will receive 'forbidden' when attempting to list pods. The proper sequence writes the kubeconfig only after RBAC objects are in place, so the user's first test is meaningful and does not mislead you into debugging a bad certificate or server endpoint.
D
Create Role, then generate kubeconfig, then create RoleBinding, then test, then revoke.
Why wrong: This order mishandles the dependency between the RoleBinding and the eventual test: although it creates the Role first (correct), it drops the kubeconfig generation in before the RoleBinding has been created. A kubeconfig generated in this window is functionally identical to one generated later, but the workflow is wrong because the user could use it immediately and see a permission error, since the RoleBinding that grants 'list' is not yet attached to the subject. In the correct workflow, the Role and RoleBinding are created consecutively, then the kubeconfig is produced, so the user's kubeconfig is never associated with an unauthorized or partially authorized state.

Question 15mediummatching

Match each network policy concept to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Controls incoming traffic to Pods

Controls outgoing traffic from Pods

Selects Pods to which the policy applies

Specifies whether rules apply to Ingress, Egress, or both

Isolates all Pods in a namespace by default

Trap 1: Ingress: Controls outbound traffic from pods

This statement reverses the direction of traffic through the pod's network interface. Ingress always refers to traffic entering the pod, so saying it controls outbound traffic is incorrect—that behavior belongs to Egress rules. An administrator relying on this mix-up might write an Ingress rule expecting to allow a pod to reach the internet, but the rule would instead permit inbound connections to that pod.

Trap 2: PodSelector: Selects namespaces for policy application

PodSelector selects Pods based on their labels within the same namespace as the NetworkPolicy, not Namespaces. To select namespaces, you must use namespaceSelector, which matches Namespace labels and can be combined with podSelector to control cross-namespace traffic. Confusing the two can cause a policy to apply to the wrong set of workloads or to no workloads at all.

A
Ingress: Controls inbound traffic to pods
An Ingress rule in a NetworkPolicy defines which inbound connections are permitted to reach the selected pods. It uses a `from` section to specify allowed sources, such as other pods by label, namespaces by label, or CIDR blocks, together with optional port restrictions. Because NetworkPolicies default to deny when any rule of that type exists, the absence of a matching ingress rule causes the traffic to be dropped.
B
Egress: Controls outbound traffic from pods
An Egress rule restricts connections that selected pods initiate outward, controlling outbound traffic to allowed destinations. It uses a `to` section with podSelector, namespaceSelector, or ipBlock selectors and can optionally limit ports and protocols. Applying any egress rule creates an implicit default-deny for all outbound traffic not explicitly permitted, which often requires a separate rule for DNS to `kube-dns`.
C
PolicyTypes: Specifies whether the policy applies to ingress, egress, or both
The `policyTypes` field explicitly lists whether a policy governs Ingress, Egress, or both, and it determines how empty rule sections are interpreted. If the field is omitted, the API server infers the type based on existing rules: an ingress rule triggers Ingress, an egress rule triggers Egress, and no rules defaults to both. This subtle behavior matters because a policy with `policyTypes: ["Egress"]` and no egress rules effectively blocks all egress, even though no rule was written.
D
Ingress: Controls outbound traffic from pods
Why wrong: This statement reverses the direction of traffic through the pod's network interface. Ingress always refers to traffic entering the pod, so saying it controls outbound traffic is incorrect—that behavior belongs to Egress rules. An administrator relying on this mix-up might write an Ingress rule expecting to allow a pod to reach the internet, but the rule would instead permit inbound connections to that pod.
E
PodSelector: Selects namespaces for policy application
Why wrong: PodSelector selects Pods based on their labels within the same namespace as the NetworkPolicy, not Namespaces. To select namespaces, you must use namespaceSelector, which matches Namespace labels and can be combined with podSelector to control cross-namespace traffic. Confusing the two can cause a policy to apply to the wrong set of workloads or to no workloads at all.

Question 16mediummatching

Match each storage concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Request for storage by a user

Describes storage provisioner and parameters

Mounts a file or directory from the host Node

Temporary storage that shares a Pod's lifecycle

Standard interface for storage plugins

Trap 1: PersistentVolume: A request for storage by a user.

This option is incorrect because it confuses two distinct Kubernetes resources: a PersistentVolume (PV) is not a request, but rather the pre-provisioned storage resource itself. A request for storage by a user is formally known as a PersistentVolumeClaim (PVC), which is the mechanism by which a user subjects a desired capacity and access mode to the cluster for binding. In practice, a PV is the actual pool or disk that satisfies a PVC, while the PVC is the declaration of intent, not the storage itself. Therefore, labeling a PV as a 'request' reverses the roles of the PV and PVC in the Kubernetes storage model.

Trap 2: StorageClass: A type of persistent volume.

This option is incorrect because a StorageClass is not a type of persistent volume, but rather a template that defines how a PersistentVolume can be dynamically provisioned. A StorageClass specifies the provisioner plugin, parameters (e.g., performance tier, replication factor), and reclaim policy, allowing the cluster to create a PV on demand when a PVC references it. In contrast, the term 'type of persistent volume' more accurately describes the various provisioners or storage backends (e.g., AWS EBS vs. NFS), not the StorageClass object itself. The StorageClass is a higher-level abstraction that decouples users from the details of storage provisioning.

Trap 3: emptyDir: An empty directory created when a pod is assigned to a…

This option is incorrect because, while emptyDir is indeed an empty directory created when a Pod is assigned to a node, it does not persist after the Pod is deleted; it is ephemeral by design. The lifecycle of an emptyDir volume is identical to the Pod's: it exists as long as the Pod runs, and it is permanently deleted when the Pod is removed or when the node is drained. The statement falsely suggests durability, which is a characteristic of PersistentVolumes, not emptyDir. Thus, the correct understanding is that emptyDir is a transient scratch space for containers within a Pod, not a persistent data store.

A
Volume: A directory accessible to containers in a pod, with a lifecycle tied to the pod.
In Kubernetes, a Volume is a storage abstraction that exists as a directory accessible to all containers in a Pod, and its lifetime is precisely tied to that Pod's lifecycle: it is created when the Pod starts and destroyed when the Pod is terminated. Unlike PersistentVolumes, this Volume does not outlive the Pod and is not intended for durable, cluster-wide storage. The definition highlights the ephemeral, Pod-scoped nature of basic volumes such as emptyDir or hostPath, which are explicitly managed as part of the Pod specification.
B
PersistentVolume: A piece of storage in the cluster provisioned by an administrator.
A PersistentVolume (PV) is a cluster-level resource that represents a piece of actual storage, such as an NFS share, a cloud disk, or an iSCSI target, which has been provisioned by an administrator independently of any Pod. Unlike a Volume, a PV has a lifecycle that is decoupled from any individual Pod, persisting until it is deleted or reclaimed. Administrators define PVs with properties like capacity, access modes, and reclaim policy, making them the durable storage foundation that users can later claim.
C
PersistentVolumeClaim: A request for storage by a user.
A PersistentVolumeClaim (PVC) is the Kubernetes mechanism through which a user requests a slice of storage from the cluster, specifying the desired capacity and access mode (e.g., ReadWriteOnce) in a declarative way. When a PVC is created, the Kubernetes control plane attempts to bind it to a PersistentVolume that satisfies the request; if none exists, a StorageClass can dynamically provision one. The PVC acts as the user-facing abstraction that decouples the Pod's storage needs from the specifics of the underlying PV, enabling portable applications.
D
PersistentVolume: A request for storage by a user.
Why wrong: This option is incorrect because it confuses two distinct Kubernetes resources: a PersistentVolume (PV) is not a request, but rather the pre-provisioned storage resource itself. A request for storage by a user is formally known as a PersistentVolumeClaim (PVC), which is the mechanism by which a user subjects a desired capacity and access mode to the cluster for binding. In practice, a PV is the actual pool or disk that satisfies a PVC, while the PVC is the declaration of intent, not the storage itself. Therefore, labeling a PV as a 'request' reverses the roles of the PV and PVC in the Kubernetes storage model.
E
StorageClass: A type of persistent volume.
Why wrong: This option is incorrect because a StorageClass is not a type of persistent volume, but rather a template that defines how a PersistentVolume can be dynamically provisioned. A StorageClass specifies the provisioner plugin, parameters (e.g., performance tier, replication factor), and reclaim policy, allowing the cluster to create a PV on demand when a PVC references it. In contrast, the term 'type of persistent volume' more accurately describes the various provisioners or storage backends (e.g., AWS EBS vs. NFS), not the StorageClass object itself. The StorageClass is a higher-level abstraction that decouples users from the details of storage provisioning.
F
emptyDir: An empty directory created when a pod is assigned to a node, persists even after pod deletion.
Why wrong: This option is incorrect because, while emptyDir is indeed an empty directory created when a Pod is assigned to a node, it does not persist after the Pod is deleted; it is ephemeral by design. The lifecycle of an emptyDir volume is identical to the Pod's: it exists as long as the Pod runs, and it is permanently deleted when the Pod is removed or when the node is drained. The statement falsely suggests durability, which is a characteristic of PersistentVolumes, not emptyDir. Thus, the correct understanding is that emptyDir is a transient scratch space for containers within a Pod, not a persistent data store.

Question 17hardmultiple choice

A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?

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

db-service.svc.cluster.local omits the required namespace field between the service name and 'svc'. The standard Kubernetes DNS record is <service>.<namespace>.svc.<cluster-domain>, so without a namespace this name points at service 'db-service' in a namespace literally called 'svc', which does not exist. A Pod in the frontend namespace would therefore receive NXDOMAIN and fail to connect.

Trap 2: db-service

db-service is only a resolvable shortcut because a Pod's /etc/resolv.conf includes the local namespace as a DNS search domain, automatically expanding it into db-service.<current-namespace>.svc.cluster.local. If the client Pod runs in 'frontend' and the Service is in 'backend', that automatic expansion resolves to db-service.frontend.svc.cluster.local. Only when working across namespaces do you need an explicit FQDN; short names cannot bridge the namespace boundary.

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

db-service.backend.cluster.local skips the mandatory 'svc' segment that separates the namespace from the cluster domain in Kubernetes DNS names. The correct path after the namespace is always '.svc.cluster.local' for standard ClusterIP services, so this string would be parsed as service 'db-service' in a namespace 'backend' with an invalid/unknown domain. Without 'svc', CoreDNS treats the name differently and cannot map it to the Service record.

A
db-service.svc.cluster.local
Why wrong: db-service.svc.cluster.local omits the required namespace field between the service name and 'svc'. The standard Kubernetes DNS record is <service>.<namespace>.svc.<cluster-domain>, so without a namespace this name points at service 'db-service' in a namespace literally called 'svc', which does not exist. A Pod in the frontend namespace would therefore receive NXDOMAIN and fail to connect.
B
db-service
Why wrong: db-service is only a resolvable shortcut because a Pod's /etc/resolv.conf includes the local namespace as a DNS search domain, automatically expanding it into db-service.<current-namespace>.svc.cluster.local. If the client Pod runs in 'frontend' and the Service is in 'backend', that automatic expansion resolves to db-service.frontend.svc.cluster.local. Only when working across namespaces do you need an explicit FQDN; short names cannot bridge the namespace boundary.
C
db-service.backend.cluster.local
Why wrong: db-service.backend.cluster.local skips the mandatory 'svc' segment that separates the namespace from the cluster domain in Kubernetes DNS names. The correct path after the namespace is always '.svc.cluster.local' for standard ClusterIP services, so this string would be parsed as service 'db-service' in a namespace 'backend' with an invalid/unknown domain. Without 'svc', CoreDNS treats the name differently and cannot map it to the Service record.
D
db-service.backend.svc.cluster.local
db-service.backend.svc.cluster.local is the fully qualified domain name Kubernetes automatically creates for the Service named db-service in the backend namespace. Any Pod in any namespace, including frontend, can use this FQDN because it contains every component needed by CoreDNS to locate the ClusterIP. It is the canonical cross-namespace address and avoids relying on search domains or local-only short names.

Question 18easymultiple choice

A pod is running with the default DNS policy. The cluster DNS service is at 10.96.0.10. The node's /etc/resolv.conf has nameserver 8.8.8.8. When the pod tries to resolve an external hostname like 'example.com', which DNS server will it query first?

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

When a pod is created with the default `ClusterFirst` DNS policy, the `kubelet` on the node configures the pod's `/etc/resolv.conf` to point to the cluster DNS service IP, not the node's own DNS server. Therefore, DNS queries originating from the pod are directed to the `kube-dns` or `CoreDNS` service running within the cluster, which then handles resolution, potentially forwarding to upstream servers like 8.8.8.8 if necessary. The pod itself does not directly query the node's `resolv.conf` entries.

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

This statement is incorrect because pods with the default `ClusterFirst` DNS policy are fully capable of resolving external names. The cluster DNS service (e.g., CoreDNS or kube-dns) is configured to forward non-cluster domain queries to upstream DNS servers, typically inherited from the node's `resolv.conf` or explicitly configured in the cluster DNS deployment. This forwarding mechanism ensures seamless external name resolution for pods.

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

While the pod does use its own `/etc/resolv.conf` for DNS resolution, this file is specifically configured by the `kubelet` to point to the cluster DNS service IP, not the node's DNS server. The `kubelet` ensures that the `nameserver` entry in the pod's `resolv.conf` is the `kube-dns` or `CoreDNS` service IP, enabling cluster-internal and external name resolution through the cluster's dedicated DNS service.

A
The node's DNS server (8.8.8.8)
Why wrong: When a pod is created with the default `ClusterFirst` DNS policy, the `kubelet` on the node configures the pod's `/etc/resolv.conf` to point to the cluster DNS service IP, not the node's own DNS server. Therefore, DNS queries originating from the pod are directed to the `kube-dns` or `CoreDNS` service running within the cluster, which then handles resolution, potentially forwarding to upstream servers like 8.8.8.8 if necessary. The pod itself does not directly query the node's `resolv.conf` entries.
B
There is no DNS resolution; the pod cannot resolve external names by default
Why wrong: This statement is incorrect because pods with the default `ClusterFirst` DNS policy are fully capable of resolving external names. The cluster DNS service (e.g., CoreDNS or kube-dns) is configured to forward non-cluster domain queries to upstream DNS servers, typically inherited from the node's `resolv.conf` or explicitly configured in the cluster DNS deployment. This forwarding mechanism ensures seamless external name resolution for pods.
C
The cluster DNS service (10.96.0.10)
With the default `ClusterFirst` DNS policy, the `kubelet` configures the pod's `/etc/resolv.conf` to list the cluster DNS service IP (e.g., 10.96.0.10, which is the default `kube-dns` or `CoreDNS` service IP in many clusters) as the primary nameserver. All DNS queries originating from the pod are initially sent to this cluster DNS service. The service then resolves internal cluster names directly and forwards external name queries to upstream DNS servers.
D
The pod's own /etc/resolv.conf which contains the node's DNS
Why wrong: While the pod does use its own `/etc/resolv.conf` for DNS resolution, this file is specifically configured by the `kubelet` to point to the cluster DNS service IP, not the node's DNS server. The `kubelet` ensures that the `nameserver` entry in the pod's `resolv.conf` is the `kube-dns` or `CoreDNS` service IP, enabling cluster-internal and external name resolution through the cluster's dedicated DNS service.

Question 19mediummultiple choice

An administrator notices that traffic to a Service is not being forwarded to any pod. The Service has selector 'app: web' and there are pods with that label. However, 'kubectl get endpoints' shows no endpoints. What is the most likely cause?

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

In Kubernetes, Service port names are only used as a convenience for multi-port Services and named references. The endpoint controller matches traffic based on the numeric targetPort, or by name only if the container port is explicitly named in the pod spec. A mismatch between the Service port name and the container port name does not stop endpoint generation because port numbers still align. Unless you are using named targetPorts that refer to missing names, this is not a cause of endpoint absence.

Trap 2: The Service type is ClusterIP.

ClusterIP is the default and most common Service type, providing a virtual IP for in-cluster access. A ClusterIP Service can absolutely have endpoints and route traffic to pods; it simply does not expose the Service externally. If selection labels match and pods are Ready, a ClusterIP Service will receive a healthy set of Endpoints. Therefore, the Service type itself is never a blocker for traffic when the issue is missing endpoints.

Trap 3: The Service targetPort is not specified.

When targetPort is omitted, Kubernetes defaults it to the value of the `port` field, meaning the Service forwards traffic to the same port number on the pod. This default behavior is well-documented and part of the Service API spec. Therefore, not specifying targetPort is only a problem if you actually intended to map to a different container port. It cannot be responsible for empty endpoints because the default is applied automatically.

A
The Service port name does not match the container port name.
Why wrong: In Kubernetes, Service port names are only used as a convenience for multi-port Services and named references. The endpoint controller matches traffic based on the numeric targetPort, or by name only if the container port is explicitly named in the pod spec. A mismatch between the Service port name and the container port name does not stop endpoint generation because port numbers still align. Unless you are using named targetPorts that refer to missing names, this is not a cause of endpoint absence.
B
The Service type is ClusterIP.
Why wrong: ClusterIP is the default and most common Service type, providing a virtual IP for in-cluster access. A ClusterIP Service can absolutely have endpoints and route traffic to pods; it simply does not expose the Service externally. If selection labels match and pods are Ready, a ClusterIP Service will receive a healthy set of Endpoints. Therefore, the Service type itself is never a blocker for traffic when the issue is missing endpoints.
C
The Service targetPort is not specified.
Why wrong: When targetPort is omitted, Kubernetes defaults it to the value of the `port` field, meaning the Service forwards traffic to the same port number on the pod. This default behavior is well-documented and part of the Service API spec. Therefore, not specifying targetPort is only a problem if you actually intended to map to a different container port. It cannot be responsible for empty endpoints because the default is applied automatically.
D
The pods are not in Ready state (e.g., failing readiness probes).
Readiness probes determine whether a pod is included in the Service's EndpointSlices. The endpoint controller monitors pod readiness and only adds pods whose readiness probe is currently passing; pods failing readiness (or running a container that never becomes ready) are excluded. If all matching pods fail their readiness probe, the endpoint list is empty, and traffic to the Service's ClusterIP or DNS name is dropped. This directly explains why traffic is not reaching the application when the selector matches but no endpoints exist.

Question 20mediummultiple choice

A company wants to expose a web application running as a Deployment with 3 replicas to external users. They need a stable IP address that does not change and the ability to terminate TLS. Which resource should they use?

Trap 1: LoadBalancer Service

A LoadBalancer Service provisions an external cloud load balancer (if running on a cloud provider) to expose the application with a stable, externally accessible IP address. While it provides external access, the Kubernetes Service object itself does not inherently handle TLS termination. To secure the web application with TLS, additional configuration would be required either on the underlying cloud load balancer or by offloading TLS termination to an Ingress controller or the application pods themselves.

Trap 2: ClusterIP Service

A ClusterIP Service creates a stable internal IP address for a set of pods, making the application accessible only from within the Kubernetes cluster. This service type is designed for internal communication between different services or components within the cluster and does not provide any mechanism for direct external access from outside the cluster. Therefore, it cannot be used alone to expose a web application to external users.

Trap 3: NodePort Service

A NodePort Service exposes the application on a static port across all nodes in the cluster, making it accessible via NodeIP:NodePort from outside the cluster. While it provides external access, this method is generally not recommended for production web applications due to several drawbacks. It relies on the potentially dynamic IP addresses of individual nodes, does not offer advanced routing capabilities, and lacks native support for TLS termination, making it less suitable for a stable, secure, and user-friendly external endpoint.

A
LoadBalancer Service
Why wrong: A LoadBalancer Service provisions an external cloud load balancer (if running on a cloud provider) to expose the application with a stable, externally accessible IP address. While it provides external access, the Kubernetes Service object itself does not inherently handle TLS termination. To secure the web application with TLS, additional configuration would be required either on the underlying cloud load balancer or by offloading TLS termination to an Ingress controller or the application pods themselves.
B
ClusterIP Service
Why wrong: A ClusterIP Service creates a stable internal IP address for a set of pods, making the application accessible only from within the Kubernetes cluster. This service type is designed for internal communication between different services or components within the cluster and does not provide any mechanism for direct external access from outside the cluster. Therefore, it cannot be used alone to expose a web application to external users.
C
Ingress resource with a TLS certificate
An Ingress resource, coupled with an Ingress controller, provides a robust solution for exposing web applications externally by offering HTTP/S routing, virtual hosting, and crucially, built-in TLS termination. It allows defining rules to route external traffic to specific services based on hostnames or URL paths, and can manage TLS certificates (stored as Kubernetes Secrets) to encrypt traffic from the client to the Ingress controller, ensuring secure communication.
D
NodePort Service
Why wrong: A NodePort Service exposes the application on a static port across all nodes in the cluster, making it accessible via NodeIP:NodePort from outside the cluster. While it provides external access, this method is generally not recommended for production web applications due to several drawbacks. It relies on the potentially dynamic IP addresses of individual nodes, does not offer advanced routing capabilities, and lacks native support for TLS termination, making it less suitable for a stable, secure, and user-friendly external endpoint.