City platform engineers aggregate kubectl top pod views and notice one namespace dominating cluster CPU. What capability does that analysis demonstrate?
Select an answer to reveal the explanation.
Short Explanation
Zoom out from one pod and the hotspot jumps out—one namespace eating the pie. Aggregation turns raw top output into 'who is burning the cluster.'
Full Explanation
Aggregating kubectl top pod views until one namespace dominates cluster CPU demonstrates attributing consumption hotspots to a specific namespace or application set. City platform engineers move from single-pod anecdotes to a clear answer for who is burning the shared cluster, which is essential multi-tenant operations across departments that share the same municipal platform. That analysis is not about binding Ingress resources without a controller; whether an Ingress attaches is unrelated to CPU attribution from top. It is not about encrypting etcd at rest without configuration; encryption-at-rest is a control-plane data protection feature, not an outcome of aggregating kubectl top. It is not automatic deletion of all NetworkPolicies; discovering a hot namespace does not authorize or imply destroying network policy objects cluster-wide. Exam caveat: Namespace dominance may be legitimate for a large department or abusive because of a memory/CPU leak—follow the finding with per-pod top and consider ResourceQuotas. Know how to scope or filter top by namespace under exam time pressure. Operational check: Run kubectl top pods across namespaces, identify the hot tenant, engage the owning civic team with the graphs, and apply quotas or rightsizing so one namespace cannot starve its neighbors.