Courseiva

CCNA Services and Networking Questions

75 of 167 questions · Page 2/3 · Services and Networking · Answers revealed

Practice these questionsDomain overviewAll questions
76
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 →
77
Multi-Selectmedium

Which THREE statements about Ingress are correct? (Choose three.)

Select 3 answers
A.Ingress can terminate TLS connections.
B.Ingress can route traffic based on host header.
C.Ingress can route traffic based on source IP.
D.Ingress can route traffic based on URL path.
E.Ingress can route traffic based on destination port.
AnswersA, B, D

Ingress controllers can terminate TLS by decrypting HTTPS traffic at the edge, using a Kubernetes secret of type kubernetes.io/tls that holds the certificate and private key. The spec.tls field maps a hostname to that secret, and after decryption, requests are forwarded to backend services over HTTP. This offloads encryption overhead from backend pods and is a standard feature of every major ingress controller.

Why this answer

Ingress can terminate TLS connections by referencing a Secret that contains the TLS certificate and private key. When a TLS section is defined in the Ingress spec, the Ingress controller terminates the HTTPS connection at the edge and forwards plain HTTP traffic to the backend services. This is a core feature for securing ingress traffic in Kubernetes.

Exam trap

The CKAD exam often tests the distinction between Layer 7 (Ingress) and Layer 4 (Service) routing, so candidates mistakenly think Ingress can route based on source IP or destination port, which are Layer 3/4 concepts.

Practice this question →
78
MCQmedium

A Pod needs to access an external database at db.example.com:3306. Which Service type allows Pods to resolve a cluster-local name to this external address?

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

An ExternalName Service maps a Service's DNS name to an external fully-qualified domain name. When queried, CoreDNS returns a CNAME record directly to the target, such as db.example.com, so pods can reach the database through an in-cluster alias without any proxy or selector.

Why this answer

The ExternalName Service type maps a cluster-local DNS name (e.g., `my-db.default.svc.cluster.local`) to an external DNS name (`db.example.com`) using a CNAME record. This allows Pods to resolve the service name to the external database address without needing to modify application code or use an external endpoint.

Exam trap

The trap here is that candidates often confuse ExternalName with ClusterIP, thinking any Service can resolve external names, but only ExternalName provides a CNAME-based DNS alias without proxying traffic.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it exposes the Service externally via a cloud provider's load balancer, which is used for external traffic ingress, not for resolving a cluster-local name to an external address. Option C (NodePort) is wrong because it exposes the Service on a static port on each Node's IP, intended for external access, not for DNS-based resolution to an external hostname. Option D (ClusterIP) is wrong because it provides a virtual IP within the cluster for Pod-to-Pod communication, but it cannot resolve to an external DNS name; it only routes traffic to internal endpoints.

Practice this question →
79
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 →
80
MCQmedium

An Ingress resource is configured with TLS. Which field in the Ingress YAML specifies the secret containing the TLS certificate and key?

A.spec.tls[].secretName
B.metadata.annotations['tls-secret']
C.spec.tls[].secret
D.spec.secretName
AnswerA

The Ingress v1 API defines TLS termination settings in the spec.tls array, where each entry has an optional hosts list and the required-in-practice secretName field. That secretName references a Kubernetes Secret in the same namespace whose data must contain tls.crt and tls.key. The controller uses this exact field to load the certificate; the field name is case-sensitive and structurally validated.

Why this answer

In Kubernetes, TLS configuration for an Ingress is defined under the `spec.tls` array. Each entry in this array must include a `secretName` field that references a Kubernetes Secret of type `kubernetes.io/tls` containing the TLS certificate and private key. This is the only field that correctly specifies the secret name, as per the Kubernetes API specification.

Exam trap

The exact YAML key for the TLS secret in an Ingress resource is `secretName`, not `secret`. This is a common point of confusion because many Kubernetes resources use `secret` as a field name, but the Ingress `spec.tls[]` entry specifically requires `secretName`.

How to eliminate wrong answers

Option B is wrong because `metadata.annotations` is not used to specify the TLS secret; annotations are arbitrary key-value pairs for metadata, not for referencing secrets. Option C is wrong because the correct field is `secretName`, not `secret`; `spec.tls[].secret` is not a valid field in the Ingress API. Option D is wrong because `spec.secretName` does not exist; the secret name must be nested under `spec.tls[]` as part of an array entry.

Practice this question →
81
MCQhard

An administrator applies the following NetworkPolicy: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress After applying this policy, which traffic flows are affected?

A.Only inbound traffic to pods is denied
B.Only outbound traffic from pods is denied
C.Both inbound and outbound traffic for all pods in the namespace is denied
D.Traffic to and from the kube-system namespace is also denied
AnswerC

The empty `podSelector` matches all pods in the namespace, and the `policyTypes` array contains both `Ingress` and `Egress`. Since no `ingress` or `egress` rules are specified, the policy falls back to the default-deny behavior for both traffic directions. Consequently, all pod traffic in the namespace — inbound and outbound — is blocked unless another NetworkPolicy explicitly allows it.

Why this answer

The NetworkPolicy has an empty `podSelector: {}` which selects all pods in the namespace, and it specifies both `Ingress` and `Egress` in `policyTypes`. By default, if no rules are defined under `ingress` or `egress` (as in this case), Kubernetes denies all traffic of that type. Thus, both inbound and outbound traffic for all pods in the namespace is denied.

Exam trap

The trap here is that candidates may think an empty `podSelector: {}` selects no pods or that omitting `ingress`/`egress` rules means all traffic is allowed, but in Kubernetes, an empty selector selects all pods and the absence of rules denies all traffic of that type.

How to eliminate wrong answers

Option A is wrong because it ignores the `Egress` policy type; the policy explicitly denies outbound traffic as well. Option B is wrong because it ignores the `Ingress` policy type; the policy explicitly denies inbound traffic as well. Option D is wrong because NetworkPolicies are namespace-scoped and only affect pods in the namespace where the policy is applied; they do not affect the `kube-system` namespace unless a separate policy is created there.

Practice this question →
82
MCQmedium

An Ingress resource has the following spec: spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 What will the Ingress controller do for a request to http://example.com/api/v1/users?

A.Route the request to api-service on port 80.
B.Route the request to the default backend.
C.Return a 502 Bad Gateway error.
D.Return 404 Not Found because the path does not match exactly.
AnswerA

The Ingress rule defines a host and a path with pathType Prefix. Because the incoming request's path starts with that prefix, the rule's match condition is satisfied. The controller then performs the routing action specified in the rule, forwarding the request to the backend service api-service on port 80. Since the rule matches, no other default or error handling is applied.

Why this answer

The Ingress rule uses `pathType: Prefix` and a path of `/api`, which matches any request whose URL path begins with `/api`. The request to `http://example.com/api/v1/users` starts with `/api`, so the Ingress controller routes it to `api-service` on port 80. This is the standard behavior defined by the Kubernetes Ingress specification for prefix-based path matching.

Exam trap

The trap here is that candidates confuse `pathType: Prefix` with `pathType: Exact` and incorrectly think the path must match exactly, leading them to choose the 404 error option.

How to eliminate wrong answers

Option B is wrong because a default backend is only used when no rules match the request; here the rule matches, so the default backend is not invoked. Option C is wrong because a 502 Bad Gateway error indicates an upstream server failure, not a routing decision; the Ingress controller would route successfully to the service. Option D is wrong because `pathType: Prefix` does not require an exact match; it matches any path that starts with the specified prefix, so `/api/v1/users` is a valid match.

Practice this question →
83
Multi-Selecthard

Which THREE statements about NetworkPolicy are correct?

Select 3 answers
A.A single NetworkPolicy can contain both ingress and egress rules
B.A NetworkPolicy can use ipBlock in the from or to field to allow traffic to/from specific IP ranges
C.NetworkPolicy is a cluster-scoped resource
D.NetworkPolicy can only be applied to pods with a specific annotation
E.By default, if no NetworkPolicy selects a pod, all traffic to/from that pod is allowed
AnswersA, B, E

A single NetworkPolicy can indeed declare both ingress and egress rules within the same object. The optional `policyTypes` field explicitly lists whether ingress, egress, or both are enforced, and when both are listed, separate `ingress` and `egress` rule arrays can be defined. If `policyTypes` is omitted, Kubernetes defaults to applying ingress rules always and egress rules only if any egress rule is present. This lets one policy govern bidirectional traffic for selected pods, enabling tight coupling of inbound and outbound restrictions.

Why this answer

A single NetworkPolicy resource can define both ingress and egress rules within its spec. The `spec.policyTypes` field explicitly lists which rule types are applied; if both `Ingress` and `Egress` are specified, the policy governs both directions. This allows administrators to enforce bidirectional traffic controls with a single policy object.

Exam trap

The CKAD exam often tests the misconception that NetworkPolicy is cluster-scoped like a ClusterRole, but it is actually namespaced and only affects pods in the same namespace as the policy.

Practice this question →
84
Multi-Selectmedium

Which TWO of the following are valid ways to expose a service externally on a Kubernetes cluster? (Select 2)

Select 2 answers
A.NodePort
B.kubectl port-forward
C.ExternalName
D.LoadBalancer
E.ClusterIP
AnswersA, D

A NodePort service exposes the application by opening a static TCP/UDP port in the default range 30000-32767 on every Kubernetes node. Any client can reach the service by sending requests to `nodeIP:nodePort`, and traffic is automatically routed to the backend pods. It is a valid, production-grade exposure method, though it provides no advanced load balancing and leaves the node IPs publicly reachable.

Why this answer

A NodePort service exposes the service on a static port on each node's IP address, making it accessible from outside the cluster via `<NodeIP>:<NodePort>`. This is a valid method for external exposure, as it opens a port in the node's firewall and routes traffic to the service.

Exam trap

The trap here is that candidates confuse `kubectl port-forward` (a debugging tool) with a persistent service exposure method, or think ExternalName provides external access when it only creates a DNS alias within the cluster.

Practice this question →
85
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 →
86
MCQeasy

What is the DNS name for a Service named `svc` in namespace `ns`?

A.svc.cluster.local
B.svc.ns.svc.cluster.local
C.svc.svc.cluster.local
D.ns.svc.cluster.local
AnswerB

This is the correct fully qualified Service DNS name for a Service named `svc` in the `ns` namespace using the default cluster domain `cluster.local`. The format is `<service-name>.<namespace>.svc.<cluster-domain>`, and this is the exact name CoreDNS publishes for both ClusterIP and headless Services. It can be used from any pod in the cluster, though pods outside the namespace would need to use a trailing dot in some contexts or rely on search domains.

Why this answer

B is correct because Kubernetes constructs the DNS name for a Service using the format `<service>.<namespace>.svc.cluster.local`. For a Service named `svc` in namespace `ns`, this becomes `svc.ns.svc.cluster.local`. This allows Pods to resolve the Service by its fully qualified domain name (FQDN) within the cluster, leveraging CoreDNS or kube-dns.

Exam trap

The trap here is that candidates often forget the namespace is required in the FQDN and incorrectly choose `svc.cluster.local` (option A), assuming the default namespace or omitting the namespace entirely.

How to eliminate wrong answers

Option A is wrong because it omits the namespace, resulting in `svc.cluster.local`, which is not a valid FQDN for a Service in a non-default namespace. Option C is wrong because it incorrectly repeats the service name as the namespace, producing `svc.svc.cluster.local`, which would only match if the namespace were also named `svc`. Option D is wrong because it places the namespace before the service name, yielding `ns.svc.cluster.local`, which reverses the required `<service>.<namespace>` order.

Practice this question →
87
MCQmedium

A company runs a web application in a Kubernetes cluster. The application consists of a frontend service and a backend service. The frontend needs to communicate with the backend using a DNS name that does not change even if the backend pods are recreated. Which Kubernetes resource should the frontend use to reach the backend?

A.An EndpointSlice
B.A regular ClusterIP Service
C.An Ingress resource
D.A headless Service
AnswerB

A regular ClusterIP Service is the correct choice for internal service discovery because it exposes a stable virtual IP and a DNS name that load-balances across the pods in its selector. This provides a reliable, single endpoint for other applications to reach the web app, regardless of pod churn or scaling. It is the standard Kubernetes abstraction for east-west traffic between workloads.

Why this answer

A regular ClusterIP Service provides a stable virtual IP and DNS name (e.g., <service-name>.<namespace>.svc.cluster.local) that remains constant regardless of pod churn. The frontend can use this DNS name to reach the backend, and the service load-balances traffic to the current set of backend pods via its label selector. This meets the requirement of a fixed DNS name that survives pod recreation.

Exam trap

The trap here is that candidates often confuse a headless Service with a regular ClusterIP Service, thinking that because headless Services also provide DNS, they are suitable for stable communication, but they fail to realize that headless Services return a dynamic list of pod IPs rather than a fixed virtual IP, which violates the requirement for an unchanging DNS name.

How to eliminate wrong answers

Option A is wrong because an EndpointSlice is a lower-level resource that tracks the IP addresses of pods matching a Service’s selector; it does not provide a stable DNS name or virtual IP for frontend-to-backend communication. Option C is wrong because an Ingress resource handles external HTTP/HTTPS traffic routing into the cluster, not internal service-to-service DNS-based communication. Option D is wrong because a headless Service (clusterIP: None) does not provide a single stable virtual IP or a round-robin DNS name; it returns the IPs of all matching pods directly, which can change as pods are recreated, breaking the requirement for a fixed DNS name.

Practice this question →
88
Multi-Selectmedium

Which TWO items are required for Ingress to work correctly in a Kubernetes cluster?

Select 2 answers
A.At least one rule specifying either host or path
B.An Ingress controller running in the cluster
C.A TLS secret for HTTPS termination
D.A LoadBalancer service for the backend
E.A default backend service
AnswersA, B

At least one rule specifying either a host or path is essential because the Ingress resource is fundamentally a routing table; without a rule, there is no destination for incoming traffic. Each rule defines a mapping from an HTTP host and/or URL path to a backend service, and this mapping is what the controller uses to proxy requests. A bare Ingress with no rules would be inert and could not route anything.

Why this answer

For Ingress to work correctly, the cluster must have a running Ingress controller to process Ingress resources. At least one rule specifying a host or path is required to define routing logic. A TLS secret is optional for HTTPS termination, not mandatory.

Without these two components, the Ingress will not route traffic.

Exam trap

The trap is that TLS is not mandatory; only an Ingress controller and at least one rule are required. Candidates often think TLS is required or that a default backend is necessary, but it is not.

Practice this question →
89
Drag & Dropmedium

Arrange the steps to create a multi-container Pod with a shared volume.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Define Pod with containers, add shared emptyDir volume, mount in each container, apply, then test.

Practice this question →
90
MCQeasy

A developer wants to access a specific pod's port 8080 from their local machine using a temporary connection. Which command should they use?

A.kubectl exec -it pod-name -- sh
B.kubectl port-forward pod/pod-name 8080:8080
C.kubectl proxy
D.kubectl expose pod pod-name --port=8080
AnswerB

kubectl port-forward pod/pod-name 8080:8080 creates a local TCP listener on the specified host port (8080) and tunnels that traffic over the Kubernetes API server to port 8080 of the named pod. This makes the pod's application available at localhost:8080, which is exactly what the developer needs for direct access to a single pod. It is ephemeral and client-side; no Service or Ingress object is created, and the tunnel disappears when the command is terminated.

Why this answer

`kubectl port-forward` creates a temporary, direct tunnel from a local port to a port on a specific pod, allowing the developer to access the pod's port 8080 from their local machine without exposing the pod via a service. This command forwards local port 8080 to the pod's port 8080, enabling debugging or testing with tools like curl or a browser.

Exam trap

The trap here is that candidates often confuse `kubectl port-forward` with `kubectl proxy`, thinking both provide similar access, but `kubectl proxy` only proxies the API server and requires constructing URLs like `/api/v1/namespaces/default/pods/pod-name:8080/proxy/` to reach a pod, which is less direct and more error-prone.

How to eliminate wrong answers

Option A is wrong because `kubectl exec -it pod-name -- sh` opens an interactive shell inside the pod, not a network tunnel to access the pod's port from the local machine. Option C is wrong because `kubectl proxy` creates a proxy to the Kubernetes API server, not a direct tunnel to a specific pod's port, and requires additional URL manipulation to reach pods. Option D is wrong because `kubectl expose pod pod-name --port=8080` creates a Service object that exposes the pod as a network service, which is a persistent, cluster-wide resource, not a temporary connection from the local machine.

Practice this question →
91
MCQmedium

A NetworkPolicy with the following spec is applied: spec: podSelector: {} policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: frontend What does this policy do?

A.Allows all outgoing traffic from pods labeled 'role: frontend'
B.Blocks all incoming traffic to pods labeled 'role: frontend'
C.Allows incoming traffic from pods labeled 'role: frontend' to all pods
D.Has no effect because policyTypes is missing Egress
AnswerC

The policy spec uses an empty podSelector, which selects all pods in the namespace as the destination of traffic. Its ingress rule contains a from podSelector matching any pod labeled 'role: frontend', so those sources are explicitly allowed to initiate connections to every pod selected by the policy. Since no egress rules or policyTypes are set, only inbound traffic is controlled and only from that source label.

Why this answer

This NetworkPolicy selects all pods (empty podSelector `{}`) and defines an ingress rule that only allows incoming traffic from pods with the label `role: frontend`. By default, Kubernetes NetworkPolicies are additive and deny all traffic that is not explicitly allowed, so this policy permits ingress from frontend pods to all pods while blocking all other inbound traffic.

Exam trap

The trap here is that candidates often think an empty `podSelector: {}` has no effect, but in Kubernetes, it selects all pods in the namespace, and combined with the ingress rule, it creates a default-deny for all other traffic.

How to eliminate wrong answers

Option A is wrong because the policy only specifies `Ingress` in `policyTypes` and has no egress rules, so it does not affect outgoing traffic at all. Option B is wrong because the policy does not block all incoming traffic; it explicitly allows incoming traffic from pods labeled `role: frontend`, so only traffic from other sources is blocked. Option D is wrong because `policyTypes` is correctly set to `Ingress`, and the policy has an effect by allowing ingress from frontend pods; missing `Egress` does not invalidate the ingress rules.

Practice this question →
92
Multi-Selectmedium

Which TWO statements about Ingress are correct?

Select 2 answers
A.An Ingress resource without an IngressClass will not work
B.Only one Ingress resource can exist per namespace
C.Ingress can handle non-HTTP protocols like TCP
D.Ingress can route traffic based on the requested hostname
E.TLS termination can be configured in the Ingress spec
AnswersD, E

This statement is true because the Ingress spec includes a `host` field in each rule, allowing you to route requests based on the requested domain name. For example, you can direct `app.example.com` to one Service and `admin.example.com` to another, even within the same Ingress resource. This enables host-based virtual hosting, a standard feature of HTTP routing.

Why this answer

An Ingress resource can route traffic based on the requested hostname using the `spec.rules.host` field. This allows multiple hostnames (e.g., `app1.example.com` and `app2.example.com`) to be served by the same Ingress controller, with each hostname directing traffic to different backend services. This host-based routing is a core feature of the Ingress API, as defined in the Kubernetes networking specification.

Exam trap

The trap here is that candidates often confuse Ingress with a general-purpose load balancer and assume it can handle TCP/UDP traffic, but the standard Kubernetes Ingress API only supports HTTP and HTTPS (Layer 7) protocols.

Practice this question →
93
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 →
94
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 →
95
MCQhard

An Ingress resource specifies TLS termination using a secret. The secret must contain which keys?

A.username and password
B.cert.pem and key.pem
C.ca.crt and tls.crt
D.tls.crt and tls.key
AnswerD

This is the correct answer because a Kubernetes secret of type `kubernetes.io/tls` conventionally uses exactly these two data keys: `tls.crt` holds the PEM-encoded server certificate (and optionally an intermediate chain), and `tls.key` holds the PEM-encoded private key. When an Ingress resource specifies a TLS block with `secretName`, the controller loads these keys to terminate HTTPS for the configured host. The presence of both correctly named keys, along with a matched certificate/key pair, enables a valid TLS termination setup.

Why this answer

Kubernetes Ingress resources require TLS termination secrets to contain exactly two keys: `tls.crt` (the TLS certificate) and `tls.key` (the private key). The Ingress controller reads these specific key names from the Secret's `data` or `stringData` field to configure HTTPS termination, as defined by the Kubernetes API specification.

Exam trap

The trap here is that candidates confuse common file extensions (`.pem`, `.crt`, `.key`) with the exact key names required by Kubernetes (`tls.crt`, `tls.key`), leading them to pick option B or C instead of D.

How to eliminate wrong answers

Option A is wrong because `username` and `password` are generic authentication credentials, not TLS certificate components; they are used for basic auth or registry secrets, not Ingress TLS. Option B is wrong because `cert.pem` and `key.pem` are common file names but not the required key names in a Kubernetes Secret for Ingress TLS; the controller expects `tls.crt` and `tls.key` exactly. Option C is wrong because `ca.crt` is an optional CA certificate for client-side verification, not a required key for server-side TLS termination, and `tls.crt` alone is insufficient without `tls.key`.

Practice this question →
96
MCQeasy

What is the default service type in Kubernetes?

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

ClusterIP is the default service type when no `spec.type` is specified. It assigns the Service a stable virtual IP reachable only within the cluster, allowing pods to discover and route to the Service's endpoints via kube-proxy and DNS. This internal-facing default provides load balancing across pods without exposing traffic externally.

Why this answer

The default service type in Kubernetes is ClusterIP, which exposes the service on a cluster-internal IP address. This makes the service reachable only from within the cluster, enabling pod-to-pod communication without external access. If no `type` field is specified in the Service manifest, Kubernetes automatically sets `type: ClusterIP`.

Exam trap

The trap here is that candidates often assume NodePort or LoadBalancer is the default because they are more visible in external access scenarios, but Kubernetes defaults to ClusterIP for internal-only communication.

How to eliminate wrong answers

Option A is wrong because NodePort is not the default; it builds on ClusterIP by exposing the service on a static port on each node's IP, but must be explicitly set. Option B is wrong because ExternalName maps a service to a DNS name (e.g., an external database) and is not the default; it requires an explicit `type: ExternalName` and does not provide a cluster IP. Option D is wrong because LoadBalancer is an extension of NodePort that provisions an external load balancer (e.g., from a cloud provider) and is not the default; it must be explicitly configured.

Practice this question →
97
MCQhard

You apply the following NetworkPolicy: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress After applying, pods in the namespace cannot reach the kube-dns service. What is the most likely reason?

A.The policy does not have a namespaceSelector
B.The policy blocks all egress traffic, including DNS
C.The policy blocks all ingress traffic only
D.The kube-dns service is not running
AnswerB

The policy defines no egress rules (an empty `egress` list), which by NetworkPolicy semantics means all egress traffic is denied — including DNS queries sent over UDP port 53 to the kube-dns service. Even if other services are reachable within the cluster, the inability to resolve DNS names will cause most network communication to fail, making this the primary reason the pod cannot connect. Ingress is also blocked, but the DNS failure is exclusively an egress-side issue.

Why this answer

The NetworkPolicy explicitly includes `Egress` in `policyTypes` and uses an empty `podSelector: {}`, which selects all pods in the namespace. With no `egress` rules defined, the default behavior is to deny all egress traffic. DNS resolution for kube-dns typically uses UDP/TCP on port 53, and since all egress traffic is blocked, pods cannot reach the kube-dns service, causing DNS failures.

Exam trap

The trap here is that candidates often assume a NetworkPolicy with no rules allows all traffic, but in Kubernetes, an empty `podSelector: {}` combined with `policyTypes` that list a direction (Ingress/Egress) actually defaults to denying all traffic in that direction, which is the opposite of what many expect.

How to eliminate wrong answers

Option A is wrong because a `namespaceSelector` is not required for this policy; the `podSelector: {}` already selects all pods in the namespace, and the policy correctly applies to the namespace where it is created. Option C is wrong because the policy includes both `Ingress` and `Egress` in `policyTypes`, so it blocks both ingress and egress traffic, not just ingress. Option D is wrong because the question states that after applying the policy, pods cannot reach kube-dns, implying the service was running before; the issue is caused by the network policy, not the service's availability.

Practice this question →
98
Multi-Selecthard

Which THREE components are typically involved when using Ingress to expose a service?

Select 3 answers
A.Ingress resource
B.External load balancer
C.Ingress controller
D.NetworkPolicy
E.Service
AnswersA, C, E

The Ingress resource is a declarative Kubernetes API object that defines external HTTP(S) routing rules, typically matching requests by hostname and URL path to specific backend Services. It serves only as a specification; it does not perform any traffic forwarding itself. Once created, an Ingress controller watches and converts these rules into actual proxy configurations. Without this resource, there is no desired state for the controller to enforce.

Why this answer

An Ingress resource defines the routing rules for external HTTP/HTTPS traffic to services within the cluster. It specifies hostnames, paths, and the backend service to forward requests to, but it is only a configuration object. The actual traffic handling requires an Ingress controller (e.g., NGINX, Traefik) to process the Ingress resource and implement the rules, and a Service of type ClusterIP or NodePort to expose the target pods internally.

Exam trap

The CKAD exam often tests the misconception that an external load balancer is a mandatory component of Ingress, when in fact the Ingress controller itself can run as a pod within the cluster and does not require an external LB unless the controller's Service type is LoadBalancer.

Practice this question →
99
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 →
100
MCQhard

You have an Ingress resource with TLS configured. The certificate is stored in a Secret named 'my-tls'. Which field in the Ingress YAML specifies the Secret name?

A..spec.tls[0].secretName
B..spec.tls[0].secret
C..metadata.annotations['cert-manager.io/cluster-issuer']
D..spec.tlsSecretName
AnswerA

In the Ingress v1 API, TLS is defined under spec.tls as a list. Each list element is an object that includes a secretName field, which is the exact key that references an existing Kubernetes Secret in the same namespace as the Ingress. That Secret must contain the TLS certificate and private key under the standard keys tls.crt and tls.key. This is the canonical way to attach an existing certificate to an Ingress.

Why this answer

In Kubernetes Ingress resources, the TLS configuration is defined under `.spec.tls`, which is an array of TLS objects. Each object contains a `hosts` field and a `secretName` field that references the Kubernetes Secret holding the TLS certificate and private key. Option A correctly identifies `.spec.tls[0].secretName` as the field that specifies the Secret name.

Exam trap

The trap here is that candidates confuse the `secretName` field with a non-existent `secret` field, or mistakenly think the TLS Secret is specified at the top level of the Ingress spec rather than under the `tls` array.

How to eliminate wrong answers

Option B is wrong because `.spec.tls[0].secret` is not a valid field; the correct field name is `secretName`. Option C is wrong because `metadata.annotations['cert-manager.io/cluster-issuer']` is an annotation used by cert-manager to specify the ClusterIssuer for automatic certificate provisioning, not a field that directly references the Secret name. Option D is wrong because `.spec.tlsSecretName` is not a valid field in the Ingress spec; the TLS Secret name is nested under each entry in the `.spec.tls` array.

Practice this question →
101
MCQmedium

You have a Service named 'my-svc' in the 'prod' namespace. What is the fully qualified DNS name for this Service?

A.my-svc.prod.svc.cluster.local
B.my-svc.svc.cluster.local
C.prod.my-svc.svc.cluster.local
D.my-svc.prod.cluster.local
AnswerA

This is the canonical fully qualified domain name (FQDN) for a Kubernetes Service. The format is `<service-name>.<namespace>.svc.<cluster-domain>`; here the service `my-svc` is in the `prod` namespace, and `svc` is the DNS subdomain reserved for Services. It resolves to the ClusterIP of the Service and is resolvable only from within the cluster (or via the cluster's DNS). No other components come before the service name.

Why this answer

The fully qualified DNS name for a Service in Kubernetes follows the pattern `<service-name>.<namespace>.svc.cluster.local`. For 'my-svc' in the 'prod' namespace, this resolves to 'my-svc.prod.svc.cluster.local'. This is the standard DNS naming convention used by CoreDNS (or kube-dns) for Service discovery within a cluster.

Exam trap

The CKAD exam often tests the exact order of components in the DNS name, specifically that the namespace comes before 'svc' and after the service name, and that 'svc' is a required subdomain, not optional.

How to eliminate wrong answers

Option B is wrong because it omits the namespace component; the correct format requires the namespace ('prod') between the service name and 'svc'. Option C is wrong because it incorrectly places the namespace before the service name; the namespace must come after the service name, not before. Option D is wrong because it omits the 'svc' subdomain; the DNS name must include 'svc' to indicate it is a Service record, not a Pod or other resource.

Practice this question →
102
MCQmedium

A pod is unable to resolve the DNS name of a Service in the same namespace. The pod's /etc/resolv.conf shows 'nameserver 10.96.0.10'. What is the most likely cause?

A.The kube-dns Service is not running
B.The pod is using dnsPolicy: Default
C.The Service is of type ExternalName
D.The pod's /etc/hosts file is misconfigured
AnswerA

The kube-dns Service (typically implemented by CoreDNS) is the cluster-wide DNS server that responds to queries for Service or Pod names. If the Service object or its backing pods are absent or in a failed state, cluster DNS resolution completely fails, causing pods to be unable to resolve any Service name. This is the most direct and common cause of such a symptom.

Why this answer

The pod's /etc/resolv.conf shows nameserver 10.96.0.10, which is the default ClusterIP of the kube-dns Service. If the kube-dns Service is not running, the DNS resolver will fail to respond to queries, causing the pod to be unable to resolve the DNS name of any Service, including one in the same namespace. This is the most direct cause because the pod relies entirely on that nameserver for DNS resolution.

Exam trap

The trap here is that candidates often confuse dnsPolicy: Default with the default pod DNS policy (ClusterFirst), or assume that an ExternalName Service bypasses DNS entirely, when in fact all DNS queries go through the same kube-dns resolver.

How to eliminate wrong answers

Option B is wrong because dnsPolicy: Default means the pod inherits the node's DNS configuration, which would not point to 10.96.0.10; the given nameserver indicates the pod is using ClusterFirst (the default policy for pods), not Default. Option C is wrong because an ExternalName Service returns a CNAME record, not a ClusterIP, but DNS resolution would still work if kube-dns is running; the issue is the resolver not responding, not the Service type. Option D is wrong because the /etc/hosts file is used for local hostname resolution and does not affect DNS queries sent to the nameserver; misconfiguration there would not cause a failure to resolve a Service DNS name via the cluster DNS.

Practice this question →
103
Multi-Selectmedium

Which THREE of the following are valid Ingress pathTypes in Kubernetes networking.k8s.io/v1?

Select 3 answers
A.Prefix
B.Exact
C.Wildcard
D.Suffix
E.ImplementationSpecific
AnswersA, B, E

Prefix is a valid Ingress pathType that matches URL paths by whole path segments, not by raw string prefix. For example, a Prefix rule for /foo will match both /foo and /foo/bar, but it will not match /foobar because the match is evaluated on element boundaries separated by slashes. This makes Prefix the standard way to implement wildcard-style routing for a subtree of paths.

Why this answer

In Kubernetes networking.k8s.io/v1, the valid Ingress pathTypes are `Prefix`, `Exact`, and `ImplementationSpecific`. `Prefix` matches URL paths based on a prefix (e.g., `/api` matches `/api/v1`), `Exact` matches the path exactly (e.g., `/api` only matches `/api`), and `ImplementationSpecific` allows the ingress controller to define its own path matching logic. All three are defined in the v1 API.

Exam trap

Candidates often mistakenly believe that only `Prefix` and `Exact` are valid in networking.k8s.io/v1, but `ImplementationSpecific` is also a standard pathType in the stable v1 API.

Practice this question →
104
MCQeasy

Which Service type is used to expose a Service on a static port on each node in the cluster?

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

NodePort exposes the Service on a static port in the default range 30000–32767 on every node in the cluster. kube-proxy listens on this NodePort and forwards traffic to the corresponding ClusterIP, which then load-balances to the backing pods. This allows external clients to reach the Service by connecting to any node's IP address with the NodePort, making it the correct Service type for static port exposure.

Why this answer

NodePort is the correct Service type because it exposes the Service on a static port (in the range 30000-32767) on every node's IP address in the cluster. Traffic sent to any node's IP on that port is forwarded to the Service's ClusterIP and then to the selected Pods, enabling external access without a cloud load balancer.

Exam trap

The trap here is that candidates confuse NodePort with LoadBalancer, thinking LoadBalancer also exposes a static port on each node, but LoadBalancer actually creates an external LB that routes to NodePort or ClusterIP, not a static port on every node itself.

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 proxy traffic; it is used for internal DNS aliasing, not for exposing services on node ports. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and assigns a public IP, but it does not expose the Service on a static port on each node; it relies on the underlying NodePort or ClusterIP for routing.

Practice this question →
105
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 →
106
MCQmedium

What is the purpose of the `IngressClass` resource in Kubernetes?

A.To enable path-based routing.
B.To define the TLS certificate for an Ingress.
C.To specify which Ingress controller should implement the Ingress.
D.To set the default backend for an Ingress.
AnswerC

The IngressClass resource exists to name a specific ingress controller, such as nginx or traefik, in its spec.controller field, and it can also set parameters for that controller. An Ingress declares a class via spec.ingressClassName, and the referenced controller then picks up and implements the Ingress's routing rules. This decouples the Ingress manifest from vendor-specific controller details, allowing the cluster administrator to choose the implementation without editing each Ingress.

Why this answer

The `IngressClass` resource decouples the Ingress definition from the specific Ingress controller implementation. It allows you to specify which controller (e.g., NGINX, HAProxy, Traefik) should process the Ingress by referencing the `spec.controller` field, enabling multi-controller clusters and dynamic routing decisions.

Exam trap

The trap here is that candidates confuse the IngressClass with Ingress features like path routing or TLS, but the CKAD exam specifically tests that IngressClass is the mechanism to select which controller implementation handles the Ingress.

How to eliminate wrong answers

Option A is wrong because path-based routing is a feature of the Ingress resource itself (via `spec.rules.http.paths`), not the IngressClass. Option B is wrong because TLS certificates are defined in the Ingress resource's `spec.tls` field, not in the IngressClass. Option D is wrong because the default backend is set within the Ingress resource's `spec.defaultBackend`, not by the IngressClass.

Practice this question →
107
MCQmedium

A headless service is created with 'clusterIP: None'. What is the primary use case for such a service?

A.To allow direct pod-to-pod DNS resolution for StatefulSets.
B.To provide a stable IP address for the service.
C.To expose the service externally without a load balancer.
D.To enable DNS round-robin across all pods.
AnswerA

Headless services (clusterIP: None) are used with StatefulSets to provide stable network identities. Instead of a virtual IP, the service creates DNS A records for each pod's unique name (e.g., pod-0.service.namespace.svc.cluster.local) that resolve directly to pod IPs. This allows clients to reach a specific pod directly by name, which is essential for stateful applications where each replica maintains its own state and peers need to discover each other by stable identity.

Why this answer

A headless service (clusterIP: None) is primarily used with StatefulSets to enable direct pod-to-pod DNS resolution. Instead of a single virtual IP, the DNS returns the individual pod IPs (A/AAAA records) or SRV records, allowing each pod to be addressed by its stable network identity (e.g., pod-name.service-name.namespace.svc.cluster.local). This is essential for stateful applications like databases that require stable peer discovery.

Exam trap

The trap here is that candidates confuse headless services with regular ClusterIP services, assuming the primary benefit is DNS round-robin (Option D), when in fact the key differentiator is the absence of a single virtual IP to enable direct pod identity resolution for StatefulSets.

How to eliminate wrong answers

Option B is wrong because a headless service does not provide a stable IP address; it deliberately omits a cluster IP to return pod IPs directly. Option C is wrong because headless services are not used for external exposure; external access typically requires a NodePort, LoadBalancer, or Ingress. Option D is wrong because DNS round-robin is the default behavior for regular ClusterIP services (via kube-dns/CoreDNS), not a primary use case for headless services; headless services return all pod IPs, leaving load balancing to the client.

Practice this question →
108
MCQeasy

Which Service type exposes a Service externally via each Node's IP on a static port?

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

NodePort exposes a service by allocating a static port (in the default 30000-32767 range) on every node in the cluster. Clients reach the service by connecting to any node's IP address at that port, and kube-proxy forwards the traffic to the service's ClusterIP, which then load-balances to endpoint pods. Since the port is open on all nodes, this type directly satisfies the requirement for node-level external exposure.

Why this answer

A NodePort Service exposes the Service on each Node's IP address at a static port (in the range 30000-32767 by default). This allows external traffic to reach the Service by sending requests to any Node's IP and the specified NodePort, which then forwards traffic to the corresponding ClusterIP Service and ultimately to the Pods.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer also uses static Node ports, but LoadBalancer relies on an external cloud LB and does not guarantee a static port on each Node's IP.

How to eliminate wrong answers

Option B (ClusterIP) is wrong because it exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an Ingress or a proxy. Option C (LoadBalancer) is wrong because it relies on an external cloud provider's load balancer to expose the Service, not directly on each Node's IP with a static port. Option D (ExternalName) is wrong because it maps a Service to a DNS name (via CNAME records) and does not expose any port or IP; it is used for internal cluster DNS aliasing, not external access.

Practice this question →
109
MCQmedium

You create a Service with the following manifest. What is the effect? service.yaml: apiVersion: v1 kind: Service metadata: name: ext-svc spec: type: ExternalName externalName: db.example.com

A.The service is a CNAME alias for db.example.com
B.The service gets a ClusterIP and forwards to db.example.com
C.The service creates a load balancer pointing to db.example.com
D.The service selects pods with label app: ext
AnswerA

An ExternalName service is a special Kubernetes service type that, instead of provisioning a ClusterIP or endpoints, writes a CNAME record into the cluster's DNS (CoreDNS) pointing to the external FQDN db.example.com. When a pod resolves the service's DNS name (e.g., my-service.default.svc.cluster.local), the DNS server returns a canonical answer directing the client to db.example.com directly. Because it is purely a DNS-level alias, no network proxy, selector, or load balancer is involved.

Why this answer

A Service of type `ExternalName` creates a DNS CNAME record in the cluster's DNS (e.g., CoreDNS) that maps the Service name `ext-svc` to the external DNS name `db.example.com`. When a Pod resolves `ext-svc`, it receives the canonical name `db.example.com` directly, with no proxy, ClusterIP, or pod selection involved.

Exam trap

The trap here is that candidates often assume all Services must have a ClusterIP or select pods, but `ExternalName` is a special type that operates purely at the DNS level with no networking objects created.

How to eliminate wrong answers

Option B is wrong because an `ExternalName` Service does not get a ClusterIP; it returns a CNAME record instead of an A/AAAA record, so no IP-based forwarding occurs. Option C is wrong because `ExternalName` does not provision any load balancer; it is purely a DNS-level alias, unlike `LoadBalancer` type which creates an external LB. Option D is wrong because `ExternalName` Services have no selector; they are designed to point to external DNS names, not to select pods via labels.

Practice this question →
110
MCQhard

You create a headless service with 'clusterIP: None' for a StatefulSet. How does a client discover the individual pod IPs?

A.DNS returns multiple A records for the service name, each pointing to a pod IP
B.The service returns the pod's hostname from the StatefulSet
C.An Ingress controller must be configured to expose each pod
D.The service provides a virtual IP that load balances among pods
AnswerA

A headless Service (clusterIP: None) removes the cluster-wide virtual IP, and CoreDNS creates an A record for every Ready pod that matches the Service's label selector. In a StatefulSet, each pod receives a stable hostname based on its ordinal, but the Service name itself returns a collection of A records containing the individual pod IPs. Clients can then connect directly to a chosen pod without any proxy involvement.

Why this answer

A is correct because a headless service (clusterIP: None) does not provide a virtual IP or load balancing. Instead, DNS is configured to return multiple A records directly for the service name, each pointing to the IP address of a pod in the StatefulSet. This allows clients to discover and connect to individual pod IPs, which is essential for stateful applications where each pod has a unique identity.

Exam trap

The trap here is that candidates confuse headless services with regular ClusterIP services, assuming DNS returns a single virtual IP or that load balancing is still in effect, when in fact headless services expose individual pod IPs directly via DNS.

How to eliminate wrong answers

Option B is wrong because a headless service does not return the pod's hostname; DNS returns A records with pod IPs, and the pod's hostname is derived from the StatefulSet name and ordinal, not from the service. Option C is wrong because an Ingress controller is used for HTTP/HTTPS traffic routing and is not required for pod IP discovery via DNS; headless services work at the network layer without Ingress. Option D is wrong because a headless service explicitly sets clusterIP: None, which disables virtual IP and load balancing; that behavior is for regular ClusterIP services, not headless ones.

Practice this question →
111
Multi-Selecthard

Which THREE of the following are true about NetworkPolicy? (Select 3)

Select 3 answers
A.Multiple NetworkPolicies are additive
B.NetworkPolicy can select pods in other namespaces using namespaceSelector
C.NetworkPolicy can control traffic to Services
D.If no NetworkPolicy selects a pod, then that pod is allowed all traffic
E.NetworkPolicy is a cluster-scoped resource
AnswersA, B, D

NetworkPolicies are evaluated as a union: when multiple NetworkPolicy objects select the same pod, every rule from every selected policy is combined, and an allow rule in any one policy will permit that traffic even if another policy does not mention it. This means the effective policy is the sum of all allow rules, not an intersection. Traffic not explicitly allowed by any of the aggregated rules remains denied once isolation is triggered.

Why this answer

Kubernetes NetworkPolicy rules are additive: if multiple policies select the same pod, the effective network rules are the union of all rules from all policies. This means that if any policy allows ingress or egress traffic on a given port/protocol, that traffic is permitted, even if another policy does not explicitly allow it. This additive behavior is defined in the Kubernetes networking specification and is critical for correctly combining policies from different teams or layers.

Exam trap

A common misconception is that NetworkPolicy is cluster-scoped or that it can control traffic to Services directly. In reality, NetworkPolicy only applies to Pod endpoints, not to the Service virtual IP.

Practice this question →
112
Multi-Selectmedium

Which TWO of the following are valid ways to expose a Deployment named 'web' as a Service?

Select 2 answers
A.kubectl expose deployment web --port=80
B.kubectl port-forward deployment/web 8080:80
C.Apply a Service YAML with selector matching the deployment's pod labels
D.kubectl run web --image=nginx --port=80
E.kubectl create service clusterip web --tcp=80:80
AnswersA, C

kubectl expose deployment web --port=80 creates a Service of type ClusterIP by default, using the deployment's selector (pod template labels) to target the pods. It validates the deployment exists and uses the container port if --target-port not specified, defaulting to --port. This is a declarative-ish imperative command that creates a Service resource, exposing the deployment's pods to other cluster clients.

Why this answer

`kubectl expose deployment web --port=80` creates a Service that automatically selects Pods based on the labels defined in the Deployment's pod template. This command generates a ClusterIP Service that maps port 80 on the Service to the target port (defaulting to the same port) on the selected Pods, providing a stable network endpoint for the Deployment's replicas.

Exam trap

The CKAD exam often tests the distinction between creating a Service versus exposing an existing workload, so the trap here is that candidates may confuse `kubectl create service` (which requires explicit selector configuration) with `kubectl expose` (which automatically derives the selector from the resource), leading them to incorrectly select option E as a valid method.

Practice this question →
113
MCQhard

You have a Service named 'app-service' in namespace 'default'. You want a pod in namespace 'monitoring' to resolve the service DNS name. What is the correct fully qualified domain name (FQDN)?

A.app-service.default.cluster.local
B.app-service.svc.default.cluster.local
C.app-service.cluster.local.default.svc
D.app-service.default.svc.cluster.local
AnswerD

Correct answer. Kubernetes DNS uses the format <service-name>.<namespace>.svc.<cluster-domain>, and the default cluster domain is 'cluster.local'. Thus 'app-service' is the service, 'default' is the namespace, 'svc' is the fixed service record marker, and 'cluster.local' is the cluster's DNS suffix. This FQDN is exactly what CoreDNS resolves to the service's ClusterIP.

Why this answer

The standard FQDN for a Kubernetes Service follows the pattern `<service-name>.<namespace>.svc.cluster.local`. This allows a pod in any namespace (including 'monitoring') to resolve the service by appending the cluster's DNS suffix. The DNS query for `app-service.default.svc.cluster.local` will be handled by CoreDNS (or kube-dns) and return the cluster IP of the service.

Exam trap

The trap here is that candidates often forget the `.svc` subdomain or misplace it, because they assume the namespace directly follows the service name without the intermediate `.svc` component.

How to eliminate wrong answers

Option A is wrong because it omits the mandatory `.svc` subdomain, which is required in the FQDN to distinguish service DNS records from pod DNS records. Option B is wrong because it places `.svc` before the namespace, breaking the correct hierarchical order of `<service>.<namespace>.svc.cluster.local`. Option C is wrong because it reverses the order entirely, placing `.cluster.local` before `.default.svc`, which does not match the Kubernetes DNS specification.

Practice this question →
114
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 →
115
MCQhard

An Ingress resource uses the annotation 'kubernetes.io/ingress.class: nginx'. However, traffic is not being routed. The cluster has multiple ingress controllers. What is the most likely cause?

A.The ingress controller is not installed.
B.The annotation is deprecated; use spec.ingressClassName instead.
C.The service backend doesn't exist.
D.TLS certificate is invalid.
AnswerB

The `kubernetes.io/ingress.class` annotation was deprecated when the `IngressClass` API resource and `spec.ingressClassName` field were introduced in Kubernetes v1.18, and it is completely ignored starting in v1.22. To specify the ingress controller, you must set `spec.ingressClassName` to the name of an `IngressClass` object, e.g., `spec.ingressClassName: nginx`. If both the annotation and the field are present, the field takes precedence, and the annotation has no effect.

Why this answer

The annotation `kubernetes.io/ingress.class` is deprecated in Kubernetes 1.18+ and removed in 1.25+. The correct approach is to use `spec.ingressClassName` in the Ingress spec, which references an `IngressClass` resource. Since the cluster has multiple ingress controllers, the deprecated annotation may be ignored or not processed by the intended controller, causing traffic not to be routed.

Exam trap

The trap here is that candidates assume the annotation still works because it was used in older versions, but the CKAD exam tests awareness of deprecation and the newer `spec.ingressClassName` field, especially in clusters with multiple ingress controllers.

How to eliminate wrong answers

Option A is wrong because the cluster has multiple ingress controllers, so at least one is installed; the issue is that the deprecated annotation may not be recognized by the intended controller. Option C is wrong because the question states traffic is not being routed, not that the service backend is missing; a missing backend would cause a different error (e.g., 503 or 404), not a complete lack of routing. Option D is wrong because an invalid TLS certificate would cause TLS handshake failures (e.g., 525 or certificate errors), not prevent traffic routing entirely; the Ingress would still route HTTP traffic or return a certificate error.

Practice this question →
116
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 →
117
Multi-Selecthard

Which TWO are valid ways to create a Service from a deployment named 'frontend'? (Choose two.)

Select 2 answers
A.kubectl create service clusterip frontend --tcp=80:80
B.kubectl autoscale deployment frontend --min=1 --max=5
C.Write a YAML manifest with apiVersion: v1, kind: Service, metadata.name, spec.selector matching deployment labels, and run kubectl apply -f manifest.yaml
D.kubectl expose deployment frontend --port=80
E.kubectl run frontend --image=nginx --port=80 --expose
AnswersC, D

Writing a YAML manifest is the declarative and preferred approach because you explicitly specify apiVersion: v1, kind: Service, metadata.name, and spec.selector matching the labels defined in the deployment's pod template. After writing the manifest, running kubectl apply -f manifest.yaml creates or updates the Service on the cluster, and the selector ensures the Service's Endpoint controller tracks the backend pods. This method is idempotent and can be version-controlled.

Why this answer

It describes the standard method of creating a Kubernetes Service by writing a YAML manifest with the correct apiVersion (v1), kind (Service), metadata.name, and spec.selector that matches the labels of the target Pods (e.g., from the 'frontend' deployment). Running 'kubectl apply -f manifest.yaml' then creates the Service, which routes traffic to Pods with matching labels.

Exam trap

The CKAD exam often tests the distinction between creating a Service for an existing workload (via 'kubectl expose' or a YAML manifest) versus commands that create new resources ('kubectl create service', 'kubectl run --expose') or unrelated resources ('kubectl autoscale'), leading candidates to confuse 'expose' with 'create service' or 'autoscale'.

Practice this question →
118
MCQeasy

Refer to the exhibit. A user has created the Service shown. The application pods listen on port 8080. Which port should an external client use to access the application from outside the cluster?

A.8080
B.80
C.30007
D.30000
AnswerC

30007 is the correct external access port because the Service is of type NodePort and explicitly declares nodePort: 30007. This port is opened on every node in the cluster, and Kubernetes routes any traffic sent to <nodeIP>:30007 to the Service's port 80, then to targetPort 8080. It falls within the default 30000-32767 nodePort range, making it a valid externally reachable endpoint.

Why this answer

The Service is of type NodePort, which exposes the application on a static port (30007) on each node's IP address. External clients can access the application by hitting any cluster node's IP on port 30007, which forwards traffic to the Service's ClusterIP on port 80, then to the pods on port 8080.

Exam trap

The trap here is that candidates confuse the Service port (80) or targetPort (8080) with the externally accessible port, failing to recognize that only the NodePort (30007) is reachable from outside the cluster.

How to eliminate wrong answers

Option A is wrong because port 8080 is the targetPort, which is the port the pods listen on inside the cluster; external clients cannot directly reach pod IPs or ports from outside. Option B is wrong because port 80 is the Service's port, which is only reachable from within the cluster via the ClusterIP; it is not exposed externally. Option D is wrong because port 30000 is not defined in the Service spec; the NodePort is explicitly set to 30007 in the YAML, and Kubernetes does not automatically assign a different NodePort unless omitted.

Practice this question →
119
MCQhard

A pod in namespace 'app' needs to resolve the DNS name 'db-service.data.svc.cluster.local'. What is the likely namespace of the 'db-service' Service?

A.app
B.data
C.svc
D.default
AnswerB

The DNS name for a service is constructed as <service-name>.<namespace>.svc.<cluster-domain>, so for a service named 'db' in the 'data' namespace the fully qualified domain becomes db.data.svc.cluster.local. The second label, 'data', is precisely the namespace that the service resides in. Since the pod is also in the 'data' namespace, resolving 'db.data' is necessary to reach the 'db' service. Thus 'data' is the correct segment to complete the DNS name.

Why this answer

The DNS name 'db-service.data.svc.cluster.local' follows the Kubernetes DNS specification for Services, which has the format <service>.<namespace>.svc.cluster.local. The second component (after the first dot) is the namespace. Here, 'data' is the namespace of the Service, so the correct answer is B.

Exam trap

The CKAD exam often tests the misconception that the namespace in the DNS name is the Pod's own namespace, when in fact it is the namespace of the target Service, as defined by the DNS format <service>.<namespace>.svc.<cluster-domain>.

How to eliminate wrong answers

Option A is wrong because 'app' is the namespace of the Pod making the query, not the namespace of the target Service; the DNS name explicitly includes 'data' as the namespace. Option C is wrong because 'svc' is a fixed label in the DNS name indicating it is a Service record, not a namespace. Option D is wrong because 'default' is a common namespace but does not appear in the given DNS name; the namespace is explicitly 'data'.

Practice this question →
120
MCQhard

A Pod named `my-pod` in namespace `ns1` tries to resolve `svc-a.ns2.svc.cluster.local`. The DNS query fails. The Service `svc-a` exists in namespace `ns2`. What is the most likely cause?

A.The Service `svc-a` does not have any endpoints
B.The Pod cannot resolve names from other namespaces
C.The Service type is NodePort
D.The DNS add-on (e.g., CoreDNS) is not deployed or is misconfigured
AnswerD

In-cluster DNS resolution depends entirely on a working cluster DNS add-on, most commonly CoreDNS, which runs as a daemon and provides a service named kube-dns. If CoreDNS is not deployed, is crashing, or has a misconfigured Corefile (e.g., missing Kubernetes plugin or incorrect zone), no Service names can be resolved for any pod. This matches the described symptom exactly, because the failure would affect all Services, not just svc-a. Therefore this is the only option that correctly identifies a root cause that would cause DNS resolution to fail.

Why this answer

The DNS query for `svc-a.ns2.svc.cluster.local` fails despite the Service existing, which points to a cluster-wide DNS resolution issue. CoreDNS is the default DNS add-on in Kubernetes that translates service names to IP addresses; if it is not deployed or misconfigured, all DNS queries (including cross-namespace ones) will fail. The fact that the Service exists and the Pod is in a different namespace does not inherently prevent resolution—CoreDNS handles cross-namespace lookups by default.

Exam trap

The trap here is that candidates assume cross-namespace DNS queries are blocked by default, but Kubernetes DNS actually resolves FQDNs across namespaces, so the failure must be due to a cluster-wide DNS issue like CoreDNS being unavailable.

How to eliminate wrong answers

Option A is wrong because the existence of endpoints is irrelevant to DNS resolution; DNS resolves the Service's ClusterIP regardless of whether endpoints exist, and a query would succeed even if no pods are behind the Service. Option B is wrong because Kubernetes DNS by default allows Pods to resolve Services in any namespace using the fully qualified domain name (FQDN) `svc-a.ns2.svc.cluster.local`; there is no namespace restriction on DNS queries. Option C is wrong because the Service type (NodePort, ClusterIP, etc.) does not affect DNS resolution; DNS always returns the ClusterIP for any Service type, and NodePort simply exposes the Service on a node port.

Practice this question →
121
Multi-Selectmedium

Which TWO statements about Kubernetes Services are correct?

Select 2 answers
A.A ClusterIP service is accessible from outside the cluster.
B.A Service provides a stable IP address and DNS name for a set of pods.
C.A Service can load balance traffic across multiple clusters.
D.A NodePort service exposes the service on a static port on each node's IP.
E.A headless service assigns a ClusterIP to the service.
AnswersB, D

Kubernetes Services act as an abstraction layer that provides a stable virtual IP (ClusterIP) and a DNS name (e.g., my-service.my-namespace.svc.cluster.local) that remains unchanged even as pods are created, destroyed, or scaled. This decouples client access from the ephemeral pod IPs, enabling reliable service discovery and load balancing. The DNS name resolves to the ClusterIP, and kube-proxy forwards traffic to the backing pods.

Why this answer

A Kubernetes Service provides a stable virtual IP address and a DNS name (via CoreDNS) that remains constant even as the underlying pods are created, destroyed, or scaled. This abstraction decouples clients from the ephemeral nature of pod IPs, ensuring reliable service discovery within the cluster.

Exam trap

The trap here is that candidates often confuse 'accessible from outside' with 'accessible from within the cluster' for ClusterIP, or they mistakenly think a headless service still gets a ClusterIP, when in fact it explicitly does not.

Practice this question →
122
MCQeasy

What is the correct command to forward a local port to a pod for debugging?

A.kubectl expose pod my-pod --port=8080
B.kubectl attach pod/my-pod
C.kubectl port-forward pod/my-pod 8080:80
D.kubectl proxy pod/my-pod 8080:80
AnswerC

kubectl port-forward pod/my-pod 8080:80 is the correct way to forward a local port to a pod. The syntax requires a resource type and name (`pod/my-pod`), followed by a pair of ports where the first is the local port (8080) and the second is the target port on the pod (80). The command establishes a bidirectional TCP tunnel between your local machine and the pod, allowing you to access services that are not exposed externally, such as a database or a debug endpoint, as if they were running locally.

Why this answer

`kubectl port-forward` creates a tunnel from a local port (8080) to a target port (80) on a pod, enabling direct network access for debugging without exposing the pod externally. This command is specifically designed for forwarding traffic to pods, services, or deployments in Kubernetes.

Exam trap

The trap here is that candidates confuse `kubectl port-forward` with `kubectl expose` or `kubectl proxy`, mistakenly thinking those commands also provide local port access, when in fact only `port-forward` creates a direct local-to-pod tunnel for debugging.

How to eliminate wrong answers

Option A is wrong because `kubectl expose` creates a Service object to expose a pod or deployment to the cluster network, not forward a local port; it does not provide local port forwarding. Option B is wrong because `kubectl attach` attaches to a running container's stdin/stdout/stderr for interactive debugging, not for network port forwarding. Option D is wrong because `kubectl proxy` starts a proxy server to the Kubernetes API server, not to a specific pod, and does not accept a pod name or port mapping in its syntax.

Practice this question →
123
MCQmedium

What is the primary purpose of a headless Service (clusterIP: None) in Kubernetes?

A.To prevent external access to the Service.
B.To provide a stable IP address for the Service.
C.To allow DNS resolution to return all pod IPs for a StatefulSet.
D.To enable load balancing across pods.
AnswerC

A headless Service (clusterIP: None) removes the virtual ClusterIP, causing the DNS name to resolve to a set of A records containing the IP addresses of all ready pods. For a StatefulSet, this yields per-pod DNS names (e.g., pod-0.service.namespace.svc.cluster.local), enabling clients to discover and connect to each stable pod identity directly. This is the primary purpose: DNS-based pod discovery rather than a single stable virtual IP.

Why this answer

Headless Services are used with StatefulSets to provide stable network identities for pods, allowing direct pod-to-pod communication without a load-balanced IP.

Practice this question →
124
MCQmedium

Which of the following is true about Istio as a service mesh?

A.It replaces kube-proxy for service routing
B.It injects a sidecar proxy into each pod
C.It only works with HTTP traffic
D.It requires all services to be of type LoadBalancer
AnswerB

This is correct: Istio's core mechanism is injecting an Envoy proxy sidecar into each application pod, typically via an admission webhook that mutates the Pod spec at creation time. This sidecar intercepts all inbound and outbound traffic using iptables rules, enabling L7 routing, mutual TLS, traffic policies, and telemetry without modifying the application code. Automatic sidecar injection is the default in modern Istio installations, and manual injection via istioctl is also supported for fine-grained control.

Why this answer

Istio is a service mesh that deploys an Envoy sidecar proxy alongside each application pod. This sidecar intercepts all inbound and outbound traffic, enabling advanced traffic management, observability, and security features without modifying application code. The sidecar injection is typically done automatically via a mutating webhook admission controller.

Exam trap

The trap here is that candidates confuse Istio's sidecar proxy with kube-proxy, assuming it replaces the default service routing mechanism, when in fact they operate at different layers and can coexist.

How to eliminate wrong answers

Option A is wrong because Istio does not replace kube-proxy; kube-proxy handles cluster-internal service routing at the node level using iptables or IPVS, while Istio's sidecar proxies manage traffic at the pod level, often working alongside kube-proxy. Option C is wrong because Istio supports multiple protocols including HTTP, gRPC, TCP, and WebSockets, with protocol-specific features like retries and circuit breaking for HTTP/gRPC, and basic routing for TCP. Option D is wrong because Istio works with any Kubernetes Service type (ClusterIP, NodePort, LoadBalancer, etc.) and does not require LoadBalancer services; ingress traffic is typically handled via an Istio Ingress Gateway, which itself is a LoadBalancer or NodePort service.

Practice this question →
125
MCQmedium

A developer needs to expose a deployment named 'web-app' running in the 'default' namespace on port 8080 internally within the cluster. Which kubectl command creates a ClusterIP service that selects pods with label 'app: web'?

A.kubectl expose deployment web-app --port=8080 --target-port=8080 --selector=app=web
B.kubectl expose deployment web-app --port=8080 --target-port=8080 --type=ClusterIP
C.kubectl run web-app --image=nginx --port=8080 --expose
D.kubectl create service clusterip web-app --tcp=8080:8080 --selector=app=web
AnswerA

This command correctly creates a Service from the existing Deployment named web-app. The --selector=app=web flag ensures the Service's label selector matches the pods that belong to the Deployment, so traffic is routed only to those pod replicas. Port 8080 is set as the Service port (the port clients connect to) and --target-port=8080 forwards traffic to the same port on the selected pods, which is appropriate if the container listens on 8080. Because kubectl expose defaults to ClusterIP, this yields an internal stable IP for intra-cluster communication.

Why this answer

`kubectl expose deployment web-app --port=8080 --target-port=8080 --selector=app=web` creates a ClusterIP service by default (no `--type` flag defaults to ClusterIP), and the `--selector` flag explicitly sets the label selector to `app=web`, ensuring the service routes traffic to pods with that label. The `--port` flag defines the service port, and `--target-port` defines the container port (8080), matching the requirement for internal cluster exposure.

Exam trap

The trap here is that candidates assume `kubectl expose` automatically uses the deployment's labels as the service selector, but the `--selector` flag is required when the target pod label differs from the deployment's selector, and `kubectl create service clusterip` lacks a `--selector` flag entirely, leading to a service with no endpoints.

How to eliminate wrong answers

Option B is wrong because it omits the `--selector=app=web` flag, so the service will inherit the selector from the deployment's pod template labels (which may not be `app: web`), failing to meet the explicit requirement. Option C is wrong because `kubectl run --expose` creates a deployment and a service in one step, but it uses the image `nginx` (not the existing `web-app` deployment) and does not allow specifying a custom selector; the service selector defaults to `run=web-app`, not `app=web`. Option D is wrong because `kubectl create service clusterip` does not accept a `--selector` flag; it creates a service without a selector, requiring manual editing to add one, and the `--tcp=8080:8080` syntax maps the service port to the target port but leaves the service headless (no selector), so it will not route to pods.

Practice this question →
126
MCQmedium

An administrator wants to allow ingress traffic to pods with label 'app: database' only from pods with label 'app: api' in the same namespace. Which NetworkPolicy rule is correct?

A.podSelector: { matchLabels: { app: database } } ingress: - from: - ipBlock: { cidr: 10.0.0.0/8 }
B.podSelector: { matchLabels: { app: api } } ingress: - from: - podSelector: { matchLabels: { app: database } }
C.podSelector: { matchLabels: { app: database } } ingress: - from: - podSelector: { matchLabels: { app: api } }
D.podSelector: { matchLabels: { app: database } } ingress: - from: - namespaceSelector: { matchLabels: { name: default } }
AnswerC

This is precisely what the administrator needs: the top-level podSelector targets the database pods, and the ingress rule's podSelector allows only traffic originating from pods with the app:api label. Since both selectors are in the same namespace and the from rule specifies a pod selector, the policy permits only api pods to reach the database, while all other sources remain denied by default (assuming a default-deny policy or as the only ingress rule on those pods). Thus, it matches the requirement exactly.

Why this answer

It defines a NetworkPolicy that selects pods with label 'app: database' as the target (podSelector) and allows ingress traffic only from pods with label 'app: api' (ingress.from.podSelector). This matches the requirement exactly: only pods with 'app: api' can send traffic to pods with 'app: database' within the same namespace, as NetworkPolicy podSelector rules are namespace-scoped by default.

Exam trap

The trap here is that candidates often confuse which podSelector applies to the target (the pods being protected) versus the source (the pods allowed to send traffic), leading them to reverse the labels as in Option B.

How to eliminate wrong answers

Option A is wrong because it uses an ipBlock rule (10.0.0.0/8) which allows traffic from any pod in that IP range, not specifically from pods with label 'app: api'; it also incorrectly selects the target pods as 'app: api' instead of 'app: database'. Option B is wrong because it selects pods with label 'app: api' as the target (podSelector) and then allows ingress from pods with label 'app: database', which is the reverse of the requirement — it would allow database pods to send traffic to api pods, not the other way around. Option D is wrong because it uses a namespaceSelector with label 'name: default', which allows ingress from pods in the 'default' namespace regardless of pod labels, not specifically from pods with label 'app: api' in the same namespace.

Practice this question →
127
MCQmedium

An admin applies the following NetworkPolicy: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress What effect does this policy have?

A.Allows all traffic because no rules are specified.
B.Denies all ingress and egress traffic to all pods in the namespace.
C.Only denies egress traffic; ingress is allowed.
D.Only denies ingress traffic; egress is allowed.
AnswerB

This is the correct default-deny behavior. The policy selects all pods with an empty podSelector and declares both Ingress and Egress in policyTypes. Since the rules array provides no allow entries for either direction, the NetworkPolicy applies a base deny rule that blocks every ingress and egress packet to and from the namespace's pods, effectively isolating them.

Why this answer

The NetworkPolicy with an empty `podSelector: {}` selects all pods in the namespace, and specifying `policyTypes: [Ingress, Egress]` with no rules under `ingress` or `egress` means no traffic is explicitly allowed. By default, Kubernetes NetworkPolicies are whitelist-based: if a policy selects a pod, any traffic not explicitly permitted is denied. Thus, this policy denies all ingress and egress traffic to all pods in the namespace.

Exam trap

The trap here is that candidates often think an empty rules list means 'allow all' (like a security group default), but Kubernetes NetworkPolicy uses a whitelist model where no rules means deny all traffic for the specified policy types.

How to eliminate wrong answers

Option A is wrong because it assumes that an empty rules list allows all traffic, but in Kubernetes NetworkPolicy, the absence of rules means no traffic is permitted (default deny), not allow-all. Option C is wrong because it claims only egress is denied, but the policy explicitly includes both `Ingress` and `Egress` in `policyTypes`, and with no rules, both directions are denied. Option D is wrong because it claims only ingress is denied, but the same logic applies: both ingress and egress are denied due to the policy types and empty rules.

Practice this question →
128
Multi-Selectmedium

Which TWO statements about NetworkPolicy are correct? (Choose two.)

Select 2 answers
A.If no NetworkPolicy selects a pod, then that pod is isolated and traffic is denied
B.NetworkPolicy is only applicable to Services
C.NetworkPolicy is a cluster-scoped resource
D.NetworkPolicy uses labels to select pods within a namespace
E.NetworkPolicy can specify both ingress and egress rules
AnswersD, E

The podSelector field in a NetworkPolicy is a label selector, consistent with how other Kubernetes resources select groups of objects. By setting matchLabels or matchExpressions, you can target specific pods (e.g., app: db) or all pods if the selector is empty, giving you flexible, IP-independent grouping. This is the only way to specify which pods a policy governs, so every policy must leverage labels.

Why this answer

NetworkPolicy uses label selectors in its `spec.podSelector` field to identify which pods within a namespace the policy applies to. This allows fine-grained control over traffic to and from specific sets of pods based on their labels, without needing to reference pod names or IPs.

Exam trap

The CKAD exam often tests the misconception that NetworkPolicy is cluster-scoped or that it applies to Services, and the trap here is confusing the default 'allow all' behavior with the 'deny all' behavior when no policy is present.

Practice this question →
129
MCQhard

An Ingress resource has the following annotation: 'kubernetes.io/ingress.class: nginx'. What is the purpose of this annotation?

A.It sets a default backend for the Ingress
B.It enables session affinity (sticky sessions)
C.It enables TLS for the Ingress
D.It specifies the Ingress controller to use (e.g., nginx)
AnswerD

This annotation specifies which Ingress controller should implement the Ingress resource. For instance, kubernetes.io/ingress.class: nginx tells the ingress-nginx controller to honor this resource, especially when multiple controllers run in the same cluster. In newer Kubernetes versions, this role has been formalized by the spec.ingressClassName field backed by IngressClass objects, but the annotation remains a widely used legacy equivalent.

Why this answer

The annotation `kubernetes.io/ingress.class: nginx` explicitly tells Kubernetes which Ingress controller should process this Ingress resource. In Kubernetes, multiple Ingress controllers (e.g., nginx, haproxy, traefik) can run in the same cluster; this annotation selects the `nginx` controller, ensuring that only that controller reads and implements the routing rules defined in the Ingress.

Exam trap

A common pitfall in CKAD is confusing the annotation that selects the Ingress controller (kubernetes.io/ingress.class) with controller-specific annotations that configure features like TLS or sticky sessions. This question tests that distinction.

How to eliminate wrong answers

Option A is wrong because setting a default backend is done via the `spec.defaultBackend` field in the Ingress spec, not via the `kubernetes.io/ingress.class` annotation. Option B is wrong because session affinity (sticky sessions) is configured through Ingress-specific annotations like `nginx.ingress.kubernetes.io/affinity` for the nginx controller, not through the ingress class annotation. Option C is wrong because enabling TLS for an Ingress is done by specifying a `tls` section in the Ingress spec with secret references, not by the ingress class annotation.

Practice this question →
130
MCQmedium

An Ingress is configured for host-based routing with two hosts: 'app1.example.com' and 'app2.example.com'. A request to 'app1.example.com' should go to service 'svc1'. Which field in the Ingress spec specifies the host?

A.spec.rules.http.paths.host
B.spec.rules.http.host
C.spec.tls.hosts
D.spec.rules.host
AnswerD

spec.rules.host is the correct field for host-based routing. Each rule in spec.rules can define an optional host, and the Ingress controller uses the Host header of incoming requests to match against these values. A rule without a host applies to all incoming HTTP(S) traffic. This field sits at the rule level, alongside the http field that contains the path-to-backend mappings.

Why this answer

In Kubernetes Ingress, host-based routing is configured by specifying the `host` field directly under `spec.rules`. Each rule can define a `host` (e.g., `app1.example.com`) and the corresponding backend service. Option D correctly identifies `spec.rules.host` as the field that specifies the host for routing traffic to the appropriate service.

Exam trap

The trap here is that candidates confuse `spec.rules.host` with `spec.tls.hosts` or incorrectly assume the host is nested under `http.paths`, leading them to pick options that are syntactically plausible but invalid in the Ingress spec.

How to eliminate wrong answers

Option A is wrong because `spec.rules.http.paths.host` is not a valid field; the `host` field is not nested under `paths` or `http`. Option B is wrong because `spec.rules.http.host` does not exist; the `host` field is a sibling of `http`, not a child. Option C is wrong because `spec.tls.hosts` is used to specify TLS certificate hostnames, not for routing traffic to services; it defines which hosts the TLS configuration applies to, not the routing rule.

Practice this question →
131
MCQmedium

A developer runs 'kubectl run nginx --image=nginx --port=80' and then creates a Service with the following YAML: apiVersion: v1 kind: Service metadata: name: nginx-svc spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 However, the Service has no endpoints. What is the most likely cause?

A.The Service selector 'app: nginx' does not match the pod's label 'run: nginx'
B.The Service and pod are in different namespaces
C.The Service must have a selector defined in order to have endpoints
D.The pod is not listening on port 80
AnswerA

The pod created by `kubectl run nginx --image=nginx --port=80` is automatically labeled with `run: nginx`, not `app: nginx`. A Service selects backend pods by evaluating its `spec.selector` against the pod's labels; here the Service's selector `app: nginx` matches no pod, so the Service has no endpoints and will not route traffic to the pod. To fix this, either change the Service selector to `run: nginx` or relabel the pod with `app: nginx`, ensuring the selector matches the pod's existing labels.

Why this answer

The `kubectl run nginx --image=nginx --port=80` command creates a pod with a default label `run: nginx`, not `app: nginx`. The Service's selector `app: nginx` therefore does not match any pod's labels, so the Service's endpoint controller finds no pods to add to the endpoints list. Without matching labels, the Service cannot route traffic to any pod, resulting in zero endpoints.

Exam trap

The trap here is that candidates assume `kubectl run` creates a pod with an `app` label or that the `--port` flag affects the pod's labels, when in fact it only sets the container port and the default label is `run: <name>`.

How to eliminate wrong answers

Option B is wrong because the Service and pod are both created in the default namespace (no `--namespace` flag was used), so they are in the same namespace. Option C is wrong because the Service does have a selector defined (`app: nginx`); the issue is that the selector does not match the pod's labels, not that it is missing. Option D is wrong because the pod is running the nginx image, which listens on port 80 by default, and the `--port=80` flag does not change the container's listening port; the lack of endpoints is due to label mismatch, not a port mismatch.

Practice this question →
132
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 →
133
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 →
134
MCQmedium

You need to debug a Service that is not routing traffic to its endpoints. Which command shows the current endpoints of a Service?

A.kubectl describe service my-service
B.kubectl get svc my-service -o wide
C.kubectl get pods -l app=my-app
D.kubectl get endpoints my-service
AnswerD

kubectl get endpoints my-service is the correct debugging step because it queries the Endpoints object associated with the Service, which lists the actual IP:port pairs of healthy, ready pods that kube-proxy will forward traffic to. If this listing is empty, you immediately know the Service has no backends and can then investigate the selector match or readiness of matching pods.

Why this answer

`kubectl get endpoints my-service` directly retrieves the Endpoints object associated with the Service, which lists the IP addresses and ports of the Pods that are currently receiving traffic. This is the most precise way to verify whether the Service has any active endpoints, as the Endpoints object is updated by the kube-controller-manager based on Pod readiness and label selectors.

Exam trap

The trap here is that candidates often assume `kubectl describe service` or `kubectl get svc -o wide` shows the full endpoint list, but these commands only provide a summary or count, not the actual IP:port pairs, leading to incomplete debugging.

How to eliminate wrong answers

Option A is wrong because `kubectl describe service my-service` shows the Service's configuration and events, but it only displays a summary of endpoints (e.g., 'Endpoints: <none>') without listing individual IPs and ports in a structured format, making it less direct for debugging endpoint availability. Option B is wrong because `kubectl get svc my-service -o wide` adds the cluster IP and external IP to the output but does not include the actual endpoint IPs; it only shows the number of endpoints in the 'ENDPOINTS' column if the Service type supports it, but not the full list. Option C is wrong because `kubectl get pods -l app=my-app` lists Pods matching a label selector, but it does not verify whether those Pods are actually registered as endpoints for the Service; a Pod might be running but not ready, or the Service selector might differ from the label used.

Practice this question →
135
MCQmedium

You need to access a database pod 'db-pod' on port 5432 from your local machine. Which command forwards local port 15432 to the pod's port 5432?

A.kubectl proxy --port=15432 db-pod:5432
B.kubectl port-forward pod/db-pod 15432:5432
C.kubectl expose pod db-pod --port=15432 --target-port=5432
D.kubectl port-forward db-pod 5432:15432
AnswerB

Correct. `kubectl port-forward pod/db-pod 15432:5432` creates a direct TCP tunnel from your local machine's port 15432 to the db-pod's port 5432. This is the standard way to access a specific pod's port when you need a one-off connection, without exposing a Service. The syntax requires the resource type (pod/) followed by the pod name, and the mapping is local-port:remote-port.

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/db-pod 15432:5432` forwards local port 15432 to the pod's port 5432, allowing you to access the database as if it were running locally.

Exam trap

The trap here is confusing the order of port mapping in `kubectl port-forward` — candidates often swap the local and pod ports, thinking the first port is the pod's port, when in fact the syntax is `local-port:pod-port`.

How to eliminate wrong answers

Option A is wrong because `kubectl proxy` creates a proxy server to the Kubernetes API server, not a direct port-forward to a pod; it does not accept a pod name and port pair in that format. Option C is wrong because `kubectl expose` creates a Service object to expose a pod or deployment within the cluster, not a local port-forward to your machine. Option D is wrong because the port mapping order is reversed: `kubectl port-forward db-pod 5432:15432` would forward local port 5432 to the pod's port 15432, which is the opposite of what the question asks.

Practice this question →
136
MCQmedium

You have a headless Service for a StatefulSet. What is the DNS resolution behavior for the StatefulSet pods?

A.DNS is disabled for headless Services.
B.The Service name resolves to the IP of the first pod only.
C.All pods share a single cluster IP via the Service.
D.Each pod gets a DNS A record pointing to its individual IP.
AnswerD

With a StatefulSet bound to a headless Service, Kubernetes publishes a stable DNS A record for each pod in the format pod-name.service-name.namespace.svc.cluster.local, pointing to that pod's specific IP address. This works because the StatefulSet gives each pod a stable hostname (e.g., mydb-0, mydb-1) and the headless Service's selector causes the DNS controller to create an A record for each ready pod. These records persist even if the pod is rescheduled, because the pod name (and hence its DNS entry) stays the same, providing consistent network identity for the stateful workload.

Why this answer

For a headless Service (clusterIP: None) associated with a StatefulSet, DNS resolution returns individual A records for each pod, mapping the pod's hostname (e.g., pod-name.service-name.namespace.svc.cluster.local) to its unique pod IP. This is because headless Services disable load-balanced cluster IPs and instead rely on DNS to provide direct pod-to-pod connectivity, which is essential for StatefulSet workloads like databases that require stable network identities.

Exam trap

The trap here is that candidates often confuse headless Services with regular Services, assuming they still provide a single virtual IP for load balancing, or mistakenly think DNS is disabled, when in fact headless Services rely entirely on DNS for direct pod resolution.

How to eliminate wrong answers

Option A is wrong because DNS is not disabled for headless Services; in fact, DNS is the primary mechanism for pod discovery in headless Services, returning A records for each pod. Option B is wrong because the Service name does not resolve to a single pod IP; it resolves to multiple A records (one per pod) or, in some implementations, to the IPs of all ready pods. Option C is wrong because headless Services explicitly set clusterIP to None, meaning no single cluster IP is assigned; each pod is directly addressable via its own IP.

Practice this question →
137
Multi-Selectmedium

Which TWO of the following are valid ways to expose a Service externally in a Kubernetes cluster?

Select 2 answers
A.Service type ClusterIP
B.Service type ExternalName
C.Service type LoadBalancer
D.Service type NodePort
E.Ingress resource with ClusterIP Service
AnswersC, D

Service type LoadBalancer is a valid way to expose a Service because the cloud provider automatically provisions an external load balancer (e.g., ALB, ELB, or a similar L4 LB) that forwards traffic to the Service's underlying node ports. This gives the Service a stable public IP or hostname, making it directly reachable from the internet. It is the most common approach for external exposure in cloud environments.

Why this answer

Service type LoadBalancer (C) exposes the Service externally by provisioning a cloud load balancer (e.g., AWS ELB, GCP L7) that routes external traffic to the Service's ClusterIP. Service type NodePort (D) exposes the Service on a static port (30000-32767) on every node's IP, allowing external access via <NodeIP>:<NodePort>. Both are valid methods for external exposure in Kubernetes.

Exam trap

The trap here is that candidates often think Ingress alone can expose a Service externally, but Ingress is only a routing layer that requires an underlying Service of type NodePort or LoadBalancer to actually receive external traffic.

Practice this question →
138
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 →
139
MCQmedium

A pod in namespace 'default' cannot resolve the service name 'db' in namespace 'data'. Which DNS name should the pod use to reach the service?

A.db.default.svc.cluster.local
B.data.db.svc.cluster.local
C.db.data.svc.cluster.local
D.db.svc.data.cluster.local
AnswerC

This FQDN correctly follows the Kubernetes DNS schema for cross-namespace Service discovery: `<service-name>.<namespace>.svc.cluster.local`. Here `db` is the Service name and `data` is the namespace, so a pod in the `default` namespace can resolve this name to the Service's ClusterIP. Using the full FQDN is required when the Service is in a different namespace than the pod, as a short name would only work within the same namespace.

Why this answer

Kubernetes DNS resolves a service in another namespace using the format <service>.<namespace>.svc.cluster.local. Since the service is named 'db' in namespace 'data', the fully qualified domain name (FQDN) is db.data.svc.cluster.local. This allows cross-namespace service discovery without needing to modify the pod's DNS configuration.

Exam trap

The trap here is that candidates often confuse the order of service and namespace in the DNS name, incorrectly placing the namespace before the service (as in option B) or misplacing 'svc' (as in option D), instead of remembering the correct pattern <service>.<namespace>.svc.cluster.local.

How to eliminate wrong answers

Option A is wrong because db.default.svc.cluster.local would resolve a service named 'db' in the 'default' namespace, not in the 'data' namespace. Option B is wrong because data.db.svc.cluster.local reverses the order of service and namespace; the correct format is <service>.<namespace>.svc.cluster.local, not <namespace>.<service>.svc.cluster.local. Option D is wrong because db.svc.data.cluster.local places 'svc' before the namespace, which is invalid; the DNS hierarchy is <service>.<namespace>.svc.<cluster-domain>, so 'svc' must come after the namespace.

Practice this question →
140
MCQmedium

You apply the following Ingress manifest: ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: ingressClassName: nginx rules: - host: app.example.com http: paths: - pathType: Prefix path: / backend: service: name: app-svc port: number: 80 ``` What is missing to enable TLS termination for this Ingress?

A.Create a ConfigMap with the TLS certificate
B.Set `service.beta.kubernetes.io/load-balancer-source-ranges` annotation on the Service
C.Change the Ingress API version to extensions/v1beta1
D.Add `tls` section under spec with hosts and secretName
AnswerD

To expose a service over HTTPS, the Ingress manifest must include a tls section directly under spec that lists the hosts to be covered and the secretName referencing a TLS secret. The secret must exist in the same namespace as the Ingress and contain the certificate and private key in the expected format. This tls block instructs the Ingress controller to terminate TLS by decrypting incoming HTTPS traffic for the specified hosts and forwarding plain HTTP to the backend service. Without this section, even if you have a valid certificate in a Secret, the Ingress will only serve plain HTTP.

Why this answer

D is correct because TLS termination in Kubernetes Ingress requires a `tls` section under `spec` that specifies the `hosts` and a `secretName` referencing a Kubernetes Secret containing the TLS certificate and private key. Without this section, the Ingress will only serve HTTP traffic, even if an ingress controller like nginx is used.

Exam trap

The trap here is that candidates may think TLS termination is automatically enabled by the ingress controller or that a ConfigMap can hold certificates, but Kubernetes explicitly requires a `tls` section and a Secret of type `kubernetes.io/tls` for this purpose.

How to eliminate wrong answers

Option A is wrong because TLS certificates are stored in a Kubernetes Secret, not a ConfigMap; ConfigMaps are for non-sensitive configuration data. Option B is wrong because the annotation `service.beta.kubernetes.io/load-balancer-source-ranges` restricts client IPs for a LoadBalancer Service, not for TLS termination on an Ingress. Option C is wrong because `extensions/v1beta1` is deprecated and removed in newer Kubernetes versions; the correct API version for Ingress is `networking.k8s.io/v1`, and changing the version does not enable TLS.

Practice this question →
141
MCQeasy

Which of the following is true about headless services?

A.It performs round-robin load balancing across pods
B.It has no cluster IP; DNS returns the IPs of the pods
C.It provides a single DNS record for the service
D.It must not have a selector
AnswerB

In a headless service, you explicitly set clusterIP: None, which removes the stable cluster IP from the Service object. The DNS name then resolves not to a VIP but to the actual IP addresses of all backing pods selected by the service. This is the defining behavior of headless services: DNS returns multiple A records, one per pod endpoint, enabling direct pod-to-pod communication.

Why this answer

A headless service is created by setting `clusterIP: None` in the Service spec. Because it has no Cluster IP, kube-proxy does not create any load-balancing rules for it. Instead, the DNS lookup for the service name returns the IP addresses of all ready pods backing the service, allowing direct pod-to-pod communication without a proxy.

Exam trap

The trap here is that candidates often assume all services must have a Cluster IP and perform load balancing, but headless services explicitly disable that to provide direct pod IP resolution for stateful workloads.

How to eliminate wrong answers

Option A is wrong because headless services do not perform any load balancing; they bypass kube-proxy entirely and rely on DNS to return multiple A/AAAA records, leaving load balancing to the client or DNS resolver. Option C is wrong because a headless service returns multiple DNS A records (one per pod IP) rather than a single record; a regular ClusterIP service returns a single DNS record pointing to the Cluster IP. Option D is wrong because a headless service can have a selector; if it has a selector, DNS returns the pod IPs; if it has no selector, DNS returns the IPs of the endpoints defined manually via an Endpoints or EndpointSlice object.

Practice this question →
142
MCQeasy

Which of the following commands creates a LoadBalancer Service named `web-svc` for a Deployment named `web` on port 80?

A.kubectl create service web-svc --port=80 --type=LoadBalancer
B.kubectl expose deployment web --name=web-svc --port=80 --type=LoadBalancer
C.kubectl create deployment web --expose --port=80 --type=LoadBalancer
D.kubectl expose pod web --port=80 --type=LoadBalancer
AnswerB

This is the correct command because `kubectl expose deployment web` reads the Deployment's pod template labels and automatically creates a Service whose selector matches those labels, ensuring the Service routes traffic to all pods managed by the Deployment. The `--type=LoadBalancer` flag requests an external load balancer from the cloud provider, `--name=web-svc` assigns a stable DNS name, and `--port=80` sets the Service's forward port. This is the standard imperative way to create a LoadBalancer Service that fronts a Deployment.

Why this answer

`kubectl expose deployment` creates a Service from an existing Deployment, and the `--name` flag sets the Service name to `web-svc`. The `--port=80` and `--type=LoadBalancer` flags configure the Service to listen on port 80 and expose it externally via a cloud load balancer, which is the standard way to create a LoadBalancer Service for a Deployment.

Exam trap

The CKAD exam often tests the distinction between `kubectl expose` (which creates a Service from an existing resource) and `kubectl create service` (which creates a standalone Service without a selector), leading candidates to pick Option A because they think 'create service' is the correct verb for making a Service.

How to eliminate wrong answers

Option A is wrong because `kubectl create service web-svc --port=80 --type=LoadBalancer` creates a Service without linking it to a Deployment; it lacks a selector to target the `web` Deployment's pods, so the Service would have no endpoints. Option C is wrong because `kubectl create deployment web --expose --port=80 --type=LoadBalancer` is invalid syntax; `--expose` creates a ClusterIP Service by default, and `--type=LoadBalancer` is not a valid flag for `kubectl create deployment`. Option D is wrong because `kubectl expose pod web --port=80 --type=LoadBalancer` creates a Service for a single pod named `web`, not for the `web` Deployment, and the Service would target that specific pod rather than the Deployment's replica set, which is not the intended behavior for a Deployment-backed Service.

Practice this question →
143
MCQhard

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

A.The Service port is already in use
B.The Service selector does not match any Pods
C.The cluster does not have a cloud provider configured
D.The Pods are not listening on the container port
AnswerC

A pending external IP on a LoadBalancer Service almost always indicates that no cloud provider integration is active in the cluster. The component responsible for creating and managing the cloud load balancer is the cloud-controller-manager (or an in-tree cloud provider in older versions); if it is not running or the cluster is on bare metal, the Service will never transition out of the '<pending>' state. This is a common scenario in minikube, kind, or on-premises deployments, where you need a solution like MetalLB to provide LB functionality.

Why this answer

A LoadBalancer Service in Kubernetes relies on an external cloud provider (e.g., AWS, GCP, Azure) to provision a real load balancer and assign its external IP. If no cloud provider is configured (e.g., in a bare-metal or Minikube cluster), the external IP will remain <pending> indefinitely because there is no controller to allocate the IP.

Exam trap

The trap here is that candidates often confuse a LoadBalancer's external IP assignment with Pod readiness or port availability, but the core requirement is a functioning cloud provider integration to allocate the external IP.

How to eliminate wrong answers

Option A is wrong because a port conflict would cause the Service creation to fail or the NodePort assignment to error, not leave the external IP as <pending>. Option B is wrong because mismatched selectors would result in no endpoints for the Service, but the external IP would still be assigned by the cloud provider if one were configured. Option D is wrong because Pods not listening on the container port would cause connection failures, but the LoadBalancer external IP assignment is independent of Pod readiness.

Practice this question →
144
MCQmedium

You have a Deployment named 'web-app' with 3 replicas. You want to expose the pods on port 80 internally within the cluster using a ClusterIP service. Which kubectl command should you use?

A.kubectl expose deployment web-app --port=80 --target-port=8080
B.kubectl create service clusterip web-app --tcp=80:8080
C.kubectl create service nodeport web-app --tcp=80:8080
D.kubectl expose pod web-app --port=80 --target-port=8080
AnswerA

kubectl expose deployment web-app --port=80 --target-port=8080 creates a ClusterIP service automatically using the Deployment's pod selector, so traffic on port 80 is forwarded to port 8080 on all three replicas. It is the correct approach because the service tracks the Deployment's labels, giving it a stable cluster-internal IP and load-balancing across healthy pods, and it remains correct across scale events and rolling updates.

Why this answer

`kubectl expose deployment web-app --port=80 --target-port=8080` creates a ClusterIP Service that maps port 80 on the Service to port 8080 on the Pods, allowing internal cluster traffic to reach the application. The `--port` flag defines the Service's listening port, while `--target-port` specifies the container port the traffic is forwarded to, which is essential when the container listens on a different port than the Service exposes.

Exam trap

The trap here is that candidates often confuse `kubectl expose` with `kubectl create service`, not realizing that `kubectl create service` does not automatically inherit the selector from an existing workload, leading to a Service that has no endpoints and fails to route traffic.

How to eliminate wrong answers

Option B is wrong because `kubectl create service clusterip web-app --tcp=80:8080` creates a Service with an arbitrary name 'web-app' but does not link it to the existing Deployment's selector labels, so it will not route traffic to the Pods managed by the Deployment. Option C is wrong because `kubectl create service nodeport web-app --tcp=80:8080` creates a NodePort Service, which exposes the Service on a static port on each Node's IP, not a ClusterIP-only Service as required by the question. Option D is wrong because `kubectl expose pod web-app --port=80 --target-port=8080` attempts to expose a single Pod named 'web-app', but 'web-app' is a Deployment, not a Pod, so this command will fail or create a Service targeting a non-existent resource.

Practice this question →
145
MCQeasy

Which command creates a Service named 'my-svc' that exposes a deployment named 'my-deploy' on port 80?

A.kubectl create service my-svc --port=80 --target-port=80
B.kubectl run my-svc --expose --port=80 --image=my-image
C.kubectl create svc clusterip my-svc --tcp=80:80
D.kubectl expose deployment my-deploy --name=my-svc --port=80
AnswerD

This is the correct command because it creates a Service from an existing deployment. `kubectl expose` reads the deployment's label selector and applies it to the Service, ensuring the Service forwards traffic to the pods managed by `my-deploy`. The `--name` flag customizes the Service name while `--port=80` defines the exposed port, with `targetPort` defaulting to the pod's container port.

Why this answer

The `kubectl expose` command is specifically designed to create a Service from an existing resource like a Deployment. By specifying `deployment my-deploy`, `--name=my-svc`, and `--port=80`, it generates a ClusterIP Service that routes traffic to the pods selected by the deployment's labels on port 80.

Exam trap

The trap here is that candidates often confuse `kubectl create service` (which requires a service type and does not link to a deployment) with `kubectl expose` (which is the correct imperative command to create a Service from an existing resource), leading them to pick Option A or C without realizing the missing selector linkage.

How to eliminate wrong answers

Option A is wrong because `kubectl create service` requires a service type (e.g., `clusterip`, `nodeport`) and does not accept a deployment reference; it creates an orphaned Service without proper selector labels matching the deployment. Option B is wrong because `kubectl run` with `--expose` creates a Pod (not a Deployment) and a Service, but the Service name defaults to the run name, and the `--name` flag is not valid here; it also requires `--image` which is irrelevant to exposing an existing deployment. Option C is wrong because `kubectl create svc clusterip` creates a Service with the specified name as the first argument (e.g., `my-svc`), but the `--tcp=80:80` flag sets the port mapping, and the command does not link to any existing deployment; the Service will lack correct selectors unless manually added.

Practice this question →
146
Multi-Selectmedium

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

Select 2 answers
A.Services can only route traffic based on named ports.
B.A Service provides a stable endpoint for a set of pods.
C.A Service uses label selectors to identify the target pods.
D.Services can only route traffic to pods in the same namespace.
E.Every Service must have a cluster IP assigned.
AnswersB, C

A Service provides a stable virtual IP address and a corresponding DNS name that remain constant even as the underlying Pods are scaled, rescheduled, or replaced. Because Pod IPs are ephemeral by nature, clients can rely on the Service address as the durable network endpoint for a logical application, and traffic is load-balanced across the current set of Pods. This stable endpoint is the primary reason Services are used for inter-Pod communication.

Why this answer

A Kubernetes Service provides a stable virtual IP and DNS name that remains constant even as the underlying pods are created, destroyed, or rescheduled. This decouples clients from the ephemeral nature of pod IPs, ensuring reliable connectivity to the pod group.

Exam trap

The trap here is that candidates often assume Services require a cluster IP or can only use named ports, but the CKAD exam tests knowledge of headless Services and the flexibility of port definitions.

Practice this question →
147
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 →
148
MCQeasy

Which of the following Ingress controllers is commonly used in Kubernetes?

A.IIS
B.Apache
C.NGINX
D.Tomcat
AnswerC

NGINX Ingress Controller is the de facto standard for Kubernetes Ingress due to its robust reverse proxy and load balancing capabilities built on the battle-tested NGINX engine. It runs as a pod inside the cluster and continuously watches the Kubernetes API for Ingress resources, translating them into NGINX configuration with minimal latency. It supports advanced features like SSL/TLS termination, path-based routing, canary releases, and fine-grained annotations, making it the most widely adopted controller across on-prem and cloud deployments.

Why this answer

NGINX is the most widely adopted Ingress controller in Kubernetes, providing a reverse proxy that routes external HTTP/HTTPS traffic to services based on Ingress resource rules. It is officially maintained by the Kubernetes community and supports advanced features like SSL termination, load balancing, and path-based routing, making it the default choice for many production clusters.

Exam trap

The CKAD exam often tests the distinction between general-purpose web servers (like Apache, Tomcat, IIS) and purpose-built Kubernetes Ingress controllers (like NGINX, Traefik, HAProxy), leading candidates to confuse a web server's ability to serve content with its ability to dynamically route traffic based on Kubernetes Ingress resources.

How to eliminate wrong answers

Option A is wrong because IIS (Internet Information Services) is a Windows-based web server from Microsoft, not a Kubernetes Ingress controller, and it lacks native integration with Kubernetes Ingress resources. Option B is wrong because Apache HTTP Server is a general-purpose web server, not designed as a Kubernetes Ingress controller; it does not natively watch Kubernetes API for Ingress rule changes. Option D is wrong because Tomcat is a Java servlet container and web server, not an Ingress controller; it cannot process Kubernetes Ingress objects or provide the required reverse proxy functionality for cluster ingress.

Practice this question →
149
MCQhard

A NetworkPolicy with the following spec is applied to a namespace. What is the effect? spec: podSelector: {} policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 10.0.0.0/8 except: - 10.0.1.0/24 egress: - to: - ipBlock: cidr: 0.0.0.0/0

A.Deny all ingress and egress traffic
B.Allow all ingress and egress traffic
C.Deny all ingress traffic except from 10.0.0.0/8 excluding 10.0.1.0/24; allow all egress
D.Allow ingress from 10.0.1.0/24 only
AnswerC

This is accurate: the ingress rule uses an ipBlock with cidr 10.0.0.0/8 and except 10.0.1.0/24, which permits traffic from any address in the /8 range except that specific /24, and denies everything else by default isolation. Since no egress rule is defined and policyTypes only includes Ingress, egress traffic remains unrestricted, matching the 'allow all egress' clause.

Why this answer

The NetworkPolicy selects all pods in the namespace (empty podSelector matches all pods) and explicitly defines both Ingress and Egress policy types. The ingress rule allows traffic only from the 10.0.0.0/8 range, except 10.0.1.0/24, effectively denying all other ingress. The egress rule allows all outbound traffic to 0.0.0.0/0, so egress is unrestricted.

Exam trap

The trap here is that candidates often forget that an empty podSelector selects all pods, and that listing a policyType without a matching rule defaults to deny, but a rule with 0.0.0.0/0 for egress explicitly allows all outbound traffic.

How to eliminate wrong answers

Option A is wrong because the policy does not deny all egress; it explicitly allows egress to 0.0.0.0/0. Option B is wrong because the ingress rule is restrictive, not permissive; it only allows traffic from a specific IP range with an exception, so not all ingress is allowed. Option D is wrong because the ingress rule denies traffic from 10.0.1.0/24 (the except block) and allows traffic from the rest of 10.0.0.0/8, not the other way around.

Practice this question →
150
MCQeasy

You need to forward a local port to port 8080 on a pod named 'my-pod' in the 'default' namespace. Which kubectl command should you use?

A.kubectl port-forward pod/my-pod 8080:80
B.kubectl port-forward pod/my-pod 8080:8080
C.kubectl forward pod/my-pod 8080:8080
D.kubectl port-forward my-pod 8080
AnswerB

This command is correct because it explicitly names a pod resource using the 'pod/' prefix and maps local port 8080 to the pod's port 8080, exactly as required. The syntax 'kubectl port-forward pod/my-pod 8080:8080' creates a tunnel from localhost:8080 to port 8080 on the specified pod, allowing direct access to the application running there. It is the only option that both uses the correct verb and targets the pod with the proper port pairing.

Why this answer

The `kubectl port-forward` command requires the resource type (pod/) and the correct port mapping syntax. The question specifies forwarding a local port to port 8080 on the pod, so the local port is 8080 and the pod port is 8080, making `8080:8080` the correct mapping. The full command `kubectl port-forward pod/my-pod 8080:8080` establishes a tunnel from localhost:8080 to the pod's port 8080.

Exam trap

The trap here is that candidates often forget to include the resource type prefix (`pod/`) or confuse the port mapping order, leading them to choose options like A or D, which either map to the wrong port or omit the required resource type.

How to eliminate wrong answers

Option A is wrong because it maps local port 8080 to pod port 80, but the question requires forwarding to port 8080 on the pod, not port 80. Option C is wrong because `kubectl forward` is not a valid kubectl subcommand; the correct subcommand is `port-forward`. Option D is wrong because it omits the required resource type prefix `pod/`; without it, kubectl cannot determine the resource type and will fail with an error.

Practice this question →
← PreviousPage 2 of 3 · 167 questions totalNext →

Ready to test yourself?

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

Start 20-question session