CKAD Practice Question: Application Environment, Configuration and Security
You have a LimitRange in namespace 'ns' that sets default limits.cpu to 500m and default requests.cpu to 200m. You create a pod without specifying any CPU resources. What CPU values will be applied to the container?
⚠ Common exam trap
Test-takers frequently assume a pod without resource specs will be rejected or have no limits, but the LimitRange admission controller silently applies defaults, making option B correct.
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: 200m, limit: 500m
When a LimitRange is configured in a namespace with default CPU limits and requests, any pod created without specifying CPU resources will have those defaults injected by the admission controller. The LimitRange sets default limits.cpu to 500m and default requests.cpu to 200m, so the container will receive request: 200m and limit: 500m. This is enforced by the LimitRanger admission plugin during pod creation.
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 pod will be rejected by the admission controller
Why it's wrong here
The pod is not rejected. A LimitRange acts as a mutating admission controller: for containers that omit resource specifications, it inserts default requests and limits rather than blocking creation. Rejection occurs only when a container's final resource values violate the configured min or max constraints of the LimitRange, not for simply lacking a resources field.
- ✓
request: 200m, limit: 500m
Why this is correct
Correct. When a container in the pod has no resources field, the LimitRange defaults apply during admission: the defaultRequest value fills the request and the default value fills the limit. The effective pod spec therefore contains request: 200m and limit: 500m, and these values are used for scheduling, QoS classification, and kubelet enforcement.
- ✗
request: 0, limit: 0 (no limits enforced)
Why it's wrong here
A LimitRange never leaves resource values at zero for a container that omits them; admission substitutes the configured defaults. For request: 0 and limit: 0 to occur, the LimitRange would have to define neither defaultRequest nor default, but this namespace has both set. Thus the container gets non-zero effective values and CPU limits are enforced from the start.
- ✗
request: 500m, limit: 500m
Why it's wrong here
The default request is 200m, not 500m; only the limit defaults to 500m. If request and limit were both 500m, the container would have no burst allowance and would be classified as Guaranteed, but the LimitRange in this namespace sets defaultRequest to 200m, producing a Burstable workload with headroom between request and limit.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD 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 CKAD exam.