CPU and memory limits are enforced by different mechanisms with different failure modes. A CPU limit is translated into a Linux CFS quota: when the container exhausts its quota inside a 100 ms period, it is descheduled until the next period. Nothing is killed, but latency spikes and the container's container_cpu_cfs_throttled_seconds_total metric climbs.
A memory limit is a hard cgroup ceiling. Exceeding it triggers the kernel OOM killer, the container terminates with exit code 137, and kubectl describe pod shows Reason: OOMKilled. The pod is then restarted according to its restart policy.
The practical consequences are opposite. Setting a CPU limit too low degrades tail latency silently and is a common cause of unexplained p99 regressions, so many teams set CPU requests and omit CPU limits. Memory limits should be set, because an unbounded container competes with the node and can trigger node-level eviction of unrelated pods. Requests, not limits, are what the scheduler uses to place a pod.