CCNA Services and Networking Questions — Page 3 of 3

151

MCQeasy

You want to expose a Deployment named 'nginx' on port 80 using a LoadBalancer service. Which YAML snippet is correct?

A.apiVersion: v1 kind: Service metadata: name: nginx-svc spec: type: NodePort ports: - port: 80 selector: app: nginx

B.apiVersion: v1 kind: Service metadata: name: nginx-svc spec: type: LoadBalancer ports: - port: 80 targetPort: 80 selector: app: nginx

C.apiVersion: v1 kind: Service metadata: name: nginx-svc spec: type: LoadBalancer ports: - port: 80 selector: app: nginx

D.apiVersion: apps/v1 kind: Service metadata: name: nginx-svc spec: type: LoadBalancer ports: - port: 80 selector: app: nginx

AnswerC

This is the correct minimal LoadBalancer Service definition. The apiVersion v1 and kind Service are correct, and setting type: LoadBalancer instructs the cluster to provision a cloud load balancer that forwards traffic to port 80. The selector app: nginx matches the deployment's pods, and since targetPort is omitted, it defaults to port (80) — a trick that keeps the manifest concise and is preferred in CKAD.

Why this answer

Option C is correct because it defines a Service of type LoadBalancer, exposing the 'nginx' Deployment on port 80. The apiVersion v1 is appropriate for a Service, and the selector matches the Deployment's labels. Option B includes an unnecessary explicit targetPort: 80, making it less preferred for the CKAD exam, which expects the most concise correct YAML.

Option A uses NodePort instead of LoadBalancer, and Option D uses an incorrect apiVersion.

Exam trap

The trap here is that candidates may confuse apiVersion apps/v1 with v1, or think that targetPort must be explicitly set. Option B is not the best answer because it includes unnecessary fields; the exam expects the most concise correct YAML.

How to eliminate wrong answers

Option A is wrong because it uses type NodePort instead of LoadBalancer, which does not provision an external load balancer and only exposes the service on a static port on each node. Option B is wrong because it explicitly sets targetPort: 80, which is redundant but not incorrect; however, the question asks for the correct snippet, and C is more concise and standard. Option D is wrong because it uses apiVersion apps/v1, which is for Deployments, not Services; Services must use apiVersion v1.

Practice this question →

152

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 allocates a static port from the default range 30000–32767 on every node's IP address, forwarding traffic to the targeted pods. ClusterIP exposes only a virtual internal address, and LoadBalancer builds on NodePort with an external cloud load balancer, so NodePort uniquely satisfies the static-port-per-node constraint.

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 →

153

MCQmedium

A user runs 'kubectl get endpoints my-service' and sees no endpoints listed. The service has a selector 'app: my-app'. Pods with that label exist and are running. What is the most likely cause?

A.The service selector does not match the pod labels

B.The pods are not assigned an IP address

C.The service name is incorrect

D.The pods are not ready (readiness probe failing)

AnswerD

Even if readiness probe fails, the endpoints would still exist if the selector matches; the pod would be removed from endpoints only if it fails readiness, but initially endpoints would have been populated. If no endpoints at all, selector mismatch is the first thing to check.

Why this answer

In Kubernetes, a Service creates Endpoints only for pods that match its selector and are ready. Because the pods are labeled app: my-app and match the selector, the missing endpoints indicate the pods are not passing their readiness probes.

Exam trap

The trap is that 'running' does not equal 'ready'. A pod must be both selected and ready to appear in Endpoints. Readiness probes determine readiness.

How to eliminate wrong answers

Option B is wrong because pods that are running and have an IP address assigned by the CNI plugin; if they were not assigned an IP, they would not reach the Running phase. Option C is wrong because the question states the user runs 'kubectl get endpoints my-service', which implies the service name is correct and the command succeeds; an incorrect service name would produce a 'not found' error, not an empty endpoints list. Option D is wrong because while a failing readiness probe can cause endpoints to be removed, the question states pods exist and are running, but does not specify they are ready; however, the most likely cause given the direct mismatch of selector and labels is the selector mismatch, not a readiness probe issue, and readiness probes affect endpoint inclusion only after the selector match is satisfied.

Practice this question →

154

MCQmedium

You have a Deployment with 3 replicas. You create a Service with 'clusterIP: None'. What is the effect on pod DNS?

A.Each pod gets its own DNS record in the form <pod-ip>.<service>.<namespace>.svc.cluster.local

B.DNS returns the IPs of all matching pods.

C.The Service name does not resolve to any IP; DNS fails.

D.The Service name resolves to a single virtual IP that load balances across pods.

AnswerB

With a headless Service (clusterIP: None) that has a selector matching the Deployment’s pods, the DNS name resolves to all matching pod IPs as separate A records. A DNS query for the Service name returns the list of endpoint IPs, which corresponds to the three running replicas. This design lets clients directly connect to individual pods for client-side load balancing or service discovery.

Why this answer

When a Service is created with `clusterIP: None`, it becomes a headless Service. For a headless Service, DNS is configured to return the IP addresses of all matching pods (the endpoints) rather than a single virtual IP. This allows client applications to discover and connect to individual pods directly, which is essential for stateful workloads like databases.

Exam trap

The trap here is that candidates confuse headless Services with regular ClusterIP Services, assuming 'None' means no DNS resolution at all, when in fact it changes the DNS behavior to return pod IPs directly.

How to eliminate wrong answers

Option A is wrong because DNS records for headless Services use the pod's hostname (derived from the pod name) and the service name, not the pod IP; the format is `<pod-hostname>.<service>.<namespace>.svc.cluster.local`. Option C is wrong because the Service name does resolve — it returns the A/AAAA records for all matching pods, not a failure. Option D is wrong because that describes a regular ClusterIP Service, which uses a single virtual IP for load balancing; a headless Service explicitly avoids this.

Practice this question →

155

Multi-Selecthard

Which THREE of the following are valid fields in a NetworkPolicy spec?

Select 3 answers

A.podSelector

B.ingress

C.policyTypes

D.namespaceSelector

E.ipBlock

AnswersA, B, C

podSelector is a required field in a NetworkPolicy's spec. It uses label selector semantics to identify the pods within the current namespace to which the policy applies. An empty podSelector (e.g., `podSelector: {}`) is valid and matches all pods in the namespace, enabling default-deny policies. Without this field, the NetworkPolicy would not know which workloads its ingress or egress rules govern, so it is mandatory.

Why this answer

`podSelector` is a required field in a NetworkPolicy spec that defines which pods the policy applies to, using standard Kubernetes label selectors. It must be present to target specific pods within a namespace, and if set to an empty selector (e.g., `{}`), it selects all pods in the namespace. The CKAD exam often tests the distinction between top-level spec fields and nested rule fields, so candidates mistakenly select `namespaceSelector` or `ipBlock` as valid spec fields when they are only valid within `ingress` or `egress` rules.

Exam trap

In the CKAD exam, candidates often confuse top-level spec fields with nested rule fields, mistakenly selecting `namespaceSelector` or `ipBlock` as valid spec fields when they are only valid within `ingress` or `egress` rules.

Practice this question →

156

MCQmedium

Which command forwards local port 8080 to port 80 of a pod named 'web-pod'?

A.kubectl port-forward service/web-service 8080:80

B.kubectl port-forward pod/web-pod 8080:80

C.kubectl port-forward deployment/web-deployment 8080:80

D.kubectl port-forward pod/web-pod 80:8080

AnswerB

This is the correct command because kubectl port-forward is given the resource type pod, the exact pod name web-pod, and the port mapping 8080:80, where the format is LOCAL_PORT:REMOTE_PORT. It opens a direct TCP tunnel from localhost:8080 on your workstation to port 80 of web-pod's IP, bypassing Services and Deployments. This ensures traffic reaches that exact pod, which is what the question specifies.

Why this answer

`kubectl port-forward` requires the resource type and name, and for a pod, the syntax is `pod/<pod-name>`. The command `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 of the pod, matching the question's requirement exactly.

Exam trap

The trap here is that candidates often confuse the port order (local:pod) or incorrectly assume that `kubectl port-forward` works with any resource type like Deployments, when in fact it only supports pods and services (and some other specific types).

How to eliminate wrong answers

Option A is wrong because it targets a Service (`service/web-service`) instead of a pod; while `kubectl port-forward` can work with services, the question specifically asks for a pod named 'web-pod', not a service. Option C is wrong because `kubectl port-forward` does not support Deployment resources directly; it only supports pods and services (and some other resource types like ReplicaSets), so targeting a Deployment will fail. Option D is wrong because it reverses the port mapping (`80:8080`), forwarding local port 80 to pod port 8080, which is the opposite of what the question requires (local 8080 to pod 80).

Practice this question →

157

MCQhard

An Ingress resource uses host-based routing. Which field in the Ingress YAML specifies the host header to match?

A.metadata.annotations['nginx.ingress.kubernetes.io/rewrite-target']

B.spec.rules[].host

C.spec.tls[].hosts

D.spec.rules[].http.paths[].host

AnswerB

The spec.rules[].host field is where you define a fully qualified domain name for host-based routing; the Ingress controller compares the incoming request's Host header to this value to select the appropriate path rules. This is part of the Ingress spec and is the only field that directly determines which hostname maps to which backend configuration.

Why this answer

In Kubernetes, host-based routing in an Ingress resource is configured using the `spec.rules[].host` field. This field specifies the fully qualified domain name (FQDN) that the Ingress controller should match against the `Host` header of incoming HTTP requests. When a request arrives with a matching `Host` header, the Ingress controller routes it to the backend service defined under that rule.

Exam trap

The trap here is that candidates confuse `spec.rules[].host` with `spec.tls[].hosts` or path-level host fields, mistakenly thinking TLS host configuration also controls routing, when in fact TLS hosts only specify certificate coverage and do not affect request routing.

How to eliminate wrong answers

Option A is wrong because `metadata.annotations['nginx.ingress.kubernetes.io/rewrite-target']` is an NGINX-specific annotation used to rewrite the request URI path, not to match the host header. Option C is wrong because `spec.tls[].hosts` defines the hostnames covered by a TLS certificate for HTTPS termination, not the host header matching for routing. Option D is wrong because `spec.rules[].http.paths[].host` is not a valid field; the `host` field is at the rule level, not within the path specification.

Practice this question →

158

MCQeasy

Which kubectl command forwards local port 8080 to port 80 of a pod named 'web-pod'?

A.kubectl port-forward pod/web-pod 80:8080

B.kubectl expose pod web-pod --port=8080 --target-port=80

C.kubectl proxy pod/web-pod 8080:80

D.kubectl port-forward pod/web-pod 8080:80

AnswerD

This is the correct syntax: kubectl port-forward pod/web-pod 8080:80 binds your local TCP port 8080 and tunnels all traffic through the Kubernetes API server to TCP port 80 on the container in pod/web-pod. You can then access the application at http://localhost:8080. The tunnel remains active until the command is terminated, making it ideal for debugging an application that is not exposed via a Service or for accessing a specific pod directly from a workstation. This is the standard, built-in mechanism for point-to-point pod port forwarding in Kubernetes.

Why this answer

`kubectl port-forward` is the command used to forward a local port to a port on a specific pod. The syntax is `kubectl port-forward pod/<pod-name> <local-port>:<remote-port>`, so `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 on the pod named 'web-pod'.

Exam trap

The trap here is that candidates often confuse the port order (local:remote vs remote:local) or mix up `port-forward` with `expose` or `proxy`, which serve different networking purposes in Kubernetes.

How to eliminate wrong answers

Option A is wrong because it reverses the port mapping: the syntax requires local port first, then remote port, so `80:8080` would forward local port 80 to pod port 8080, not the requested 8080 to 80. Option B is wrong because `kubectl expose` creates a Service (e.g., ClusterIP) to expose a pod or deployment, not a direct local port forward; it does not forward a local port to a pod. Option C is wrong because `kubectl proxy` creates a proxy server to the Kubernetes API server, not a port forward to a specific pod; it does not accept a pod name or port mapping in that format.

Practice this question →

159

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 →

160

MCQhard

An Ingress resource has the following spec. What is the effect? spec: tls: - hosts: - myapp.example.com secretName: myapp-tls rules: - host: myapp.example.com http: paths: - path: / pathType: Prefix backend: service: name: myapp port: number: 80

A.Ingress terminates TLS using the secret and routes to the service.

B.Ingress uses the secret for client authentication.

C.Ingress redirects HTTP to HTTPS automatically.

D.Ingress passes the TLS connection through to the service.

AnswerA

The Ingress controller uses the certificate and private key from the referenced secret to decrypt incoming HTTPS traffic at the edge. After TLS termination, the decrypted request is forwarded as plain HTTP to the backend service identified by the ingress routing rules. This is the conventional edge-termination model for Kubernetes Ingress.

Why this answer

The Ingress spec defines TLS termination at the ingress controller using the secret `myapp-tls` for the host `myapp.example.com`. The `tls` block configures the ingress to decrypt HTTPS traffic using the certificate and key stored in that secret, and then forward the decrypted HTTP traffic to the backend service `myapp` on port 80. This is the standard behavior for securing traffic with TLS in Kubernetes Ingress.

Exam trap

The trap here is that candidates often assume TLS in an Ingress spec implies automatic HTTP-to-HTTPS redirect or TLS passthrough, but Kubernetes Ingress only terminates TLS by default unless explicitly configured otherwise.

How to eliminate wrong answers

Option B is wrong because the `tls` block in an Ingress spec is used for server-side TLS termination, not client authentication (mutual TLS). Client authentication would require additional configuration like `nginx.ingress.kubernetes.io/auth-tls-secret` or similar annotations. Option C is wrong because the spec does not include any redirect configuration; automatic HTTP-to-HTTPS redirect is not implicit and must be explicitly enabled (e.g., via annotation `nginx.ingress.kubernetes.io/ssl-redirect: "true"`).

Option D is wrong because TLS passthrough would require the `tls` block to be absent or the ingress controller to be configured for passthrough mode (e.g., with `nginx.ingress.kubernetes.io/ssl-passthrough: "true"`), and the backend would need to handle TLS itself; here the secret is used for termination, not passthrough.

Practice this question →

161

MCQmedium

You need to create a NetworkPolicy that denies all ingress traffic to pods with label 'app: db' in namespace 'prod'. Which YAML snippet correctly implements this?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-db namespace: prod spec: podSelector: matchLabels: app: db policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 0.0.0.0/0

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: prod spec: podSelector: {} policyTypes: - Ingress ingress: - from: []

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress ingress: []

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-db namespace: prod spec: podSelector: matchLabels: app: db policyTypes: - Ingress ingress: []

AnswerD

This is the correct NetworkPolicy because it selects the intended pods via podSelector.matchLabels.app: db and restricts itself to the prod namespace with the namespace field. It declares policyTypes: [Ingress] and provides an empty ingress array ([]), which means no ingress rules are defined. With no allow rules, the policy defaults to denying all ingress traffic to the selected pods, satisfying the 'deny all ingress' requirement exactly as asked.

Why this answer

It defines a NetworkPolicy that selects pods with label 'app: db' in namespace 'prod', specifies 'policyTypes: [Ingress]', and sets 'ingress: []'. An empty ingress rule list means no ingress traffic is allowed, effectively denying all ingress to the selected pods. This is the standard Kubernetes pattern for creating a deny-all ingress policy for a specific set of pods.

Exam trap

The trap here is that candidates often confuse an empty ingress array (deny-all) with an empty from array (which also denies all but is often misapplied), or they forget to set the correct podSelector and namespace, leading to policies that either allow all traffic or apply to the wrong pods.

How to eliminate wrong answers

Option A is wrong because it uses an ipBlock rule allowing traffic from 0.0.0.0/0, which permits all ingress traffic instead of denying it. Option B is wrong because it uses an empty podSelector '{}' which selects all pods in the namespace, not just those with label 'app: db', and also uses 'ingress: [from: []]' which is invalid syntax (empty from array allows no traffic but the podSelector is incorrect). Option C is wrong because it omits the namespace field (defaults to 'default'), uses an empty podSelector selecting all pods, and defines the policy without a namespace, failing to target the 'prod' namespace and the specific 'app: db' pods.

Practice this question →

162

MCQhard

A NetworkPolicy is applied to a namespace with the following rules: ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress ``` What is the effect on pods in that namespace?

A.All inbound traffic is denied, outbound traffic is allowed

B.All traffic is allowed

C.Only traffic from specific namespaces is allowed

D.All inbound and outbound traffic is denied

AnswerA

Because the policy's podSelector matches all pods and policyTypes lists only Ingress, the lack of any ingress rules creates a default deny for all inbound traffic. The policy does not include Egress in policyTypes, so no egress rule is evaluated and outbound connections remain permitted. Thus incoming requests are blocked while pods can still initiate traffic to external endpoints.

Why this answer

This NetworkPolicy selects all pods in the namespace (podSelector: {}) and specifies only Ingress in policyTypes. By default, if any NetworkPolicy selects a pod, all traffic not explicitly allowed by a rule is denied. Since no ingress rules are defined, all inbound traffic is denied.

Outbound traffic is not restricted because Egress is not listed in policyTypes and no egress rules are defined, so it remains allowed by default.

Exam trap

The CKAD exam often tests the misconception that a NetworkPolicy with no rules allows all traffic, but in reality, any NetworkPolicy selecting a pod triggers a default-deny for the specified traffic direction (Ingress or Egress) unless rules explicitly allow it.

How to eliminate wrong answers

Option B is wrong because a NetworkPolicy with an empty podSelector applies to all pods, and with no ingress rules, it denies all inbound traffic, not allows all traffic. Option C is wrong because no ingress rules are defined to allow traffic from specific namespaces; the policy only denies all inbound traffic. Option D is wrong because the policy does not include Egress in policyTypes, so outbound traffic is not affected and remains allowed by default.

Practice this question →

163

Multi-Selecthard

Which TWO statements about Kubernetes DNS are correct?

Select 2 answers

A.The kube-dns service is responsible for DNS resolution

B.A service named 'api' in namespace 'prod' has DNS name 'api.prod.svc.cluster.local'

C.Pods with hostNetwork: true automatically get DNS entries

D.Headless services also have DNS A records for each pod

E.A pod's DNS name is always 'pod-ip.namespace.pod.cluster.local'

AnswersB, D

This is correct because Kubernetes constructs a service's fully qualified domain name using the pattern `<service-name>.<namespace>.svc.<cluster-domain>`. With the default cluster domain of `cluster.local`, a service named `api` in the `prod` namespace resolves to `api.prod.svc.cluster.local`. Other pods in the cluster can rely on this DNS name for service discovery, and the name is stable for the service's lifetime.

Why this answer

Kubernetes DNS assigns a fully qualified domain name (FQDN) to services following the pattern `<service-name>.<namespace>.svc.cluster.local`. For a service named 'api' in the 'prod' namespace, the DNS name is `api.prod.svc.cluster.local`, enabling cluster-internal service discovery via CoreDNS or kube-dns.

Exam trap

A common misconception is that all pods automatically get DNS A records, but in reality, only pods with explicit `hostname` and `subdomain` fields, and belonging to a headless service, receive such entries.

Practice this question →

164

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 →

165

MCQhard

An ingress resource is created with the following spec. Which request will be routed to the 'green' service? ```yaml spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: blue port: number: 80 - path: /api/v1 pathType: Exact backend: service: name: green port: number: 80 ```

A.http://example.com/api/v1

B.http://example.com/api/v1/

C.http://example.com/api

D.http://example.com/

AnswerA

This request URL has the path /api/v1 with no trailing slash, which exactly matches the ingress rule's pathType: Exact specification for /api/v1. In Kubernetes, an Exact path rule requires a case-sensitive, byte-for-byte match of the entire request path. Therefore, this request is unambiguously routed to the green backend service.

Why this answer

The request to http://example.com/api/v1 matches the Exact path /api/v1, which routes to the green service. In Kubernetes ingress, Exact pathType requires the request path to be identical to the specified path, and /api/v1 matches exactly.

Exam trap

The trap here is that candidates often forget that Exact pathType requires an exact match without a trailing slash, leading them to choose Option B with the trailing slash, or they confuse Prefix and Exact matching, thinking /api/v1 would match the Prefix /api instead of the Exact /api/v1.

How to eliminate wrong answers

Option B is wrong because the request path /api/v1/ includes a trailing slash, which does not match the Exact path /api/v1 (without trailing slash), so it will not be routed to the green service. Option C is wrong because /api matches the Prefix path /api, which routes to the blue service, not green. Option D is wrong because / matches no defined path, so it will not be routed to any service (default behavior is 404).

Practice this question →

166

Multi-Selectmedium

Which TWO statements about Services are true? (Choose two.)

Select 2 answers

A.A Service of type LoadBalancer automatically creates a NodePort Service.

B.A Service of type ClusterIP is accessible from outside the cluster.

C.A Service of type ExternalName requires a selector to route traffic.

D.A headless Service has clusterIP set to "0.0.0.0".

E.A Service of type NodePort exposes the Service on a static port on each Node's IP.

AnswersA, E

A Service of type LoadBalancer is an extension of NodePort: the cloud provider provisions a load balancer that targets the NodePort Service automatically created for that Service. Because NodePort exposes the Service on every node's IP and port, the external load balancer can route incoming traffic to any healthy node, which then forwards it through the ClusterIP to the selected pods. Thus, you only need to define a single LoadBalancer Service and Kubernetes creates the underlying NodePort and ClusterIP Services for you.

Why this answer

When a Service of type LoadBalancer is created, Kubernetes automatically creates a corresponding NodePort Service (and a ClusterIP Service) as part of its implementation. The cloud load balancer routes external traffic to the NodePort on each node, which then forwards to the ClusterIP. This is defined in the Kubernetes Service specification and is a core behavior of the LoadBalancer type.

Exam trap

The CKAD exam often tests the misconception that a LoadBalancer Service is a standalone type, when in fact it is built on top of NodePort and ClusterIP, and candidates may forget that ExternalName Services do not require selectors.

Practice this question →

167

MCQmedium

A Service of type NodePort is created with 'spec.ports[0].nodePort: 30080'. The cluster nodes have IPs 10.0.0.1, 10.0.0.2. Which command can be used to test connectivity to the Service from outside the cluster?

A.curl 10.0.0.1:30080

B.curl 10.0.0.1:80 --header 'Host: service.namespace.svc.cluster.local'

C.curl 10.0.0.1:80

D.curl 10.96.0.1:30080

AnswerA

This is correct because NodePort services are published on the port specified in `spec.ports[0].nodePort` (30080) on every node's IP address. Since 10.0.0.1 is a node IP, traffic sent to that address on port 30080 is intercepted by kube-proxy and forwarded to the backing pods, regardless of which node actually runs the pod.

Why this answer

A NodePort service exposes the same port (nodePort: 30080) on every cluster node's IP address. From outside the cluster, you can reach the service by targeting any node's IP and the nodePort, so `curl 10.0.0.1:30080` will connect to the service via node 10.0.0.1.

Exam trap

The trap here is that candidates often confuse the clusterIP port (80) with the nodePort (30080), or assume that the clusterIP (e.g., 10.96.0.1) is reachable from outside the cluster, when in fact it is only routable within the cluster network.

How to eliminate wrong answers

Option B is wrong because it uses port 80 (the clusterIP port, not the nodePort) and adds a Host header, which is unnecessary for NodePort access; the service is not listening on port 80 on the node's external interface. Option C is wrong because it uses port 80 on the node IP, but the NodePort service only listens on the configured nodePort (30080), not on the targetPort or clusterIP port. Option D is wrong because 10.96.0.1 is a typical clusterIP address (e.g., for the Kubernetes API server), not the service's clusterIP, and even if it were the service's clusterIP, that IP is only reachable from inside the cluster, not from outside.

Practice this question →