CKAD Practice Question: Application Environment, Configuration and Security
Which THREE of the following are benefits of using a ResourceQuota in a namespace? (Select THREE)
⚠ Common exam trap
A common mix-up: candidates confuse the purpose of a ResourceQuota with a LimitRange, mistakenly thinking a ResourceQuota sets default resource requests/limits, when in fact that is exclusively a LimitRange feature.
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
✓
It can enforce that every Pod has resource limits set
Option B is correct because a ResourceQuota can include the key limits.cpu and limits.memory (or requests.cpu/requests.memory), which forces every Pod in the namespace to declare matching resource limits or requests—otherwise the Pod is rejected at admission time. Option D is correct because by capping aggregate CPU, memory, storage, and object counts per namespace, ResourceQuota stops one namespace from consuming the entire cluster's capacity and starving other tenants. Option E is correct because ResourceQuota tracks the sum of requests/limits across all Pods in the namespace and denies any new Pod that would push the total past the configured CPU or memory ceiling. Option A is not correct because setting default requests and limits is the job of a LimitRange, not a ResourceQuota. Option C is not correct because restricting which users can create Pods is handled by RBAC (Roles/RoleBindings) or admission policies, not by ResourceQuota.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
It sets default resource requests and limits for Pods that don't specify them
Why it's wrong here
ResourceQuota does not mutate or inject default resource values into individual Pod specifications. That capability belongs to a LimitRange, which supplies defaults for requests and limits when a Pod omits them, subject to its own validation. In contrast, a ResourceQuota only establishes hard aggregate ceilings for a namespace; it never alters Pod specs, so a Pod without explicit limits remains untouched by the quota.
- ✓
It can enforce that every Pod has resource limits set
Why this is correct
By declaring `limits.cpu` and `limits.memory` in the quota's `hard` map, the namespace is forced to have every Pod set these fields explicitly. The quota admission controller rejects any Pod whose PodSpec does not include a CPU and memory limit, regardless of the actual values. This guarantees that no Pod can run unbounded, although it does not enforce a particular limit size; a LimitRange or individual Pod spec sets the actual numbers.
- ✗
It restricts which users can create Pods in the namespace
Why it's wrong here
ResourceQuota is entirely orthogonal to authentication and authorization. Granting or denying Pod creation permissions is the responsibility of RBAC roles and role bindings, which map users or service accounts to verbs (create, get, etc.) on resources. A ResourceQuota takes effect only after an authorized request is evaluated, constraining consumption for all subjects equally; it cannot distinguish one user from another. Access-control decisions are made by kube-apiserver's RBAC layer before quota admission runs.
- ✓
It prevents a single namespace from exhausting cluster resources
Why this is correct
Without a quota, a single namespace's workloads can consume arbitrary amounts of CPU and memory, leaving other namespaces with resource starvation. A ResourceQuota imposes a hard cap on aggregate usage, which the admission controller enforces at creation time, so any request that would exceed the cap is denied. That guarantee protects the cluster's schedulable resources and preserves a baseline of availability for other tenants, making resource sharing predictable and fair across namespaces.
- ✓
It limits the total amount of CPU and memory that can be consumed by all Pods in the namespace
Why this is correct
The ResourceQuota's `hard` specification can name exact resource quantities, for example `requests.cpu: "10"` and `limits.memory: 20Gi`, to cap aggregate consumption across all pods in the namespace. As Pods are created, the admission controller sums the requested and limited amounts for every existing object plus the incoming Pod and denies admission if the total exceeds any quota keyword. This enforces a concrete, namespace-wide ceiling on CPU and memory usage, distinct from mechanisms that merely set defaults or validate individual Pod values.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-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 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.