CCNA Services Networking Questions

MCQeasy

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?

A.The node's DNS server (8.8.8.8)

B.There is no DNS resolution; the pod cannot resolve external names by default

C.The cluster DNS service (10.96.0.10)

D.The pod's own /etc/resolv.conf which contains the node's DNS

AnswerC

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.

Why this answer

With the default DNS policy (ClusterFirst), pods are configured to use the cluster DNS service (10.96.0.10) as the first nameserver in their /etc/resolv.conf. This is achieved by kubelet injecting the cluster DNS IP and a search domain into the pod's resolv.conf. Therefore, the pod will query the cluster DNS service first for any hostname resolution, including external names like 'example.com'.

Exam trap

The trap here is that candidates confuse the default DNS policy ('ClusterFirst') with the 'Default' policy, mistakenly thinking the pod inherits the node's /etc/resolv.conf directly, when in fact 'ClusterFirst' forces the pod to use the cluster DNS service as the primary resolver.

How to eliminate wrong answers

Option A is wrong because the pod's /etc/resolv.conf lists the cluster DNS service (10.96.0.10) as the first nameserver, not the node's 8.8.8.8; the node's resolv.conf is only used when the pod's DNS policy is set to 'Default' (which inherits the node's DNS), but the question states the default policy is 'ClusterFirst'. Option B is wrong because the default DNS policy does allow external name resolution; the cluster DNS forwards unresolved queries (e.g., for external names) to upstream DNS servers configured in its CoreDNS configuration. Option D is wrong because the pod's /etc/resolv.conf does not contain the node's DNS server (8.8.8.8) by default; it contains the cluster DNS IP and search domains, not the node's nameserver.

Practice this question →

MCQmedium

A Kubernetes cluster has a Service named 'web-svc' of type ClusterIP in the 'production' namespace. The Service selects pods with label 'app=web'. A NetworkPolicy in the same namespace is applied with the following spec: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-web spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: frontend ``` A pod with label 'role=frontend' in the 'staging' namespace attempts to connect to 'web-svc.production.svc.cluster.local' on port 80. What is the result?

A.The connection is denied because the NetworkPolicy does not specify an egress rule for the staging pod.

B.The connection is denied because the NetworkPolicy only allows ingress from pods in the same namespace with label 'role=frontend'.

C.The connection is allowed because the Service's ClusterIP is accessible cluster-wide and NetworkPolicy does not apply to Service traffic.

D.The connection is allowed because the pod has the label 'role=frontend'.

AnswerB

The NetworkPolicy selects pods with 'app=web' in the production namespace. Its ingress rule permits traffic only from pods that match 'role=frontend' and are in the same namespace, because no namespaceSelector is specified. The staging pod is in a different namespace, so it is not selected by the podSelector. Therefore, the connection is denied.

Why this answer

The NetworkPolicy selects pods with 'app=web' in the production namespace and allows ingress only from pods with 'role=frontend' in the same namespace, because the podSelector lacks a namespaceSelector. A pod in the staging namespace, even with the correct label, is not selected by that podSelector. Therefore, the connection is denied.

This illustrates that podSelector alone is namespace-scoped.

Exam trap

The trap here is assuming that a podSelector in a NetworkPolicy matches pods across all namespaces, when it actually defaults to the policy's own namespace.

Practice this question →

MCQhard

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?

A.Calico is not configured with an overlay network.

B.A NetworkPolicy is blocking inter-node traffic.

C.The pods are using different Service types.

D.The nodes' firewalls are blocking required ports for Calico (e.g., BGP port 179 or VXLAN port 4789).

AnswerD

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.

Why this answer

Calico relies on specific ports for inter-node communication. When using BGP (default), port 179 must be open; when using VXLAN overlay, port 4789 is required. If node firewalls block these ports, Calico cannot establish routes or encapsulate traffic between nodes, causing cross-node pod communication to fail while same-node communication (which uses the local bridge) remains unaffected.

Exam trap

The trap here is that candidates often assume Calico always uses an overlay (like Flannel) and pick Option A, missing the fact that Calico's default BGP mode is a direct routing approach that requires open ports, not an overlay.

How to eliminate wrong answers

Option A is wrong because Calico does not require an overlay network by default; it uses BGP for direct routing, and even when VXLAN is used, the issue is port blocking, not the absence of an overlay. Option B is wrong because the question explicitly states that Network Policies are not enforced, so no NetworkPolicy can be blocking traffic. Option C is wrong because Service types (ClusterIP, NodePort, etc.) affect how services are exposed, not the underlying pod-to-pod communication at the CNI level.

Practice this question →

MCQmedium

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?

A.The Service port name does not match the container port name.

B.The Service type is ClusterIP.

C.The Service targetPort is not specified.

D.The pods are not in Ready state (e.g., failing readiness probes).

AnswerD

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.

Why this answer

The most likely cause is that the pods are not in Ready state, often due to failing readiness probes. Kubernetes endpoints are only populated for pods that pass their readiness checks; if a pod is not Ready, it is removed from the Service's endpoint list, even if it is running and has the correct labels.

Exam trap

The trap here is that candidates often assume label matching alone guarantees endpoint creation, but Kubernetes requires pods to be in the Ready state (determined by readiness probes) before they are added to the Service's endpoints.

How to eliminate wrong answers

Option A is wrong because the Service port name and container port name do not need to match; the Service selects pods by label, and port mapping is done by port number or targetPort, not by name. Option B is wrong because ClusterIP is the default Service type and does not affect endpoint population; endpoints are created regardless of the Service type as long as there are matching Ready pods. Option C is wrong because if targetPort is not specified, it defaults to the same value as the Service's port, which still allows traffic to reach the container port; missing targetPort does not prevent endpoints from being created.

Practice this question →

MCQhard

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, but kubectl get pods shows the READY column as 0/1 for each pod. 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?

A.Change the Service type to NodePort to bypass the Ingress.

B.Update the Ingress to use a different backend service.

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.

D.Modify the Service selector to match the pod labels exactly.

AnswerC

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.

Why this answer

Although the Service's selector 'app: web' matches the pod labels, the absence of endpoints indicates that the pods are not being considered ready by the Service. Since `kubectl get pods` shows the READY column as '0/1', the readiness probes are failing or the container is not successfully listening on the expected port. This prevents the endpoints controller from adding the pod IPs to the Service's Endpoints list.

Checking the container port and readiness probe configuration is the correct troubleshooting step.

Exam trap

The trap here is assuming that missing endpoints always mean a mismatched Service selector. If the pods are running but their READY status is 0/1, the endpoints will be empty because the readiness probe is failing, not because of a selector mismatch.

How to eliminate wrong answers

Option A is wrong because changing the Service type to NodePort does not fix the underlying issue of missing endpoints; it only exposes the Service on a node port, but the Ingress still relies on the Service's endpoints to route traffic. Option B is wrong because updating the Ingress to use a different backend service does not address the root cause—the current Service has no endpoints, and any backend service would face the same problem if its selector doesn't match pods. Option D is wrong because the Service selector 'app: web' already matches the pod labels 'app: web', so modifying the selector is unnecessary and would not resolve the missing endpoints if the pods are not listening on port 3000 or readiness probes are failing.

Practice this question →

MCQmedium

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?

A.Change the Service type to NodePort

B.Set service.spec.sessionAffinity to ClientIP

C.Remove the ClusterIP Service and use headless service

D.Add a readiness probe to the pods

AnswerB

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.

Why this answer

Intermittent connectivity issues with multiple replicas often stem from requests being distributed across different pods, which can break session state if the application is not stateless. Setting `service.spec.sessionAffinity` to `ClientIP` ensures that all requests from a given client IP are routed to the same pod, providing stable connectivity for stateful sessions without changing the service type or removing the ClusterIP.

Exam trap

The trap here is that candidates often confuse readiness probes (which ensure pods are healthy) with session affinity (which ensures client requests stick to the same pod), leading them to select the readiness probe option despite it not solving the session persistence problem.

How to eliminate wrong answers

Option A is wrong because changing the Service type to NodePort exposes the service on a static port on each node's IP, which does not address session persistence and may introduce additional network complexity without solving the intermittent connectivity issue. Option C is wrong because removing the ClusterIP Service and using a headless service disables load balancing and DNS-based round-robin, which would break the stable connectivity goal by requiring clients to manage pod IPs directly. Option D is wrong because adding a readiness probe only controls whether a pod receives traffic based on its health, but does not ensure that requests from the same client are consistently routed to the same pod, which is the root cause of intermittent connectivity for stateful applications.

Practice this question →

MCQhard

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?

A.db-service.svc.cluster.local

B.db-service

C.db-service.backend.cluster.local

D.db-service.backend.svc.cluster.local

AnswerD

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.

Why this answer

Kubernetes DNS resolves services using the format `<service>.<namespace>.svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).

Exam trap

The trap here is that candidates often forget the 'svc' subdomain or assume that omitting the namespace works across namespaces, leading them to pick Option A or C, while the correct FQDN must include both namespace and 'svc' for reliable resolution.

How to eliminate wrong answers

Option A is wrong because it omits the namespace, so it would only resolve if the pod and service were in the same namespace; cross-namespace access requires the namespace. Option B is wrong because a bare service name without a domain suffix is only valid within the same namespace and relies on search domains, which are not guaranteed to resolve across namespaces. Option C is wrong because it uses 'backend.cluster.local' instead of 'backend.svc.cluster.local', missing the mandatory 'svc' subdomain that Kubernetes DNS expects for service records.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.To provide a single stable IP address for the service.

B.To expose a service externally via a cloud load balancer.

C.To enable a client to discover all pod IPs for a StatefulSet.

D.To enable DNS to return individual pod IPs for stateful applications.

E.To provide load-balanced access to a set of pods.

AnswersC, D

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.

Why this answer

A Headless Service (with `clusterIP: None`) does not provide a single stable IP or load balancing. Instead, it returns DNS A/AAAA records for all pod IPs that match the service's selector. This is essential for StatefulSets, where each pod has a unique identity and clients need to discover and connect to specific pods directly, such as in a database cluster.

Exam trap

The trap here is that candidates confuse a Headless Service's DNS-based pod discovery with load balancing or external exposure, when in fact it is designed to give clients direct access to individual pod IPs for stateful workloads.

Practice this question →

MCQhard

A Kubernetes cluster uses kube-proxy in IPVS mode. A Service named 'api-svc' of type ClusterIP has three endpoints: 10.244.1.5:8080, 10.244.2.6:8080, and 10.244.3.7:8080. A client pod repeatedly connects to 'api-svc' and observes that all connections are routed to the same endpoint, 10.244.1.5:8080. The client pod and the endpoints are on different nodes. What is the most likely cause?

A.The IPVS scheduler is set to 'rr' (round-robin), but session affinity is enabled on the Service.

B.The IPVS scheduler is set to 'sh' (source hashing), which consistently maps the same client IP to the same endpoint.

C.The Service has 'externalTrafficPolicy: Local' set, causing traffic to be routed only to endpoints on the same node as the client.

D.The client pod is using a persistent HTTP connection, and the Service's load balancing only applies to new TCP connections.

AnswerB

In IPVS mode, the default scheduler is 'rr' (round-robin), but if the scheduler is changed to 'sh' (source hashing), IPVS uses a hash of the source IP to select a real server. This ensures that all connections from the same client IP go to the same endpoint, explaining why the client pod always reaches 10.244.1.5. This is the most likely cause given the consistent routing without session affinity.

Why this answer

In IPVS mode, kube-proxy can use different schedulers. The default is round-robin, but if configured to source hashing ('sh'), IPVS selects the real server based on a hash of the source IP. This causes all connections from the same client IP to consistently go to the same endpoint.

Since the client pod always reaches the same endpoint across multiple connections, the most likely cause is that the IPVS scheduler is set to 'sh'.

Exam trap

The trap here is confusing connection-level load balancing with per-request load balancing; IPVS source hashing can pin a client to one endpoint even without session affinity.

Practice this question →

MCQmedium

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?

A.LoadBalancer Service

B.ClusterIP Service

C.Ingress resource with a TLS certificate

D.NodePort Service

AnswerC

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.

Why this answer

An Ingress resource with a TLS certificate is the correct choice because it provides a stable IP address (via the underlying LoadBalancer or NodePort Service) and terminates TLS at the ingress controller, allowing the web application to serve HTTPS traffic without modifying the Deployment. This meets the requirements of exposing the application externally with a fixed IP and TLS termination.

Exam trap

CNCF often tests the misconception that a LoadBalancer Service alone can terminate TLS, but in Kubernetes, TLS termination is not a built-in feature of Services; it requires an Ingress or a custom proxy, making the Ingress resource the correct choice for this requirement.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer Service exposes the application directly via a cloud load balancer, but it does not terminate TLS natively; TLS termination would require additional configuration (e.g., an external load balancer with TLS support) and the IP may change if the Service is recreated. Option B is wrong because a ClusterIP Service is only accessible within the cluster and cannot expose the application to external users. Option D is wrong because a NodePort Service exposes the application on a static port on each node's IP, but it does not provide a stable IP address (node IPs can change) and does not terminate TLS; TLS termination would require additional components like an Ingress or a reverse proxy.

Practice this question →

MCQeasy

Given the following YAML manifests in the same namespace: ```yaml apiVersion: v1 kind: Pod metadata: name: my-pod labels: app: my-app spec: containers: - name: app image: nginx ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - port: 80 targetPort: 8080 ``` A pod in the same namespace tries to reach my-service on port 80. What is the most likely outcome?

A.The connection succeeds but reaches the pod on port 80.

B.The connection fails because the endpoints list is empty.

C.The connection is randomly dropped due to missing port specification.

D.The connection succeeds and reaches the pod on port 8080.

AnswerD

The Service selects the pod via the matching `app: my-app` label, and its `targetPort: 8080` forwards traffic to the container's declared `containerPort`. kube-proxy programs the cluster IP so requests to port 80 are DNAT'd to the pod's IP on 8080, satisfying the same-namespace reachability constraint.

Why this answer

The Service my-service is configured with port: 80 and targetPort: 8080. Therefore, traffic sent to the Service on port 80 is forwarded to the pod's container port 8080, and the connection succeeds, reaching the pod on port 8080. If targetPort were not set, it would default to port 80, causing the connection to fail because the pod listens on 8080.

Exam trap

The trap here is that candidates assume the Service's `port` automatically maps to the container's listening port, but Kubernetes defaults `targetPort` to the same value as `port`, not to the container's port, so a mismatch causes connection failures unless explicitly configured.

How to eliminate wrong answers

Option A is wrong because the connection would not reach the pod on port 80 unless the Service's `targetPort` is explicitly set to 80 or omitted (defaulting to `port`), but the pod is listening on 8080, so traffic would be dropped or rejected. Option B is wrong because the endpoints list is not empty; the Service selects the pod via labels, so endpoints exist unless the pod is not running or labels mismatch. Option C is wrong because Kubernetes does not randomly drop connections due to missing port specification; if `targetPort` is omitted, it defaults to the `port` value, and traffic is forwarded deterministically to that port on the pod.

Practice this question →