CKAD Application Design and Build Practice Question
Which of the following is the correct way to set a memory limit of 512Mi for a container in a pod spec?
⚠ Common exam trap
Many candidates confuse `requests` (guarantees) with `limits` (caps), or misplace the `limits` field as a subfield of `requests`, leading them to pick option C or A instead of the correct B.
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
✓
resources.limits.memory: 512Mi
`resources.limits.memory` is the Kubernetes field used to set the maximum amount of memory a container is allowed to use. When a container exceeds this limit, it may be terminated or OOM-killed. The value `512Mi` specifies 512 mebibytes, which is a binary-based unit commonly used in Kubernetes resource specifications.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
resources.requests.memory: 512Mi
Why it's wrong here
This sets the memory request, which is the amount Kubernetes uses for scheduling decisions and guarantees the container can reserve—it is not a hard ceiling. A container can exceed this value and consume node memory up to the limit (or the node's allocatable memory if no limit is set), so it does not prevent OOM-kill or enforce a cap. The memory request only helps the scheduler place the pod; you need resources.limits.memory for the actual maximum.
- ✓
resources.limits.memory: 512Mi
Why this is correct
This is correct because resources.limits.memory defines the hard upper bound on memory that the container can use. When the container's memory usage exceeds this value, the kernel will terminate the container with an OOMKilled error (if memory pressure exists) or the container will be evicted. It also affects the pod's Quality-of-Service class, especially when paired with a matching request.
- ✗
resources.requests.limits.memory: 512Mi
Why it's wrong here
This path is structurally invalid: under 'resources', the keys 'requests' and 'limits' are separate sibling objects, each containing 'cpu' and 'memory'. Writing 'requests.limits.memory' implies a nested 'limits' object inside 'requests', which does not exist in the API schema and will cause a validation error. Even conceptually, a 'request' and a 'limit' are distinct constructs—a request is a reservation, while a limit is an enforcement ceiling; they cannot be combined in this way.
- ✗
resources.limits.cpu: 512Mi
Why it's wrong here
This incorrectly uses the 'cpu' key to specify a memory value. In Kubernetes resource specifications, 'cpu' is measured in cores or millicores (e.g., 500m, 1), while 'memory' uses binary or decimal byte units like Mi or Gi. Specifying '512Mi' under 'limits.cpu' is a unit mismatch that will be rejected as an invalid quantity; to limit memory you must use 'resources.limits.memory'.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 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 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.