Google ACE Practice Question: A Kubernetes namespace is shared by multiple teams

Answer analysis

Option-by-option breakdown

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

• ✗

  LimitRange — sets per-Pod CPU and memory limits

  Why it's wrong here

  A LimitRange is a namespace-scoped policy that defines default, minimum, and maximum resource requests and limits for individual Pods or containers. It does not set an aggregate ceiling: multiple Pods can each be within the per-Pod maximum yet collectively consume far more than the namespace can handle. LimitRanges apply when pod specs omit values or exceed the declared bounds, but they do not restrict total resource utilization across all Pods, so they cannot guarantee that global resource contention is avoided.

• ✓

  ResourceQuota scoped to the namespace

  Why this is correct

  A ResourceQuota scoped to a namespace is the correct control because it enforces aggregate resource ceilings at the namespace level, evaluated at admission time. For example, setting `spec.hard.requests.cpu: "10"` and `spec.hard.requests.memory: "20Gi"` makes the API server reject any new Pod whose addition would push total namespace requests beyond those values with a 403 Forbidden response. Quotas can also cap limits.cpu, limits.memory, and object counts (e.g., services, secrets, PVCs), which directly addresses the need to avoid resource contention by bounding total consumption.

• ✗

  PodDisruptionBudget limiting the number of running Pods

  Why it's wrong here

  A PodDisruptionBudget (PDB) specifies a minimum number of available Pods or a maximum number of unavailable Pods that must be maintained during voluntary disruptions such as node drains, cluster upgrades, or cluster autoscaler evictions. It is purely an availability control — it does not limit the number of running Pods at any given time and it has no mechanism to restrict aggregate CPU or memory requests. It neither rejects Pod creation when resource limits are exceeded nor prevents resource contention from excessive workloads.

• ✗

  Network Policy restricting namespace traffic to avoid resource contention

  Why it's wrong here

  NetworkPolicies are cluster-level or namespace-level firewall rules that select Pods by labels and control ingress/egress traffic at L3/L4 (IP, port, protocol). They have no bearing on CPU or memory consumption: a Pod can be allowed to communicate freely yet still be unschedulable or evicted for resource exhaustion. Resource contention from CPU/memory overcommit cannot be prevented by network traffic filtering, so this action does not address the requirement.

Go deeper

Related to this question