Knowledge + Practice

CCNA Cka Services Networking Questions

75 of 131 questions · Page 1/2 · Cka Services Networking topic · Answers revealed

Practice these questions Exam hub All questions

1

MCQeasy

You need to create a Service that exposes port 80 on each node's IP at a static port (30080). Which Service type should you use?

A.NodePort

B.LoadBalancer

C.ClusterIP

D.ExternalName

AnswerA

NodePort allocates a static port from the default range (30000–32767) on every node's IP, satisfying the requirement for port 30080. kube-proxy programs iptables or IPVS rules forwarding that node port to the Service's cluster IP, then to backing pods.

Why this answer

A NodePort Service exposes the application on a static port (30080) across every node's IP address in the cluster. This is the only Service type that allows you to specify a fixed port on the node's IP, making it the correct choice for this requirement.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking a load balancer is required for external access, but NodePort directly satisfies the requirement of exposing a static port on each node's IP without any cloud dependency.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it relies on an external cloud provider to provision a load balancer and does not directly expose a static port on each node's IP; it typically creates a NodePort underneath but adds an external IP. Option C (ClusterIP) is wrong because it only exposes the Service on a cluster-internal IP, not on the node's IP or a static port accessible from outside the cluster. Option D (ExternalName) is wrong because it maps a Service to an external DNS name via CNAME records and does not expose any port on the nodes.

Practice this question →

2

MCQmedium

You create a ClusterIP service named 'my-svc' in the 'default' namespace. A pod in the same namespace tries to reach the service using the DNS name 'my-svc'. Which fully qualified domain name (FQDN) should the pod use to resolve the service?

A.my-svc.default.svc.cluster

B.my-svc.default.svc.cluster.local

C.my-svc.default.cluster.local

D.my-svc.svc.cluster.local

AnswerB

This is the canonical fully qualified domain name for a ClusterIP Service in the default namespace. Kubernetes DNS constructs it as <service-name>.<namespace>.svc.cluster.local, where 'svc' identifies the service record type and cluster.local is the cluster domain. When you create a Service named my-svc in the default namespace, this exact FQDN resolves to the Service's ClusterIP address, enabling stable in-cluster service discovery.

Why this answer

The standard FQDN for a Kubernetes service in the default namespace is `<service-name>.<namespace>.svc.cluster.local`. This is the DNS record created by CoreDNS (or kube-dns) for ClusterIP services, allowing pods to resolve the service by its fully qualified domain name. The pod can also use the shorter form `my-svc` because the DNS search path includes the service's namespace and the `svc.cluster.local` suffix, but the FQDN ensures unambiguous resolution.

Exam trap

The trap here is that candidates often forget the `svc` subdomain in the FQDN or omit the namespace, leading them to choose options like `my-svc.svc.cluster.local` (missing namespace) or `my-svc.default.cluster.local` (missing `svc`), while the correct format is `<service>.<namespace>.svc.cluster.local`.

How to eliminate wrong answers

Option A is wrong because it uses `cluster` instead of `cluster.local`; Kubernetes DNS domain is `cluster.local` by default, not `cluster`. Option C is wrong because it omits `svc` from the FQDN; the correct hierarchy is `<service>.<namespace>.svc.cluster.local`, not `<service>.<namespace>.cluster.local`. Option D is wrong because it omits the namespace `default`; the FQDN must include the namespace to uniquely identify the service, as services are namespaced resources.

Practice this question →

3

Multi-Selectmedium

Which two of the following are valid methods for service discovery in Kubernetes?

Select 2 answers

A.Ingress controller

B.Consul agent running on each node

C.kubectl proxy

D.Environment variables injected into pods

E.DNS resolution via CoreDNS

AnswersD, E

When a pod starts, the kubelet injects environment variables for every Service that already exists in the pod's namespace, such as MY_SERVICE_SERVICE_HOST and MY_SERVICE_SERVICE_PORT, using the service's cluster IP and port values. Because these variables are set only at container creation time, they become stale if services are created or removed later, and they are namespace-scoped. This is a valid built-in discovery method but less dynamic than DNS.

Why this answer

Option D is correct because Kubernetes automatically injects environment variables (e.g., <SVCNAME>_SERVICE_HOST and <SVCNAME>_SERVICE_PORT) into containers for each active Service, allowing pods to discover service endpoints without an external mechanism. Option E is correct because CoreDNS runs as the cluster DNS add-on and resolves Service names (e.g., my-svc.my-namespace.svc.cluster.local) to ClusterIPs, which is the standard in-cluster service discovery method. Option A is incorrect because an Ingress controller only routes external HTTP/HTTPS traffic to Services; it is not a service discovery mechanism.

Option B is incorrect because Consul is a third-party tool, not a built-in Kubernetes service discovery method, and running a Consul agent per node is an external integration rather than a native Kubernetes mechanism. Option C is incorrect because kubectl proxy only creates a local proxy to the Kubernetes API server for accessing the API, not for discovering Services.

Exam trap

The trap here is that candidates may confuse external traffic management tools (Ingress) or third-party service meshes (Consul) with Kubernetes' native service discovery mechanisms, or mistake kubectl proxy (a debugging tool) for an in-cluster discovery method.

Practice this question →

4

MCQhard

A NetworkPolicy named 'default-deny-ingress' is applied to all pods in a namespace. The policy has no rules. An administrator then creates a new NetworkPolicy that allows ingress traffic to pods with label 'app: web' from any source using a podSelector with '{}'. Will traffic be allowed to pods labeled 'app: web'?

A.No, because the new policy's empty podSelector selects all pods but does not specify a source

B.Yes, because the default-deny policy is ignored when a new policy exists

C.No, because the default-deny policy takes precedence

D.Yes, because the new policy allows traffic to pods with label 'app: web'

AnswerD

Kubernetes NetworkPolicies are additive, meaning that if any policy explicitly allows a connection, that connection is permitted. Even with a default-deny ingress policy in place, a new NetworkPolicy that specifically targets pods with the label `app: web` and defines an `ingress` rule will create an exception. This new policy's allow rule will override the general deny for traffic destined for those specific pods.

Why this answer

A NetworkPolicy with a podSelector of '{}' selects all pods in the namespace, and the 'from' section with an empty podSelector (or no 'from' selector at all) allows traffic from any source. When multiple NetworkPolicies are applied, they are additive: if any policy allows the traffic, it is allowed, overriding a default-deny policy that has no rules. Thus, the new policy explicitly permits ingress to pods with label 'app: web', so traffic to those pods is allowed.

Exam trap

The trap here is that candidates often think a default-deny policy is absolute and cannot be overridden, or they misunderstand that an empty podSelector in the 'from' field means 'from all sources', leading them to incorrectly assume the new policy is incomplete.

How to eliminate wrong answers

Option A is wrong because the new policy's empty podSelector selects all pods, and the 'from' section with an empty podSelector (or no 'from' selector) means 'from any source' — it does specify a source implicitly as all sources. Option B is wrong because the default-deny policy is not ignored; rather, NetworkPolicies are evaluated together, and if any policy allows the traffic, it is permitted — the default-deny is overridden by the allow rule. Option C is wrong because the default-deny policy does not take precedence; in Kubernetes, NetworkPolicy rules are additive, and an explicit allow rule overrides a default-deny rule for the matching traffic.

Practice this question →

5

Multi-Selecteasy

Which TWO of the following are valid kube-proxy modes?

Select 2 answers

A.eBPF

B.userspace

C.ipvs

D.iptables

E.kernelnet

AnswersC, D

Correct. ipvs is a supported mode.

Why this answer

Options C and D are correct because kube-proxy officially supports ipvs and iptables as its two main production-ready proxy modes: ipvs mode uses the Linux IPVS (IP Virtual Server) load balancer in the kernel for better scalability and performance with large numbers of services, while iptables mode programs netfilter rules to implement Service load balancing and is the long-standing default on most clusters. Both are documented, selectable via the --proxy-mode flag (e.g., --proxy-mode=ipvs or --proxy-mode=iptables), and are the modes Kubernetes validates and maintains. Option A (eBPF) is not a kube-proxy mode; eBPF-based service handling is provided by alternative CNI/dataplane implementations such as Cilium, not by kube-proxy itself.

Option B (userspace) was a legacy kube-proxy mode but is deprecated and removed in modern Kubernetes, so it is not a valid current answer. Option E (kernelnet) is not a real kube-proxy mode at all.

Exam trap

Candidates often mistake 'userspace' as still being a valid mode, but it was officially removed in Kubernetes v1.26. Additionally, while eBPF is a popular technology for Kubernetes networking (e.g., Cilium), it is not an official built-in kube-proxy mode.

Practice this question →

6

Multi-Selectmedium

Which THREE of the following are valid methods for service discovery in Kubernetes?

Select 3 answers

A.kubectl port-forward

B.Environment variables (e.g., SERVICE_NAME_SERVICE_HOST)

C.Ingress rules

D.DNS lookups using CoreDNS

E.Kubernetes API queries via kubectl or API calls

AnswersB, D, E

Kubernetes injects environment variables for each active Service into pod containers, exposing values such as SERVICE_NAME_SERVICE_HOST. This lets applications discover service endpoints without querying DNS or the API, satisfying the stem's valid service discovery methods.

Why this answer

Environment variables (B) are a valid service-discovery mechanism because kubelet injects variables such as SERVICE_NAME_SERVICE_HOST and SERVICE_NAME_SERVICE_PORT for each Service into Pods at creation time, letting containers locate dependencies without an external registry. DNS lookups using CoreDNS (D) are the canonical discovery method: CoreDNS serves records like <service>.<namespace>.svc.cluster.local and SRV records for named ports, resolving Service ClusterIPs and headless endpoints. Kubernetes API queries (E) are valid because clients can list/watch Service and Endpoints/EndpointSlice objects via kubectl or direct API calls to discover backends dynamically. kubectl port-forward (A) merely tunnels a local port to a Pod or Service for debugging and does not provide in-cluster discovery, while Ingress rules (C) only expose HTTP/HTTPS routes from outside the cluster and are not a discovery mechanism for workloads.

Exam trap

The trap here is that candidates confuse `kubectl port-forward` (a manual, ephemeral tunnel) with a built-in discovery mechanism, or mistake Ingress (external routing) for internal service-to-service communication.

Practice this question →

7

MCQmedium

A pod 'my-pod' in the 'default' namespace cannot resolve the service 'db-service' in the 'production' namespace. Which DNS name should be used to reach the service from 'my-pod'?

A.db-service

B.db-service.production.svc.cluster.local

C.db-service.production.pod.cluster.local

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

AnswerB

This is the fully qualified domain name (FQDN) for a Service in the production namespace, following the required Kubernetes DNS pattern: <service>.<namespace>.svc.<cluster-domain>. Since it is an absolute name with the 'svc' subdomain, it resolves to the ClusterIP of db-service regardless of the pod's namespace. The default cluster domain is 'cluster.local', so this name is valid and reachable from any namespace.

Why this answer

Kubernetes DNS resolves services across namespaces using the fully qualified domain name (FQDN) format `<service>.<namespace>.svc.cluster.local`. Since 'my-pod' is in the 'default' namespace and 'db-service' is in the 'production' namespace, the short name 'db-service' will not resolve; the FQDN must include the namespace and the cluster domain suffix to reach the service.

Exam trap

The trap here is that candidates assume the short service name works across namespaces or confuse the order of namespace and service in the FQDN, leading them to pick Option A or D, while Option C exploits the common misconception that pods use the same DNS suffix as services.

How to eliminate wrong answers

Option A is wrong because 'db-service' only resolves within the same namespace; it does not include the namespace or cluster domain, so it fails for cross-namespace resolution. Option C is wrong because the DNS suffix for services is '.svc.cluster.local', not '.pod.cluster.local' (which is used for pod hostnames). Option D is wrong because the correct FQDN format is '<service>.<namespace>.svc.cluster.local', not '<namespace>.<service>.svc.cluster.local' — the namespace comes after the service name, not before.

Practice this question →

8

MCQmedium

You create a Deployment with 3 replicas and a ClusterIP Service. You notice that some pods are not receiving traffic. What is the most likely cause?

A.The pods are in CrashLoopBackOff

B.The Deployment has a revision history limit set too low

C.The Service's selector does not match the pod labels

D.The Service type is NodePort instead of ClusterIP

AnswerC

Kubernetes Services use label selectors to dynamically identify and group target pods. If the labels defined under the Service's spec.selector do not exactly match the labels on the Deployment's pod template, the Endpoints controller will fail to discover the pods, resulting in an empty Endpoints object and a complete failure to route traffic.

Why this answer

The most likely cause is that the Service's selector does not match the pod labels. A ClusterIP Service uses label selectors to identify which pods should receive traffic; if the selector does not match the labels defined on the pods, the Service's endpoints controller will not populate the endpoints object, and traffic will not be forwarded to any pod. This is a common misconfiguration that results in some or all pods not receiving traffic, even though the pods themselves are healthy.

Exam trap

The trap here is that candidates often assume the issue is with pod health (CrashLoopBackOff) or Service type, but the CKA exam specifically tests the understanding that a Service routes traffic based on label selectors, and a mismatch is the most common cause of pods not receiving traffic when they are otherwise running.

How to eliminate wrong answers

Option A is wrong because pods in CrashLoopBackOff would not be in a Running state and would not be ready to receive traffic, but the question states that some pods are not receiving traffic, implying others are; a mismatch in selectors affects all pods equally, not just some. Option B is wrong because the Deployment's revision history limit controls how many old ReplicaSets are retained for rollback, not traffic routing to pods. Option D is wrong because changing the Service type to NodePort would expose the Service on each node's port but would not fix a selector mismatch; the core issue of traffic not reaching pods due to mismatched labels would persist regardless of the Service type.

Practice this question →

9

MCQeasy

Which Service type exposes a Service on each Node's IP at a static port in the range 30000-32767?

A.NodePort

B.ExternalName

C.ClusterIP

D.LoadBalancer

AnswerA

NodePort exposes the Service on each Node's IP at a static port, which is allocated from a default range of 30000-32767. Kubernetes automatically routes traffic incoming to this port on any node directly to the underlying backend Pods, regardless of which node those Pods are actually running on. This makes the service accessible from outside the cluster using the combination of any Node's IP and the allocated port.

Why this answer

A NodePort Service exposes the Service on each Node's IP at a static port in the range 30000-32767. When you create a NodePort Service, Kubernetes allocates a port from that range (or you can specify one) and opens that port on every node in the cluster, forwarding traffic to the Service's ClusterIP and then to the selected Pods.

Exam trap

The trap here is that candidates confuse NodePort with LoadBalancer, thinking LoadBalancer also uses the 30000-32767 port range on nodes, but LoadBalancer typically uses a cloud provider's load balancer and does not guarantee a static node port in that range unless NodePort is also specified.

How to eliminate wrong answers

Option B is wrong because ExternalName maps a Service to a DNS name (CNAME record) and does not expose any port on nodes. Option C is wrong because ClusterIP exposes the Service only on a cluster-internal IP, not on a static port on each node's IP. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and does not directly expose a static port in the 30000-32767 range on each node's IP.

Practice this question →

10

Multi-Selectmedium

Which TWO of the following are valid ways to expose a Service externally? (Select TWO.)

Select 2 answers

A.NodePort

B.Headless

C.LoadBalancer

D.ExternalName

E.ClusterIP

AnswersA, C

NodePort exposes the Service on a static port allocated from the default range 30000-32767 on every node's IP. Clients outside the cluster can reach the Service by connecting to `<NodeIP>:<NodePort>` on any node, and kube-proxy forwards the traffic to the backing Pods. This gives external access without requiring a cloud provider, though the port must be unique across Services.

Why this answer

A NodePort service exposes the application on a static port (30000–32767) on every node's IP address, making it accessible externally via `<NodeIP>:<NodePort>`. A LoadBalancer service provisions an external load balancer (e.g., from a cloud provider) that routes traffic to the service, typically using a public IP. Both are explicitly designed for external access, unlike ClusterIP which is internal only.

Exam trap

The trap here is that candidates confuse 'exposing externally' with any service type that has a DNS name or IP, but only NodePort and LoadBalancer provide direct external network access without additional components like Ingress or kubectl proxy.

Practice this question →

11

Multi-Selecteasy

Which THREE of the following are CNI plugins?

Select 3 answers

A.kube-proxy

B.Flannel

C.Weave

D.CoreDNS

E.Calico

AnswersB, C, E

Correct. Flannel is a CNI plugin.

Why this answer

Flannel is a CNI plugin that provides a simple overlay network for Kubernetes clusters, typically using VXLAN or host-gw to encapsulate and route pod traffic across nodes. It implements the Container Network Interface (CNI) specification by installing a binary and configuration file on each node, enabling pod-to-pod communication without requiring a separate network daemon.

Exam trap

The trap here is that candidates confuse cluster networking components (kube-proxy, CoreDNS) with CNI plugins, which are specifically responsible for pod-level network connectivity and IP assignment, not service proxying or DNS resolution.

Practice this question →

12

MCQeasy

Which of the following is NOT a valid Service type in Kubernetes?

A.ExternalName

B.NodePort

C.Headless

D.ClusterIP

AnswerC

Headless is not one of the four Kubernetes Service types; it is a configuration of a ClusterIP Service created by setting spec.clusterIP to None. Instead of providing a stable virtual IP and load balancing, it returns DNS records for each backing pod directly, which is why calling it a Service type is incorrect.

Why this answer

Headless is not a valid Service type in Kubernetes; it is a configuration of a ClusterIP service where the cluster IP is set to 'None' to return individual pod DNS records instead of a single virtual IP. The valid Service types are ClusterIP, NodePort, LoadBalancer, and ExternalName.

Exam trap

The trap here is that candidates often confuse 'Headless' as a separate Service type because it is a common configuration pattern, but Kubernetes officially defines only four Service types (ClusterIP, NodePort, LoadBalancer, ExternalName), and Headless is merely a variant of ClusterIP.

How to eliminate wrong answers

Option A is wrong because ExternalName is a valid Service type that maps a service to a DNS name via the externalName field, returning a CNAME record. Option B is wrong because NodePort is a valid Service type that exposes the service on a static port on each node's IP, typically used for external access. Option D is wrong because ClusterIP is the default Service type that exposes the service on a cluster-internal IP, reachable only within the cluster.

Practice this question →

13

MCQeasy

Which kube-proxy mode supports connection-based load balancing using Linux IPVS?

A.ipvs

B.iptables

C.kernelspace

D.userspace

AnswerA

IPVS (IP Virtual Server) in kube-proxy runs in kernel space and supports advanced scheduling algorithms such as least-connections, source hashing, and weighted round-robin. It maintains per-connection state in a connection table, allowing it to route new connections to backends with the fewest active connections and thereby implement true connection-based load balancing. This goes beyond simple random or round-robin selection.

Why this answer

The IPVS (IP Virtual Server) mode in kube-proxy uses the Linux kernel's IPVS module to implement Layer 4 (transport layer) load balancing. IPVS supports multiple scheduling algorithms (e.g., round-robin, least connections) and provides connection-based load balancing by maintaining a connection tracking table, which allows it to forward packets belonging to the same TCP/UDP session to the same backend pod. This is more efficient than iptables for large-scale clusters due to its use of hash tables (O(1) lookup) rather than linear rule chains.

Exam trap

A common misconception is that 'iptables' is the only or best mode for connection-based load balancing, but iptables does not natively support connection-based persistence without relying on conntrack, while IPVS explicitly provides it through its scheduling algorithms and connection table.

How to eliminate wrong answers

Option B is wrong because iptables mode uses Linux Netfilter rules to implement random or round-robin load balancing via statistic modules, but it does not support connection-based persistence natively; each packet is evaluated independently against the rule chain, which can cause different packets from the same connection to be sent to different backends unless conntrack is used, and it lacks the advanced scheduling algorithms of IPVS. Option C is wrong because 'kernelspace' is not a valid kube-proxy mode; the three supported modes are userspace (deprecated), iptables (default), and IPVS. Option D is wrong because userspace mode runs entirely in user space, proxying traffic through a single userspace process, which introduces high latency and poor scalability; it does not use IPVS or kernel-level connection tracking.

Practice this question →

14

MCQeasy

Which resource is used to configure TLS termination and path-based routing for HTTP(S) traffic into a cluster?

A.Ingress

B.Service

C.NetworkPolicy

AnswerA

Ingress is the standard Kubernetes resource designed specifically to manage external access to services, typically via HTTP/HTTPS. It natively supports TLS termination by referencing a TLS Secret and allows operators to define complex path-based or host-based routing rules to direct traffic to different backend Services.

Why this answer

An Ingress resource provides HTTP and HTTPS routing to services within a Kubernetes cluster, enabling TLS termination and path-based routing. It acts as a layer 7 load balancer, directing external traffic to the appropriate backend Service based on hostnames and paths defined in its rules.

Exam trap

CNCF often tests the distinction between Ingress and Service, where candidates mistakenly think a Service can handle TLS termination or path-based routing, but a Service only provides layer 4 load balancing without HTTP awareness.

How to eliminate wrong answers

Option B is wrong because a Service is a layer 4 abstraction that provides stable network endpoints for pods, but it does not support TLS termination or path-based routing; those functions require a higher-level resource. Option C is wrong because a NetworkPolicy controls ingress and egress traffic at the IP address or port level (layer 3/4) using pod selectors and CIDR rules, not HTTP path or TLS configuration. Option D is wrong because a Gateway is a newer, more advanced API (part of the Gateway API project) that can handle TLS and routing, but it is not the standard resource used for TLS termination and path-based routing in the CKA exam; the exam focuses on the traditional Ingress resource.

Practice this question →

15

MCQmedium

A NetworkPolicy allows ingress from pods with label 'role: frontend'. Which field is used to select those pods?

A.from.podSelector

B.spec.podSelector

C.ingress.podSelector

D.to.podSelector

AnswerA

For an ingress rule inside a NetworkPolicy, the `from` array identifies the allowed sources of inbound traffic. `from.podSelector` selects source pods by their labels within the same namespace as the policy, and it is the correct field to express 'allow ingress from pods with role f'.

Why this answer

In a Kubernetes NetworkPolicy, the `from.podSelector` field under `ingress` specifies the source pods from which traffic is allowed. When you set `from.podSelector.matchLabels` with `role: frontend`, only pods with that label can send ingress traffic to the pods selected by `spec.podSelector`. This is defined in the Kubernetes networking API under `networking.k8s.io/v1`.

Exam trap

The trap here is that candidates confuse `spec.podSelector` (which selects the target pods) with `from.podSelector` (which selects the source pods), leading them to pick option B instead of A.

How to eliminate wrong answers

Option B is wrong because `spec.podSelector` selects the pods to which the NetworkPolicy applies (the target pods), not the source pods allowed to send traffic. Option C is wrong because `ingress.podSelector` is not a valid field; the correct structure is `ingress[].from[].podSelector`. Option D is wrong because `to.podSelector` is used under `egress` rules to select destination pods, not for ingress source selection.

Practice this question →

16

MCQhard

You apply the following NetworkPolicy: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress ``` What is the result?

A.All traffic is allowed because no ingress/egress rules are specified

B.Only ingress traffic is denied; egress traffic is allowed

C.All ingress and egress traffic to/from all pods in the namespace is denied

D.The policy is invalid because podSelector is empty

AnswerC

This YAML defines a classic "default-deny-all" policy for the namespace. By using an empty `podSelector: {}`, the policy targets every pod in the namespace. Since both `Ingress` and `Egress` are specified in `policyTypes` but no actual allow rules are defined in the body, all incoming and outgoing network traffic is completely blocked for these pods.

Why this answer

This NetworkPolicy uses an empty `podSelector: {}` which selects all pods in the namespace. By specifying both `Ingress` and `Egress` in `policyTypes` without any rules, the policy defaults to denying all ingress and egress traffic for those pods. This is the standard Kubernetes behavior: a NetworkPolicy with no rules under a given `policyTypes` entry acts as a deny-all for that direction.

Exam trap

The trap here is that candidates assume an empty `podSelector` or missing rules means 'allow all', but Kubernetes NetworkPolicy defaults to deny when a policy selects a pod and no matching rule is present.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy with `policyTypes` defined and no rules does not allow all traffic; it denies all traffic for the specified directions. Option B is wrong because the policy explicitly includes `Egress` in `policyTypes`, so egress traffic is also denied, not just ingress. Option D is wrong because an empty `podSelector: {}` is valid and selects all pods in the namespace; the policy is not invalid.

Practice this question →

17

MCQeasy

What is the default DNS name for a service named 'my-svc' in namespace 'default'?

A.my-svc.default.cluster.local

B.my-svc.svc.cluster.local

C.my-svc.default.svc.cluster.local

D.my-svc.cluster.local

AnswerC

my-svc.default.svc.cluster.local is the canonical fully-qualified domain name for a Service named 'my-svc' created in the 'default' namespace. The pattern is '<service-name>.<namespace>.svc.cluster.local', and it maps to the cluster IP of that Service. This is the DNS name that kube-dns/CoreDNS exposes and that pods use to reach the service via stable cluster-local DNS.

Why this answer

In Kubernetes, the default DNS name for a service follows the pattern `<service-name>.<namespace>.svc.cluster.local`. For a service named 'my-svc' in the 'default' namespace, the fully qualified domain name (FQDN) is `my-svc.default.svc.cluster.local`. This is defined by the cluster DNS specification (CoreDNS or kube-dns) and allows pods to resolve the service by name within the cluster.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or the namespace component, leading them to pick options that omit one or both, such as A, B, or D, while the correct pattern always includes `<service>.<namespace>.svc.cluster.local`.

How to eliminate wrong answers

Option A is wrong because it omits the mandatory `svc` subdomain, which is part of the standard DNS schema for services. Option B is wrong because it uses `svc` directly after the service name, missing the namespace component (`default`) that is required to form the correct FQDN. Option D is wrong because it drops both the namespace and the `svc` subdomain, resulting in an incomplete and non-resolvable DNS name.

Practice this question →

18

MCQmedium

What is the default kube-proxy mode in modern Kubernetes clusters?

A.kernelspace

B.iptables

C.userspace

D.ipvs

AnswerB

Iptables is the default kube-proxy mode in virtually all modern Kubernetes clusters. In this mode, kube-proxy programs iptables rules to intercept packets destined for Service ClusterIPs and apply DNAT to randomly selected backend Pods. It has been the default since Kubernetes 1.2 and requires no extra kernel modules, making it the most universally compatible option, although its rule-chain traversal can become inefficient in very large clusters.

Why this answer

In modern Kubernetes clusters (v1.30+), the default kube-proxy mode is `iptables`. This mode uses Linux Netfilter rules to intercept and redirect traffic to backend pods, offering better performance and scalability than the legacy `userspace` mode while remaining the default for broad compatibility across distributions.

Exam trap

A common misconception in the CKA exam is that `ipvs` is the default in modern clusters, but the expected answer is `iptables` unless the question explicitly specifies a different mode.

How to eliminate wrong answers

Option A is wrong because `kernelspace` is not a valid kube-proxy mode; it may be confused with the Windows `kernelspace` proxy mode, which is not the default on Linux. Option C is wrong because `userspace` was the default in early Kubernetes versions (pre-v1.2) but was replaced by `iptables` due to higher latency and CPU overhead from userspace packet forwarding. Option D is wrong because `ipvs` is an optional mode that requires the `ipvs` kernel module and is not the default; it offers better performance for large clusters but is not set by default.

Practice this question →

19

MCQhard

You apply the following NetworkPolicy to namespace 'ns1': apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-ingress spec: podSelector: {} policyTypes: - Ingress ingress: [] What effect does this policy have?

A.Denies all egress traffic as well.

B.Allows ingress traffic only from pods in the same namespace.

C.Denies all ingress traffic to all pods in namespace ns1.

D.Allows all ingress traffic because no explicit deny rules are defined.

AnswerC

This policy selects all pods in ns1 (or a specific subset, depending on podSelector) and explicitly lists Ingress in policyTypes while providing an empty ingress list. Under Kubernetes NetworkPolicy semantics, an empty rules list means no incoming connections are permitted, so every pod matched by the selector is denied all ingress traffic. This effectively implements a deny-all-ingress rule for the namespace.

Why this answer

This NetworkPolicy selects all pods in namespace 'ns1' (via empty `podSelector: {}`), specifies `policyTypes: [Ingress]`, and defines an empty `ingress: []` rule list. In Kubernetes, an empty `ingress: []` explicitly denies all ingress traffic because no allow rules are present, overriding the default allow-all behavior. Therefore, all ingress traffic to any pod in ns1 is denied.

Exam trap

The trap here is that candidates often misinterpret an empty `ingress: []` as 'no restrictions' (i.e., allow all), when in fact Kubernetes NetworkPolicy semantics define an empty rule list as denying all traffic of that type, which is a common point of confusion in the CKA exam.

How to eliminate wrong answers

Option A is wrong because this policy only specifies `policyTypes: [Ingress]` and does not include `Egress` in the policyTypes list, so egress traffic is unaffected and remains allowed by default. Option B is wrong because the policy has no ingress rules at all (empty `ingress: []`), so it denies all ingress traffic, not just traffic from outside the namespace; it does not selectively allow intra-namespace traffic. Option D is wrong because an empty `ingress: []` is an explicit deny — it is not an absence of rules; Kubernetes NetworkPolicy semantics treat an empty rule list as denying all traffic of that type, not allowing it.

Practice this question →

20

MCQmedium

Which of the following commands can be used to check the endpoints of a service named 'my-service'?

A.kubectl get endpoints my-service

B.kubectl get pod my-service

C.kubectl get service my-service -o yaml

D.kubectl get svc my-service --show-endpoints

AnswerA

This command queries the Endpoints API object that Kubernetes maintains for a Service. The endpoints controller watches the Service's pod selector and updates this object with the current IPs and ports of ready backing pods, so `kubectl get endpoints my-service` directly lists the live backend addresses that the Service routes to.

Why this answer

The `kubectl get endpoints my-service` command directly retrieves the Endpoints object associated with the service, which lists the IP addresses and ports of the pods that match the service's selector. This is the standard and most direct way to check the active endpoints for a service in Kubernetes.

Exam trap

The trap here is that candidates may confuse the `kubectl describe svc` command (which shows endpoints in its output) with a non-existent `--show-endpoints` flag, or assume that the service YAML contains the resolved endpoint IPs.

How to eliminate wrong answers

Option B is wrong because `kubectl get pod my-service` attempts to retrieve a Pod named 'my-service', not the endpoints of the service; it would fail unless a pod with that exact name exists. Option C is wrong because `kubectl get service my-service -o yaml` outputs the service definition itself, which includes the selector but not the resolved endpoint IPs; you would need to parse the selector and query pods separately. Option D is wrong because `kubectl get svc my-service --show-endpoints` is not a valid kubectl flag; the correct command to see endpoints alongside the service is `kubectl get endpoints my-service` or `kubectl describe svc my-service`.

Practice this question →

21

MCQeasy

Which Service type is used to expose a service externally with a cloud provider's load balancer?

A.NodePort

B.ClusterIP

C.LoadBalancer

D.ExternalName

AnswerC

Correct. The LoadBalancer service type integrates with cloud providers to automatically provision a physical or virtual load balancer in your cloud infrastructure. This external load balancer receives public traffic and forwards it to the underlying NodePort and ClusterIP configurations automatically created by Kubernetes.

Why this answer

The LoadBalancer service type provisions an external load balancer from the underlying cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer, Azure Load Balancer) and assigns a public IP or DNS name to route external traffic to the Kubernetes service. It is the only built-in service type that directly integrates with a cloud provider's infrastructure to expose a service externally with a managed load balancer.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking NodePort alone provides external access via a cloud load balancer, but NodePort only opens a port on the node's IP and requires manual setup of an external load balancer or DNS to be truly accessible from the internet.

How to eliminate wrong answers

Option A is wrong because NodePort exposes the service on a static port on each node's IP address, but it does not provision a cloud provider's load balancer; it relies on the node's IP and port, which may not be externally reachable without additional configuration. Option B is wrong because ClusterIP exposes the service only on a cluster-internal IP, making it unreachable from outside the cluster. Option D is wrong because ExternalName maps a service to a DNS name (CNAME record) without proxying traffic or exposing any ports; it does not create a load balancer or provide external access via a cloud provider's load balancer.

Practice this question →

22

MCQmedium

You need to expose a Service externally using an Ingress. The Ingress controller requires a specific IngressClass. How do you specify the IngressClass in the Ingress resource?

A.Set spec.class: nginx

B.Set spec.ingressClassName: nginx

C.Add an annotation: kubernetes.io/ingress.class: nginx

D.Create an IngressClass resource and reference it via spec.ingressClassRef

AnswerB

spec.ingressClassName is the standard field in networking.k8s.io/v1 Ingress that names the IngressClass resource responsible for this Ingress. It is a simple string equal to the .metadata.name of an IngressClass, which in turn declares the controller to use via its spec.controller field. Because this field is part of the formal API, it is the correct, non-deprecated way to expose a service externally with a specific ingress controller.

Why this answer

The `spec.ingressClassName` field is the standard way to specify the IngressClass for an Ingress resource in Kubernetes v1.18+ (GA in v1.22). This field references the name of an IngressClass resource, which defines the controller (e.g., nginx, haproxy) and its configuration. Using this field ensures the Ingress controller selects the correct implementation.

Exam trap

The trap here is that candidates confuse the deprecated annotation `kubernetes.io/ingress.class` with the newer `spec.ingressClassName` field, or they invent a non-existent field like `spec.ingressClassRef`, leading them to pick the wrong option.

How to eliminate wrong answers

Option A is wrong because `spec.class` is not a valid field in the Ingress API; the correct field is `spec.ingressClassName`. Option C is wrong because the annotation `kubernetes.io/ingress.class` is deprecated since Kubernetes v1.18 and is no longer recommended; it may still work but is not the modern, preferred method. Option D is wrong because `spec.ingressClassRef` is not a valid field; the correct field is `spec.ingressClassName`, which takes a string name, not a reference object.

Practice this question →

23

MCQmedium

A cluster administrator needs to allow pods labeled 'app=web' in namespace 'frontend' to receive TCP traffic on port 443 only from pods labeled 'app=proxy' in namespace 'backend'. The cluster uses the default CNI plugin that enforces NetworkPolicy. The administrator creates a NetworkPolicy in the 'frontend' namespace with podSelector matching 'app=web', policyTypes: ['Ingress'], and an ingress rule with from: [{namespaceSelector: {matchLabels: {name: 'backend'}}, podSelector: {matchLabels: {app: 'proxy'}}}], ports: [{protocol: 'TCP', port: 443}]. However, the namespace 'backend' is not labeled with 'name=backend'. What is the effect of this policy?

A.The policy allows traffic from any pod in the 'backend' namespace regardless of labels, because the podSelector is not required when namespaceSelector is present.

B.The policy allows traffic from pods with label 'app=proxy' in any namespace, because the namespaceSelector is ignored when the namespace lacks the label.

C.The policy allows traffic from pods with label 'app=proxy' in the 'backend' namespace only if the namespace is labeled 'name=backend'; otherwise, no traffic is allowed.

D.The policy allows traffic from pods with label 'app=proxy' in the 'backend' namespace, because the podSelector alone is sufficient to identify the source.

AnswerC

The ingress rule requires the source namespace to have the label 'name=backend' and the source pod to have the label 'app=proxy'. Because the 'backend' namespace is not labeled accordingly, the rule does not match any source, and since the policy selects 'app=web' pods and has an ingress policyType, it isolates them, denying all ingress traffic except what is explicitly allowed. Thus, no traffic is allowed.

Why this answer

A NetworkPolicy ingress rule that combines namespaceSelector and podSelector in the same 'from' element requires both to match. The 'backend' namespace must have the label 'name=backend' for the rule to apply. Because it does not, the rule matches no sources, and the policy isolates the selected pods, denying all ingress traffic.

Thus, no traffic is allowed until the namespace is labeled or the policy is adjusted.

Exam trap

The trap here is assuming that a namespaceSelector without a matching namespace label will allow all namespaces or be ignored, when in fact it results in no match and thus no allowed traffic.

Practice this question →

24

MCQmedium

A developer runs `kubectl run nginx --image=nginx --port=80` and then `kubectl expose pod nginx --port=80 --target-port=80 --type=NodePort`. What is the name of the created Service?

A.nginx

B.expose-nginx

C.nginx-service

D.nginx-pod

AnswerA

When you expose a Kubernetes resource such as a Pod using the kubectl expose command, the resulting Service inherits the exact name of the target resource by default. Since the Pod created in this command is named nginx, the generated Service will also be named nginx unless an explicit --name override is provided.

Why this answer

The `kubectl expose pod nginx --port=80 --target-port=80 --type=NodePort` command creates a Service that inherits its name from the resource being exposed, which is the pod named 'nginx'. By default, `kubectl expose` uses the name of the referenced resource (in this case, the pod) as the Service name, resulting in a Service named 'nginx'. This is consistent with Kubernetes behavior where the Service name is derived from the resource name unless overridden with the `--name` flag.

Exam trap

The trap here is that candidates may assume `kubectl expose` appends a suffix like '-service' or uses a different naming pattern, but the default behavior is to reuse the exact resource name without any modification.

How to eliminate wrong answers

Option B is wrong because 'expose-nginx' is not a default naming convention; `kubectl expose` does not prepend 'expose-' to the resource name. Option C is wrong because 'nginx-service' is not automatically appended; the Service name is exactly the resource name ('nginx') unless explicitly specified with `--name`. Option D is wrong because 'nginx-pod' is not the Service name; the Service name is derived from the pod name without any suffix like '-pod'.

Practice this question →

25

MCQeasy

What is the default DNS name for a Service named 'my-service' in namespace 'my-ns'?

A.my-service.my-ns.cluster.local

B.my-service.svc.my-ns.cluster.local

C.my-service.cluster.local

D.my-service.my-ns.svc.cluster.local

AnswerD

This is the standard fully qualified domain name (FQDN) for a Kubernetes Service in the 'my-ns' namespace. The format '<service>.<namespace>.svc.cluster.local' is defined by the cluster's DNS specification, typically implemented by CoreDNS, and resolves to the Service's ClusterIP or to the pod IPs for headless Services. This FQDN works from any namespace within the cluster.

Why this answer

In Kubernetes, the default DNS name for a Service follows the pattern `<service-name>.<namespace>.svc.cluster.local`. This is defined by the cluster DNS specification (CoreDNS or kube-dns). For a Service named 'my-service' in namespace 'my-ns', the fully qualified domain name (FQDN) is `my-service.my-ns.svc.cluster.local`.

The `.svc` subdomain is a fixed part of the DNS schema, distinguishing Services from other resource types like Pods.

Exam trap

The trap here is that candidates often forget the `.svc` subdomain or misplace it, leading them to choose options like A or B, but the correct order is always `<service>.<namespace>.svc.cluster.local`.

How to eliminate wrong answers

Option A is wrong because it omits the `.svc` component, which is required in the DNS name for Services; the correct pattern includes `.svc` after the namespace. Option B is wrong because it places `.svc` before the namespace, reversing the correct order; the namespace must come before `.svc`. Option C is wrong because it omits both the namespace and the `.svc` component, which would only match a Service in the default namespace if the pattern were incomplete, but the full FQDN always includes namespace and `.svc`.

Practice this question →

26

Multi-Selectmedium

Which TWO commands can be used to test DNS resolution for a Service named 'my-svc' in namespace 'default' from within a temporary pod? (Choose 2)

Select 1 answer

A.kubectl run test --image=busybox --rm -it --restart=Never -- wget my-svc

B.kubectl run test --image=busybox --rm -it --restart=Never -- nslookup my-svc

C.kubectl run test --image=busybox --rm -it --restart=Never -- ping my-svc

D.kubectl run test --image=busybox --rm -it --restart=Never -- curl my-svc

E.kubectl run test --image=busybox --rm -it --restart=Never -- dig my-svc

AnswersB

nslookup queries DNS.

Why this answer

Option B is correct because nslookup is a DNS query tool included in busybox that resolves the Service name 'my-svc' to its ClusterIP by querying the cluster DNS (CoreDNS), directly testing DNS resolution from inside a temporary busybox pod. Option E is incorrect because the standard busybox image does not include dig; the command would fail with 'dig: not found'. To use dig, you must use an image that contains it, such as gcr.io/kubernetes-e2e-test-images/dnsutils:1.3.

Options A and D are incorrect because wget and curl are HTTP clients that test connectivity to a web endpoint, not DNS resolution itself, and they would fail if the Service has no HTTP listener. Option C is incorrect because ping tests ICMP reachability, not DNS resolution, and many Service ClusterIPs do not respond to ICMP even when DNS works.

Exam trap

The CKA exam often tests the distinction between tools that perform DNS resolution (nslookup, dig) versus tools that test network connectivity (wget, curl, ping), leading candidates to mistakenly choose connectivity tools for DNS testing.

Practice this question →

27

Multi-Selectmedium

Which two of the following are valid methods for exposing a Service externally in Kubernetes? (Select TWO.)

Select 2 answers

A.Headless

B.ExternalName

C.LoadBalancer

D.NodePort

E.ClusterIP

AnswersC, D

A LoadBalancer Service is the standard way to expose a Service to the internet on a cloud provider; it provisions an external load balancer (e.g., AWS ELB, GCP LB) that forwards traffic to the Service's node ports or internal endpoints. This gives a stable external IP and L4 load balancing, making it one of the two valid methods for external exposure (along with NodePort).

Why this answer

Option C (LoadBalancer) is correct because a Service of type LoadBalancer provisions an external load balancer (via the cloud provider's controller, e.g., an AWS ELB or GCP LB) that exposes the Service on a publicly reachable IP, making it externally accessible. Option D (NodePort) is correct because it allocates a static port on every node's IP (default range 30000-32767) and forwards traffic to the Service, so external clients can reach the Service via <NodeIP>:<NodePort>. Option A (Headless) is not a valid external exposure method; a headless Service (clusterIP: None) simply returns pod IPs directly via DNS for direct pod addressing, not external access.

Option B (ExternalName) maps a Service to an external DNS name via a CNAME record and is used for accessing external resources from inside the cluster, not for exposing an internal Service externally. Option E (ClusterIP) is the default type and only provides an internal virtual IP reachable within the cluster, so it does not expose the Service externally.

Exam trap

A common misconception is that Headless or ExternalName can expose a Service externally, but they are designed for internal DNS resolution and DNS aliasing, respectively, not for external traffic routing.

Practice this question →

28

MCQeasy

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

A.ExternalName

B.ClusterIP

C.LoadBalancer

D.NodePort

AnswerD

A NodePort Service allocates a static port from the default range 30000–32767 on every node’s IP address, forwarding inbound traffic on that port to the Service’s ClusterIP and then to the selected Pods. This satisfies the stem’s constraint of exposing the Service on a static port per node IP, unlike ClusterIP (internal only) or LoadBalancer (cloud-provisioned external IP).

Why this answer

NodePort is the correct answer because it exposes a Service on a static port (in the range 30000–32767) on every node's IP address. Traffic sent to any node's IP on that port is forwarded to the Service's ClusterIP and then to the backing pods. This is defined in the Service's `spec.ports[].nodePort` field.

Exam trap

The trap here is that candidates confuse LoadBalancer with NodePort, forgetting that LoadBalancer relies on an external cloud controller to provision an actual LB, while NodePort directly opens a static port on every node's IP.

How to eliminate wrong answers

Option A is wrong because ExternalName maps a Service to a DNS name (via CNAME) and does not expose any port or IP on nodes. Option B is wrong because ClusterIP exposes the Service only on a cluster-internal virtual IP, which is not reachable from outside the cluster without additional components. Option C is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and does not directly expose a static port on each node's IP; it typically builds on NodePort but adds a cloud LB.

Practice this question →

29

MCQmedium

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

A.kubectl expose deployment web --port=80 --type=ClusterIP

B.kubectl create deployment web --image=nginx --port=80

C.kubectl run web --image=nginx --port=80

D.kubectl create service clusterip web --tcp=80:80

AnswerA

`kubectl expose deployment web --port=80 --type=ClusterIP` is the canonical imperative command for exposing a Deployment as a Service. It reads the Deployment's pod selector (e.g., `app=web`), creates a ClusterIP Service named `web` with `port=80`, and sets the Service's targetPort to the same value unless overridden. This automatically gains an Endpoints object pointing at the Deployment's healthy pods, which is exactly what "exposing" a Deployment means on the internal cluster network.

Why this answer

`kubectl expose deployment web --port=80 --type=ClusterIP` creates a ClusterIP Service that exposes the Deployment named 'web' on port 80 internally within the cluster. The `--type=ClusterIP` is the default service type, making this command explicitly create a ClusterIP Service, which is only reachable from inside the Kubernetes cluster.

Exam trap

The trap here is that candidates may think `kubectl create service clusterip` is the correct way to expose an existing Deployment, but it creates an orphaned Service without linking to the Deployment's Pods, whereas `kubectl expose` correctly derives the selector from the Deployment.

How to eliminate wrong answers

Option B is wrong because `kubectl create deployment web --image=nginx --port=80` creates a Deployment, not a Service; it does not expose the Deployment as a ClusterIP Service. Option C is wrong because `kubectl run web --image=nginx --port=80` creates a Pod (or a Deployment in newer versions), not a Service, and does not create a ClusterIP Service. Option D is wrong because `kubectl create service clusterip web --tcp=80:80` creates a ClusterIP Service but it is not linked to the existing Deployment 'web'; it creates a standalone Service without selecting the Pods of that Deployment, so it does not expose the Deployment as intended.

Practice this question →

30

MCQhard

A NetworkPolicy named 'deny-all' is applied to a namespace with podSelector: {}. The policy has no ingress rules. What is the effect?

A.All traffic to and from pods in the namespace is denied.

B.Only traffic from pods in the same namespace is allowed.

C.All ingress traffic to pods in the namespace is denied, but egress traffic is allowed.

D.All traffic is allowed because podSelector: {} matches nothing.

AnswerC

This is the correct behavior because setting podSelector: {} applies the policy to all pods in the namespace, and omitting ingress rules creates an isolate-and-deny-all state for incoming traffic. Because the policy does not define Egress in its policyTypes, outbound connections from these pods are left unaffected and allowed by default.

Why this answer

A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. With no ingress rules defined, the policy defaults to denying all ingress traffic to those pods, while egress traffic remains unrestricted unless explicitly denied by another policy. This is because Kubernetes NetworkPolicy is additive for ingress: if any policy selects a pod, the default allow for ingress is overridden, and only explicitly allowed ingress traffic is permitted.

Exam trap

The trap here is that candidates often assume `podSelector: {}` matches nothing or that a policy with no rules allows all traffic, but in Kubernetes, an empty podSelector matches all pods, and a NetworkPolicy with no ingress rules defaults to denying all ingress traffic.

How to eliminate wrong answers

Option A is wrong because the policy only denies ingress traffic; egress traffic is not affected by the absence of ingress rules, so not all traffic is denied. Option B is wrong because the policy does not allow any ingress traffic, including traffic from the same namespace; it denies all ingress, so only egress traffic is allowed. Option D is wrong because `podSelector: {}` matches all pods in the namespace, not nothing; it is a valid selector that applies the policy to every pod.

Practice this question →

31

MCQeasy

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

A.ExternalName

B.NodePort

C.LoadBalancer

D.ClusterIP

AnswerB

NodePort allocates a static port from the default range 30000–32767 and opens it on every node's IP, forwarding traffic to the service. This satisfies the stem's requirement for exposure on a fixed port per node, unlike ClusterIP (internal only) or LoadBalancer (cloud-provisioned external IP).

Why this answer

NodePort is the correct answer because it exposes a service on a static port (in the range 30000-32767) on every node's IP address. When you create a NodePort service, Kubernetes allocates a port from that range and opens that port on all nodes, forwarding traffic to the service's ClusterIP and then to the pods.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking that LoadBalancer also exposes a static port on each node, but LoadBalancer actually relies on a cloud provider's external load balancer and does not automatically open a port on every node's IP.

How to eliminate wrong answers

Option A is wrong because ExternalName maps a service to a DNS name (via CNAME record) and does not expose any port on node IPs. Option C is wrong because LoadBalancer exposes the service via a cloud provider's load balancer (e.g., ELB) and assigns an external IP, not a static port on each node's IP. Option D is wrong because ClusterIP exposes the service only on a cluster-internal IP, reachable only within the cluster, not on node IPs.

Practice this question →

32

MCQhard

You want to configure NetworkPolicy to allow ingress traffic only from pods with label 'role: frontend' in the same namespace. Which podSelector should be in the ingress rule?

A.podSelector in spec.podSelector

B.podSelector in spec.ingress.from

C.podSelector in spec.egress.to

D.namespaceSelector in spec.ingress.from

AnswerB

Within an ingress rule, the from field accepts one or more sources, and a podSelector there selects the exact source pods whose traffic to the selected destination pods will be permitted. This is the core mechanism for allowing ingress from specific pods, as it matches pods by labels in the same namespace unless combined with a namespaceSelector. Without this field, the ingress rule has an empty from, which means no sources are allowed, aligning with the default-deny behavior.

Why this answer

In a Kubernetes NetworkPolicy, the `spec.ingress.from` field specifies the sources allowed to send ingress traffic. To match pods with a specific label within the same namespace, you use a `podSelector` under `from`. This selects pods based on their labels, and since no `namespaceSelector` is specified, it defaults to the same namespace as the NetworkPolicy.

Exam trap

The trap here is that candidates often confuse `spec.podSelector` (which selects the target pods the policy applies to) with the `podSelector` inside `ingress.from` (which selects the source pods allowed to send traffic), leading them to pick Option A.

How to eliminate wrong answers

Option A is wrong because `spec.podSelector` defines which pods the NetworkPolicy applies to (the target pods), not the source of ingress traffic. Option C is wrong because `spec.egress.to` is used for egress rules, not ingress; it controls outbound traffic destinations. Option D is wrong because a `namespaceSelector` selects entire namespaces, not pods with a specific label within the same namespace; it would allow traffic from any pod in the selected namespace, not just those with label 'role: frontend'.

Practice this question →

33

MCQeasy

What is the default kube-proxy mode in Kubernetes v1.29?

A.nftables

B.userspace

C.iptables

D.ipvs

AnswerC

iptables is the default kube-proxy mode in Kubernetes v1.29, using legacy netfilter rules to implement Service load balancing. kube-proxy programs iptables chains with rules that use the statistic matching module to select backend Pods with random probability. This approach provides efficient in-kernel NAT and load balancing without requiring a separate proxy process for each connection, which is why it remains the standard.

Why this answer

In Kubernetes v1.29, the default kube-proxy mode is `iptables`. This mode uses Linux iptables rules to handle service traffic, providing better performance and reliability than the older userspace mode. It is the default because it balances simplicity and efficiency for most cluster configurations.

Exam trap

The trap here is that candidates may confuse the default mode with the most advanced or performant option (like ipvs), or mistakenly think nftables is the default because it is the modern replacement for iptables in Linux, but Kubernetes v1.29 still defaults to iptables.

How to eliminate wrong answers

Option A is wrong because `nftables` is not a supported kube-proxy mode in Kubernetes v1.29; it is a newer Linux packet filtering framework that may be used in future versions but is not the default. Option B is wrong because `userspace` was the default mode in early Kubernetes versions (pre-v1.2) but was deprecated due to high overhead and is no longer the default. Option D is wrong because `ipvs` is an optional mode that provides better performance for large-scale clusters but is not the default; it must be explicitly configured via the `--proxy-mode=ipvs` flag or kube-proxy configuration.

Practice this question →

34

MCQeasy

Which Service type exposes a Service externally via a cloud provider's load balancer?

A.ExternalName

B.LoadBalancer

C.ClusterIP

D.NodePort

AnswerB

This service type integrates directly with cloud providers to automatically provision a native external load balancer, such as an AWS NLB/ALB or GCP Cloud Load Balancer. It assigns a public IP address or DNS name to the service, routing external internet traffic directly to the underlying NodePort and ClusterIP configurations.

Why this answer

(LoadBalancer) is correct because the LoadBalancer Service type automatically provisions an external load balancer from the underlying cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer, Azure Load Balancer) and assigns a public IP or DNS name to expose the Service externally. This is achieved by the cloud-controller-manager component, which watches for Services of type LoadBalancer and creates the corresponding cloud resource.

Exam trap

The CKA exam often tests the distinction between NodePort and LoadBalancer, trapping candidates who think NodePort alone provides external cloud load balancing, when in fact NodePort only opens a port on each node and requires an external load balancer or manual routing to be truly accessible from outside.

How to eliminate wrong answers

Option A (ExternalName) is wrong because it maps a Service to a DNS name (via CNAME) and does not expose any ports or provide load balancing; it is used for internal DNS aliasing, not external exposure. Option C (ClusterIP) is wrong because it assigns a virtual IP reachable only within the cluster (via kube-proxy iptables/IPVS rules) and is not accessible from outside the cluster without additional components. Option D (NodePort) is wrong because it exposes the Service on a static port on each Node's IP address, but it does not integrate with a cloud provider's load balancer; it is a lower-level mechanism that requires manual configuration or an external load balancer to route traffic to the NodePort.

Practice this question →

35

MCQmedium

You need to expose multiple HTTP services on a single IP address with path-based routing. Which resource should you use?

A.Service of type ClusterIP

B.NetworkPolicy

C.Service of type NodePort

D.Ingress

AnswerD

Ingress is the standard Kubernetes API object for L7 HTTP routing, allowing you to define host- and path-based rules that direct traffic to multiple backend Services. A single Ingress controller receives external traffic on one IP (often via a load balancer) and routes each request to the appropriate Service based on the URL path. This exactly fulfills the requirement of exposing multiple HTTP services on a single IP address.

Why this answer

Ingress is the correct resource because it provides HTTP/HTTPS layer-7 routing to multiple services based on hostnames or paths, all exposed on a single IP address. Services of type ClusterIP, NodePort, or LoadBalancer operate at layer 4 and cannot perform path-based routing. An Ingress controller (e.g., NGINX, HAProxy) implements the rules defined in the Ingress resource to direct traffic to the appropriate backend services.

Exam trap

The trap here is that candidates confuse Ingress with Service types like NodePort or LoadBalancer, thinking those can handle HTTP routing, but they only provide layer-4 load balancing without any awareness of HTTP paths or hostnames.

How to eliminate wrong answers

Option A is wrong because a Service of type ClusterIP is only reachable within the cluster and does not provide external access or path-based routing. Option B is wrong because NetworkPolicy controls traffic flow between pods at the network layer (layer 3/4) and cannot expose services or perform HTTP path routing. Option C is wrong because a Service of type NodePort exposes a static port on each node's IP at layer 4 (TCP/UDP) and cannot route based on HTTP paths or hostnames.

Practice this question →

36

MCQmedium

You update a NetworkPolicy to add an egress rule. After applying, pods affected by the policy can no longer reach external IPs. What is the most likely reason?

A.The egress rule has a typo in the IP block

B.The pods are not running

C.NetworkPolicy egress rules deny all traffic by default unless explicitly allowed

D.The CNI plugin does not support egress rules

AnswerC

When a `NetworkPolicy` is applied to pods and includes an `egress` section, the default behavior for those pods' outbound traffic immediately switches from "allow all" to "deny all." Any egress traffic not explicitly matched by one of the `egress` rules within that policy will be dropped. Therefore, if the newly added egress rule does not explicitly permit the necessary external IPs, all external traffic will be blocked by default.

Why this answer

NetworkPolicy in Kubernetes follows a default-deny model for traffic. When any egress rule is added to a NetworkPolicy, it implicitly denies all egress traffic that is not explicitly allowed by that rule. Therefore, if the egress rule does not include a rule allowing traffic to external IPs (e.g., via an IPBlock or a namespace selector), those destinations become unreachable.

This is by design, as NetworkPolicies are additive whitelists.

Exam trap

The trap here is that candidates often assume egress rules are additive (i.e., they only allow traffic without affecting existing connectivity), but Kubernetes NetworkPolicy egress rules are whitelist-only, meaning any egress rule implicitly denies all other egress traffic.

How to eliminate wrong answers

Option A is wrong because a typo in the IP block would cause a mismatch, but the question states the pods can no longer reach external IPs at all, which is a broader symptom consistent with default-deny behavior, not a typo. Option B is wrong because if the pods were not running, they would not be able to reach any IPs at all, and the question implies they were previously able to reach external IPs before the update. Option D is wrong because most CNI plugins (e.g., Calico, Cilium, Weave) support egress rules; the CKA exam assumes a standard CNI that supports NetworkPolicy, and lack of support would typically cause no enforcement, not a sudden block.

Practice this question →

37

MCQhard

A NetworkPolicy named 'deny-all' is created with an empty podSelector and no rules. What does this policy accomplish?

A.Has no effect because NetworkPolicy requires at least one rule

B.Denies all ingress and egress traffic to all pods in the namespace

C.Denies only ingress traffic to pods labeled 'app: denied'

D.Allows all traffic because no rules are specified

AnswerB

This is correct because an empty podSelector matches every pod within the target namespace. By defining both Ingress and Egress in the policyTypes list without providing any corresponding allow rules, the policy enforces a strict default-deny posture for all incoming and outgoing network traffic.

Why this answer

A NetworkPolicy with an empty `podSelector` selects all pods in the namespace. When no rules are specified, the policy defaults to denying all ingress and egress traffic because NetworkPolicy rules are whitelist-based: if no rule allows traffic, all traffic is denied. This effectively isolates the namespace by blocking all network traffic to and from every pod.

Exam trap

The trap here is that candidates assume an empty rule set means 'allow all' or that a podSelector must match specific labels, but in Kubernetes NetworkPolicy, an empty podSelector selects all pods and no rules means deny all traffic.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy with an empty podSelector and no rules is valid and has the effect of denying all traffic; it does not require at least one rule to take effect. Option C is wrong because an empty podSelector selects all pods, not just those with a specific label like 'app: denied', and the policy denies all traffic, not just ingress. Option D is wrong because the absence of rules means no traffic is allowed, not that all traffic is allowed; NetworkPolicy uses a default-deny model when no rules match.

Practice this question →

38

MCQhard

A pod cannot resolve a service DNS name. The cluster uses CoreDNS. Which of the following is the most likely cause if the pod's /etc/resolv.conf contains 'nameserver 10.96.0.10' and the CoreDNS pod is running?

A.The CoreDNS ConfigMap does not have the correct cluster domain.

B.The pod's DNS policy is set to 'Default'.

C.The CoreDNS pod is in CrashLoopBackOff.

D.The service's DNS name is misspelled.

AnswerA

CoreDNS's kubernetes plugin reads a ConfigMap (typically named 'coredns' in the kube-system namespace) to determine the cluster domain, usually 'cluster.local.' If the 'kubernetes' block in that ConfigMap specifies a mismatched or missing domain, CoreDNS will not append the correct search domain, so fully qualified service names like 'my-svc.my-ns.svc.cluster.local' will fail to resolve. Since the pod is running, a static misconfiguration in the ConfigMap is a primary suspect and directly explains the symptom.

Why this answer

If the CoreDNS ConfigMap does not specify the correct cluster domain (e.g., `cluster.local`), CoreDNS will not respond to queries for service DNS names within that domain. The pod's `resolv.conf` shows the correct ClusterIP of the CoreDNS service (10.96.0.10), and the CoreDNS pod is running, so the issue is likely a misconfiguration in the CoreDNS plugin settings, specifically the `kubernetes` plugin's `clusterDomain` parameter.

Exam trap

The trap here is that candidates assume a running CoreDNS pod and correct `nameserver` IP guarantee DNS resolution, overlooking that CoreDNS must be configured with the correct cluster domain to handle service DNS names.

How to eliminate wrong answers

Option B is wrong because setting the pod's DNS policy to 'Default' means the pod inherits the node's `/etc/resolv.conf`, which typically points to the cluster's DNS service (10.96.0.10) anyway, so it would not prevent DNS resolution. Option C is wrong because the question explicitly states the CoreDNS pod is running, so CrashLoopBackOff is not the cause. Option D is wrong because while a misspelled DNS name would cause resolution failure, the question asks for the most likely cause given the pod's resolv.conf is correct and CoreDNS is running; a configuration error in CoreDNS is a more systematic issue than a simple typo.

Practice this question →

39

MCQhard

You have a NodePort service. Which kube-proxy mode allows for better performance and more sophisticated load balancing algorithms like 'least connection'?

A.ipvs

B.iptables

C.kernelnet

D.userspace

AnswerA

IPVS (IP Virtual Server) is a kernel-level transport-layer load balancer that kube-proxy uses to implement Kubernetes Services with a virtual server table. Unlike iptables' random chaining, IPVS supports multiple scheduling algorithms, including least connection (lc), which routes new connections to the backend with the fewest active connections. It also offers better scalability and O(1) lookups by using hash tables, making it the correct choice for advanced load-balancing needs.

Why this answer

(ipvs) is correct because kube-proxy in IPVS mode uses the Linux kernel's IP Virtual Server (IPVS) to implement Layer 4 load balancing, which supports sophisticated scheduling algorithms such as 'least connection' (lc), round-robin, and others. IPVS operates in kernel space with a hash table structure, providing better performance and scalability compared to iptables, especially in clusters with thousands of services.

Exam trap

The trap here is that candidates often assume iptables is the default and most performant mode, but the CKA exam expects you to know that IPVS is the only mode that supports advanced scheduling algorithms like 'least connection' and offers better performance at scale.

How to eliminate wrong answers

Option B is wrong because iptables mode uses a linear chain of iptables rules for each service, which becomes slow and inefficient as the number of services grows, and it only supports random or round-robin selection via DNAT rules, not sophisticated algorithms like 'least connection'. Option C is wrong because 'kernelnet' is not a valid kube-proxy mode; the recognized modes are userspace, iptables, IPVS, and (in newer versions) nftables. Option D is wrong because userspace mode runs in user space and proxies traffic via a userspace proxy, which introduces higher latency and lower performance due to context switching, and it does not support advanced load balancing algorithms like 'least connection'.

Practice this question →

40

MCQeasy

Which of the following Service types does NOT assign a ClusterIP to the Service?

A.LoadBalancer

B.Headless

C.ClusterIP

D.NodePort

AnswerB

A Headless Service is explicitly configured by setting the spec.clusterIP field to None. This configuration instructs the control plane not to allocate a virtual IP address or perform load balancing via kube-proxy. Instead, DNS queries for the service return the direct A/AAAA records of the underlying backend pods, making it ideal for stateful applications.

Why this answer

A Headless Service is created by setting the `clusterIP` field to `None` in the Service specification. This tells Kubernetes not to allocate a ClusterIP, making the Service headless. Instead of a virtual IP, DNS queries for the Service name return the IP addresses of all matching Pods directly, enabling stateful workloads like databases to discover individual Pod endpoints.

Exam trap

The trap here is that candidates often assume all Services must have a ClusterIP, forgetting that the `clusterIP: None` field explicitly disables it, and they may confuse Headless Services with NodePort or LoadBalancer types that still allocate a ClusterIP under the hood.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer Service type does assign a ClusterIP; it creates a ClusterIP first, then provisions an external load balancer that routes traffic to that ClusterIP. Option C is wrong because ClusterIP is the default Service type that explicitly assigns a stable virtual IP from the cluster's service CIDR range. Option D is wrong because a NodePort Service type also assigns a ClusterIP; it builds on top of ClusterIP by additionally opening a high-port on every Node to forward traffic to that ClusterIP.

Practice this question →

41

MCQeasy

Which of the following is a valid CNI plugin for Kubernetes networking?

A.Calico

B.etcd

C.Docker

D.Kubelet

AnswerA

Calico is a valid Container Network Interface (CNI) plugin that provides networking and network policy for Kubernetes clusters. It implements the CNI specification by configuring routes, assigning IP addresses (via IPAM), and enforcing policy using iptables or eBPF dataplanes, making it one of the most widely adopted CNI plugins in production.

Why this answer

Calico is a valid CNI plugin that implements the Container Network Interface specification to provide networking and network policy for Kubernetes clusters. It uses BGP (Border Gateway Protocol) to route packets between nodes and supports overlay or non-overlay networking modes, making it a widely adopted choice for production environments.

Exam trap

The trap here is that candidates confuse cluster infrastructure components (etcd, kubelet) or container runtimes (Docker) with CNI plugins, because they are all part of the Kubernetes ecosystem but serve fundamentally different roles.

How to eliminate wrong answers

Option B (etcd) is wrong because etcd is a distributed key-value store used to store Kubernetes cluster state and configuration, not a CNI plugin for networking. Option C (Docker) is wrong because Docker is a container runtime that can be used with Kubernetes but is not a CNI plugin; CNI plugins handle network interface setup, not container execution. Option D (Kubelet) is wrong because Kubelet is the primary node agent that manages pods and containers on a node, and while it invokes CNI plugins, it is not itself a CNI plugin.

Practice this question →

42

MCQmedium

An administrator runs `kubectl port-forward service/my-svc 8080:80`. What does this command do?

A.Creates a new Service with port mapping 8080:80

B.Forwards port 8080 from the Service to port 80 on the local machine

C.Forwards port 80 from the local machine to port 8080 on the Service

D.Forwards local port 8080 to port 80 on the Service

AnswerD

The command `kubectl port-forward service/<name> 8080:80` correctly creates a local listener on port 8080 and forwards traffic through the Kubernetes API server to a pod that backs the specified Service, reaching that pod on its port 80. The format is always <local>:<remote>, so the left side of the colon is the port that appears on your workstation (localhost:8080) and the right side is the intended destination port inside the cluster (the Service's port 80). This lets you reach a cluster-internal Service endpoint without exposing it publicly, which is useful for debugging, accessing a private web UI, or testing a preview of an application running inside the cluster.

Why this answer

`kubectl port-forward` creates a tunnel from a local port to a pod (or service) in the cluster. When targeting a Service, it selects one of the Service's endpoints (a pod) and forwards traffic from localhost:8080 to port 80 on that pod. This allows direct access to the Service without exposing it externally.

Exam trap

The trap here is confusing the direction of the port mapping: candidates often think the first port is the remote port and the second is the local port, but `kubectl port-forward` always uses the format `local_port:remote_port`.

How to eliminate wrong answers

Option A is wrong because `kubectl port-forward` does not create or modify any Kubernetes resources; it only establishes a temporary network tunnel from the local machine. Option B is wrong because it reverses the direction: the command forwards the local port 8080 to the Service's port 80, not the Service's port 8080 to the local machine. Option C is wrong because it incorrectly states that the local machine's port 80 is forwarded to the Service's port 8080, which is the opposite of the actual mapping (local 8080 → Service 80).

Practice this question →

43

MCQeasy

Which kube-proxy mode uses iptables rules to handle service traffic?

A.ipvs

B.nftables

C.userspace

D.iptables

AnswerD

iptables is the correct mode because kube-proxy in this mode programs the kernel's iptables NAT table with rules that translate a service's ClusterIP or NodePort to a selected pod IP. These rules use statistics to randomly choose among healthy endpoints, so packet forwarding and load balancing are entirely implemented with iptables rules. As a result, the service handling is performed by iptables in the kernel, not by a userspace process.

Why this answer

Kube-proxy's iptables mode uses Linux iptables rules to handle service traffic. In this mode, kube-proxy watches the Kubernetes API server for Service and Endpoint changes and programs iptables rules in the NAT table (specifically the PREROUTING and OUTPUT chains) to redirect traffic destined for a Service's ClusterIP to the backend Pod IPs via DNAT. This is the default mode in most Kubernetes distributions due to its reliability and moderate performance.

Exam trap

The trap here is that candidates often confuse the iptables mode with the ipvs mode, assuming ipvs also uses iptables rules, but ipvs operates at a different layer (kernel-level load balancing) and does not rely on iptables for service traffic handling.

How to eliminate wrong answers

Option A is wrong because ipvs mode uses the IPVS (IP Virtual Server) kernel module to handle service traffic, not iptables; it offers better scalability and performance for large clusters by using a hash table instead of a linear rule chain. Option B is wrong because nftables is a modern replacement for iptables, but kube-proxy does not have a native nftables mode; the iptables mode uses legacy iptables, not nftables. Option C is wrong because userspace mode is an older, deprecated mode where kube-proxy runs in userspace and proxies traffic through a userspace process, not using iptables rules for packet forwarding.

Practice this question →

44

MCQeasy

You need to temporarily access a pod's HTTP endpoint on port 8080 from your local machine on port 8080. Which kubectl command should you use?

A.kubectl expose pod my-pod --port=8080

B.kubectl proxy --port=8080

C.kubectl port-forward service/my-service 8080:8080

D.kubectl port-forward pod/my-pod 8080:8080

AnswerD

This command successfully establishes a secure, temporary tunnel from your local machine's port 8080 directly to port 8080 of the specified pod. It is the standard, lightweight method for debugging and interacting with a pod's endpoint without exposing it to the wider network.

Why this answer

`kubectl port-forward` creates a direct tunnel from a local port to a specific pod, allowing you to access the pod's HTTP endpoint on port 8080 from your local machine on port 8080. This command targets the pod directly (`pod/my-pod`) and maps local port 8080 to the pod's port 8080, which is exactly what the question requires for temporary, ad-hoc access without creating a Service.

Exam trap

The trap here is that candidates often confuse `kubectl port-forward` with `kubectl expose` or `kubectl proxy`, thinking those commands provide direct pod access, when in fact `port-forward` is the only command that creates a direct, temporary tunnel from a local port to a specific pod's port without creating a Service or proxying through the API server.

How to eliminate wrong answers

Option A is wrong because `kubectl expose` creates a Kubernetes Service object (e.g., ClusterIP, NodePort) that persists in the cluster, not a temporary local port forward; it does not directly expose the pod to your local machine on port 8080. Option B is wrong because `kubectl proxy` creates a local HTTP proxy to the Kubernetes API server, not a direct tunnel to a specific pod's port; it requires additional URL path manipulation to reach a pod and does not map local port 8080 to the pod's port 8080. Option C is wrong because it targets a Service (`service/my-service`) rather than the pod itself; while `port-forward` works with Services, the question explicitly asks to access a pod's HTTP endpoint, and using a Service introduces an extra layer that may not be available or desired for temporary direct pod access.

Practice this question →

45

MCQmedium

You run `kubectl port-forward service/my-svc 8080:80`. What does this command do?

A.It forwards local port 8080 to port 80 on a Pod selected by the Service, bypassing the Service's ClusterIP.

B.It forwards traffic from port 80 to port 8080 within the cluster.

C.It creates a LoadBalancer Service on port 8080 forwarding to port 80.

D.It exposes the Service on each node's port 8080.

AnswerA

Port-forward resolves the Service to a backing Pod and tunnels local 8080 directly to that Pod's port 80, bypassing the ClusterIP entirely. This satisfies the scenario's constraint of reaching a Service-selected Pod without routing through the virtual IP.

Why this answer

The `kubectl port-forward` command forwards connections from a local port to a port on a Pod. When you specify a Service (e.g., `service/my-svc`), kubectl automatically selects an active Pod matching the Service's selector and forwards the traffic directly to that Pod. It completely bypasses the Service's ClusterIP and kube-proxy routing.

Exam trap

Candidates often mistakenly believe that `kubectl port-forward` routes traffic through the Service's ClusterIP. In reality, it resolves the Service's selector, picks a backing Pod, and establishes a direct tunnel to that Pod via the API server and the node's kubelet.

How to eliminate wrong answers

Option B is wrong because it describes the direction of traffic backwards: port-forward forwards from a local port to a remote port, not from port 80 to port 8080 within the cluster. Option C is wrong because port-forward does not create or modify any Service object; it is a temporary client-side tunnel, not a LoadBalancer Service creation. Option D is wrong because port-forward does not expose the Service on each node's port; that would be achieved by a NodePort Service, not by kubectl port-forward.

Practice this question →

46

MCQeasy

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

A.kubectl exec -it web-pod -- nc -l -p 8080

B.kubectl proxy --port=8080

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

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

AnswerD

kubectl port-forward pod/web-pod 8080:80 creates a direct TCP tunnel from your localhost:8080 to port 80 inside web-pod via the Kubernetes API server. The pod/<name> resource identifier and the local:remote port pair are the correct port-forward syntax, and this is the intended command for one-off debugging access. It keeps running until interrupted.

Why this answer

`kubectl port-forward` creates a direct tunnel from a local port to a specified port on a pod, allowing access to the pod's service without exposing it externally. The syntax `pod/web-pod 8080:80` forwards localhost:8080 to port 80 of the pod named 'web-pod'.

Exam trap

The trap here is that candidates confuse `kubectl port-forward` with `kubectl expose` or `kubectl proxy`, mistakenly thinking that creating a Service or a proxy is the correct way to forward a local port to a specific pod, when in fact `port-forward` is the only command that creates a direct local-to-pod tunnel.

How to eliminate wrong answers

Option A is wrong because `kubectl exec -it web-pod -- nc -l -p 8080` starts a netcat listener inside the pod on port 8080, which does not forward a local port to the pod's port 80; it listens on a different port inside the container. Option B is wrong because `kubectl proxy --port=8080` creates a proxy server that forwards traffic to the Kubernetes API server, not to a specific pod's port 80. Option C is wrong because `kubectl expose pod web-pod --port=8080 --target-port=80` creates a Service object that exposes the pod within the cluster, but it does not forward a local port to the pod; it requires additional steps like `kubectl get svc` and accessing via the service IP or node port.

Practice this question →

47

MCQhard

A developer runs 'kubectl port-forward service/my-svc 8080:80' and reports that connections to localhost:8080 fail. The service is a ClusterIP service that selects pods with label 'app: my-app'. What is the most likely cause?

A.The service type is ClusterIP, which does not support port forwarding.

B.No pods match the service selector, so the service has no endpoints.

C.kubectl port-forward cannot forward to services, only to pods.

D.The port forward command requires the --address flag to bind to localhost.

AnswerB

This is the correct explanation. For a Service, kubectl port-forward requires at least one ready endpoint, which is created automatically when pod labels match the service's selector. When no pods match, the Endpoints object is empty, causing the API server to fail with an error such as 'Unable to connect to a frontend pod'. The developer must verify the selector against existing pod labels or manually define endpoints for selector-less services.

Why this answer

B is correct because if no pods match the service selector 'app: my-app', the service will have no endpoints. Without endpoints, the service cannot route traffic, and kubectl port-forward will fail to establish a connection to localhost:8080. The port-forward command relies on the service having at least one endpoint to forward traffic to.

Exam trap

The trap here is that candidates may assume port forwarding only works with pods, but Kubernetes actually supports port forwarding to services by automatically selecting a pod from the service's endpoints.

How to eliminate wrong answers

Option A is wrong because ClusterIP services do support port forwarding; the service type does not affect the ability to use kubectl port-forward. Option C is wrong because kubectl port-forward can forward to services (as well as pods) by resolving the service to its endpoints. Option D is wrong because the --address flag is optional and defaults to localhost; the failure is not due to missing the --address flag.

Practice this question →

48

MCQmedium

Which of the following is the default DNS name for a Service named 'my-svc' in namespace 'my-ns'?

A.my-svc.my-ns.svc.cluster.local

B.my-svc.my-ns.cluster.local

C.my-svc.my-ns.svc

D.my-svc.my-ns.pod.cluster.local

AnswerA

This represents the fully qualified domain name (FQDN) for a Kubernetes Service. It strictly adheres to the standard format `<service-name>.<namespace>.svc.<cluster-domain>`, where the `svc` segment explicitly identifies the resource type as a service and `cluster.local` represents the default cluster-wide domain suffix.

Why this answer

A is correct because Kubernetes uses a built-in DNS system (CoreDNS) that automatically creates DNS records for Services. The fully qualified domain name (FQDN) for a Service follows the pattern `<service-name>.<namespace>.svc.cluster.local`, where `svc` is a fixed label indicating it's a Service record, and `cluster.local` is the default cluster domain. This allows pods to resolve the Service by name within the cluster.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or the `cluster.local` suffix, confusing the Service DNS pattern with the Pod DNS pattern or assuming a shorter name will work due to search domain expansion.

How to eliminate wrong answers

Option B is wrong because it omits the `svc` subdomain, which is a required component in the DNS name for a Service; without it, the DNS query would not match the Service's A/AAAA record. Option C is wrong because it lacks the cluster domain suffix `cluster.local`, making it an incomplete FQDN that would not be resolved by CoreDNS unless a search domain is appended. Option D is wrong because it uses `pod` instead of `svc`, which is the subdomain for Pod DNS records (e.g., `pod-ip.namespace.pod.cluster.local`), not for Services.

Practice this question →

49

MCQmedium

You have a headless service named 'my-headless' with clusterIP: None. A pod in the same namespace queries the DNS name 'my-headless'. What will the DNS response contain?

A.An error because headless services cannot be queried by DNS.

B.A single A record with the service's IP.

C.The ClusterIP of the service (which is None).

D.A list of A records for each pod matching the service selector.

AnswerD

A headless Service with a selector creates Endpoints (or EndpointSlices) from the ready pods that match the labels. When a client looks up this Service name, CoreDNS returns one A record for each such pod IP, allowing direct pod discovery. This behavior is fundamental to StatefulSets, where each pod gets its own DNS name from this list.

Why this answer

A headless service (clusterIP: None) does not have a ClusterIP or load-balance traffic. Instead, DNS queries for the service name return A records for the individual pod IPs that match the service's selector. This allows direct pod-to-pod communication without a proxy, as defined by Kubernetes DNS specification.

Exam trap

The trap here is that candidates confuse headless services with normal ClusterIP services, assuming DNS will return a single virtual IP or an error, rather than understanding that headless services return multiple pod IPs for direct pod-to-pod resolution.

How to eliminate wrong answers

Option A is wrong because headless services are specifically designed to be queried by DNS, returning pod IPs rather than an error. Option B is wrong because a headless service does not have a single service IP; it returns multiple A records for each matching pod. Option C is wrong because the ClusterIP is explicitly set to 'None', and the DNS response does not return this value; it returns pod IPs instead.

Practice this question →

50

MCQhard

You have a NetworkPolicy that selects pods with label 'app: db'. The policy has an ingress rule allowing traffic from pods with label 'app: frontend'. A pod with label 'app: frontend' is in a different namespace. No namespaceSelector is specified in the ingress rule. Will traffic from that pod be allowed?

A.Yes, because podSelector selects pods across all namespaces

B.No, because NetworkPolicy only works within the same namespace

C.Yes, because all ingress traffic is allowed by default

D.No, because the frontend pod is in a different namespace and no namespaceSelector is specified

AnswerD

Since the frontend pod resides in a different namespace, a simple podSelector rule inside the NetworkPolicy will not match it. To permit cross-namespace traffic, the policy must explicitly define a namespaceSelector to target the external namespace.

Why this answer

A NetworkPolicy's ingress rule without a namespaceSelector only applies to pods within the same namespace as the policy. Since the frontend pod is in a different namespace and no namespaceSelector is specified, the rule does not match it, and traffic is denied by default (as NetworkPolicy enforces default-deny for selected pods).

Exam trap

The trap here is that candidates assume a podSelector alone can match pods across namespaces, confusing it with the behavior of a namespaceSelector, or they forget that NetworkPolicy defaults to deny-all ingress for selected pods.

How to eliminate wrong answers

Option A is wrong because a podSelector in a NetworkPolicy only selects pods within the policy's namespace, not across all namespaces, unless combined with a namespaceSelector. Option B is wrong because NetworkPolicy can work across namespaces when a namespaceSelector is used in the ingress rule, but the question states no namespaceSelector is specified. Option C is wrong because when a NetworkPolicy selects a pod, all ingress traffic is denied by default unless explicitly allowed by a matching rule; there is no default allow for ingress.

Practice this question →

51

MCQmedium

You run 'kubectl get svc my-service -o yaml' and see 'type: ClusterIP'. The service has no endpoints. What is the most likely cause?

A.The service type is ClusterIP, which does not support endpoints.

B.The service's port does not match the container port.

C.The service is misconfigured and needs to be deleted and recreated.

D.No pods with labels matching the service selector are running and ready.

AnswerD

The endpoint controller only publishes Backends for pods that match the Service's selector and have their Ready condition set to True. If no pod carries the label/value pair defined in the selector, or if all matching pods are still Pending/Running with failing readiness probes, the Endpoints object stays empty. This is the canonical root cause of a Service with type ClusterIP but no endpoints.

Why this answer

A Kubernetes Service of type ClusterIP relies on a label selector to identify target Pods. If no Pods match the selector and are in the Ready state, the Service will have no endpoints, causing traffic to be dropped. The absence of endpoints directly indicates a mismatch or absence of matching, ready Pods.

Exam trap

The trap here is that candidates assume a missing endpoint is due to a port mismatch or Service type limitation, rather than recognizing that endpoints are solely driven by the label selector and Pod readiness.

How to eliminate wrong answers

Option A is wrong because ClusterIP is the default Service type and fully supports endpoints; endpoints are created when Pods matching the selector are ready. Option B is wrong because a port mismatch between the Service and container port would cause connection failures, not a lack of endpoints; endpoints are generated based on the selector, not port matching. Option C is wrong because misconfiguration (e.g., incorrect selector) can be fixed by editing the Service's selector field, not by deleting and recreating it; deletion is unnecessary unless the Service is fundamentally broken.

Practice this question →

52

MCQmedium

What is the DNS name for a Service named 'api' in the 'default' namespace?

A.api.default.svc.cluster.local

B.default.api.svc.cluster.local

C.api.svc.default.cluster.local

D.api.default.cluster.local

AnswerA

The Kubernetes DNS schema for a Service is <service-name>.<namespace>.svc.cluster.local. Since the Service is named 'api' and created in the default namespace, the fully qualified domain name becomes api.default.svc.cluster.local. This FQDN resolves to the Service's ClusterIP and enables reliable cluster-wide service discovery.

Why this answer

The correct DNS name for a Service in Kubernetes follows the pattern `<service-name>.<namespace>.svc.cluster.local`. For a Service named 'api' in the 'default' namespace, this resolves to `api.default.svc.cluster.local`. The `svc` subdomain is a fixed part of the cluster domain, and `cluster.local` is the default cluster domain suffix configured in kubelet and CoreDNS.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or reverse the service/namespace order, because they may confuse the DNS format with other Kubernetes naming conventions (e.g., pod DNS or headless service records) or assume the namespace comes first.

How to eliminate wrong answers

Option B is wrong because it reverses the order of service name and namespace, which would be `default.api.svc.cluster.local` — this is not a valid Kubernetes DNS format. Option C is wrong because it places `svc` after the namespace, resulting in `api.svc.default.cluster.local` — the `svc` component must come after the namespace, not before it. Option D is wrong because it omits the `svc` subdomain entirely, giving `api.default.cluster.local` — this would not be resolved by CoreDNS for a Service, as the `svc` label is required in the DNS search path.

Practice this question →

53

MCQmedium

You create a Service of type LoadBalancer in a Kubernetes cluster that does not have an external load balancer provider (e.g., bare-metal). What will be the state of the EXTERNAL-IP field when you run 'kubectl get svc'?

A.The ClusterIP

B.The node's IP address

C.<pending>

D.<none>

AnswerC

Immediately after a LoadBalancer service is created, its external IP status is set to <pending>. This status persists until the cloud-controller-manager successfully communicates with the underlying cloud provider's API to provision the physical or virtual load balancer and assign it a public IP address.

Why this answer

When a Service of type LoadBalancer is created in a Kubernetes cluster without an external load balancer provider (e.g., bare-metal or on-premises), the cloud-controller-manager component responsible for provisioning the external load balancer is absent or non-functional. As a result, the external IP address remains unassigned, and `kubectl get svc` displays `<pending>` for the EXTERNAL-IP field until a controller sets it. This state persists indefinitely unless an external tool like MetalLB is deployed to fulfill the LoadBalancer request.

Exam trap

The trap here is that candidates confuse `<pending>` with `<none>`, assuming that without a cloud provider the field will simply be empty, but Kubernetes explicitly marks the LoadBalancer Service as pending to indicate it is waiting for an external IP assignment.

How to eliminate wrong answers

Option A is wrong because the ClusterIP is the internal IP assigned to the Service for cluster-internal traffic, not the external IP; the EXTERNAL-IP field is separate and shows the load balancer's address. Option B is wrong because the node's IP address is not automatically assigned to a LoadBalancer Service; a cloud provider or external controller must program the load balancer to route traffic to nodes, and without one, no IP is populated. Option D is wrong because `<none>` indicates the field is intentionally empty (e.g., for ClusterIP or NodePort Services), but for a LoadBalancer Service, the field is expected to be assigned and shows `<pending>` to reflect the waiting state.

Practice this question →

54

MCQmedium

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

A.Ingress traffic from pods with label 'app: allowed' is allowed.

B.All ingress and egress traffic to/from pods in the namespace is denied.

C.The policy has no effect because no rules are specified.

D.All ingress traffic to any pod in the namespace is denied.

AnswerD

An empty podSelector selects every pod in the namespace, and the sole policyType is Ingress, so all inbound connections to those pods are blocked while egress stays unaffected. It satisfies the scenario's requirement to deny all incoming traffic namespace-wide.

Why this answer

This NetworkPolicy uses a `podSelector: {}` which selects all pods in the namespace, and specifies `policyTypes: [Ingress]` with no ingress rules. According to Kubernetes NetworkPolicy semantics, when no ingress rules are defined, all ingress traffic is denied. This effectively creates a default-deny ingress policy for all pods in the namespace, making option D correct.

Exam trap

The trap here is that candidates often think a NetworkPolicy with no rules is ineffective or that `podSelector: {}` alone does nothing, but in Kubernetes, specifying `policyTypes` without corresponding rules triggers a default-deny for that traffic direction.

How to eliminate wrong answers

Option A is wrong because the policy has no ingress rules, so no ingress traffic is allowed based on labels; the `podSelector: {}` selects all pods, but without an `ingress` field, no traffic is permitted. Option B is wrong because the policy only specifies `Ingress` in `policyTypes`, not `Egress`, so egress traffic is not affected; a separate `Egress` policy would be needed to deny egress. Option C is wrong because the policy does have an effect: by specifying `policyTypes: [Ingress]` with no ingress rules, it defaults to denying all ingress traffic; this is a valid and intentional configuration.

Practice this question →

55

MCQhard

You have an Ingress resource with the following spec: spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 A client sends a request to http://example.com/api/v1/users. Which path is matched?

A./api/v1/users

B.ImplementationSpecific: depends on the Ingress controller

C./api

D.No match, returns 404

AnswerC

With pathType Prefix, the path /api matches any request URL whose path starts with /api, and matching is performed on a segment boundary; /api/v1/users begins with /api followed by the / segment, so it satisfies the rule. Prefix is the default and most common pathType for REST APIs because it allows a single rule to govern all nested resource endpoints. Thus /api is the correct path that the Ingress rule defines.

Why this answer

The Ingress rule uses `pathType: Prefix` with a path of `/api`. According to the Kubernetes Ingress specification, a Prefix pathType matches any URL path that has the specified path as its prefix. The request `/api/v1/users` starts with `/api`, so it matches the rule, and the traffic is forwarded to the `api-service` on port 80.

Exam trap

The trap here is that candidates often confuse `Prefix` with `Exact` and think the entire request path must match the specified path, leading them to incorrectly select Option A or D, or they assume `ImplementationSpecific` is the default behavior when `pathType` is explicitly set.

How to eliminate wrong answers

Option A is wrong because the path `/api/v1/users` is not the path defined in the Ingress rule; the rule matches based on the prefix `/api`, not the full request path. Option B is wrong because `ImplementationSpecific` is not the pathType used here; the spec explicitly sets `pathType: Prefix`, so the behavior is defined by the Kubernetes specification, not left to the controller. Option D is wrong because the request does match the prefix rule, so a 404 is not returned; the Ingress controller routes the request to the backend service.

Practice this question →

56

Multi-Selecthard

Which three components are part of the Gateway API? (Choose three.)

Select 3 answers

A.Ingress

B.GatewayClass

D.HTTPRoute

E.Service

AnswersB, C, D

GatewayClass is one of the three core Gateway API resources and serves as a cluster-scoped template that defines a named class of gateways. It references a controller that manages gateways of that class and can include parameters for customization, similar to StorageClass in the storage API. By grouping gateways into classes, it enables different implementations (e.g., different load balancers) to be used transparently within the same cluster. Thus, GatewayClass is correct because it is a fundamental building block for defining gateway behavior.

Why this answer

The Gateway API defines three core resource types: GatewayClass, Gateway, and HTTPRoute (along with other route types like TCPRoute and TLSRoute). Option B, GatewayClass, is correct because it is a cluster-scoped resource that identifies the controller implementing the Gateway API and defines the class of gateways available. Option C, Gateway, is correct because it represents an instance of a gateway that provisions the underlying load balancer or proxy and defines listeners for traffic.

Option D, HTTPRoute, is correct because it is a route resource that attaches to a Gateway and specifies how HTTP traffic is matched and forwarded to backend Services. Option A, Ingress, is not part of the Gateway API; it is a separate, older Kubernetes API for HTTP routing. Option E, Service, is a core Kubernetes resource used as a backend target, not a component of the Gateway API itself.

Exam trap

The CKA exam often tests the distinction between the older Ingress API and the newer Gateway API, where candidates mistakenly think Ingress is a component of the Gateway API, but Ingress is a separate, standalone resource.

Practice this question →

57

MCQmedium

An Ingress resource is created with the following spec: spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 The backend service 'api-service' is in the same namespace as the Ingress. What must be true for the Ingress to route traffic to the service?

A.The Ingress controller must be configured to use the NodePort of the service.

B.The service 'api-service' must be of type NodePort.

C.The service 'api-service' must have a valid ClusterIP and at least one endpoint.

D.The Ingress must have an IngressClass annotation.

AnswerC

Ingress routing resolves the backend through the Service, so the Service needs a valid ClusterIP and at least one ready endpoint. Without endpoints, kube-proxy has no pod to forward to and requests fail, regardless of correct Ingress path and host configuration.

Why this answer

For an Ingress to route traffic to a backend service, the service must have a valid ClusterIP (so the Ingress controller can reach it via the cluster network) and at least one healthy endpoint (i.e., pods matching the service’s selector must be running and ready). The Ingress controller forwards traffic to the service’s ClusterIP on the specified port, not directly to pods, so a ClusterIP and endpoints are essential.

Exam trap

The trap here is that candidates often assume Ingress requires a NodePort or LoadBalancer service type, but in reality, Ingress works with any service type that has a ClusterIP (including ClusterIP, NodePort, and LoadBalancer), and the critical requirement is that the service has a reachable ClusterIP and at least one ready endpoint.

How to eliminate wrong answers

Option A is wrong because the Ingress controller does not require NodePort of the service; it uses the service’s ClusterIP and port, not the node port. Option B is wrong because the service does not need to be of type NodePort; Ingress works with ClusterIP services (the default type) as long as the service has a ClusterIP and endpoints. Option D is wrong because while an IngressClass annotation may be needed in some setups (e.g., multiple controllers), it is not universally required; the question does not specify a multi-controller environment, and the Ingress can work without it if a default IngressClass is defined or the controller is configured to watch all Ingresses.

Practice this question →

58

MCQmedium

You want to forward local port 8080 to port 80 of a pod named 'nginx-pod'. Which command should you use?

A.kubectl proxy pod/nginx-pod 8080:80

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

C.kubectl forward pod/nginx-pod 8080 80

D.kubectl port-forward service/nginx-pod 8080:80

AnswerB

This is the correct command and syntax for forwarding traffic from a local port to a pod. The `kubectl port-forward` subcommand targets the `pod/nginx-pod` resource and maps local port 8080 to the container's port 80, establishing a secure tunnel via the API server.

Why this answer

`kubectl port-forward` is the Kubernetes command used to forward a local port to a port on a specific pod. The syntax `kubectl port-forward pod/nginx-pod 8080:80` correctly specifies the pod resource, the local port (8080), and the target pod port (80), enabling access to the pod's port 80 from the local machine.

Exam trap

The trap here is that candidates often confuse `kubectl port-forward` with `kubectl proxy` or misremember the syntax, leading them to choose a non-existent command like `kubectl forward` or incorrectly assume that a service must always be used for port forwarding.

How to eliminate wrong answers

Option A is wrong because `kubectl proxy` is used to create a proxy server to the Kubernetes API server, not to forward ports to a specific pod; it does not accept a pod resource type or port mapping syntax. Option C is wrong because `kubectl forward` is not a valid kubectl command; the correct command is `kubectl port-forward`. Option D is wrong because it forwards to a service (`service/nginx-pod`) rather than a pod; while `kubectl port-forward` can target services, the question explicitly asks for forwarding to a pod named 'nginx-pod', and the service name may not match the pod name, making this option incorrect for the given scenario.

Practice this question →

59

Multi-Selectmedium

Which TWO statements about Headless services are correct? (Select TWO)

Select 2 answers

A.A headless service assigns a ClusterIP to the service

B.Headless services provide round-robin load balancing across pods

C.Headless services require a selector that matches at least one pod

D.DNS queries for a headless service return the IP addresses of the backing pods

E.A headless service is created by setting clusterIP to None

AnswersD, E

For a headless service with a selector, Kubernetes still creates an Endpoints object listing the IPs of all pods that match the selector, but it does not expose those IPs behind a ClusterIP. Instead, DNS A/AAAA records for the service name resolve directly to those individual pod IPs, so a query returns one or more pod addresses depending on how many endpoints exist. This is the core mechanism that enables stateful applications, such as databases, to discover and connect to specific pod instances rather than a load-balanced virtual IP.

Why this answer

Option E is correct because a headless service is defined by explicitly setting the spec.clusterIP field to "None" in the Service manifest, which tells Kubernetes not to allocate a virtual IP. Option D is correct because, with no ClusterIP, kube-dns/CoreDNS resolves the service name directly to the individual pod IPs (A/AAAA records) of the endpoints rather than to a single service VIP. Options A and B are wrong because a headless service has no ClusterIP and therefore no kube-proxy VIP-based round-robin load balancing; clients connect directly to pod IPs.

Option C is wrong because a headless service does not strictly require a selector — a selectorless headless service is valid and is commonly used with manually managed Endpoints or EndpointSlices.

Exam trap

The trap here is that candidates often confuse headless services with regular ClusterIP services, assuming they still get a ClusterIP or that they provide built-in load balancing, when in fact headless services are designed for direct pod addressing without proxying.

Practice this question →

60

MCQmedium

You have a NetworkPolicy that selects pods with label 'role: db' in the 'default' namespace. The policy has no ingress rules defined. What is the effect on traffic to the selected pods?

A.Only traffic from pods with label 'role: frontend' is allowed

B.Both ingress and egress traffic are denied

C.All ingress traffic is denied

D.All ingress traffic is allowed

AnswerC

This is the correct behavior because applying a NetworkPolicy to a pod transitions it into an isolated state for ingress. Since the policy selects the target pods but contains no ingress rules to explicitly permit traffic, Kubernetes defaults to a deny-all stance for all incoming connections.

Why this answer

A NetworkPolicy with no ingress rules defaults to denying all ingress traffic to the selected pods. This is because Kubernetes NetworkPolicies are whitelist-based: if no ingress rules are specified, the policy implicitly denies all incoming traffic, even if other policies allow it. The selected pods with label 'role: db' will therefore receive no ingress traffic.

Exam trap

The trap here is that candidates often assume a NetworkPolicy with no rules allows all traffic, but Kubernetes defaults to deny for ingress when a policy selects the pod, making 'All ingress traffic is allowed' a common mistake.

How to eliminate wrong answers

Option A is wrong because the policy has no ingress rules, so it does not allow traffic from any specific source, including pods with label 'role: frontend'. Option B is wrong because the policy only affects ingress traffic; egress traffic is not denied unless an egress rule is explicitly defined. Option D is wrong because the absence of ingress rules results in all ingress traffic being denied, not allowed.

Practice this question →

61

MCQmedium

Which of the following is a correct Ingress resource snippet that routes traffic to service 'web-svc' on port 80 for the host 'example.com'?

A.spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: web-svc port: number: 80

B.spec: rules: - http: paths: - backend: service: name: web-svc port: number: 80

C.spec: rules: - host: example.com http: paths: - backend: serviceName: web-svc servicePort: 80

D.spec: rules: - host: example.com backend: serviceName: web-svc servicePort: 80

AnswerA

This snippet correctly adheres to the networking.k8s.io/v1 Ingress API specification. It properly defines a routing rule under spec.rules with a designated host, an http routing block, and a path list containing the required path, pathType (set to Prefix), and a nested backend.service configuration specifying both name and port.number.

Why this answer

It follows the exact structure required by the Kubernetes Ingress v1 API (networking.k8s.io/v1). It specifies the host `example.com`, defines an HTTP rule with a path of `/` and `pathType: Prefix`, and correctly references the backend service `web-svc` on port 80 using the `service.name` and `port.number` fields. This configuration ensures that traffic for `example.com` is routed to the target service.

Exam trap

The trap here is that candidates often confuse the deprecated `extensions/v1beta1` API syntax (using `serviceName` and `servicePort`) with the current `networking.k8s.io/v1` API syntax (using `service.name` and `port.number`), leading them to select option C.

How to eliminate wrong answers

Option B is wrong because it omits the `host` field, which means the rule would match all hosts, not just `example.com`, and fails to meet the requirement of routing traffic specifically for `example.com`. Option C is wrong because it uses the deprecated `serviceName` and `servicePort` fields from the older `extensions/v1beta1` API; the correct Ingress v1 API requires `service.name` and `port.number`. Option D is wrong because it places the `backend` block directly under the `rules` entry instead of under `http.paths`, which is an invalid structure; the backend must be nested within a path definition.

Practice this question →

62

MCQhard

You have a Service with endpoints for pods in different zones. You want kube-proxy to use a mode that provides better performance for large clusters and supports scheduling algorithms like least-connection. Which mode should you use?

A.userspace mode

B.ipvs mode

C.iptables mode

D.kernelspace mode

AnswerB

IPVS (IP Virtual Server) mode operates in the Linux kernel space and utilizes hash tables, allowing it to scale efficiently to thousands of services. It supports advanced load-balancing algorithms, such as round-robin, least connection, and destination hashing, which are crucial for optimizing traffic distribution across different zones.

Why this answer

IPVS (IP Virtual Server) mode is correct because it uses the LVS (Linux Virtual Server) kernel module to provide a transport-layer load balancer that supports multiple scheduling algorithms, including least-connection (lc), round-robin (rr), and source hashing (sh). Unlike iptables, IPVS uses a hash table as the underlying data structure, which scales linearly with the number of services and endpoints, making it far more performant in large clusters with thousands of services.

Exam trap

The trap here is that candidates often assume iptables mode is the best for performance because it is the default, but they overlook that IPVS is specifically designed for high-performance load balancing with advanced scheduling algorithms, while iptables mode only supports random selection and suffers from linear rule traversal in large clusters.

How to eliminate wrong answers

Option A is wrong because userspace mode runs kube-proxy in user space, proxying traffic through a userspace program, which incurs high overhead due to context switching and copying data between kernel and user space, and does not support advanced scheduling algorithms like least-connection. Option C is wrong because iptables mode uses a chain of iptables rules that are evaluated sequentially for every packet, leading to O(n) lookup time and poor performance in large clusters with many services; it also only supports random selection (via statistic module) and does not natively support least-connection scheduling. Option D is wrong because kernelspace mode is not a valid kube-proxy mode; the three supported modes are userspace, iptables, and IPVS.

Practice this question →

63

Multi-Selectmedium

Which THREE components are required for a pod to resolve a Service DNS name?

Select 3 answers

A.The Service exists in the cluster

B.CoreDNS is running and has a Service entry for the cluster domain

C.kubelet configures the pod's /etc/resolv.conf

D.kube-proxy is running in iptables mode

E.A CNI plugin is installed

AnswersA, B, C

The Service must exist in the cluster because the cluster DNS system only creates DNS A/AAAA records for Service objects, not for individual pods or arbitrary endpoints. When a Service is created, the DNS controller registers a name in the form <service>.<namespace>.svc.<cluster-domain>, and without that object there is no record for the resolver to return. This is a prerequisite independent of the DNS server itself or the pod's resolver configuration: even a healthy CoreDNS and correctly set resolv.conf cannot resolve a Service name that was never defined.

Why this answer

A Pod resolves a Service DNS name by querying the cluster's DNS service, which only returns an A/AAAA record if the Service object exists. Without the Service, the DNS name has no corresponding cluster IP to resolve, so the query fails with NXDOMAIN.

Exam trap

A common trap is confusing kube-proxy's role in Service traffic routing with DNS name resolution. kube-proxy handles load balancing of traffic to Service pods, but it does not resolve DNS names. DNS resolution relies solely on CoreDNS and the pod's resolv.conf configuration.

Practice this question →

64

MCQeasy

Which resource type is used to configure HTTP/HTTPS routing to Services?

A.EndpointSlice

B.NetworkPolicy

C.Ingress

D.Service

AnswerC

Ingress is the standard Kubernetes API resource designed specifically to manage external access to services, typically via HTTP and HTTPS. It allows administrators to define routing rules based on hostnames (Layer 7 domain names) and URL paths, enabling a single external IP address to expose multiple backend services.

Why this answer

Ingress is the Kubernetes resource that provides HTTP and HTTPS routing from outside the cluster to Services within the cluster. It defines rules for host-based and path-based routing, TLS termination, and load balancing, making it the correct choice for configuring external HTTP/HTTPS access.

Exam trap

The trap here is that candidates confuse a Service's external exposure (e.g., NodePort or LoadBalancer) with the need for HTTP/HTTPS routing, forgetting that Ingress is the dedicated resource for L7 routing and TLS termination.

How to eliminate wrong answers

Option A is wrong because EndpointSlice is a resource that tracks network endpoints (IP addresses and ports) for a Service, not for routing HTTP/HTTPS traffic. Option B is wrong because NetworkPolicy is used to control ingress and egress traffic between Pods at the network layer (L3/L4), not for HTTP/HTTPS routing. Option D is wrong because a Service exposes Pods internally or via a load balancer but does not provide HTTP/HTTPS routing rules, host-based routing, or TLS termination.

Practice this question →

65

MCQmedium

A developer runs 'kubectl port-forward service/my-service 8080:80'. What does this command do?

A.It creates a proxy that routes traffic from the service's ClusterIP to the local machine on port 8080.

B.It forwards incoming traffic on local port 8080 to port 80 on the service's ClusterIP.

C.It exposes the service as a NodePort on port 8080.

D.It creates a new service of type LoadBalancer on port 8080.

AnswerB

This is the correct behavior of the command. It binds to port 8080 on the local loopback interface and securely tunnels any connection made to localhost:8080 through the API server to port 80 of the specified Service, which then routes it to the backing Pods.

Why this answer

`kubectl port-forward` creates a tunnel from a local port on the client machine to a specified port on a Kubernetes resource, in this case a Service. It forwards traffic received on localhost:8080 to the Service's ClusterIP on port 80, allowing the developer to access the service without exposing it externally.

Exam trap

The trap here is that candidates confuse `kubectl port-forward` with `kubectl expose` or `kubectl proxy`, mistakenly thinking it creates a permanent Service or NodePort, when in fact it only creates a temporary, client-side tunnel.

How to eliminate wrong answers

Option A is wrong because `kubectl port-forward` does not create a proxy that routes traffic from the service's ClusterIP to the local machine; it does the opposite — it forwards from the local machine to the service. Option C is wrong because the command does not expose the service as a NodePort; NodePort is a Service type that opens a port on every node, not a local port-forward. Option D is wrong because `kubectl port-forward` does not create any Service object, let alone a LoadBalancer type; it only establishes a temporary tunnel for debugging.

Practice this question →

66

Multi-Selecthard

Which TWO statements about EndpointSlices are correct?

Select 2 answers

A.EndpointSlices improve scalability compared to Endpoints.

B.EndpointSlices include topology information like zone.

C.EndpointSlices are created manually by the user.

D.Each EndpointSlice can contain only one endpoint.

E.EndpointSlices are only used with ClusterIP services.

AnswersA, B

The legacy Endpoints API stores every IP address for a Service in a single object, which becomes extremely large and causes every node's kube-proxy to be notified on any change. EndpointSlices partition that data into multiple, smaller objects that default to a maximum of 100 endpoints each, so scaling to thousands of pods does not create a single massive, frequently updated resource. This dramatically reduces the update blast radius and improves overall cluster performance.

Why this answer

Option A is correct because EndpointSlices improve scalability over the legacy Endpoints object: instead of one large Endpoints resource per Service, the EndpointSlice controller splits endpoints across multiple EndpointSlice objects (default up to 100 endpoints per slice), reducing the size of updates propagated to kube-proxy and other watchers. Option B is correct because each EndpointSlice endpoint includes topology information such as the node's zone and hostname (under the topology field, e.g., kubernetes.io/hostname and topology.kubernetes.io/zone), which enables topology-aware routing and traffic distribution. Option C is incorrect because EndpointSlices are normally created and managed automatically by the EndpointSlice controller (and mirrored by kube-proxy), not manually by users.

Option D is incorrect because a single EndpointSlice can hold many endpoints (up to 100 by default), not just one. Option E is incorrect because EndpointSlices back all Service types that have endpoints, including ClusterIP, NodePort, LoadBalancer, and headless Services, not only ClusterIP.

Exam trap

The trap here is that candidates often assume EndpointSlices are a manual or optional feature, or that they only apply to ClusterIP Services, when in reality they are the default and automatically managed for all Services with selectors, and they support topology-aware routing.

Practice this question →

67

MCQhard

You have a kube-proxy running in ipvs mode. Which of the following is true about IPVS?

A.IPVS supports multiple load balancing algorithms.

B.IPVS uses iptables rules for service discovery.

C.IPVS is the default kube-proxy mode since Kubernetes 1.0.

D.IPVS cannot handle large numbers of services.

AnswerA

IPVS (IP Virtual Server) is a kernel-level transport-layer load balancer that exposes multiple scheduling algorithms, including round-robin (rr), least-connections (lc), destination hashing (dh), and source hashing (sh). kube-proxy in IPVS mode programs these algorithms into the kernel, allowing operators to select a traffic distribution strategy that best fits their workload instead of being limited to iptables' simple random or default behavior.

Why this answer

IPVS (IP Virtual Server) supports multiple load balancing algorithms, such as round-robin, least-connection, source-hashing, and others, which is a key advantage over iptables mode. This allows kube-proxy to distribute traffic across pods more flexibly and efficiently, especially in high-traffic environments.

Exam trap

The trap here is that candidates often confuse IPVS with iptables, assuming IPVS still relies on iptables rules for service discovery, when in fact IPVS uses a separate kernel-level mechanism with its own scheduling algorithms.

How to eliminate wrong answers

Option B is wrong because IPVS uses a hash table and kernel-level load balancing, not iptables rules, for service discovery and packet forwarding; iptables mode is a separate kube-proxy mode. Option C is wrong because IPVS is not the default mode since Kubernetes 1.0; iptables mode was the default for many years, and IPVS became an optional mode later (introduced as alpha in 1.8 and stable in 1.11). Option D is wrong because IPVS is specifically designed to handle large numbers of services efficiently, using a hash table that scales better than iptables linear rule processing.

Practice this question →

68

MCQmedium

You run `kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort` and the Service is created. What is the effect of this command?

A.It creates a NodePort Service, making the deployment accessible on each node's IP on a high port.

B.It creates a LoadBalancer Service and provisions a cloud load balancer.

C.It creates a ClusterIP Service that is only accessible within the cluster.

D.It creates an ExternalName Service that maps to an external DNS name.

AnswerA

The `kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort` command creates a Service of type NodePort, which allocates a high port (30000–32767) on every cluster node and forwards traffic from that port to port 8080 on the pods selected by the `web` deployment. This satisfies the requirement to expose the deployment externally without a cloud load balancer, using each node’s IP address as the access point.

Why this answer

The `kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort` command creates a NodePort Service. This Service exposes the deployment on each node's IP address on a static port (in the range 30000-32767 by default), making it accessible from outside the cluster via `<NodeIP>:<NodePort>`. The `--type=NodePort` flag explicitly overrides the default ClusterIP type, and the Service will also automatically allocate a ClusterIP for internal routing.

Exam trap

The trap here is that candidates often confuse `--type=NodePort` with `--type=LoadBalancer`, assuming that exposing a Service on a node port automatically provisions a cloud load balancer, or they forget that NodePort Services also include a ClusterIP and are not purely external.

How to eliminate wrong answers

Option B is wrong because `--type=NodePort` does not create a LoadBalancer Service; a LoadBalancer Service requires `--type=LoadBalancer` and typically provisions a cloud load balancer via the cloud provider's integration. Option C is wrong because while a NodePort Service does include a ClusterIP for internal access, the explicit `--type=NodePort` flag creates a NodePort Service, not a pure ClusterIP Service; a ClusterIP Service would be created with `--type=ClusterIP` or by omitting the type flag. Option D is wrong because an ExternalName Service maps a Service to an external DNS name using the `externalName` field, which is not set by this command; `kubectl expose` does not support creating ExternalName Services directly.

Practice this question →

69

MCQhard

An ingress resource is defined with the following snippet: ```yaml spec: tls: - hosts: - app.example.com secretName: app-tls rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: app-service port: number: 80 ``` The secret 'app-tls' exists and contains a valid certificate. However, accessing https://app.example.com returns a certificate warning in the browser. What is the most likely cause?

A.The TLS secret is in a different namespace than the ingress resource

B.The ingress controller does not support TLS termination

C.The path type is Prefix but should be Exact

D.The secret name does not match the TLS section host

AnswerA

In Kubernetes, Ingress resources can only reference TLS Secret objects that reside within the exact same namespace. If the Secret containing the TLS certificate and private key is deployed in a different namespace, the Ingress controller will fail to locate it, resulting in TLS handshake failures or fallback to a default self-signed certificate.

Why this answer

The TLS secret must reside in the same namespace as the Ingress resource because the Ingress controller reads the secret from the Ingress's namespace. If the secret is in a different namespace, the controller cannot access it, causing it to fall back to its default (untrusted) certificate or fail to serve the correct certificate, which results in a browser certificate warning.

Exam trap

A common pitfall is assuming the TLS secret can be in any namespace; Kubernetes requires the secret to be in the same namespace as the Ingress resource. If not, the Ingress controller cannot access it, leading to a certificate warning.

How to eliminate wrong answers

Option B is wrong because most ingress controllers (e.g., NGINX, Traefik) support TLS termination; if they didn't, HTTPS would not work at all, not just show a warning. Option C is wrong because the path type Prefix with path '/' matches all paths, which is correct for serving the application; changing to Exact would only match the root path and break routing. Option D is wrong because the secret name in the TLS section does not need to match the host; the secret is referenced by name, and the host list in the TLS section indicates which hosts use that secret, so a mismatch would not cause a certificate warning if the secret exists and is valid.

Practice this question →

70

MCQmedium

You need to expose a service named 'my-svc' on a static port 30080 on every node. Which service type should you use?

A.LoadBalancer

B.NodePort

C.ExternalName

D.ClusterIP

AnswerB

NodePort is the correct service type because it reserves a static port from a default range (30000-32767) across all cluster nodes. This allows external clients to access the service by targeting any node's IP address combined with the designated static port, satisfying the requirement directly without external dependencies.

Why this answer

NodePort is the correct service type because it exposes the service on a static port (30080) on every node's IP address. When you create a NodePort service, Kubernetes allocates a port from the range 30000-32767 (by default) and opens that port on all nodes, forwarding traffic to the service's ClusterIP and then to the pods. This allows external access to the service via any node's IP and the specified NodePort.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer is required for external access, but NodePort alone suffices for exposing a static port on every node without cloud dependencies.

How to eliminate wrong answers

Option A is wrong because LoadBalancer creates an external load balancer (e.g., from a cloud provider) and does not directly expose a static port on every node; it typically relies on NodePort underneath but adds a cloud-specific LB. Option C is wrong because ExternalName maps a service to a DNS name (CNAME) and does not expose any port or provide network connectivity to pods. Option D 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.

Practice this question →

71

MCQmedium

You have a service 'my-svc' of type ClusterIP with no selector defined. You manually create an Endpoints object with the same name. Which statement is true?

A.The service will automatically create an Endpoints object based on the service ports.

B.The Endpoints object must have the same labels as the service.

C.The service will route traffic to the IPs defined in the Endpoints object.

D.The service must be of type ExternalName to use manually created Endpoints.

AnswerC

For a ClusterIP service without a selector, Kubernetes relies on a manually created Endpoints resource sharing the same name. kube-proxy will configure the data plane (such as iptables or IPVS) to intercept traffic sent to the Service's ClusterIP and route it directly to the target IP addresses and ports defined in that Endpoints object.

Why this answer

A Kubernetes Service without a selector relies on a manually created Endpoints object to define the backend targets. The Service's ClusterIP will route traffic to the IP addresses and ports specified in the Endpoints object, as long as the Endpoints object has the same name as the Service and the Service's ports match the Endpoints' ports. This is a common pattern for routing traffic to external resources or services not managed by Kubernetes.

Exam trap

The trap here is that candidates assume a Service always auto-creates an Endpoints object, but the CKA exam tests the specific case where a Service has no selector, requiring manual Endpoints creation.

How to eliminate wrong answers

Option A is wrong because a Service without a selector does not automatically create an Endpoints object; the Endpoints object must be created manually. Option B is wrong because Endpoints objects do not require labels to match the Service; they are linked by name, not labels. Option D is wrong because a Service of type ExternalName is used for DNS-based redirection, not for routing traffic to manually created Endpoints; manually created Endpoints work with ClusterIP, NodePort, or LoadBalancer Services.

Practice this question →

72

MCQmedium

A pod in namespace 'ns1' cannot resolve the DNS name 'svc.ns2.svc.cluster.local'. What is the most likely cause?

A.The pod's DNS policy is set to None.

B.The service 'svc' does not exist in namespace 'ns2'.

C.The pod is trying to resolve using only the short service name 'svc' without the namespace.

D.The pod's DNS policy is set to Default.

AnswerB

DNS resolution of svc.ns2.svc.cluster.local requires a Service named svc in namespace ns2; CoreDNS returns NXDOMAIN when that Service is absent. Since the pod's own namespace is irrelevant to a fully qualified cross-namespace lookup, a missing Service in ns2 is the most likely cause.

Why this answer

In Kubernetes, CoreDNS dynamically creates DNS records for Services using the format '<service-name>.<namespace>.svc.<cluster-domain>'. If a pod attempts to resolve the fully qualified domain name (FQDN) 'svc.ns2.svc.cluster.local' and fails, the most likely cause is that the Service named 'svc' does not exist in the namespace 'ns2', meaning no DNS record exists for it.

Exam trap

Candidates often confuse cross-namespace resolution issues. While it is true that a pod in 'ns1' cannot resolve a service in 'ns2' using only the short name 'svc', the stem specifies that the FQDN 'svc.ns2.svc.cluster.local' itself is failing to resolve. If the FQDN fails, the issue is that the target Service does not exist, not that the pod is using a short name.

How to eliminate wrong answers

Option A is wrong because setting the pod's DNS policy to 'None' means the pod uses no DNS configuration from the cluster, but the question states the pod is trying to resolve a specific DNS name, implying it has some DNS configuration; a 'None' policy would prevent any resolution, not just cross-namespace resolution. Option B is wrong because if the service 'svc' did not exist in namespace 'ns2', the DNS query for 'svc.ns2.svc.cluster.local' would return NXDOMAIN, but the question implies the issue is with the resolution attempt itself, not the existence of the service. Option D is wrong because the 'Default' DNS policy inherits the node's DNS resolution, which typically includes the cluster DNS server; this would allow resolution of FQDNs, so it would not cause a failure to resolve 'svc.ns2.svc.cluster.local'.

Practice this question →

73

Multi-Selectmedium

Which TWO of the following are valid ways to expose a Service externally in a Kubernetes cluster running on-premises (no cloud provider)?

Select 2 answers

A.LoadBalancer

B.NodePort

C.Ingress

D.ClusterIP

E.ExternalName

AnswersB, C

NodePort is a highly reliable, built-in method that allocates a static port (typically in the 30000-32767 range) across all cluster nodes. External traffic hitting any node's IP address on this designated port is automatically routed to the underlying target pods, making it a universally supported way to expose services.

Why this answer

NodePort (B) is correct because it exposes a Service on each node's IP at a static port in the 30000-32767 range, which works on any on-premises cluster without a cloud provider's load-balancer integration. Ingress (C) is correct because an Ingress resource plus an Ingress controller (e.g., NGINX, Traefik) provides HTTP/HTTPS routing from outside the cluster to internal Services, and it functions on-premises as long as the controller is deployed and reachable. LoadBalancer (A) is not valid here because it relies on a cloud provider's load-balancer implementation (or a bare-metal solution like MetalLB) to allocate an external IP, which is absent in a plain on-premises cluster.

ClusterIP (D) only provides an internal virtual IP reachable within the cluster, so it does not expose the Service externally. ExternalName (E) merely returns a CNAME DNS record pointing to an external hostname and does not expose a Service running in the cluster.

Exam trap

The trap here is that candidates often assume Ingress is not a valid external exposure method because it is not a Service type, but the question asks for 'valid ways to expose a Service externally,' and Ingress achieves this by routing external traffic to internal Services, making it a correct answer alongside NodePort.

Practice this question →

74

Multi-Selectmedium

Which two of the following are correct statements about EndpointSlices?

Select 2 answers

A.EndpointSlices are only used for services of type LoadBalancer.

B.EndpointSlices replace the Endpoints resource entirely.

C.EndpointSlices are automatically created by the EndpointSlice controller.

D.EndpointSlices are an alpha feature and must be enabled via feature gate.

E.EndpointSlices can contain up to 100 endpoints per slice by default.

AnswersC, E

This is correct. The EndpointSlice controller runs inside the kube-controller-manager and automatically watches Services with selectors and the Pods that match those selectors. Whenever a matching Pod is created, updated, or removed, the controller creates, updates, or deletes the appropriate EndpointSlice objects. This automation means administrators never manually create EndpointSlices; they are entirely controller-managed.

Why this answer

Option C is correct because the EndpointSlice controller in the Kubernetes control plane (kube-controller-manager) automatically creates and manages EndpointSlice objects for Services that have a selector, keeping them in sync with the matching Pods. Option E is correct because each EndpointSlice is limited to a default maximum of 100 endpoints, a value controlled by the --max-endpoints-per-slice flag on the kube-controller-manager, which improves scalability and reduces update churn compared to the single Endpoints object. Option A is wrong because EndpointSlices back Services of all types with selectors (ClusterIP, NodePort, LoadBalancer, and headless), not only LoadBalancer.

Option B is wrong because EndpointSlices do not entirely replace the Endpoints resource; the legacy Endpoints API still exists and is maintained for compatibility, with EndpointSlices serving as the more scalable alternative. Option D is wrong because EndpointSlices graduated to stable (GA) in Kubernetes 1.21, so they are no longer an alpha feature requiring a feature gate.

Exam trap

The trap here is that candidates often confuse the deprecated Endpoints resource with EndpointSlices, assuming EndpointSlices are still alpha or require feature gates, when in fact they are GA and automatically managed by the controller since Kubernetes v1.21.

Practice this question →

75

MCQhard

You have an Ingress resource with a TLS section specifying a secret named 'tls-secret'. The certificate in 'tls-secret' is expired. What happens when a client connects via HTTPS to the Ingress host?

A.TLS handshake succeeds but the client receives a warning about the expired certificate

B.The Ingress controller returns an error and refuses to terminate TLS

C.The Ingress controller automatically renews the certificate

D.The secret is ignored and HTTP is used instead

AnswerA

When an Ingress controller loads a TLS secret, it does not validate the expiration date of the certificate during the configuration phase. It will successfully bind the certificate to the listener and complete the TLS handshake with clients. However, because the certificate's validity period has passed, the client's browser or TLS library will flag it as untrusted and display an expiration warning.

Why this answer

When a client connects via HTTPS to an Ingress host with an expired TLS certificate, the Ingress controller (e.g., NGINX) still terminates the TLS handshake successfully because TLS termination does not validate certificate expiration at the server side. The expired certificate is presented to the client, and the client's browser or tool (e.g., curl) will show a warning about the expired certificate but the connection proceeds unless the client is configured to reject expired certificates. The Ingress controller does not enforce certificate validity; it only serves the configured secret.

Exam trap

The trap here is that candidates assume the Ingress controller validates certificate expiration and would refuse the connection, but in reality, TLS certificate expiration is only enforced by the client, not the server.

How to eliminate wrong answers

Option B is wrong because the Ingress controller does not validate certificate expiration; it terminates TLS regardless of the certificate's validity, so it does not return an error or refuse the handshake. Option C is wrong because the Ingress controller has no built-in mechanism to automatically renew certificates; renewal must be handled externally (e.g., cert-manager or manual update). Option D is wrong because the TLS secret is not ignored; the Ingress controller uses the configured secret for TLS termination, and the connection uses HTTPS, not HTTP, even if the certificate is expired.

Practice this question →

Page 1 of 2 · 131 questions totalNext →

Ready to test yourself?

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

Start 20-question session