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 →

Multi-Selecthard

A Kubernetes cluster uses a NetworkPolicy to restrict traffic to a set of pods labeled 'app: db'. Which TWO statements about the following NetworkPolicy are correct? apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-policy spec: podSelector: matchLabels: app: db policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: api ports: - port: 5432

Select 2 answers

A.The database pods can accept traffic on any port from pods with label 'app: api'.

B.Pods in other namespaces with label 'app: api' cannot reach the database pods.

C.The database pods can initiate outbound connections to any destination.

D.Pods from the same namespace but without matching labels can still access the database pods.

E.Pods with label 'app: api' can connect to the database pods on TCP port 5432.

AnswersC, E

Since only Ingress is specified, egress is allowed by default.

Why this answer

NetworkPolicy only restricts inbound (Ingress) traffic when `policyTypes` includes only `Ingress`. By default, if no Egress rules are defined and `policyTypes` does not include `Egress`, outbound traffic is unrestricted. Thus, the database pods can initiate connections to any destination.

Exam trap

The trap here is that candidates often forget that a NetworkPolicy with an ingress rule implicitly denies all other ingress traffic, and that `podSelector` without `namespaceSelector` restricts the rule to the same namespace, allowing cross-namespace traffic to bypass the policy.

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

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 →

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 is correctly configured with endpoints mapping port 80 to targetPort 8080.

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 →