CKA Workloads and Scheduling Practice Question
You apply a LimitRange that sets default CPU request to 0.5 and default CPU limit to 1. You create a pod without specifying any CPU resources. What are the effective CPU request and limit for the pod?
⚠ Common exam trap
A common mix-up: candidates think a pod without resource specifications will have no limits or requests, but the LimitRange admission controller automatically applies defaults, overriding the absence of explicit values.
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
✓
request: 0.5, limit: 1
When a LimitRange is applied to a namespace, it automatically injects default resource requests and limits into pods that do not specify them. In this case, the LimitRange sets default CPU request to 0.5 and default CPU limit to 1, so the pod inherits these values. This ensures the pod is subject to resource constraints even without explicit specification.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
request: 0.5, limit: 1
Why this is correct
The LimitRange's admission controller applies its declared default request and default limit to any Pod that omits resource requirements. Because default.cpu is 0.5 and default.limit is 1, the effective container specification becomes request: 0.5, limit: 1. This happens automatically at Pod creation, before the object is persisted, so you do not need to manually add the values to the manifest.
- ✗
request: 0.5, limit: 0 (no limit)
Why it's wrong here
This option captures only the CPU request default and incorrectly treats the limit as unset (0). A LimitRange's defaultLimit value is also injected when the container has no explicit limit, so the limit becomes 1, not 0 or omitted. Moreover, a limit of '0' is not a valid representation of 'no limit' in a computed resource quantity; unset limits are simply absent from the object.
- ✗
request: 0, limit: 0 (no defaults applied)
Why it's wrong here
This answer assumes that LimitRange defaults only apply when the Pod's namespace is explicitly labeled or when you set something in the Pod spec, but admission control does this automatically. Any container without a CPU request or limit gets both default.cpu (0.5) and default.limit (1) at creation time, regardless of how the manifest was written. A zero request/limit pair also contradicts QoS class assignment, since a fully defaulted Pod would be Burstable rather than BestEffort.
- ✗
request: 1, limit: 0.5
Why it's wrong here
This configuration swaps the LimitRange's request and limit values. The LimitRange specifies default.cpu=0.5 and default.limit=1, so a correct defaulted container must have request <= limit. A request of 1 and limit of 0.5 violates the Kubernetes invariant that a container's resource request cannot be greater than its limit (when a limit is set), and it also does not match the declared defaults.
About these practice questions
Courseiva writes every CKA question from scratch — 726 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.