Knowledge + Practice

CCNA Cka Services Networking Questions

48 questions · Cka Services Networking topic · All types, answers revealed

Practice these questions Exam hub All questions

1

MCQeasy

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

A.NodePort

B.LoadBalancer

C.ClusterIP

D.ExternalName

AnswerA

NodePort exposes the Service on each node's IP at a static port (30080).

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

2

MCQhard

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

3

Multi-Selectmedium

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

Select 2 answers

A.NodePort

B.Headless

C.LoadBalancer

D.ExternalName

E.ClusterIP

AnswersA, C

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

Why this answer

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

Exam trap

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

Practice this question →

4

Multi-Selecteasy

Which THREE of the following are CNI plugins?

Select 3 answers

A.kube-proxy

B.Flannel

C.Weave

D.CoreDNS

E.Calico

AnswersB, C, E

Correct. Flannel is a CNI plugin.

Why this answer

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

Exam trap

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

Practice this question →

5

MCQmedium

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

A.from.podSelector

B.spec.podSelector

C.ingress.podSelector

D.to.podSelector

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

6

MCQmedium

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

A.kernelspace

B.iptables

C.userspace

D.ipvs

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

7

MCQhard

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

A.Denies all egress traffic as well.

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

8

MCQeasy

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

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

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

C.my-service.cluster.local

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

AnswerD

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

9

MCQeasy

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

A.To allow DNS queries to return all pod IPs for a StatefulSet

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

C.To provide load balancing across pods

D.To assign a static ClusterIP

AnswerA

A headless Service (spec.clusterIP: None) allocates no ClusterIP, so kube-proxy provides no virtual IP or load balancing. Instead, the DNS entry for the Service resolves to the set of individual Pod IPs backing that Service; for a StatefulSet, this enables clients and peers to discover and connect directly to every Pod, including via stable names like pod-0.svc.namespace.svc.cluster.local. This is the standard cluster-internal pattern for stateful discovery (e.g., databases), not a stable front-end VIP.

Why this answer

A Headless Service (clusterIP: None) is used when you want to discover individual pod IPs directly, rather than having a single virtual IP load-balance traffic. When a Service has clusterIP set to None, DNS queries return the A/AAAA records for all ready pod IPs, which is essential for StatefulSets where each pod has a unique identity and needs to be addressed individually, such as in clustered databases like Cassandra or Kafka.

Exam trap

The trap here is that candidates often confuse a Headless Service with a regular ClusterIP Service, thinking it still provides load balancing or a stable virtual IP, when in fact it disables both and returns all pod IPs for direct pod-to-pod communication.

How to eliminate wrong answers

Option B is wrong because exposing a Service externally via a cloud load balancer requires setting type: LoadBalancer, not clusterIP: None. Option C is wrong because a Headless Service does not provide load balancing; it bypasses the kube-proxy and returns all pod IPs, leaving load balancing to the client or application. Option D is wrong because clusterIP: None explicitly prevents assigning a static ClusterIP; instead, it makes the Service headless with no ClusterIP at all.

Practice this question →

10

MCQmedium

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

11

MCQeasy

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

A.ExternalName

B.NodePort

C.LoadBalancer

D.ClusterIP

AnswerB

NodePort exposes the service on a static port on each node's IP address.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

12

MCQhard

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

A.podSelector in spec.podSelector

B.podSelector in spec.ingress.from

C.podSelector in spec.egress.to

D.namespaceSelector in spec.ingress.from

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

13

MCQeasy

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

A.LoadBalancer

B.ExternalName

C.NodePort

D.ClusterIP

AnswerC

A NodePort Service allocates a static port from the default range 30000–32767 on every cluster node, binding that port to the Service’s ClusterIP. This directly satisfies the stem’s requirement for a static port exposed on each node’s IP address, distinguishing it from ClusterIP (internal only) and LoadBalancer (cloud‑provisioned external IP).

Why this answer

NodePort is the Service type that exposes a Service on a static port (in the range 30000-32767) on each node's IP address. When a NodePort Service is created, Kubernetes allocates a port from that range and opens that port on every node in the cluster, forwarding traffic to the Service's ClusterIP and then to the pods. This allows external traffic to reach the Service by hitting any node's IP address and the allocated NodePort.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking that LoadBalancer also exposes a static port on each node, but LoadBalancer actually delegates external access to an external load balancer and does not guarantee a static port on every node's IP.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer Service provisions an external load balancer (e.g., from a cloud provider) and assigns a public IP, but it does not expose the Service on a static port on each node's IP address; it relies on the load balancer to distribute traffic to the NodePort or ClusterIP. Option B is wrong because ExternalName maps a Service to a DNS name (CNAME record) and does not expose any port or IP address on nodes; it is used for internal DNS aliasing. Option D is wrong because ClusterIP exposes the Service only on a cluster-internal IP address, which is not reachable from outside the cluster and does not involve a static port on each node's IP.

Practice this question →

14

MCQmedium

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

A.Service of type ClusterIP

B.NetworkPolicy

C.Service of type NodePort

D.Ingress

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

15

MCQmedium

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

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

B.The pods are not running

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

D.The CNI plugin does not support egress rules

AnswerC

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

Why this answer

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

This is by design, as NetworkPolicies are additive whitelists.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

16

Multi-Selecthard

Which TWO of the following are valid ways to isolate a set of pods from all ingress traffic except from monitoring pods?

Select 2 answers

A.Apply a NetworkPolicy with ingress rule allowing from a specific pod only

B.Apply a NetworkPolicy with empty podSelector and ingress rule allowing all

C.Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp } and ingress rule with namespaceSelector: { matchLabels: { name: monitoring } }

D.Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp }, ingress: [ { from: [ { podSelector: { matchLabels: { role: monitoring } } } ] } ]

E.Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp }, policyTypes: [Ingress], and no ingress rules

AnswersD, E

This allows ingress from monitoring pods.

Why this answer

It uses a NetworkPolicy with a `podSelector` targeting the protected pods and an `ingress` rule that explicitly allows traffic only from pods with the label `role: monitoring`. This isolates the target pods from all other ingress traffic, as Kubernetes NetworkPolicy defaults to denying ingress when any ingress rule is defined, and only the specified source pods are permitted.

Exam trap

The trap here is that candidates often confuse `namespaceSelector` with `podSelector` and think a namespace-level rule is sufficient to isolate traffic to specific pods, but without a `podSelector` in the ingress rule, all pods in the monitoring namespace are allowed, breaking isolation.

Practice this question →

17

MCQhard

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

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

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

C.The CoreDNS pod is in CrashLoopBackOff.

D.The service's DNS name is misspelled.

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

18

MCQhard

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

A.ipvs

B.iptables

C.kernelnet

D.userspace

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

19

MCQeasy

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

A.Calico

B.etcd

C.Docker

D.Kubelet

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

20

MCQmedium

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

21

MCQeasy

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

A.ipvs

B.nftables

C.userspace

D.iptables

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

22

MCQmedium

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

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

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

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

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

AnswerA

Port-forward maps a local port to a port on a resource (pod or service).

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

23

MCQeasy

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

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

B.kubectl proxy --port=8080

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

24

MCQhard

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

25

MCQmedium

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

26

MCQmedium

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

A.api.default.svc.cluster.local

B.default.api.svc.cluster.local

C.api.svc.default.cluster.local

D.api.default.cluster.local

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

27

MCQmedium

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

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

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

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

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

AnswerD

Correct. The policy selects all pods and denies ingress by default.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

28

MCQhard

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

A./api/v1/users

B.ImplementationSpecific: depends on the Ingress controller

C./api

D.No match, returns 404

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

29

MCQmedium

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

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

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

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

D.The Ingress must have an IngressClass annotation.

AnswerC

The Ingress controller forwards traffic to the service's ClusterIP, and endpoints must exist for the service to forward to pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

30

Multi-Selectmedium

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

Select 3 answers

A.The Service exists in the cluster

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

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

D.kube-proxy is running in iptables mode

E.A CNI plugin is installed

AnswersA, B, C

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

Why this answer

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

Exam trap

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

Practice this question →

31

MCQhard

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

A.IPVS supports multiple load balancing algorithms.

B.IPVS uses iptables rules for service discovery.

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

D.IPVS cannot handle large numbers of services.

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

32

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 →

33

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 →

34

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 →

35

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 →

36

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 →

37

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 →

38

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 →

39

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 →

40

Multi-Selecthard

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

Select 3 answers

B.GatewayClass

C.LoadBalancer

D.HTTPRoute

E.Ingress

AnswersA, B, D

Gateway represents the instantiation of a gateway.

Why this answer

A Gateway is a top-level resource in the Gateway API resource model that represents a specific point where traffic is received and processed, typically backed by a load balancer or proxy. It defines listeners (protocol, port, hostname) and references a GatewayClass to indicate the implementation.

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 →

41

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 →

42

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 →

43

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 used CNI plugin that provides networking and network policy.

Why this answer

Calico is a widely adopted CNI plugin that provides network policy enforcement using IP-in-IP or VXLAN encapsulation and leverages BGP for routing. It supports both overlay and non-overlay networking, making it suitable for on-premises and cloud deployments.

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 →

44

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 →

45

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 →

46

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 →

47

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 →

48

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

Correct. The namespaceSelector in the ingress rule allows traffic from pods in namespaces matching the selector, enabling cross-namespace traffic control.

Why this answer

A NetworkPolicy ingress rule can use a `namespaceSelector` to allow traffic from pods in a specific namespace. Option C is correct because an empty `podSelector: {}` selects all pods in the namespace. Option D is correct because `podSelector.matchLabels` is used to select pods based on specific labels.

Options B and E are incorrect: B is false because without any NetworkPolicy, all traffic is allowed; E is false because NetworkPolicy is namespaced, not cluster-scoped.

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 →

Ready to test yourself?

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

Start 20-question session