A team cannot create additional ConfigMaps in the finance namespace even though CPU and memory quota still show headroom. Which ResourceQuota capability most likely explains the deny?
Select an answer to reveal the explanation.
Short Explanation
Quotas are not only about CPU piles — they can also count how many ConfigMaps, Secrets, or PVCs exist. Hitting the object counter blocks creates even when compute still has room. Check the hard counts on the ResourceQuota.
Full Explanation
When a team cannot create additional ConfigMaps in the finance namespace even though CPU and memory quota still show headroom, a ResourceQuota hard limit on configmaps (object count) most likely explains the deny. ResourceQuota can constrain both compute totals and object counts independently, so CPU headroom does not authorize another ConfigMap once the configmaps count is exhausted. Municipal finance namespaces often cap ConfigMap counts to prevent config sprawl from filling etcd.
Claiming ResourceQuotas never limit object counts and that only node allocatable CPU can block ConfigMaps fails because object-count quota resources are a standard capability and ConfigMaps are not scheduled onto node CPU. Claiming ConfigMap creates ignore quotas unless binaryData keys exist invents a special case that does not exempt ordinary creates. Claiming LimitRange maxLimits.cpu applies to ConfigMaps the same way it applies to Pods fails because LimitRange targets Pod/container resource fields, not ConfigMap object admission counts.
Exam caveat: quota resource names are exact—configmaps versus pods versus secrets—so read the ResourceQuota status carefully. Operational check: kubectl describe resourcequota -n finance, note the configmaps used versus hard values, delete unused ConfigMaps or raise the count through platform change, then retry creation.