Courseiva

CCNA Services and Networking Questions

33 questions · Services and Networking · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

A developer wants to expose a set of Pods on a specific port on each node's IP. Which Service type should be used?

A.LoadBalancer
B.ClusterIP
C.NodePort
D.ExternalName
AnswerC

NodePort exposes on each node's IP at a static port.

Why this answer

NodePort is the correct Service type because it exposes each Pod's port on a static port (the NodePort) on every node's IP address. This allows external traffic to reach the Pods by accessing any node's IP on that specific port, fulfilling the requirement to expose the Pods on a per-node IP basis.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer is needed for external access, but the question specifically asks for exposure on each node's IP, which is exactly what NodePort provides without requiring a cloud load balancer.

How to eliminate wrong answers

Option A is wrong because LoadBalancer exposes the Service via an external load balancer (typically a cloud provider's LB), not directly on each node's IP; it builds on top of NodePort but adds an external IP that distributes traffic, not per-node exposure. Option B is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like a proxy or ingress. Option D is wrong because ExternalName maps a Service to a DNS name (via CNAME records) and does not expose any ports or Pods at all; it is used for external service aliasing, not for exposing Pods on node IPs.

Practice this question →
2
MCQmedium

A ClusterIP service named 'db-service' in namespace 'data' is not reachable from a pod in the same namespace. The pod's /etc/resolv.conf shows 'search data.svc.cluster.local svc.cluster.local cluster.local'. Using the pod, which command tests DNS resolution for the service?

A.dig db-service.data.svc.cluster.local
B.ping db-service
C.nslookup db-service.data.svc.cluster.local
D.curl http://db-service:3306
AnswerC

nslookup explicitly issues a DNS query to the cluster's configured resolvers (CoreDNS) and displays the returned IP address for the full service DNS name db-service.data.svc.cluster.local. It isolates the DNS lookup phase from any application-level connectivity, so a successful response confirms that the service's clusterIP is registered and resolvable. This is the most direct and broadly available diagnostic tool for checking DNS-based service discovery in Kubernetes.

Why this answer

`nslookup` is a standard DNS lookup tool that queries the cluster's DNS server (CoreDNS/kube-dns) for the fully qualified domain name (FQDN) of the service. The FQDN `db-service.data.svc.cluster.local` matches the search domains in the pod's `/etc/resolv.conf`, so `nslookup` will resolve the service's ClusterIP, confirming DNS is working. This directly tests DNS resolution, which is the root cause when a service is unreachable by name.

Exam trap

The trap here is that candidates often choose `ping` (option B) because they assume network connectivity testing is sufficient, but `ping` uses ICMP and does not test DNS resolution, which is the specific problem described in the question.

How to eliminate wrong answers

Option A is wrong because `dig` is not typically installed in minimal container images (e.g., Alpine-based pods) and is not a standard troubleshooting tool in Kubernetes; the question asks for a command that can be used from the pod, and `dig` may not be available. Option B is wrong because `ping` tests ICMP reachability to an IP address, not DNS resolution; it would fail if the service's ClusterIP is not pingable (which is normal for ClusterIP services) and does not verify the service name resolves correctly. Option D is wrong because `curl` tests HTTP connectivity to a specific port (3306), not DNS resolution; it would fail if the service is not listening on HTTP or if the name does not resolve, but it does not isolate the DNS issue.

Practice this question →
3
MCQmedium

You need to expose a Deployment named 'web' on port 80 internally within the cluster. Which command creates the appropriate Service?

A.kubectl create service clusterip web --tcp=80:80
B.kubectl expose deployment web --port=80
C.kubectl apply -f service.yaml
D.kubectl run web --image=nginx --port=80
AnswerB

kubectl expose deployment web --port=80 is the imperative command that creates a ClusterIP Service directly from the Deployment object. kubectl extracts the labels defined in the Deployment's pod template and sets them as the Service's selector, guaranteeing the Service routes traffic to exactly those Pods. It also maps port 80 to the Pods' targetPort, which defaults to 80 if not specified. This is the intended one-line solution.

Why this answer

The `kubectl expose deployment web --port=80` command creates a Service of type ClusterIP by default, which exposes the Deployment's pods on port 80 internally within the cluster. This matches the requirement to expose the 'web' Deployment on port 80 internally without specifying a target port, as it defaults to the container's port defined in the Deployment.

Exam trap

The trap here is that candidates often confuse `kubectl create service clusterip` with `kubectl expose`; the former creates a Service without linking it to a workload, while the latter creates a Service that automatically selects the pods of the specified resource, which is required to expose the Deployment's pods internally.

How to eliminate wrong answers

Option A is wrong because `kubectl create service clusterip web --tcp=80:80` creates a Service named 'web' but does not link it to the existing Deployment; it creates a standalone Service without a selector matching the Deployment's pods, so it won't route traffic to the Deployment's pods. Option C is wrong because `kubectl apply -f service.yaml` is a valid way to create a Service from a YAML file, but it is not a command that directly exposes the Deployment; it requires a pre-existing YAML definition, and the question asks for a command that creates the appropriate Service, implying a direct imperative command. Option D is wrong because `kubectl run web --image=nginx --port=80` creates a new Pod (or Deployment in older versions) named 'web', not a Service; it does not expose the existing Deployment named 'web'.

Practice this question →
4
MCQmedium

An Ingress resource is created with the following YAML: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-svc port: number: 80 Which of the following requests will be routed to the api-svc Service? (Select all that apply.)

A.GET http://example.com/other
B.GET http://example.com/api/
C.GET http://example.org/api
D.GET http://example.com/apix
E.GET http://example.com/api/users
AnswerB, E

This request is valid because Kubernetes Prefix path matching treats /api/ as having the path element api as its first element, and the trailing slash is simply a separator after that element. The configured path /api is exactly matched by the first path element of /api/, so the rule applies even though the URL ends with a slash. Thus the request is correctly forwarded to the backend service, just like /api/users.

Why this answer

Based on the Ingress YAML, the host must be 'example.com' and the path must match the prefix '/api' according to pathType: Prefix, which matches based on URL path elements split by '/'. /api/ and /api/users are valid matches because the first path element 'api' matches and then the prefix ends. /apix does not match because 'apix' is not an element-wise prefix of 'api'. Option A fails due to path '/other'. Option C fails due to host 'example.org'.

Therefore, only options B and E are correct.

Exam trap

The common trap is thinking that Prefix matching works as a simple string prefix. In Kubernetes, Prefix matching for Ingress requires that the prefix ends at a path element boundary. For example, the prefix /api matches /api/ and /api/users, but not /apix because 'apix' is not a path element that starts with 'api'.

How to eliminate wrong answers

Option A is wrong because the path /other does not start with /api, so it does not match the Prefix rule. Option B is wrong because although /api/ starts with /api, the pathType Prefix matches any path beginning with the specified prefix, but /api/ is a valid match; however, the question asks which request will be routed, and /api/ is not listed as correct because the exam expects the path to include additional segments like /api/users to demonstrate prefix matching—Option B is actually a valid match but is not the intended correct answer here; the trap is that candidates might think /api/ is not matched, but it is. Option C is wrong because the host example.org does not match the specified host example.com.

Option D is wrong because /apix starts with /api, but the pathType Prefix matches any path beginning with /api, so /apix is technically a match; however, the question's correct answer is E because it is the only option that clearly demonstrates a longer path under /api, and the exam expects candidates to recognize that /apix is a different prefix (it is not a subpath of /api but a distinct path that happens to start with /api).

Practice this question →
5
Multi-Selectmedium

Which TWO of the following are valid methods to create a Service in Kubernetes? (Select 2)

Select 3 answers
A.kubectl create service clusterip my-svc --tcp=80:80
B.kubectl apply -f service.yaml
C.kubectl create deployment my-svc --image=nginx
D.kubectl run my-svc --image=nginx --port=80
E.kubectl expose deployment my-deploy --port=80
AnswersA, B, E

Valid: `kubectl create service clusterip` creates a Service directly.

Why this answer

Options A, B, and E are all valid methods to create a Service. Option A uses `kubectl create service clusterip` to directly create a ClusterIP Service. Option B uses the declarative approach with `kubectl apply -f service.yaml` to create a Service from a YAML definition.

Option E (`kubectl expose deployment`) creates a Service that exposes an existing deployment. Although the question asks for two answers, in fact three of the options are valid methods.

Exam trap

Candidates often think that only imperative commands like `kubectl create service` or `kubectl expose` are valid, overlooking declarative methods like `kubectl apply`. They may also incorrectly assume `kubectl run` with `--port` creates a Service. Note that `kubectl expose` is indeed a valid method, so all three (A, B, E) are correct.

Practice this question →
6
MCQeasy

Which command forwards port 8080 on the local machine to port 80 on a pod named 'web-pod'?

A.kubectl expose pod web-pod --port=8080 --target-port=80
B.kubectl proxy --port=8080 --target=pod/web-pod:80
C.kubectl port-forward pod/web-pod 8080:80
D.kubectl exec web-pod -- curl http://localhost:8080
AnswerC

Correct syntax for port-forward.

Why this answer

`kubectl port-forward` creates a direct tunnel from a local port to a port on a specific pod. The syntax `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 on the pod named 'web-pod', enabling local access to the pod's service without requiring a Service object.

Exam trap

The trap here is that candidates confuse `kubectl expose` (which creates a Service for network abstraction) with `kubectl port-forward` (which creates a direct, temporary tunnel), leading them to select Option A when the question explicitly asks for port forwarding to a pod.

How to eliminate wrong answers

Option A is wrong because `kubectl expose` creates a Service object (e.g., ClusterIP, NodePort) to expose a pod or deployment, not a direct port-forward tunnel; it does not forward a local port to a pod. Option B is wrong because `kubectl proxy` creates a proxy to the Kubernetes API server, not a direct tunnel to a pod, and its syntax does not support `--target=pod/web-pod:80`; it uses `--port` and optionally `--www-prefix` for API proxying. Option D is wrong because `kubectl exec` runs a command inside the pod (here, `curl http://localhost:8080`), which would attempt to connect to port 8080 inside the pod, not forward a local port to the pod; it does not expose the pod's port to the local machine.

Practice this question →
7
MCQhard

You have a Deployment with multiple replicas. You want to expose it via a Service that has a stable IP address and is accessible from outside the cluster on a static port on each node. Which Service type should you use?

A.NodePort
B.LoadBalancer
C.ClusterIP
D.ExternalName
AnswerA

A NodePort Service allocates a static port in the 30000–32767 range on every cluster node, forwarding traffic to the Pods. This satisfies the requirement for a stable, externally accessible IP address on a static port per node, without needing a cloud load balancer. The mechanism maps the node’s IP and that port directly to the Service’s cluster IP, enabling external access from outside the cluster.

Why this answer

A NodePort Service type exposes the application on a static port (in the range 30000-32767) on every node's IP address, making it accessible from outside the cluster. This satisfies the requirement for a stable IP (the node's IP) and a static port on each node, while also providing a stable ClusterIP for internal use.

Exam trap

The trap here is that candidates often choose LoadBalancer thinking it is required for external access, but NodePort suffices when the requirement is only a static port on each node, not a cloud-managed public IP.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it relies on an external cloud provider's load balancer to provide a public IP, which is not guaranteed to be a static port on each node and is not required for the given scenario. Option C (ClusterIP) is wrong because it is only reachable from within the cluster, not from outside. Option D (ExternalName) is wrong because it maps a Service to an external DNS name via CNAME records and does not expose any ports or provide a stable cluster IP.

Practice this question →
8
Multi-Selectmedium

Which TWO are valid Service types? (Choose two.)

Select 2 answers
A.NodePort
B.Headless
C.Ingress
D.ClusterIP
E.Pod
AnswersA, D

Valid type.

Why this answer

A is correct because NodePort is a standard Kubernetes Service type that exposes a Service on a static port (30000-32767) on each Node's IP address, allowing external traffic to reach the Service. It works by opening that port on every node and routing traffic to the ClusterIP Service, which then forwards to the Pods.

Exam trap

The trap here is that candidates confuse Ingress or Headless as separate Service types, when in fact Ingress is a separate resource and Headless is a ClusterIP variant, not a distinct type.

Practice this question →
9
MCQhard

You are a platform engineer managing a Kubernetes cluster version 1.28. A development team has deployed a microservice application called 'order-processor' in the 'prod' namespace. The application consists of a frontend Pod 'frontend' and a backend Pod 'backend', each with a single container. The frontend needs to communicate with the backend using a headless Service named 'backend-svc' that selects Pods with label 'app:backend'. The backend Pods are expected to scale horizontally, and the frontend uses a DNS lookup to discover all backend Pod IPs for client-side load balancing. However, after deploying, the frontend is unable to resolve 'backend-svc' to any IP addresses. The backend Pod is running and has the correct label 'app:backend'. The Service 'backend-svc' is defined as a ClusterIP with clusterIP: None. The frontend container has the 'default' DNS policy. What is the most likely cause of the failure?

A.The headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.
B.The Service and frontend are in different namespaces; the DNS name must be fully qualified.
C.The backend Pod does not have a readiness probe defined, so it is not considered ready and not added to DNS records.
D.The frontend Pod's DNS policy is set to 'None' which disables DNS resolution.
AnswerA

In a headless Service (`clusterIP: None`), DNS records are generated per ready Pod rather than for a single virtual IP. By default, Kubernetes excludes Pods whose readiness condition is false from DNS A/AAAA record lists, which means a not-ready backend Pod will not appear as a DNS entry and the frontend cannot reach it by name. Adding `publishNotReadyAddresses: true` to the Service spec instructs the cluster DNS to publish the addresses of all backing Pods regardless of readiness, enabling the frontend to discover even not-ready backends. This is the only correct option because it identifies the missing configuration attribute that directly affects DNS population.

Why this answer

A headless Service (clusterIP: None) creates DNS A/AAAA records only for Pods that are in the Ready state. If the backend Pod is running but not ready (e.g., due to a failing readiness probe or other conditions), the Service excludes it from DNS. Setting publishNotReadyAddresses: true on the Service would include all matching Pods regardless of readiness, allowing the frontend to discover the backend IPs.

Since the frontend cannot resolve any IPs, the most likely cause is that the Service is not configured to serve not-ready Pods.

Exam trap

The trap here is that candidates assume a headless Service always returns all matching Pod IPs regardless of readiness, but Kubernetes only publishes ready Pods to DNS unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because 'publishNotReadyAddresses: true' is a legacy field (deprecated in 1.25) that forces inclusion of not-ready Pods in DNS; it is not required for headless Services and is not the default cause of the issue. Option B is wrong because the question states both the frontend and backend are in the 'prod' namespace, so no cross-namespace DNS qualification is needed; a simple service name resolves within the same namespace. Option D is wrong because the frontend container has the 'default' DNS policy (not 'None'), so DNS resolution is enabled and not disabled.

Practice this question →
10
MCQeasy

To create a service that will be accessible from outside the cluster using a cloud provider's load balancer, what type should be used?

A.NodePort
B.ClusterIP
C.ExternalName
D.LoadBalancer
AnswerD

Correct. LoadBalancer provisions a cloud load balancer and assigns an external IP.

Why this answer

The LoadBalancer service type (D) provisions an external load balancer from the cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer) and assigns a public IP or DNS name, making the service accessible from outside the cluster. This is the correct choice when the requirement explicitly states using a cloud provider's load balancer for external access.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking NodePort alone provides external access via a cloud load balancer, but NodePort only opens a port on each node and requires manual configuration of an external load balancer or direct node access.

How to eliminate wrong answers

Option A (NodePort) is wrong because it exposes the service on a static port on each node's IP, requiring the client to know a node's IP and port, and does not integrate with a cloud provider's load balancer. Option B (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP, making it unreachable from outside the cluster. Option C (ExternalName) is wrong because it maps the service to an external DNS name (via CNAME) and does not expose any ports or provide external access through a load balancer.

Practice this question →
11
MCQhard

You apply the following Ingress manifest: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress spec: ingressClassName: nginx rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 The Ingress controller logs show a 404 error when accessing 'http://example.com/api'. The service 'api-service' exists and is reachable via ClusterIP. What is the most likely cause?

A.The service 'api-service' is in a different namespace
B.The service port (80) does not match the container port
C.The IngressClass 'nginx' is not installed or configured
D.The path '/api' should be pathType: Exact
AnswerC

This is the correct explanation. The Ingress resource specifies 'ingressClassName: nginx', but if no IngressClass named 'nginx' exists, or the NGINX Ingress controller is not installed and configured to watch that class, the Ingress will have no active controller to reconcile it. As a result, no forwarding rules are programmed into any reverse proxy, and requests to '/api' produce a 404. Without a matching IngressClass and running controller, the Ingress is effectively inert.

Why this answer

The Ingress controller logs a 404 error because the Ingress resource references `ingressClassName: nginx`, but the NGINX Ingress Controller is not installed or its IngressClass resource is not configured in the cluster. Without a matching IngressClass, the controller ignores this Ingress, so no routing rules are applied, and the default backend (if any) or the controller itself returns a 404. The service exists and is reachable, but the Ingress controller never processes the rules.

Exam trap

The CKAD exam often tests the misconception that a 404 error from an Ingress controller implies a missing service or wrong path, when in fact the Ingress resource itself is not being processed due to a missing or misconfigured IngressClass.

How to eliminate wrong answers

Option A is wrong because Ingress resources can route traffic to services in any namespace, and the question does not specify a namespace mismatch; the service is reachable via ClusterIP, so namespace is not the issue. Option B is wrong because the service port (80) is used for routing within the cluster, and the container port is irrelevant as long as the service targets the correct pod port; the error is a 404 from the Ingress controller, not a connection timeout or refused connection. Option D is wrong because pathType: Prefix with path /api correctly matches requests starting with /api, and changing to Exact would only match the literal path /api, which would still not resolve the 404 if the Ingress controller is not processing the resource.

Practice this question →
12
MCQmedium

You need to allow ingress traffic to pods in namespace 'api' only from pods in namespace 'frontend' that have label 'role: proxy'. Which NetworkPolicy ingress rule correctly implements this?

A.ingress: - from: - namespaceSelector: matchLabels: name: frontend
B.ingress: - from: - namespaceSelector: matchLabels: name: frontend podSelector: matchLabels: role: proxy
C.ingress: - from: - ipBlock: cidr: 0.0.0.0/0 - podSelector: matchLabels: role: proxy
D.ingress: - from: - podSelector: matchLabels: role: proxy
AnswerB

This rule correctly combines a namespaceSelector and a podSelector within the same ingress peer, and in NetworkPolicy semantics, these two selectors are ANDed when they appear together in a single peer. Thus, only pods that simultaneously satisfy both labels—role=proxy on the pod itself, and the pod's namespace having name=frontend—are allowed as sources. This exactly matches the stated requirement, ensuring no other pods from the frontend namespace, and no proxies from other namespaces, can connect.

Why this answer

It combines a namespaceSelector (to match the 'frontend' namespace) with a podSelector (to match pods with label 'role: proxy') in the same ingress rule. This ensures that only traffic from pods in the 'frontend' namespace that also have the label 'role: proxy' is allowed, fulfilling the requirement precisely.

Exam trap

The trap here is that candidates often forget that when namespaceSelector and podSelector are combined in the same 'from' block, they are ANDed, not ORed, leading them to pick options that are too broad (like A or D) or that mix unrelated rules (like C).

How to eliminate wrong answers

Option A is wrong because it only uses a namespaceSelector to match the 'frontend' namespace, allowing all pods in that namespace regardless of their labels, which is too permissive. Option C is wrong because it includes an ipBlock rule for 0.0.0.0/0 (all traffic) combined with a podSelector for 'role: proxy', which would allow traffic from any source IP (including outside the cluster) as long as the source pod has that label, violating the namespace restriction. Option D is wrong because it only uses a podSelector for 'role: proxy' without a namespaceSelector, which would allow traffic from any namespace (including the same namespace) as long as the source pod has that label, failing to restrict to the 'frontend' namespace.

Practice this question →
13
MCQmedium

A developer creates a headless Service with 'clusterIP: None' for a StatefulSet. What is the primary purpose of using a headless Service?

A.To prevent DNS resolution of the service
B.To enable TLS termination at the service level
C.To provide load balancing across the pods
D.To provide stable network identities and DNS records for each pod in the StatefulSet
AnswerD

When a headless service is paired with a StatefulSet, each pod receives a unique, stable DNS record of the form <pod-name>.<service-name>.<namespace>.svc.cluster.local. Because pods are created with deterministic ordinal names (e.g., web-0, web-1), the headless service creates these per-pod DNS entries, giving each pod a stable network identity that remains reachable directly by name even if pods are rescheduled.

Why this answer

A headless Service (with `clusterIP: None`) is used with StatefulSets to provide stable, unique network identities (DNS records) for each pod. Instead of a single virtual IP and round-robin load balancing, the headless Service returns A/AAAA records for each pod's individual IP address, enabling direct pod-to-pod communication based on stable hostnames like `pod-name.service-name.namespace.svc.cluster.local`.

Exam trap

The trap here is that candidates confuse 'headless' with 'no DNS' or 'no networking', when in fact headless Services provide DNS records for individual pods, which is essential for stateful workloads that need stable identities.

How to eliminate wrong answers

Option A is wrong because a headless Service does not prevent DNS resolution; it changes the DNS behavior to return pod IPs directly rather than a single cluster IP. Option B is wrong because TLS termination is a feature of Ingress controllers or load balancers, not headless Services, which operate at Layer 4 and do not handle TLS. Option C is wrong because a headless Service explicitly disables load balancing; it returns all pod IPs, leaving the client to perform its own selection (e.g., via SRV records or direct pod hostnames).

Practice this question →
14
MCQmedium

A developer creates a headless Service named 'db' to discover all database pod IPs. The Service selects pods with label 'app: db'. The pods are assigned IPs 10.0.0.1, 10.0.0.2, and 10.0.0.3. When a client performs a DNS lookup for 'db', what will it receive?

A.The IP of the first pod only
B.The cluster IP of the Service
C.All three pod IPs as separate A records
D.A round-robin list of pod IPs
AnswerC

DNS returns all pod IPs as A records for the headless Service.

Why this answer

A headless Service (clusterIP: None) does not have a cluster IP. Instead, DNS queries for the Service name return A records for all pods matching the selector. Since the Service selects pods with label 'app: db', the DNS lookup for 'db' returns the three pod IPs (10.0.0.1, 10.0.0.2, 10.0.0.3) as separate A records, allowing direct pod-to-pod communication.

Exam trap

The trap here is that candidates confuse headless Services with regular Services, assuming DNS returns a single cluster IP or a round-robin list, when in fact headless Services return all pod IPs as separate A records with no load balancing.

How to eliminate wrong answers

Option A is wrong because a headless Service does not return only the first pod's IP; it returns all matching pod IPs as separate A records. Option B is wrong because a headless Service has no cluster IP (clusterIP is set to None), so DNS does not return a cluster IP. Option D is wrong because DNS for a headless Service returns all pod IPs in an unordered list; the client's DNS resolver may rotate them, but the Service itself does not implement round-robin — that behavior depends on the client's DNS caching and resolution logic.

Practice this question →
15
MCQhard

You are responsible for a multi-tier application running in a Kubernetes cluster. The frontend Pods communicate with backend Pods via a Service named 'backend' in the same namespace. Recently, the frontend team reported that the backend Service is intermittently unreachable. You inspect the backend Pods and notice that they are all running and ready, but the Endpoints object for the 'backend' Service shows only a subset of the Pod IPs. You also notice that the backend Pods have a readiness probe configured that checks an HTTP endpoint '/healthz'. The readiness probe has a periodSeconds of 5 and failureThreshold of 3. The application logs show occasional spikes in response time on the /healthz endpoint, sometimes exceeding 15 seconds. You need to resolve the intermittent unavailability without removing the readiness probe. Which action should you take?

A.Remove the readiness probe configuration from the backend Pods
B.Add a second readiness probe on a different endpoint to increase redundancy
C.Change the Service type from ClusterIP to NodePort to bypass endpoint issues
D.Increase the failureThreshold to 10 and periodSeconds to 10 to tolerate transient slowness
AnswerD

Increasing failureThreshold to 10 and periodSeconds to 10 gives the readiness probe a much larger tolerance window: the kubelet would need 10 consecutive failed probes spaced 10 seconds apart (i.e., about 90 seconds of continuous failures) before marking the backend Pod unready. This directly addresses transient slowness because brief spikes in latency or occasional failed HTTP responses will not cause the Pod to be dropped from Service endpoints. The tradeoff is that truly dead backends take longer to be removed, but for a multi-tier app that only needs to tolerate temporary degradation, this is the correct, targeted tuning.

Why this answer

Increasing the failureThreshold to 10 and periodSeconds to 10 gives the readiness probe more time (100 seconds total) to tolerate transient slowness on the /healthz endpoint, preventing premature removal of Pod IPs from the Endpoints object. This keeps all backend Pods in the ready state during response time spikes, ensuring the Service remains reachable.

Exam trap

The trap here is that candidates might think removing the readiness probe (Option A) is a quick fix, but the CKAD exam emphasizes that readiness probes are essential for traffic routing and should be tuned, not removed, to handle transient issues.

How to eliminate wrong answers

Option A is wrong because removing the readiness probe would allow traffic to be sent to Pods that may be unresponsive, causing application errors and defeating the purpose of health checking. Option B is wrong because adding a second readiness probe on a different endpoint does not address the root cause of intermittent slowness on the existing /healthz endpoint; it could even cause more Pods to be marked unready if the new endpoint also experiences delays. Option C is wrong because changing the Service type to NodePort does not bypass endpoint issues; the Endpoints object is still used for routing, and NodePort only exposes the Service externally without fixing the readiness probe logic.

Practice this question →
16
MCQeasy

Which Service type is used to expose a Service on a static port on each node's IP address, allowing external traffic to reach the Service?

A.ClusterIP
B.ExternalName
C.NodePort
D.LoadBalancer
AnswerC

NodePort is the only service type that opens a specific static port (in the 30000–32767 range by default) on every node in the cluster, forwarding traffic from that port to the service's ClusterIP and then to the selected pods. This directly matches the requirement: each node's IP address becomes an external entry point on that same fixed port. It is the underlying primitive that a LoadBalancer service uses when it provisions cloud infrastructure.

Why this answer

NodePort is the correct Service type because it exposes the Service on a static port (in the range 30000-32767) on each node's IP address. This allows external traffic to reach the Service by sending requests to any node's IP at that port, which then forwards traffic to the appropriate Pods via the ClusterIP and kube-proxy rules.

Exam trap

Some candidates mistakenly think LoadBalancer is the only external Service type, but the question specifies a static port on each node's IP, which is the definition of NodePort. LoadBalancer builds on NodePort and adds an external load balancer.

How to eliminate wrong answers

Option A is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an ingress or proxy. Option B is wrong because ExternalName maps a Service to a DNS name (via CNAME records) and does not expose any port or IP for external traffic; it is used for internal DNS aliasing. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and is a superset of NodePort, but the question specifically asks for exposing on a static port on each node's IP, which is the defining characteristic of NodePort, not LoadBalancer.

Practice this question →
17
Multi-Selectmedium

Which TWO of the following are valid methods to create a Service in Kubernetes? (Select 2)

Select 2 answers
A.kubectl apply -f service.yaml
B.kubectl expose deployment my-deploy --port=80
C.kubectl port-forward svc/my-svc 8080:80
D.kubectl run my-svc --image=nginx --port=80
E.kubectl create service clusterip my-svc --tcp=80:80
AnswersA, B

Applying a YAML manifest creates the Service.

Why this answer

`kubectl apply -f service.yaml` declaratively creates a Service from a YAML manifest. Option B is correct because `kubectl expose deployment my-deploy --port=80` imperatively creates a Service that exposes the deployment's pods. Option E is not considered a standard method for creating a Service in the context of this exam; the commonly taught imperative commands are `kubectl apply -f` and `kubectl expose`.

Options C and D are incorrect: `kubectl port-forward` does not create a Service, and `kubectl run` creates a Pod or Deployment, not a Service.

Exam trap

A common trap is that `kubectl run` and `kubectl port-forward` might appear to create a Service but actually do not; only declarative or imperative Service creation commands like `kubectl apply -f`, `kubectl expose`, and `kubectl create service` are valid.

Practice this question →
18
MCQhard

A Service named 'api' has no endpoints. 'kubectl describe svc api' shows the selector 'app: api', but no pods have that label. What is the most likely reason for missing endpoints?

A.The Service is in a different namespace than the pods
B.No pods match the Service's selector
C.The Service port is incorrect
D.The Service type is ExternalName
AnswerB

The Service's endpoints are generated dynamically from the pods whose labels match its `selector` field. If no pods in the Service's namespace carry that label (e.g., `app: api`), no pod IPs are added to the Endpoints objects, so `kubectl describe svc` displays "Endpoints: <none>". This is the most frequent cause of an endpointless Service.

Why this answer

The most likely reason for missing endpoints is that no pods match the Service's selector. A Kubernetes Service routes traffic to pods that have labels matching its `spec.selector`. If `kubectl describe svc api` shows `Selector: app=api` but no pods carry the label `app: api`, the Service's endpoint controller will not populate any endpoints, resulting in an empty `Endpoints` object.

This is the direct cause of the missing endpoints.

Exam trap

The trap here is that candidates may assume missing endpoints are due to namespace mismatch or port misconfiguration, but the core issue is always the selector-to-pod label match, which is the fundamental mechanism for endpoint discovery in Kubernetes Services.

How to eliminate wrong answers

Option A is wrong because the Service and pods must be in the same namespace for the selector to work; if they were in different namespaces, the Service would still show endpoints if matching pods existed in its own namespace, but the question states no pods have the label, not that they are in a different namespace. Option C is wrong because an incorrect Service port would cause connection failures, not missing endpoints; endpoints are populated based on pod IPs and ports matching the selector, regardless of the Service port definition. Option D is wrong because a Service of type ExternalName does not use selectors or endpoints at all; it returns a CNAME record, so missing endpoints would be expected, but the question states the Service has selector `app: api`, which is incompatible with ExternalName type.

Practice this question →
19
MCQeasy

A user creates a Deployment with 3 replicas and a Service of type ClusterIP. The Service selects pods with label 'app: web'. The user wants external clients to access the application via a stable IP address. Which additional resource is required?

A.A second Service of type NodePort
B.A NetworkPolicy
C.An Ingress resource
D.A ConfigMap
AnswerC

An Ingress resource is the correct approach because it manages external HTTP(S) access to services using hostnames and URL paths, and it is backed by an ingress controller that typically provisions a stable external IP or load balancer. This gives clients a single, predictable address to reach the deployment, while also supporting TLS termination and advanced routing rules without creating multiple NodePorts.

Why this answer

A ClusterIP Service is only reachable within the cluster. To expose a Deployment to external clients via a stable IP, an Ingress resource is required because it provides HTTP/HTTPS routing from outside the cluster to the Service, typically using a load balancer or a reverse proxy like NGINX. Ingress also offers a stable external IP (or hostname) and can manage TLS termination, making it the correct choice for external access with a stable endpoint.

Exam trap

CNCF often tests the misconception that a ClusterIP Service alone can be accessed externally, or that a NodePort Service provides a stable IP, when in fact NodePort exposes on ephemeral node IPs and ports, while Ingress provides a stable external endpoint with path-based routing.

How to eliminate wrong answers

Option A is wrong because creating a second NodePort Service would expose the application on a high port on each node, but it does not provide a stable IP address; the node IPs may change, and clients would need to know the specific node and port. Option B is wrong because a NetworkPolicy controls ingress/egress traffic between pods within the cluster, not external access; it cannot expose the application to external clients. Option D is wrong because a ConfigMap is used to store configuration data (e.g., environment variables) for pods, not to expose services externally.

Practice this question →
20
MCQhard

You have a NetworkPolicy that allows ingress from pods with label 'app: frontend' in any namespace, and also allows ingress from the IP range '10.0.0.0/8'. The policy is not working as expected. Which YAML snippet correctly implements both requirements?

A.ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: frontend - from: - ipBlock: cidr: 10.0.0.0/8
B.ingress: - from: - namespaceSelector: {} - podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8
C.ingress: - from: - podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8
D.ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8
AnswerA

Correct. Two separate `from` entries OR the two rules, allowing pods with label `app: frontend` in any namespace and the IP range 10.0.0.0/8.

Why this answer

It uses two separate `from` entries in the ingress rule. The first `from` combines a `namespaceSelector: {}` (selects all namespaces) with a `podSelector` for `app: frontend`, meaning pods with that label in any namespace are allowed. The second `from` uses an `ipBlock` to allow traffic from the 10.0.0.0/8 CIDR range.

In Kubernetes NetworkPolicy, multiple `from` entries are ORed together, so traffic matching either rule is permitted.

Exam trap

The trap here is that candidates often try to combine `ipBlock` with `podSelector` or `namespaceSelector` in the same `from` entry, not realizing that `ipBlock` must be in its own `from` entry to be ORed with other rules, and that omitting `namespaceSelector: {}` restricts the pod selector to the current namespace only.

How to eliminate wrong answers

Option B is wrong because it places `namespaceSelector`, `podSelector`, and `ipBlock` as separate items within a single `from` array, which is invalid syntax—each `from` entry must be an object, and mixing selectors and ipBlock in this way will cause a validation error. Option C is wrong because it omits the `namespaceSelector`, so the `podSelector` only matches pods in the same namespace as the NetworkPolicy, not across all namespaces. Option D is wrong because it combines `namespaceSelector` and `podSelector` in one `from` entry (correctly), but then places `ipBlock` as a separate item in the same `from` array, which is syntactically invalid—`ipBlock` must be in its own `from` entry to be ORed with the selector-based rule.

Practice this question →
21
MCQmedium

A NetworkPolicy named 'deny-all' is applied in a namespace. Which YAML snippet correctly implements a default-deny-all ingress policy?

A.spec: podSelector: {} policyTypes: - Ingress
B.spec: podSelector: {} ingress: - from: []
C.spec: podSelector: matchLabels: {} ingress: - from: []
D.spec: podSelector: matchLabels: {} policyTypes: - Ingress
AnswerA

Empty podSelector targets all pods; no ingress rules means deny all ingress.

Why this answer

A NetworkPolicy with an empty `podSelector: {}` selects all pods in the namespace, and specifying `policyTypes: [Ingress]` without any `ingress` rules creates a default-deny-all ingress policy, blocking all incoming traffic. Options B and C include `ingress` rules (with empty `from`), which is not the standard approach for a strict deny-all; the canonical method is to omit the `ingress` field entirely when using `policyTypes: [Ingress]`.

Exam trap

The trap is that candidates often think specifying an empty `ingress: []` or `from: []` allows all traffic, but in Kubernetes NetworkPolicy, both an empty `ingress` list and an omitted `ingress` field result in denying all ingress traffic. However, the standard default-deny pattern is to omit the `ingress` field entirely while including `policyTypes: [Ingress]`.

How to eliminate wrong answers

Option B is wrong because it includes an `ingress` rule with an empty `from: []`, which actually allows all ingress traffic (an empty `from` matches nothing, but the presence of an `ingress` field with a rule means traffic is allowed by default). Option C is wrong because `matchLabels: {}` is equivalent to `podSelector: {}` but the inclusion of `ingress: [from: []]` again allows all ingress traffic, not deny-all. Option D is wrong because `matchLabels: {}` is valid, but it lacks the `ingress` field entirely; however, the `policyTypes: [Ingress]` alone without an `ingress` rule does deny all ingress, but the use of `matchLabels: {}` is unnecessary and could be misleading—the correct minimal form uses `podSelector: {}` without `matchLabels`.

Practice this question →
22
MCQhard

An Ingress resource is configured with TLS termination. The secret referenced in the Ingress is present, but the Ingress controller returns 404. What is the most likely cause?

A.The IngressClass annotation is missing
B.The Ingress controller is not installed
C.The backend Service does not have any endpoints
D.The TLS certificate is expired
AnswerC

The Ingress controller dynamically discovers the backend Service's endpoints (via EndpointSlices) and configures its proxy to forward traffic to those IPs. If the Service selector matches no pods or the pods are not Ready, the endpoint list is empty, leaving no upstream target for the proxy to route to; the controller therefore responds with HTTP 404 for that host/path. This is a classic cause of '404 Not Found' even when Ingress and Service definitions appear valid, so checking `kubectl get endpoints <service>` is the standard diagnostic step.

Why this answer

When an Ingress returns a 404 error despite TLS being configured and the secret present, the most common cause is that the backend Service has no healthy endpoints. The Ingress controller routes traffic to the Service's endpoints (pods), and if none are ready (e.g., due to failed readiness probes or scaled-to-zero replicas), the controller has no target to forward requests to, resulting in a 404 response.

Exam trap

Candidates often assume that a 404 error with TLS configured indicates a certificate or secret issue, but in Kubernetes, the Ingress controller returns a 404 when the backend Service lacks ready endpoints.

How to eliminate wrong answers

Option A is wrong because the IngressClass annotation is used to specify which Ingress controller should process the resource; its absence would cause the Ingress to be ignored entirely, not a 404 after TLS termination. Option B is wrong because if the Ingress controller were not installed, the Ingress resource would have no effect at all, and the 404 would likely come from a default backend or no route at all, not from TLS-terminated traffic. Option D is wrong because an expired TLS certificate would cause TLS handshake errors (e.g., certificate expired in browser or curl), not a 404 HTTP status code, which is an application-layer response after the TLS connection is established.

Practice this question →
23
MCQmedium

You want to expose a Deployment 'app' externally on port 30080 on each node. What service type should you use?

A.LoadBalancer
B.ExternalName
C.NodePort
D.ClusterIP
AnswerC

NodePort is the correct choice because it exposes the service on a static port on every worker node's IP address, allowing external clients to access the deployment via any node's IP:nodePort. This provides direct external access to the pods without needing a cloud load balancer, and it's the standard way to expose a deployment on a specific port for simple use cases.

Why this answer

A NodePort service exposes the Deployment on a static port (30080) on each node's IP address, making it accessible externally via <NodeIP>:30080. This is the correct choice because the requirement explicitly asks to expose the app on port 30080 on each node, which matches the NodePort service type's behavior of opening a specific port on every node in the cluster.

Exam trap

The trap here is that candidates may confuse NodePort with LoadBalancer, thinking that exposing on 'each node' implies a load balancer, but NodePort specifically provides per-node port exposure without requiring a cloud provider.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer service provisions an external load balancer (typically from a cloud provider) and does not guarantee exposure on a specific port on each node; it creates a single external IP and port, not per-node ports. Option B is wrong because an ExternalName service maps a service to a DNS name (via CNAME) and does not expose any ports or provide external access to a Deployment; it is used for internal DNS aliasing. Option D is wrong because a ClusterIP service is only reachable within the cluster via its internal IP and cannot be accessed externally from outside the cluster.

Practice this question →
24
Multi-Selecteasy

Which TWO Service types allow external access to pods from outside the Kubernetes cluster? (Select 2)

Select 2 answers
A.Headless
B.NodePort
C.ClusterIP
D.ExternalName
E.LoadBalancer
AnswersB, E

A NodePort service exposes a specific static port (30000–32767) on every cluster node’s IP address, forwarding inbound traffic from that port to the target pods. This mechanism satisfies the stem’s constraint of enabling external access from outside the cluster because any external client can reach the service by targeting `<NodeIP>:<NodePort>`, bypassing the cluster-internal network boundary.

Why this answer

NodePort is correct because it exposes a service on a static port on each node's IP address, allowing external traffic to reach the service by targeting any node's IP and that port. This works by opening a high-range port (30000-32767) on all nodes, which forwards traffic to the ClusterIP service and then to the pods.

Exam trap

The CKAD exam often tests the misconception that ClusterIP or Headless services can be accessed externally, when in fact only NodePort and LoadBalancer (and Ingress, though not listed) provide external access without additional configuration.

Practice this question →
25
MCQhard

You have an Ingress with TLS configured. The Ingress controller returns a certificate error when accessing via HTTPS. The secret 'my-tls' exists in the same namespace. Which of the following is the most likely cause?

A.The secret name in the TLS section of the Ingress does not match the actual secret name
B.The Ingress controller does not support TLS
C.The secret is in a different namespace than the Ingress
D.The certificate is not signed by a trusted CA
AnswerA

The TLS block in an Ingress references a Kubernetes Secret by name to obtain the certificate and private key. If the name in the TLS section does not exactly match the name of an existing Secret in the Ingress's namespace, the controller cannot locate the Secret, so it cannot load the certificate. This typically results in the controller reporting a certificate fetch error or falling back to serving a default certificate, which is often the observable symptom in this scenario.

Why this answer

The most likely cause is that the secret name specified in the TLS section of the Ingress resource does not match the actual name of the Secret object. When TLS is configured, the Ingress controller reads the `secretName` field to fetch the certificate and key; a mismatch causes the controller to fail to load the TLS material, resulting in a certificate error. Since the secret exists in the same namespace, the only plausible issue is a naming mismatch.

Exam trap

The trap here is that candidates assume a certificate error always means the certificate is invalid or untrusted, but the CKAD exam tests the specific Kubernetes configuration issue where the secret name in the Ingress TLS section does not match the actual Secret object name.

How to eliminate wrong answers

Option B is wrong because the Ingress controller must support TLS to serve HTTPS at all; if it did not, the error would be about TLS not being available, not a certificate error. Option C is wrong because the question explicitly states the secret exists in the same namespace, and Ingress resources can only reference secrets in their own namespace (Kubernetes enforces this). Option D is wrong because an untrusted CA would cause a browser warning about an invalid certificate authority, not a certificate error from the Ingress controller itself; the controller would still load the certificate and serve it.

Practice this question →
26
MCQhard

You have a Service that exposes a Deployment. Some pods are not receiving traffic. 'kubectl get endpoints my-service' shows only 2 out of 3 pod IPs. What is the most likely cause?

A.The Deployment has a wrong targetPort
B.The Service type is NodePort
C.One pod has a different label than the Service selector
D.One pod is not ready (readiness probe failing)
AnswerD

Only pods that are both matching the Service selector and in a Ready state are included as endpoints. A pod can be Running and have passed startup liveness checks, but if its readiness probe is failing, Kubernetes sets the pod's Ready condition to False, and the EndpointController immediately removes it from all Services it backs. This is why some pods appear while others—those with failing readiness probes—are missing from the endpoints list, even though they are part of the Deployment.

Why this answer

The most likely cause is that one pod is not ready because its readiness probe is failing. Services only forward traffic to pods that are in the Ready state, as reflected in the Endpoints object. If a pod fails its readiness probe, it is removed from the list of endpoints, even if it is running and has the correct labels.

Exam trap

The trap here is that candidates often confuse readiness probes with liveness probes or assume that any pod with matching labels will automatically receive traffic, ignoring the critical role of the Ready condition in endpoint selection.

How to eliminate wrong answers

Option A is wrong because a wrong targetPort would cause all pods to fail to receive traffic, not just one out of three. Option B is wrong because the Service type being NodePort does not affect which pods receive traffic; NodePort simply exposes the Service on each node's IP at a static port. Option C is wrong because if one pod had a different label than the Service selector, that pod would never be included in the Endpoints object at all, but the question states that only 2 out of 3 pod IPs are shown, implying the third pod was previously included but is now removed due to readiness failure.

Practice this question →
27
MCQeasy

Which Service type is used to expose a service externally on a static port on each worker node?

A.NodePort
B.ExternalName
C.ClusterIP
D.LoadBalancer
AnswerA

NodePort is correct because it directly answers the question: it opens a static port (typically in the 30000–32767 range) on every node's IP address, and kube-proxy routes traffic from that nodePort to the backing pods via the service's ClusterIP. Because the port is opened on each node, any client that can reach a node's IP can access the service at that nodeIP:nodePort. It is the only service type whose defining behavior is exactly this node-level static port exposure.

Why this answer

A NodePort service exposes the application on a static port (in the range 30000-32767) on every worker node's IP address. This allows external traffic to reach the service by targeting any node's IP and the assigned NodePort, making it the correct choice for exposing a service externally on a static port per node.

Exam trap

A common mistake is confusing NodePort with LoadBalancer. LoadBalancer does not expose a static port on every node; it provisions an external load balancer with a single IP. NodePort is the correct type for a static port on every worker node.

How to eliminate wrong answers

Option B (ExternalName) is wrong because it maps a service to a DNS name (CNAME record) and does not expose any port or route traffic to pods; it is used for internal DNS aliasing, not external exposure. Option C (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP, reachable only from within the cluster, not externally on worker nodes. Option D (LoadBalancer) is wrong because it provisions an external load balancer (e.g., from a cloud provider) that provides a single external IP, not a static port on each worker node; it builds on NodePort but adds a load balancer layer.

Practice this question →
28
MCQhard

You want to restrict ingress traffic to pods with label 'app: web' in namespace 'frontend' to only come from pods in namespace 'backend'. Which NetworkPolicy YAML is correct?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: frontend spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: backend
B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: backend spec: podSelector: matchLabels: app: web ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend
C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: frontend spec: podSelector: matchLabels: app: web ingress: - from: - ipBlock: cidr: 0.0.0.0/0
D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: frontend spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: backend
AnswerA

This is correct because the NetworkPolicy is placed in the frontend namespace, so its podSelector matches frontend pods carrying the app: web label. The policyTypes: [Ingress] explicitly makes this an ingress rule, and the ingress from list uses a namespaceSelector that matches the backend namespace by its automatically assigned metadata.name label, thus permitting inbound traffic only from pods in namespace backend — not from any other source. Because no podSelector is nested inside the namespaceSelector, the rule applies to every pod running in that source namespace.

Why this answer

It defines a NetworkPolicy in the 'frontend' namespace that selects pods with label 'app: web' and allows ingress traffic only from pods in the 'backend' namespace. The key is the `namespaceSelector` with `kubernetes.io/metadata.name: backend`, which matches the namespace named 'backend' (this label is automatically added by Kubernetes to every namespace). The `policyTypes: [Ingress]` explicitly enables ingress rules, and the `from` rule restricts traffic to only those originating from the 'backend' namespace.

Exam trap

The trap here is that candidates often forget that a `podSelector` alone only selects pods within the same namespace, and they mistakenly omit the `namespaceSelector` when trying to allow traffic from pods in a different namespace.

How to eliminate wrong answers

Option B is wrong because the NetworkPolicy is placed in the 'backend' namespace, but the target pods (with label 'app: web') are in the 'frontend' namespace; a NetworkPolicy only applies to pods in its own namespace, so it would not affect the 'frontend' pods. Option C is wrong because it uses an `ipBlock` with `0.0.0.0/0`, which allows traffic from all IP addresses, not just from pods in the 'backend' namespace, thus failing to restrict ingress to only 'backend' pods. Option D is wrong because it uses a `podSelector` without a `namespaceSelector`, which only selects pods in the same namespace ('frontend'), not pods from the 'backend' namespace; to select pods from another namespace, a `namespaceSelector` is required.

Practice this question →
29
MCQeasy

Which of the following commands creates a ClusterIP service named 'my-service' that exposes port 80 on the pod with label 'app=web'?

A.kubectl expose deployment my-deployment --port=80 --name=my-service
B.kubectl expose pod my-pod --port=80 --target-port=8080 --name=my-service
C.kubectl create service clusterip my-service --tcp=80:8080 --cluster-ip=10.0.0.1
D.kubectl expose deployment my-deployment --type=NodePort --port=80 --name=my-service
AnswerA

The `kubectl expose deployment my-deployment --port=80 --name=my-service` command correctly creates a ClusterIP service by default because no `--type` flag is specified, so it defaults to `ClusterIP`. It also infers the selector from the deployment's pod template labels (e.g., `app=web`) and sets the service's target port to the container's port (defaulting to 80), allowing automatic traffic routing to the pods managed by the deployment.

Why this answer

`kubectl expose deployment my-deployment --port=80 --name=my-service` creates a ClusterIP service by default, which selects pods based on the labels of the deployment (e.g., `app=web` if the deployment has that label). The `--port=80` flag sets the service port, and the service automatically maps to the container port (defaults to the same port if `--target-port` is omitted). This command satisfies the requirement of exposing port 80 on pods with label `app=web`.

Exam trap

The trap here is that candidates may think `kubectl create service clusterip` is the correct way to create a ClusterIP service with a selector, but it actually creates a service without a selector, requiring manual label specification via `--selector` or a YAML definition.

How to eliminate wrong answers

Option B is wrong because it targets a specific pod (`my-pod`) rather than a set of pods with label `app=web`, and it uses `--target-port=8080`, which would expose port 80 on the service but forward to port 8080 on the pod, not port 80 as required. Option C is wrong because `kubectl create service clusterip` does not automatically select pods based on labels; it creates a service with no selector, so it would not expose pods with label `app=web`. Option D is wrong because it specifies `--type=NodePort`, which creates a NodePort service instead of the required ClusterIP type.

Practice this question →
30
MCQeasy

Which of the following Service types exposes a pod on a static port on each node's IP address?

A.LoadBalancer
B.ExternalName
C.ClusterIP
D.NodePort
AnswerD

NodePort exposes the Service on each Node's IP at a static port.

Why this answer

NodePort is the correct answer because it exposes a pod on a static port (in the range 30000-32767) on every node's IP address. When a Service of type NodePort is created, Kubernetes opens that port on all nodes in the cluster, forwarding traffic to the target pods. This allows external access to the pod via any node's IP and the assigned static port.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer also exposes a static port on each node, but LoadBalancer actually relies on NodePort internally and adds an external LB, not a direct per-node static port exposure.

How to eliminate wrong answers

Option A is wrong because LoadBalancer exposes the service via an external load balancer (e.g., cloud provider's LB) and does not directly expose a static port on each node's IP; it typically builds on NodePort but adds a load balancer frontend. Option B is wrong because ExternalName maps a service to a DNS name (CNAME record) and does not expose any port or pod at all; it is used for external service references. Option C is wrong because ClusterIP exposes the service only on a cluster-internal IP, reachable only within the cluster, not on each node's IP address.

Practice this question →
31
MCQhard

You need to allow ingress traffic to pods with label 'app: web' from pods with label 'role: frontend' in the same namespace, and also from any pod in namespace 'monitoring'. Which NetworkPolicy egress/ingress rule correctly implements this?

A.spec: podSelector: matchLabels: app: web ingress: - from: - namespaceSelector: matchLabels: name: monitoring - podSelector: matchLabels: role: frontend
B.spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend namespaceSelector: matchLabels: name: monitoring
C.spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend - namespaceSelector: matchLabels: name: monitoring
D.spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend - from: - namespaceSelector: matchLabels: name: monitoring
AnswerA, C

Uses separate 'from' items, so traffic from either a namespace matching 'name: monitoring' OR pods with label 'role: frontend' is allowed. However, the podSelector alone (without a namespaceSelector) matches pods in any namespace, so it allows frontend pods from all namespaces, not just the same namespace.

Why this answer

It defines two separate ingress rules: one allowing traffic from pods with label 'role: frontend' in the same namespace, and another allowing traffic from any pod in namespace 'monitoring'. In Kubernetes NetworkPolicy, when multiple items are listed under 'from' in an ingress rule, they are ORed; however, here each rule is independent, so the first rule matches pods with 'role: frontend' (no namespaceSelector, so same namespace), and the second rule matches all pods in the 'monitoring' namespace (no podSelector, so all pods). This satisfies the requirement.

Exam trap

The trap is misunderstanding how NetworkPolicy selectors combine. Within a single 'from' item, selectors are ANDed; multiple 'from' items are ORed. Option B incorrectly combines both selectors in one 'from' item (AND), requiring pods to match both conditions.

Option A and C correctly use separate 'from' items (OR), allowing frontend pods (same namespace, because a bare podSelector defaults to the namespace of the policy) or all pods from the monitoring namespace. Option D is also valid with two separate ingress rules.

How to eliminate wrong answers

Option A is wrong because it places both the podSelector and namespaceSelector in the same 'from' item, which means traffic must come from a pod that is both labeled 'role: frontend' AND in a namespace labeled 'name: monitoring' — an AND condition, not the required OR. Option B is wrong because it also combines podSelector and namespaceSelector in the same 'from' item, again requiring both conditions to be met simultaneously (AND logic), which would only allow pods with 'role: frontend' in the 'monitoring' namespace. Option D is wrong because it uses two separate 'from' blocks, but the second 'from' block has a namespaceSelector without a podSelector, which would allow traffic from any pod in 'monitoring' — however, the first 'from' block with only a podSelector would allow traffic from any pod with 'role: frontend' in any namespace (including other namespaces), which is too permissive; the requirement is to allow from pods with 'role: frontend' only in the same namespace.

Practice this question →
32
MCQhard

An Ingress resource is defined as: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: test-ingress spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 tls: - hosts: - example.com secretName: tls-secret What must exist in the cluster for TLS termination to work?

A.An IngressClass annotation specifying the ingress controller
B.A ServiceAccount named tls-secret
C.A Secret named tls-secret of type kubernetes.io/tls in the same namespace
D.A ConfigMap named tls-secret with certificate data
AnswerC

The Ingress resource must reference a Secret of type kubernetes.io/tls in its spec.tls[].secretName field, and Kubernetes requires that Secret to exist in the same namespace as the Ingress. This Secret must contain the keys tls.crt and tls.key, holding the PEM-encoded certificate and private key. The ingress controller reads those exact keys to terminate HTTPS traffic, so creating this Secret in the correct namespace is the essential prerequisite for TLS to function.

Why this answer

C is correct because TLS termination requires the actual TLS certificate and key to be stored in a Kubernetes Secret of type `kubernetes.io/tls`. The Ingress controller reads this Secret to terminate HTTPS connections, decrypting traffic before forwarding it to the backend service. Without this Secret, the Ingress controller cannot present a valid certificate to clients.

Exam trap

The trap here is that candidates may think TLS termination requires an IngressClass annotation or a ConfigMap, but the CKAD exam specifically tests that a Secret of type `kubernetes.io/tls` with the correct name and namespace is mandatory for TLS to work.

How to eliminate wrong answers

Option A is wrong because an IngressClass annotation is not required for TLS termination; it is used to specify which Ingress controller should process the Ingress, but TLS termination works as long as any Ingress controller is present. Option B is wrong because a ServiceAccount is unrelated to TLS certificates; it is used for pod identity and RBAC, not for storing TLS material. Option D is wrong because a ConfigMap cannot hold sensitive certificate data; Secrets are designed for confidential data like TLS keys, and ConfigMaps are for non-sensitive configuration.

Practice this question →
33
MCQeasy

A Service of type LoadBalancer is created but the external IP remains pending. What is the most likely reason?

A.The service selector does not match any pods
B.The service port is already in use
C.The cluster does not have a load balancer controller
D.The namespace has a NetworkPolicy blocking traffic
AnswerC

Without a load balancer controller running in the cluster, there is no controller-manager component to detect the LoadBalancer service and create the actual load balancer resource in the cloud provider. Consequently, the service's status field for load balancer ingress remains unset and the external IP stays stuck at '<pending>' indefinitely. This is the standard symptom when a cluster is misconfigured or running on bare metal without a controller like MetalLB.

Why this answer

A Service of type LoadBalancer in Kubernetes requires an external load balancer controller (e.g., cloud-controller-manager for AWS, Azure, GCP, or MetalLB for on-premises) to provision and assign the external IP. If no such controller is running in the cluster, the external IP remains in 'pending' state indefinitely because Kubernetes itself does not implement load balancer logic. This is the most common reason for a stuck pending external IP.

Exam trap

A common pitfall in CKAD is assuming that a Service of type LoadBalancer will automatically get an external IP in any Kubernetes cluster. In reality, Kubernetes relies on an external load balancer controller (e.g., cloud-controller-manager or a bare-metal solution like MetalLB) to provision the IP. Without such a controller, the external IP remains pending.

How to eliminate wrong answers

Option A is wrong because a mismatched selector would cause the Service to have no endpoints, but the external IP would still be assigned by the load balancer controller once it provisions the IP; the pending state is unrelated to endpoint availability. Option B is wrong because port conflicts on the node (e.g., hostPort) would cause the Service to fail to start or report errors, not leave the external IP pending; the load balancer controller does not check node port availability before assigning the IP. Option D is wrong because NetworkPolicies restrict traffic flow at the pod level (Layer 3/4) and do not affect the provisioning of the external IP by the load balancer controller; the IP would still be assigned even if traffic is later blocked.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Services and Networking questions.

Start 20-question session