KCNA Kubernetes Fundamentals Practice Question
Which two of the following are valid ways to set resource constraints on a container in a Pod spec?
⚠ Common exam trap
Many exam-takers confuse the naming convention of Kubernetes resource fields (e.g., 'limits' vs 'max', 'requests' vs 'min' or 'guarantees'), leading them to choose plausible-sounding but non-existent keys like 'resources.max.cpu' or 'resources.guarantees.cpu'.
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
✓
Specify 'resources.limits.memory' for maximum memory
Option B is correct because the Pod spec's container definition uses the 'resources.limits' field to declare the maximum amount of a resource the container may consume, so 'resources.limits.memory' sets a hard memory ceiling that the container cannot exceed. Option D is correct because 'resources.requests.cpu' declares the minimum CPU the container is guaranteed for scheduling purposes, and the kubelet uses this value when allocating CPU shares. The other options are invalid field names: 'resources.guarantees.cpu' (A), 'resources.min.memory' (C), and 'resources.max.cpu' (E) do not exist in the Kubernetes API, which only supports 'requests' and 'limits' under 'resources'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Specify 'resources.guarantees.cpu' for CPU guarantees
Why it's wrong here
Kubernetes Pod specs define resources under 'resources.requests' and 'resources.limits'; no 'guarantees' field exists. It is tempting because guarantees conceptually resemble requests, so the term sounds plausible, yet the API would reject this unknown field during validation.
- ✓
Specify 'resources.limits.memory' for maximum memory
Why this is correct
Setting `resources.limits.memory` in a container's spec caps the memory the container may consume, so the kubelet enforces the limit and the container is OOM-killed if it exceeds it. This directly satisfies the stem's requirement for a valid resource constraint mechanism within the Pod spec.
- ✗
Specify 'resources.min.memory' for minimum memory
Why it's wrong here
Resource constraints use 'resources.requests' and 'resources.limits'; 'resources.min.memory' is not a valid field. It is tempting because a minimum memory concept mirrors requests, but Kubernetes expresses that through requests.memory, and an unrecognised key fails schema validation.
- ✓
Specify 'resources.requests.cpu' for minimum CPU
Why this is correct
Setting `resources.requests.cpu` declares the minimum CPU the scheduler reserves for the container, guaranteeing that capacity on the node. This directly satisfies the stem's requirement for a valid resource constraint in the Pod spec, since requests define the guaranteed floor rather than a hard ceiling.
- ✗
Specify 'resources.max.cpu' for CPU limits
Why it's wrong here
Kubernetes nests limits under resources.limits.cpu; resources.max.cpu is not a recognised field and the API server rejects the manifest. It tempts because 'max' intuitively suggests an upper bound, and a schema using resources.max would be valid in some other orchestrators' resource models.
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 930-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 KCNA 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 KCNA exam.