CKA Storage Practice Question
Exhibit
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: test
image: busybox
command: ["sleep", "3600"]
volumeMounts:
- name: cache
mountPath: /cache
volumes:
- name: cache
emptyDir:
medium: MemoryRefer to the exhibit. A pod is defined with an emptyDir volume using memory medium. The pod is scheduled on a node with 4 GB of RAM. The container writes 3 GB of data to /cache. What will happen?
⚠ Common exam trap
Many exam-takers assume emptyDir with `medium: Memory` has a default limit or triggers OOMKill, when in fact it only uses node memory and is constrained only by explicit `sizeLimit` or node capacity.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The pod will run normally because there is no memory limit and the node has sufficient RAM.
An emptyDir volume with `medium: Memory` creates a tmpfs filesystem that uses the node's RAM, but it does not impose any inherent limit on how much memory the container can consume via that volume. Since the pod has no memory limit set (no `resources.limits.memory`), the container can write up to the node's available memory (4 GB) without being throttled or killed, as long as the node has sufficient free RAM.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The container will be throttled by the kernel's memory management.
Why it's wrong here
Memory is a non-compressible resource in Linux and Kubernetes, meaning it cannot be throttled like CPU. When a container or node runs out of memory, the kernel's Out-Of-Memory killer immediately terminates the offending process rather than slowing down its execution. Therefore, memory management issues will lead to pod termination or eviction rather than kernel throttling.
- ✗
The pod will be evicted because emptyDir with memory is not allowed to use more than 1 GB.
Why it's wrong here
Kubernetes does not impose an arbitrary 1 GB limit on memory-backed emptyDir volumes. By default, a tmpfs emptyDir volume can consume up to 50% of the host node's physical memory unless a specific sizeLimit is declared in the pod specification. Since no such limit is configured here, the 3 GB write is fully permissible on a node with 4 GB of RAM.
- ✗
The pod will be OOMKilled because the emptyDir memory usage exceeds the default limit.
Why it's wrong here
There is no default memory limit applied to pods or emptyDir volumes in Kubernetes unless a LimitRange is active in the namespace. Without explicit container memory limits or an emptyDir sizeLimit specified in the manifest, the volume can scale up to the node's available memory capacity. Consequently, the pod will not trigger an Out-Of-Memory kill event simply by writing 3 GB of data.
- ✓
The pod will run normally because there is no memory limit and the node has sufficient RAM.
Why this is correct
When an emptyDir volume is configured with medium: Memory, Kubernetes mounts a tmpfs filesystem that consumes the host node's RAM. Because the pod has no defined memory limits and the 3 GB of written data fits within the node's 4 GB of physical RAM, the operation completes successfully. The pod will continue to run normally without triggering eviction or OOM termination.
Go deeper
Related to this question
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.