CKA resource requests Practice Question
Which TWO of the following are valid ways to specify resource requests and limits for a container in a pod? (Select 2)
⚠ Common exam trap
A common mix-up: candidates confuse the singular `resource` with the correct plural `resources`, or they incorrectly place CPU/memory fields directly under the container spec without the proper nesting, mimicking the syntax of Docker Compose or older Kubernetes versions.
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
✓
spec: containers: - name: app resources: requests: cpu: "500m" memory: "512Mi" limits: cpu: "1" memory: "1Gi"
Options C and D are both correct. Option C uses the correct YAML structure with a `resources` block containing both `requests` and `limits`, and specifies CPU as a string (e.g., "500m") and memory as a string (e.g., "512Mi"). Option D is also valid because Kubernetes allows specifying only `limits` without `requests`; the request defaults to the limit if omitted. Both options conform to the Kubernetes API specification for resource management in Pod containers. Options A, B, and E contain invalid syntax: A uses CPU and memory directly under the container without a resources block; B uses the singular `resource` instead of the plural `resources`; E uses invalid units ('millicores' and 'MB').
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
spec: containers: - name: app cpu: 0.5 memory: 512Mi
Why it's wrong here
Placing `cpu` and `memory` directly under the container spec is invalid because Kubernetes expects resource constraints inside a nested `resources` object with `requests` and `limits` subfields. At the container level, Kubelet looks for `resources.requests` and `resources.limits` to enforce CPU and memory guarantees, not top-level keys. Even though `cpu: 0.5` is a legitimate way to express half a core, this YAML fails schema validation because the keys are in the wrong location.
- ✗
spec: containers: - name: app resource: request: cpu: 1 memory: 1Gi limit: cpu: 2 memory: 2Gi
Why it's wrong here
The field names here are singular (`resource`, `request`, `limit`), but the Kubernetes API requires the plural forms: `resources`, `requests`, and `limits`. Additionally, the structure is flattened incorrectly—the `resource` object should contain `requests` and `limits`, not nested under a singular `resource` key. If the correct plural names were used, requests and limits for both CPU and memory would be valid, but as written this YAML is rejected by the API server.
- ✓
spec: containers: - name: app resources: requests: cpu: "500m" memory: "512Mi" limits: cpu: "1" memory: "1Gi"
Why this is correct
This is the canonical way to specify resource requirements in Kubernetes: each container has a `resources` field containing `requests` and `limits`. The `cpu` value `"500m"` means 500 milliCPUs (half a core), and `"1"` means one full core; memory uses binary suffixes, with `"512Mi"` and `"1Gi"` being valid mebibyte units. These strings are parsed by Kubernetes quantity format, and this structure is accepted by the API server while satisfying both scheduling and kubelet constraints.
- ✓
spec: containers: - name: app resources: limits: cpu: "1" memory: "1Gi"
Why this is correct
Specifying only `limits` is a valid shorthand because Kubernetes automatically sets each resource's `request` equal to its `limit` when a limit is defined but a request is not. This means for the CPU limit of `"1"` and memory limit of `"1Gi"`, the scheduler uses these values as requests as well, resulting in a Guaranteed QoS class since requests exactly equal limits. This YAML is accepted and often used when the operator wants a strict upper bound and is willing to dedicate those resources to the container.
- ✗
spec: containers: - name: app resources: requests: cpu: "500 millicores" memory: "512 MB"
Why it's wrong here
This entry is invalid because Kubernetes quantity strings do not accept natural-language units like `"millicores"` or space-separated memory like `"512 MB"`. CPU must be expressed as a number of cores (e.g., `"1"` or `"0.5"`) or as milliCPU with the `m` suffix (e.g., `"500m"`), and memory must use Kubernetes quantity suffixes such as `Mi`, `Gi`, `M`, or `G` without spaces. The valid memory units are binary (Ki, Mi, Gi) or decimal (K, M, G), but `"MB"` is not a recognized suffix, and `"millicores"` is not parsed by the resource quantity library.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
About these practice questions
One of 302 original CKA 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 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.