5 exercises — master the vocabulary Kubernetes engineers use when discussing pod scheduling, workload controllers, service exposure, namespace boundaries, and resource management.
0 / 18 completed
1 / 18
A senior architect says: "The logging sidecar runs in the same pod as the application container."
What does co-location inside the same pod guarantee that running the two containers in separate pods would not provide?
A pod is a co-scheduling boundary with shared Linux namespaces — it is not just a logical grouping.
What containers in the same pod share:
Shared resource
What this means in practice
Network namespace
Same IP address. Containers communicate via localhost:port — no DNS, no service mesh resolution needed
PID namespace (optional)
Containers can see each other's processes if shareProcessNamespace: true
IPC namespace
Shared memory and semaphores between containers
Volumes
Pod-level volumes can be mounted by multiple containers (e.g., app writes logs → sidecar reads and ships them)
Node placement
Scheduler places the entire pod on one node — containers are always co-located
What containers in the same pod do NOT automatically share:
• File system — each container has its own root FS from its image. Shared data requires explicit volumeMount
• Resource limits — each container in the pod spec has its own resources.requests / resources.limits
• Restart behaviour — containers can crash and restart independently; a crashing sidecar does not restart the main container (unless restartPolicy triggers the whole pod)
Key vocabulary:
• Pod — the smallest deployable unit in Kubernetes; one or more containers sharing network and storage namespaces
• Sidecar container — a secondary container in the same pod that augments the main application (logging, proxying, config injection)
• Network namespace — the Linux kernel resource that isolates networking; containers in the same pod share it
• Co-scheduling — Kubernetes guarantees all containers in a pod run on the same worker node
2 / 18
A platform engineer says: "We use a StatefulSet for our Kafka brokers because each pod needs a stable hostname and its own dedicated persistent volume."
Which characteristic of StatefulSets is being described that a Deployment cannot provide?
StatefulSets were designed for workloads that need persistent identity — distributed databases, message brokers, and consensus systems.
Deployment vs StatefulSet — what differs:
Property
Deployment
StatefulSet
Pod names
Random suffix: app-7f4b2c-xkpq9
Stable ordinal: kafka-0, kafka-1
DNS hostname
Not addressable by pod name
Each pod gets a stable DNS entry via a Headless Service
Storage
Shared or ephemeral volumes only
volumeClaimTemplates — each pod gets its own PVC, retained on restart
Pod ordering
All pods start/stop in parallel
Sequential: kafka-0 starts before kafka-1
Rolling update
Can update all pods simultaneously with surge
Updates one pod at a time, in reverse ordinal order
When to use StatefulSet:
• Distributed databases: PostgreSQL (Patroni), MySQL, MongoDB, Cassandra
• Message brokers: Kafka, RabbitMQ
• Consensus systems: etcd, ZooKeeper
• Any workload where each instance must be individually addressable and retain data across restarts
Key vocabulary:
• StatefulSet — a Kubernetes workload controller that provides stable network identities and persistent storage to pods
• Headless Service — a Service with clusterIP: None that creates individual DNS records for each StatefulSet pod
• volumeClaimTemplates — per-pod PVC templates in a StatefulSet; each replica gets its own bound PersistentVolumeClaim
• Ordinal index — the sequential integer suffix (0, 1, 2…) in a StatefulSet pod's name
3 / 18
A developer says: "We need a LoadBalancer Service for the public-facing API, not a ClusterIP."
What does a ClusterIP Service provide, and what does the LoadBalancer type add on top of that?
Kubernetes Service types form a hierarchy — each type extends the one below it.
Service type
Reachable from
Common use case
ClusterIP (default)
Inside the cluster only via stable virtual IP
Internal service-to-service communication
NodePort
Any node's IP on a static high port (30000–32767)
Development/testing; bare-metal clusters
LoadBalancer
External public IP from cloud provider
Exposing a single service to the internet
ExternalName
Maps to an external DNS name
Aliasing an external database or third-party API
How LoadBalancer works in a managed cluster (GKE, EKS, AKS):
① Kubernetes calls the cloud provider's API to provision a cloud load balancer (AWS ALB/NLB, GCP Cloud Load Balancer, Azure Load Balancer)
② The load balancer gets a public IP (or hostname for NLB)
③ Traffic flows: Internet → Cloud LB → NodePort → kube-proxy → Pod
④ The LoadBalancer service still creates a ClusterIP and NodePort under the hood
When to use Ingress instead:
LoadBalancer creates one cloud LB per service — expensive for many services. An Ingress controller uses a single LB and routes by hostname/path, making it far more cost-effective for multi-service platforms.
Key vocabulary:
• ClusterIP — stable virtual IP for a Service, routable only within the cluster
• LoadBalancer Service — extends ClusterIP by provisioning an external cloud load balancer with a public IP
• kube-proxy — runs on each node; implements Service VIP routing using iptables or IPVS rules
• Ingress — an API object that defines HTTP/HTTPS routing rules; requires an Ingress controller (nginx, Traefik, ALB controller)
4 / 18
A DevOps engineer says: "We isolate dev, staging, and production using Kubernetes namespaces, so pods in different environments cannot communicate."
Which statement correctly describes a common misconception about namespace isolation?
Namespace ≠ network boundary. This is one of the most common Kubernetes security misconceptions.
What namespaces DO provide:
Feature
How namespaces help
Name scoping
Resource names only need to be unique within a namespace
RBAC scope
RoleBindings are namespace-scoped; restrict which teams can access which resources
Resource quotas
Limit total CPU/memory consumption per namespace
LimitRange
Set default and maximum resource limits per container in the namespace
What namespaces do NOT provide (by default):
• Network isolation — any pod can reach any other pod by ClusterIP or DNS name (service.other-namespace.svc.cluster.local) across namespaces unless a CNI-enforced NetworkPolicy blocks the traffic
• Node isolation — pods from different namespaces can run on the same node; node-level isolation requires Taints/Tolerations or dedicated node pools
• Container isolation — not a security boundary at the kernel level
To actually restrict inter-namespace traffic:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-from-other-namespaces
namespace: production
spec:
podSelector: {}
ingress:
- from:
- podSelector: {} # allow only within this namespace
Key vocabulary:
• Namespace — a virtual partition for Kubernetes resources providing name scoping, RBAC, and quotas — not a security or network boundary
• NetworkPolicy — a Kubernetes resource that defines ingress/egress traffic rules; enforced by the CNI plugin (Calico, Cilium, Weave Net)
• CNI (Container Network Interface) — the plugin that implements pod networking; must support NetworkPolicy for it to be enforced
• ResourceQuota — caps total resource consumption within a namespace
5 / 18
An SRE explains: "We configure a CPU request of 250m and a CPU limit of 1000m for the application container — the request is deliberately lower than the limit."
Which statement correctly explains the operational difference between a resource request and a limit in Kubernetes?
Requests and limits operate at two different moments in the pod lifecycle: scheduling time and runtime.
Property
Request
Limit
When used
Scheduling time — node selection
Runtime — enforcement by kernel
CPU behaviour
Scheduler sums all requests on a node; won't place pod if available CPU < request
Container is CPU-throttled (not killed) when it exceeds the limit — CFS scheduler enforces it
Memory behaviour
Same scheduling logic as CPU
Container is OOM-killed if it exceeds memory limit (memory cannot be throttled)
The 250m/1000m strategy explained:
• 250m request means the scheduler only needs a node with 250 milli-CPUs free — allowing dense pod packing
• 1000m limit means the container can burst to 1 full CPU when the node is not busy
• If the node is under pressure and many pods try to burst simultaneously, they are throttled back toward their requests
Common mistake — setting no limits:
Without a memory limit, a leaked memory application can consume all node memory, causing the kernel's OOM killer to terminate other pods on the same node — a noisy-neighbour problem.
Key vocabulary:
• Resource request — the minimum guaranteed resource reservation used by the scheduler for pod placement
• Resource limit — the maximum resource a container may consume; enforced by the Linux kernel at runtime
• OOM-kill — the kernel terminating a process because it exceeded its memory limit
• CPU throttling — reducing a container's CPU time share when it exceeds its limit; no termination, but increased latency
• QoS class — Kubernetes quality-of-service classification (Guaranteed / Burstable / BestEffort) that determines eviction priority
6 / 18
During a code review for a new microservice deployment, a senior developer, Sarah, comments on the PR description: 'I'm concerned about the lack of explicit health checks defined in this service. Kubernetes will only automatically restart it if the container exits unexpectedly.' What does Sarah's comment primarily highlight regarding the configuration of the application within its Pod?
Sarah's comment focuses on the importance of proactive health checks within Kubernetes. While Kubernetes *does* have default restart policies, relying solely on these without explicitly defined liveness probes means the system won't automatically detect and recover from issues that don't cause the container to crash—such as a service outage or unresponsive API calls. This can result in prolonged periods of downtime; therefore, explicit health checks are crucial for reliable operation.
7 / 18
PR Description:
"This service exposes a REST API and handles user authentication. It's deployed as a Deployment with a single replica set. We've configured the Pod to automatically restart if it crashes."
During a Slack conversation about this PR, a junior developer asks, "But what happens if the API starts returning 500 errors? Kubernetes won't know anything is wrong, right?" What does this question primarily reveal about the current deployment setup?
The question highlights that the deployment relies solely on the container exiting unexpectedly to trigger a restart – this is a common misconception. While Kubernetes *can* be configured with HTTP probes (option B), the PR description doesn't mention any such configuration. The core issue is the absence of proactive health checks, meaning Kubernetes isn't actively monitoring the API's response codes and will only react when the container itself fails which aligns with Sarah's comment in the code review. Option A is incorrect because it introduces a component not present in the description; option D is also inaccurate as automation doesn't replace the need for proper health checks.
8 / 18
During a code review for a new microservice deployment, a senior developer, Sarah, comments on the PR description: 'I'm concerned about the lack of explicit health checks defined in this service. Kubernetes will only automatically restart it if the container exits unexpectedly.' What does Sarah's comment primarily highlight regarding the configuration of the application within its Pod?
Sarah's comment focuses on the importance of proactive health checks within Kubernetes. While Kubernetes *does* have default restart policies, relying solely on these without explicitly defined liveness probes means the system won't automatically detect and recover from issues that don't cause the container to crash—such as a service outage or unresponsive API calls. This can result in prolonged periods of downtime; therefore, explicit health checks are crucial for reliable operation.
9 / 18
PR Description:
"This service exposes a REST API and handles user authentication. It's deployed as a Deployment with a single replica set. We've configured the Pod to automatically restart if it crashes."
During a Slack conversation about this PR, a junior developer asks, "But what happens if the API starts returning 500 errors? Kubernetes won't know anything is wrong, right?" What does this question primarily reveal about the current deployment setup?
The question highlights that the deployment relies solely on the container exiting unexpectedly to trigger a restart – this is a common misconception. While Kubernetes *can* be configured with HTTP probes (option B), the PR description doesn't mention any such configuration. The core issue is the absence of proactive health checks, meaning Kubernetes isn't actively monitoring the API's response codes and will only react when the container itself fails which aligns with Sarah's comment in the code review. Option A is incorrect because it introduces a component not present in the description; option D is also inaccurate as automation doesn't replace the need for proper health checks.
10 / 18
During a code review for a new microservice deployment, a senior developer, Sarah, comments on the PR description: 'I'm concerned about the lack of explicit health checks defined in this service. Kubernetes will only automatically restart it if the container exits unexpectedly.' What does Sarah's comment primarily highlight regarding the configuration of the application within its Pod?
Sarah's comment focuses on the importance of proactive health checks within Kubernetes. While Kubernetes *does* have default restart policies, relying solely on these without explicitly defined liveness probes means the system won't automatically detect and recover from issues that don't cause the container to crash—such as a service outage or unresponsive API calls. This can result in prolonged periods of downtime; therefore, explicit health checks are crucial for reliable operation.
11 / 18
PR Description:
"This service exposes a REST API and handles user authentication. It's deployed as a Deployment with a single replica set. We've configured the Pod to automatically restart if it crashes."
During a Slack conversation about this PR, a junior developer asks, "But what happens if the API starts returning 500 errors? Kubernetes won't know anything is wrong, right?" What does this question primarily reveal about the current deployment setup?
The question highlights that the deployment relies solely on the container exiting unexpectedly to trigger a restart – this is a common misconception. While Kubernetes *can* be configured with HTTP probes (option B), the PR description doesn't mention any such configuration. The core issue is the absence of proactive health checks, meaning Kubernetes isn't actively monitoring the API's response codes and will only react when the container itself fails which aligns with Sarah's comment in the code review. Option A is incorrect because it introduces a component not present in the description; option D is also inaccurate as automation doesn't replace the need for proper health checks.
12 / 18
During a code review for a new microservice deployment, a senior developer, Sarah, comments on the PR description: 'I'm concerned about the lack of explicit health checks defined in this service. Kubernetes will only automatically restart it if the container exits unexpectedly.' What does Sarah's comment primarily highlight regarding the configuration of the application within its Pod?
Sarah's comment focuses on the importance of proactive health checks within Kubernetes. While Kubernetes *does* have default restart policies, relying solely on these without explicitly defined liveness probes means the system won't automatically detect and recover from issues that don't cause the container to crash—such as a service outage or unresponsive API calls. This can result in prolonged periods of downtime; therefore, explicit health checks are crucial for reliable operation.
13 / 18
PR Description:
"This service exposes a REST API and handles user authentication. It's deployed as a Deployment with a single replica set. We've configured the Pod to automatically restart if it crashes."
During a Slack conversation about this PR, a junior developer asks, "But what happens if the API starts returning 500 errors? Kubernetes won't know anything is wrong, right?" What does this question primarily reveal about the current deployment setup?
The question highlights that the deployment relies solely on the container exiting unexpectedly to trigger a restart – this is a common misconception. While Kubernetes *can* be configured with HTTP probes (option B), the PR description doesn't mention any such configuration. The core issue is the absence of proactive health checks, meaning Kubernetes isn't actively monitoring the API's response codes and will only react when the container itself fails which aligns with Sarah's comment in the code review. Option A is incorrect because it introduces a component not present in the description; option D is also inaccurate as automation doesn't replace the need for proper health checks.
14 / 18
Sarah, a senior developer, is reviewing a PR for a new microservice. The description states: 'We've configured the Pod to automatically restart if it crashes.' What does this configuration primarily ensure? This ensures that Kubernetes will continuously monitor the application and automatically recover from any failures within the pod
This configuration highlights the Kubernetes feature of self-healing. It doesn't guarantee perfect uptime, but it ensures that if a crash occurs, the pod will be automatically restarted, preventing service interruption. Options A and D are incorrect because they misrepresent the scope of the restart functionality.
15 / 18
You're a DevOps engineer troubleshooting slow deployments. The monitoring dashboard shows frequent restarts of your application pods. Analyzing the logs, you discover that the pod is repeatedly crashing due to resource contention (CPU and memory). What is the *primary* reason for configuring CPU requests and limits on Kubernetes Pods? To manage resource allocation and prevent a single container from monopolizing resources, leading to instability and crashes
CPU requests and limits are fundamental to Kubernetes resource management. Requests guarantee a minimum amount of CPU for the container, while limits prevent it from consuming excessive resources and potentially starving other containers or the node itself. Option A is incorrect because it only focuses on memory; options B and D are also inaccurate.
16 / 18
As a platform engineer, you're explaining the purpose of using a Service Mesh (e.g., Istio) alongside your microservices deployed on Kubernetes. A developer asks: 'Why do I need another layer of abstraction?' You respond, stating: 'A service mesh handles communication between services, providing features like traffic management, security, and observability – things that would be complex to implement directly within each pod.' What key benefit is being described related to the Service Mesh? To simplify inter-service communication by adding intelligent routing, security policies, and monitoring capabilities.
Service meshes sit between applications and the Kubernetes control plane, managing communication complexities. They offer features like traffic routing, security policies, and observability – all of which can be difficult to implement within individual pods, simplifying the overall architecture.
17 / 18
You are reviewing a Slack message from a developer named Alex: 'I'm trying to deploy this new service, but I keep getting errors related to DNS resolution. It seems like the pod can't find the external database.' Considering Kubernetes networking concepts, what is the *most likely* underlying issue causing this problem? Incorrectly configured DNS settings within the Kubernetes cluster or a misconfigured Service that doesn't properly expose the database endpoint.
Kubernetes uses a cluster-wide DNS service (kube-dns or CoreDNS) to resolve hostnames within the pod network. If this DNS isn't configured correctly, pods won't be able to find services like databases. Option A is misleading; option B describes a deliberate configuration change, and option D focuses on the database server itself.
18 / 18
You are writing a PR description for deploying a new microservice to Kubernetes. The description includes: 'The service is deployed as a Deployment with a single replica set.' A junior developer asks you: 'What does 'replica set' mean in this context?' What is the *primary* function of a ReplicaSet? To maintain a specified number of identical pod replicas running simultaneously, ensuring high availability and fault tolerance.
A ReplicaSet ensures that a specified number of pod replicas are always running, providing redundancy and high availability. If one pod fails, the ReplicaSet automatically creates a new one to maintain the desired count. Options A and B misrepresent its function; option D is incorrect.
What will I practice in "Container Orchestration Language — Cloud-Native Exercises"?
This is a Cloud-Native exercise set. It walks through 18 scenario-based multiple-choice questions built around real usage of Cloud-Native terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 18 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the Cloud-Native vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Cloud-Native exercises?
See the Cloud-Native exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — Cloud-Native vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.