CCNA Cka Services Networking Questions — Page 2 of 2

MCQhard

A Kubernetes cluster uses kube-proxy in iptables mode. A Service named 'web-svc' of type ClusterIP has three endpoints: pod A (10.244.1.5:8080), pod B (10.244.2.6:8080), and pod C (10.244.3.7:8080). A client pod repeatedly sends requests to the Service's ClusterIP. The administrator observes that all requests from a single client pod are being routed to pod A, even though pod B and pod C are healthy. Which of the following is the most likely explanation?

A.kube-proxy in iptables mode uses random selection for each packet, so the client should see distribution across all endpoints; the observed behavior indicates a bug in kube-proxy.

B.The client pod is using a persistent HTTP connection, and the Service is using IPVS mode with a least-connections algorithm, which sticks to one backend.

C.The endpoints for pod B and pod C are not ready, so kube-proxy only routes to pod A; the administrator should check readiness probes.

D.The Service has sessionAffinity set to ClientIP, which causes kube-proxy to route all requests from the same client IP to the same endpoint for the duration of the session affinity timeout.

AnswerD

When sessionAffinity is set to ClientIP, kube-proxy implements client IP-based session affinity, directing all requests from a given client IP to the same backend pod for the configured timeout (default 3 hours). This exactly matches the scenario where a single client pod's requests all go to pod A. It is a common configuration for stateful applications.

Why this answer

The most likely explanation is that the Service has sessionAffinity set to ClientIP. This setting makes kube-proxy route all requests from a particular client IP to the same backend pod for a configurable duration. Since the client pod's IP is constant, all its requests go to pod A.

This is a deliberate feature for session persistence, not a load-balancing bug.

Exam trap

The trap here is assuming that iptables mode always distributes evenly across endpoints, overlooking the possibility of session affinity being enabled.

Practice this question →

MCQmedium

You have a Service named 'my-service' in namespace 'ns1'. Another pod in namespace 'ns2' needs to resolve 'my-service' using DNS. What FQDN should the pod use?

A.my-service.svc.cluster.local

B.my-service.cluster.local

C.my-service.ns1.svc.cluster.local

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

AnswerC

This is the correct Fully Qualified Domain Name (FQDN) for a Kubernetes service. It adheres to the standard format: `<service-name>.<namespace-name>.svc.<cluster-domain>`. Here, `my-service` is the service name, `ns1` is its namespace, `svc` denotes it as a service, and `cluster.local` is the default cluster domain. This FQDN provides an unambiguous and universally resolvable address for the service from any pod within the cluster, regardless of the querying pod's own namespace.

Why this answer

Kubernetes DNS resolves services using the FQDN format `<service>.<namespace>.svc.cluster.local`. Since the pod in namespace 'ns2' needs to resolve 'my-service' which resides in namespace 'ns1', the FQDN must include the target namespace 'ns1' to perform a cross-namespace DNS lookup. Omitting the namespace would default to the pod's own namespace, which would fail to resolve the service.

Exam trap

The trap here is that candidates often forget to include the namespace in the FQDN for cross-namespace service resolution, assuming that the default search path will find the service, but it only searches the pod's own namespace first and will not resolve a service in a different namespace without the explicit namespace qualifier.

How to eliminate wrong answers

Option A is wrong because it omits the namespace, so the DNS query would default to the pod's own namespace (ns2), not ns1, and would not resolve the service. Option B is wrong because it uses the incorrect domain suffix 'cluster.local' without the 'svc' subdomain; Kubernetes DNS records for services are always under 'svc.cluster.local', not directly under 'cluster.local'. Option D is wrong because it specifies namespace 'ns2', which is the pod's own namespace, not the namespace where the service actually exists (ns1); this would only work if the service were in ns2.

Practice this question →

MCQmedium

A NetworkPolicy named 'deny-all' has only a podSelector matching all pods and no rules. What is the effect?

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

B.Allows all traffic because there are no explicit deny rules

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

D.Denies all egress traffic from all pods in the namespace

AnswerC

A NetworkPolicy with an empty `podSelector: {}` targets all pods within its namespace. When no `ingress` rules are explicitly defined, or an empty `ingress: []` array is present, and `policyTypes` implicitly defaults to `["Ingress"]`, the policy effectively denies all incoming network connections to these selected pods. This creates a secure-by-default posture for ingress traffic across the entire namespace, preventing any external or internal pod-to-pod communication unless explicitly allowed by another policy.

Why this answer

A NetworkPolicy with a podSelector matching all pods and no rules defaults to denying all ingress traffic because the policy's empty `ingress` rules array means no traffic is allowed. This implements a default-deny ingress behavior for the selected pods, as Kubernetes NetworkPolicy rules are whitelist-based: any traffic not explicitly allowed is denied.

Exam trap

The trap here is that candidates assume an empty policy has no effect, but in Kubernetes, a NetworkPolicy with no rules creates a default-deny for the selected direction (ingress or egress), which is a common point of confusion in the CKA exam.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy does not require at least one rule to take effect; an empty rules array still creates a policy that denies all ingress traffic. Option B is wrong because NetworkPolicy does not have implicit allow rules; it operates on a whitelist model where no rules means no traffic is permitted. Option D is wrong because this policy has no `egress` rules specified, so it does not affect egress traffic; egress is only denied if an egress rule is present or if a separate egress policy is applied.

Practice this question →

MCQmedium

Which component is responsible for implementing the NetworkPolicy rules?

A.CoreDNS

B.kube-controller-manager

C.kube-proxy

D.CNI plugin

AnswerD

The correct answer is the CNI plugin. The Container Network Interface plugin manages pod networking and, depending on the implementation (e.g., Calico, Cilium, Weave, or Antrea), also enforces NetworkPolicy by programming dataplane rules. When a NetworkPolicy is created or updated, the CNI plugin receives the pod metadata and translates the allow/deny rules into iptables, eBPF, or other forwarding constructs. Without a CNI plugin that supports NetworkPolicy, the rules are stored by the API server but have no effect on traffic.

Why this answer

NetworkPolicy rules are enforced by the Container Network Interface (CNI) plugin, not by kube-proxy or any other Kubernetes control plane component. The CNI plugin (e.g., Calico, Cilium, Weave Net) implements the actual network policy by programming iptables, eBPF, or other data-plane mechanisms to allow or deny traffic between pods based on the policy selectors and rules defined in the NetworkPolicy resource.

Exam trap

The trap here is that candidates often confuse kube-proxy's role in service traffic with network policy enforcement, but kube-proxy only handles load balancing for Services, not the pod-to-pod access control defined by NetworkPolicy.

How to eliminate wrong answers

Option A is wrong because CoreDNS is the cluster DNS resolver, responsible for service discovery and name resolution, not for enforcing network traffic policies. Option B is wrong because kube-controller-manager runs controllers like the Node Controller and Replication Controller, but it does not handle packet filtering or network policy enforcement. Option C is wrong because kube-proxy implements service load balancing (via iptables, IPVS, or userspace mode) and handles cluster IP traffic, but it does not enforce NetworkPolicy rules; those are implemented by the CNI plugin at the pod network level.

Practice this question →

MCQeasy

You want to debug a Service that is not reachable. Which kubectl command can you use to forward a local port to a pod in the Service?

A.kubectl expose deployment my-deployment --type=NodePort

B.kubectl port-forward svc/my-service 8080:80

C.kubectl exec -it my-pod -- curl localhost:80

D.kubectl proxy

AnswerB

kubectl port-forward svc/my-service 8080:80 is the correct command because it establishes a secure, temporary tunnel from your local machine's port 8080 to port 80 on a pod backing the specified my-service. This allows you to directly access the service from your local machine, bypassing any external network configurations or ingress controllers. It's an ideal method for debugging an unreachable service by testing its internal functionality and connectivity directly.

Why this answer

`kubectl port-forward svc/my-service 8080:80` creates a local TCP tunnel from port 8080 on your workstation to port 80 on a pod selected by the Service `my-service`. This allows you to reach the Service's backend pod directly without exposing it externally, which is a standard debugging technique for testing connectivity to a Service that appears unreachable.

Exam trap

The trap here is that candidates may confuse `kubectl port-forward` with `kubectl expose` or `kubectl proxy`, thinking any command that 'exposes' or 'proxies' can forward a local port, but only `port-forward` directly creates a local-to-pod tunnel for debugging a specific Service endpoint.

How to eliminate wrong answers

Option A is wrong because `kubectl expose deployment my-deployment --type=NodePort` creates a new Service or modifies an existing one to expose it via a NodePort, but it does not forward a local port to a pod; it changes the Service type to make it externally accessible on a node port, which is not a debugging port-forward command. Option C is wrong because `kubectl exec -it my-pod -- curl localhost:80` runs a command inside a specific pod to test connectivity from within the pod itself, but it does not forward a local port from your workstation to the pod; it tests the pod's internal loopback, not the Service's reachability from outside. Option D is wrong because `kubectl proxy` starts a proxy server that provides access to the Kubernetes API server, not to individual pods or Services; it does not forward a local port to a pod in a Service.

Practice this question →

MCQmedium

Which annotation is commonly used with ExternalDNS to specify the DNS hostname for a Service?

A.service.beta.kubernetes.io/load-balancer-dns

B.external-dns.alpha.kubernetes.io/hostname

C.dns.alpha.kubernetes.io/hostname

D.kubernetes.io/ingress.class

AnswerB

This is the canonical annotation ExternalDNS watches on Services and Ingresses. Its value is a comma-separated list of DNS names that ExternalDNS will provision records for, using the resource's external IP or hostname as the target. The alpha segment of the prefix signals that the annotation's schema may evolve, but this key remains the standard way to explicitly request a DNS record.

Why this answer

`external-dns.alpha.kubernetes.io/hostname` is the annotation used by the ExternalDNS project to specify the desired DNS hostname for a Kubernetes Service or Ingress. ExternalDNS watches resources with this annotation and synchronizes the DNS records (e.g., A or CNAME) with a configured DNS provider like AWS Route53 or Google Cloud DNS.

Exam trap

The trap here is that candidates confuse the `external-dns.alpha.kubernetes.io/hostname` annotation with the similar-sounding but non-existent `dns.alpha.kubernetes.io/hostname`, or they mistakenly associate `service.beta.kubernetes.io/load-balancer-dns` with DNS hostname configuration, when in fact it is not a real annotation in Kubernetes.

How to eliminate wrong answers

Option A is wrong because `service.beta.kubernetes.io/load-balancer-dns` is not a standard annotation; the correct annotation for specifying a custom DNS name on a Service of type LoadBalancer is `external-dns.alpha.kubernetes.io/hostname`. Option C is wrong because `dns.alpha.kubernetes.io/hostname` is not a recognized annotation in Kubernetes or ExternalDNS; the correct prefix is `external-dns.alpha.kubernetes.io`. Option D is wrong because `kubernetes.io/ingress.class` is used to specify the Ingress controller class (e.g., nginx, haproxy) for an Ingress resource, not for DNS hostname configuration with ExternalDNS.

Practice this question →

MCQeasy

Which Kubernetes Service type exposes the Service on a static port on each Node's IP address, allowing external access without a LoadBalancer?

A.LoadBalancer

B.ClusterIP

C.ExternalName

D.NodePort

AnswerD

NodePort exposes the service externally by reserving a static port (typically in the 30000-32767 range) on every cluster node's IP address. Any traffic sent to this designated port on any node is automatically routed to the underlying pods via kube-proxy, providing a direct mechanism for external access.

Why this answer

A NodePort Service exposes the Service on a static port (in the range 30000-32767) on every Node's IP address. This allows external traffic to reach the Service by targeting any cluster node's IP and the assigned NodePort, without requiring a cloud LoadBalancer. The kube-proxy component on each node creates iptables or IPVS rules to forward traffic from that port to the corresponding ClusterIP Service and then to the selected Pods.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking a LoadBalancer is required for external access, but NodePort directly provides external access on each node's IP without any cloud provider dependency.

How to eliminate wrong answers

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

Practice this question →

MCQmedium

Which kube-proxy mode uses iptables rules to handle service traffic and is the default in many distributions?

A.userspace

B.ipvs

C.iptables

D.nftables

AnswerC

iptables mode is the default kube-proxy mode and uses a carefully constructed set of iptables rules (typically DNAT and REDIRECT) to handle Service traffic. For each Service and its endpoints, kube-proxy creates separate rules that are evaluated in a linear chain; the kernel rewrites the destination IP of a packet to one of the selected backend pod IPs. This mode operates entirely in kernel space, avoiding user-space copying while providing reliable and predictable behavior, although the linear rule traversal can introduce latency with thousands of Services.

Why this answer

The iptables mode is the default kube-proxy mode in many Kubernetes distributions, including kubeadm-based clusters. In this mode, kube-proxy watches the Kubernetes API server for Service and Endpoint changes and programs iptables rules in the kernel's netfilter framework to direct traffic to the appropriate backend Pods, providing efficient NAT-based load balancing without requiring a userspace proxy.

Exam trap

The trap here is that candidates often confuse the default kube-proxy mode with the ipvs mode, which is more performant but requires explicit configuration, or mistakenly think nftables is a supported mode in current Kubernetes releases.

How to eliminate wrong answers

Option A is wrong because the userspace mode is an older, deprecated kube-proxy mode that runs a userspace proxy process to handle service traffic, which introduces higher latency and is not the default in modern distributions. Option B is wrong because the ipvs mode uses the IPVS kernel module for load balancing and is not the default in most distributions; it must be explicitly enabled via the `--proxy-mode=ipvs` flag. Option D is wrong because nftables is a modern replacement for iptables in Linux, but kube-proxy does not support an nftables mode as of Kubernetes 1.28; it remains an experimental or future feature.

Practice this question →

MCQmedium

You create a Service with clusterIP: None. What is this called and what is its purpose?

A.NodePort Service; it exposes on node ports.

B.ExternalName Service; it maps to an external DNS name.

C.ClusterIP Service; it provides a stable IP.

D.Headless Service; it allows direct pod-to-pod DNS resolution.

AnswerD

A Service with `clusterIP: None` is a headless Service: the DNS lookup returns multiple A records, one for each ready endpoint, instead of a single virtual IP. This allows clients to discover and connect directly to individual pods, enabling pod-to-pod DNS resolution and client-side load balancing without kube-proxy.

Why this answer

A Service with `clusterIP: None` is called a Headless Service. Its purpose is to allow direct pod-to-pod DNS resolution by returning the IP addresses of the backing pods (via DNS A/AAAA records) rather than a single virtual ClusterIP, enabling stateful applications like databases to discover individual pod endpoints.

Exam trap

The trap here is that candidates confuse the absence of a ClusterIP with a different Service type (like NodePort or ExternalName), not realizing that `clusterIP: None` specifically creates a Headless Service for direct pod DNS resolution.

How to eliminate wrong answers

Option A is wrong because a NodePort Service exposes a Service on a static port on each node's IP, not by setting `clusterIP: None`. Option B is wrong because an ExternalName Service maps to an external DNS name via a CNAME record, not by omitting the ClusterIP. Option C is wrong because a ClusterIP Service provides a stable virtual IP for load balancing, which is explicitly disabled when `clusterIP: None` is set.

Practice this question →

MCQmedium

A developer asks you to create a Service that resolves to an external database at 'db.example.com'. Which Service type should you use?

A.ExternalName

B.LoadBalancer

C.NodePort

D.ClusterIP

AnswerA

ExternalName services map a Kubernetes service directly to an external DNS name by returning a CNAME record from the cluster's internal DNS provider (like CoreDNS). This allows pods to reference external resources, such as a managed database, using a consistent internal service name without proxying any traffic through the cluster.

Why this answer

An ExternalName Service type maps a Service to a DNS name (e.g., 'db.example.com') by returning a CNAME record, allowing pods to resolve the Service name to an external endpoint without a proxy or selector. This is the only Service type that directly resolves to an external DNS name without requiring endpoints or a backend selector.

Exam trap

The trap here is that candidates often confuse ExternalName with a regular ClusterIP Service that has an external endpoint, but ExternalName is the only type that purely provides DNS-based resolution without any proxy or selector.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it exposes the Service externally via a cloud load balancer, but it still requires a selector and endpoints to route traffic, not a DNS name. Option C (NodePort) is wrong because it exposes the Service on a static port on each node's IP, but it also requires a selector and internal endpoints, not an external DNS resolution. Option D (ClusterIP) is wrong because it provides a virtual IP within the cluster for internal traffic only, and it requires a selector to route to pods, not an external DNS name.

Practice this question →

MCQmedium

Which annotation is commonly used with the ExternalDNS project to manage DNS records for a Kubernetes service?

A.prometheus.io/scrape

B.external-dns.alpha.kubernetes.io/hostname

C.kubernetes.io/ingress.class

D.cert-manager.io/cluster-issuer

AnswerB

This is the standard annotation used by the ExternalDNS controller to dynamically provision DNS records in external providers like AWS Route53 or Cloudflare. When applied to a Service or Ingress resource, ExternalDNS reads this value to map the resource's public IP or hostname to the specified custom domain name.

Why this answer

The ExternalDNS project synchronizes exposed Kubernetes Services and Ingresses with DNS providers. The annotation `external-dns.alpha.kubernetes.io/hostname` is used to explicitly specify the DNS hostname that ExternalDNS should manage for a Service of type LoadBalancer or NodePort, overriding the default naming logic.

Exam trap

The trap here is that candidates confuse annotations used by different ecosystem projects (Prometheus, cert-manager, Ingress controllers) with those specific to ExternalDNS, leading them to pick a familiar but incorrect annotation.

How to eliminate wrong answers

Option A is wrong because `prometheus.io/scrape` is an annotation used by the Prometheus operator to indicate that a target should be scraped for metrics, not for DNS record management. Option C is wrong because `kubernetes.io/ingress.class` is an annotation used on Ingress resources to select the Ingress controller (e.g., nginx, haproxy), not for ExternalDNS. Option D is wrong because `cert-manager.io/cluster-issuer` is an annotation used by cert-manager to specify the ClusterIssuer for TLS certificate issuance, not for DNS record management.

Practice this question →

MCQmedium

Which kube-proxy mode uses IP Virtual Server (IPVS) for load balancing and supports more algorithms than the default mode?

A.ipvs

B.userspace

C.iptables

D.kube-proxy

AnswerA

IPVS (IP Virtual Server) is a Linux kernel module that provides high-performance L4 load balancing with dedicated scheduling algorithms. In kube-proxy's ipvs mode, the kernel creates IPVS virtual servers for each Service, supporting algorithms like round-robin, least-connection, and weighted scheduling directly in kernel space. This is the mode that specifically leverages IPVS for load balancing, avoiding the linear rule traversal and limited scheduling of iptables.

Why this answer

The IP Virtual Server (IPVS) mode in kube-proxy leverages the Linux kernel's IPVS module, which is built on the Netfilter framework and operates in the kernel space. Unlike the default iptables mode, IPVS supports a variety of load-balancing algorithms (e.g., round-robin, least-connection, source-hashing) and provides better scalability and performance for large clusters by using a hash table for service-to-endpoint mapping.

Exam trap

The trap here is that candidates often confuse the default mode (iptables) with the IPVS mode, or mistakenly think that kube-proxy itself is a mode, when in fact IPVS is a distinct mode that must be explicitly enabled via the `--proxy-mode=ipvs` flag.

How to eliminate wrong answers

Option B (userspace) is wrong because it is the legacy mode that proxies traffic in user space, leading to high latency and poor performance; it does not use IPVS. Option C (iptables) is wrong because it is the default mode that uses iptables rules for load balancing, which supports only random or round-robin selection via statistic modules and lacks the advanced scheduling algorithms of IPVS. Option D (kube-proxy) is wrong because it is the component itself, not a mode; the question asks for the mode that uses IPVS.

Practice this question →

MCQmedium

A pod is unable to resolve DNS names of services in other namespaces. Which DNS configuration is most likely missing?

A.CoreDNS is not deployed in the cluster.

B.The pod's dnsPolicy is set to 'Default'.

C.The pod is in a different namespace than the service.

D.The service does not have a ClusterIP assigned.

AnswerB

When a pod's dnsPolicy is configured as 'Default', it inherits the name resolution configuration of the hosting node rather than using the cluster's DNS service (CoreDNS). Consequently, the pod can resolve external internet domains but lacks the search paths and nameservers required to resolve internal Kubernetes service FQDNs across namespaces.

Why this answer

When a pod's `dnsPolicy` is set to `Default`, the pod inherits the node's DNS resolution configuration, which typically points to the host's `/etc/resolv.conf` and does not include the cluster's DNS service (CoreDNS). This prevents the pod from resolving service DNS names like `<service>.<namespace>.svc.cluster.local`, which are only resolvable via the cluster's DNS. Setting `dnsPolicy` to `ClusterFirst` (the default if not specified) ensures the pod uses CoreDNS for DNS queries, enabling cross-namespace service discovery.

Exam trap

The trap here is that candidates often assume DNS issues are always due to CoreDNS not running or a service misconfiguration, but the CKA exam tests the subtle behavior of `dnsPolicy` and how `Default` inherits the node's DNS, breaking cluster service resolution.

How to eliminate wrong answers

Option A is wrong because if CoreDNS were not deployed, no pod in the cluster would resolve service DNS names, but the question implies only this specific pod has the issue, so CoreDNS is likely present. Option C is wrong because being in a different namespace does not prevent DNS resolution; Kubernetes DNS uses the format `<service>.<namespace>.svc.cluster.local` to resolve services across namespaces. Option D is wrong because a service without a ClusterIP would not be reachable via DNS at all, but the question states the pod cannot resolve DNS names, implying the service exists and has a ClusterIP; the issue is with the pod's DNS configuration, not the service's IP assignment.

Practice this question →

MCQmedium

After creating a NetworkPolicy that selects pods with label 'role: db' and allows ingress on TCP port 3306 from pods with label 'role: api', you notice that pods with label 'role: db' are still reachable on port 3306 from pods without 'role: api' label. What is the most likely cause?

A.The NetworkPolicy is not in the same namespace as the pods.

B.The NetworkPolicy uses the wrong protocol.

C.The NetworkPolicy has an egress rule that overrides ingress.

D.The NetworkPolicy requires an explicit 'deny all' rule.

AnswerA

Kubernetes NetworkPolicy resources are strictly namespace-scoped. The podSelector defined within a policy only matches pods residing in the exact same namespace as the policy itself. If the policy is deployed in a different namespace than the target pods, it will fail to select them and have no effect on their traffic.

Why this answer

NetworkPolicies are namespaced resources. If the NetworkPolicy is created in a different namespace than the pods with label 'role: db', it will not apply to those pods. The policy must reside in the same namespace as the pods it targets; otherwise, the default behavior (allow all ingress) remains in effect for those pods.

Exam trap

The trap here is that candidates assume NetworkPolicies are cluster-scoped or automatically apply across namespaces, but they are namespaced resources and only affect pods in the same namespace unless explicitly using namespaceSelectors.

How to eliminate wrong answers

Option B is wrong because the question states the policy allows TCP port 3306, and the pods are reachable on that port; if the protocol were wrong (e.g., UDP), traffic would not match the rule, but the issue is that all traffic is allowed, not that a specific rule fails. Option C is wrong because egress rules do not override ingress rules; they are independent, and the absence of an egress rule does not affect ingress behavior. Option D is wrong because NetworkPolicies do not require an explicit 'deny all' rule; they are additive—if no policy selects a pod, all traffic is allowed, but if a policy selects the pod, only explicitly allowed traffic is permitted (implicit deny).

The problem here is that the policy is not being applied at all.

Practice this question →

Multi-Selectmedium

Which THREE components are part of the Gateway API?

Select 3 answers

A.Gateway

B.Service

C.Ingress

D.HTTPRoute

E.GatewayClass

AnswersA, D, E

Gateway is a core resource in the Gateway API that represents the point where external traffic enters the cluster. It defines one or more listeners specifying protocol, port, and hostname, and is bound to a GatewayClass that provides the underlying controller implementation. Gateways are typically managed by cluster operators, not application developers, and serve as the entrypoint for routing traffic to services via attached routes.

Why this answer

The Gateway API is a Kubernetes SIG-Network set of role-oriented, portable, and expressive routing resources, and its core object model consists of GatewayClass, Gateway, and route resources such as HTTPRoute. Option A, Gateway, is correct because it represents a deployed instance of a gateway (a data-plane load balancer/proxy) that listeners and routes attach to. Option D, HTTPRoute, is correct because it is one of the standard route types that defines HTTP/HTTPS routing rules and binds to a Gateway listener.

Option E, GatewayClass, is correct because it is the cluster-scoped template that defines the controller implementation and configuration for Gateways, analogous to IngressClass. Option B, Service, is not part of the Gateway API itself; it is a core Kubernetes resource used for exposing pods and may be referenced as a backend, but it is not a Gateway API component. Option C, Ingress, is not part of the Gateway API; it is the older, separate Kubernetes Ingress resource that the Gateway API is intended to supersede.

Exam trap

In the CKA exam, candidates may confuse the older Ingress API with the newer Gateway API, mistakenly thinking Ingress is part of Gateway API or that Service is a routing resource within Gateway API.

Practice this question →

MCQhard

You have a Service 'my-svc' with ClusterIP None (headless). You create a StatefulSet with 3 replicas and a headless Service. How do you reach individual pods?

A.Use the pod DNS name: <pod-name>.my-svc.<namespace>.svc.cluster.local

B.Use the Service name 'my-svc' which will round-robin between pods

C.Use the Service's ClusterIP (None) to reach all pods

D.You cannot reach individual pods directly; you must use the Service name

AnswerA

When a Service is configured as headless by setting clusterIP to None, CoreDNS automatically creates individual A or AAAA records for each backing Pod that matches the selector. These records are formatted as <pod-name>.<service-name>.<namespace>.svc.cluster.local, allowing clients to bypass the service proxy and resolve the direct IP address of a specific Pod. This mechanism is essential for stateful applications that require direct, addressable communication with individual cluster members.

Why this answer

In a headless Service (ClusterIP: None), Kubernetes creates DNS A/AAAA records for each pod in a StatefulSet using the pattern <pod-name>.<service-name>.<namespace>.svc.cluster.local. This allows direct, stable network identity for each pod, which is essential for stateful applications like databases that require consistent hostnames.

Exam trap

The trap here is that candidates often assume a Service always provides a virtual IP for load balancing, but a headless Service deliberately removes that abstraction to expose individual pod identities directly via DNS.

How to eliminate wrong answers

Option B is wrong because a headless Service (ClusterIP: None) does not perform load balancing or round-robin; it only provides DNS-based pod discovery without a virtual IP. Option C is wrong because the ClusterIP is explicitly set to 'None', meaning there is no ClusterIP to use for reaching pods; attempting to use it would fail. Option D is wrong because you can reach individual pods directly via their pod DNS names, which is the primary purpose of combining a headless Service with a StatefulSet.

Practice this question →

MCQeasy

Which NetworkPolicy rule will allow ingress traffic from pods with label 'role: frontend' in the same namespace?

A.ingress: - from: - podSelector: matchLabels: role: frontend

B.ingress: - from: - ipBlock: cidr: 0.0.0.0/0

C.egress: - to: - podSelector: matchLabels: role: frontend

D.ingress: - from: - namespaceSelector: matchLabels: role: frontend

AnswerA

The `from` section with a `podSelector` selects source pods by their labels, and because the selector is placed directly under `ingress`, it governs inbound traffic. This rule allows traffic only from pods in the same namespace that carry the label `role: frontend`, which is exactly the intended behavior. It correctly targets pod identity rather than IP ranges or namespace identity, making it the right choice.

Why this answer

A NetworkPolicy ingress rule with a `podSelector` matches pods in the same namespace as the policy. By specifying `matchLabels: role: frontend`, it allows inbound traffic from any pod in the same namespace that has that label, which is exactly what the question requires.

Exam trap

The trap here is that candidates often confuse `podSelector` (which selects pods in the same namespace) with `namespaceSelector` (which selects namespaces), or they mistakenly choose an egress rule when the question explicitly asks for ingress traffic.

How to eliminate wrong answers

Option B is wrong because `ipBlock: 0.0.0.0/0` allows ingress traffic from any IP address, not just from pods with the label `role: frontend`. Option C is wrong because it defines an `egress` rule (outbound traffic), not an ingress rule, and the question specifically asks for ingress traffic. Option D is wrong because `namespaceSelector` matches entire namespaces based on their labels, not pods within the same namespace; it would allow traffic from pods in any namespace that has the label `role: frontend`, which is broader and not restricted to the same namespace.

Practice this question →

MCQeasy

Which DNS record does CoreDNS create for a headless Service named 'headless-svc' in the namespace 'default'?

A.A records for each pod IP backing the Service

B.No DNS record

C.A CNAME record pointing to an external DNS

D.An A record for the Service IP (ClusterIP)

AnswerA

When a Service is configured as headless by setting spec.clusterIP to None, CoreDNS bypasses the creation of a single virtual IP record. Instead, it directly generates individual A or AAAA records mapping the Service's fully qualified domain name to the IP addresses of all ready backend pods selected by the Service. This allows clients to perform direct peer-to-peer communication or implement custom client-side load balancing.

Why this answer

CoreDNS creates A records for each pod IP backing a headless Service because headless Services (with clusterIP set to None) are designed to return pod IPs directly via DNS, rather than a single Service IP. For a headless Service named 'headless-svc' in the 'default' namespace, CoreDNS performs a DNS lookup that returns multiple A records, one for each ready pod endpoint, enabling direct pod-to-pod communication without load balancing.

Exam trap

The trap here is that candidates often assume headless Services create no DNS records or that they use a ClusterIP-based A record, but CoreDNS actually creates A records for each pod IP, not for a virtual Service IP, which is a key distinction for stateful applications.

How to eliminate wrong answers

Option B is wrong because CoreDNS does create DNS records for headless Services — specifically A records for each pod IP, not no records at all. Option C is wrong because headless Services do not use CNAME records to point to external DNS; CNAME records are used for external name resolution or Service aliases, not for headless Services. Option D is wrong because headless Services have no ClusterIP (set to None), so there is no A record for a Service IP; instead, A records are created for the individual pod IPs.

Practice this question →

MCQeasy

Which of the following is the default DNS name for a Service named 'api' in namespace 'production'?

A.api.production.cluster.local

B.api.production.svc.cluster.local

C.production.api.svc.cluster.local

D.api.svc.production.cluster.local

AnswerB

This is the canonical fully qualified Domain Name (FQDN) for a Service. For a Service named `api` in Namespace `production`, CoreDNS registers an A record at `api.production.svc.cluster.local` using the standard schema `<service-name>.<namespace>.svc.<cluster-domain>`. Pods inside the cluster can resolve this name to the Service's ClusterIP, making it the default and correct Service DNS name.

Why this answer

In Kubernetes, the default DNS name for a Service follows the pattern `<service>.<namespace>.svc.cluster.local`. For a Service named 'api' in namespace 'production', this resolves to `api.production.svc.cluster.local`. The `svc` subdomain is a fixed component that distinguishes Service DNS records from Pod DNS records, and `cluster.local` is the default cluster domain.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or confuse the order of namespace and service name, leading them to choose options like A or C, which omit or misplace the `svc` component.

How to eliminate wrong answers

Option A is wrong because it omits the required `svc` subdomain, which is part of the standard DNS schema for Services. Option C is wrong because it reverses the order of the Service name and namespace, placing the namespace before the Service name, which does not match the Kubernetes DNS specification. Option D is wrong because it places `svc` after the namespace and before the cluster domain, whereas the correct order is `<service>.<namespace>.svc.cluster.local`.

Practice this question →

MCQmedium

You want to expose an application running in the cluster on a public IP address. Which Service type should you use?

A.NodePort

B.LoadBalancer

C.ExternalName

D.ClusterIP

AnswerB

LoadBalancer is the Service type that provisions an external load balancer—often via your cloud provider's API—and assigns it a stable public IP address. It automatically routes incoming traffic to the Service's endpoints and performs health checks, so it is the direct way to expose an application to the internet without manual configuration. This is exactly what is required when "exposing an application running in the cluster" means giving it a routable external endpoint.

Why this answer

The LoadBalancer service type provisions an external load balancer (e.g., from a cloud provider) that assigns a public IP address to the service, directing external traffic to the application pods. This is the correct choice when you need a publicly accessible IP address without manual node-level configuration.

Exam trap

The trap here is that candidates often confuse NodePort with a public IP solution, forgetting that NodePort only exposes the service on node IPs, which are typically private and require an additional load balancer or ingress for public access.

How to eliminate wrong answers

Option A (NodePort) is wrong because it exposes the service on a static port on each node's IP address, but the node IPs are often private or not directly accessible from the internet without additional routing or a load balancer. Option C (ExternalName) is wrong because it maps the service to an external DNS name (via CNAME records) and does not expose any internal pods or provide a public IP address. Option D (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP address, which is unreachable from outside the cluster.

Practice this question →

MCQhard

You have a NetworkPolicy that denies all ingress traffic by default, and you want to allow traffic only from pods with label 'app: monitoring' in the same namespace. What should the policy spec look like?

A.ingress: - from: - ipBlock: cidr: 0.0.0.0/0

B.ingress: - from: - podSelector: matchLabels: app: monitoring - namespaceSelector: matchLabels: name: my-namespace

C.ingress: - from: - podSelector: matchLabels: app: monitoring

D.ingress: - from: - namespaceSelector: matchLabels: app: monitoring

AnswerC

This is the correct configuration because omitting the namespaceSelector entirely defaults the scope of the podSelector to the same namespace where the NetworkPolicy is applied. It successfully permits ingress traffic exclusively from pods labeled app: monitoring within the local namespace. This precisely satisfies the requirement of isolating traffic to specific local pods while maintaining the default-deny rule for everything else.

Why this answer

A NetworkPolicy with an ingress rule using only a podSelector allows traffic from pods matching the specified labels within the same namespace. Since the default policy denies all ingress traffic, this rule explicitly permits traffic from pods labeled 'app: monitoring' in the same namespace, which satisfies the requirement.

Exam trap

The trap here is that candidates often add a namespaceSelector unnecessarily, thinking it is required to restrict to the same namespace, when in fact omitting the namespaceSelector automatically limits the rule to the policy's namespace.

How to eliminate wrong answers

Option A is wrong because an ipBlock rule with 0.0.0.0/0 would allow traffic from all IP addresses, which contradicts the requirement to restrict traffic to only pods with label 'app: monitoring'. Option B is wrong because it includes a namespaceSelector, which would allow traffic from pods with label 'app: monitoring' in any namespace matching the namespace label 'name: my-namespace', not just the same namespace. Option D is wrong because it uses only a namespaceSelector, which would allow traffic from all pods in namespaces with label 'app: monitoring', regardless of pod labels, thus not restricting to pods with label 'app: monitoring'.

Practice this question →

Multi-Selecthard

Which THREE components are part of the Gateway API resource model? (Select THREE)

Select 3 answers

A.Gateway

B.GatewayClass

C.LoadBalancer

D.HTTPRoute

E.Ingress

AnswersA, B, D

Gateway is a core Gateway API resource, representing a specific load-balancing instance that defines listeners, protocols and TLS settings, and binds routes to underlying infrastructure. It sits alongside GatewayClass and HTTPRoute in the role-oriented model.

Why this answer

The Gateway API resource model is built around three primary role-oriented resources: GatewayClass, Gateway, and Route objects such as HTTPRoute. Option B (GatewayClass) is correct because it defines a cluster-scoped template that identifies the controller implementing the gateway, analogous to an IngressClass but for the Gateway API. Option A (Gateway) is correct because it represents a specific instance of infrastructure (a load balancer or proxy) provisioned by a GatewayClass controller, and it defines listeners for protocols like HTTP, HTTPS, or TLS.

Option D (HTTPRoute) is correct because Route resources attach to a Gateway's listeners and specify how traffic is matched and forwarded to backend Services, with HTTPRoute being the HTTP/HTTPS-specific route type. Option C (LoadBalancer) is not part of the Gateway API resource model; it is a Kubernetes Service type (spec.type: LoadBalancer) used for exposing workloads, not a Gateway API kind. Option E (Ingress) is the older, separate Kubernetes API for HTTP routing and is not a Gateway API resource, though Gateway API is designed as its successor.

Exam trap

The CKA exam often tests the distinction between the older Ingress API and the newer Gateway API, and candidates mistakenly select Ingress as a component of Gateway API, when in fact Gateway API is a separate, more expressive API family that includes GatewayClass, Gateway, and route resources like HTTPRoute.

Practice this question →

MCQmedium

A pod cannot resolve a Service name 'my-svc' in the same namespace. The DNS pod is running. What is a likely cause?

A.The kube-proxy is not running

B.The Service type is ExternalName

C.The Service 'my-svc' does not exist

D.The pod is in a different namespace

AnswerC

CoreDNS generates DNS records only for Service objects that actually exist. If no Service named my-svc exists in the pod's namespace, the query for my-svc.<namespace>.svc.cluster.local returns NXDOMAIN, which is exactly the failure described. Because the short name my-svc is expanded using the pod's search domains to include the namespace, a missing Service object means no A record can be synthesized. Running kubectl get svc -n <namespace> to confirm that the Service is present is the correct first troubleshooting step.

Why this answer

If the Service 'my-svc' does not exist, the CoreDNS pod will not have an A/AAAA record for it, and DNS resolution will fail with NXDOMAIN. The pod's DNS resolver queries the cluster's DNS service (typically CoreDNS) for the Service name; if no matching Service object is defined, no DNS record is created, and the name cannot be resolved regardless of other components being healthy.

Exam trap

The trap here is that candidates often confuse DNS resolution issues with network connectivity issues, incorrectly attributing the failure to kube-proxy or Service type, when the root cause is simply that the Service object does not exist and thus has no DNS record.

How to eliminate wrong answers

Option A is wrong because kube-proxy handles traffic forwarding to Service endpoints, not DNS resolution; a missing or misconfigured kube-proxy would cause connectivity failures (e.g., connection refused or timeout) but would not prevent DNS name resolution itself. Option B is wrong because an ExternalName Service type returns a CNAME record pointing to an external DNS name, which would still resolve successfully (to the external name) and not cause a failure to resolve 'my-svc' in the same namespace. Option D is wrong because the question explicitly states the pod and Service are in the same namespace; even if they were in different namespaces, DNS resolution would still work by using the fully qualified domain name (e.g., 'my-svc.<namespace>.svc.cluster.local'), so being in a different namespace would not prevent resolution of a Service that exists.

Practice this question →

MCQeasy

An administrator creates a NetworkPolicy in namespace 'app' with the following YAML. Which statement is true about the policy? apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress

A.The policy denies all ingress traffic to no pods because no podSelector is specified.

B.The policy denies all egress traffic from all pods in the 'app' namespace.

C.The policy denies all ingress traffic to all pods in the 'app' namespace.

D.The policy allows all ingress traffic to all pods in the 'app' namespace.

AnswerC

An empty `podSelector` targets all pods in the 'app' namespace, and because the policy defines `Ingress` in its `policyTypes` but contains no allowed ingress rules, it acts as a default-deny policy. This effectively blocks all incoming traffic to every pod in that namespace.

Why this answer

The NetworkPolicy uses an empty `podSelector: {}`, which selects all pods in the namespace, and specifies `policyTypes: [Ingress]` with no ingress rules. By default, Kubernetes NetworkPolicy denies all ingress traffic that is not explicitly allowed, so this policy effectively blocks all incoming traffic to every pod in the 'app' namespace.

Exam trap

The trap here is that candidates often misinterpret an empty `podSelector: {}` as selecting no pods, when in fact it selects all pods in the namespace, leading them to incorrectly choose option A.

How to eliminate wrong answers

Option A is wrong because an empty `podSelector: {}` selects all pods, not no pods; it is a common misconception that an empty selector matches nothing, but in Kubernetes it matches everything. Option B is wrong because the policy only specifies `policyTypes: [Ingress]`, so it has no effect on egress traffic; egress traffic remains unrestricted unless an egress rule is defined. Option D is wrong because the policy has no ingress rules, and the default behavior of a NetworkPolicy with `policyTypes: [Ingress]` is to deny all ingress traffic, not allow it.

Practice this question →

100

MCQhard

You have three pods selected by a service. One pod is in 'CrashLoopBackOff' state. How does the service's endpoints behave?

A.The service removes all endpoints to avoid partial connectivity

B.The service endpoints include only the two healthy pods

C.The service endpoints include the unhealthy pod but traffic is not routed to it

D.The service includes all three pods in its endpoints

AnswerB

The Endpoints object for a Service contains only the IP addresses of Pods that are currently Ready — that is, passing their readiness probes. Since two of the three Pods are healthy, the Service's Endpoints (or EndpointSlices) list exactly those two Pod IPs, and the ClusterIP load balances only to them.

Why this answer

B is correct because Kubernetes services use endpoints (or endpoint slices) to track which pods are ready to receive traffic. The readiness probe determines pod readiness; a pod in CrashLoopBackOff fails its readiness probe, so it is removed from the service's endpoints. Only the two healthy pods remain in the endpoint list, ensuring traffic is routed only to healthy pods.

Exam trap

CNCF often tests the misconception that a service will still include an unhealthy pod in its endpoints but simply not route traffic to it, whereas in reality the endpoint controller removes the pod entirely from the endpoint list based on readiness probe failures.

How to eliminate wrong answers

Option A is wrong because the service does not remove all endpoints; it only removes the unhealthy pod, preserving connectivity via the healthy pods. Option C is wrong because the service endpoints do not include the unhealthy pod; the endpoint controller removes pods that fail readiness probes, so the pod is not present in the endpoint list at all. Option D is wrong because the service does not include all three pods; the CrashLoopBackOff pod is excluded from endpoints due to its failed readiness probe.

Practice this question →

101

MCQeasy

Which of the following is a core component of the Gateway API?

A.VirtualService

B.GatewayClass

C.IngressController

D.ServiceEntry

AnswerB

GatewayClass is a core, cluster-scoped resource in the Kubernetes Gateway API that defines a template and set of common configurations for a class of Gateways. Similar to how IngressClass functions for Ingress resources, it links the declarative API to a specific controller implementation that manages the underlying data plane infrastructure.

Why this answer

The Gateway API is a Kubernetes SIG-Network project that defines a set of resources for configuring service networking. Its core components are GatewayClass, Gateway, and HTTPRoute (or TCPRoute, etc.). GatewayClass is analogous to IngressClass in the Ingress API, defining a class of gateways that a controller can implement, making it a foundational core component.

Exam trap

The trap here is that candidates confuse the Gateway API's core resources (GatewayClass, Gateway, HTTPRoute) with similar-sounding resources from service meshes like Istio (VirtualService, ServiceEntry) or the older Ingress API (IngressController), leading them to select a non-core component.

How to eliminate wrong answers

Option A is wrong because VirtualService is a custom resource defined by the Istio project for traffic routing within a service mesh, not a core component of the Kubernetes Gateway API. Option C is wrong because IngressController is a generic term for the software that implements the Ingress API (e.g., NGINX Ingress Controller), not a resource defined by the Gateway API. Option D is wrong because ServiceEntry is an Istio resource used to register external services into the mesh, unrelated to the Gateway API's core resources.

Practice this question →

102

Multi-Selecthard

Which FOUR are correct ways to configure a default deny all ingress traffic NetworkPolicy? (Choose 4)

Select 4 answers

A.A NetworkPolicy with podSelector: {} and an ingress rule with from: []

B.A NetworkPolicy with podSelector: {} and an ingress rule with from: [{}]

C.A NetworkPolicy with podSelector: {} and ingress: []

D.A NetworkPolicy with podSelector: {} and no rules at all (only metadata and spec)

E.A NetworkPolicy with podSelector: {} and no ingress rules

AnswersA, C, D, E

An empty from list does not match any sources, but the rule itself is an ingress rule; however, it still results in no allowed traffic, but it's not a default deny pattern (it's an allow rule that allows nothing). The classic default deny has no ingress rules.

Why this answer

Option C is correct because `podSelector: {}` selects all pods in the namespace and `ingress: []` defines an empty ingress rule set, which denies all ingress traffic to those pods. Option D is correct because a NetworkPolicy with `podSelector: {}` and no rules at all (only metadata and spec) has no ingress rules, so it isolates all selected pods and denies all ingress by default. Option E is correct because omitting the `ingress` field entirely is equivalent to having an empty ingress rule set, which denies all ingress traffic to the selected pods.

Option A is also correct: an ingress rule with `from: []` contains an empty list of sources, which matches no sources and therefore allows no ingress traffic; the presence of the rule does not permit traffic because no source matches. Option B is incorrect because `from: [{}]` contains an empty object, which matches all sources and therefore allows all ingress traffic, the opposite of deny all.

Exam trap

The exam often tests the subtle difference between `from: []` (empty array, denies all) and `from: [{}]` (empty object, allows all), as well as the fact that a NetworkPolicy with no rules at all (only podSelector) still enforces a default deny, which candidates may mistakenly think requires an explicit empty ingress list.

Practice this question →

103

MCQmedium

A cluster uses Flannel as the CNI plugin. Which of the following best describes Flannel's networking model?

A.It requires an external etcd to store network state.

B.It uses BGP to distribute routes across the cluster.

C.It provides network policies with full support for ingress and egress rules.

D.It assigns a /24 subnet to each node and uses VXLAN encapsulation.

AnswerD

By default, Flannel allocates a unique /24 IPv4 subnet from a larger pre-configured cluster CIDR to each node and encapsulates inter-node pod traffic using VXLAN (Virtual Extensible LAN) at Layer 2 over Layer 3, facilitating seamless overlay communication.

Why this answer

Flannel's default networking model assigns a /24 subnet to each node and uses VXLAN encapsulation to create an overlay network. This allows pods on different nodes to communicate without requiring changes to the underlying physical network, as VXLAN tunnels traffic between nodes using UDP encapsulation.

Exam trap

The trap here is that candidates confuse Flannel's simple overlay model with more feature-rich CNI plugins like Calico, assuming Flannel supports BGP routing or network policies, when in fact it only provides basic pod-to-pod connectivity via VXLAN encapsulation.

How to eliminate wrong answers

Option A is wrong because Flannel does not require an external etcd; it stores network state in the Kubernetes API server (or optionally in etcd, but not as a mandatory external dependency). Option B is wrong because Flannel does not use BGP to distribute routes; BGP is used by other CNI plugins like Calico. Option C is wrong because Flannel does not natively support Kubernetes Network Policies; it only provides basic connectivity, and network policy enforcement requires a separate component like Calico or Cilium.

Practice this question →

104

Multi-Selectmedium

Which TWO of the following are components of the Ingress API? (Select TWO.)

Select 2 answers

A.rules

B.IngressClass

C.Service

D.Endpoints

E.tls

AnswersA, E

The `rules` field is the core routing engine of the Ingress API; each rule defines an optional hostname and a list of HTTP paths, and each path has an associated `pathType` and a `backend` that references a Service name and port. When a request arrives, the Ingress controller evaluates these rules in order and forwards traffic to the specified backend, making rules the fundamental component for host- and path-based traffic routing.

Why this answer

Option A, rules, is correct because the Ingress spec is fundamentally built around a list of rules that map incoming HTTP/HTTPS host and path requests to backend Services, making rules a core component of the Ingress API. Option E, tls, is correct because the Ingress resource includes a tls field that declares TLS configuration (hosts and secretName) so the ingress controller can terminate TLS for specified hosts. IngressClass (B) is a separate API resource used to select which controller implements an Ingress, not a component inside the Ingress object itself.

Service (C) and Endpoints (D) are distinct core/v1 resources that Ingress rules reference as backends; they are not part of the Ingress API's own structure.

Exam trap

The CKA exam often tests the distinction between fields within the Ingress spec (like `rules` and `tls`) versus separate Kubernetes resources that are referenced by Ingress (like `IngressClass`, `Service`, and `Endpoints`), causing candidates to confuse API components with related but distinct objects.

Practice this question →

105

MCQmedium

A Kubernetes cluster has a Service of type ClusterIP named 'my-svc' in the 'default' namespace. You deploy a pod and want it to resolve the service's cluster IP using DNS. What FQDN should the pod use?

A.my-svc.default.pods.cluster.local

B.my-svc.cluster.local

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

D.my-svc.default.svc.cluster.com

AnswerC

This is the standard, fully qualified DNS name for a Kubernetes service. CoreDNS creates an A record for every ClusterIP service under <service-name>.<namespace>.svc.<cluster-domain>, so with the service in the default namespace and the standard cluster.local domain, my-svc.default.svc.cluster.local correctly resolves to the service's ClusterIP. Applications can use this FQDN both within and outside the namespace to reach the service.

Why this answer

The standard FQDN for a Kubernetes Service is `<service-name>.<namespace>.svc.cluster.local`. This DNS record resolves to the ClusterIP of the Service, allowing pods to reach it via DNS. The `svc` subdomain is a fixed part of the cluster domain, distinguishing Service records from pod records.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or the namespace, picking a shorter form like `my-svc.cluster.local`, which is not a valid Kubernetes Service FQDN.

How to eliminate wrong answers

Option A is wrong because `pods.cluster.local` is the subdomain for pod DNS records (e.g., for headless Services), not for Services; the correct subdomain for Services is `svc.cluster.local`. Option B is wrong because it omits the namespace and the `svc` subdomain; the FQDN must include `<namespace>.svc` to be valid. Option D is wrong because the cluster domain suffix is `cluster.local`, not `cluster.com`; `cluster.local` is the default DNS domain defined in the kubelet configuration.

Practice this question →

106

MCQhard

Which of the following CNI plugins typically uses BGP to distribute routing information across nodes?

A.Calico

B.Flannel

C.Weave

D.Cilium

AnswerA

Calico is highly regarded for its native use of the Border Gateway Protocol (BGP) to distribute routing information among Kubernetes nodes. By acting as a BGP peer, each node advertises its pod IP blocks directly to the physical network infrastructure or to a central BGP Route Reflector. This eliminates the need for packet encapsulation overhead, allowing for highly performant, bare-metal-like networking.

Why this answer

Calico uses BGP (Border Gateway Protocol) to exchange routing information between nodes, enabling direct pod-to-pod communication without overlays. Each node runs a BGP client that advertises the pod CIDRs assigned to that node, allowing the underlying network infrastructure to route traffic at Layer 3.

Exam trap

The trap here is that candidates often associate BGP only with external routing or load balancers (like MetalLB), forgetting that Calico uses BGP internally for pod-to-pod routing across nodes.

How to eliminate wrong answers

Option B is wrong because Flannel typically uses a simple overlay network (e.g., VXLAN, host-gw) and does not implement BGP for route distribution; it relies on etcd for storing subnet allocations. Option C is wrong because Weave creates its own mesh overlay using UDP encapsulation and a custom control protocol, not BGP. Option D is wrong because Cilium primarily leverages eBPF for networking and security, and while it can integrate with BGP via external tools (e.g., MetalLB), its native routing does not depend on BGP for inter-node pod communication.

Practice this question →

107

MCQeasy

Which of the following is a valid use case for a Headless Service?

A.To provide a stable IP address for a deployment

B.To enable DNS-based service discovery for stateful applications like StatefulSets

C.To load balance traffic across pods using iptables

D.To allow external traffic to reach pods without a load balancer

AnswerB

By setting clusterIP to None, a headless service allows CoreDNS to generate direct A or AAAA records for each individual pod associated with a StatefulSet. This enables peer-to-peer discovery and direct communication between specific replicas, which is essential for clustering databases like PostgreSQL, Cassandra, or Kafka.

Why this answer

A Headless Service (with clusterIP: None) is used to enable DNS-based service discovery, returning the IP addresses of all backing pods rather than a single virtual IP. This is essential for stateful applications like StatefulSets, where each pod requires a stable network identity and direct pod-to-pod communication without load balancing.

Exam trap

The trap here is that candidates confuse the purpose of a Headless Service with a regular ClusterIP Service, assuming it still provides load balancing or a stable virtual IP, when in fact it is designed for direct pod DNS resolution without proxying.

How to eliminate wrong answers

Option A is wrong because a Headless Service does not provide a stable IP address; it returns pod IPs via DNS, and stable IPs are provided by a regular ClusterIP Service or a StatefulSet's pod identity. Option C is wrong because load balancing traffic across pods using iptables is the default behavior of a regular ClusterIP Service, not a Headless Service, which deliberately skips proxying and DNS round-robin. Option D is wrong because allowing external traffic to reach pods without a load balancer is the role of a NodePort or LoadBalancer Service, not a Headless Service, which is only for internal DNS-based pod discovery.

Practice this question →

108

MCQmedium

In a Kubernetes cluster using CoreDNS, what is the DNS name for a Service named 'api' in namespace 'backend'?

A.backend.api.svc.cluster.local

B.api.backend.svc.cluster.local

C.api.backend.cluster.local

D.api.svc.backend.cluster.local

AnswerB

This is the correct fully qualified domain name for a Service. CoreDNS serves the record in the format '<service>.<namespace>.svc.<cluster-domain>', so 'api' is the service, 'backend' is the namespace, and 'svc' marks this as a Service record. It resolves to the Service's ClusterIP, allowing pods to reach it with a stable DNS name.

Why this answer

In Kubernetes, CoreDNS resolves Service DNS names using the format `<service>.<namespace>.svc.cluster.local`. For a Service named 'api' in namespace 'backend', the fully qualified DNS name is `api.backend.svc.cluster.local`. This allows Pods to discover the Service via DNS, with CoreDNS serving as the cluster DNS provider.

Exam trap

The trap here is that candidates often confuse the order of service and namespace, or omit the `svc` subdomain, because they think the namespace alone is sufficient for DNS resolution.

How to eliminate wrong answers

Option A is wrong because it reverses the order of service and namespace (backend.api.svc.cluster.local), which does not match the Kubernetes DNS specification. Option C is wrong because it omits the mandatory `svc` subdomain, which is required for Service DNS resolution in the cluster domain. Option D is wrong because it places `svc` before `backend`, breaking the standard `<service>.<namespace>.svc.<cluster-domain>` hierarchy.

Practice this question →

109

MCQeasy

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

A.kubectl exec -it my-pod -- /bin/bash

B.kubectl proxy --port=9090

C.kubectl expose pod my-pod --port=9090 --target-port=8080

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

AnswerD

This command establishes a secure, temporary tunnel that forwards traffic from port 9090 on your local machine directly to port 8080 of the specified pod. It is the ideal tool for debugging and temporarily accessing a pod's web endpoint without exposing it to the public internet or creating permanent cluster resources.

Why this answer

`kubectl port-forward` creates a direct tunnel from a local port (9090) to a pod's port (8080) over the Kubernetes API server, enabling temporary access to a pod's HTTP endpoint without exposing a service. This is the standard method for debugging or testing a pod's network endpoint from a local machine.

Exam trap

The trap here is that candidates often confuse `kubectl port-forward` with `kubectl expose` or `kubectl proxy`, mistakenly thinking those commands provide direct local access to a pod's port, when in fact `kubectl expose` creates a Service (requiring additional access methods) and `kubectl proxy` targets the API server, not the pod.

How to eliminate wrong answers

Option A is wrong because `kubectl exec -it my-pod -- /bin/bash` opens an interactive shell inside the pod, not a network tunnel; it does not forward ports or provide HTTP access from the local machine. Option B is wrong because `kubectl proxy --port=9090` starts a proxy to the Kubernetes API server on port 9090, not to a specific pod's HTTP endpoint on port 8080; it accesses the API server, not the pod's application. Option C is wrong because `kubectl expose pod my-pod --port=9090 --target-port=8080` creates a Kubernetes Service object that exposes the pod as a network service within the cluster, but it does not forward ports to the local machine; it requires additional steps (like `kubectl get svc` and accessing via NodePort or proxy) to reach from outside the cluster.

Practice this question →

110

MCQmedium

Which kubectl command correctly retrieves the list of EndpointSlices for a Service named 'my-svc' in the 'default' namespace?

A.kubectl get endpoints my-svc -n default

B.kubectl describe svc my-svc -n default

C.kubectl get endpointslice -n default --selector=kubernetes.io/service-name=my-svc

D.kubectl get endpointslices my-svc -n default

AnswerC

The label selector kubernetes.io/service-name=my-svc is the standard label automatically applied by the EndpointSlice controller to each slice that belongs to the Service. Since a Service can have multiple EndpointSlices (sharded by address type, subsets, or topology), this selector collects all of them, which is exactly what the task requires. The kubectl get endpointslice command then lists every matching EndpointSlice object in the default namespace.

Why this answer

EndpointSlices are the modern, scalable replacement for Endpoints, and they use a specific label `kubernetes.io/service-name` to associate them with a Service. The command `kubectl get endpointslice -n default --selector=kubernetes.io/service-name=my-svc` correctly filters EndpointSlices by that label, retrieving all slices belonging to 'my-svc'.

Exam trap

The trap here is that candidates often confuse the legacy `endpoints` resource with `endpointslice`, or assume that `kubectl get endpointslice my-svc` works like `kubectl get pods my-pod`, not realizing that EndpointSlices are not named after the Service and require a label selector to filter.

How to eliminate wrong answers

Option A is wrong because `kubectl get endpoints` retrieves the legacy Endpoints object, not EndpointSlices, and does not use the `--selector` flag to filter by service name. Option B is wrong because `kubectl describe svc` shows the Service's details, including its selector and endpoints, but does not list the individual EndpointSlice objects. Option D is wrong because `kubectl get endpointslices` is not a valid kubectl command (the correct resource name is `endpointslice`, not `endpointslices`), and even if corrected, it would not filter by service name without the `--selector` flag.

Practice this question →

111

MCQeasy

What 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.svc.cluster.local

C.my-svc.my-ns.cluster.local

D.my-svc.cluster.local

AnswerA

This is the canonical Kubernetes Service Fully Qualified Domain Name (FQDN). The layout is <service-name>.<namespace>.svc.<cluster-domain>, and for a service named my-svc in namespace my-ns, the default cluster domain cluster.local yields my-svc.my-ns.svc.cluster.local. This record is dynamically maintained by CoreDNS and resolves to the service's ClusterIP, allowing deterministic internal access for workloads in any namespace.

Why this answer

Kubernetes constructs the default DNS name for a Service using the format `<service-name>.<namespace>.svc.cluster.local`. This is defined by the cluster DNS specification (CoreDNS or kube-dns) and allows Pods to resolve the Service by its fully qualified domain name (FQDN) within the cluster. For 'my-svc' in namespace 'my-ns', the FQDN is 'my-svc.my-ns.svc.cluster.local'.

Exam trap

The trap here is that candidates often forget the 'svc' subdomain or the namespace component, mistakenly thinking the Service name alone (e.g., 'my-svc.cluster.local') or just the namespace (e.g., 'my-svc.my-ns.cluster.local') is sufficient, while Kubernetes strictly requires the full `<service>.<namespace>.svc.cluster.local` format for cross-namespace DNS resolution.

How to eliminate wrong answers

Option B is wrong because it omits the namespace component, which is required in the FQDN format `<service>.<namespace>.svc.cluster.local`; without the namespace, the DNS name is incomplete and would not resolve correctly. Option C is wrong because it uses 'cluster.local' directly after the namespace, missing the mandatory 'svc' subdomain that distinguishes Service DNS records from other object types (e.g., Pods use `<pod-ip>.<namespace>.pod.cluster.local`). Option D is wrong because it omits both the namespace and the 'svc' subdomain, representing a common misconception that the Service name alone suffices for cluster-wide DNS resolution.

Practice this question →

112

MCQmedium

An Ingress resource uses 'networking.k8s.io/v1' API. Which field specifies the hostname and path rules for routing traffic?

A.spec.ingress

B.spec.tls

C.spec.rules

D.spec.backend

AnswerC

The spec.rules field is the heart of ingress routing, containing an ordered list of HTTP rules. Each rule can specify an optional host and a set of HTTP paths, each with a pathType (Prefix or Exact) and a backend that points to a Service and port. When incoming traffic matches the host and path criteria, it is forwarded to the specified backend. This is exactly what defines routing rules in an Ingress.

Why this answer

In the 'networking.k8s.io/v1' Ingress API, the 'spec.rules' field is where you define an array of routing rules, each containing a 'host' field for the hostname and an 'http' subfield with 'paths' that specify path-based routing to backend services. This is the primary mechanism for directing traffic based on hostname and path.

Exam trap

A common trap in the CKA exam is confusing 'spec.rules' with 'spec.backend'. While 'spec.backend' defines a default backend, 'spec.rules' is the correct field for hostname and path-based routing rules.

How to eliminate wrong answers

Option A is wrong because 'spec.ingress' is not a valid field in the Ingress spec; the correct top-level field is 'spec.rules'. Option B is wrong because 'spec.tls' is used to configure TLS termination (certificates and hosts) but does not define hostname and path routing rules. Option D is wrong because 'spec.backend' defines a default backend that receives traffic when no rules match, not the hostname and path rules themselves.

Practice this question →

113

Multi-Selectmedium

Which TWO network plugins (CNI) are commonly used in Kubernetes clusters? (Select TWO)

Select 2 answers

A.Calico

B.Flannel

C.CoreDNS

D.kube-proxy

E.Docker

AnswersA, B

Calico is a widely deployed CNI plugin providing pod networking and NetworkPolicy enforcement in Kubernetes clusters. It operates as a CNI implementation, unlike service meshes or ingress controllers, which sit above the CNI layer rather than supplying pod IP address management and connectivity.

Why this answer

Calico (A) is correct because it is a widely deployed CNI plugin that provides pod networking and network policy enforcement using BGP or VXLAN for routing. Flannel (B) is also correct as a common, lightweight CNI plugin that creates an overlay network (typically VXLAN) to give each pod a cluster-wide unique IP. CoreDNS (C) is not a CNI plugin; it is the cluster DNS server that resolves service and pod names. kube-proxy (D) is not a CNI plugin; it implements Service load balancing via iptables/IPVS rules on each node.

Docker (E) is a container runtime, not a Kubernetes CNI plugin.

Exam trap

The trap here is confusing Kubernetes networking components (CoreDNS, kube-proxy) with actual CNI plugins, or mistaking Docker's deprecated networking model for a valid CNI plugin.

Practice this question →

114

MCQhard

A NetworkPolicy allows ingress traffic from pods with label 'app: frontend' in any namespace. Which selector is used?

A.spec.ingress[0].from[0].podSelector: { matchLabels: { app: frontend } }

B.spec.ingress[0].from[0].namespaceSelector: {} and spec.ingress[0].from[0].podSelector: { matchLabels: { app: frontend } }

C.spec.ingress[0].from[0].ipBlock: { cidr: 0.0.0.0/0 }

D.spec.ingress[0].from[0].namespaceSelector: { matchLabels: { app: frontend } }

AnswerB

This is the correct rule because an empty namespaceSelector ({}) explicitly matches all namespaces, and the combined podSelector then narrows those namespaces to only the pods carrying the label app=frontend. In a NetworkPolicyPeer, when both namespaceSelector and podSelector are present, they are ANDed: the source pod must exist in a selected namespace AND carry the matching pod label. This gives cross-namespace, label-based ingress control, which is exactly what the question requires.

Why this answer

To allow ingress traffic from pods with label 'app: frontend' in any namespace, you must combine an empty namespaceSelector (which selects all namespaces) with a podSelector that matches the pod label. This combination tells Kubernetes to allow traffic from any pod matching the label, regardless of which namespace it resides in. Without the namespaceSelector, the podSelector would only apply to pods in the same namespace as the NetworkPolicy.

Exam trap

A common trap is that candidates think a podSelector alone can select pods across namespaces, but without an empty namespaceSelector, the podSelector is scoped to the NetworkPolicy's own namespace.

How to eliminate wrong answers

Option A is wrong because a podSelector alone restricts the rule to pods in the same namespace as the NetworkPolicy, not across all namespaces. Option C is wrong because ipBlock selects traffic based on source IP ranges, not pod labels, and does not consider namespace or pod selectors. Option D is wrong because a namespaceSelector with matchLabels would only select namespaces that have the label 'app: frontend', not pods with that label, and it would not select pods in any namespace unless the namespace itself has that label.

Practice this question →

115

MCQmedium

You run: kubectl expose deployment web --port=80 --target-port=8080 --type=LoadBalancer --name=web-svc. What is the effect of this command?

A.Creates a Service of type ClusterIP which is later changed to LoadBalancer

B.Creates a Service that selects pods with label 'app=web' and maps port 80 to 8080

C.Creates a Service that selects all pods in the namespace regardless of labels

D.Creates a Service that exposes port 8080 on the node

AnswerB

When `kubectl expose` is used with a Deployment, the resulting Service automatically inherits the Deployment's label selector. For a Deployment named 'web', this selector is typically `app=web`, ensuring the Service routes traffic exclusively to the pods managed by that specific Deployment. The command specifies the Service will listen on `port 80`, and the context implies the Deployment's containers are listening on `target-port 8080`, establishing the mapping from Service port 80 to pod port 8080.

Why this answer

The `kubectl expose deployment web --port=80 --target-port=8080 --type=LoadBalancer --name=web-svc` command creates a Service named 'web-svc' that automatically inherits the label selector from the 'web' deployment (typically `app=web`). It maps the Service's port 80 to the pods' container port 8080, and the `--type=LoadBalancer` sets the Service type to LoadBalancer, which provisions an external load balancer (if supported by the cluster) and also creates a NodePort and ClusterIP automatically.

Exam trap

The trap here is that candidates often think `kubectl expose deployment` selects all pods in the namespace or requires an explicit label selector, when in fact it automatically uses the deployment's pod template labels, and the `--type=LoadBalancer` immediately creates a LoadBalancer Service, not a ClusterIP that is later upgraded.

How to eliminate wrong answers

Option A is wrong because the `--type=LoadBalancer` flag directly creates a Service of type LoadBalancer; it does not create a ClusterIP that is later changed — the type is set at creation. Option C is wrong because `kubectl expose deployment` derives the label selector from the deployment's pod template labels (e.g., `app=web`), not all pods in the namespace; it does not select all pods. Option D is wrong because the Service exposes port 80 (the Service port), not port 8080 on the node; port 8080 is the target port on the pods, and the NodePort (if any) is dynamically assigned, not explicitly set to 8080.

Practice this question →

116

Multi-Selectmedium

Which TWO statements about EndpointSlices are true? (Choose 2)

Select 2 answers

A.EndpointSlices are only used for Services of type ClusterIP

B.EndpointSlices are automatically created and managed by the EndpointSlice controller

C.EndpointSlices replace Endpoints in all Kubernetes versions

D.EndpointSlices support dual-stack networking

E.EndpointSlices can contain up to 100 endpoints each

AnswersB, D

EndpointSlices are the primary endpoint discovery API and are reconciled by the EndpointSlice controller running inside kube-controller-manager. This controller watches Service and Pod events, generating and updating EndpointSlice objects to reflect the current set of backing Pod IPs and ports, and also handles not-ready addresses and topology hints. When a Service is deleted, the corresponding EndpointSlices are automatically cleaned up, which is why operators do not manage EndpointSlices directly in normal operations.

Why this answer

Option B is correct because the EndpointSlice controller in the Kubernetes control plane (kube-controller-manager) automatically creates and manages EndpointSlice objects for Services that have selectors, keeping them in sync with the matching Pods. Option D is correct because EndpointSlices natively support dual-stack networking by including an addressType field (IPv4, IPv6, or FQDN) and can represent endpoints of both IP families for a Service. Option A is wrong because EndpointSlices back Services of any type that use selectors, including ClusterIP, NodePort, and LoadBalancer, not just ClusterIP.

Option C is wrong because EndpointSlices were introduced as an alpha feature in Kubernetes 1.16 and became GA in 1.21; older versions still rely solely on Endpoints, so they do not replace Endpoints in all versions. Option E is wrong because the default maximum is 100 endpoints per EndpointSlice, but this is a configurable limit (via --max-endpoints-per-slice on the controller manager), so stating a fixed cap of 100 as an absolute truth is inaccurate.

Exam trap

The trap here is that candidates often assume EndpointSlices have a hard-coded limit of 100 endpoints, but the CKA exam expects you to know that this value is configurable and not an immutable constraint.

Practice this question →

117

Multi-Selectmedium

Which of the following can be used to expose a set of pods externally to the internet in a Kubernetes cluster? (Select THREE.)

Select 3 answers

A.Ingress resource

B.Service of type NodePort

C.Service of type LoadBalancer

D.Service of type Headless

E.Service of type ClusterIP

AnswersA, B, C

Ingress is not a Service type but a separate Kubernetes API object that exposes HTTP and HTTPS routes from outside the cluster to Services. It operates at Layer 7, allowing hostname- and path-based routing, TLS termination, and virtual hosting, and it requires an Ingress controller (e.g., NGINX, Traefik) to interpret and implement the rules.

Why this answer

An Ingress resource (A) exposes HTTP/HTTPS routes from outside the cluster to Services inside the cluster, acting as a layer-7 entry point with rules and TLS termination, so it can publish a set of pods to the internet. A Service of type NodePort (B) exposes the Service on each node's IP at a static port (default range 30000-32767), making the pods reachable externally via any node IP and that port. A Service of type LoadBalancer (C) provisions an external load balancer (e.g., via a cloud provider) that routes internet traffic to the Service's endpoints, directly exposing the pods externally.

A headless Service (D) sets clusterIP: None and returns pod IPs directly via DNS for direct pod addressing, but it does not provide an external entry point. A Service of type ClusterIP (E) only assigns a virtual IP reachable within the cluster, so it is not externally accessible without additional components like Ingress or NodePort.

Exam trap

A common mistake is thinking that a Headless service can be used for external exposure because it still has a DNS name, but it lacks any IP or port mapping for external traffic. Headless services are intended for internal service discovery, not external exposure.

Practice this question →

118

MCQeasy

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

A.To expose the Service externally via a cloud load balancer

B.To provide load balancing across pods

C.To map the Service to an external DNS name

D.To allow direct DNS resolution to pod IPs

AnswerD

By setting clusterIP: None, Kubernetes bypasses the allocation of a single virtual IP for the Service. Instead, the internal DNS server directly returns a list of A or AAAA records containing the individual IP addresses of all matching, healthy Pods, allowing clients to establish direct, peer-to-peer connections with specific Pods.

Why this answer

A headless Service (clusterIP: None) disables the virtual IP and load balancing, causing DNS queries to return the IP addresses of the backing pods directly. This allows clients to perform DNS-based service discovery and connect to specific pod IPs, which is essential for stateful applications like databases that require direct pod-to-pod communication.

Exam trap

The trap here is that candidates confuse a headless Service with a regular ClusterIP Service, assuming it still provides load balancing or external access, when in fact it is designed for direct pod-to-pod DNS resolution without a virtual IP.

How to eliminate wrong answers

Option A is wrong because a headless Service does not expose anything externally; external exposure is achieved via NodePort, LoadBalancer, or Ingress, not by setting clusterIP to None. Option B is wrong because headless Services explicitly disable load balancing; the kube-proxy does not create iptables rules for a headless Service, so traffic is not distributed across pods. Option C is wrong because mapping to an external DNS name is done via ExternalName Services, not headless Services; headless Services resolve to pod IPs within the cluster DNS.

Practice this question →

119

MCQmedium

Which Ingress resource field is used to specify the hostname for which traffic should be routed?

A.spec.tls[].hosts

B.spec.defaultBackend

C.spec.host

D.spec.rules[].host

AnswerD

In an Ingress resource, the spec.rules[].host field is the correct location to specify the domain name for routing. The Ingress controller inspects the HTTP Host header of incoming requests and matches it against this field to apply the corresponding path-based routing rules.

Why this answer

In Kubernetes Ingress resources, host-based routing is defined under `spec.rules[].host`. Each rule can specify a hostname, and the Ingress controller uses this field to match the `Host` header of incoming HTTP requests, directing traffic to the appropriate backend service. This is the standard field for routing traffic based on hostname as defined in the Kubernetes Ingress API.

Exam trap

The trap here is that candidates confuse `spec.tls[].hosts` with the routing hostname, thinking TLS host fields also control traffic routing, when in fact they only associate TLS certificates with hostnames and do not affect request routing.

How to eliminate wrong answers

Option A is wrong because `spec.tls[].hosts` is used to specify hostnames that should be covered by a TLS certificate, not for routing traffic — it defines which hosts the TLS secret applies to, not where traffic is directed. Option B is wrong because `spec.defaultBackend` defines a fallback backend for traffic that does not match any rule, not a specific hostname for routing. Option C is wrong because there is no `spec.host` field in the Ingress spec; hostnames are specified per rule under `spec.rules[].host`.

Practice this question →

120

Multi-Selectmedium

Which TWO statements about Ingress in Kubernetes are correct?

Select 2 answers

A.Setting spec.ingressClassName to 'nginx' disables the default Ingress controller.

B.Ingress can terminate TLS connections for backend Services.

C.Ingress natively supports gRPC services without any additional configuration.

D.Ingress can provide Layer 4 (TCP/UDP) load balancing.

E.Ingress can route traffic to different Services based on the hostname in the HTTP Host header.

AnswersB, E

Ingress can terminate TLS connections for backend Services when a TLS block specifies a secret containing a certificate and private key. The Ingress controller decrypts HTTPS traffic at the edge and forwards plain HTTP to the backend Service. This offloads TLS handling from application Pods and centralizes certificate management.

Why this answer

Option B is correct because an Ingress resource can reference a TLS Secret via spec.tls, allowing the Ingress controller to terminate TLS connections and forward decrypted HTTP traffic to the backend Services. Option E is correct because Ingress rules use the host field to match the HTTP Host header and route requests to different backend Services accordingly. Option A is wrong because spec.ingressClassName selects which Ingress controller should handle the resource; it does not disable the default controller.

Option C is wrong because gRPC support is not native to Ingress and typically requires controller-specific annotations or a Gateway API/HTTPRoute setup. Option D is wrong because Ingress operates at Layer 7 (HTTP/HTTPS), while Layer 4 TCP/UDP load balancing requires a Service of type LoadBalancer or a Gateway API TCPRoute.

Exam trap

The trap here is that candidates confuse Ingress's Layer 7 capabilities with Layer 4 load balancing, or assume gRPC works out-of-the-box without understanding that Ingress controllers require explicit HTTP/2 support and protocol configuration for gRPC.

Practice this question →

121

MCQeasy

You need to expose a Deployment named 'web' on port 80 inside the cluster. Which kubectl command creates a ClusterIP service?

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

B.kubectl expose deployment web --port=80

C.kubectl create service clusterip web --tcp=80

D.kubectl port-forward deployment/web 80:80

AnswerB

This command successfully creates a ClusterIP service named `web` that exposes the deployment's pods internally on port 80. Because no `--type` flag is explicitly provided, the `kubectl expose` command defaults to the `ClusterIP` service type. This is the standard and most secure way to enable internal service discovery within a Kubernetes cluster.

Why this answer

The `kubectl expose deployment web --port=80` command creates a ClusterIP service by default, which exposes the deployment on port 80 within the cluster. The `expose` command without specifying `--type` defaults to ClusterIP, making it the appropriate choice for internal cluster access.

Exam trap

The trap here is that candidates often assume `kubectl expose` requires an explicit `--type` flag, but the default is ClusterIP, and they may confuse `kubectl create service clusterip` (which lacks automatic selector binding) with `kubectl expose` (which automatically sets selectors from the target resource).

How to eliminate wrong answers

Option A is wrong because `--type=NodePort` creates a NodePort service, not a ClusterIP service, and exposes the deployment on a port accessible from outside the cluster via node IPs. Option C is wrong because `kubectl create service clusterip web --tcp=80` creates a ClusterIP service but does not link it to the 'web' deployment's pod selectors; it creates a standalone service without automatically setting the selector to match the deployment's labels, so it won't route traffic to the deployment's pods. Option D is wrong because `kubectl port-forward deployment/web 80:80` is a debugging command that forwards a local port to a pod, not a service creation command, and does not create any persistent service object.

Practice this question →

122

Multi-Selecteasy

Which two of the following are valid service discovery methods in Kubernetes? (Choose two.)

Select 2 answers

A.Environment variables injected into pods

B.DNS resolution via CoreDNS

C.Manual /etc/hosts entries

D.Consul agent running as a sidecar

E.Using kubectl get endpoints

AnswersA, B

When a pod starts, the kubelet injects environment variables for every Service that already exists in the same namespace, with entries like MY_SERVICE_HOST and MY_SERVICE_PORT. This allows containers to locate Services without needing explicit configuration, but only those created before the pod's creation. Because the variables are static once injected, they do not update when new Services are added, making this a limited legacy discovery method that works only for a fixed set of Services.

Why this answer

Option A is correct because Kubernetes automatically injects environment variables (e.g., <SERVICE_NAME>_SERVICE_HOST and <SERVICE_NAME>_SERVICE_PORT) into containers at pod creation time for existing Services, providing a native service discovery mechanism. Option B is correct because CoreDNS is the default cluster DNS add-on that resolves Service names (e.g., my-svc.my-namespace.svc.cluster.local) and headless Service records to ClusterIPs or pod IPs, which is the primary service discovery method in Kubernetes. Option C is not a Kubernetes-native discovery method; /etc/hosts is managed by kubelet for pod hostname resolution and does not dynamically discover Services.

Option D describes a third-party service mesh/registry approach (Consul) that is not a built-in Kubernetes service discovery method. Option E, kubectl get endpoints, is an administrative query of the Endpoints API, not a runtime service discovery mechanism used by pods.

Exam trap

The trap here is that candidates may confuse external service discovery tools (like Consul) or manual configuration methods (like /etc/hosts) with Kubernetes-native mechanisms, or mistake a diagnostic command (kubectl get endpoints) for an actual runtime discovery method.

Practice this question →

123

MCQhard

A cluster has kube-proxy running in ipvs mode. An administrator creates a Service of type ClusterIP. Which of the following is true about how traffic is forwarded to the pods?

A.kube-proxy uses userspace mode to proxy traffic

B.kube-proxy uses iptables rules to randomly select a pod

C.kube-proxy does nothing; the cluster DNS does the load balancing

D.kube-proxy creates IPVS virtual servers that use scheduling algorithms like round-robin

AnswerD

When configured in IPVS mode, kube-proxy implements Netfilter hooks and programs IPVS virtual servers to handle Service traffic directly in kernel space. This mode supports sophisticated load-balancing algorithms such as round-robin (rr), least connection (lc), destination hashing (dh), and source hashing (sh). This architecture provides superior throughput and lower latency compared to iptables, especially in large-scale clusters with thousands of Services.

Why this answer

When kube-proxy runs in ipvs mode, it creates IPVS virtual servers for each ClusterIP Service. These virtual servers use kernel-level scheduling algorithms (e.g., round-robin, least connections) to forward traffic directly to the selected backend pods, bypassing iptables for per-packet decisions. This provides better performance and more sophisticated load-balancing policies compared to iptables mode.

Exam trap

The trap here is that candidates confuse kube-proxy modes (userspace, iptables, ipvs) and assume iptables rules are always used, or mistakenly think DNS handles load balancing, when in fact ipvs mode uses kernel-level virtual servers with explicit scheduling algorithms.

How to eliminate wrong answers

Option A is wrong because userspace mode is a legacy kube-proxy mode where traffic is proxied through a userspace process; in ipvs mode, kube-proxy does not use userspace proxying. Option B is wrong because iptables rules are used in iptables mode, not ipvs mode; in ipvs mode, kube-proxy creates IPVS virtual servers and does not rely on iptables for random pod selection. Option C is wrong because cluster DNS (CoreDNS) only resolves Service names to ClusterIPs and does not perform load balancing or traffic forwarding; kube-proxy is responsible for forwarding traffic to pods.

Practice this question →

124

Multi-Selecthard

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

Select 3 answers

A.NetworkPolicy can define rules based on DNS names

B.NetworkPolicy supports both ingress and egress rules

C.NetworkPolicy can select pods from other namespaces using namespaceSelector

D.NetworkPolicy is a cluster-scoped resource

E.By default, if no NetworkPolicy applies to a pod, all traffic to that pod is allowed

AnswersB, C, E

NetworkPolicy is designed to control both directions of traffic. The spec contains an ingress section that restricts inbound connections to selected pods, and an egress section that restricts outbound connections from those pods. Each section is independently evaluated: an empty list under ingress means no inbound traffic is allowed, while an empty egress list blocks all outbound traffic, effectively creating default-deny behavior.

Why this answer

Option B is correct because a NetworkPolicy spec can include both an ingress array and an egress array, allowing you to control inbound and outbound traffic for the selected pods (with policyTypes declaring which directions are enforced). Option C is correct because the podSelector within an ingress/egress rule can be combined with a namespaceSelector, and when both are used in the same peer element they match pods in the namespaces selected by namespaceSelector, enabling cross-namespace pod selection. Option E is correct because Kubernetes NetworkPolicy is additive and default-allow: if no NetworkPolicy selects a given pod, that pod is not isolated and all ingress and egress traffic is permitted.

Option A is not correct because NetworkPolicy peers are defined by ipBlock CIDRs, podSelector, and namespaceSelector — not by DNS names. Option D is not correct because NetworkPolicy is a namespaced resource (it lives in a namespace and selects pods within that namespace, though rules can reference other namespaces).

Exam trap

The CKA exam often tests the misconception that NetworkPolicy is cluster-scoped, but it is actually namespaced, and candidates frequently forget that egress rules require explicit allowance for DNS traffic to avoid breaking name resolution.

Practice this question →

125

MCQhard

You have a Deployment with 3 replicas. You create a headless service (clusterIP: None) with a label selector. Which of the following is true about DNS resolution for this service?

A.DNS returns the IP addresses of all pods that match the selector.

B.DNS does not resolve the service name at all.

C.DNS returns the service name as a CNAME to the pod names.

D.DNS resolves the service name to a single ClusterIP.

AnswerA

With a headless service (clusterIP: None), the DNS name for the service is not backed by a virtual IP. Instead, CoreDNS/kube-dns creates an A record for each ready pod endpoint that matches the service's selector, so a DNS query for the service name returns the IP addresses of all 3 pod replicas.

Why this answer

A headless service (clusterIP: None) does not allocate a ClusterIP. Instead, DNS returns the IP addresses of all pods matching the label selector via A/AAAA records. This allows direct pod-to-pod communication without load balancing, commonly used for stateful workloads like databases.

Exam trap

The trap here is that candidates assume all services have a ClusterIP and that DNS always returns a single IP, but headless services bypass this entirely, returning multiple pod IPs instead.

How to eliminate wrong answers

Option B is wrong because DNS does resolve the headless service name; it returns the pod IPs rather than failing. Option C is wrong because DNS returns A/AAAA records with pod IPs, not a CNAME to pod names (though pod DNS names are created via StatefulSet, not a headless service alone). Option D is wrong because a headless service explicitly sets clusterIP: None, so no ClusterIP is assigned; DNS never returns a single ClusterIP.

Practice this question →

126

Multi-Selectmedium

Which TWO statements are true about Ingress in Kubernetes?

Select 2 answers

A.Ingress can terminate TLS connections

B.Ingress can expose multiple Services under the same IP address

C.IngressClass is a mandatory field in Ingress spec

D.Ingress is the only way to expose Services externally

E.Ingress works without an Ingress controller

AnswersA, B

Ingress can terminate TLS because the Ingress spec supports a tls section that references a Secret containing the certificate and private key. When configured, the Ingress controller performs HTTPS termination, decrypting traffic at the edge and forwarding plain HTTP to backend Services. This is a built-in feature of most controllers, such as NGINX, and is managed by the controller itself.

Why this answer

Option A is correct because an Ingress resource can specify a TLS block with a secretName referencing a Kubernetes TLS Secret, allowing the Ingress controller to terminate TLS connections at the edge before forwarding traffic to backend Services. Option B is correct because a single Ingress resource can define multiple rules and paths (host- and path-based routing) that map to different backend Services, all reachable through the same Ingress controller IP address. Option C is not correct because IngressClass is not a mandatory field in the Ingress spec; it can be set via the ingressClassName field or the deprecated kubernetes.io/ingress.class annotation, and defaults may apply.

Option D is not correct because Services can also be exposed externally via NodePort, LoadBalancer, or externalIPs without using Ingress. Option E is not correct because an Ingress resource has no effect on its own; an Ingress controller (such as NGINX or Traefik) must be running to implement the routing rules.

Exam trap

This certification often tests the misconception that IngressClass is mandatory or that Ingress can function without a controller, leading candidates to overestimate the Ingress resource's autonomy.

Practice this question →

127

MCQmedium

A developer runs 'kubectl run nginx --image=nginx --expose --port=80'. What Kubernetes resources are created?

A.Only a pod named 'nginx'

B.A pod named 'nginx' and a ClusterIP service named 'nginx'

C.A pod named 'nginx' and a LoadBalancer service named 'nginx'

D.A deployment named 'nginx' and a NodePort service named 'nginx'

AnswerB

Executing kubectl run with the --expose flag creates a Pod and concurrently provisions a ClusterIP Service sharing the exact same name. By default, this Service acts as an internal load balancer, mapping its own port directly to the container port defined in the Pod specification.

Why this answer

The `kubectl run nginx --image=nginx --expose --port=80` command creates a pod named 'nginx' and automatically generates a ClusterIP service named 'nginx' that exposes port 80. The `--expose` flag triggers the creation of a service of type ClusterIP (the default service type) to provide stable network access to the pod.

Exam trap

The trap here is that candidates often assume `kubectl run` always creates a Deployment (as it did in older Kubernetes versions) or that `--expose` creates a LoadBalancer, but the CKA exam tests the current default behavior where `kubectl run` creates a pod and `--expose` creates a ClusterIP service.

How to eliminate wrong answers

Option A is wrong because it ignores the `--expose` flag, which explicitly instructs kubectl to create a service alongside the pod. Option C is wrong because `kubectl run` with `--expose` creates a ClusterIP service, not a LoadBalancer service; a LoadBalancer would require `--type=LoadBalancer` or a separate `kubectl expose` command with that type. Option D is wrong because `kubectl run` without `--generator` or `--restart` flags creates a standalone pod, not a deployment, and the service type defaults to ClusterIP, not NodePort.

Practice this question →

128

MCQeasy

Which DNS record type does Kubernetes use to resolve a Service's ClusterIP?

A.PTR record

B.SRV record

C.CNAME record

D.A record

AnswerD

An A record, or Address record, is the fundamental DNS record type used to map a hostname directly to an IPv4 address. For a Kubernetes Service, CoreDNS creates an A record that maps the service's fully qualified domain name (e.g., `my-service.my-namespace.svc.cluster.local`) to its stable ClusterIP, which is an IPv4 address. This direct, one-to-one mapping is precisely what enables pods within the cluster to resolve service names to their corresponding network addresses for communication.

Why this answer

Kubernetes uses A records to resolve a Service's ClusterIP. When a DNS query is made for a Service name (e.g., `my-svc.my-namespace.svc.cluster.local`), the cluster's DNS server (typically CoreDNS) returns an A record containing the Service's ClusterIP address. This allows pods to reach the Service via its stable virtual IP.

Exam trap

The trap here is that candidates confuse SRV records (used for headless Services with named ports) with the standard A record resolution for ClusterIP Services, or mistakenly think CNAME records are used for internal Service resolution.

How to eliminate wrong answers

Option A is wrong because PTR records are used for reverse DNS lookups (IP to hostname), not for resolving a Service's ClusterIP. Option B is wrong because SRV records are used to locate specific services with port information (e.g., for headless Services with named ports), not for standard ClusterIP resolution. Option C is wrong because CNAME records alias one hostname to another; Kubernetes uses A records (or AAAA for IPv6) for ClusterIP Services, not CNAMEs, which are typically used for external DNS aliasing.

Practice this question →

129

MCQhard

A NetworkPolicy with podSelector: {} and policyTypes: [Ingress] is applied to a namespace. What is the effect on pods in that namespace?

A.All ingress traffic is denied unless explicitly allowed by another policy.

B.The policy has no effect because no rules are defined.

C.All ingress traffic is allowed.

D.All egress traffic is denied.

AnswerA

An empty `podSelector: {}` in a NetworkPolicy selects all pods within the policy's namespace. When `policyTypes: [Ingress]` is specified without any `ingress` rules, the policy's effect on the selected pods is to deny all incoming traffic by default. This effectively creates a default-deny ingress posture for all pods in the namespace, unless another NetworkPolicy explicitly permits specific ingress connections to those pods.

Why this answer

A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. When `policyTypes: [Ingress]` is set without any ingress rules, it defaults to denying all ingress traffic that is not explicitly allowed by another policy. This is because Kubernetes NetworkPolicy implements an implicit deny for the specified traffic direction when no rules are provided, effectively isolating the pods from inbound connections.

Exam trap

The trap here is that candidates often assume an empty rules list means 'no effect' or 'allow all', but Kubernetes NetworkPolicy defaults to deny for the specified policyTypes when no rules are defined, making it a powerful isolation tool.

How to eliminate wrong answers

Option B is wrong because a NetworkPolicy with `podSelector: {}` and `policyTypes: [Ingress]` does have an effect: it denies all ingress traffic by default, even without explicit rules. Option C is wrong because the absence of ingress rules in a policy with `policyTypes: [Ingress]` results in a deny-all behavior for ingress, not an allow-all. Option D is wrong because the policy only specifies `policyTypes: [Ingress]`, so it has no effect on egress traffic; egress remains allowed by default unless another policy denies it.

Practice this question →

130

MCQeasy

Which kubectl command will expose a deployment named 'web-app' as a NodePort service on port 80?

A.kubectl expose pod web-app --type=NodePort --port=80

B.kubectl create deployment web-app --expose --port=80

C.kubectl create service nodeport web-app --port=80

D.kubectl expose deployment web-app --type=NodePort --port=80

AnswerD

This command correctly targets the `deployment` resource named `web-app` and dynamically generates a NodePort service. It automatically extracts the deployment's pod template labels to populate the service's selector, ensuring seamless routing of external traffic on the specified port.

Why this answer

The `kubectl expose deployment web-app --type=NodePort --port=80` command creates a Service from an existing Deployment named 'web-app', setting the service type to NodePort and mapping port 80 on the node to the target port on the pods. This is the standard way to expose a Deployment as a NodePort service in Kubernetes.

Exam trap

The trap here is that candidates often confuse `kubectl expose` with `kubectl create service` or misuse the `--expose` flag on `kubectl create deployment`, not realizing that `kubectl expose` is the correct command to create a service from an existing resource and that the `--type=NodePort` flag is required for NodePort exposure.

How to eliminate wrong answers

Option A is wrong because it attempts to expose a pod named 'web-app' rather than a deployment, and the pod name does not match the deployment name; also, exposing a pod directly is not the intended method for managing a scalable service. Option B is wrong because `kubectl create deployment` with `--expose` creates a new deployment and a ClusterIP service (not NodePort) simultaneously, and it does not allow specifying the service type as NodePort. Option C is wrong because `kubectl create service nodeport` requires a `--tcp` flag to specify the port mapping (e.g., `--tcp=80:80`) and does not automatically link to an existing deployment; it creates a standalone service without selecting the deployment's pods.

Practice this question →

131

Multi-Selecthard

Which THREE statements about NetworkPolicy are correct?

Select 3 answers

A.To allow traffic from a specific namespace, you can use a namespaceSelector in the ingress rule.

B.If no NetworkPolicy exists, all traffic is denied by default.

C.A NetworkPolicy with podSelector: {} selects all pods in the namespace.

D.The field 'podSelector.matchLabels' is used to select pods based on labels.

E.NetworkPolicy is a cluster-scoped resource.

AnswersA, C, D

A namespaceSelector matches pods by their namespace's labels, so an ingress rule containing it permits traffic originating from pods in the selected namespace. This satisfies the stem's requirement for allowing traffic from a specific namespace.

Why this answer

Option A is correct because an ingress rule's 'from' clause can include a namespaceSelector that matches namespaces by their labels, thereby permitting traffic originating from pods in those namespaces. Option C is correct because an empty podSelector (podSelector: {}) matches every pod in the NetworkPolicy's own namespace, effectively applying the policy to all pods there. Option D is correct because podSelector uses a LabelSelector whose matchLabels field selects pods by exact key/value label pairs.

Option B is wrong because the absence of any NetworkPolicy means all ingress and egress traffic is allowed by default; traffic is only denied once a policy selects the pod. Option E is wrong because NetworkPolicy is a namespaced resource, not cluster-scoped, and only affects pods within its own namespace.

Exam trap

A common misconception is that NetworkPolicy defaults to deny-all when no policy exists, but the actual default is allow-all; the trap is that candidates confuse the 'default deny' behavior that occurs once a policy selects a pod (if no rule allows traffic) with the cluster-wide default.

Practice this question →