Set requests from observed usage, typically around the median for CPU and near the peak for memory, because requests drive scheduling and capacity. Set a memory limit close to the request, since exceeding it gets the container killed, and be cautious with CPU limits because they cause throttling that shows up as unexplained latency. Revisit the numbers with real data rather than copying them between services.
Why interviewers ask this
This is a practical question where wrong answers cause real production pain, and the interviewer probably has scars. They want you to know that CPU is compressible and memory is not, that CPU limits cause throttling rather than a graceful slowdown, and that requests determine both scheduling and cluster cost. Mentioning quality of service classes and how to measure usage shows depth.
How to structure your answer
- Explain that requests drive scheduling and limits drive enforcement.
- Separate CPU from memory because they behave differently.
- Give a method for arriving at numbers from real data.
- Mention throttling, out of memory kills, and quality of service.
Example answer
Requests are what the scheduler uses to place the pod and what you are effectively paying for, and limits are the ceiling the runtime enforces. The two resources behave completely differently. CPU is compressible, so hitting a CPU limit means the container gets throttled, and that appears as latency spikes with no obvious cause, which is horrible to debug. Memory is not compressible, so exceeding the memory limit means the container is killed outright. That leads to my defaults: set the CPU request from the observed median usage with some headroom, and I am usually cautious about CPU limits on latency sensitive services, or I set them generously. For memory I set the request near the realistic peak and the limit close to it, so a leak fails fast and visibly rather than quietly eating the node. I get the numbers from a couple of weeks of actual usage percentiles, not from copying another service, and I revisit after load tests. The other side is that inflated requests are the main reason clusters look empty and still cannot schedule anything.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What happens to a pod when it exceeds its memory limit?
- Why might you deliberately omit a CPU limit?
- How do the quality of service classes affect eviction order?
Related devops engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions