yoklainterview sim
ProgressHistory

DevOps / Cloud K8s Storage Interview Questions

75 verified DevOps / Cloud K8s Storage interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

K8s StorageDifficulty 1
A Pod uses an emptyDir volume mounted at /data. A process writes a file there, then the Pod is deleted and a new Pod with the same spec is created. What happens to the file?
  • aIt is copied to the new Pod automatically by the kubelet
  • bIt stays on the node and the new Pod mounts the same directory
  • cIt is gone, since emptyDir is scoped to that Pod's lifetime✓
  • dIt moves to whichever PersistentVolume is bound in the namespace
Explanation:An emptyDir volume is created when a Pod is assigned to a node and its contents are deleted permanently when that specific Pod is removed. A new Pod, even with an identical spec, gets a fresh empty directory.
K8s StorageDifficulty 1
A Pod mounts a persistentVolumeClaim volume backed by a PVC that is Bound. The Pod is deleted and a new Pod referencing the same PVC name is created in its place. What happens to files written before deletion?
  • aThey remain, because the PVC and its underlying storage outlive the Pod✓
  • bThey are lost, because volumes are always scoped to a single Pod
  • cThey remain only if the new Pod runs on the same node
  • dThey are lost unless the StorageClass has reclaimPolicy: Retain
Explanation:A PVC is a separate API object bound to a PersistentVolume; its lifecycle is independent of any single Pod. Any Pod that mounts the same PVC sees the same underlying storage and data, regardless of which node it lands on (for network-backed storage) or whether it's a brand-new Pod.
K8s StorageDifficulty 2
You apply this PVC in a cluster where the only StorageClass is named standard:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 1Gi

kubectl get pvc data-pvc is run right after. What is shown in the STATUS column?
  • aBound, because Kubernetes falls back to the default StorageClass
  • bPending, because no fast-ssd StorageClass exists to satisfy the request✓
  • cFailed, because the PVC gets rejected by the API server at creation time
  • dBound, because storage 1Gi is small enough for any provisioner to satisfy
Explanation:A PVC that names a non-existent StorageClass has nothing to bind or provision against, so it stays Pending. kubectl describe pvc shows an event like storageclass.storage.k8s.io "fast-ssd" not found from the persistentvolume-controller.
K8s StorageDifficulty 2
In a minikube cluster (default StorageClass standard, provisioner k8s.io/minikube-hostpath), you apply:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 1Gi

No storageClassName field is set. What happens?
  • aThe PVC stays Pending, because no StorageClass was explicitly requested
  • bThe PVC is rejected, because storageClassName is a required field
  • cAn admin must manually create a matching PersistentVolume first
  • dThe PVC uses the default StorageClass and provisions dynamically✓
Explanation:When storageClassName is omitted, Kubernetes uses whichever StorageClass is marked as default (annotated storageclass.kubernetes.io/is-default-class: "true"). Its provisioner then dynamically creates a matching PersistentVolume and the PVC becomes Bound without any admin step.
K8s StorageDifficulty 1
A PersistentVolumeClaim requests accessModes: ["ReadWriteOnce"]. What does this mean in practice?
  • aOnly one container inside a Pod can mount the volume
  • bThe volume can be mounted read-write by a single node at a time✓
  • cThe volume can only ever be written to once, then becomes read-only
  • dOnly the Pod that created the PVC can ever mount it again
Explanation:ReadWriteOnce (RWO) means the volume can be mounted as read-write, but by only one node at a time — multiple Pods scheduled to that same node can still share the mount. Multiple Pods on different nodes cannot mount an RWO volume simultaneously.
K8s StorageDifficulty 2
Pod A on node-1 mounts a PVC with accessModes: ["ReadWriteOnce"] and the underlying PV is currently attached to node-1. A Deployment rollout schedules Pod B, which mounts the same PVC, onto node-2. What is the most likely outcome?
  • aPod B stays stuck (ContainerCreating) since RWO can't attach to two nodes✓
  • bBoth Pods mount the volume simultaneously without any issue
  • cPod A is automatically evicted so Pod B can attach the volume
  • dThe PVC silently switches to ReadOnlyMany to allow both mounts
Explanation:An RWO volume can only be attached to one node at a time. If Pod A's node still holds the volume, Pod B on a different node will fail to mount it and remain stuck until the volume is detached (typically after Pod A terminates).

By specialization

AWS 450Azure 450GCP 450Kubernetes 450Linux 450Terraform 450

By seniority

DevOps / Cloud JuniorDevOps / Cloud MidDevOps / Cloud Senior

Other fields

BackendFrontendFullstackAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3375-question DevOps / Cloud bank.

Start interview