Top 30 Easy Docker & Kubernetes Interview Questions and Answers for Freshers
30 easy multiple-choice Docker & Kubernetes interview questions, the ones an interviewer opens with: definitions, everyday syntax, and the quick checks that you have really used it. They come from 30 bites in the Docker & Kubernetes library, the gentlest slice of the 144 Docker & Kubernetes interview questions in the library. 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.
Containers, Helm, orchestration, service mesh
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.
Question 1 of 30
What is the core architectural difference that makes a container lighter than a virtual machine?
Show the answer
Answer: c · Containers share the host kernel instead of booting a full guest OS
Containers share the host's kernel and isolate via namespaces and cgroups, avoiding a full guest OS; the compression claim is irrelevant since the weight savings come from not running a separate kernel.
Question 2 of 30
When you run a container from an image, how does Docker handle the image layers and runtime file changes?
Show the answer
Answer: a · It keeps the image layers read-only and adds a writable layer on top for runtime changes.
A container mounts the image's read-only layers and adds a writable layer on top, allowing runtime changes without altering the original image. Option B is wrong because containers are isolated processes that share the host kernel, not mini-VMs that boot their own kernels.
Read the full bite: How do Docker images and containers differ and relate?
Question 3 of 30
In docker run -d -p 8080:80 my-app:1.0, what does the 8080:80 specify?
Show the answer
Answer: b · Host port 8080 forwards to container port 80
The -p flag uses host:container ordering, so host 8080 maps to container 80; reversing this is the classic mistake and the other options misread the syntax entirely.
Read the full bite: Build, tag, and run a container with port mapping
Question 4 of 30
Which scenario is the legitimate reason to choose ADD over COPY in a Dockerfile?
Show the answer
Answer: a · Auto-extracting a local tar archive into the destination
ADD's distinguishing legitimate feature is auto-extracting local tar archives; plain file copies are exactly what COPY is for, and both support ownership flags so that is not a differentiator.
Question 5 of 30
If a Dockerfile has ENTRYPOINT ["ping"] and CMD ["localhost"], what happens when you run the container with the argument example.com?
Show the answer
Answer: d · It pings example.com, since the arg overrides CMD but appends to ENTRYPOINT
Run-time arguments replace CMD but are appended to ENTRYPOINT, so ping example.com runs; the arg does not replace the ENTRYPOINT executable nor cause a conflict.
Question 6 of 30
Why is docker compose logs -f web preferred over docker logs web to follow a Compose service's output?
Show the answer
Answer: c · compose logs resolves the service name and aggregates its containers, even when scaled
Compose logs takes the service name from the YAML and aggregates all its containers (including scaled replicas), whereas docker logs needs a specific container name or ID; docker logs does support -f.
Read the full bite: Start Compose services detached and view one service's logs
Question 7 of 30
You mount a named volume at the Postgres data directory, then run docker compose down. Why does the data survive?
Show the answer
Answer: a · Named volumes are managed independently of containers, so removing containers leaves them intact
Named volumes have a lifetime separate from containers, so down (which removes containers) leaves the volume and its data; there is no snapshot, and down does remove containers unless you add -v which would also delete the volume.
Read the full bite: Persist PostgreSQL data across compose down
Question 8 of 30
In a Compose project, why does the web app use db (the service name) rather than localhost to reach the database?
Show the answer
Answer: d · From inside the web container, localhost is the web container itself; db resolves via Docker DNS to the database
Each container's localhost refers to itself, so the web container must use the database's service name, which Docker's embedded DNS resolves to the right container; the localhost-blocking and protocol claims are false.
Read the full bite: How Compose services reach each other by name
Question 9 of 30
You run docker push my-app after building locally and get an authentication error. What is the most likely cause?
Show the answer
Answer: c · The bare name defaults to Docker Hub, where you lack push rights, instead of your private registry
An image reference without a registry host defaults to Docker Hub, so the push targets the wrong place. The image exists (D) and commit is unrelated (B); push is cross-platform (A).
Read the full bite: Tag and push an image to a private registry
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
Question 11 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).
Question 12 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.
Question 13 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
Question 14 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
Question 15 of 30
After running kubectl create deployment webapp --image=my-app:1.0 with no extra flags, how many Pods does Kubernetes schedule by default?
Show the answer
Answer: a · One, because create defaults to a single replica
create deployment defaults to a single replica, so you must scale to reach three. The 'three by default' option is a common misconception; there is no automatic per-node or zero-replica behavior.
Read the full bite: Create a Deployment with 3 replicas via kubectl
Question 16 of 30
Why is kubectl logs POD_NAME --previous often more useful than plain kubectl logs for a CrashLoopBackOff Pod?
Show the answer
Answer: b · It retrieves output from the prior crashed container instance, which holds the actual error
The current container may have just died, so --previous reads the crashed instance's logs where the error actually appears. It does not stream future logs or aggregate across Pods.
Question 17 of 30
What core problem with using raw Pod IPs does a Kubernetes Service solve?
Show the answer
Answer: d · Pod IPs are ephemeral and change when Pods are rescheduled, so a Service gives a stable address
Pods get new IPs when replaced or rescheduled, so a Service provides a stable virtual IP and DNS plus load balancing. Pod IPs are internally routable and protocol-agnostic; length is irrelevant.
Question 18 of 30
Which Service type is the standard choice for exposing a production web app to the public internet on a managed cloud?
Show the answer
Answer: c · LoadBalancer, because it provisions an external cloud load balancer with a public IP
LoadBalancer provisions a cloud load balancer with a public IP for production external access. ClusterIP is internal only, NodePort exposes raw node ports unsuited to production, and headless skips load balancing entirely.
Question 19 of 30
Which statement about Kubernetes Secrets is accurate?
Show the answer
Answer: a · Secrets store sensitive data; base64 is only encoding, and real protection needs RBAC and encryption at rest
Secrets are for sensitive data, but base64 is encoding, not encryption, so security relies on RBAC and enabling encryption at rest. They differ from ConfigMaps and can be mounted as files too.
Question 20 of 30
What is a key practical advantage of mounting a ConfigMap as a volume rather than injecting it as environment variables?
Show the answer
Answer: a · Volume-mounted ConfigMaps are updated in place, so changes can be picked up without restarting the Pod
Mounted ConfigMaps are refreshed by the kubelet so an app re-reading the file gets updates without a restart, while env vars are fixed at container start. Both can carry multiple text keys.
Read the full bite: Two ways to consume a ConfigMap in a Pod
Question 21 of 30
How does a Pod ultimately get durable storage through the PV/PVC model?
Show the answer
Answer: c · The Pod mounts a PVC, which is bound to a matching PV
A Pod references a PVC, and Kubernetes binds that claim to a satisfying PV, decoupling the workload from the storage details. Pods do not reference PVs directly, and a PVC is a request, not the mounting agent.
Read the full bite: What are PersistentVolumes and PersistentVolumeClaims for?
Question 22 of 30
A Pod with an emptyDir and a Retain PVC is deleted. What is the outcome for each volume's data?
Show the answer
Answer: c · emptyDir data is erased; the Retain PV's data persists in Released state
emptyDir lives only for the Pod's lifetime, so it is erased on deletion, while a Retain PV keeps its data and moves to Released for manual recovery. Retain does not auto-remount, and the PV's data is not deleted.
Read the full bite: What happens to volume data when a Pod is deleted?
Question 23 of 30
Which statement correctly distinguishes a Docker named volume from a bind mount?
Show the answer
Answer: b · A named volume is Docker-managed and portable; a bind mount maps a specific host path
Named volumes are managed by Docker under its data directory and are portable, while bind mounts attach a specific host path. Both persist beyond container removal, and neither relies on the disposable writable layer.
Read the full bite: Bind mounts vs named volumes for persisting Docker data?
Question 24 of 30
A container exceeds its memory limit, and separately exceeds its CPU limit. What happens in each case?
Show the answer
Answer: d · Memory: the container is OOM-killed; CPU: it is throttled
Memory is incompressible, so exceeding the limit triggers an OOM kill, while CPU is compressible and is merely throttled. Reversing these, or claiming the whole Pod is deleted, misstates how the two resource types are enforced.
Question 25 of 30
What is the simplest way to force a Pod onto nodes labeled disktype=ssd?
Show the answer
Answer: d · Add a nodeSelector with disktype: ssd to the Pod spec
A nodeSelector map of disktype: ssd is the minimal field that restricts scheduling to matching nodes. Taints and tolerations repel rather than attract, and hardcoding nodeName bypasses the scheduler and does not generalize across nodes.
Read the full bite: How do you pin a Pod to nodes with a given label?
Question 26 of 30
You want to stop new Pods landing on a node but keep current Pods running. Which command fits exactly?
Show the answer
Answer: b · kubectl cordon on the node
kubectl cordon marks the node unschedulable without disturbing running Pods, matching the goal precisely. Drain additionally evicts running Pods, deleting the node is destructive, and a NoExecute taint would force existing Pods off.
Read the full bite: How do you stop new Pods scheduling on a node?
Question 27 of 30
Which statement about granting Kubernetes RBAC permissions is correct?
Show the answer
Answer: b · A RoleBinding can reference a ClusterRole to scope it to one namespace
A RoleBinding may reference a ClusterRole, granting those permissions only within the binding's namespace. Roles cannot cover cluster-scoped nodes, bindings never define rules, and ClusterRoleBindings apply cluster-wide.
Question 28 of 30
A pod previously reachable by everyone gets its first NetworkPolicy, which specifies policyTypes Ingress but lists no ingress rules. What is the effect on inbound traffic?
Show the answer
Answer: c · All inbound traffic to the pod is now denied
Selecting a pod for Ingress flips it to default-deny; with zero allow rules, all inbound traffic is dropped. An empty-rule policy is a lockdown, not a no-op.
Read the full bite: First NetworkPolicy flips a pod to default-deny
Question 29 of 30
Why is running a logging agent as a DaemonSet preferred for ensuring logs survive pod termination?
Show the answer
Answer: c · Container stdout logs live on the node and are deleted with the pod, so a per-node agent ships them to durable storage
Container logs are ephemeral node files removed when a pod is deleted, so a per-node DaemonSet agent forwards them to a central store. kubectl logs is not durable, and DaemonSets run one agent per node, not per pod.
Read the full bite: Viewing pod logs and durable log collection
Question 30 of 30
Which metric would come from kube-state-metrics rather than node-exporter?
Show the answer
Answer: d · Number of available replicas in a Deployment
kube-state-metrics exposes API object state like Deployment replica counts. CPU, disk, and network host metrics come from node-exporter, which knows nothing about Kubernetes objects.
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.