5 exercises — Describe Service types, Ingress routing strategies, NetworkPolicy selector logic, CNI plugins, and cluster DNS in professional English.
0 / 11 completed
1 / 11
Your application needs to be accessible only from within the Kubernetes cluster — no external ingress, no node-level port exposure. Which Service type is correct and why?
ClusterIP is the default and most restrictive Service type — the virtual IP it assigns is only routable inside the cluster, making it the natural choice for internal microservice communication.
LoadBalancer provisions an external cloud load balancer with a public IP — unnecessary and expensive for internal traffic. NodePort opens a port (30000–32767) on every node's external interface, exposing the service to anything that can reach the nodes. ExternalName is a special type used to alias an external DNS name, not to restrict access. ClusterIP gives you stable internal DNS (service-name.namespace.svc.cluster.local), load balancing across pod endpoints, and zero external exposure by default.
Key vocabulary:
• ClusterIP — default Service type; virtual IP reachable only from within the cluster
• NodePort — exposes the service on a static port on every node's external IP; accessible externally
• LoadBalancer — provisions a cloud load balancer with a public IP; extends NodePort externally
2 / 11
An Ingress resource has two rules: one routes api.example.com to the API service, and another routes example.com/dashboard to the UI service. How do you correctly describe the difference between these routing strategies?
Host-based routing uses the HTTP Host header to direct traffic to different services; path-based routing uses the URL path prefix — both can be combined in a single Ingress resource.
In Ingress YAML: a rule with a host field uses host-based routing — the Ingress controller checks the Host header. A rule with paths configuration uses path-based routing — the controller matches the request URI path. A single Ingress can have both: host "api.example.com" with path "/" goes to the API service, while host "example.com" with path "/dashboard" goes to the UI. Ingress controllers (nginx, traefik, istio gateway) implement both strategies based on the standard Ingress spec.
Key vocabulary:
• host-based routing — directs traffic based on the HTTP Host header; requires a DNS record per host
• path-based routing — directs traffic based on the URL path prefix; multiple services share one hostname
• Ingress controller — the component that implements the Ingress rules (nginx, traefik, ALB, etc.)
3 / 11
A NetworkPolicy has both a podSelector and a namespaceSelector in the samefrom array entry. How do you correctly explain the resulting behaviour to a colleague?
The AND vs. OR distinction in NetworkPolicy from entries is one of the most common sources of misconfiguration — the indentation of the YAML changes the security semantics fundamentally.
Same from entry (AND): only pods with label app=api that are ALSO in a namespace with label team=platform can connect. Separate from entries (OR): pods with label app=api in any namespace CAN connect, OR pods in any namespace labelled team=platform CAN connect — much broader. Always use AND (same entry) when you want to restrict to a specific pod in a specific namespace. Use separate entries only when truly intending to permit either condition independently. Double-check your NetworkPolicies with kubectl describe networkpolicy to confirm the parsed rules.
Key vocabulary:
• podSelector — matches pods by label within the policy's namespace or the specified namespace
• namespaceSelector — matches namespaces by label; all pods in matching namespaces are included
• from entry — a single element in the from array; multiple selectors within one entry are ANDed
4 / 11
A new SRE asks what a CNI plugin is and why the choice of CNI matters for a Kubernetes cluster. Which explanation is most accurate?
The CNI plugin is what makes pod networking work — without it, pods cannot get IP addresses, cannot reach each other, and NetworkPolicies are not enforced.
Not all CNI plugins are equal. Flannel provides basic overlay networking but does NOT enforce NetworkPolicies. Calico adds NetworkPolicy enforcement on top of BGP or overlay routing. Cilium goes further with eBPF-based packet processing, enabling transparent encryption, L7 policy enforcement, and deep observability. When choosing a CNI plugin, teams must evaluate: NetworkPolicy support, performance (overlay vs. native routing), observability features, and support for the specific cloud provider. Switching CNI plugins after cluster creation requires a full cluster rebuild.
Key vocabulary:
• CNI (Container Network Interface) — spec and plugin system for pod IP assignment and inter-pod routing
• overlay network — encapsulates pod traffic in an outer packet (VXLAN/Geneve); works across subnets
• eBPF — Linux kernel technology that lets CNI plugins like Cilium process packets with high efficiency
5 / 11
Inside a pod, you curl http://payment-svc.billing.svc.cluster.local:8080. A junior engineer asks what each segment of this DNS name means. Which explanation is correct?
The cluster DNS FQDN format is: <service-name>.<namespace>.svc.<cluster-domain> — each segment has a precise meaning and together they form the stable address for any Service in any namespace.
CoreDNS (the cluster DNS server) resolves this FQDN to the Service's ClusterIP. Within the same namespace, you can use just the service name (payment-svc) because the search domains in /etc/resolv.conf include the local namespace. Across namespaces, use service-name.namespace or the full FQDN. The "svc" segment distinguishes Service records from pod headless DNS records (which use pod-ip.namespace.pod.cluster.local). The cluster domain is usually cluster.local but can be customised during cluster bootstrap.
Key vocabulary:
• FQDN — Fully Qualified Domain Name; the complete, unambiguous DNS name including all domain segments
• CoreDNS — the cluster-internal DNS server that resolves service FQDNs to ClusterIP addresses
• search domains — DNS suffixes in /etc/resolv.conf that allow short hostname resolution within a namespace
6 / 11
Alex (Senior Dev) comments on your PR:
'The Service definition is good, but I'm concerned about exposing port 80 directly. Consider using a NodePort service if external access is truly needed, or explore an Ingress controller for more controlled routing. We should also document why we chose this approach.' What does Alex most likely mean by 'explore an Ingress controller'?
Alex is referring to an Ingress controller which acts as a reverse proxy. Ingress controllers allow you to define routing rules (e.g., based on URL paths or hostnames) without directly exposing ports on your Kubernetes nodes. This offers more flexibility and security compared to simply opening port 80.
7 / 11
Sarah (DevOps Engineer) sends a Slack message:
'Hey team, just running some diagnostics on the cluster. I'm seeing high latency between our frontend and backend services. I've checked the network policies and they seem to be in place as expected. Any ideas?' You need to explain what she's likely investigating regarding NetworkPolicies. Which statement best describes her concern?
Sarah's message indicates high latency between services. While NetworkPolicies *can* cause problems if misconfigured, the most likely scenario – given she's checked them 'as expected' – is that they are incorrectly configured to block traffic, causing delays. It's important to investigate whether the policies are actually preventing communication.
8 / 11
Ben (Dev) writes a PR description:
'This change introduces a new NetworkPolicy that restricts access to the database service only from authorized microservices. We've used podSelectors to target specific pods and namespace selectors to limit scope. This is crucial for security.' What does Ben mean by 'podSelectors' in this context?
Ben is using podSelectors to define *which* pods are allowed to access the database. PodSelectors work by matching labels on Kubernetes pods – for example, a selector might target pods with the label `app: my-microservice`. This provides fine-grained control over network access.
9 / 11
Chloe (SRE) asks you a question:
'I'm noticing some performance issues with our inter-service communication. Can you explain what a CNI plugin is and why its choice matters?' Which of the following best describes the role of a CNI plugin?
A CNI (Container Network Interface) plugin is the software that implements the Kubernetes networking model. It's responsible for managing the low-level details of networking within the cluster – things like IP address allocation, routing packets between pods, and handling network connectivity. Different CNI plugins offer varying performance characteristics and features.
10 / 11
You are troubleshooting a service that intermittently fails to communicate with other services within the cluster. The logs show no errors related to DNS resolution. You suspect a problem with network connectivity. Which of the following commands would be MOST helpful in diagnosing this issue?
While DNS resolution is crucial, intermittent connectivity issues often stem from underlying network problems. Using nslookup within a pod allows you to directly test the DNS resolution of the service name *from* the perspective of the pod itself, revealing if there are any subtle routing or firewall issues preventing communication. Option A lists pods, C describes a service definition and D focuses on log messages.
11 / 11
During a daily stand-up, you're asked about your work on improving inter-service communication latency. You explain that you've been investigating CNI plugins.
What is the primary purpose of a CNI (Container Network Interface) plugin in a Kubernetes cluster?
CNI plugins are responsible for establishing the fundamental network connectivity between pods in a Kubernetes cluster. They handle tasks like IP address assignment, routing, and firewalling – essentially, they're the building blocks of container networking. While security and monitoring can be influenced by CNI choices, their primary role is infrastructure.
What will I practise in "Kubernetes Networking Language — Kubernetes Operations | CoderLingo"?
5 advanced exercises practising Kubernetes networking vocabulary — Service types, Ingress routing, NetworkPolicy selectors, CNI plugins, and cluster DNS.
How many exercises are in this module?
This module has 11 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Kubernetes Operations exercises?
Browse the full Kubernetes Operations hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.