Skip to content
tezvyn:

Top 30 Kubernetes Interview Questions and Answers

30 multiple-choice questions on Kubernetes, drawn from 30 bites out of the 293 tagged Kubernetes on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

  1. Question 1 of 30

    Which statement accurately describes a key characteristic of Linux namespaces?

    Show the answer

    Answer: c · They enable processes to have isolated views of system resources while sharing the host's single kernel.

    Linux namespaces provide isolated environments for resources like process IDs and network interfaces, but they all share the host's single kernel. This is a fundamental difference from virtual machines, which run their own independent kernels. The card explicitly states that namespaces are not a sole security boundary for untrusted code.

    Read the full bite: Linux Namespaces: A Virtual Slice of the OS

  2. Question 2 of 30

    What is the primary problem that Linux cgroups were designed to solve in a multi-tenant server environment?

    Show the answer

    Answer: c · Preventing a single application from consuming all available CPU or memory, thus starving other processes.

    The card explicitly states that cgroups were introduced because 'a single runaway process could consume all available CPU or memory, starving every other process and crashing the system.' While cgroups are related to container isolation, their primary role is resource limiting, not network traffic isolation or secure communication.

    Read the full bite: Linux cgroups: Resource Fences for Processes

  3. Question 3 of 30

    Which component ultimately enforces CPU and memory limits after the container runtime writes the cgroup configuration at startup?

    Show the answer

    Answer: d · The Linux kernel scheduler and memory manager, using the configured cgroup values

    The Linux kernel scheduler and memory manager enforce cgroup limits continuously using values written by the runtime at startup. It is a common misconception that the Docker daemon actively monitors and throttles containers, but the daemon only configures limits while the kernel handles enforcement.

    Read the full bite: How do containers enforce CPU and memory limits via cgroups?

  4. Question 4 of 30

    Which component in a Kubernetes node is directly responsible for pulling container images and setting up their isolated execution environment?

    Show the answer

    Answer: a · The container runtime, which executes containers based on instructions from the kubelet

    The container runtime is the low-level engine that directly pulls images and creates isolated container environments using features like namespaces and cgroups. The kubelet acts as a 'transmission,' translating Kubernetes commands into instructions for the runtime, but does not perform the execution itself.

    Read the full bite: Container Runtime: The Engine That Runs Your Containers

  5. Question 5 of 30

    What is the most realistic downside a team accepts when prioritizing strict portability across two cloud providers?

    Show the answer

    Answer: a · They forgo the deepest managed services and slow feature velocity

    Portability forces a lowest-common-denominator design, sacrificing best-of-breed managed services and adding overhead that slows delivery. Faster shipping is the opposite of what multi-cloud abstraction produces.

    Read the full bite: Designing for portability across two clouds

  6. Question 6 of 30

    The OCI Runtime Spec primarily standardizes container execution by defining:

    Show the answer

    Answer: d · The structure of a filesystem bundle and a config.json for runtime instructions.

    The OCI Runtime Spec defines the 'filesystem bundle' (a directory containing the root filesystem and a config.json) and the config.json file itself, which specifies how a low-level runtime should execute the container. Option B describes the OCI Image Spec, while options C and D refer to higher-level abstractions or user-facing tools, which the Runtime Spec is explicitly not.

    Read the full bite: OCI Runtime Spec: The 'How to Run' Standard for Containers

  7. Question 7 of 30

    Which scenario best illustrates the primary benefit of a container runtime shim?

    Show the answer

    Answer: c · A container daemon crashes, but all running containers continue to operate unaffected.

    The primary benefit of a runtime shim is to decouple the container daemon from the container's lifecycle, allowing the daemon to restart or crash without terminating running containers. Option B is incorrect because the daemon (e.g., containerd) prepares the container's filesystem and configuration, not the shim.

    Read the full bite: Container Runtime Shim: Decoupling the Container Lifecycle

  8. Question 8 of 30

    Which of the following is the primary security benefit of adopting a pull-based GitOps deployment model?

    Show the answer

    Answer: a · It prevents the exposure of production cluster credentials to external CI/CD pipelines or systems.

    The card states that the pull-based model is more secure as it "avoids exposing cluster credentials externally," contrasting it with the push-based model that "requires giving your CI system powerful, high-risk credentials." Option D describes a general benefit of using Git for configuration, not a specific security advantage of the pull-based model.

    Read the full bite: GitOps: Your Git Repo is the Single Source of Truth

  9. Question 9 of 30

    What is the primary functional distinction between stopping a container and removing it?

    Show the answer

    Answer: d · Stopping a container allows it to be restarted later with its preserved internal state, whereas removing it permanently deletes the container instance and any data not on a volume.

    The card explicitly states that stopping a container retains its state, allowing it to be restarted, while removing it permanently deletes the container and its non-volume data. Option A is incorrect because 'stop' sends a graceful shutdown signal (SIGTERM), not an immediate termination, and 'rm' deletes an already stopped container, it doesn't initiate the shutdown process itself.

    Read the full bite: Container Lifecycle: From Create to Remove

  10. Question 10 of 30

    What is the core problem with deploying app:latest to production Kubernetes?

    Show the answer

    Answer: d · The tag is mutable, so the same reference can resolve to different code across pods and time

    latest is a movable pointer, breaking reproducibility and rollbacks. It is not blocked by Kubernetes (A), unrelated to size (B), and does not affect health checks (C).

    Read the full bite: Why :latest is a production anti-pattern

  11. Question 11 of 30

    A pod is stuck in ImagePullBackOff. What is the most informative first troubleshooting step?

    Show the answer

    Answer: a · Run kubectl describe pod and read the Events to see the exact failure reason

    The Events section names the specific cause (auth, wrong name, or network), guiding the fix. Recreating blindly (C) or restarting kubelets (D) wastes time without diagnosis.

    Read the full bite: Debugging ImagePullBackOff on a private registry

  12. Question 12 of 30

    A pull-through cache reduces cross-region pull cost primarily because:

    Show the answer

    Answer: d · After the first pull, subsequent in-region pulls are served locally instead of crossing regions

    The cache fetches once from upstream then serves the region locally, cutting egress and latency. It does not change compression (A), auth (C), or architecture (B).

    Read the full bite: Reducing cross-region image pull costs

  13. Question 13 of 30

    Why does Kubernetes schedule Pods rather than individual containers onto Nodes?

    Show the answer

    Answer: d · A Pod groups tightly coupled containers that share network and storage as one schedulable unit

    The Pod is the unit that bundles a shared IP, volumes, and lifecycle for co-located containers. Containers can run without Kubernetes (C), and a Node runs many Pods (B).

    Read the full bite: Node, Pod, and Container relationship

  14. Question 14 of 30

    Which component is the only one that reads from and writes to etcd directly?

    Show the answer

    Answer: d · The kube-apiserver

    All access to etcd is funneled through the kube-apiserver, which serves the API. The scheduler and controller-manager interact with etcd indirectly via the apiserver, and the kubelet runs on nodes.

    Read the full bite: Core control plane components

  15. Question 15 of 30

    Why is a Service needed in front of the Deployment's Pods for external access?

    Show the answer

    Answer: c · Pod IPs are ephemeral, so a Service provides a stable endpoint and load-balances across them

    Pods get new IPs when rescheduled; a Service gives a durable virtual IP and balances traffic across current healthy Pods. The Deployment creates Pods regardless of any Service.

    Read the full bite: Minimal objects to expose a stateless app

  16. Question 16 of 30

    In the described notebook platform, what happens after 30 minutes of user inactivity to optimize cost while preserving work?

    Show the answer

    Answer: c · An idle manager scales the notebook Pod to zero, saving state to the persistent volume claim

    The card describes an idle manager that scales the Pod to zero after a timeout while saving state to the PVC, avoiding compute costs without destroying user data. Option D reflects a VM-centric misconception that ignores the Kubernetes-native design, while D incorrectly suggests destroying the namespace rather than suspending the Pod.

    Read the full bite: Design on-demand containerized dev environments for data scientists

  17. Question 17 of 30

    After the apiserver stores a new Pod in etcd, what assigns it to a specific Node?

    Show the answer

    Answer: a · The kube-scheduler watches for unscheduled Pods and binds one to a suitable Node

    The scheduler filters and scores Nodes, then writes a binding via the apiserver. kubectl does not pick Nodes (C), and the kubelet only acts on Pods already assigned to its Node (B).

    Read the full bite: What happens after kubectl apply

  18. Question 18 of 30

    If etcd loses quorum, what is the immediate effect on the cluster?

    Show the answer

    Answer: c · The control plane cannot accept state changes, but already-running Pods keep running

    Without quorum etcd cannot accept writes, so scheduling and changes stop, yet the data plane continues on last-known state. Running Pods are not killed (D) and etcd cannot self-rebuild from kubelets (A).

    Read the full bite: etcd as the cluster source of truth

  19. Question 19 of 30

    What is the primary advantage of configuring a Virtual repository in Google Cloud's Artifact Registry?

    Show the answer

    Answer: d · It provides a unified endpoint for accessing artifacts from multiple underlying repositories.

    A Virtual repository's main benefit is to group multiple standard and remote repositories behind a single endpoint, simplifying artifact access for developers. Option B describes a Remote repository, which is a component that a Virtual repository can group, but not the primary advantage of the Virtual repository itself.

    Read the full bite: Artifact Registry: Google's Universal Package Manager

  20. Question 20 of 30

    Why is using an image digest crucial for production deployments, especially compared to using a mutable tag?

    Show the answer

    Answer: b · Digests guarantee that the exact, tested version of an image is deployed, preventing unintended updates.

    Digests provide an immutable reference, ensuring that the specific, tested version of an image is consistently deployed, which is vital for reproducibility and stability in production. Option D is incorrect because digests prevent automatic updates; they pin an image to a specific, unchanging version, which is the opposite of automatically pulling the 'most recent' version.

    Read the full bite: Image Digest: The Immutable Image Identifier

  21. Question 21 of 30

    Why is the reconciliation loop described as level-triggered rather than edge-triggered?

    Show the answer

    Answer: b · It acts on the current gap between desired and actual state, so it corrects drift even if it missed events

    Level-triggered means evaluating current state against desired on every pass, making it resilient to missed events and drift. Edge-only triggering (D) or one-shot runs (A) would fail to self-heal.

    Read the full bite: The Kubernetes reconciliation loop

  22. Question 22 of 30

    Why is a StatefulSet, not a Deployment, the right choice for a clustered database?

    Show the answer

    Answer: c · Each Pod needs a stable identity and its own persistent volume that survives rescheduling

    A StatefulSet gives stable ordinal names, stable DNS, and per-Pod persistent storage that databases require. Deployments treat Pods as interchangeable and can mount volumes (B) but not per-Pod stable ones.

    Read the full bite: Deployment versus StatefulSet

  23. Question 23 of 30

    A team submits a distributed training job requiring eight GPUs on four nodes to a shared Kubernetes cluster. What is the main reason to use an advanced scheduler like Volcano or Kueue rather than the default Kubernetes scheduler?

    Show the answer

    Answer: d · It ensures the job waits until all eight GPUs are available before placing any pods, avoiding deadlock from partial allocation

    The default scheduler may place only part of a distributed job, causing deadlock while reserved GPUs sit idle; advanced schedulers use gang scheduling to allocate all required resources together. The first distractor confuses the scheduler with the gateway submission abstraction layer described in the card.

    Read the full bite: Design training job submission to a shared Kubernetes cluster

  24. Question 24 of 30

    What is the role of the filtering phase in the Kubernetes scheduler?

    Show the answer

    Answer: a · It eliminates Nodes that cannot feasibly run the Pod, leaving candidates for scoring

    Filtering applies hard constraints (resources, taints, required affinity) to discard infeasible Nodes; scoring then ranks the survivors. Ranking is the scoring phase (D), and the kubelet starts containers (B).

    Read the full bite: Scheduler filtering and scoring phases

  25. Question 25 of 30

    How does an OCI Image Manifest primarily ensure the integrity and immutability of a container image?

    Show the answer

    Answer: b · Through the use of cryptographic hashes for the manifest itself, its configuration, and all referenced layers.

    The card explicitly states that "The manifest, its config, and its layers are all content-addressable by their cryptographic hashes, ensuring immutability and verifiability." Option A is incorrect as digital signatures are not the primary mechanism described for the manifest's inherent integrity.

    Read the full bite: OCI Image Manifest: The Recipe for a Container Image

  26. Question 26 of 30

    What is the primary reason an enterprise would implement Harbor for its container image management?

    Show the answer

    Answer: d · To establish a private, secure, and auditable repository for managing their software supply chain.

    Harbor's core purpose is to offer a private, secure, and auditable environment for an organization's software supply chain, enabling features like vulnerability scanning and content signing. While other options might be perceived as benefits of some registries, they are not the primary drivers for adopting Harbor as described in the card.

    Read the full bite: Harbor: A Private, Secure Artifact Registry

  27. Question 27 of 30

    In a hybrid ML pipeline, which scenario best justifies choosing Kubeflow over Airflow for a specific stage?

    Show the answer

    Answer: b · The stage requires distributed GPU autoscaling and native experiment tracking on Kubernetes

    Kubeflow is purpose-built for Kubernetes-native distributed GPU training, autoscaling, and built-in experiment tracking. The most tempting distractor claims Airflow cannot run containers, but the card explicitly notes Airflow can orchestrate containerized workloads via KubernetesPodOperator, so that is a common misconception rather than a valid justification.

    Read the full bite: Compare Airflow and Kubeflow for ML training pipelines

  28. Question 28 of 30

    Why is a CRD alone insufficient to manage a complex application like a database?

    Show the answer

    Answer: b · A CRD only defines and stores a new resource type; a controller is needed to act on it via a reconciliation loop

    A CRD adds schema and storage but takes no action; the Operator's controller watches the resource and reconciles real objects. CRDs are stored in etcd (C) and remain fully supported (D).

    Read the full bite: CRDs and the Operator pattern

  29. Question 29 of 30

    During a Deployment image update, what mechanism actually performs the rolling update?

    Show the answer

    Answer: c · The Deployment creates a new ReplicaSet and scales it up while scaling the old one down

    The Deployment orchestrates rollouts by creating a new ReplicaSet and shifting replicas between old and new. A ReplicaSet only maintains count; it does not rewrite Pods in place (B).

    Read the full bite: Deployment, ReplicaSet, and Pod hierarchy

  30. Question 30 of 30

    Which architecture best prevents starvation and noisy-neighbor interference in a multi-tenant GPU cluster?

    Show the answer

    Answer: b · Namespace ResourceQuotas, Kueue fair-share queues, and MIG profiles for hardware isolation

    This pairs namespace governance with fair-share scheduling to prevent starvation and hardware isolation to block memory bandwidth contention. D is tempting because it includes preemption, MIG, and quotas, but the default kube-scheduler lacks fair-share and gang scheduling semantics, so starvation remains likely.

    Read the full bite: Design multi-tenant GPU cluster scheduling and preemption policies

Could you explain these out loud?

That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon