A latency-sensitive service shows periodic latency spikes. CPU utilisation on the node is 40%. What do you check first?

What the interviewer is testing

Whether you know the specific and counter-intuitive behaviour of Kubernetes CPU limits, which produces exactly this symptom.

The mechanism

A container is throttled at its CPU limit even when the node has abundant idle CPU. The limit is enforced by the kernel over short scheduling periods — typically 100 ms — so a container that exhausts its quota part-way through a period is stopped until the next one.

The result is latency spikes measured in tens of milliseconds, appearing at high percentiles, with node-level utilisation looking perfectly healthy. Teams look at the node, see 40%, and go hunting elsewhere.

The metric that confirms it is throttling time or throttled period count for the container, which is exposed and rarely on anyone's dashboard.

The fix

For latency-sensitive services, set a CPU request based on measured usage and consider omitting the CPU limit, letting the container burst into idle capacity. This is counter to intuition — limits feel like good hygiene — and it is well supported by production experience.

The request is what guarantees the share and drives scheduling; the limit only caps the upside.

Where limits are still warranted: multi-tenant clusters where a runaway container must not starve neighbours, and batch workloads where predictability matters more than latency.

Memory is different, and the contrast matters

Memory is incompressible: exceeding a memory limit terminates the container immediately. There is no throttling equivalent. So the guidance inverts — set memory request and limit equal, so the pod is guaranteed what it needs and is killed predictably rather than evicted at an arbitrary moment.

What a strong answer adds

Checking the runtime's own view of available CPU. Many runtimes size thread pools and garbage collector threads from the node's core count rather than the container's quota, which produces oversubscription and makes throttling far worse. Setting the runtime's parallelism explicitly is a frequent and dramatic fix.

Common weak answers

Raising the limit without understanding why, which sometimes helps and does not explain the behaviour. Blaming garbage collection without checking throttling metrics.