CKAD Application Deployment Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  requests: memory: 2Gi, cpu: 500m; no limits

  Why it's wrong here

  Setting memory and CPU requests but leaving limits unset does not produce BestEffort QoS; a pod with non-zero requests and no limits is classified as Burstable. The scheduler honors the 2Gi/500m requests, but without a cgroup limit the container can consume all free CPU and memory on the node, so it is not isolated and may be evicted or OOM-killed under node pressure. This configuration fails to give the application a hard resource ceiling, so it is not the correct guaranteed deployment.

• ✓

  requests: memory: 2Gi, cpu: 500m; limits: memory: 2Gi, cpu: 500m

  Why this is correct

  When memory and CPU requests are set identically to their limits, the pod belongs to the Guaranteed QoS class, which is the only class with the highest eviction priority. The node reserves exactly 2Gi of memory and 500m of CPU for scheduling, while the runtime caps actual usage at those same values, preventing memory overcommit and making the pod's resource behavior completely predictable. This matches the stated 2Gi requirement and ensures the application is never silently granted less or allowed to escape its quota.

• ✗

  requests: memory: 2Gi, cpu: 500m; limits: memory: 4Gi, cpu: 1

  Why it's wrong here

  This configuration is Burstable because the requests (2Gi memory, 500m CPU) are lower than the limits (4Gi memory, 1 full CPU). The scheduler only guarantees the request values, so the pod is permitted to burst up to the higher limits, but that extra headroom means its usage is not tightly bounded and it can be evicted before a Guaranteed pod when memory pressure occurs. It does not provide the deterministic resource envelope the 2Gi application needs, especially since the CPU limit of 1 allows double the requested capacity.

• ✗

  requests: memory: 1Gi, cpu: 250m; limits: memory: 2Gi, cpu: 500m

  Why it's wrong here

  Although the memory limit is 2Gi, the memory request is only 1Gi, so the scheduler may place this pod on a node with just 1Gi of available memory — half of what the application requires. With CPU request at 250m and limit at 500m, the pod is again Burstable and is guaranteed only a quarter of a vCPU, risking CPU starvation and memory exhaustion because the advertised request does not reflect the real 2Gi memory need. This under-provisions the baseline resources, making the workload vulnerable to eviction or OOM before it can reach its limit.

Go deeper

Related to this question